極簡數據平台史：從數據倉庫、數據湖到湖倉一體

1. 寫在前面

我們身處一個大數據時代，企業的數據量爆炸式增長。如何應對海量數據存儲和處理的挑戰，建設好數據平台，對一個企業來說是很關鍵的問題。從數據倉庫、數據湖，到現在的湖倉一體，業界建設數據平台的新方法和新技術層出不窮。

理解這些方法和技術背後隱藏的演進脈路、關鍵問題、核心技術原理，可以幫助企業更好地建設數據平台。這也是百度智能雲推出數據湖系列內容的初衷。

本系列文章將包含幾個部分：

本篇將作為數據平台整個系列的開篇，為大家介紹數據平台技術的歷史和發展過程中遇到的一些關鍵技術問題。

後續內容將分為兩大主題，從存儲和計算的兩個角度出發介紹數據平台中的核心技術原理和最佳實踐，以及百度智能雲對這些問題的思考。

2. 數據的價值

"Data is the new oil." — Clive Humby, 2006

Clive Humby在 2006 年說出這句 「數據是新的石油」 然後，迅速成為大家的共識。這哥們一生的軌跡是大數據時代最好的註腳，他最早是一位數學家，後來和妻子聯合創建了一家數據公司，再後來成立了專註於數據領域的投資基金。說這句話的時候，Clive Humby 正在向資本市場賣力地推銷他和妻子創建的公司。資本市場喜歡這樣簡單有力的金句，他的公司在 5 年後賣出了好價錢。

對於數據的所有者、數據行業的從業者而言，這句話只說出了一半的真相。Michael Palmer 對這句話進行了補充：

"Data is just like crude. It's valuable, but if unrefined it cannot really be used. It has to be changed into gas, plastic, chemicals, etc to create a valuable entity that drives profitable activity; so must data be broken down, analysed for it to have value." — Michael Palmer

簡單來講，就是 「數據需要提煉才能釋放真正的價值」。

對於一個企業來說，最容易理解和最容易做的是 「大數據」 3 個字的 「大」 字，在意識到經營各個環節的數據中可能蘊含著營收、用戶數增長的奧秘之後，往往積累了大量的原始數據。這些原始數據就是原油，儘管珍貴，但包含了很多的噪音、雜質，甚至錯誤，不同數據間的內在關係也不是顯而易見的。這距離需要挖掘的奧秘還有很長的路要走。要洞悉這些奧秘就需要繼續 「提煉」，就是使用恰當的方法對原始數據進行整理、提純、組合、分析，去蕪存菁、抽絲剝繭，揭示數據中真正有價值的部分，最終轉化為業務增長的驅動力。

支撐這一 「提煉」 全流程的基礎設施就是一個企業的數據平台。數據平台之於數據，就好比煉油廠之於原油。

隨著企業數據量的爆炸式增長，以及越來越多的企業上雲，數據平檯面臨的數據存儲、數據處理的挑戰越來越大，採用什麼樣的技術來構建和迭代這個平台一直是業界研究的熱點，新技術和新思路不斷湧現。將這些技術歸納下來以數據倉庫 (Data Warehouse) 和數據湖 (Data Lake) 為兩類典型的路線。近年來這兩個路線在演進過程中邊界日趨模糊，逐漸走向融合，開始形成所謂的現代數據架構 (Modern Data Architecture)，又稱湖倉一體 (Data Lakehouse)。

3. 數據平台的組成

在討論具體的技術問題之前，我們先看下業界的數據平台長什麼樣：

數據平台 = 存儲系統 + 計算引擎 + 介面

這幾部分的作用可以概括如下。

3.1 數 據存儲

數據存儲解決將原料存進來的問題，具有時間跨度長、來源分散、集中存儲的特點。

• 「時間跨度長」的意思是數據存儲應儘可能地保存全歷史數據。歷史數據對企業的重要性，在於 「以史明鑒」，從一個更長的時間維度去觀察數據的趨勢、健康度等信息。
• 「來源分散」是因為數據的源頭通常是各類業務系統，可能是 MySQL、Oracle 這樣的關係型資料庫中的數據，也可能是業務系統記錄的日誌。企業還可能購買或採集第三方的數據集作為內部數據的補充。數據平台需要有能力導入不同源頭的數據，至於導入後以什麼樣的格式存儲，不同的技術方案有各自的要求。
• 「集中存儲」是為了建立 single source of truth，無論數據的源頭在哪裡，納入數據平台之後，數據平台就是唯一的可信來源。這裡更多的是指邏輯上的集中存儲，在物理上還存在分散的可能性，例如一個企業採用了多雲架構，將數據分散存儲在不同的雲廠商，數據平台對數據使用方屏蔽了數據的實際位置。集中存儲同時還意味著更精細的管控，防止數據使用許可權擴大到不必要的範圍。

