之前寫了數據倉庫和數據湖：

今天是大數據專題的最后一篇，來講講數據湖倉。

█ 為什么會有“數據湖倉”？

前面我們提到，數據倉庫出現于1990年代，主要基于MPP（Massively Parallel Processing，大規模并行處理）或者關系型數據庫實現，用于企業做數據存儲、處理和分析，發展數據看板、BI（商業智能）等用途。

而數據湖，出現于2010年代，主要基于大數據技術（Hadoop等）生態，用于支撐多樣化的數據存儲，實時性更強，適合滿足批處理、流式計算等業務場景。

數據倉庫的特點是，先做數據處理，搞得規范整齊之后，存起來。用的時候就直接用。它主要存的是結構化（行列）數據。

數據湖的特點是，什么數據（結構化、非結構化、半結構化）都能存，不做預處理，先全部都存起來，等要用的時候，再處理。

兩種技術，各有優缺點：

從成本的角度來看，數據湖的起步成本很低，但隨著數據體量的增大，成本會迅速飆升。而數據倉庫恰好相反，前期建設開支很大，后期成本增加趨緩。

數據倉庫和數據湖，都是基于數據進行價值挖掘，只是側重點不同。對于企業來說，兩者都有價值，所以，會選擇同時建設。

很顯然，這不僅導致了高昂的建設投資成本，也使得數據存在冗余和重復。

基于以上種種原因，業界就開始思考：是不是可以將數據倉庫和數據湖進行結合，充分發揮兩者的優勢，彌補各自的缺陷呢？

于是，就有一些服務商，開始研究如何將兩者的能力進行“打通”。

主要思路包括兩種：一種是讓數據倉庫支持對數據湖的訪問。還有一種，是讓數據湖具備數據倉庫的一些能力。

前者比較有代表性的，是2017年Redshift推出的Redshift Spectrum。它支持Redsift數據倉庫用戶訪問AWS S3數據湖的數據。

后者有代表性的比較多，包括2017年Hortonworks孵化出的Apache Atlas和Ranger項目，2018年Nexflix開源的內部增強版本元數據服務系統Iceberg。2018-2019年，Uber和Databricks相繼推出了Apache Hudi和DeltaLake，推出增量文件格式，用以支持Update/Insert、事務等數據倉庫功能。

所有這些嘗試和努力，都多多少少存在一些缺陷（數據倉庫和數據湖存在本質的區別，整合難度很大），并不算成功。

2020年，數據智能獨角獸企業Databricks（沒錯，就是提出Delta Lake的那個公司，數據湖的代表企業）正式提出了數據湖倉（Data Lakehouse）概念。

Databricks聯合創始人兼首席執行官阿里·戈德西（Ali Ghodsi）表示：

“從長遠來看，所有數據倉庫都將被納入數據湖倉，這不會在一夜之間發生——這些東西會共存一段時間——在價格和性能上，數據湖倉完勝數據倉庫。”

數據湖倉，也被稱為湖倉一體。

2021年，“湖倉一體”首次被寫入Gartner數據管理領域成熟度報告。2023年6月，大數據技術標準推進委員會發布了《湖倉一體技術與產業研究報告（2023年）》。這一年的6月26日，“湖倉一體”在中國大數據產業發展大會上成功入選“2023大數據十大關鍵詞”。

█數據湖倉的主要特點

數據湖倉（湖倉一體），說白了，就是一種將數據倉庫和數據湖打通的新型開放式架構。它既具備數據湖的靈活性，也具備數據倉庫的高性能及管理能力，為企業進行數據治理帶來了更大的便利和更高的效率。

在數據湖倉的底層，支持多種數據類型并存，能實現數據間的相互共享。

在數據湖倉的上層，可以通過統一接口進行訪問，可同時支持實時查詢和分析。

數據倉庫和數據湖這兩套體系相互打通之后，數據可以在兩者之間自由流動。

也就是說，數據湖里的“新鮮”數據（熱數據），可以流到數據倉庫里，直接被數據倉庫使用。

而數據倉庫里的“不新鮮”數據（冷數據），也可以流到數據湖里，低成本長久保存，供未來使用。

數據湖倉的特點，其實就是數據倉庫的優點+數據湖的優點。

在數據存儲方面，繼承了數據湖的優勢，支持多樣化數據，且以HDFS或云對象存儲為基礎，實現了低成本、高可用。數據以原始格式或開放文件格式（如 Parquet、ORC）存儲，具備高效的壓縮比與列存儲特性，方便查找。

