一時間，似乎所有與數(shù)據(jù)庫有關的廠商都在提“湖倉一體”，僅從百度新聞搜索查詢到權重較高的媒體文章就至少有150多篇。隨著企業(yè)數(shù)字化轉型進入深水區(qū)，越來越多的企業(yè)視“湖倉一體”為數(shù)字變革的重要契機，如今湖倉一體受到前所未有的關注。

然而，關注度越高，意味著嘈雜聲也會越多。對“湖倉一體”的錯誤理解，也會將轉型中的企業(yè)引入更加復雜的數(shù)據(jù)孤島局面。對此，偶數(shù)科技向數(shù)據(jù)猿表示，盡管這些錯誤理解最終會得被市場淘汰，但從現(xiàn)實而言，可能會造成企業(yè)成本上升，甚至會錯過數(shù)字化轉型的戰(zhàn)略時機。

作為在數(shù)據(jù)庫領域的領先創(chuàng)業(yè)，偶數(shù)科技獲得紅杉中國、騰訊、紅點中國、金山云等機構的四輪融資，今年3月，偶數(shù)科技又入選了Gartner最新的《數(shù)據(jù)庫市場指南》。

同時，Gartner在上述報告中指出，中國數(shù)據(jù)庫行業(yè)將加速增長并逐步向云端遷移，未來四年中國數(shù)據(jù)庫行業(yè)向公有云遷移的速度將超過全球平均水平。而偶數(shù)科技正是采用了云原生數(shù)倉架構方案，突破傳統(tǒng) MPP 和 Hadoop 的局限性，實現(xiàn)了存算徹底分離，并提出“湖倉一體ANCHOR標準”以及在實時性方面的Omega架構，希望能對數(shù)字化轉型中的企業(yè)有所啟發(fā)。

從湖倉的前世今生說起

最初的數(shù)據(jù)庫既沒有湖，也沒有倉。數(shù)據(jù)庫的起源可以追溯到上世紀六十年代乃至更久，當時，來自美國的查爾斯·巴赫曼（Charles Bachman）設計了第一個計算機化的數(shù)據(jù)庫。緊接著七十年代發(fā)生了數(shù)據(jù)庫歷史上最有影響力的事件，即關系型數(shù)據(jù)庫的誕生。關系型數(shù)據(jù)庫是用行列二維表格結構表示實體及實體之間聯(lián)系的數(shù)據(jù)模型，降低了存儲成本，而且關系型數(shù)據(jù)庫是可搜索的，其中SQL就是基于關系型數(shù)據(jù)庫的結構化查詢語言。

關系型數(shù)據(jù)庫，來源：Wikipedia

計算機軟件的發(fā)展在八九十年代可謂如日中天，雖然企業(yè)源源不斷產(chǎn)生數(shù)據(jù)，但傳統(tǒng)的關系型數(shù)據(jù)庫依然可以滿足企業(yè)的增刪查改，就是通常所說的OLTP（聯(lián)機事務處理）。不過，在日益激烈的市場競爭中，企業(yè)還希望能進行數(shù)據(jù)分析。

1990年，數(shù)據(jù)倉庫之父比爾·恩門（Bill Inmon）率先提出了數(shù)據(jù)倉庫的概念，1991年在其正式出版的專著《建立數(shù)據(jù)倉庫》中指出，企業(yè)需要建立數(shù)據(jù)倉庫用來數(shù)據(jù)分析進而為其決策服務，數(shù)據(jù)倉庫并不是所謂的“大型數(shù)據(jù)庫”，而是強調(diào)其數(shù)據(jù)分析能力，即OLAP，目的是輔助企業(yè)決策。

來源：偶數(shù)科技

隨著數(shù)據(jù)倉庫技術進一步發(fā)展，此時OLTP 數(shù)據(jù)庫又無法有效滿足大量歷史數(shù)據(jù)的存儲、查閱以及數(shù)據(jù)分析的需求，隨即分布式數(shù)據(jù)庫（MPP）誕生了。它是用計算機網(wǎng)絡將物理上分散的多個數(shù)據(jù)庫單元連接起來，組成邏輯上統(tǒng)一的數(shù)據(jù)庫。MPP處理的主要還是結構化數(shù)據(jù)，仍然屬于數(shù)據(jù)倉庫層面。