3.2 計算引擎

計算引擎的目標是從數據存儲中提煉有效信息。遺憾的是，目前業界並不存在一個大一統的計算引擎，根據模型、實效性、數據量的要求，往往採用不同的解決方案。典型的，對於深度學習任務使用 TensorFlow、PyTorch、PaddlePaddle 等框架，數據挖掘等離線計算採用 Hadoop MapReduce、Spark 引擎，商業智能分析使用 Apache Doris 等 MPP 數據倉庫。

不同的計算引擎對數據存儲格式的要求也不盡相同：

• 一部分計算引擎支持的介面比較開放和底層，對數據格式的要求很寬鬆。例如 Hadoop MapReduce、Spark 可以直接讀取 HDFS 中的文件，這些數據是什麼樣的格式，引擎本身並不關心，業務自己決定如何解釋和適用數據。當然，有一些格式（如 Apache Parquet 等）應用比較廣泛，在底層介面之上，引擎可以選擇封裝出對特定格式的處理邏輯，減少業務的重複開發成本。
• 另外一部分計算引擎較為封閉，只能支持有限的數據格式，甚至不暴露內部的數據格式，所有的外部數據處理前都必須經過導入的步驟。例如，Apache Doris 數據如何存儲是系統自己決定，好處是可以讓存儲和計算配合更緊密，性能更好。

計算引擎在計算過程中生產的一些有價值的數據，一般也會存回數據存儲中，以方便其他業務使用。

3.3 介面

介面決定了數據平台的用戶如何使用計算引擎。最為流行的是 SQL 語言介面。一些計算引擎還提供了封裝層次不一的編程介面。對於一個企業來說，提供的介面種類越少越好，對用戶來說越友好。

4. 數據平台的兩種路線：數據倉庫和資料庫

4.1 數據倉庫

數據倉庫出現的時間要遠比資料庫要早。最初的場景是商業智能 (Business Intelligence)，簡單說就是企業的管理層希望有一個方便看各類經營數據的儀錶盤，展示一些統計、趨勢數據，數據來源是 ERP、CRM、業務資料庫等。為了把這個需求做得好用，最佳的方法是將企業內部各個數據源的數據統一收集到單個站點上歸檔，並維護歷史數據，讓相關的查詢需求在這一個站點解決。這個統一的站點就是數據倉庫。

主流的數據倉庫實現基於「聯機分析處理 (Online Analytical Processing, OLAP)」技術。在數據倉庫誕生之前，業務已經廣泛在使用 MySQL、Orcale 等關係型資料庫，這類資料庫基於「在線交易處理 (On-Line Transactional Processing, OLTP)」技術。OLTP 資料庫中的數據有固定的格式，組織清晰，支持的 SQL 查詢語言好用易懂。同時，其自身又是數據倉庫最重要的數據來源之一。因此，直接使用 OLTP 資料庫來建設數據倉庫是一個很自然的想法。但很快，大家就發現數據倉庫有自己的業務特點，基於 OLTP 遇到了瓶頸，OLAP 獲得獨立發展的契機：

• 一方面，OLTP 資料庫的數據存儲方式是面向行的 (row-oriented)，一個行的數據存儲在一起，讀取的時候哪怕只需要幾個欄位，都需要把整行數據都讀取出來再提取需要的欄位。數據倉庫表的欄位通常比較多，這就導致了讀取效率不高。面向列的 (column-oriented) 的數據存儲方式，將不同的列或列族分開存儲，在讀取的時候就可以只讀取需要的部分，這種方式能夠有效減少讀取的數據量，對數據倉庫的場景更為友好。
• 另一方面，傳統 OLTP 資料庫依賴單機硬體配置的 scale-up 來提升處理能力，上限較低。而數據倉庫場景一次查詢讀取的數據量非常大，在相同欄位上反覆調用同樣的讀取邏輯，很適合做單機、多機的並行處理優化，利用集群的 scale-out 處理能力來縮短查詢的時間。這就是 MPP (Massively Parallel Processor) 計算引擎的核心思想。

