針對 Azure Databricks 中的效能瓶頸進行疑難排解

  • 發行項

注意

本文依賴裝載于 GitHub 上的開放原始碼程式庫： https://github.com/mspnp/spark-monitoring 。

原始程式庫支援 Azure Databricks Runtimes 10.x (Spark 3.2.x) 和更早版本。

Databricks 已提供更新版本，以支援分支上的 l4jv2 Azure Databricks Runtimes 11.0 (Spark 3.3.x) 和更新版本： https://github.com/mspnp/spark-monitoring/tree/l4jv2 。

請注意，11.0 版本與回溯相容，因為 Databricks Runtimes 中使用的記錄系統不同。 請務必針對 Databricks Runtime 使用正確的組建。 程式庫和 GitHub 存放庫處於維護模式。 沒有進一步版本的方案，而且問題支援只會最努力。 如需程式庫或 Azure Databricks 環境監視和記錄藍圖的任何其他問題，請連絡 azure-spark-monitoring-help@databricks.com 。

本文說明如何使用監視儀表板，在 Azure Databricks 上尋找 Spark 作業的效能瓶頸。

Azure Databricks 是以 Apache Spark 為基礎的分析服務，可讓您輕鬆快速地開發和部署巨量資料分析。 在運作生產環境 Azure Databricks 工作負載時，監視效能問題及進行疑難排解是很重要的。 若要找出常見的效能問題，使用以遙測資料為基礎的監視視覺效果會很有用。

必要條件

若要設定本文中所示的 Grafana 儀表板：

部署的 Grafana 儀表板包含一組時間序列視覺效果。 每個圖表都是時間序列的計量圖，與 Apache Spark 作業、作業的階段以及組成每個階段的工作相關。

Azure Databricks 效能概觀

Azure Databricks 是以 Apache Spark (一般用途的分散式計算系統) 為基礎。 應用程式程式碼 (稱為 [作業]) 會在 Apache Spark 叢集上執行，並由叢集管理員協調。 一般情況下，作業是最高層級的計算單位。 作業代表 Spark 應用程式所執行的完整作業。 一般作業包括從來源讀取資料、套用資料轉換，以及將結果寫入至儲存體或另一個目的地。

作業會細分為 [階段]。 作業會依序向前移到各階段，這表示稍後的階段必須等待較早的階段完成。 階段包含可在 Spark 叢集的多個節點上平行執行的相同 [工作] 群組。 工作是資料子集上所進行最細微的執行單位。

下一節將說明一些有助於效能疑難排解的儀表板視覺效果。

作業和階段延遲

作業延遲是作業執行的持續時間 (從開始到完成為止)。 其會顯示為每個叢集的作業執行百分位數和應用程式識別碼，以允許極端值的視覺效果。 下圖顯示的作業記錄中，第 90 個百分位數達到 50 秒，即使第 50 個百分位數持續大約 10 秒。

顯示作業延遲的圖表

調查叢集和應用程式執行的作業，以尋找延遲的尖峰。 一旦識別出高延遲的叢集和應用程式後，請繼續調查階段延遲。

階段延遲也會顯示為百分位數，以允許極端值的視覺效果。 階段延遲會依叢集、應用程式和階段名稱細分。 找出圖表中工作延遲的尖峰，以判斷哪些工作會阻礙階段完成。

顯示階段延遲的圖表

叢集輸送量圖表會顯示每分鐘完成的作業、階段和工作數目。 這可協助您根據每項作業的階段相對數目和工作來了解工作負載。 在這裡，您可以看到每分鐘的作業數目範圍介於 2 到 6 之間，而階段數大約是每分鐘 12 至 24。

顯示叢集輸送量的圖表

工作執行延遲的總和

此視覺效果會顯示在叢集上執行的每部主機工作執行延遲的總和。 您可以使用此圖表來偵測因為主機變慢而執行緩慢的工作，或每個執行程式的工作 配置錯誤。 在下圖中，大部分的主機都有大約 30 秒的總和。 不過，兩部主機的總和會停留在 10 分鐘左右。 可能是主機執行速度緩慢，或每個執行程式的工作數目配置錯誤。

顯示每個主機工作執行總和的圖表

每個執行程式的工作數目會顯示有兩個執行程式指派了不相稱的工作數目，因而造成瓶頸。

顯示每個執行程式工作的圖表

每個階段的工作計量

