1. 動(dòng)機(jī)

Lakehouse最早由Databricks公司提出，其可作為低成本、直接訪問云存儲(chǔ)并提供傳統(tǒng)DBMS管系統(tǒng)性能和ACID事務(wù)、版本、審計(jì)、索引、緩存、查詢優(yōu)化的數(shù)據(jù)管理系統(tǒng)，Lakehouse結(jié)合數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫的優(yōu)點(diǎn)：包括數(shù)據(jù)湖的低成本存儲(chǔ)和開放數(shù)據(jù)格式訪問，數(shù)據(jù)倉(cāng)庫強(qiáng)大的管理和優(yōu)化能力。Delta Lake，Apache Hudi和Apache Iceberg是三種構(gòu)建Lakehouse的技術(shù)。

與此同時(shí)，Pulsar提供了一系列特性：包括分層存儲(chǔ)、流式卸載、列式卸載等，讓其成為一個(gè)可以統(tǒng)一批和事件流的存儲(chǔ)層。特別是分層存儲(chǔ)的特性，然Pulsar成為一個(gè)輕量級(jí)數(shù)據(jù)湖，但是Pulsar還是缺乏一些性能優(yōu)化，比如索引，數(shù)據(jù)版本（在傳統(tǒng)DBMS管理系統(tǒng)中非常常見），引入列式卸載程序的目的是為了縮小性能差距，但是還不夠。

本提議嘗試將Apache Pulsar作為L(zhǎng)akehouse，該提案僅提供頂層設(shè)計(jì)，詳細(xì)設(shè)計(jì)和實(shí)現(xiàn)在后面的子提議中解決；

2. 分析

本部分將分析構(gòu)建Lakehouse需要的關(guān)鍵特性，然后分析Pulsar是否滿足要求以及識(shí)別還有哪些差距。

Lakehouse有如下關(guān)鍵特性：

• 事務(wù)支持：企業(yè)級(jí)Lakehouse中很多數(shù)據(jù)pipeliine會(huì)并發(fā)讀寫數(shù)據(jù)，支持ACID事務(wù)可以保證并發(fā)讀寫的一致性，特別是使用SQL；Delta Lake，Iceberg，Hudi三個(gè)數(shù)據(jù)湖框架都基于低成本的對(duì)象存儲(chǔ)實(shí)現(xiàn)了事務(wù)層，都支持事務(wù)。Pulsar在2.7.0版本后引入了事務(wù)支持，并且支持跨topic的事務(wù)；
• Schema約束和治理：Lakehouse需要支持Schema的約束和演進(jìn)，支持?jǐn)?shù)倉(cāng)型Schema范式，如星型/雪花型Schema，另外系統(tǒng)應(yīng)該能夠推理數(shù)據(jù)完整性，并且應(yīng)該具有健壯的治理和審核機(jī)制，上述三個(gè)系統(tǒng)都有該能力。Pulsar有內(nèi)置的Schema注冊(cè)服務(wù)，它滿足Schema約束和治理的基本要求，但是可能仍有一些地方需要改進(jìn)。
• BI支持：Lakehouses可以直接在源數(shù)據(jù)上使用BI工具，這樣可以減少陳舊性，提高新鮮度，減少等待時(shí)間，并降低必須同時(shí)在數(shù)據(jù)湖和倉(cāng)庫中操作兩個(gè)數(shù)據(jù)副本的成本。三個(gè)數(shù)據(jù)湖框架與Apache Spark的集成非常好，同時(shí)可以允許Redshift，Presto/Athena查詢?cè)磾?shù)據(jù)，Hudi社區(qū)也已經(jīng)完成了對(duì)多引擎如Flink的支持。Pulsar暴露了分層存儲(chǔ)中的段以供直接訪問，這樣可以與流行的數(shù)據(jù)處理引擎緊密集成。 但是Pulsar中的分層存儲(chǔ)本身在服務(wù)BI工作負(fù)載方面仍然存在性能差距，我們將在該提案中解決這些差距。
• 存儲(chǔ)與計(jì)算分離：這意味著存儲(chǔ)和計(jì)算使用單獨(dú)的集群，因此這些系統(tǒng)可以單獨(dú)水平無限擴(kuò)容。三個(gè)框均支持存儲(chǔ)與計(jì)算分離。Pulsar使用了存儲(chǔ)與計(jì)算分離的多層體系結(jié)構(gòu)部署。
• 開放性：使用開放和標(biāo)準(zhǔn)化的數(shù)據(jù)格式，如Parquet，并且它們提供了API，因此各種工具和引擎（包括機(jī)器學(xué)習(xí)和Python / R庫）可以"直接"有效地訪問數(shù)據(jù)，三個(gè)框架支持Parquet格式，Iceberg還支持ORC格式，對(duì)于ORC格式Hudi社區(qū)正在支持中。Pulsar還不支持任何開放格式，列存卸載支持Parquet格式。
• 支持從非結(jié)構(gòu)化數(shù)據(jù)到結(jié)構(gòu)化數(shù)據(jù)的多種數(shù)據(jù)類型：Lakehouse可用于存儲(chǔ)，優(yōu)化，分析和訪問許多新數(shù)據(jù)應(yīng)用程序所需的數(shù)據(jù)類型，包括圖像，視頻，音頻，半結(jié)構(gòu)化數(shù)據(jù)和文本。尚不清楚Delta，Iceberg，Hudi如何支持這一點(diǎn)。Pulsar支持各種類型數(shù)據(jù)。
• 支持各種工作負(fù)載：包括數(shù)據(jù)科學(xué)，機(jī)器學(xué)習(xí)以及SQL和分析。 可能需要多種工具來支持所有這些工作負(fù)載，但它們都依賴于同一數(shù)據(jù)存儲(chǔ)庫。三個(gè)框架與Spark緊密結(jié)合，Spark提供了廣泛的工具選擇。Pulsar也與Spark有著緊密結(jié)合。
• 端到端流：實(shí)時(shí)報(bào)告是許多企業(yè)的常態(tài)，對(duì)流的支持消除了對(duì)專門用于服務(wù)實(shí)時(shí)數(shù)據(jù)應(yīng)用程序的單獨(dú)系統(tǒng)的需求，Delta Lake和Hudi通過變更日志提供了流功能。 但這不是真正的“流”。Pulsar是一個(gè)真正的流系統(tǒng)。

