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