因此，現代數據倉庫架構的特點是分散式、列式存儲、MPP 計算引擎。用戶發起計算任務後，數據倉庫的MPP 計算引擎將計算進行分拆，每個節點負責處理一部分，節點間並行計算，最終匯總結果輸出給用戶。

數據倉庫是典型的 「Schema-on-Write」 模式，要求存儲的數據在寫入的時候處理成預先定義的格式，即schema。這就好比數據倉庫的管理員提前確定了一個包裝盒的樣式，所有的貨物 (數據) 必須用包裝盒裝好，整整齊齊才能進入倉庫。

數據源的原始數據往往和定義好的 schema 存在差異，因此導入的數據需要經過 ETL 過程，ETL 是抽取(Extract)、轉換 (Transform)、載入 (Load) 這三個步驟的縮寫。Extract 階段從原始數據源讀取進行數據清理(data cleansing) 糾正其中存在的錯誤、重複。然後進入 Transform 階段，做必要的處理將數據轉化成指定的schema。最後，數據入庫 Load 到數據倉庫中。

4.2 數據湖

內蒙古自治區白雲鄂博礦，全球唯一一個同時包含 17 種稀土元素的礦。在長達 60 多年的時間裡，這個礦一直被當成鐵礦開採，後來隨著稀土戰略價值的提升，以及開採技術的進步，才轉型為中國最大的稀土礦藏。

講這個故事是想說明原始數據的重要性，原始數據就像白雲鄂博礦，除了已經被發現的鐵，還可能蘊藏著儲量豐富的稀土。數據倉庫的 「Schema-on-Write」 模式要求我們在處理數據之前就確切的知道我們挖的是什麼，當時間流逝，歷史數據只剩下數據倉庫中保存的那些時，我們可能連丟棄掉了哪些稀土都不會知道。

更好更多地保留原始數據，避免丟失重要的未知信息，這是數據湖概念的初衷。數據湖提倡所有的數據，不管是資料庫的結構化數據，還是視頻、圖片、日誌這類非結構化的數據，都以它們原始的格式存儲到一個統一的存儲底座中。各個數據源，彷彿一條條河流，匯聚到這個統一的 「湖」 中融為一體，所有的數據使用方由這個「湖」 統一供水。

由於缺乏明確的結構信息，數據湖使用 「Schema-on-Read」 模式，用戶在讀取數據後再將其轉化為對應的結構進行處理。和數據倉庫的 「Schema-on-Write」 相比，對數據的處理流程變成了 ELT，即 Transform 階段在Load 之後發生。

「Schema-on-Read」由於結構非常鬆散，對計算引擎的約束較少，業界事實上根據不同的場景發展出多種計算引擎。

傳統的數據湖，是大數據體系的等價詞，主要經歷了 「存算一體」 和 「存算分離」 兩個階段：

階段 1：存算一體數據湖

這一階段企業基於 Hadoop 生態開展數據湖，使用 HDFS 作為數據存儲，使用Hadoop MapReduce、Spark 等計算引擎，計算和存儲資源在同一批機器上，擴容集群會同時擴容算力和容量。雲計算髮展起來之後，這套架構被從線下 IDC 機房原封不動地搬到雲上。

階段 2：存算分離數據湖

在經歷一段時間的實踐之後，存算一體架構遭遇到了瓶頸，主要體現在幾個方面：

• 計算和存儲無法分開擴容，而現實中大部分用戶對這兩種資源的需求不是匹配的，存算一體架構必然會導致其中一種資源的浪費。
• 存儲容量和文件數量爆炸式增長之後，HDFS 的 NameNode 單點架構遇到了元數據性能的瓶頸，企業通過升級 NameNode 節點配置、多套 HDFS 集群或 HDFS Federation 來緩解該問題，但未能根本解決此問題，給數據平台運維人員帶來極大的負擔。
• 存儲成本也是存算一體架構的一個痛點。HDFS 的 3 副本機制並不適合存儲較冷的數據，比糾刪碼機制的成本要高出至少一倍。在雲上還面臨副本放大的問題，雲廠商提供的雲磁碟本身就有副本機制，使用雲磁碟搭建 HDFS 的實際副本數更高，可能高達 9 副本。

