診斷建議

問題描述

建議措施

數據傾斜

StarRocks數據在各個存儲節點分布不均，使得某些節點在讀取數據時需要掃描更多的數據，導致查詢延遲。

建議檢查并優化分桶鍵設置，確保數據更均勻分布。

IO傾斜

Scan算子多個實例在讀取數據時，部分實例花費的時間顯著大于其它實例時間。

建議從以下方面進行排查：

• 資源層面：檢查是否存在節點的IO使用率明顯高于其它節點或IO線程池打滿的情況。

• 數據模型層面：檢查是否存在查詢的數據在節點上分布不均的情況。

數據掃描未有效過濾

基于掃描原始數據量以及最終查詢語句輸出數據量、結合Query Profile執行樹信息進行判斷。當Scan算子本身掃描數據量較大，同時輸出給下游算子的數據量未顯著過濾的情況下，認為數據掃描未有效過濾。

StarRocks提供索引、謂詞下推、Join Runtime Filter等多種方式過濾Scan算子的數據量，可以通過多種方式來提高Scan算子的掃描過濾效率。建議從以下方面進行排查：

• 檢查表結構是否合理。

• 檢查排序鍵是否合適。

• 檢查是否需要添加索引。

• 檢查查詢條件是否包含函數，導致無法用于過濾數據。

診斷建議

問題描述

建議措施

Join結果膨脹

正常情況下，Join算子的輸出結果行數一般小于等于輸入行數。如果輸出結果顯著大于輸入結果，則視為Join結果膨脹。此種情況通常是缺少Join條件造成Cross Join，或者Join條件錯誤導致Join的兩張表數據出現1:N的情況。還有一些情況是缺少統計信息、或者數據變更后統計信息過期，導致優化器選擇了錯誤的計劃。

建議從以下方面進行排查：

• 優化Join條件設置：檢查Join條件是否缺失、是否符合業務邏輯，增添必要條件以精確匹配，避免Join結果膨脹。

• 優化多表Join順序：如果是多表Join，檢查Join順序是否正確。如果不正確，可以設置session參數disable_join_reorder為 true來手動控制查詢中的Join順序。

Join build表選擇不合理

在Join算子中，Build階段系統通常會在內存中創建哈希表，Build表數據量過大會消耗更多的內存資源。此種情況，通常是因為執行優化器沒有正確的選擇Build表所致。

建議從以下方面進行排查：

• 檢查統計信息是否收集或過期。

• 通過設置session參數disable_join_reorder為 true來手動控制查詢中的Join順序。

Join不應該使用Broadcast

當小表與大表Join時，如果小表遠小于大表，Broadcast Join可以將小表廣播到大表所在節點，避免大表的數據重分布，從而有效降低了網絡傳輸的開銷。但某些情況下，由于統計信息錯誤等原因，優化器錯誤地估計了表的大小，導致較大的表也使用了Broadcast Join，增加網絡和計算的成本。

建議在JOIN關鍵字后添加[shuffle] Hint，限制使用Broadcast Join。

診斷建議

問題描述

建議措施

Aggregate本地聚合度低

在執行聚合操作時，各個計算節點通常會先在本地聚合獲取較小聚合結果后再分發到其它節點，以減少網絡數據傳輸。但某些情況下，本地聚合時未能有效縮減數據量，不僅不能減少網絡數據傳輸，反而會消耗大量的計算資源。

如果Aggregate整體（包括非本地聚合部分）執行時間較長，則建議通過修改Session參數new_planner_agg_stage=1關閉二階段聚合。