Lakehouse: 統一數據倉庫和高級分析的新一代開放平臺

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架構逐步過渡。