Paimon 在特定場景（如流式 Lookup Join）下，會為了極致的查詢性能而引入額外的存儲（本地磁盤?LookupFile）和計算（構建?LookupFile）開銷。但這是一種用一次性的、可控的開銷，換取后續持續、高吞吐、低延遲查詢的典型權衡。

當把寫入、存儲、Compaction 和查詢的全鏈路開銷綜合對比時，Paimon 在其設計的分析型場景中，整體資源消耗和效率往往優于 HBase。

下面我們來進行一個綜合的對比分析。

對比維度	Paimon (為數據湖分析與流式追加優化)	HBase (為在線隨機讀寫與強一致性優化)	結論與權衡
寫入路徑開銷	輕量級內存追加 內存操作 寫入僅是向內存中的SortBuffer進行無序追加，開銷極低。 若內存不足，則溢寫至本地磁盤。 在commit、compaction或超過sort buffer容量時會進行flushable，將內存與磁盤數據合并構建為Parquet文件，一次性寫入遠程存儲。 持久化 不依賴高成本的WAL，而是巧妙借助Flink Checkpoint機制，原子化更新元數據。	同步WAL，有序內存寫入 1. 寫WAL : 每條數據都需 同步寫入HDFS上的Write-Ahead Log ，確保單點強持久性，但引入了 高昂的遠程I/O 。 2. 內存操作 : 寫入MemStore（通常是跳表），需 實時維護內存結構有序 ，存在一定的計算開銷和內存碎片風險。	Paimon寫入效率壓倒性優勢。 Paimon專為高吞吐流式場景設計，其 “先追加，后排序，批量提交” 的模式，完美規避了遠程I/O瓶頸。 HBase的同步WAL機制雖保證了單條寫入的強一致性，但在大規模批量寫入時，成為了性能的主要瓶頸。
最終存儲開銷	極致壓縮，元數據極簡 采用 Parquet列式存儲 ，天然具備極高的壓縮比。元數據開銷小，僅在文件級別記錄統計信息，無冗余。	行式存儲，元數據冗余 HFile雖為二進制格式，但需為每個單元格(Cell)存儲完整的RowKey + ColumnFamily + Qualifier + Timestamp，在寬表場景下， 元數據冗余巨大 。	Paimon存儲成本顯著更優。得益于列存和高效壓縮，Paimon的存儲占用通常僅為HBase的 1/3甚至更少 。在PB級數據規模下，這意味著 巨大的成本節約 。
查詢路徑與延遲	Paimon內存的MemStore和sort buffer溢寫的臨時文件不可見，需要等待checkpoint提交，因此有一段延遲。 批量分析： 直接讀取Parquet，充分利用列裁剪和謂詞下推，分析性能極佳。 流式點查 (Lookup Join)： 采用"延遲加載，本地緩存"策略。首次訪問時，將遠程數據拉取到本地磁盤構建高速LookupFile（如哈希文件、排序Block），后續查詢轉為高速本地I/O，實現了攤銷后的極低延遲。	通用化、穩定的低延遲設計 1. 查緩存 : 優先訪問BlockCache（內存）。 2. 查文件 : 若未命中，通過內存索引快速定位到遠程HDFS上的HFile并讀取。整個過程對用戶透明，提供 普適性的低延遲 保證。	各擅勝場，取決于應用模式。 ? HBase提供的是 通用的、可預期的低延遲 隨機讀取能力。 ? Paimon則更加“智能”和“場景化”：分析場景下發揮列存優勢；高頻點查場景下，通過 “預熱” 將遠程讀轉化為本地讀，實現了 極致的攤銷后延遲 。
Compaction開銷	讀寫放大 合并多個Parquet文件，寫入新的Parquet文件。讀寫單位是文件。	讀寫放大 合并多個HFile，寫入新的HFile。讀寫單位是文件。	兩者都存在讀寫放大問題，這是LSM-Tree架構的固有成本。

具體問題

1. 寫入時?Sort Buffer?和溢寫文件的開銷需要考慮嗎？

   • 需要，但這是一種內部優化。這個開銷是臨時的、在本地的。它的目的是將大量無序的寫入，在本地磁盤中整理成有序的批次，然后一次性高效地寫入最終的列式文件。這避免了對遠程存儲進行大量的隨機小文件寫入。相比之下，HBase 的 WAL 是對遠程存儲的持續寫入，開銷更大。

2. Lookup 時重寫 Parquet 變為?Lookup File?的開銷需要考慮嗎？

   • 需要，但這是一種用空間換時間的查詢優化策略。這個開銷只發生在特定的?changelog-producer = 'lookup'?或 Flink Lookup Join 場景下。Paimon 的設計哲學是：既然流作業會持續不斷地進行 lookup，那么與其每次都去遠程讀 Parquet（即使有謂詞下推，對于點查也不是最高效的格式），不如一次性支付“預處理”成本，在計算節點本地構建一個為點查高度優化的索引文件（LookupFile）。這個開銷一旦支付，后續成千上萬次的 lookup 都會受益，整體吞吐量和延遲會遠優于重復訪問遠程存儲。

