Stage層級診斷結果 - AnalyticDB

AnalyticDB MySQL版的SQL診斷功能可以對SQL查詢進行Query、Stage和運算元（Operator）層級的資訊統計，再在統計資訊的基礎上進行診斷並提供調優建議。本文介紹如何查看和分析Stage層級診斷結果。

診斷結果類型

說明查看Stage層級診斷結果的方法，請參見查看診斷結果。

問題
廣播（Broadcast）是在兩個相鄰的Stage間，上遊向下遊Stage傳輸資料時所用的一種方法（更多詳情，請參見資料輸出類型）。如果某個Stage廣播了較多資料，可能會導致查詢佔用較大的峰值記憶體。
建議
- 首先需要判斷當前的廣播操作是否合理。某個Stage中的資料被廣播，一般是因為這些廣播後的資料會作為Join操作的右表（Builder端）來在記憶體中構建雜湊表，所以右表越小越好。在高並發查詢的情境下，這樣有利於減少節點間的網路連接，提升系統整體穩定性。對於Join條件存在資料扭曲的情境，如果不廣播小表，那麼會出現如下圖的執行流程：
  假設上圖中的表Tsmall在b欄位上存在嚴重資料扭曲，那麼當表Tbig以a欄位均勻地分布在AnalyticDB MySQL版的儲存節點上時，對Tbig表的重分布會存在處理時間長尾，而且在下遊Stage執行Join時也會存在長尾。
  如果Tbig表不做重分布，而只廣播Tsmall表，會有如下的執行流程：
  如上圖所示，只廣播Tsmall這張小表，可以緩解資料扭曲帶來的處理長尾問題。
- 在某些情境下，例如統計資訊到期，會導致預估的表大小有偏差，從而導致廣播了大量資料，此時可以考慮使用HintJOIN_DISTRIBUTION_TYPE=repartitioned來關閉資料的廣播功能。

問題
導致Stage輸入資料扭曲的可能原因如下：
- 建表時選擇的分布欄位不合理，導致Stage中的某個資料掃描運算元在掃描資料時存在傾斜。
- 上遊Stage的資料通過網路傳輸到當前Stage時存在傾斜。
建議
- 建表時選擇合適的分布欄位。更多詳情，請參見資料建模診斷。
- 查看上遊Stage是否存在Stage輸出資料扭曲問題。更多詳情，請參見Stage輸出資料扭曲。

問題
Stage輸出資料扭曲會導致當前Stage處理耗時不均勻，存在長尾；如果下遊Stage處理過程複雜，也會導致下遊Stage在處理資料時存在長尾，最終都會影響查詢整體效能。
建議
通過診斷結果中提示的欄位名來判斷是否是這些欄位存在資料扭曲（如出現大量空值）。