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

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

作為在資料庫領域的領先創業，偶數科技獲得紅杉中國、騰訊、紅點中國、金山雲等機構的四輪融資，今年3月，偶數科技又入選了Gartner最新的《資料庫市場指南》。

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

從湖倉的前世今生說起

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

關係型資料庫，來源：Wikipedia

計算機軟體的發展在八九十年代可謂如日中天，雖然企業源源不斷產生資料，但傳統的關係型資料庫依然可以滿足企業的增刪查改，就是通常所說的OLTP（聯機事務處理）。不過，在日益激烈的市場競爭中，企業還希望能進行資料分析。

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

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

時間來到2012 年， 當時國內技術發展較快的一些行業，如電信和頭部銀行，大都完成了資料倉庫的建設。與此同時，網際網路的快速發展，讓資料體量以前所未有的速度增長，非結構化資料大量出現，而且企業對於資料處理的實時性和易用性也有了更高的要求。

彼時，企業開始大規模使用 Hadoop 分散式的大資料計算和儲存方式。在這個體系架構下，Spark Streaming、Flink 讓大資料平臺具備了實時處理資料能力；HDFS處理海量資料的高可用廉價儲存；用MapReduce實現平行計算；Hive則作為Hadoop的資料倉庫工具。

Hadoop生態，來源：Apache Hive Essentials by Dayong Du

Hadoop曾得到了業界的廣泛認可，大資料熱讓人們對Hadoop抱有更高的期待，認為既然 Hadoop 平臺能解決很多資料處理和分析問題，自然可以替代傳統的資料倉庫。

然而事實並非如此，企業嘗試使用後發現Hadoop的效能和併發支援能力有限。雖然Hadoop 邏輯上實現了計算和儲存分離，但是其物理部署架構依然強調在每一個節點同時部署計算和儲存節點，而且事務支援弱，交付運維成本高，企業最終意識到基於 Hadoop 終究無法替代核心數倉。

儘管Hadoop無法替代資料倉庫，但還是找到了自身的定位，那就是資料湖。

資料湖被定義為一種儲存各類格式，包括結構化、半結構化和非結構化資料的系統，此時架構師也開始考慮，如何構建一個單一的系統，共同發揮資料湖和資料倉庫兩種優勢。

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

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

為什麼大多數“湖倉一體”都做不到真正的一體？

現在，業內對於“湖倉一體”的解決方案大致可以分為兩大類：基於Hadoop的改造方案，如Hudi、Iceberg、Delta Lake方案；基於新一代雲原生資料倉庫架構的方案，如Snowflake、偶數科技的OushuDB 方案。不過這些都是真正的“湖倉一體”嗎？

據偶數科技的調查發現，由於資料湖始終無法滿足使用者在效能、事務等方面的要求，所以很多廠商的變通做法是，先讓所有的資料入湖，便於自由靈活的資料分析和探索，在某個分析逐步成熟時，將其轉移到資料倉庫，這樣就形成了資料湖和資料倉庫互補的方式。

湖與倉相互協作的前提是各自的技術都相對穩定成熟，時下這方面並不是問題。既有 Greenplum、Vertica、GaussDB等MPP 資料倉庫，也有 Cloudera、AWS、阿里雲、騰訊雲等廠商主要基於Hadoop的資料湖解決方案。企業在構建資料湖的同時，也使用 MPP，最後形成Hadoop+MPP模式。

在這種模式下，湖是湖，倉是倉，湖倉各自獨立部署， 資料透過 ETL 的方式打通，現在很大一部分“湖倉一體”實際是 “湖倉分體”的模式。

“資料湖 + 資料倉庫”互補，湖倉分體模式，來源：偶數科技

“湖倉分體”雖然很想達到“湖倉一體”的結果，但還不是真正的“湖倉一體”。Gartner 認為，湖倉一體是將資料湖的靈活性和數倉的易用性、規範性、高效能結合起來的融合架構，無資料孤島。

而事實上，“湖倉分體”的資料多叢集冗餘儲存、叢集規模受限、高併發受限均會產生資料孤島，然後在疏解資料孤島的過程中，又催生了一系列複雜的實施和運維問題，如ETL邏輯複雜、資料變更困難、資料不一致、資料治理困難等。

此外，傳統的MPP和Hadoop都不適應雲平臺的要求。MPP 資料庫存算耦合，而 Hadoop不得不透過計算和儲存部署在同一物理叢集，拉近計算與資料的距離，僅在同一叢集下構成存算分離。而基於Hadoop改造方案僅從事務特性出發做最佳化，如Iceberg和Hudi等基於HDFS或S3實現一個支援事務的儲存層，其他方面與Hadoop區別不大。

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

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

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

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

第一，實時 T+0 （Real-Time）：透過全量資料T+0的流處理和實時按需查詢， 滿足基於資料的事前預測、事中判斷和事後分析。

具備實時能力的湖倉一體架構，需要同時滿足實時流處理、實時分析、離線分析三種需求。實時資料服務應包括透過系統日誌點查方式得到的“直接特徵”，如點選、瀏覽、下載、支付；還有更具應用價值的“衍生特徵”，如某一產品 5 分鐘的點選量，某一使用者 30 天內查詢徵信報告的次數等。

