一種新穎的方法將數據湖倉分析的所有優勢與數據倉庫的高性能完美結合。

譯自How to Get Data Warehouse Performance on the Data Lakehouse，作者 Sida Shen 是CelerData的產品營銷經理。他擁有機器學習和大數據基礎設施背景的工程師，負責公司的市場研究，并與分析行業的工程師和開發人員密切合作，解決實時分析的相關挑戰。

數據湖倉庫架構的普及性持續增加，這一點毫不令人驚訝。它們無縫集成數據湖和數據倉庫的優點的潛力，承諾為數據處理和分析帶來變革性的體驗。然而，這種方法也存在缺陷。本文檢驗了這些挑戰，如查詢性能和高成本，并確定了幫助數據湖倉庫解決它們的新技術。

數據湖倉庫分析的現狀

數據湖倉庫用其靈活性、可擴展性和成本效益的承諾吸引了無數企業。然而，事實是，當前支持這些數據湖倉庫的查詢引擎在大規模低延遲或高并發分析方面未能提供查詢性能。目前，這些數據湖倉庫的查詢引擎呈兩極分化狀態。一方面，我們有針對提取、轉換和加載(ETL)工作流進行優化的引擎，側重于階段性操作。另一方面，我們看到引擎不利用現代優化技術，如單指令多數據(SIMD)指令集，這對利用現代 CPU 的全部計算能力至關重要。

這種固有的性能限制促使大多數用戶將數據從數據湖倉庫復制到專有數據倉庫，以實現他們所需的查詢性能。但這是一種昂貴的變通方法。

成本#1：數據攝入昂貴

圖1:常見的數據湖流水線

一開始，向數據倉庫攝入數據看似一個簡單的過程，但遠非如此。這個過程需要將數據轉換為倉庫的特定格式，這項任務需要大量的硬件資源。此外，這種復制導致數據存儲的冗余——這在成本和空間方面是一個昂貴的命題。

不僅僅是物理資源，所需的人力也同樣重要?？此茊握{乏味的任務，如調整兩個系統之間的數據類型，都可能耗盡資源。此外，這個數據攝入過程無意中引入了延遲，削弱了數據的新鮮度。

成本#2：數據攝入管道對數據治理不利

數據的完整性和準確性對任何企業來說都是至關重要的。諷刺的是，本應技術上增強其效用的向另一個數據倉庫攝入數據的行為本身，對數據治理構成了嚴峻的挑戰。您如何確保所有副本都得到一致更新？您如何防止不同副本之間的差異？您又如何在維護強大的數據治理的同時做到這一點？這些不僅僅是理論問題；它們是嚴峻的技術挑戰，需要重大的工程努力，如果做錯了，有可能影響您基于數據的決策的真實性。

一種現代方法：無流水線的數據湖倉庫

數據湖倉庫的查詢性能固有挑戰和作為變通方法的專有數據倉庫的使用，正在推動越來越多的企業尋求更高效的替代方案。一種流行的方法是采用無攝入的湖倉架構。下面是它的工作原理。

MPP架構與內存數據調度

數據湖查詢引擎采用數據調度來實現可擴展性能，特別是在復雜的聯接操作和聚合方面。然而，許多數據湖倉庫引擎最初設計用于數據湖的多樣且可負擔的數據存儲，側重于數據轉換和即席查詢，將中間結果持久化到磁盤。雖然適用于批處理作業，但這種方法妨礙了湖倉庫不斷發展的工作負載，特別是實時的面向客戶的查詢。此外，基于磁盤的調度引入了延遲，阻礙了查詢性能，阻礙了即時洞察。

圖2:MPP與MapReduce框架

為了應對這一挑戰，并直接在數據湖倉庫上運行低延遲查詢，擁抱裝備了內存數據調度的大規模并行處理(MPP)查詢引擎是一個明智之舉。與傳統方法不同，內存調度完全繞過磁盤持久化。這確保查詢執行流暢，幾乎沒有等待時間。這種操作不僅高效，而且對于實現低查詢延遲至關重要，使得從數據湖倉庫獲得即時洞察成為可能。

設計良好的緩存框架

優化數據湖倉庫查詢的主要障礙之一在于從遠程存儲位置檢索數據的高昂開銷。數據湖倉庫中數據的巨大規模和分布式特性使每次掃描都成為一個資源密集型任務。一個設計良好的內置數據緩存系統是必要的。緩存系統應采用分層緩存機制，不僅利用基于磁盤的緩存，還利用基于內存的緩存，減少從遠程存儲訪問數據，從而減少延遲。

此外，此緩存框架的效用取決于它與查詢引擎的集成。它不應該是一個獨立的需要單獨部署的模塊——這可能會引入復雜性和潛在的性能瓶頸——而應該是本機內嵌于系統中的。這種內聚架構簡化了操作，并確保緩存以峰值效率運行，從而為數據檢索和查詢執行提供盡可能好的性能。

進一步的系統級優化

圖3:SIMD優化

像SIMD這樣的系統級優化在進一步提高數據湖倉庫性能方面發揮著不可或缺的作用。例如，SIMD增強使多個數據點能夠并行處理統一指令。當與數據湖文件格式(如Parquet或優化的列式(ORC))中的列存儲結合使用時，它允許以更大的批次處理數據，顯著提高了聯機分析處理(OLAP)查詢的性能，特別是涉及連接操作的查詢。

考慮開源解決方案

最后，優先考慮開源解決方案。如果要最大限度地利用數據湖倉庫架構的好處，擁抱開源至關重要。數據湖倉庫的固有開放性不僅體現在它支持的格式上；它提供的靈活性是它的關鍵優勢之一。這種模塊化意味著組件(包括查詢引擎)可以輕松互換，使您能夠保持敏捷，并隨著數據分析不斷發展的環境輕松適應。

無流水線數據湖倉庫實踐：Trip.com的Artnova平臺

所有這一切在理論上聽起來不錯，但在實踐中呢？Trip.com的統一內部報告平臺Artnova提供了一個很好的例子。

圖4. 以前：業務關鍵工作負載攝入StarRocks

最初，Artnova使用Apache Hive作為數據湖，使用Trino作為查詢引擎。然而，由于大量的數據加上低延遲的需求以及處理大量并發請求的能力，Trino在某些用例下無法滿足要求。Trip.com不得不將數據復制并轉移到其高性能數據倉庫StarRocks中。雖然這種策略解決了一些性能問題，但也引入了更多問題:

• 盡管攝入相對較快，但數據新鮮度落后，影響查詢的靈活性和及時性。
• 由于額外的攝入任務以及表模式和索引設計要求，在數據流水線中增加了復雜性。

將數據復制到另一個數據倉庫很復雜且昂貴。攜程最初僅將最關鍵的業務工作負載移動到StarRocks，但最終決定進行架構上的全面改造并擴大StarRocks的使用。

圖5. 之后：StarRocks作為統一查詢引擎

根據Trip.com進行的性能測試，在相同數據上使用StarRocks作為查詢引擎比Trino快7.4倍。在StarRocks內置的物化視圖的加速下，對業務關鍵用例的性能提升非常顯著。

使用無流水線的數據湖倉庫

數據湖倉庫的演變重塑了數據分析，結合了數據湖和數據倉庫的優勢。盡管它具有變革性的潛力，但諸如高效查詢性能等挑戰仍然存在。創新解決方案如MPP查詢執行、緩存框架和系統級優化可能彌合這些差距，并使企業能夠享受湖倉庫的所有好處，而無需承受任何缺點。