廣州熱線(xiàn)

去年，熱門(mén)數(shù)據(jù)庫(kù)廠商Databricks和Snowflake因TPC-DS測(cè)試結(jié)果在湖倉(cāng)戰(zhàn)場(chǎng)正面開(kāi)撕，讓很多業(yè)內(nèi)吃瓜群眾大呼過(guò)癮，我們暫且不論兩企業(yè)究竟孰強(qiáng)孰弱。事實(shí)上，作為大數(shù)據(jù)分析賽道的代表性廠商，不論是具備數(shù)據(jù)倉(cāng)庫(kù)功能的數(shù)據(jù)湖工具Databricks，還是借鑒數(shù)據(jù)湖范式的可擴(kuò)展數(shù)據(jù)倉(cāng)庫(kù)Snowflakes，其發(fā)展路線(xiàn)都說(shuō)明“湖倉(cāng)一體化”已成為了目前市場(chǎng)主流的技術(shù)發(fā)展方向。

雖然業(yè)界對(duì)于湖倉(cāng)一體的價(jià)值是高度認(rèn)同的，但作為一種新興的架構(gòu)，大多數(shù)公司對(duì)于湖倉(cāng)一體仍處在初期的探索階段，有些企業(yè)甚至對(duì)于要選擇怎樣的湖倉(cāng)一體架構(gòu)仍舊是云里霧里。很多人難免會(huì)問(wèn)，我們到底需要什么樣的湖倉(cāng)一體？

1 當(dāng)下企業(yè)對(duì)湖倉(cāng)的需求場(chǎng)景

隨著網(wǎng)絡(luò)的高速發(fā)展，產(chǎn)生的數(shù)據(jù)也爆炸性增長(zhǎng)，企業(yè)對(duì)數(shù)據(jù)的使用也逐步從離線(xiàn)場(chǎng)景到實(shí)時(shí)數(shù)據(jù)分析場(chǎng)景的轉(zhuǎn)變。剛開(kāi)始，很多企業(yè)主要是利用離線(xiàn)場(chǎng)景對(duì)歷史數(shù)據(jù)進(jìn)行分析，而隨著業(yè)務(wù)發(fā)展到一定規(guī)模以后，離線(xiàn)數(shù)據(jù)的缺點(diǎn)就愈發(fā)凸顯，公司的業(yè)務(wù)方、決策方對(duì)實(shí)時(shí)化數(shù)據(jù)提出了更高的訴求，希望從業(yè)務(wù)端獲取到數(shù)據(jù)以后，便能夠立即被清洗處理，從而滿(mǎn)足基于數(shù)據(jù)的事前預(yù)測(cè)、事中判斷和事后分析。

實(shí)時(shí)數(shù)據(jù)分析的需求場(chǎng)景一般分為四個(gè)層面：

運(yùn)營(yíng)層面：實(shí)時(shí)業(yè)務(wù)變化、實(shí)時(shí)營(yíng)銷(xiāo)效果、當(dāng)日業(yè)務(wù)趨勢(shì)分析；

用戶(hù)層面：搜索推薦排序、實(shí)時(shí)行為等特征變量的生產(chǎn)，為用戶(hù)推薦更精準(zhǔn)的內(nèi)容；

風(fēng)控層面：實(shí)時(shí)風(fēng)險(xiǎn)識(shí)別、反欺詐、異常交易等；

生產(chǎn)層面：實(shí)時(shí)監(jiān)控系統(tǒng)的穩(wěn)定性和健康狀況等。

不難發(fā)現(xiàn)，無(wú)論是互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)企業(yè)，數(shù)據(jù)的時(shí)效性都被擺在了重要位置，甚至有些企業(yè)已經(jīng)從 PV、UV 指標(biāo)等單點(diǎn)實(shí)時(shí)化進(jìn)階到了全面實(shí)時(shí)化的階段。也正于因此，數(shù)據(jù)的時(shí)效性也就成為了企業(yè)判斷自身架構(gòu)設(shè)計(jì)是否滿(mǎn)足真正湖倉(cāng)一體的關(guān)鍵因素。

總體來(lái)看，企業(yè)到底需要怎樣的湖倉(cāng)一體架構(gòu)？除了要滿(mǎn)足實(shí)時(shí)化數(shù)據(jù)需求這一關(guān)鍵要素以外，數(shù)據(jù)一致性、超高并發(fā)、云原生、支持多類(lèi)型數(shù)據(jù)以及一份數(shù)據(jù)也被列入了湖倉(cāng)一體的 ANCHOR 六大特征。

2 基于OushuDB的云原生湖倉(cāng)一體