時間來到2012 年， 當時國內(nèi)技術發(fā)展較快的一些行業(yè)，如電信和頭部銀行，大都完成了數(shù)據(jù)倉庫的建設。與此同時，互聯(lián)網(wǎng)的快速發(fā)展，讓數(shù)據(jù)體量以前所未有的速度增長，非結構化數(shù)據(jù)大量出現(xiàn)，而且企業(yè)對于數(shù)據(jù)處理的實時性和易用性也有了更高的要求。

彼時，企業(yè)開始大規(guī)模使用 Hadoop 分布式的大數(shù)據(jù)計算和存儲方式。在這個體系架構下，Spark Streaming、Flink 讓大數(shù)據(jù)平臺具備了實時處理數(shù)據(jù)能力；HDFS處理海量數(shù)據(jù)的高可用廉價存儲；用MapReduce實現(xiàn)并行計算；Hive則作為Hadoop的數(shù)據(jù)倉庫工具。

Hadoop生態(tài)，來源：Apache Hive Essentials by Dayong Du

Hadoop曾得到了業(yè)界的廣泛認可，大數(shù)據(jù)熱讓人們對Hadoop抱有更高的期待，認為既然 Hadoop 平臺能解決很多數(shù)據(jù)處理和分析問題，自然可以替代傳統(tǒng)的數(shù)據(jù)倉庫。

然而事實并非如此，企業(yè)嘗試使用后發(fā)現(xiàn)Hadoop的性能和并發(fā)支持能力有限。雖然Hadoop 邏輯上實現(xiàn)了計算和存儲分離，但是其物理部署架構依然強調(diào)在每一個節(jié)點同時部署計算和存儲節(jié)點，而且事務支持弱，交付運維成本高，企業(yè)最終意識到基于 Hadoop 終究無法替代核心數(shù)倉。

盡管Hadoop無法替代數(shù)據(jù)倉庫，但還是找到了自身的定位，那就是數(shù)據(jù)湖。

數(shù)據(jù)湖被定義為一種存儲各類格式，包括結構化、半結構化和非結構化數(shù)據(jù)的系統(tǒng)，此時架構師也開始考慮，如何構建一個單一的系統(tǒng)，共同發(fā)揮數(shù)據(jù)湖和數(shù)據(jù)倉庫兩種優(yōu)勢。

此時，“湖倉一體”應運而生。數(shù)據(jù)猿曾撰文指出，“湖倉一體”是構建在數(shù)據(jù)湖低成本的數(shù)據(jù)存儲架構之上，同時繼承了數(shù)據(jù)倉庫的數(shù)據(jù)處理和分析功能。湖倉一體的英文名叫“Lakehouse”，有人把“湖倉一體”做了形象的比喻，就好像湖邊搭建了很多小房子，有的可以負責數(shù)據(jù)分析，有的來運轉機器學習，有的來檢索音視頻等，而這些數(shù)據(jù)源流，都可以從數(shù)據(jù)湖里輕松取得。

來源：艾瑞

根據(jù)沙利文和頭豹研究院的觀點，數(shù)據(jù)湖和數(shù)據(jù)倉庫的邊界正在慢慢模糊，數(shù)據(jù)湖自身的治理能力、數(shù)據(jù)倉庫延伸到外部存儲的能力都在加強，湖倉一體的出現(xiàn)讓數(shù)據(jù)管理的靈活性與成長性得到了統(tǒng)一。

來源：沙利文、頭豹研究院

為什么大多數(shù)“湖倉一體”都做不到真正的一體？

現(xiàn)在，業(yè)內(nèi)對于“湖倉一體”的解決方案大致可以分為兩大類：基于Hadoop的改造方案，如Hudi、Iceberg、Delta Lake方案；基于新一代云原生數(shù)據(jù)倉庫架構的方案，如Snowflake、偶數(shù)科技的OushuDB 方案。不過這些都是真正的“湖倉一體”嗎？

據(jù)偶數(shù)科技的調(diào)查發(fā)現(xiàn)，由于數(shù)據(jù)湖始終無法滿足用戶在性能、事務等方面的要求，所以很多廠商的變通做法是，先讓所有的數(shù)據(jù)入湖，便于自由靈活的數(shù)據(jù)分析和探索，在某個分析逐步成熟時，將其轉移到數(shù)據(jù)倉庫，這樣就形成了數(shù)據(jù)湖和數(shù)據(jù)倉庫互補的方式。

