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

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

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

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

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

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

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

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

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

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

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

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

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

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

MPP架構(gòu)與內(nèi)存數(shù)據(jù)調(diào)度

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

圖2:MPP與MapReduce框架

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

設(shè)計(jì)良好的緩存框架

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

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

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

圖3:SIMD優(yōu)化

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

考慮開源解決方案

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

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

所有這一切在理論上聽起來不錯(cuò)，但在實(shí)踐中呢？Trip.com的統(tǒng)一內(nèi)部報(bào)告平臺(tái)Artnova提供了一個(gè)很好的例子。

圖4. 以前：業(yè)務(wù)關(guān)鍵工作負(fù)載攝入StarRocks

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

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

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

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

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

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

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