3. Paimon 依賴 Flink Checkpoint，沒有 WAL

   • 完全正確！這是 Paimon 架構的一個基石。它將一致性保證的難題交給了 Flink 的分布式快照機制。這使得 Paimon 的寫入器 (MergeTreeWriter) 無需處理復雜的 WAL 邏輯，極大地簡化了設計并消除了 WAL 帶來的寫入開銷。這是它相比 HBase 在寫入路徑上更輕量級的核心原因之一。

Paimon 和 HBase 空間占用

對比維度	Paimon (使用 Parquet)	HBase	空間影響分析
1. 存儲格式	列式存儲 (Columnar)	面向列族的鍵值存儲	這是最關鍵的區別。Parquet 將同一列的數據連續存儲，而 HBase 雖叫“列式數據庫”，但其物理存儲更接近按行（Row Key）組織的、稀疏的、多維度的 Map。
2. 數據壓縮	極高壓縮率	中等壓縮率	列式存儲把相同類型的數據放在一起，熵值更低，因此壓縮效果極好（如字典編碼、行程編碼 RLE）。HBase 只能對 KeyValue 塊進行通用壓縮（如 Snappy, Gzip），效果不如列式存儲。
3. 元數據開銷	非常低	非常高	Parquet 只需在文件頭/尾存儲一次列名和類型。而 HBase 為每一個單元格（Cell）都存儲了完整的 Key，這個 Key 包含：RowKey + Column Family + Column Qualifier + Timestamp + Type。當列多、RowKey 長時，元數據開銷會急劇膨脹，甚至超過數據本身。
4. 更新與版本	LSM-Tree (Copy-on-Write)	LSM-Tree (Append-only)	兩者都通過追加新版本數據和定期 Compaction 來處理更新。Paimon 寫新文件，HBase 寫新的 KeyValue。在 Compaction 前都會有空間放大，但 HBase 的放大效應因其高元數據開銷而更顯著。

結合代碼分析 Paimon 的寫入過程

在MergeTreeWriter.java?文件中，flushWriteBuffer?方法是寫入流程的核心：

// ... existing code ...private void flushWriteBuffer(boolean waitForLatestCompaction, boolean forcedFullCompaction)throws Exception {if (writeBuffer.size() > 0) {
// ... existing code ...final RollingFileWriter<KeyValue, DataFileMeta> dataWriter =writerFactory.createRollingMergeTreeFileWriter(0, FileSource.APPEND);try {// 1. 從內存/磁盤排序緩沖中取出數據writeBuffer.forEach(keyComparator,mergeFunction,changelogWriter == null ? null : changelogWriter::write,// 2. 交給 dataWriter 寫入dataWriter::write);} finally {
// ... existing code ...// 3. 關閉 writer，完成一個 Parquet 文件的生成dataWriter.close();}// 4. 獲取新生成文件的元數據List<DataFileMeta> dataMetas = dataWriter.result();
// ... existing code ...}
// ... existing code ...}
// ... existing code ...

這里的?dataWriter?(最終實現是?ParquetWriter?或類似) 就是將內存中的?KeyValue?數據轉換并寫入成高效的 Parquet 文件的執行者。在這個寫入過程中，它會執行：

1. 列式轉換：將行式數據?KeyValue?拆分成列。
2. 編碼與壓縮：對每一列數據應用最高效的編碼（如字典、RLE）和壓縮算法。
3. 寫入文件：將壓縮后的列數據、頁頭、列元數據、文件元數據等組織成一個完整的 Parquet 文件。

這個過程天然地就利用了列存的所有優勢來節省空間。

為什么 Paimon/Parquet 能省空間？

1. 列存帶來的高壓縮率：這是最主要的因素。相同類型的數據連續存放，極大提升了壓縮算法的效率。
2. 極低的元數據開銷：相對于 HBase 為每個 Cell 存儲一遍長長的 Key，Parquet 的元數據開銷幾乎可以忽略不計。想象一個有 100 列的表，HBase 會存儲 100 次?RowKey + Column Family + Timestamp，而 Parquet 只在文件元數據中存一次列名。
3. 編碼優化：Parquet 的字典編碼（Dictionary Encoding）和行程編碼（Run-Length Encoding, RLE）等技術能進一步壓縮數據，特別是對于低基數（重復值多）的列，效果拔群。

因此，“Paimon 寫入 Parquet 占用的磁盤空間只有 HBase 的 1/3” 在許多場景下是一個合理且偏保守的估計。尤其是在表寬（列多）、RowKey 和列名較長、數據重復度高的場景下，Paimon/Parquet 的空間優勢會更加明顯，節省的空間可能會遠超 2/3。

綜合結論

?Paimon 為了實現不同目標所付出的“代價”。

• Paimon 的“開銷”是有策略的、可控的投資：無論是寫緩沖還是?LookupFile，都是為了優化整個數據處理鏈路中的某個環節（通常是 I/O）而引入的。這些開銷服務于其作為數據湖存儲核心的定位，旨在最大化分析吞吐量和效率。
• HBase 的“開銷”是為實現其核心價值的固有成本：WAL 和高冗余的元數據存儲是 HBase 實現低延遲、高可靠隨機讀寫的基石，這個成本是持續存在的。

因此，不能簡單地說 Paimon 的查找開銷比 HBase 大。更準確的說法是：Paimon 為流式分析場景下的高頻查找，選擇了一次性的構建開銷來換取后續的極致性能，而在其他方面（特別是寫入和存儲）的開銷遠小于 HBase。