Hudi 演變 | LakeHouse 還是 Warehouse?(2/2)

這篇博文包括 Onehouse 首席執(zhí)行官 Vinoth Chandar 于 2022 年 3 月在奧斯汀數(shù)據(jù)委員會(huì)發(fā)表的重要演講的后半部分。本文是第 2 部分，比較了架構(gòu)的功能和性價(jià)比特征。最后，它描述了一個(gè)面向未來的、湖倉一體的架構(gòu)。

對(duì)于核心讀寫：湖倉一體和倉庫都可以支持更新、刪除、事務(wù)、統(tǒng)計(jì)、排序、批量加載、審計(jì)、回滾、時(shí)間旅行這些基本功能。倉庫具有更完整的關(guān)系或數(shù)據(jù)庫功能，例如多表事務(wù)、聚簇等。在Lakehouse中大多數(shù)技術(shù)都是以庫的形式提供。例如在 Hudi 中從一開始就支持主鍵，因?yàn)樵?Uber 時(shí)，唯一鍵約束對(duì)我們來說是一個(gè)非常困難的要求。

Lakehouse 的設(shè)計(jì)選擇更多地反映了更大規(guī)模的數(shù)據(jù)需求

有些能力是專有的，有些是開放的，然后有一些圍繞流式更新和所有這些東西的特定設(shè)計(jì)選擇。通常會(huì)看到湖倉一體設(shè)計(jì)選擇更多地反映了更大規(guī)模的數(shù)據(jù)需求，而倉庫則貼近它們開始時(shí)使用的數(shù)據(jù)庫源。

不僅僅是高效寫入數(shù)據(jù)，還需要優(yōu)化表的核心服務(wù)以確保真正良好的性能。可以看到例如聚類或排序以獲得良好的性能，空間回收。當(dāng)數(shù)據(jù)變得臟時(shí)，如何管理它？在它們的自動(dòng)化管理方式方面，或者是否需要將其中一些庫放在Lakehouse上運(yùn)行，這兩者之間存在巨大差異。像文件大小這類信息在數(shù)倉中是隱藏的文件，但它們?nèi)匀槐┞对诤}一體中，如果不能很好地管理它們可能會(huì)影響性能。一些框架具有自動(dòng)強(qiáng)制執(zhí)行功能，有些是DIY的。在 Hudi 中也有這些功能，但仍然需要自我管理。Hudi 可以進(jìn)行聚簇，但需要自己運(yùn)行聚簇作業(yè)。而如果只是使用托管服務(wù)，這些都是在內(nèi)部管理。數(shù)倉中的緩存是透明加速的，Lakehouse可使用或不用。

數(shù)據(jù)庫更改數(shù)據(jù)捕獲 （CDC）、引入日志事件等內(nèi)容。許多使用云（現(xiàn)代數(shù)據(jù)棧或云數(shù)據(jù)倉庫）的人都擁有托管的零操作攝取服務(wù)，他們更喜歡使用這些服務(wù)來獲取數(shù)據(jù)并構(gòu)建表。但是在湖上開發(fā)者使用Debezium或框架并與Hudi庫捆綁在一起以構(gòu)建一個(gè)端到端的系統(tǒng)。因此如果想建造一個(gè)Lakehouse并投入使用，這確實(shí)需要一些時(shí)間，必須通過觀察所有這些不同的問題并找到解決方案，這提供了極大的靈活性，但需要一些時(shí)間才能將其付諸實(shí)施。

這是一個(gè)非常有趣的話題：價(jià)格/性能。首先考慮不同工作負(fù)載，當(dāng)談?wù)撔詢r(jià)比時(shí)會(huì)看到以 TPC-DS 的基準(zhǔn)測(cè)試報(bào)告。

實(shí)際上至少需要有四種不同類型的工作負(fù)載，并且并非所有工作負(fù)載都需要高級(jí)引擎，例如 SQL 優(yōu)化不一定能幫助進(jìn)行數(shù)據(jù)攝取，因?yàn)榉浅Ｊ?I/O 限制。不同工作負(fù)載具有不同的性價(jià)比特征，在湖上仍然需要做大量工作來管理表，可以選擇為每個(gè)用例選擇合適的引擎。因此對(duì)于某些人來說也許會(huì)選擇開源版本，而對(duì)于某些人來說會(huì)選擇云產(chǎn)商的產(chǎn)品。