可以看到Pulsar滿足構(gòu)建Lakehouse的所有條件。然而現(xiàn)在的分層存儲(chǔ)有很大的性能差距，例如：

• Pulsar并不以開放和標(biāo)準(zhǔn)的格式存儲(chǔ)數(shù)據(jù)，如Parquet；
• Pulsar不會(huì)為卸載的數(shù)據(jù)部署任何索引機(jī)制；
• Plusar不支持高效的Upserts；

這里旨在解決Pulsar存儲(chǔ)層的性能問題，使Pulsar能作為L(zhǎng)akehouse。

3. 當(dāng)前方案

圖1展示了當(dāng)前Pulsar流的存儲(chǔ)布局。

• Pulsar在ZooKeeper中存儲(chǔ)了段（segment）元數(shù)據(jù)；
• 最新的段存儲(chǔ)在Apache BookKeeper中（更快地存儲(chǔ)層）
• 舊的段從Apache BookKeeper卸載到分層存儲(chǔ)（便宜的存儲(chǔ)層）。 卸載的段的元數(shù)據(jù)仍保留在Zookeeper中，引用的是分層存儲(chǔ)中卸載的對(duì)象。

當(dāng)前的方案有一些缺點(diǎn)：

• 它不使用任何開放式存儲(chǔ)格式來存儲(chǔ)卸載的數(shù)據(jù)。 這意味著很難與更廣泛的生態(tài)系統(tǒng)整合。
• 它將所有元數(shù)據(jù)信息保留在ZooKeeper中，這可能會(huì)限制可伸縮性。

4. 新的Lakehouse存儲(chǔ)方案

新方案建議在分層存儲(chǔ)中使用Lakehouse存儲(chǔ)卸載的數(shù)據(jù)。該提案建議使用Apache Hudi作為L(zhǎng)akehouse存儲(chǔ)，原因如下：

• 云提供商在Apache Hudi上提供了很好的支持。
• Apache Hudi已經(jīng)作為頂級(jí)項(xiàng)目畢業(yè)。
• Apache Hudi同時(shí)支持Spark和Flink多引擎。同時(shí)在中國(guó)有一個(gè)相當(dāng)活躍的社區(qū)。

4.1 新的存儲(chǔ)布局

圖2展示了Pulsar topic新的布局。