工作計量視覺效果可提供工作執行的成本明細。 您可以使用其查看工作 (例如序列化和還原序列化) 所花費的相對時間。 這項資料可能會顯示最佳化的機會，例如，使用廣播變數來避免傳送資料。 工作計量也會顯示工作的隨機資料大小，以及隨機讀取和寫入時間。 如果這些值很高，則表示大量資料會在網路上移動。

另一個工作計量是排程器延遲，可測量排程工作所需的時間。 在理想的情況下，相較於執行程式計算時間 (這是實際執行工作所花費的時間)，這個值應該很低。

下圖顯示排程器延遲時間 (3.7 秒) 超過執行程式計算時間 (1.1 秒)。 這表示等候工作排程比實際工作需要花費更多時間。

顯示每個階段工作計量的圖表

在這種情況下，問題是因為有太多分割區造成大量的負擔。 減少排程器延遲時間的分割區數目。 下圖顯示大部分的時間花費在執行工作。

顯示減少分割區數目降低排程器延遲時間的圖表。

串流輸送量和延遲

串流輸送量與結構化串流直接相關。 有兩個重要計量與串流輸送量相關聯：每秒輸入資料列和每秒處理的資料列。 如果每秒輸入資料列超過每秒處理的資料列，則表示串流處理系統落後。 此外，如果輸入資料來自事件中樞或 Kafka，則每秒輸入資料列應該會趕上前端的資料內嵌速率。

兩個作業可能會有類似的叢集輸送量，但串流計量會非常不同。 下列螢幕擷取畫面會顯示兩個不同的工作負載。 其在叢集輸送量方面很類似 (作業、階段和每分鐘的工作)。 但第二回合會處理 12,000 個資料列/秒與 4,000 個資料列/秒。

顯示串流輸送量的圖表

串流輸送量通常為比叢集輸送量更好的商務計量，因為其會測量已處理的資料記錄數目。

每個執行程式的資源耗用量

這些計量可協助您了解每個執行程式所執行的工作。

百分比計量會測量執行程式花費在各項目上的時間，並以所花費時間與整體執行程式計算的比例來表示。 計量包括：

  • % 序列化時間
  • % 還原序列化時間
  • % CPU 執行程式時間
  • % JVM 時間

這些視覺效果會顯示這些計量對整體執行程式處理各有多少貢獻。

顯示每個計量對整體執行程式處理貢獻的視覺效果。

隨機計量是與跨執行程式隨機資料相關的計量。

  • 隨機 I/O
  • 隨機記憶體
  • 檔案系統使用量
  • 磁碟使用狀況

常見的效能瓶頸

Spark 有兩個常見的效能瓶頸：工作落後和非最佳隨機分割區計數。

工作落後

作業中的各階段會循序執行 (較早的階段會阻礙之後的階段)。 如果有一項工作執行隨機分割區的速度較其他工作緩慢，則叢集中的所有工作都必須等待緩慢的工作趕上，階段才能結束。 這可能因為以下原因而發生：

  1. 主機或主機群組執行緩慢。 徵兆：高工作量、階段或作業延遲，以及低叢集輸送量。 每個主機的工作延遲總和不會平均分散。 不過，資源耗用量會平均分散到執行程式。

  2. 匯總執行工作所費不貲 (資料扭曲)。 徵兆：高工作延遲、高階段延遲、高作業延遲或低叢集輸送量，但每個主機的延遲總和會平均分散。 資源耗用量會平均分散到執行程式。

  3. 如果分割區的大小不相等，則較大的分割區可能會造成工作執行 (分割區扭曲) 不平衡。 徵兆：相較於叢集中執行的其他執行程式，執行程式資源耗用量偏高。 在該執行程式上執行的所有工作都會執行緩慢，並在管線中阻礙階段執行。 這些階段稱為「階段障礙」。

非最佳隨機分割區計數

在結構化串流查詢期間，將工作指派給執行程式是叢集的資源密集作業。 如果隨機資料並非最佳的大小，則工作的延遲量將會對輸送量和延遲造成負面影響。 如果分割區太少，叢集中的核心使用量將會過低，從而導致處理效率不彰。 相反地，如果有太多分割區，少量的工作就會有大量的管理負擔。

使用資源耗用量計量，針對叢集上的執行程式分割區扭曲和配置錯誤進行疑難排解。 如果分割區扭曲，則相較於叢集上執行的其他執行程式，執行程式資源會更高。

例如，下圖顯示前兩個執行程式隨機播放所使用的記憶體比其他執行程式大 90 倍：

顯示前兩個執行程式上隨機使用的記憶體大於其他執行程式 90X 的圖表。

下一步