一種新穎的方法將數(shù)據(jù)湖倉分析的所有優(yōu)勢與數(shù)據(jù)倉庫的高性能完美結合。

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

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

數(shù)據(jù)湖倉庫分析的現(xiàn)狀

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

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

成本#1：數(shù)據(jù)攝入昂貴

圖1:常見的數(shù)據(jù)湖流水線

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

不僅僅是物理資源，所需的人力也同樣重要。看似單調乏味的任務，如調整兩個系統(tǒng)之間的數(shù)據(jù)類型，都可能耗盡資源。此外，這個數(shù)據(jù)攝入過程無意中引入了延遲，削弱了數(shù)據(jù)的新鮮度。

成本#2：數(shù)據(jù)攝入管道對數(shù)據(jù)治理不利

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

一種現(xiàn)代方法：無流水線的數(shù)據(jù)湖倉庫

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

MPP架構與內存數(shù)據(jù)調度

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

圖2:MPP與MapReduce框架

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

設計良好的緩存框架

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

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

進一步的系統(tǒng)級優(yōu)化

圖3:SIMD優(yōu)化

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

考慮開源解決方案

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

無流水線數(shù)據(jù)湖倉庫實踐：Trip.com的Artnova平臺

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

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

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

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

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

圖5. 之后：StarRocks作為統(tǒng)一查詢引擎

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

使用無流水線的數(shù)據(jù)湖倉庫

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