• 最新片段（未卸載片段）的元數(shù)據(jù)存儲(chǔ)在ZooKeeper中。
• 最新片段（未卸載片段）的數(shù)據(jù)存儲(chǔ)在BookKeeper中。
• 卸載段的元數(shù)據(jù)和數(shù)據(jù)直接存儲(chǔ)在分層存儲(chǔ)中。 因?yàn)樗莾H追加流。 我們不必使用像Apache Hudi這樣的Lakehouse存儲(chǔ)庫。 但是如果我們也將元數(shù)據(jù)存儲(chǔ)在分層存儲(chǔ)中，則使用Lakehouse存儲(chǔ)庫來確保ACID更有意義。

4.2 支持高效Upserts

Pulsar不直接支持upsert。它通過主題（topic）壓縮支持upsert。 但是當(dāng)前的主題壓縮方法既不可擴(kuò)展，也不高效。

• 主題壓縮在代理內(nèi)（broker）完成。 它無法支持大量數(shù)據(jù)的插入，特別是在數(shù)據(jù)集很大的情況下。
• 主題壓縮不支持將數(shù)據(jù)存儲(chǔ)在分層存儲(chǔ)中。

為了支持高效且可擴(kuò)展的Upsert，該提案建議使用Apache Hudi將壓縮后的數(shù)據(jù)存儲(chǔ)在分層存儲(chǔ)中。 圖3展示了使用Apache Hudi支持主題壓縮中的有效upserts的方法。

該想法是實(shí)現(xiàn)主題壓縮服務(wù)。主題壓縮服務(wù)可以作為單獨(dú)的服務(wù)（即Pulsar函數(shù)）運(yùn)行以壓縮主題。

• 代理向壓縮服務(wù)發(fā)出主題壓縮請(qǐng)求。
• 壓縮服務(wù)接收壓縮請(qǐng)求，并讀取消息并將其向上插入到Hudi表中。
• 完成upsert之后，將主題壓縮游標(biāo)前進(jìn)到它壓縮的最后一條消息。

主題壓縮游標(biāo)將引用位置的元數(shù)據(jù)存儲(chǔ)在存儲(chǔ)Hudi表的分層存儲(chǔ)中。

4.3 將Hudi表當(dāng)做Pulsar Topic

Hudi會(huì)在不同的即時(shí)時(shí)間維護(hù)對(duì)表執(zhí)行的所有操作的時(shí)間軸，這有助于提供表的即時(shí)視圖，同時(shí)還有效地支持按_arrival_順序進(jìn)行數(shù)據(jù)檢索。Hudi支持從表中增量拉取變更。我們可以支持通過Hudi表備份的_ReadOnly_主題。這允許應(yīng)用程序從Pulsar代理流式傳輸Hudi表的變更。圖4展示了這個(gè)想法。

4.4 可擴(kuò)展的元數(shù)據(jù)管理

當(dāng)我們開始將所有數(shù)據(jù)存儲(chǔ)在分層存儲(chǔ)中時(shí)，該提案建議不存儲(chǔ)卸載或壓縮數(shù)據(jù)的元數(shù)據(jù)，而只依賴分層存儲(chǔ)來存儲(chǔ)卸載或壓縮數(shù)據(jù)的元數(shù)據(jù)。

該提案提議在以下目錄布局中組織卸載和壓縮的數(shù)據(jù)。

- <tenant>/
  - <namespace>/
    - <topics>/
      - segments/ <= Use Hudi to store the list of segments to guarantee ACID
        - segment_<segment-id>
        - ...
      - cursors/
        - <cursor A>/ <= Use Hudi to store the compacted table for cursor A.
        - <cursor B>/ <= ...

5. 引用

[1] Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics.http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

[2] What is a Lakehouse?https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html

[3] Diving Deep into the inner workings of the Lakehouse and Delta Lake.https://databricks.com/blog/2020/09/10/diving-deep-into-the-inner-workings-of-the-lakehouse-and-delta-lake.html

以上就是Apache Pulsar結(jié)合Hudi構(gòu)建Lakehouse方案分析的詳細(xì)內(nèi)容，更多關(guān)于Apache Pulsar結(jié)合Hudi構(gòu)建Lakehouse的資料請(qǐng)關(guān)注本站其它相關(guān)文章！

香港快速服務(wù)器

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請(qǐng)保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場(chǎng)，如有內(nèi)容涉嫌侵權(quán)，請(qǐng)聯(lián)系alex-e#qq.com處理。