1. 摘要
數倉架構在未來一段時間內會逐漸消亡，會被一種新的Lakehouse架構取代，該架構主要有如下特性
- 基於開放的數據格式，如Parquet；
- 機器學習和數據科學將被作爲頭等公民支持；
- 提供卓越的性能；
Lakehouse可以解決數據倉庫面臨的幾個主要挑戰，如數據陳舊，可靠性，總成本，數據格式不開放和有限場景支持。
2. 數據分析平臺發展
數據倉庫將業務數據庫的數據收集到集中式倉庫來幫助企業領導者獲得分析見解，然後將其用於決策支持和商業智能（BI），倉庫使用寫模式（schema-on-write）寫入數據，對下游消費者進行了優化，此爲第一代數據分析平臺。
慢慢地第一代系統開始面臨若干挑戰，首先是計算與存儲耦合使得擴容成本增加；其次越來越多的數據集是非結構化的，例如視頻，音頻和文本文檔，數據倉庫無法存儲和查詢這些數據。
爲了解決這些問題，引入第二代數據分析平臺，其將所有原始數據導入數據湖：具有文件API的低成本存儲系統，該API以通用且通常是開放的文件格式保存數據，例如Apache Parquet和ORC，可以基於HDFS實現低成本數據湖存儲，數據湖是一種讀模式（schema-on-read）架構，可以靈活地以低成本存儲任何數據。
該架構中的一小部分數據隨後將被ETL到下游數據倉庫以提供最重要的決策支持和BI應用程序。
從2015年起，S3，ADLS，GCS，OSS等雲數據湖開始取代HDFS，雲上的架構與第二代系統中的架構基本相同，雲上有Redshift、Snowflake和ADB等數據倉庫，這種兩層的數據湖+數倉架構在行業中占主導地位（財富500強企業中幾乎都在使用）。但這種架構也面臨了一些挑戰，儘管由於分開的存儲（例如S3）和計算（例如Redshift）而使雲數據湖和倉庫的體系架構表面上便宜，但是對於用戶來說，兩層體系結構卻非常複雜。在第一代平臺中所有數據都從運營數據系統直接ETL到倉庫，而在這種架構中，數據首先被ETL到數據湖，然後又被ELT到數倉，引入額外的複雜性、延遲和故障率，而且企業用例中包括機器學習之類的高級分析，數據湖和倉庫都支持得不理想，具體來說，當前的數據架構通常會遇到如下四個問題：
- 可靠性。保持數據湖和數倉一致是困難且昂貴的，需要對兩個系統之間的ETL作業進行仔細設計，每個ETL步驟還有發生故障或引入錯誤的風險，例如由於數據湖和倉庫引擎之間的細微差別而導致數據質量降低的風險。
- 數據陳舊。與數據湖的數據相比，倉庫中的數據是陳舊的，新數據的加載通常需要幾天的時間。與第一代分析系統相比是個倒退，第一代分析系統中新的運營數據可立即用於查詢。
- 對高級分析的支持有限。企業希望使用數據進行預測，但TensorFlow，PyTorch和XGBoost等機器學習系統都無法在數倉之上工作，與BI查詢提取少量數據不同，這些系統需要使用複雜的非SQL代碼處理大型數據集，而通過ODBC/JDBC讀取此數據效率很低，並且無法直接訪問倉庫內部專有格式，對於這些用例會建議將數據導出到文件中，這進一步增加了複雜性和陳舊性（添加了第三個ETL步驟！），或者用戶可以針對開放格式的數據湖數據運行這些系統，但會失去數據倉庫的豐富管理功能，例如ACID事務，數據版本控制和索引。
- 總成本。除了支付ETL作業費用外，用戶還爲複製到倉庫的數據支付了兩倍的存儲成本，而商業倉庫使用內部專有格式增加了將數據或工作負載遷移到其他系統的成本。
一種被廣泛採用的解決方案是不使用數據湖，將所有數據存儲在內置了計算和存儲分離功能的倉庫中，但這種解決方案可行性有限，因爲其不支持管理視頻/音頻/文本數據或從ML和數據科學工作負載中直接訪問。
隨着越來越多的業務應用開始依賴運營數據和高級分析，Lakehouse架構可以消除數據倉庫中的一些主要挑戰，Lakehouse的時機已經到來。
Lakehouse爲以下關鍵問題提供解決方案：
- 數據湖上可靠的數據管理：Lakehouse需要存儲原始數據，同時支持ETL/ELT流程來提高數據分析質量，而傳統數據湖將半結構化格式數據作爲"一堆文件"進行管理，很難提供一些簡化數據倉庫中ETL/ELT的關鍵管理功能，例如事務、版本回滾以及零拷貝等。一些新型的數據湖框架（如Delta、Hudi、Iceberg）提供了數據湖的事務視圖，並提供了管理功能，減少了ETL步驟，並且分析人員可以高效地查詢原始數據表，這與第一代分析平臺非常類似。
- 支持機器學習和數據科學：ML系統支持直接讀取數據湖格式，很多ML系統採用DataFrames作爲操作數據的抽象，而聲明式DataFrame API可以對ML工作負載中的數據訪問進行查詢優化，可以直接享受在Lakehouse中的許多優化。
- SQL性能：Lakehouse需要在海量Parquet/ORC數據集上提供很好的SQL性能，相比之下經典數倉對SQL進行更徹底的優化（包括使用專有存儲格式）。Lakehouse可以使用多種技術來維護有關Parquet/ORC數據集的輔助數據，並在這些現有格式內優化數據佈局以實現更好的性能。
當前的行業趨勢表明客戶對兩層數據湖+數倉架構並不滿意，首先近年來幾乎所有的數據倉庫都增加了對Parquet和ORC格式的外部表支持，這使數倉用戶可以從相同的SQL引擎查詢數據湖表（通過連接器訪問），但它不會使數據湖表更易於管理，也不會消除倉庫中數據的ETL複雜性、陳舊性和高級分析挑戰。實際上這些連接器的性能通常較差，因爲SQL引擎主要是針對其內部數據格式進行了優化，而僅憑這些分析引擎並不能解決數據湖的所有問題並取代倉庫，數據湖仍然缺乏基本的管理功能（例如ACID事務）和有效的訪問方法（例如與數據倉庫性能匹配的索引）。
3. Lakehouse架構
Lakehouse可定義爲基於低成本，可直接訪問存儲的數據管理系統，該系統還提供傳統的分析型DBMS管理和性能功能，例如ACID事務，數據版本，審計，索引，緩存和查詢優化。因此Lakehouse結合了數據湖和數據倉庫的主要優勢：開放格式的低成本存儲可通過前者的各種系統訪問，而後者則具有強大的管理和優化功能。而核心問題是能否可以有效地結合這些優勢：特別是Lakehouse對直接訪問的支持意味着它們放棄了數據獨立性的某些方面，這一直是關係型DBMS設計的基礎。
Lakehouse特別適合具有單獨計算和存儲的雲環境：不同的計算應用程序可以在完全獨立的計算節點（例如ML的GPU羣集）上按需運行，同時直接訪問相同的存儲數據，但也可以在本地存儲系統（例如HDFS）上實現Lakehouse。
3.1 實現Lakehouse系統
實現Lakehouse的第一個關鍵思想是使用標準文件格式（如Apache Parquet）將數據存儲在低成本的對象存儲（例如Amazon S3）中，並在對象存儲上實現元數據層，其定義哪些對象是表版本一部分。這使系統可以在元數據層實現諸如ACID事務處理或版本控制之類的管理功能，同時將大量數據保留在低成本對象存儲中，並允許客戶端使用標準文件格式直接從該存儲中讀取對象，儘管元數據層增加了管理功能，但不足以實現良好的SQL性能，數據倉庫使用多種技術獲得很好的性能，例如將熱數據存儲在SSD等高速設備、維護統計信息、構建有效的訪問方法（例如索引）以及優化數據格式和計算引擎。基於現有存儲格式的Lakehouse中無法變更格式，但是也可以實現在保持數據文件不變情況下的其他優化，包括緩存、輔助數據結構（例如索引和統計信息）和數據佈局優化。
Lakehouse既可以加快高級分析負載，又可以爲其提供更好的數據管理功能。許多ML庫（例如TensorFlow和Spark MLlib）已經可以讀取數據湖文件格式（如Parquet）。因此將它們與Lakehouse集成的最簡單方法是查詢元數據層，以確定哪些Parquet文件屬於表，然後將它們傳遞給ML庫。
3.2 用於數據管理的元數據層
Lakehouses的第一個組件是元數據層，其可以實現ACID事務和其他管理功能。諸如S3或HDFS之類的數據湖存儲系統僅提供了低級的對象存儲或文件系統接口，在這些接口中，即使是簡單的操作（如更新跨多個文件的表）也不是原子的，這個問題使得一些組織開始設計更豐富的數據管理層，從Apache Hive ACID開始，其使用OLTP DBMS跟蹤給定表版本中哪些數據文件是Hive表的一部分，並允許操作以事務方式更新此集合。近年來一些新系統提供了更多功能和改進的可伸縮性，如2016年Databricks開發的Delta Lake，其將有關哪些對象是表中一部分的信息存儲在數據湖中，作爲Parquet格式的事務日誌，使其能夠擴展到每張表數十億個對象；Netflix的Apache Iceberg也使用類似的設計，並支持Parquet和ORC存儲；Apache Hudi始於Uber也類似，儘管它不支持併發寫入（正在支持中），該系統側重於簡化流式數據入數據湖。
這些系統的經驗表明它們可以提供與原始Parquet/ORC數據湖類似或更好的性能，同時還增加了非常有用的管理功能，例如事務處理，零拷貝和時間旅行。元數據層對數據質量非常重要，例如可以對Schema進行校驗，使其不破壞數據質量，另外元數據層可以實現諸如訪問控制和審覈日誌記錄之類的治理功能，例如元數據層可以在授予客戶端憑據以從雲對象存儲讀取表中的原始數據之前，檢查是否允許客戶端訪問表，並且記錄所有訪問行爲。
未來方向和替代設計。由於數據湖的元數據層非常新，因此存在許多懸而未決的問題和替代設計。例如Delta Lake設計爲將事務日誌存儲在它運行的同一對象存儲中（例如S3）以簡化管理（消除了運行單獨存儲系統的需要）並提供高可用性和高讀取帶寬，但對象存儲的高延遲限制了它可以支持的每秒事務處理速率，在某些情況下將元數據使用更快的存儲系統的設計可能更可取。同樣Delta Lake，Iceberg和Hudi僅支持單表事務，但也可以擴展以支持跨表事務，優化事務日誌的格式和管理對象的大小也是未解決的問題。
3.3 Lakehouse中的SQL性能
Lakehouse方案的最大技術問題可能是如何提供最新的SQL性能，同時又放棄了傳統DBMS設計中很大一部分的數據獨立性，有很多解決方案，例如可以在對象存儲上添加一個緩存層，以及是否可以更改數據對象存儲格式而不使用現有的標準（例如Parquet和ORC（不斷改進這些格式的新設計不斷湧現））。無論採用何種設計，核心挑戰在於數據存儲格式已成爲系統公共API的一部分以允許快速直接訪問，這與傳統DBMS不同。
我們提出了幾種技術可以在Lakehouse中優化SQL性能，並且與數據格式無關，因此可以將其與現有格式或未來數據格式一起使用，這些與格式無關的優化大致如下：
- 緩存：使用元數據層時，Lakehouse系統可以安全地將雲對象存儲中的文件緩存在處理節點上更快的存儲設備（例如SSD和RAM）上，正在運行的事務可以確定讀取緩存的文件是否還有效，此外緩存可以採用轉碼格式，其對於查詢引擎運行效率更高，例如在Databricks的緩存會解壓了部分它加載的Parquet數據。
- 輔助數據：即使Lakehouse爲支持直接I/O訪問需要開放表存儲格式（如Parquet），它也可以維護其他數據來幫助優化查詢，如在Parquet文件中維護表中每個數據文件的列最小-最大統計信息，有助於跳過數據，以及基於Bloom過濾器的索引。可以實現各種各樣的輔助數據結構，類似於爲"原始"數據建立索引。
- 數據佈局：數據佈局在訪問性能中起着重要作用。Lakehouse系統也可以優化多個佈局決策，最明顯的是記錄排序：哪些記錄聚集在一起可以最容易被批量讀取，Delta中使用Z-Order，Hudi中使用基於哪些列進行Clustering。
對於分析系統中的典型訪問模式，這三個優化可以很好地協同工作。典型的工作負載中大多數查詢傾向於集中在數據的"熱"子集上，Lakehouse可以使用與數據倉庫相同的優化數據結構對其進行緩存，以提供相同的查詢性能。 對於雲對象存儲中的"冷"數據，性能的主要決定於每個查詢讀取的數據量，在該情況下數據佈局優化（將共同訪問的數據聚類）和輔助數據結構（如區域圖，使引擎快速確定要讀取的數據文件範圍）的組合可以使Lakehouse系統與數倉一樣最小化I/O開銷，儘管使用標準的開放文件格式（相比於數倉內置文件格式）。
3.4 高級分析高效訪問
高級分析庫通常不是使用SQL命令編寫，其需要訪問大量數據，如何設計數據訪問層以最大程度地提高運行在頂部的代碼的靈活性，仍然可以從Lakehouse的優化中受益。
機器學習API迅速發展，但是一些數據訪問API（例如TensorFlow的tf.data）沒有嘗試將查詢語義推入底層存儲系統，一些API還專注於CPU到GPU的傳輸和GPU計算，這在數據倉庫中並未引起太多關注。
我們需要標準ML接口以使數據科學家能夠充分利用Lakehouse（甚至數據倉庫）中強大的數據管理功能，如事務，數據版本控制和時間旅行等。
4. 研究問題和啓示
Lakehouse還提出了其他一些研究問題，功能日益豐富的數據湖的行業趨勢也對數據系統研究的其他領域產生了影響。
- 還有其他方法可以實現Lakehouse目標嗎？ 可以想像其他方法來實現Lakehouse的主要目標，例如構建用於數據倉庫的大規模並行服務層，可以支持對高級分析工作負載的並行讀取，但是與工作負載直接訪問對象存儲庫相比成本將更高，難以管理，並且性能可能會降低。這種服務層並未得到廣泛應用，例如Hive LLAP。除了在性能、可用性、成本和鎖定方面的挑戰外，還有一些重要的管理原因，如企業可能更喜歡將數據保留爲開放格式。隨着對數據管理的法規要求不斷提高，組織可能需要在短時間內搜索舊數據集，刪除各種數據或更改其數據處理基礎結構，並且採用開放格式進行標準化意味着它們將始終可以直接訪問數據，軟件行業的長期趨勢一直是開放數據格式，企業數據應該繼續保持這種趨勢。
- 什麼是正確的存儲格式和訪問API？Lakehouse的訪問接口包括原始存儲格式以及直接讀取此格式的客戶端庫（例如使用TensorFlow讀取時）以及高級SQL接口。有很多不同的方法可以在這些層上放置豐富的功能，例如通過要求讀者執行更復雜的“可編程”解碼邏輯，可以爲系統提供更大的靈活性的存儲方案。有待觀察哪種存儲格式、元數據層設計和訪問API的組合效果最佳。
- Lakehouse如何影響其他數據管理研究和趨勢？數據湖的流行以及對豐富管理接口的使用不斷增加，無論它們是元數據層還是完整的Lakehouse設計，都對數據管理研究的其他領域產生了影響。Polystore旨在解決跨不同存儲引擎查詢數據這一難題，該問題在企業中持續存在，但是在雲數據湖中以開放格式提供的數據比例越來越高，也可以通過直接針對雲對象存儲運行許多polystore查詢，即使基礎數據文件是邏輯上分開的Lakehouse的一部分。還可以在Lakehouse上設計數據集成和清理工具，並可以快速並行訪問所有數據，這可以開啓大型聯接和聚類等新算法。可以將HTAP系統構建爲Lakehouse前面的"附加"層，通過使用其事務管理API將數據直接歸檔到Lakehouse系統中，Lakehouse將能夠查詢數據的一致快照。ML的數據管理也會變得更加簡單和強大，如今組織正在構建各種可重新實現標準DBMS功能的，特定於ML的數據版本控制和特徵存儲系統，使用帶有內置DBMS管理功能的數據湖來實現特徵存儲功能可能會更簡單。無服務器引擎之類的雲原生DBMS設計將需要與更豐富的元數據層集成，而不是直接掃描數據湖中的原始文件，可以能夠提高查詢性能。最後Lakehouse的設計易於分佈式協作，因爲可以從對象存儲庫直接訪問所有數據集，這使得共享數據變得很簡單。
5. 結論
在開放的數據湖文件格式上實現數據倉庫功能的統一數據平臺體系結構可以爲當今的數據倉庫系統提供具有競爭力的性能，並有助於應對數據倉庫用戶面臨的許多挑戰，儘管限制數據倉庫的存儲層以標準格式直接訪問看起來似乎是一個重大限制，但諸如熱數據緩存和冷數據數據佈局優化之類的優化可以使Lakehouse獲得很不錯的性能，另外鑑於數據湖中已有大量數據，並且有機會大大簡化企業數據架構，行業很可能會向Lakehouse架構逐步過渡。