人們在解決這些問題的過程中注意到雲廠商的對象存儲服務。這種服務提供了一個性能和容量近乎無限擴展、成本低廉、serverless 的存儲系統。除了在部分文件系統介面 POSIX 兼容性方面 (如原子 rename、邊寫邊讀等) 存在不足，這個服務解決了上述的痛點問題，是 HDFS 的一個合適替代品。實際上，下一代 HDFS 系統OZone 系統也借鑒了對象存儲的思路來解決上述問題。

以對象存儲為基礎的數據湖誕生了「存算分離「架構。存算分離的特點是計算資源和存儲資源獨立擴展。

存算分離架構中的存儲是雲廠商提供的對象存儲服務。和自建 HDFS、OZone 相比，雲廠商最大的一個優勢來自規模。雲廠商需要足夠大的集群來存儲海量的用戶數據，數據量越大，集群的規模就越大，節點、設備就越多，能夠提供的整體性能就越高。對於單個用戶來說，就能「借用」到比同等規模自建 HDFS 更高的性能。足夠大的存儲資源池，是存算分離架構能夠工作的前提和底氣。

在對象存儲解決了擴展性、性能、成本的基礎上，serverless 的產品形態讓存算分離數據湖的計算引擎很容易獨立伸縮其算力，甚至可以做到需要計算的時候才去分配計算資源，計算完成就立刻銷毀資源，僅為使用的資源付費，在成本和效率方面做到最優。 這一點是存算分離架構和雲計算之前的時代是不可能做到的。

對於雲廠商來說，這種架構的轉變讓對象存儲服務一下子成為舞台的焦點，讓雲廠商甜蜜的同時也考驗著他們的技術實力，吹過的牛逼必須不打折扣地一一兌現。這裡的主要挑戰包括：

• 規模。一個客戶數 PB 幾十 PB，很多客戶共享資源池，累加起來讓對象存儲的容量輕鬆達到 EB 級，相應的元數據規模達到萬億級。單個集群服務好 EB 級的容量、萬億級的元數據，需要非常優秀硬核的架構設計，系統的每個部分都不存在擴展性的短板。
• 穩定性。支持 EB 級的容量、萬億級的元數據，每個集群的機器數量達到數萬甚至數十萬台，龐大的機器基數下，硬體故障、軟體故障是家常便飯。降低甚至消除這些不可控因素的影響，提供穩定的延時和吞吐水平、較低的長尾，拼的是高質量的工程實現和運維能力。
• 兼容性。儘管對象存儲作為數據湖存儲已經成為一個共識，但大數據體系內的軟體，無論是因為歷史包袱的原因，還是因為確實無法改造，在一些場景下依然會依賴 HDFS 特有的一些能力。例如，Spark 依賴 rename 提交任務，利用了 HDFS rename 操作較快的執行速度和原子性保證，但在對象存儲的鼻祖 AWS S3 里，rename 不被支持，只能粗糙的通過「拷貝 + 刪除」模擬，執行速度很慢且沒有原子性保證。如果各家雲廠商對象存儲的普遍水平是在 70% 的場景下取代 HDFS，那剩下的 30% 的部分就看廠商如何進一步去解決兼容性差的部分，從而讓存算分離架構執行得更徹底。

4.3 數據倉庫 VS 數據湖

數據倉庫和數據湖套用前文的公式歸納為：

數據倉庫 = 結構化數據存儲系統 + 內置計算引擎 + SQL 介面

數據湖 = 原始數據存儲系統 + 多種計算引擎 + 包含 SQL 在內的多種介面

數據倉庫和數據湖就好比是手機屆的 iOS 和 Andriod：

• 數據倉庫好比 iOS，是一個相對封閉的體系，數據流入流出、使用場景約束較多，但勝在簡單易用，封閉的體系控制力更強，較容易做存儲格式、計算並行等性能上的優化，在一些要求極致性能的查詢場景仍佔據著主導地位。
• 數據湖好比 Android，強調開放性，幾乎把選擇的權利都下放給用戶了，可以選擇的手機廠商 (計算引擎) 也很多，但用好它需要用戶一定的專業能力，用不好會有副作用，很容易導致 「數據沼澤 (Data Swamp)」。