對(duì)于 TPC-DS ，我們將做一些不同的事情并嘗試剖析查詢。首先是Lakehouse或倉庫中的性能差異從何而來？一個(gè)是獲取元數(shù)據(jù)。可以查看表元數(shù)據(jù)、架構(gòu)、統(tǒng)計(jì)信息以及了解如何規(guī)劃查詢所需的任何內(nèi)容。目前Lakehouse要么存儲(chǔ)在像 Hive 這樣的元存儲(chǔ)中，要么存儲(chǔ)在存儲(chǔ)有關(guān)表的統(tǒng)計(jì)信息的文件中。然后倉庫主要使用數(shù)據(jù)庫存儲(chǔ)，當(dāng)數(shù)據(jù)量很大時(shí)數(shù)據(jù)庫在很多方面都優(yōu)于文件。因此Lakehouse現(xiàn)在還處于早期階段，必須在此基礎(chǔ)上發(fā)展Lakehouse的統(tǒng)計(jì)管理。查詢計(jì)劃很大程度上取決于引擎和供應(yīng)商。查詢優(yōu)化是一個(gè)非常困難的問題，隨著花費(fèi)的時(shí)間增加，它會(huì)變得更好，需要一個(gè)更成熟的優(yōu)化器，這是一個(gè)不斷發(fā)展的格局。有了查詢計(jì)劃進(jìn)行執(zhí)行時(shí)，Lakehouse采用開放的文件格式，而數(shù)倉使用封閉的文件格式，但很多性能差異來自文件格式本身，而更像是運(yùn)行時(shí)的差異 - 如果做一個(gè)分組查詢，假設(shè)必須對(duì)數(shù)據(jù)進(jìn)行洗牌，引擎是怎么做到的？即使在Lakehouse引擎內(nèi)部，也存在巨大的差異。

像 Spark 會(huì)更有彈性地洗牌、重試；但像 Presto 希望保持交互式查詢性能和更低的延遲。因此它可能會(huì)失敗，并且在洗牌數(shù)據(jù)和響應(yīng)查詢時(shí)會(huì)做出不同的選擇。TPC-DS 固然很好，但更需要的是運(yùn)行自身的工作負(fù)載，當(dāng)運(yùn)行工作負(fù)載時(shí)可能發(fā)現(xiàn)差距不是那么大，建議使用前五個(gè)查詢或類似的查詢，然后進(jìn)行分析。

在基本的 EC2 成本之上，不同的引擎定價(jià)也不同。假設(shè)引擎收取 2 倍的費(fèi)用，但完成該查詢的速度比凈值快 3 倍就會(huì)獲得性價(jià)比優(yōu)勢(shì)。但是都需要快嗎？例如因?yàn)榫彺嬉卜浅？欤鼈冃枰ㄥX。如果在某些情況下可以負(fù)擔(dān)得起較慢的速度，那么它也可以更便宜。

對(duì)自身的工作負(fù)載進(jìn)行基準(zhǔn)測(cè)試

最快并不是唯一的。還要看看數(shù)據(jù)倉庫的定價(jià)：有些是按查詢定價(jià)的，有些是針對(duì)不同虛擬實(shí)例類型的定價(jià)。因此主要還是對(duì)自身的工作負(fù)載進(jìn)行基準(zhǔn)測(cè)試。

ETL 工作負(fù)載在很多時(shí)候并沒有得到太多關(guān)注——盡管很多人在它們上花費(fèi)了大量時(shí)間。實(shí)際上有一個(gè)用于數(shù)據(jù)集成的基準(zhǔn)，TPC-DI，但很少看到有人報(bào)告任何關(guān)于它的內(nèi)容。至少根據(jù)我們的經(jīng)驗(yàn)，如果看右邊的模式，有一個(gè)事實(shí)表、一個(gè)事件表和一些正在更新的維度表。可以看到更新模式確實(shí)非常不同，所有這些工作負(fù)載不都是一樣的，因此我們需要更好的標(biāo)準(zhǔn)化。

數(shù)據(jù)優(yōu)化確實(shí)很重要。正如我們所看到的關(guān)于聚簇如何提高性能的研究。一個(gè)來自 Hudi，一個(gè)來自 AWS，一個(gè)來自我們自己的博客和開源。可以仔細(xì)控制數(shù)據(jù)布局，但是如何在數(shù)百個(gè)表中做到這一點(diǎn)而不會(huì)產(chǎn)生副作用呢？如何通過數(shù)據(jù)布局控制進(jìn)行成本和全局優(yōu)化？這些都是非常開放的問題，很多人今天不得不手動(dòng)調(diào)整并花費(fèi)大量時(shí)間從這些技術(shù)中榨取價(jià)值。

有了Lakehouse，相對(duì)而言隨著規(guī)模的擴(kuò)大會(huì)更有性價(jià)比

總結(jié)一下：

• ? 開放。數(shù)據(jù)倉庫通常是封閉的；Lakehouse是開放（但條件適用）。

• ? 使用案例。數(shù)據(jù)倉庫是為 BI 設(shè)計(jì)的；數(shù)據(jù)湖倉一體具有更好的數(shù)據(jù)科學(xué)、分析和 ML/AI 支持。

• ? 操作。數(shù)據(jù)倉庫往往是完全托管的；對(duì)于數(shù)據(jù)湖倉一體來說，可以DIY，更難管理。

