目錄

Join 類型 和 Join 策略

1. Join 類型（Join Type）

2. Join 策略（Join Strategy）

分布式 Join 策略 (核心)

1. Colocate Join (本地 Join - 最優):

2. Bucket Shuffle Join:

3. Broadcast Join (復制廣播):

4. Shuffle Join (重分區):

5. Replicated Join (復制表):

6. 運行時優化

a. Runtime Filter (運行時過濾器 - 核心加速)

b. Join 算法優化

c. Cost-Based Optimizer (CBO - 基于成本的優化器)

d. 謂詞下推 (Predicate Pushdown)

顯式啟用join策略

總結與最佳實踐建議：

優化實踐

---

Join 類型 和 Join 策略

Join 類型（Join Type） 和 Join 策略（Join Strategy） 是兩個不同層面的概念，它們的可控制性也不同：

---

1. Join 類型（Join Type）

• 是什么？ 指 SQL 標準定義的 INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN, SEMI JOIN, ANTI JOIN 等語義類型。
• 能否顯式指定？ ? 可以且必須顯式指定！

• • 您在編寫 SQL 查詢時，必須在 FROM / JOIN 子句中明確寫出您需要的 Join 類型（如 SELECT ... FROM fact_table INNER JOIN dim_table ON ...）。
  • 這是 SQL 語法的一部分，StarRocks 會嚴格按照您指定的語義執行。

• 優化器的影響： CBO 優化器會根據您指定的 Join 類型、表大小、過濾條件等選擇最高效的執行策略（如 Colocate/Broadcast/Shuffle），但不會改變您指定的 Join 語義。

---

2. Join 策略（Join Strategy）

• 是什么？ 指在分布式環境下執行 Join 操作時采用的物理實現方式，即您之前問題中提到的：

• • Colocate Join
  • Bucket Shuffle Join
  • Broadcast Join
  • Shuffle Join
  • Replicated Join (通過表屬性實現)

• 能否顯式指定？ ?? 通常不能（或不建議）直接在 SQL 中強制指定！

• • StarRocks 的 Cost-Based Optimizer (CBO) 是自動選擇它認為最優的 Join 策略的。
  • CBO 的決策基于：

• • • 表的分區分桶定義（是否滿足 Colocate 條件）。
    • 表的統計信息（大小、基數）。
    • Join 條件。
    • 相關系統參數（如 broadcast_row_limit）。

• • 設計目標： 讓優化器基于數據和統計信息自動選擇最高效的策略，用戶無需手動干預復雜的分布式執行細節。

分布式 Join 策略 (核心)

1. Colocate Join (本地 Join - 最優):

• • • 原理： 參與 Join 的多張表使用相同分區方式和分桶方式（Distributed By），且分桶數相同。
    • 優勢： 相同分桶鍵的數據必然落在同一個 BE 節點上。Join 計算完全在本地節點內完成，無需跨節點數據 Shuffle，網絡開銷為零。
    • 適用場景： 星型/雪花模型中的事實表與維度表關聯（維度表通常較小，可復制或采用 Colocate 分區），或大表與大表關聯（前提是分區策略匹配且數據分布均勻）。

2. Bucket Shuffle Join:

• • • 原理： 當左表（通常是驅動表/事實表）分桶，且 Join 的 ON 子句中包含左表的分桶列時啟用。
    • 優勢： 右表（通常是維度表）的數據會根據左表的分桶規則進行 Shuffle，分發到左表數據所在的 BE 節點。Join 計算在節點本地進行（左表數據不動）。相比 Broadcast 和 Shuffle，網絡傳輸量顯著減少。
    • 適用場景： 事實表（左表）與維度表（右表）關聯，且 Join Key 包含事實表的分桶列。比 Broadcast 更能處理較大的右表。

3. Broadcast Join (復制廣播):

• • • 原理： 將較小的右表（或查詢結果）完整復制到所有包含左表數據的 BE 節點上。
    • 優勢： 每個 BE 節點持有完整的右表數據，可以在本地與左表的分片進行 Join，無需跨節點傳輸左表數據。
    • 適用場景： 右表非常小（通常建議 < 100MB）時非常高效。如果右表過大，網絡傳輸和內存開銷會很大，甚至 OOM。

4. Shuffle Join (重分區):

• • • 原理： 根據 Join Key 的 Hash 值，將左表和右表的數據都進行 Shuffle 重分布，確保相同 Join Key 的數據落到同一個 BE 節點上，然后在該節點進行本地 Join。
    • 優勢： 適用于兩張大表關聯且無法使用 Colocate 或 Bucket Shuffle 的場景。
    • 劣勢： 網絡傳輸開銷最大，因為兩張表的數據都需要跨節點傳輸。是其他策略不適用時的保底方案。

5. Replicated Join (復制表):