5. 現代數據平台：湖倉一體

5.1 數據湖面臨的困境

數據湖將 「存儲什麼數據、如何使用數據」 的決定權還給了用戶，約束非常寬鬆。但用戶如果在數據入湖的時候沒有做好數據的管理工作，有用無用、高質量低質量的數據被一股腦丟進來了，使用的時候很容易找不到需要的數據。長期下來，數據湖變成了一個巨大的垃圾場，規範的叫法是 「數據沼澤」。

為了避免數據湖最後變成數據沼澤，需要解決幾個重要的問題：

問題 1：數據質量問題

僅靠 「Schema-on-Read」 在計算時直接處理原始格式的數據，過濾掉其中的無用信息，這個工作每次計算都需要重複做，既降低了計算的速度又既浪費了算力。

一個可行的方式，是在數據湖借鑒數據倉庫的做法，通過一輪或多輪 ETL 對原始數據進行一些前置處理，將數據轉化成對計算引擎更友好、數據質量更高的數據。原始數據不刪除，而 ETL 產生的數據同樣存儲在數據湖中，這樣既保留了原始數據，又保證了計算的效率。

問題 2：元數據 (metadata) 管理問題

元數據是描述數據的數據，它對數據的重要性在於它負責回答那幾個重要的哲學問題 「我是誰？我在哪裡？我從哪裡來？」。數據的格式信息 (例如一個資料庫表文件的欄位定義) 、數據的位置信息 (例如數據存儲在哪個路徑)、數據的血緣關係 (例如數據是從哪些上游數據處理得到的) 等等都需要依賴元數據來解釋。

為數據湖建立完善的元數據可以幫助用戶更好地使用數據。一般元數據分為兩部分，都很重要。一個是集中的數據目錄 (Data Catalog) 服務，一般這類服務具備一些自動分析和模糊搜索的能力，用於管理和發現數據湖中都有哪些數據。另外就是數據自己內置的元數據，這些元數據可以保證即使數據挪了位置也能準確的解釋數據。打個比方，數據目錄好比圖書館裡的書架，通過對書籍分門別類整理歸檔，能夠快速地定位書籍所在的位置；數據內置的元數據好比一本書的目錄部分，通過目錄可以快速了解這本書大概包含哪些內容，都位於哪一頁；當一本書從一個書架挪動到另外一個書架上，改變的只是書的位置，書的目錄沒有變化。

元數據管理還需要解決數據許可權的問題。數據湖底層依賴的存儲系統，無論是HDFS，還是對象存儲，提供的數據許可權是以目錄和文件為單位的，粒度和上層業務的需求並不一致。舉個例子，一個圖片識別 AI 任務的數據集有很多的小文件，這些小文件的應當被視作一個整體，不存在「一個用戶有許可權訪問其中部分文件，沒許可權訪問另外一部分文件」的現象。另外一個例子是，一個文件存儲了業務訂單的數據，對於銷售人員、公司高管，能夠查看的數據範圍是不一樣的。這些都要求更精細的許可權控制。

問題 3：數據版本問題

數據入湖通常不是一鎚子買賣，導入一次從此就不更新了。例如，從線上用戶訂單資料庫採集數據到數據湖用於後續分析，需要源源不斷的同步新的訂單。解決多次導入問題最簡單的方法就是每次都全量導入一遍，但這種方式顯然過於粗糙，會增加資源消耗，數據導入的耗時也較高。

因此，支持對數據增量更新是數據湖的一個重要能力。這其中存在一些棘手的難題，包括：1) 正在更新的時候如何處理讀請求；2) 更新操作中斷後如何恢復；3)如何識別不完整的更新操作；4) 數據被一次錯誤的操作污染之後如何復原。後面的這些棘手問題在資料庫和數據倉庫中的答案是 ACID。數據湖領域近年來出現的表格格式 (Table Format)，如 Apache Iceberg、Apache Hudi、Delta Lake 致力於為對象存儲補齊這些能力，已經成為數據湖的重要組成部分。

問題 4：數據流通問題

