在愈發(fā)復雜的大數(shù)據(jù)場景下，數(shù)據(jù)倉庫與數(shù)據(jù)湖各自的弊端開始顯現(xiàn)，湖倉一體架構走向舞臺中央。在國外有兩種流行的實現(xiàn)數(shù)據(jù)湖倉的技術，他們分別是基于數(shù)據(jù)倉庫和基于數(shù)據(jù)湖的解決方案，他們的代表分別是Snowflake和Databricks。 去年11月，雙方曾就兩者性能差異吵得不可開交，作為大數(shù)據(jù)分析賽道的代表性廠商，不論是具備數(shù)據(jù)倉庫功能的數(shù)據(jù)湖工具Databricks，還是借鑒數(shù)據(jù)湖范式的可擴展數(shù)據(jù)倉庫Snowflakes，其發(fā)展路線都說明“湖倉一體化”已成為了目前市場主流的技術發(fā)展方向。
雖然業(yè)界對于湖倉一體的價值是高度認同的，但作為一種新興的架構，大多數(shù)公司對于湖倉一體仍處在初期的探索階段，有些企業(yè)甚至對于要選擇怎樣的湖倉一體架構仍舊是云里霧里。很多人難免會問，我們到底需要什么樣的湖倉一體?
1 當下企業(yè)實時性數(shù)據(jù)分析需求暴增
隨著網(wǎng)絡的高速發(fā)展，產(chǎn)生的數(shù)據(jù)也爆炸性增長，企業(yè)對數(shù)據(jù)的使用也逐步從離線場景到實時數(shù)據(jù)分析場景的轉(zhuǎn)變。剛開始，很多企業(yè)主要是利用離線場景對歷史數(shù)據(jù)進行分析，而隨著業(yè)務發(fā)展到一定規(guī)模以后，離線數(shù)據(jù)的缺點就愈發(fā)凸顯，公司的業(yè)務方、決策方對實時化數(shù)據(jù)提出了更高的訴求，希望從業(yè)務端獲取到數(shù)據(jù)以后，便能夠立即被清洗處理，從而滿足基于數(shù)據(jù)的事前預測、事中判斷和事后分析。
實時數(shù)據(jù)分析的需求場景一般分為四個層面：
運營層面：實時業(yè)務變化、實時營銷效果、當日業(yè)務趨勢分析;
用戶層面：搜索推薦排序、實時行為等特征變量的生產(chǎn)，為用戶推薦更精準的內(nèi)容;
風控層面：實時風險識別、反欺詐、異常交易等;
生產(chǎn)層面：實時監(jiān)控系統(tǒng)的穩(wěn)定性和健康狀況等。
不難發(fā)現(xiàn)，無論是互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)企業(yè)，數(shù)據(jù)的時效性都被擺在了重要位置，甚至有些企業(yè)已經(jīng)從 PV、UV 指標等單點實時化進階到了全面實時化的階段。也正于因此，數(shù)據(jù)的時效性也就成為了企業(yè)判斷自身架構設計是否滿足真正湖倉一體的關鍵因素。
總體來看，企業(yè)到底需要怎樣的湖倉一體架構?除了要滿足實時化數(shù)據(jù)需求這一關鍵要素以外，數(shù)據(jù)一致性、超高并發(fā)、云原生、支持多類型數(shù)據(jù)以及一份數(shù)據(jù)也被列入了湖倉一體的 ANCHOR 六大特征。
2 基于OushuDB的云原生湖倉一體
如前文所言，隨著市場競爭和用戶需求的不斷變幻，企業(yè)對于數(shù)據(jù)的時效性需求不斷攀升，但實時數(shù)據(jù)的分析場景出現(xiàn)以后，也給數(shù)據(jù)技術的實現(xiàn)帶來了很大的挑戰(zhàn)。目前，無論是擅長事務型工作的數(shù)據(jù)倉庫，還是數(shù)據(jù)類型更為豐富的數(shù)據(jù)湖，亦或是 Hadoop+MPP 模式下的湖倉分體，其都是基于 T+1 設計的，即便引入了流處理引擎實現(xiàn)了部分固定模式的實時分析，仍無法達到 T+0 全實時的水平。
為了讓數(shù)據(jù)實現(xiàn)全面實時化，行業(yè)內(nèi)也衍生出了不同的湖倉一體方案，可以將其大致分為兩類：一類是基于 Hadoop 的改造方案，拿 Hudi、Iceberg 兩款開源數(shù)據(jù)湖項目為例，結構化、半結構化及非結構化的數(shù)據(jù)通過 SparkSQL/Flink 引擎不斷流轉(zhuǎn)與計算，再基于 HDFS/S3 實現(xiàn)事務存儲，但此類方案在性能支持上與 Hadoop 的區(qū)別并不大;
另一類則是從新的基礎架構發(fā)展出的云原生數(shù)據(jù)倉庫，其中比較典型的代表有 Snowflake、OushuDB 方案，二者均突破了傳統(tǒng) MPP 和 Hadoop 的局限性，實現(xiàn)了存儲和計算的完全分離，并且通過虛擬計算集群技術，其單個集群可以達到數(shù)萬節(jié)點，同時在復雜查詢性能和 SQL 兼容性上也非常完善。在國外，Snowflake 可以算作落地湖倉一體的成功先例之一，而偶數(shù)科技圍繞 OushuDB 提出的湖倉一體解決方案，也成為國內(nèi)該賽道中的一顆耀眼的新星。
若想了解 OushuDB性能的強大之處，我們大抵可以從以下這組公開數(shù)據(jù)中窺知一二：由于 OushuDB 使用了 SIMD(單指令多數(shù)據(jù)流)的執(zhí)行器優(yōu)化策略，其全面性能超過 Spark性能相差 8 倍以上，最大相差 55 倍。通過橫向?qū)Ρ葞最惡}一體解決方案，我們發(fā)現(xiàn)，在 T+0全實時方面，基于 OushuDB 的方案也展現(xiàn)出了較大的優(yōu)勢。
3 為什么偶數(shù)科技的實時湖倉性能卓越？
那么問題來了，偶數(shù)科技是如何實現(xiàn)具備實時能力的湖倉一體架構?我們可以先從 Lambda 以及 Kappa 這兩種典型架構的優(yōu)劣說起。
為了能夠讓流處理與批處理配合使用，Lambda 架構應運而生，基于這套架構，任務可以根據(jù)是否需要被實時處理進行分離，然而，這套架構背后也隱藏了很多問題。首先，離線和實時兩套方案會產(chǎn)生不同的計算結果，當發(fā)生數(shù)據(jù)產(chǎn)生不一致問題時，對比排查需要花費較長時間。此外，由于 Lambda 架構由多個引擎和系統(tǒng)組成，其學習成本、運維成本也相對較高。
可見，Lambda 架構在開發(fā)割裂感、資源重復、集群維護成本以及數(shù)據(jù)一致性等問題上存在較大的問題。為了解決 Lambda 架構需要維護兩套代碼的難題，Kappa 架構又出現(xiàn)了，即在 Lambda 架構的基礎上移除了批處理層，利用流計算的分布式特征，加大流數(shù)據(jù)的時間窗口，統(tǒng)一批處理和流處理，最終處理后的數(shù)據(jù)可以直接給業(yè)務層使用。相比之下，雖然 Kappa 架構的優(yōu)點顯而易見，但其也存在以下兩方面的缺點：
依賴 Kafka 等消息隊列來保存所有歷史，而 Kafka 難以實現(xiàn)數(shù)據(jù)的更新和糾錯，發(fā)生故障或者升級時需要重做所有歷史，周期較長;
Kappa 依然是針對不可變更數(shù)據(jù)，無法實時匯集多個可變數(shù)據(jù)源形成的數(shù)據(jù)集快照，不適合即席查詢。
面對 Lambda 架構與 Kappa 架構的局限性，業(yè)內(nèi)也亟需一種新型技術架構來滿足企業(yè)的實時分析需求。為此，偶數(shù)科技在 2021 年初提出了同時滿足實時流處理、實時按需分析以及離線分析的 Omega 架構，其是根據(jù)流數(shù)據(jù)處理系統(tǒng)和實時數(shù)倉構成的。
需要強調(diào)的一點是，在 Omega 架構中需要變更流處理版本時，不再需要流處理引擎訪問 Kafka，直接訪問 OushuDB 即可獲得所有歷史數(shù)據(jù)，這樣一來，便規(guī)避了 Kafka 難以實現(xiàn)數(shù)據(jù)更新和糾錯的問題，大大提升了數(shù)據(jù)處理的效率。在 Omega 全實時架構的加持下，偶數(shù)科技實現(xiàn)了具備實時能力的湖倉一體，即實時湖倉。
4 行業(yè)的廣泛認可與偶數(shù)的持續(xù)創(chuàng)新
盡管OushuDB只是一個誕生5年的云數(shù)據(jù)庫，但OushuDB卻是由國內(nèi)頂尖工程師自主開發(fā)，其研發(fā)團隊曾主導國際頂級的數(shù)據(jù)庫開源項目，符合國家信創(chuàng)標準。偶數(shù)科技作為一家新興的數(shù)據(jù)庫公司，自2017年誕生以來，作為微軟加速器和騰訊加速器成員企業(yè)，已經(jīng)獲得世界頂級投資機構紅杉中國、騰訊、紅點中國與金山云的四輪投資，并入選福布斯中國企業(yè)科技 50 強以及美國著名商業(yè)雜志《快公司》中國最佳創(chuàng)新公司 50 強。
除了OushuDB，偶數(shù)科技的實時湖倉一體解決方案還包含自動化機器學習平臺LittleBoy 、數(shù)據(jù)分析與應用平臺Kepler以及數(shù)據(jù)管理平臺Lava等多個產(chǎn)品， 深厚的研發(fā)實力和優(yōu)秀的產(chǎn)品性能吸引了廣泛的知名用戶群，目前已在金融、電信、制造、公安、能源和互聯(lián)網(wǎng)等行業(yè)得到廣泛的部署和應用。
（本內(nèi)容屬于網(wǎng)絡轉(zhuǎn)載，文中涉及圖片等內(nèi)容如有侵權，請聯(lián)系編輯刪除。市場有風險，選擇需謹慎！此文僅供參考，不作買賣及投資依據(jù)。）
原創(chuàng)文章，作者：陳晨，如若轉(zhuǎn)載，請注明出處：http://m.2079x.cn/article/559815.html
