Data Lakehouse（湖倉一體）是數據管理領域中的一種新架構范例，結合了Data Warehouse和Data Lakes的最佳特性。數據分析師和數據科學家可以在同一個數據存儲中對數據進行操作，同時它也能為公司進行數據治理帶來更多的便利性。
1、背景
在Databricks的過去幾年中，我們看到了一種新的數據管理范式，該范式出現在許多客戶和案例中：LakeHouse。在這篇文章中，我們將描述這種新范式及其相對于先前方案的優勢。
數據倉庫技術自1980誕生以來一直在發展，其在決策支持和商業智能應用方面擁有悠久的歷史，而MPP體系結構使得系統能夠處理更大數據量。但是，雖然數據倉庫非常適合結構化數據，但許多現代企業必須處理非結構化數據、半結構化數據以及具有多樣性，高速度和高容量的數據。數據倉庫不適用于許多此類場景，并且也不是最具成本效益的。
隨著公司開始從許多不同源收集大量數據，架構師開始構想一個單一的系統來容納不同分析產品和工作負載的數據。大約十年前，公司開始構建數據湖：各種格式原始數據的存儲庫。數據湖雖然適合存儲數據，但缺少一些關鍵功能：不支持事務、無法提高數據質量、缺乏一致性/隔離性，導致幾乎不可能混合處理追加（append）和讀取，批處理和流處理作業。由于這些原因，數據湖之前的許多承諾尚未實現，在許多情況下還會失去數據倉庫的許多好處。
公司對靈活、高性能系統的需求并未減少，如需要用于各種數據應用程序的系統，包括SQL分析、實時監控、數據科學和機器學習。人工智能的最新進展大部分是用于處理非結構化數據（文本，圖像，視頻，音頻）的更好模型，但是這些恰恰是數據倉庫未針對其優化的數據類型。一種常見的方法是使用多個系統-一個數據湖，幾個數據倉庫以及其他專用系統，例如流，時間序列，圖形和圖像數據庫。擁有大量系統會帶來復雜性，更重要的是會帶來延遲，因為數據專業人員始終需要在不同系統之間移動或復制數據。
2、什么是LakeHouse?
解決數據湖限制的新系統開始出現，LakeHouse是一種結合了數據湖和數據倉庫優勢的新范式。LakeHouse使用新的系統設計：直接在用于數據湖的低成本存儲上實現與數據倉庫中類似的數據結構和數據管理功能。如果你現在需要重新設計數據倉庫，鑒于現在存儲（以對象存儲的形式）廉價且高可靠，不妨可以使用LakeHouse。
- 數據倉庫：數倉這樣的一種數據存儲架構，它主要存儲的是以關系型數據庫組織起來的結構化數據。數據通過轉換、整合以及清理，并導入到目標表中。在數倉中，數據存儲的結構與其定義的schema是強匹配的。
- 數據湖：數據湖這樣的一種數據存儲結構，它可以存儲任何類型的數據，包括像圖片、文檔這樣的非結構化數據。數據湖通常更大，其存儲成本也更為廉價。存儲其中的數據不需要滿足特定的schema，數據湖也不會嘗試去將特定的schema施行其上。相反的是，數據的擁有者通常會在讀取數據的時候解析schema（schema-on-read），當處理相應的數據時，將轉換施加其上。
當初許多的公司往往同時會搭建數倉、數據湖這兩種存儲架構，一個大的數倉和多個小的數據湖。這樣，數據在這兩種存儲中就會有肯定的冗余。
Data Lakehouse的出現試圖去交融數倉和數據湖這兩者之間的差別，通過將數倉構建在數據湖上，使得存儲變得更為便宜和彈性，同時lakehouse能夠有效地提升數據質量，減小數據冗余。在lakehouse的構建中，ETL起了非常重要的作用，它能夠將未經規整的數據湖層數據轉換成數倉層結構化的數據。Data Lakehouse概念是由Databricks在此文[1]中提出的，在提出概念的同時，也列出了如下一些特性：
- 事務支持：Lakehouse可以處理多條不同的數據管道。這意味著它可以在不破壞數據完整性的前提下支持并發的讀寫事務。
- 模式執行和治理（Schema enforcement and governance）：LakeHouse應該有一種可以支持模式執行和演進、支持DW模式的范式（如star/snowflake-schemas）。該系統應該能夠推理數據完整性，并具有健壯的治理和審計機制。
- Schemas：數倉會在所有存儲其上的數據上施加Schema，而數據湖則不會。Lakehouse的架構可以根據應用的需求為絕大多數的數據施加schema，使其標準化。
- BI支持：LakeHouse可以直接在源數據上使用BI工具。這樣可以提高數據新鮮度，減少等待時間，降低必須同時在數據湖和數據倉庫中操作兩個數據副本的成本
- 存儲與計算分離：這意味著存儲和計算使用單獨的集群，因此這些系統能夠支持更多用戶并發和更大數據量。一些現代數據倉庫也具有此屬性。
- 報表以及分析應用的支持：報表和分析應用都可以使用這一存儲架構。Lakehouse里面所保存的數據經過了清理和整合的過程，它可以用來加速分析。同時相比于數倉，它能夠保存更多的數據，數據的時效性也會更高，能顯著提升報表的質量。
- 數據類型擴展：數倉僅可以支持結構化數據，而Lakehouse的結構可以支持更多不同類型的數據，包括文件、視頻、音頻和系統日志。
- 端到端的流式支持：Lakehouse可以支持流式分析，從而能夠滿足實時報表的需求，實時報表在現在越來越多的企業中重要性在逐漸提高。
- 開放性：Lakehouse在其構建中通常會使Iceberg，Hudi，Delta Lake等組件，首先這些組件是開源開放的，其次這些組件采用了Parquet，ORC這樣開放兼容的存儲格式作為下層的數據存儲格式，因此不同的引擎，不同的語言都可以在Lakehouse上進行操作
Lakehouse的概念最早是由Databricks所提出的，而其他的類似的產品有Azure Synapse Analytics。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、Data lakehouse解決了什么問題
這些年來，在許多的公司里，數倉和數據湖一直并存且各自發展著，也沒有遇到過太過嚴重的問題。但是仍有一些領域有值得進步的空間，比如：
- 數據重復性：如果一個組織同時維護了一個數據湖和多個數倉，這無疑會帶來數據冗余。在最好的情況下，這僅僅只會帶來數據處理的不高效，但是在最差的情況下，它會導致數據不一致的情況出現。Data Lakehouse統一了一切，它去除了數據的重復性，真正做到了Single Version of Truth。
- 高存儲成本：數倉和數據湖都是為了降低數據存儲的成本。數倉往往是通過降低冗余，以及整合異構的數據源來做到降低成本。而數據湖則往往使用大數據文件系統（譬如Hadoop HDFS）和Spark在廉價的硬件上存儲計算數據。而最為廉價的方式是結合這些技術來降低成本，這就是現在Lakehouse架構的目標。
- 報表和分析應用之間的差異：報表分析師們通常傾向于使用整合后的數據，比如數倉或是數據集市。而數據科學家則更傾向于同數據湖打交道，使用各種分析技術來處理未經加工的數據。在一個組織內，往往這兩個團隊之間沒有太多的交集，但實際上他們之間的工作又有一定的重復和矛盾。而當使用Data Lakehouse后，兩個團隊可以在同一數據架構上進行工作，避免不必要的重復。
- 數據停滯（Data stagnation）：在數據湖中，數據停滯是一個最為嚴重的問題，如果數據一直無人治理，那將很快變為數據沼澤。我們往往輕易的將數據丟入湖中，但缺乏有效的治理，長此以往，數據的時效性變得越來越難追溯。Lakehouse的引入，對于海量數據進行catalog，能夠更有效地幫助提升分析數據的時效性。
- 潛在不兼容性帶來的風險：數據分析仍是一門興起的技術，新的工具和技術每年仍在不停地出現中。一些技術可能只和數據湖兼容，而另一些則又可能只和數倉兼容。Lakehouse靈活的架構意味著公司可以為未來做兩方面的準備。
5、Data Lakehouse存在的問題
現有的Lakehouse架構仍存在著一些問題，其中最為顯著的是：
- 大一統的架構：Lakehouse大一統的架構有許多的優點，但也會引入一些問題。通常，大一統的架構缺乏靈活性，難于維護，同時難以滿足所有用戶的需求，架構師通常更傾向于使用多模的架構，為不同的場景定制不同的范式。
- 并非現有架構上本質的改進：現在對于Lakehouse是否真的能夠帶來額外的價值仍存在疑問。同時，也有不同的意見 - 將現有的數倉、數據湖結構與合適的工具結合 - 是否會帶來類似的效率呢？
- 技術尚未成熟：Lakehouse技術當前尚未成熟，在達到上文所提的能力之前仍有較長的路要走。
6、從BI到AI
LakeHouse是一種新的數據管理范式，從根本上簡化了企業數據基礎架構，并且有望在機器學習已滲透到每個行業的時代加速創新。過去公司產品或決策中涉及的大多數數據都是來自操作系統的結構化數據，而如今，許多產品都以計算機視覺和語音模型、文本挖掘等形式集成了AI。而為什么要使用LakeHouse而不是數據湖來進行AI？是因為LakeHouse可以提供數據版本控制、治理、安全性和ACID屬性，即使對于非結構化數據也是如此。
當前LakeHouse降低了成本，但它們的性能仍然落后于專門的系統（如數據倉庫），但這些系統需要數年的投入和實際部署。同時用戶可能會偏愛某些工具（BI tools, IDEs, notebooks），因此LakeHouse也需要改善其UX以及與流行工具的連接器，以便更具吸引力。隨著技術的不斷成熟和發展，這些問題將得到解決。隨著時間推移，LakeHouse將縮小這些差距，同時保留服務各種數據應用的更簡單、更具成本效益和更強大的能力的核心屬性。
參考資料
浙公網安備 33010602011771號