現實場景複雜多變，對數據處理的實時性、準確性要求不盡相同，業界也因此發展出來諸多的計算引擎。如果這些計算引擎各講各話，只認自己定義的存儲格式時，那麼同樣的一份數據在被不同計算引擎處理時，需要反覆的做 Schema-on-Read 或者 ETL，白白浪費大量的資源。這顯然不合理。

不需要經過翻譯，大家都能講普通話是最理想的。在大數據的發展過程中，逐漸形成了一些常用的數據格式(Apache Parquet、Apache ORC 等) 和表格格式(Apache Iceberg、Apache Hudi、Delta Lake 等)，這些技術逐漸被越來越多的計算引擎支持，某種意義上充當了數據湖領域普通話的作用，改善了數據流通問題。

5.2 湖和倉融合的趨勢

數據湖在迭代過程中，和數據倉庫的界限越來越模糊，逐漸呈現出融合的趨勢：

• 在解決數據沼澤的過程之中，為了讓一個很寬鬆的生態變得更好用，業界的實踐實際上就是對數據湖的使用做了很多的約束。有意思的是，這些約束和原來數據倉庫做的很多事情是很類似的，例如ETL、ACID、許可權控制等。這使得數據湖呈現出數據倉庫的一些特徵。
• 業界在嘗試了一圈非 SQL 的各種編程介面和交互方式之後，發現很多的場景下，SQL 依然是最佳的選擇。數據倉庫這些年也越來越開放，對數據湖常用的一些數據格式、表格格式的支持越來越好，除了內置 ETL 的支持，也可以直接把它們當做外部源來處理。這些趨勢表明，數據倉庫作為一種重要的計算引擎，可以生長在數據湖之上。
• 數據倉庫同樣面臨存算一體的局限性，也在向存算分離架構迭代。一些系統採用了冷熱分離的設計，熱數據保存本地節點高速介質上，冷數據下沉到數據湖中，在性能和成本之間取得平衡。另外一些更徹底的雲原生數倉系統，全量數據都在數據湖中，通過本地節點的緩存來彌補數據湖速度的問題，這種設計可以簡化數據倉庫的架構，讓數據倉庫不需要再關注數據可靠性問題，同時可以讓多個只讀集群共享同一份數據。
• 數據倉庫領域發展的一些重要技術和方法，也可以被數據湖之上的大數據計算引擎借鑒，反之亦然。例如在 ClickHouse 等數據倉庫中成熟應用的計算引擎加速技術，如向量化計算 (vectorization)、LLVM JIT，被借鑒來實現 Spark 的 Native 引擎，和原有的 JVM 引擎相比，Native 引擎的硬體資源利用率更高，計算速度更快。

除了數據倉庫、大數據外，企業內還存在其它重要的計算類型，最常見的就是AI、HPC 等高性能計算。 數據湖的性能優勢的體現是吞吐高，元數據性能和延時一般，而高性能計算對元數據性能、延時有比較苛刻的要求。因此，企業還需要在數據湖外為這類業務額外維護一套或多套高速文件存儲系統 (Lustre、BeeGFS 等)。 本質上看，高性能計算使用的框架也是某種計算引擎，數據的來源和產出也是企業數字資產的一部分，如何將這部分業務納入到數據湖體系中是一個重要的問題。這個問題的答案和數據倉庫存算分離是類似的，解決思路也是相通的，同樣是兩個路線：

• 冷熱分離設計。高速文件存儲系統將數據湖作為冷數據層。
• 基於數據湖設計雲原生的文件系統。這類文件系統雖然提供文件系統介面，但實際上是一個緩存加速系統，採用的是「緩存層 + 數據湖」的架構。緩存層在計算節點或靠近計算節點的硬體上按需維護熱數據的緩存。數據湖存儲全量數據，保證數據的可靠性。一旦緩存系統中數據淘汰或丟失，仍然可以從數據湖重新載入數據。

湖倉一體這個說法最早是 Databricks 提出的，在業界尚有分歧，其它一些競爭公司會儘力避免使用這個術語，AWS 採用的是現代數據架構 (Modern Data Architecture) 的說法。但不管怎麼命名，湖倉一體都代表著數據湖的下一階段的形態，其本質是企業的終極一站式數據平台。

這個數據平台首先是一個 all-in-one 的存儲基礎設施，滿足了企業所有的數據存儲需求，不光能滿足低成本的存儲需求，也能滿足高性能的需求。其次，數據平台超越了數據倉庫、大數據的範疇，之上運行著數據倉庫、大數據、AI、HPC 等各種各樣的計算引擎，這些不同的計算引擎都能消費和產出互相能理解的數據結構，數據在業務之間的流轉無障礙。