湖與倉相互協(xié)作的前提是各自的技術都相對穩(wěn)定成熟，時下這方面并不是問題。既有 Greenplum、Vertica、GaussDB等MPP 數(shù)據(jù)倉庫，也有 Cloudera、AWS、阿里云、騰訊云等廠商主要基于Hadoop的數(shù)據(jù)湖解決方案。企業(yè)在構建數(shù)據(jù)湖的同時，也使用 MPP，最后形成Hadoop+MPP模式。

在這種模式下，湖是湖，倉是倉，湖倉各自獨立部署， 數(shù)據(jù)通過 ETL 的方式打通，現(xiàn)在很大一部分“湖倉一體”實際是 “湖倉分體”的模式。

“數(shù)據(jù)湖 + 數(shù)據(jù)倉庫”互補，湖倉分體模式，來源：偶數(shù)科技

“湖倉分體”雖然很想達到“湖倉一體”的結果，但還不是真正的“湖倉一體”。Gartner 認為，湖倉一體是將數(shù)據(jù)湖的靈活性和數(shù)倉的易用性、規(guī)范性、高性能結合起來的融合架構，無數(shù)據(jù)孤島。

而事實上，“湖倉分體”的數(shù)據(jù)多集群冗余存儲、集群規(guī)模受限、高并發(fā)受限均會產(chǎn)生數(shù)據(jù)孤島，然后在疏解數(shù)據(jù)孤島的過程中，又催生了一系列復雜的實施和運維問題，如ETL邏輯復雜、數(shù)據(jù)變更困難、數(shù)據(jù)不一致、數(shù)據(jù)治理困難等。

此外，傳統(tǒng)的MPP和Hadoop都不適應云平臺的要求。MPP 數(shù)據(jù)庫存算耦合，而 Hadoop不得不通過計算和存儲部署在同一物理集群，拉近計算與數(shù)據(jù)的距離，僅在同一集群下構成存算分離。而基于Hadoop改造方案僅從事務特性出發(fā)做優(yōu)化，如Iceberg和Hudi等基于HDFS或S3實現(xiàn)一個支持事務的存儲層，其他方面與Hadoop區(qū)別不大。

偶數(shù)科技建立起湖倉一體的ANCHOR判斷標準

既然并不是所有的“湖”與“倉”都是一體的，偶數(shù)科技表示，那就可以建立一種標準，讓企業(yè)客戶能夠迅速分辨出更適合他們的“湖倉一體”。

正如搜索引擎的“新快全準”，數(shù)據(jù)庫事務的“ACID”，偶數(shù)科技采用英語“ANCHOR”六個首字母來界定湖倉一體的標準， 即代表了“湖倉一體”的六大特性。ANCHOR 中文譯為錨點、頂梁柱，偶數(shù)科技希望這套標準能夠湖倉一體浪潮下的定海神針。

來源：偶數(shù)科技

滿足 ANCHOR 定義的湖倉一體在哪些方面會為企業(yè)帶來價值？偶數(shù)科技概括為以下六個方面：

第一，實時 T+0 （Real-Time）：通過全量數(shù)據(jù)T+0的流處理和實時按需查詢， 滿足基于數(shù)據(jù)的事前預測、事中判斷和事后分析。

具備實時能力的湖倉一體架構，需要同時滿足實時流處理、實時分析、離線分析三種需求。實時數(shù)據(jù)服務應包括通過系統(tǒng)日志點查方式得到的“直接特征”，如點擊、瀏覽、下載、支付；還有更具應用價值的“衍生特征”，如某一產(chǎn)品 5 分鐘的點擊量，某一用戶 30 天內(nèi)查詢征信報告的次數(shù)等。

第二，一份數(shù)據(jù)（One Copy of Data）：所有用戶（BI 用戶、數(shù)據(jù)科學家等）應該共享同一份數(shù)據(jù)， 避免數(shù)據(jù)孤島。

在多數(shù)湖倉分體架構中，不同用戶使用各自的副本并更新，這樣引發(fā)了數(shù)據(jù)冗余存儲及數(shù)據(jù)更新導致數(shù)據(jù)不一致等問題。ANCHOR 標準保障所有用戶可以共享同一份數(shù)據(jù)，避免數(shù)據(jù)孤島。