如前文所言，隨著市場(chǎng)競(jìng)爭(zhēng)和用戶(hù)需求的不斷變幻，企業(yè)對(duì)于數(shù)據(jù)的時(shí)效性需求不斷攀升，但實(shí)時(shí)數(shù)據(jù)的分析場(chǎng)景出現(xiàn)以后，也給數(shù)據(jù)技術(shù)的實(shí)現(xiàn)帶來(lái)了很大的挑戰(zhàn)。目前，無(wú)論是擅長(zhǎng)事務(wù)型工作的數(shù)據(jù)倉(cāng)庫(kù)，還是數(shù)據(jù)類(lèi)型更為豐富的數(shù)據(jù)湖，亦或是 Hadoop+MPP 模式下的湖倉(cāng)分體，其都是基于 T+1 設(shè)計(jì)的，即便引入了流處理引擎實(shí)現(xiàn)了部分固定模式的實(shí)時(shí)分析，仍無(wú)法達(dá)到 T+0 全實(shí)時(shí)的水平。

為了讓數(shù)據(jù)實(shí)現(xiàn)全面實(shí)時(shí)化，行業(yè)內(nèi)也衍生出了不同的湖倉(cāng)一體方案，可以將其大致分為兩類(lèi)：一類(lèi)是基于 Hadoop 的改造方案，拿 Hudi、Iceberg 兩款開(kāi)源數(shù)據(jù)湖項(xiàng)目為例，結(jié)構(gòu)化、半結(jié)構(gòu)化及非結(jié)構(gòu)化的數(shù)據(jù)通過(guò) SparkSQL/Flink 引擎不斷流轉(zhuǎn)與計(jì)算，再基于 HDFS/S3 實(shí)現(xiàn)事務(wù)存儲(chǔ)，但此類(lèi)方案在性能支持上與 Hadoop 的區(qū)別并不大；

另一類(lèi)則是從新的基礎(chǔ)架構(gòu)發(fā)展出的云原生數(shù)據(jù)倉(cāng)庫(kù)，其中比較典型的代表有 Snowflake、OushuDB 方案，二者均突破了傳統(tǒng) MPP 和 Hadoop 的局限性，實(shí)現(xiàn)了存儲(chǔ)和計(jì)算的完全分離，并且通過(guò)虛擬計(jì)算集群技術(shù)，其單個(gè)集群可以達(dá)到數(shù)萬(wàn)節(jié)點(diǎn)，同時(shí)在復(fù)雜查詢(xún)性能和 SQL 兼容性上也非常完善。在國(guó)外，Snowflake 可以算作落地湖倉(cāng)一體的成功先例之一，而偶數(shù)科技圍繞 OushuDB 提出的湖倉(cāng)一體解決方案，也成為國(guó)內(nèi)該賽道中的一顆耀眼的新星。

若想了解 OushuDB 性能的強(qiáng)大之處，我們大抵可以從以下這組公開(kāi)數(shù)據(jù)中窺知一二：由于 OushuDB 使用了 SIMD（單指令多數(shù)據(jù)流）的執(zhí)行器優(yōu)化策略，其全面性能超過(guò) Spark 性能相差 8 倍以上，最大相差 55 倍。通過(guò)橫向?qū)Ρ葞最?lèi)湖倉(cāng)一體解決方案，我們發(fā)現(xiàn)，在 T+0全實(shí)時(shí)方面，基于 OushuDB 的方案也展現(xiàn)出了較大的優(yōu)勢(shì)。

3 為什么偶數(shù)科技的實(shí)時(shí)湖倉(cāng)性能卓越？

那么問(wèn)題來(lái)了，偶數(shù)科技是如何實(shí)現(xiàn)具備實(shí)時(shí)能力的湖倉(cāng)一體架構(gòu)？我們可以先從 Lambda 以及 Kappa 這兩種典型架構(gòu)的優(yōu)劣說(shuō)起。

為了能夠讓流處理與批處理配合使用，Lambda 架構(gòu)應(yīng)運(yùn)而生，基于這套架構(gòu)，任務(wù)可以根據(jù)是否需要被實(shí)時(shí)處理進(jìn)行分離，然而，這套架構(gòu)背后也隱藏了很多問(wèn)題。首先，離線(xiàn)和實(shí)時(shí)兩套方案會(huì)產(chǎn)生不同的計(jì)算結(jié)果，當(dāng)發(fā)生數(shù)據(jù)產(chǎn)生不一致問(wèn)題時(shí)，對(duì)比排查需要花費(fèi)較長(zhǎng)時(shí)間。此外，由于 Lambda 架構(gòu)由多個(gè)引擎和系統(tǒng)組成，其學(xué)習(xí)成本、運(yùn)維成本也相對(duì)較高。