5.3 湖倉一體架構

根據前面的討論，我們可以使用數據平台公式對湖倉一體進行簡單的歸納：

湖倉一體 = 配備元數據層和加速層的對象存儲 + 數據倉庫、大數據、AI、HPC 等各個領域的計算引擎 + 包含SQL 在內的多種介面

存儲系統部分，對象存儲已經成為事實上的數據湖標準存儲，其生態繁榮程度遠超其它種類的雲存儲產品。對於對象存儲無法很好解決的存儲問題，需要搭配合適的元數據層和加速層。

• 針對數據沼澤問題，元數據層建立必要的數據質量、元數據管理、版本管理、數據流通機制，讓企業內部各業務能便捷地使用高質量的數據。
• 針對一些對元數據、延時有更高要求的業務，如數據倉庫、AI、HPC 等，加速層作為對象存儲的補充，一般採用高速文件系統或者緩存系統，部署上離計算節點較近，元數據和數據可在加速層和數據湖之間自動流轉。為了簡化使用，加速層還會搭配上層的作業調度系統，來讓數據流轉工作更加智能和簡單。例如，通過作業調度系統提前預熱數據，在數據預熱到緩存之後，作業調度系統才開始分配計算資源執行計算，由此可以享受到比數據湖更快的訪問速度。

計算引擎部分，存在數據倉庫、大數據、AI、HPC 等各類引擎。數據流轉是最基本的問題。此外，還有一個重要的問題是這些計算引擎本身的調度和管理問題。從資源的角度看，這些計算引擎主要消耗 CPU、GPU 等種類的計算資源，具備資源共享的基礎，提高資源的整體利用率對用戶來說意味著節省成本。解決這個問題有兩個手段。

• 一個手段是，對於特定的計算引擎，使用雲廠商的託管或 serverless 的服務代替自建，雲廠商的服務內置彈性收縮能力，按需付費，可以讓相關的資源利用率控制在合適的範圍內，規避了資源共享的問題。
• 另外一個手段是，用戶自己運維的計算引擎使用統一的調度和資源管理平台來分配資源，這方面 Kubenetes 是最流行的選擇，如果某種計算引擎還未支持在其上部署，只是時間問題。雲廠商通常也會提供優化的Kubenetes 的版本或服務供用戶選擇。

介面部分，其實取決於具體的計算引擎，能用 SQL 表示的場景 SQL 是最好的選擇，其它場景需要用戶熟悉引擎的編程介面。

6. 總結

企業數據量爆炸式增長，業務場景日趨複雜，推動著數據平台技術不斷變革。數據倉庫、數據湖，這兩種數據平台的技術路線在過去的實踐中充分展現了各自的優點和缺陷，近年來開始融合，取長補短，向所謂的湖倉一體或現代數據架構迭代。

不斷地湧現的新技術、新方法，是無數從業者集體智慧的結晶，而開放的基調則是促成這一切的催化劑。這一領域的開放體現在很多方面：

• 數據是開放的。計算引擎越來越開放，普遍支持一些標準的數據格式，數據流通越來越容易，業務按需選擇最合適的引擎處理計算任務。
• 技術是開放的。湖倉一體技術架構中的絕大部分重要技術，都以開源項目的形式存在著，沒有任何一家企業可以壟斷知識產權。廠商發行版和開源版本之間可以相互替代，選擇權在用戶。技術的開放也促進了跨領域的技術融合，不同的領域之間互相借鑒方法和技術，揚長補短，起到 1 + 1 > 2 的效果。
• 基礎設施是開放的。在湖倉一體解決方案中，雲廠商扮演著重要的角色，提供了對象存儲、託管大數據服務等基礎設施。這些基礎設施兼容行業標準，也存在開源替代，客戶很容易搭建混合雲、多雲架構，更好地利用雲的彈性。

在這開放的基調下，整個行業，無論是用戶還是平台，都對數據平台有自己的思考和看法。我們也希望藉此表達我們的一些觀點，一方面是希望能給業界提供一些淺薄的見解，另一方面未來回看時對自己而言也是雪泥鴻爪。