### 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架構逐步