• • • 原理： 將維度表定義為 replicated 屬性，StarRocks 會自動在集群所有 BE 節點上存儲該表的完整副本。
    • 優勢： 任何 Join 涉及該復制表時，都可以直接在本地 BE 節點上進行，完全避免網絡傳輸，效果類似于 Broadcast Join 但無需運行時廣播。
    • 適用場景： 小維度表（能容忍全集群存儲多份副本）。需要建表時指定 PROPERTIES ("replicated_storage" = "true")。

6. 運行時優化

a. Runtime Filter (運行時過濾器 - 核心加速)

• • 原理： 在 Join 計算時（尤其是 Hash Join），StarRocks 會動態地從右表（Build Side）提取 Join Key 的最小/最大值（Min/Max Filter）或構建一個 Bloom Filter。
  • 優勢： 將這個 Filter 下推到左表（Probe Side）的掃描算子。左表在讀取數據時，可以利用這個 Filter 提前過濾掉大量不可能匹配 Join Key 的行，顯著減少需要參與后續 Join 計算的數據量。
  • 類型： 支持 IN, MIN_MAX, BLOOM_FILTER。通常 BLOOM_FILTER 效果最佳。
  • 適用場景： 對大表作為 Probe Side 的 Join 性能提升巨大，尤其是當 Join Key 具有高選擇性時。通過 set global runtime_join_filter_push_down_limit = X; 控制適用右表大小上限。

b. Join 算法優化

• • 向量化 Hash Join: StarRocks 的向量化執行引擎對 Hash Join 算法進行了深度優化。它利用 SIMD 指令集，一次處理一批數據（向量），極大地提高了 CPU 利用率和緩存命中率，加速 Join 計算過程。
  • 多表 Join 順序優化: StarRocks 的 CBO 優化器會根據表大小、過濾條件和統計信息，智能選擇最優的 Join 順序，盡量先過濾掉更多數據再進行 Join，減少中間結果集大小。

c. Cost-Based Optimizer (CBO - 基于成本的優化器)

• • 原理： StarRocks 收集并維護表的統計信息（行數、列 NDV、NULL 值數、Min/Max 值、數據分布直方圖等）。
  • 優勢： CBO 利用這些統計信息，估算不同 Join 策略（Colocate/Bucket Shuffle/Broadcast/Shuffle）和不同 Join 順序的成本，并選擇它認為執行成本最低的計劃。
  • 關鍵： 需要定期執行 ANALYZE TABLE 命令更新統計信息，CBO 才能做出更準確的判斷。

d. 謂詞下推 (Predicate Pushdown)

• • 原理： 優化器會盡可能將 Join 條件或 WHERE 條件中的過濾條件下推到數據掃描的最早階段。
  • 優勢： 在掃描磁盤或從內存讀取數據時，就應用這些過濾條件，盡早過濾掉不相關的數據，減少后續算子（特別是 Join）需要處理的數據量。

顯式啟用join策略

分析查詢 | StarRocks

總結與最佳實踐建議：

1. 查看執行計劃: 使用 EXPLAIN / EXPLAIN ANALYZE 查看執行計劃，確認優化器選擇了期望的策略（如 colocate: true, runtime filters 信息）。根據執行情況調整表結構、查詢寫法或優化器參數。

分析查詢 | StarRocks

1. 首選 Colocate Join: 表設計階段，對于需要高頻 Join 且數據量大的表，優先考慮使用相同的分區分桶策略。這是性能最高的 Join 方式。
2. 善用 Bucket Shuffle Join: 當無法 Colocate 時，確保事實表（左表）按 Join Key 分桶，并讓 Join Key 包含分桶列。
3. 控制 Broadcast Join 使用范圍: 僅對小表使用 Broadcast Join。通過 SET broadcast_row_limit = X; 控制優化器選擇 Broadcast 的閾值。
4. 務必啟用 Runtime Filter: 這是加速大表 Join 的利器。通常保持默認開啟即可，效果顯著。
5. 維護準確的統計信息: 定期 ANALYZE TABLE 是 CBO 發揮效力的基礎。
6. 合理選擇 Join 類型: 根據業務語義和數據特點選擇 INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL OUTER JOIN, SEMI JOIN, ANTI JOIN 等。優化器對不同類型可能有不同優化策略。
7. 避免笛卡爾積: 確保 Join 條件有效，除非業務確實需要笛卡爾積。

通過綜合運用這些優化技術，StarRocks 能夠高效地處理各種復雜和大規模的 Join 查詢，滿足高性能分析的需求。理解這些原理對于設計和優化高效的 StarRocks 查詢至關重要。

優化實踐

StarRocks 技術內幕 | Join 查詢優化

StarRocks 技術內幕 | Join 查詢優化_starrocks join-CSDN博客

StarRocks-Profile分析及優化指南

StarRocks-Profile分析及優化指南 - 經驗教程 - StarRocks中文社區論壇