1. 動機

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

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

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

2. 分析

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

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

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

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

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

這里旨在解決Pulsar存儲層的性能問題，使Pulsar能作為Lakehouse。

3. 當(dāng)前方案

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

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

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

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

4. 新的Lakehouse存儲方案

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

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

4.1 新的存儲布局

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

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

4.2 支持高效Upserts

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

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

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

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

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

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

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

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

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

當(dāng)我們開始將所有數(shù)據(jù)存儲在分層存儲中時，該提案建議不存儲卸載或壓縮數(shù)據(jù)的元數(shù)據(jù)，而只依賴分層存儲來存儲卸載或壓縮數(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方案分析的詳細內(nèi)容，更多關(guān)于Apache Pulsar結(jié)合Hudi構(gòu)建Lakehouse的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論