• ? 費(fèi)用。使用數(shù)據(jù)倉庫時(shí)，費(fèi)用會(huì)隨著規(guī)模的擴(kuò)大而增加；有了Lakehouse，相對(duì)而言隨著規(guī)模的擴(kuò)大會(huì)更有性價(jià)比。

人們什么時(shí)候會(huì)采用Lakehouse？

開始通常只需復(fù)制運(yùn)營(yíng)數(shù)據(jù)，然后配置儀表盤。然后即使數(shù)據(jù)大小略有增長(zhǎng)，也可以在倉庫上執(zhí)行一些 ETL。最終要么遇到成本限制，要么公司足夠大，需要關(guān)心開放性、開放格式，以及前面討論的內(nèi)容。使用Lakehouse，然后開始編寫一些 ETL，這些 ETL 需要從倉庫中提供一些數(shù)據(jù)。還可以復(fù)制從倉庫卸載的任何 ETL，同時(shí)也開始復(fù)制數(shù)據(jù)，數(shù)據(jù)沒有一個(gè)單一的事實(shí)來源。Lakehouse必須與外部系統(tǒng)能互操作，即使是倉庫。所有引擎中應(yīng)該能夠以橫切方式訪問該數(shù)據(jù)。對(duì)于給定的引擎，通常可以在開源之間進(jìn)行選擇；供應(yīng)商提供的托管服務(wù)；和/或云提供商產(chǎn)品。

將數(shù)據(jù)保存在湖上

這里所說的“在湖上”是指開放數(shù)據(jù)格式。供應(yīng)商起起落落，但數(shù)據(jù)就在那里。在過去的五年中以開放格式將數(shù)據(jù)庫變更或所有原始運(yùn)營(yíng)數(shù)據(jù)直接復(fù)制到湖倉一體上，可以為未來做好準(zhǔn)備。因?yàn)檫@些通常是最龐大的數(shù)據(jù)集。

以開放格式將數(shù)據(jù)庫變更或所有原始運(yùn)營(yíng)數(shù)據(jù)直接復(fù)制到 Lakehouse 上，為未來做好準(zhǔn)備

即使在倉庫中，通常影響成本的也是第一層的原始 ETL，即將其放入倉庫，然后運(yùn)行 dbt 來獲取表。

因此使用Lakehouse可以很好地做到這一點(diǎn)，而且總是可以重新計(jì)算任何東西，可以切換查詢引擎，可以重新計(jì)算，在這個(gè)架構(gòu)中可以獲得非常大的靈活性。

最重要的是：它現(xiàn)在提供了一個(gè)單一的事實(shí)來源，這意味著相同的數(shù)據(jù)可以輸入到BI和數(shù)據(jù)科學(xué)團(tuán)隊(duì)中。

在數(shù)據(jù)湖上管理

我們可以盡可能地在Lakehouse上管理很多東西，因?yàn)樗恍枰呒?jí)計(jì)算。其中許多管理服務(wù)更多地受 IO 約束或依賴于外部交互。我們看到了充分利用可互操作Lakehouse的三個(gè)最佳實(shí)踐：

• ? 將大批量作業(yè)保留在Lakehouse中。在原始云存儲(chǔ)上運(yùn)行掃描。

• ? 在方便的地方處理小型 ETL 作業(yè)。這些可以在Lakehouse或倉庫上運(yùn)行。

• ? 更傾向于增量更新。更多地轉(zhuǎn)向增量模型。

所有這些都提供了性價(jià)比的選擇，可以擁有具有成本效益的 ETL - 大大降低成本，而不會(huì)在重要的地方損失性能。

當(dāng)一切都完成后看起來像這樣。對(duì)于Lakehouse，它是開放的并具有所有的互操作性，可以以一種經(jīng)濟(jì)高效的方式編寫ETL，如果能夠快速將數(shù)據(jù)（甚至是 ETL 和 ETL 數(shù)據(jù)）放入倉庫或直接查詢，將獲得非常好的 BI 和報(bào)告性能。可以輕松探索 ML 或流式處理等方法。許多這些新興領(lǐng)域可以很好地整合，因?yàn)樗瑯邮且环N開放格式，生態(tài)系統(tǒng)可以自行發(fā)展，而不受制于供應(yīng)商。當(dāng)然這已被證明可以支持?jǐn)?shù)據(jù)科學(xué)和工程。

推薦閱讀

LakeHouse 還是 Warehouse？(1/2)

通用數(shù)據(jù)湖倉一體架構(gòu)正當(dāng)時(shí)

Apache Hudi從零到一：深入研究讀取流程和查詢類型（二）

回顧 2023：Hudi 的重點(diǎn)新功能一覽

Apache Hudi從零到一：存儲(chǔ)格式初探（一）