什麼是 AggregatingMergeTree？#

AggregatingMergeTree 是 ClickHouse MergeTree 家族中的「聚合專用儲存引擎」，其特點是：

• 資料寫入時儲存為 AggregateFunction 型別（預計算的聚合狀態）。
• Merge 階段進行 狀態合併 (State Merging)，將多筆相同 Primary Key 的聚合結果進行再彙總。
• 查詢時透過 聚合狀態還原 (State Finalization)，將狀態轉為最終數值結果。

這種設計特別適合高頻寫入 + 聚合查詢的場景，如：網站流量統計、實時 KPI 指標儀表板、IoT 裝置資料彙總。

與 SummingMergeTree 的差異比較#

語法與基本範例#

1
-- Source Table
2
CREATE TABLE visits (
3
    StartDate DateTime64 NOT NULL,
4
    CounterID UInt64,
5
    Sign Nullable(Int32),
6
    UserID Nullable(Int32)
7
) ENGINE = MergeTree ORDER BY (StartDate, CounterID);
8

9
-- AggregatingMergeTree Table
10
CREATE TABLE agg_visits (
11
    StartDate DateTime64 NOT NULL,
12
    CounterID UInt64,
13
    Visits AggregateFunction(sum, Int32),
14
    Users AggregateFunction(uniqExact, Int32)
15
)
16
ENGINE = AggregatingMergeTree()
17
ORDER BY (StartDate, CounterID);
18

19
-- Materialized View Table
20
CREATE MATERIALIZED VIEW visits_mv TO agg_visits
21
AS SELECT
22
    StartDate,
23
    CounterID,
24
    sumState(Sign) AS Visits,
25
    uniqState(UserID) AS Users
26
FROM visits
27
GROUP BY StartDate, CounterID;

1
INSERT INTO visits (StartDate, CounterID, Sign, UserID)
2
 VALUES (1667446031000, 1, 3, 4), (1667446031000, 1, 6, 3);

1
SELECT
2
    StartDate,
3
    sumMerge(Visits) AS Visits,
4
    uniqMerge(Users) AS Users
5
FROM test.visits_mv
6
GROUP BY StartDate
7
ORDER BY StartDate;

1
┌───────────────StartDate─┬─Visits─┬─Users─┐
2
│ 2022-11-03 03:27:11.000 │      9 │     2 │
3
└─────────────────────────┴────────┴───────┘

運作流程#

1. 資料寫入 (AggregateFunction 狀態寫入)

   • 透過 sumState(), avgState(), uniqExactState() 等函數將資料寫入為「聚合狀態」。

2. 背景 Merge 操作 (State Merging)

   • 當相同 Primary Key 的資料進行合併時，ClickHouse 會將 AggregateFunction 狀態進行「狀態合併」。
   • 這個過程發生於背景合併 (Merge)，不影響寫入吞吐量。

3. 查詢時還原聚合結果 (State Finalization)

   • 查詢時需透過 sumMerge(), avgMerge(), uniqExactMerge() 等函數將聚合狀態還原為最終數值。

應用場景#

改進：延遲聚合至 Merge 階段#

為了將聚合計算成本從 INSERT 時移至 Merge 階段，可以這麼做：

1
SET optimize_on_insert = 0;
2

3
CREATE MATERIALIZED VIEW visits_mv TO agg_visits
4
AS SELECT
5
    StartDate,
6
    CounterID,
7
    initializeAggregation('sum', Sign) AS Visits,
8
    initializeAggregation('uniqExact', UserID) AS Users
9
FROM visits;

透過以下兩個關鍵步驟：

• initializeAggregation()：將原始值轉為聚合狀態寫入，無需 Group By。
• optimize_on_insert = 0：關閉插入時的自動聚合優化，將聚合推遲到後續 Merge 操作進行。

可以帶來：

1. 減少 INSERT 時的計算壓力 (極大化寫入吞吐)
   • 傳統 Materialized View 的預聚合邏輯：每次寫入 (INSERT) 都需要先做 Group By 聚合計算，這會對 CPU 與 Memory 造成即時壓力，寫入高峰時，會拖慢寫入速度。
   • initializeAggregation + optimize_on_insert = 0：每筆資料直接以「聚合狀態」寫入，無需即時計算聚合結果，讓 INSERT 成本變成「純寫檔案 + 生成狀態」的低成本操作。
   • 特別適合每秒數萬、數十萬筆的高頻寫入場景，如 IoT、網站點擊流、使用者行為追蹤。
2. 聚合計算的成本被「平滑化」到背景 Merge
   • 傳統的預聚合方式會把所有聚合計算都集中在 INSERT 時進行，當寫入高峰時，資源使用率會瞬間飆升。
   • initializeAggregation 模式將聚合邏輯延遲到 Merge 階段，讓這些計算能夠由 ClickHouse 以 批次、自動、分散式的方式在背景進行。所以背景 Merge 可以根據系統負載動態調整，不會對線上寫入與查詢造成即時衝擊，更能彈性調整 Merge 策略 (如 TTL-based Merge、optimize_final 週期性合併)。

Best Practice#

AggregatingMergeTree v.s. SummingMergeTree 選用時機#

結語#

個人覺得 AggregatingMergeTree 是處理「高頻寫入 + 複雜聚合統計」場景的強大工具。但內部真的很複雜 XD，知識點極多，當你在選用 MergeTree 引擎時，應當具備較深的相關知識，才能發揮很好的優化系統。

而透過 AggregateFunction 型別預儲存聚合狀態，搭配 MergeTree 的合併機制與 Materialized View 實時計算能力，能將查詢效能提升到毫秒級，極適合指標報表、流量監控、IoT 資料彙總等應用場景。

但也需留意 Primary Key 與 Partition 設計，才能讓聚合合併與查詢裁剪效能發揮到極致。