你一定愛讀的極簡資料平臺史，從資料倉庫、資料湖到湖倉一體

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 的效果。

• 基礎設施是開放的。在湖倉一體解決方案中，雲廠商扮演著重要的角色，提供了物件儲存、託管大資料服務等基礎設施。這些基礎設施相容行業標準，也存在開源替代，客戶很容易搭建混合雲、多雲架構，更好地利用雲的彈性。

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

接下來本系列的文章，將圍繞儲存和計算的兩大主題，介紹資料平臺中的核心技術原理和最佳實踐，以及百度智慧雲對這些問題的思考。幫助讀者能對資料湖形成系統性認識，在做資料平臺建設時更有思路。

:arrow_down:點選 閱讀原文 ，瞭解更多資料湖解決方案