開放文件格式，也保障了數據在不同計算引擎間的通用性。

數據湖倉同樣支持Iceberg、Hudi、Delta Lake等開放表格式。它們不僅支持數據的近實時更新、高效的快照管理，還兼容 SQL 標準，使得數據既可以像傳統數據庫表一樣進行事務性操作，又能充分利用數據湖的分布式存儲與彈性計算優勢。

在計算引擎方面（采用存算分離架構），整合了Spark、Flink、Presto、Doris等多樣的計算引擎。通過統一的調度與資源管理，不同引擎可以共享存儲資源，協同處理復雜的數據工作流，滿足企業從實時監控到深度分析的全方位計算需求。

阿里云數據湖倉架構（來自阿里云官網）

在數據一致性方面，提供ACID（原子性、一致性、隔離性、持久性）保證，確保數據寫入的一致性，保證了多方同時讀取或寫入數據時的數據準確性。

在數據管理方面，數據湖倉實現了統一的元數據管理，支持全鏈路血緣，提供統一的命名空間、全局的數據目錄。無論數據存儲在何處，使用何種計算引擎，用戶都能通過統一的API進行快速檢索、理解與訪問數據。數據治理，變得非常高效。

在數據安全方面，數據湖倉一般還支持多租戶和庫表列級數據權限，能夠很好地進行租戶隔離和數據權限管控，確保了數據的安全性和隱私性。

當然了，數據湖倉也不是沒有缺點。

作為一項融合的技術架構，它的復雜性比較高，需要很高的技術門檻。而且，它的早期投資比較大，對企業來說有一定的成本壓力。

數據湖倉的性能優化、數據治理以及安全防護，也存在一定的挑戰。這些門檻和挑戰，往往會讓企業用戶望而卻步。

█數據湖倉的參考架構

數據湖倉誕生至今的時間并不是很長。從最開始的倉和湖獨立建設，到后來，逐漸形成了“湖上建倉”與“倉外掛湖”兩種實踐路徑。

湖上建倉， 是指基于數據湖架構，或者以數據湖作為數據存儲中間層，實現多源異構數據的統一存儲。然后，以統一調用接口方式調用計算引擎，最終實現上下結構的湖倉一體架構。

倉外掛湖，是指以MPP數據庫為基礎，使用可插拔架構，通過開放接口對接外部存儲，實現統一存儲。

隨著時間的推移，也有企業開始推出兩種架構的深入融合。

目前，在數據湖倉領域 比較有代表性的服務商，包括國外的AWS（ 亞馬遜云科技 ）、微軟Azure 、Databricks、 Snowflake，以及國內的阿里云、騰訊云、 華為云、星環科技等。

各大服務商的架構有較差的差異，但基本上都包括存儲層、元數據管理層、計算引擎層、服務與治理層等。

以下是幾個比較有代表性的架構，供參考。

科杰的數據湖倉架構：

圖片來自網絡

Azure的數據湖倉架構：

圖片來自網絡

AWS的數據湖倉（他們叫智能湖倉）架構：

圖片來自“特大號”

基于Apache Doris的湖倉一體架構：

圖片來自網絡

█最后的話

目前來看，數據湖倉正在加速成為企業重要的戰略性基礎設施，用于長期的數據價值挖掘，以及發展AI應用。

根據畢馬威的報告顯示，86%的海外企業計劃統一其分析數據，以支持AI業務的開發。國內也是如此。例如騰訊、B站、小紅書等頭部互聯網企業，都采用了數據湖倉架構，用于不同程度的AI應用。

數據湖倉在實時流處理與機器學習方面表現出色，能夠很好地滿足大模型的訓練需求，相信未來幾年會得到更好的發展。

好啦，以上就是關于數據湖倉的介紹。鮮棗課堂大數據專題系列到此結束。感謝大家的耐心觀看！

參考文獻：

1、《數據庫、數據湖、數據倉庫、湖倉一體、智能湖倉，分別都是什么鬼》，特大號；

2、《從數據湖到湖倉一體：統一數據架構演進之路》，Light Gao，知乎；

3、《數據倉庫、數據湖、湖倉一體，究竟有什么區別？》，SelectDB，知乎；

4、《什么是湖倉一體？湖倉一體解決了什么問題？》，帆軟；

5、《2024大數據“打假”：什么才是真湖倉一體？》，張友東；大數據在線；

6、《大數據架構系列：如何理解湖倉一體？》，葉強盛，騰訊云開發者社區；

7、百度百科，維基百科，各大服務商官網。