第三，超高并發(fā)（High Concurrency）：支持數(shù)十萬用戶使用復雜分析查詢并發(fā)訪問同一份數(shù)據(jù)。

一個涉及海量的復雜查詢可能會影響整個系統(tǒng)的性能，當分析型的 MPP 或者 Hadoop 進行復雜查詢達到幾十萬并發(fā)的時候，其吞吐量就會下降。ANCHOR要求的超高并發(fā)在新技術的迭代中成為可能，進而支持百萬用戶同時在線查詢分析。

第四，數(shù)據(jù)一致性（Consistency）：通過支持完善的事務機制， 保障不同用戶同時查詢和更新同一份數(shù)據(jù)時的一致性。

在企業(yè)，多用戶同時運行時，ANCHOR要求保證數(shù)據(jù)的一致性；另外，要保證在事務中的數(shù)據(jù)一致性，即同一事務中所有數(shù)據(jù)操作應是不可分割的，要么都執(zhí)行，要么都不執(zhí)行，不允許出現(xiàn)中間狀態(tài)的數(shù)據(jù)。

第五，云原生（Native on Cloud）：適合云環(huán)境，自由增減計算和存儲資源，按用量計費， 節(jié)約成本。

第六，支持多類型數(shù)據(jù)（All Data Types, Structured & Unstructured）：支持關系表、文本、圖像、視頻等結構化數(shù)據(jù)和非結構化數(shù)據(jù)存儲。

從以上六要素來看，我們發(fā)現(xiàn)并非所有湖倉一體的方案都能完全滿足ANCHOR，尤其在T+0 實時特性方面差距很大。目前大多數(shù)方案都是基于T+1 設計的，面對T+0實時的按需分析，即便引入流處理引擎實現(xiàn)部分固定模式的實時分析，仍無法達到T+0 全實時水平。

面向全實時湖倉一體，偶數(shù)科技有自己獨特的解決策略

值得一提的是，隨著公有云和私有云的普及，讓一切軟件上云成為當今趨勢，為了保證存儲和計算可以獨立的彈性擴展和伸縮，Snowflake橫空出世，數(shù)據(jù)平臺的設計出現(xiàn)了嶄新的架構，即存算分離架構。從新的基礎架構發(fā)展出云原生數(shù)據(jù)倉庫，其存算分離特性更具有技術前瞻性，成為實現(xiàn)湖倉一體的關鍵技術，該架構將是未來的發(fā)展趨勢。

在新一代的云原生數(shù)倉架構方案中，突破傳統(tǒng)MPP和Hadoop的局限性，實現(xiàn)了存算徹底分離，計算和存儲可部署在不同的物理集群中，在存儲層支持AWS S3、Azure Blob、Google Cloud等多個云服務商，計算層則從存儲層獲取數(shù)據(jù)并將其緩存在本地以備未來的查詢，運行查詢語句調(diào)取數(shù)據(jù)后，用戶還可用SQL像使用數(shù)據(jù)倉庫一樣進行數(shù)據(jù)分析。

偶數(shù)科技的OushuDB同屬于新一代湖倉一體架構，通過虛擬計算集群技術在數(shù)十萬節(jié)點的超大規(guī)模集群上實現(xiàn)了高并發(fā)，保障事務支持，提供實時能力，一份數(shù)據(jù)再無數(shù)據(jù)孤島。

來源：偶數(shù)科技

在新一代湖倉一體的架構下，數(shù)字化轉型的業(yè)務需求和技術難點能得到更多關注和解決。隨著線上業(yè)務的迅猛發(fā)展，“實時性”是其中尤為重要的需求，而大多數(shù)湖倉分體卻無法達到 T+0 全實時水平。

Gartner對“實時性”給出了明確的刻畫：以一個事件發(fā)生的前后作為時間軸，可以將時間線分為三個階段， 分別是事件發(fā)生的同時、事件發(fā)生后短時間內(nèi)、事件發(fā)生后較長時間，對應的實時要求分別是實時流處理、實時按需分析、離線分析。

實時分析處理三大場景，來源：Gartner