可見(jiàn)，Lambda 架構(gòu)在開(kāi)發(fā)割裂感、資源重復(fù)、集群維護(hù)成本以及數(shù)據(jù)一致性等問(wèn)題上存在較大的問(wèn)題。為了解決 Lambda 架構(gòu)需要維護(hù)兩套代碼的難題，Kappa 架構(gòu)又出現(xiàn)了，即在 Lambda 架構(gòu)的基礎(chǔ)上移除了批處理層，利用流計(jì)算的分布式特征，加大流數(shù)據(jù)的時(shí)間窗口，統(tǒng)一批處理和流處理，最終處理后的數(shù)據(jù)可以直接給業(yè)務(wù)層使用。相比之下，雖然 Kappa 架構(gòu)的優(yōu)點(diǎn)顯而易見(jiàn)，但其也存在以下兩方面的缺點(diǎn)：

依賴(lài) Kafka 等消息隊(duì)列來(lái)保存所有歷史，而 Kafka 難以實(shí)現(xiàn)數(shù)據(jù)的更新和糾錯(cuò)，發(fā)生故障或者升級(jí)時(shí)需要重做所有歷史，周期較長(zhǎng)；

Kappa 依然是針對(duì)不可變更數(shù)據(jù)，無(wú)法實(shí)時(shí)匯集多個(gè)可變數(shù)據(jù)源形成的數(shù)據(jù)集快照，不適合即席查詢(xún)。

面對(duì) Lambda 架構(gòu)與 Kappa 架構(gòu)的局限性，業(yè)內(nèi)也亟需一種新型技術(shù)架構(gòu)來(lái)滿(mǎn)足企業(yè)的實(shí)時(shí)分析需求。為此，偶數(shù)科技在 2021 年初提出了同時(shí)滿(mǎn)足實(shí)時(shí)流處理、實(shí)時(shí)按需分析以及離線(xiàn)分析的 Omega 架構(gòu)，其是根據(jù)流數(shù)據(jù)處理系統(tǒng)和實(shí)時(shí)數(shù)倉(cāng)構(gòu)成的。

需要強(qiáng)調(diào)的一點(diǎn)是，在 Omega 架構(gòu)中需要變更流處理版本時(shí)，不再需要流處理引擎訪(fǎng)問(wèn) Kafka，直接訪(fǎng)問(wèn) OushuDB 即可獲得所有歷史數(shù)據(jù)，這樣一來(lái)，便規(guī)避了 Kafka 難以實(shí)現(xiàn)數(shù)據(jù)更新和糾錯(cuò)的問(wèn)題，大大提升了數(shù)據(jù)處理的效率。在 Omega 全實(shí)時(shí)架構(gòu)的加持下，偶數(shù)科技實(shí)現(xiàn)了具備實(shí)時(shí)能力的湖倉(cāng)一體，即實(shí)時(shí)湖倉(cāng)。

4 行業(yè)的廣泛認(rèn)可與偶數(shù)的持續(xù)創(chuàng)新

盡管OushuDB只是一個(gè)誕生5年的云數(shù)據(jù)庫(kù)，但OushuDB卻是由國(guó)內(nèi)頂尖工程師自主開(kāi)發(fā)，其研發(fā)團(tuán)隊(duì)曾主導(dǎo)國(guó)際頂級(jí)的數(shù)據(jù)庫(kù)開(kāi)源項(xiàng)目，符合國(guó)家信創(chuàng)標(biāo)準(zhǔn)。偶數(shù)科技作為一家新興的數(shù)據(jù)庫(kù)公司，自2017年誕生以來(lái)，作為微軟加速器和騰訊加速器成員企業(yè)，已經(jīng)獲得世界頂級(jí)投資機(jī)構(gòu)紅杉中國(guó)、騰訊、紅點(diǎn)中國(guó)與金山云的四輪投資，并入選福布斯中國(guó)企業(yè)科技 50 強(qiáng)以及美國(guó)著名商業(yè)雜志《快公司》中國(guó)最佳創(chuàng)新公司 50 強(qiáng)。

除了OushuDB，偶數(shù)科技的實(shí)時(shí)湖倉(cāng)一體解決方案還包含自動(dòng)化機(jī)器學(xué)習(xí)平臺(tái)?LittleBoy 、數(shù)據(jù)分析與應(yīng)用平臺(tái)Kepler以及數(shù)據(jù)管理平臺(tái)?Lava等多個(gè)產(chǎn)品， 深厚的研發(fā)實(shí)力和優(yōu)秀的產(chǎn)品性能吸引了廣泛的知名用戶(hù)群，目前已在金融、電信、制造、公安、能源和互聯(lián)網(wǎng)等行業(yè)得到廣泛的部署和應(yīng)用。