第二，一份資料（One Copy of Data）：所有使用者（BI 使用者、資料科學家等）應該共享同一份資料， 避免資料孤島。

在多數湖倉分體架構中，不同使用者使用各自的副本並更新，這樣引發了資料冗餘儲存及資料更新導致資料不一致等問題。ANCHOR 標準保障所有使用者可以共享同一份資料，避免資料孤島。

第三，超高併發（High Concurrency）：支援數十萬使用者使用複雜分析查詢併發訪問同一份資料。

一個涉及海量的複雜查詢可能會影響整個系統的效能，當分析型的 MPP 或者 Hadoop 進行復雜查詢達到幾十萬併發的時候，其吞吐量就會下降。ANCHOR要求的超高併發在新技術的迭代中成為可能，進而支援百萬使用者同時線上查詢分析。

第四，資料一致性（Consistency）：透過支援完善的事務機制， 保障不同使用者同時查詢和更新同一份資料時的一致性。

在企業，多使用者同時執行時，ANCHOR要求保證資料的一致性；另外，要保證在事務中的資料一致性，即同一事務中所有資料操作應是不可分割的，要麼都執行，要麼都不執行，不允許出現中間狀態的資料。

第五，雲原生（Native on Cloud）：適合雲環境，自由增減計算和儲存資源，按用量計費， 節約成本。

第六，支援多型別資料（All Data Types， Structured & Unstructured）：支援關係表、文字、影象、影片等結構化資料和非結構化資料儲存。

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

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

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

在新一代的雲原生數倉架構方案中，突破傳統MPP和Hadoop的侷限性，實現了存算徹底分離，計算和儲存可部署在不同的物理叢集中，在儲存層支援AWS S3、Azure Blob、Google Cloud等多個雲服務商，計算層則從儲存層獲取資料並將其快取在本地以備未來的查詢，執行查詢語句調取資料後，使用者還可用SQL像使用資料倉庫一樣進行資料分析。

偶數科技的OushuDB同屬於新一代湖倉一體架構，透過虛擬計算叢集技術在數十萬節點的超大規模叢集上實現了高併發，保障事務支援，提供實時能力，一份資料再無資料孤島。

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

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

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

以一次銀行轉賬為例，交易發生的同時要進行交易反欺詐檢測，透過實時流處理系統將本次交易的時間、金額、位置等要素提供給反欺詐應用系統；該筆交易結束後，需要立即反映到實時報表和統計分析中，同時使用者也會按照特定需求查詢到該筆交易，由於實時報表和實時統計分析需求千變萬化，流處理系統難以滿足，所以需要實時按需分析；另外，這筆交易發生後也可能被用來進行報表統計、資料探勘和機器學習，因此離線分析也是基本需求之一。

目前， 實時處理有兩種典型架構：Lambda 和 Kappa 架構。Lambda架構在批處理層對離線資料進行預處理並存儲，流處理層專注實時資料，其問題在於，資料在不同的檢視中儲存多份，浪費儲存空間，資料一致性的問題亦難以解決；Kappa 架構在Lambda架構的基礎上移除了批處理層，批流一體處理所有歷史資料和當前資料，可以直接給業務層使用，其侷限在於Kafka 難以實現資料的更新和糾錯，發生故障或者升級時需要重做所有歷史。

由此來看，兩個架構都難以處理可變更資料（如關係資料庫中不停變化的實時資料），那麼自然需要一種新的架構來滿足企業實時分析的全部需求。

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

Omega架構是由流資料處理系統和實時數倉構成。相比Lambda 和 Kappa，Omega架構新引入了“實時數倉”和“快照檢視”的概念。實時查詢可以透過儲存於實時數倉的快照檢視得以實現，而且任意時間點的歷史資料都可以透過T+0快速得到，這樣無論實時查詢還是離線查詢都可以在實時數倉中完成。

流處理系統WASP既可以實現實時連續的流處理，也可以實現Kappa 架構中的批流一體，但與之不同之處在於，OushuDB由實時數倉儲存來自Kafka的全部歷史資料，而在Kappa架構中源端採集後通常儲存在 Kafka中。當需要流處理版本變更的時候，訪問實時數倉即可，規避了Kafka難以實現資料更新和糾錯的問題，大幅提高了效率。此外，整個服務層可以在實時數倉中實現，無需引入外部元件，至此，偶數科技實現了全實時 Omega 架構的湖倉一體，即實時湖倉一體。

Omega vs。 Lambda vs。 Kappa，來源：偶數科技

據瞭解，早在2020年建設銀行就與偶數科技成立了高效能大資料聯合實驗室，合作開發基於雲原生資料庫技術的全實時湖倉一體方案，該方案已在建行及其客戶的實時場景下得到了驗證。

總結來看，透過理清歷史發展的脈絡，我們理解了湖倉一體是資料庫發展到雲原生時代的必然產物，也瞭解到有些“湖倉一體”不但沒有從資料平臺層面消除資料孤島，反而催生了更為複雜的架構。為幫助有需求的企業更好地做出判斷，偶數科技對湖倉一體率先建立了ANCHOR標準，並針對其中“實時性”方面提出了可被驗證的Omega 架構。

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

文：陸易斯 / 資料猿