1. 動機

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

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

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

2. 分析

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

Lakehouse有如下關鍵特性：

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

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

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

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

3. 當前方案

圖1展示了當前Pulsar流的存儲布局。

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

當前的方案有一些缺點：

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

4. 新的Lakehouse存儲方案

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

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

4.1 新的存儲布局

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

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

4.2 支持高效Upserts

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

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

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

該想法是實現主題壓縮服務。主題壓縮服務可以作為單獨的服務（即Pulsar函數）運行以壓縮主題。

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

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

4.3 將Hudi表當做Pulsar Topic

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

4.4 可擴展的元數據管理

當我們開始將所有數據存儲在分層存儲中時，該提案建議不存儲卸載或壓縮數據的元數據，而只依賴分層存儲來存儲卸載或壓縮數據的元數據。

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

- <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