超越數據湖和數據倉庫的新範式：LakeHouse

2020 年 3 月 11 日
筆記

翻譯自： https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html

1. 引入

在Databricks的過去幾年中，我們看到了一種新的數據管理範式，該範式出現在許多客戶和案例中：LakeHouse。在這篇文章中，我們將描述這種新範式及其相對於先前方案的優勢。

數據倉庫技術自1980誕生以來一直在發展，其在決策支援和商業智慧應用方面擁有悠久的歷史，而MPP體系結構使得系統能夠處理更大數據量。但是，雖然數據倉庫非常適合結構化數據，但許多現代企業必須處理非結構化數據、半結構化數據以及具有高多樣性，高速度和高容量的數據。數據倉庫不適用於許多此類場景，並且也不是最具成本效益的。

隨著公司開始從許多不同源收集大量數據，架構師開始構想一個單一的系統來容納不同分析產品和工作負載的數據。大約十年前，公司開始構建數據湖：各種格式原始數據的存儲庫。數據湖雖然適合存儲數據，但缺少一些關鍵功能：不支援事務、無法提高數據品質、缺乏一致性/隔離性，導致幾乎不可能混合處理追加（append）和讀取，批處理和流處理作業。由於這些原因，數據湖之前的許多承諾尚未實現，在許多情況下還會失去數據倉庫的許多好處。

公司對靈活、高性能系統的需求並未減少，如需要各類數據應用程式包括SQL分析、實時監控、數據科學和機器學習的系統。人工智慧的大部分最新進展是有可用於更好處理非結構化數據（文本，影像，影片，音頻）的模型，這些恰恰是數據倉庫未針對優化的數據類型。一種常見的解決方案是使用多個系統，即一個數據湖、幾個數據倉庫以及其他專用系統（如流、時間序列、圖形和影像資料庫系統）。維護大量系統會引入額外的複雜性，更重要的是會帶來延遲，因為數據專業人員需要在不同系統間移動或複製數據。

2. 什麼是LakeHouse?

解決數據湖限制的新系統開始出現，LakeHouse是一種結合了數據湖和數據倉庫優勢的新範式。LakeHouse使用新的系統設計：直接在用於數據湖的低成本存儲上實現與數據倉庫中類似的數據結構和數據管理功能。如果你現在需要重新設計數據倉庫，鑒於現在存儲（以對象存儲的形式）廉價且高可靠，不妨可以使用LakeHouse。

LakeHouse有如下關鍵特性:

事務支援：企業內部許多數據管道通常會並發讀寫數據。對ACID事務支援確保了多方可使用SQL並發讀寫數據。
模式執行和治理（Schema enforcement and governance）：LakeHouse應該有一種可以支援模式執行和演進、支援DW模式的範式（如star/snowflake-schemas）。該系統應該能夠推理數據完整性，並具有健壯的治理和審計機制。
BI支援：LakeHouse可以直接在源數據上使用BI工具。這樣可以提高數據新鮮度，減少等待時間，降低必須同時在數據湖和數據倉庫中操作兩個數據副本的成本。
存儲與計算分離：這意味著存儲和計算使用單獨的集群，因此這些系統能夠支援更多用戶並發和更大數據量。一些現代數據倉庫也具有此屬性。
開放性：使用的存儲格式（如Parquet）是開放式和標準化的，並提供API以便各類工具和引擎（包括機器學習和Python / R庫）可以直接有效地訪問數據。
支援從非結構化數據到結構化數據的多種數據類型：LakeHouse可用於存儲、優化、分析和訪問許多數據應用所需的包括影像、影片、音頻、半結構化數據和文本等數據類型。
支援各種工作負載：包括數據科學、機器學習以及SQL和分析。可能需要多種工具來支援這些工作負載，但它們底層都依賴同一數據存儲庫。
端到端流：實時報表是許多企業中的標準應用。對流的支援消除了需要構建單獨系統來專門用於服務實時數據應用的需求。

以上是LakeHouse的關鍵特性，企業級系統可能還需要其他功能特性，如安全和訪問控制工具是基本要求，尤其是根據最近的隱私法規，包括審核、保留和沿襲（lineage）在內的數據治理功能變得至關重要。可能還需要使用數據發現（ data discovery ）工具，例如數據目錄（catalog）和數據使用指標。使用LakeHouse，那麼就只需為單個系統實施、測試和管理此類企業功能。

3. 早期示例

Databricks平台具有LakeHouse的特性。微軟的Azure Synapse Analytics服務與Azure Databricks集成，可實現類似LakeHouse模式，其他託管服務（例如BigQuery和Redshift Spectrum）具有上面列出的一些LakeHouse功能特性，但它們是主要針對BI和其他SQL應用。企業若想構建系統，可參考適合於構建LakeHouse的開源文件格式（Delta Lake，Apache Iceberg，Apache Hudi）。

將數據湖和數據倉庫合併至一個系統意味著數據團隊可以更快地移動，因為他們無需訪問多個系統便可使用數據。在早期的LakeHouse中，SQL與BI工具的集成通常足以滿足大多數企業數據倉庫的需求。雖然可以使用物化視圖和存儲過程，但用戶可能需要採用其他機制，這些機制與傳統數據倉庫中的機制不同。後者對於「lift and shift scenarios」尤為重要，「lift and shift scenarios」要求系統所具有的語義與舊的商業數據倉庫的語義幾乎相同。

LakeHouse對其他類型數據應用的支援又如何呢？LakeHouse的用戶可以使用各種標準工具（Spark，Python，R，機器學習庫）來處理如數據科學和機器學習等非BI工作負載。數據探索和加工是許多分析和數據科學應用程式的標準。Delta Lake可以讓用戶逐步改進LakeHouse的數據品質，直到可以使用為止。

儘管分散式文件系統可以用於存儲層，但對象存儲在LakeHouse中更為常見。對象存儲提供低成本、高可用的存儲，在大規模並發讀取方面表現出色，這是現代數據倉庫的基本要求。

4. 從BI到AI

LakeHouse是一種新的數據管理範式，從根本上簡化了企業數據基礎架構，並且有望在機器學習已滲透到每個行業的時代加速創新。過去公司產品或決策中涉及的大多數數據都是來自作業系統的結構化數據，而如今，許多產品都以電腦視覺和語音模型、文本挖掘等形式集成了AI。而為什麼要使用LakeHouse而不是數據湖來進行AI？是因為LakeHouse可以提供數據版本控制、治理、安全性和ACID屬性，即使對於非結構化數據也是如此。

當前LakeHouse降低了成本，但它們的性能仍然落後於專門的系統（如數據倉庫），但這些系統需要數年的投入和實際部署。同時用戶可能會偏愛某些工具（BI工具，IDE，筆記型電腦電腦），因此LakeHouse也需要改善其UX以及與流行工具的連接器，以便更具吸引力。隨著技術的不斷成熟和發展，這些問題將得到解決。隨著時間推移，LakeHouse將縮小這些差距，同時保留服務各種數據應用的更簡單、更具成本效益和更強大的能力的核心屬性。