Impala 在 Iceberg 上的性能優化與比較

引言

隨著大數據處理需求的增長，資料儲存與查詢效率成為關鍵議題。Apache Impala 作為一個高效的互動式查詢引擎，與 Apache Iceberg 的整合提供了強大的資料管理能力。Iceberg 作為一種開放的表格式，支援高效的資料刪除與更新操作，而 Impala 則能快速處理大量資料。本文探討 Impala 與 Iceberg 的整合機制，分析其性能優化策略，並透過實際測試案例驗證效能提升的可行性。

主要內容

技術或工具的定義與基本概念

Impala 架構：

支援多節點集群，包含協調器（Coordinator）與執行器（Executor）。
協調器負責查詢解析、計劃生成與資料分發。
執行器處理資料讀取、Join、聚合等操作。
查詢計劃以樹狀結構呈現，包含掃描節點（Scan Node）、Join 節點、交換節點（Exchange Node）等。

Iceberg 表格式特性：

支援多種刪除策略：
- Copy and Delete：重寫資料檔案，刪除特定資料。
- Merge and Read：寫入刪除檔案，讀取時合併資料與刪除資訊。
位置刪除（Position Delete）：
- 刪除檔案包含資料檔案位置資訊（File Path）與行位置（Position）。
- 需在讀取時合併資料與刪除檔案。

重要的特性或功能

資料讀取機制：

Impala 透過 Iceberg API 獲取資料檔案與刪除檔案清單。
根據資料檔案是否存在刪除檔案，分為兩種處理方式：
- 無刪除檔案：直接掃描資料檔案。
- 有刪除檔案：
  1. 掃描資料檔案與刪除檔案。
  2. 透過左反連接（Left Anti Join）合併資料與刪除資訊。
  3. 新增虛擬欄位（File Path、Position）於資料掃描節點。

網路傳輸優化：

透過直接分佈模式（Direct Distribution Mode）：
- 利用 Iceberg 調度器（Scheduler）的資料檔案分發資訊。
- 根據刪除檔案的 File Path 映射執行器節點，直接傳送資料至目標節點。
- 減少網路傳輸量，避免全域廣播（Broadcast）或分區（Partition）Join 的高成本。

實際的應用案例或實作步驟

性能測試與結果：

測試環境：
- 40 節點集群，資料存儲於 S3。
- 測試表包含 85 億筆資料，刪除 10% 資料（約 8.5 億筆）。
- 執行簡單的 SELECT COUNT(*) 查詢。
原始性能：
- 網路傳輸成本：
  - 交換節點耗時 7 秒（左側資料） + 4 秒（右側資料）。
  - 總查詢時間：21 秒。
優化後結果：
- 透過直接分佈模式優化：
  - 減少網路傳輸量至 8.25 億筆資料。
  - 總查詢時間降至 12 秒（性能提升 42%）。

大規模測試案例：

測試挑戰：
- 1 兆筆資料表（兩欄：Station、Measure）。
- 執行 SELECT ... GROUP BY 查詢。
- 增加刪除與更新操作：
  - 新增時間戳（Timestamp）與感測器類型（Sensor Type）欄位。
  - 使用 Iceberg 分區策略（Day Truncate、Bucket Hash）。
  - 透過 Merge on Read 技術寫入位置刪除檔案。
測試結果：
- 無刪除資料時：2.5 分鐘。
- 70 億筆刪除資料時：7 分 15 秒（性能下降 3 倍）。

技術的優勢與挑戰

優勢：

透過直接分佈模式優化，顯著減少網路傳輸成本。
支援高效資料刪除與更新操作，提升查詢效能。
並行處理資料與刪除檔案掃描，提升查詢吞吐量。

挑戰：

建立哈希表效率低下，導致 C++ 向量（Vector）頻繁重分配。
大規模資料處理時，刪除操作可能導致性能下降。

總結

Impala 與 Iceberg 的整合透過資料結構優化與並行處理，顯著提升查詢效能。實際測試顯示，網路傳輸優化與刪除操作處理策略對性能有顯著影響。未來需進一步優化資料結構建立與並行處理機制，以提升 Iceberg 表的查詢效能。