以一次銀行轉賬為例，交易發(fā)生的同時要進行交易反欺詐檢測，通過實時流處理系統(tǒng)將本次交易的時間、金額、位置等要素提供給反欺詐應用系統(tǒng)；該筆交易結束后，需要立即反映到實時報表和統(tǒng)計分析中，同時用戶也會按照特定需求查詢到該筆交易，由于實時報表和實時統(tǒng)計分析需求千變?nèi)f化，流處理系統(tǒng)難以滿足，所以需要實時按需分析；另外，這筆交易發(fā)生后也可能被用來進行報表統(tǒng)計、數(shù)據(jù)挖掘和機器學習，因此離線分析也是基本需求之一。

目前， 實時處理有兩種典型架構：Lambda 和 Kappa 架構。Lambda架構在批處理層對離線數(shù)據(jù)進行預處理并存儲，流處理層專注實時數(shù)據(jù)，其問題在于，數(shù)據(jù)在不同的視圖中存儲多份，浪費存儲空間，數(shù)據(jù)一致性的問題亦難以解決；Kappa 架構在Lambda架構的基礎上移除了批處理層，批流一體處理所有歷史數(shù)據(jù)和當前數(shù)據(jù)，可以直接給業(yè)務層使用，其局限在于Kafka 難以實現(xiàn)數(shù)據(jù)的更新和糾錯，發(fā)生故障或者升級時需要重做所有歷史。

由此來看，兩個架構都難以處理可變更數(shù)據(jù)（如關系數(shù)據(jù)庫中不停變化的實時數(shù)據(jù)），那么自然需要一種新的架構來滿足企業(yè)實時分析的全部需求。

2021年初，偶數(shù)科技推出Omega全實時架構。

Omega架構是由流數(shù)據(jù)處理系統(tǒng)和實時數(shù)倉構成。相比Lambda 和 Kappa，Omega架構新引入了“實時數(shù)倉”和“快照視圖”的概念。實時查詢可以通過存儲于實時數(shù)倉的快照視圖得以實現(xiàn)，而且任意時間點的歷史數(shù)據(jù)都可以通過T+0快速得到，這樣無論實時查詢還是離線查詢都可以在實時數(shù)倉中完成。

流處理系統(tǒng)WASP既可以實現(xiàn)實時連續(xù)的流處理，也可以實現(xiàn)Kappa 架構中的批流一體，但與之不同之處在于，OushuDB由實時數(shù)倉存儲來自Kafka的全部歷史數(shù)據(jù)，而在Kappa架構中源端采集后通常存儲在 Kafka中。當需要流處理版本變更的時候，訪問實時數(shù)倉即可，規(guī)避了Kafka難以實現(xiàn)數(shù)據(jù)更新和糾錯的問題，大幅提高了效率。此外，整個服務層可以在實時數(shù)倉中實現(xiàn)，無需引入外部組件，至此，偶數(shù)科技實現(xiàn)了全實時 Omega 架構的湖倉一體，即實時湖倉一體。

Omega vs. Lambda vs. Kappa，來源：偶數(shù)科技

據(jù)了解，早在2020年建設銀行就與偶數(shù)科技成立了高性能大數(shù)據(jù)聯(lián)合實驗室，合作開發(fā)基于云原生數(shù)據(jù)庫技術的全實時湖倉一體方案，該方案已在建行及其客戶的實時場景下得到了驗證。

總結來看，通過理清歷史發(fā)展的脈絡，我們理解了湖倉一體是數(shù)據(jù)庫發(fā)展到云原生時代的必然產(chǎn)物，也了解到有些“湖倉一體”不但沒有從數(shù)據(jù)平臺層面消除數(shù)據(jù)孤島，反而催生了更為復雜的架構。為幫助有需求的企業(yè)更好地做出判斷，偶數(shù)科技對湖倉一體率先創(chuàng)建了ANCHOR標準，并針對其中“實時性”方面提出了可被驗證的Omega 架構。

誠然，每個新概念的誕生都離不開業(yè)務場景和技術的雙重驅(qū)動，在概念落地時，難免會出現(xiàn)一些認知上的偏差和技術上的彎路。湖倉一體也才剛剛走過一年多的時間，包括偶數(shù)科技在內(nèi)的探索者不斷嘗試和試錯正在推動市場形成共識，如同1970年代關系型數(shù)據(jù)庫和1990年數(shù)據(jù)倉庫的理念，每次微小的突破，都能掀起后續(xù)的波瀾，這也是讓科技創(chuàng)新者不斷前進的動力所在。

來源：數(shù)據(jù)猿