效能微調的可觀察性模式和計量

此解決方案示範可觀察性模式和計量，以改善使用 Azure Databricks 之巨量資料系統的處理效能。

架構

下載此架構的 Visio 檔案 。

工作流程

解決方案牽涉到下列步驟：

1. 伺服器會將客戶分組的大型 GZIP 檔案傳送至 Azure Data Lake 儲存體 （ADLS） 中的 [源 資料] 資料夾。

2. ADLS 接著會將成功擷取的客戶檔案傳送至Azure 事件方格，這會將客戶檔案資料轉換成數個訊息。

3. Azure 事件方格會將訊息傳送至 Azure 佇列儲存體服務，以將它們儲存在佇列中。

4. Azure 佇列儲存體將佇列傳送至 Azure Databricks 資料分析平臺進行處理。

5. Azure Databricks 會將佇列資料解壓縮並處理成它傳回 ADLS 的已處理檔案：

   1. 如果處理過的檔案有效，它會進入 登陸 資料夾。

   2. 否則，檔案會進入 [不正確的 資料夾] 樹狀結構。 一開始，檔案會進入 [重試 ] 子資料夾中，ADLS 會再次嘗試客戶檔案處理 （步驟 2）。 如果一對重試嘗試仍然會導致 Azure Databricks 傳回不正確已處理檔案，則已處理的檔案會進入 [失敗 ] 子資料夾中。

6. 當 Azure Databricks 在上一個步驟中解除封裝及處理資料時，也會將應用程式記錄和計量傳送至 Azure 監視器以供儲存體使用。

7. Azure Log Analytics 工作區會針對來自 Azure 監視器的應用程式記錄和計量套用 Kusto 查詢，以進行疑難排解和深入診斷。

元件

• Azure Data Lake 儲存體 是一組專用於巨量資料分析的功能。
• Azure 事件方格可讓開發人員輕鬆地使用事件架構建置應用程式。
• Azure 佇列儲存體是用來儲存大量訊息的服務。 它允許透過使用 HTTP 或 HTTPS 的已驗證呼叫，從世界各地存取訊息。 您可以使用佇列來建立待處理工作待辦專案，以非同步方式處理。
• Azure Databricks 是針對 Azure 雲端平臺優化的資料分析平臺。 Azure Databricks 為開發資料密集型應用程式的兩個環境之一是 Azure Databricks Workspace ，這是 Apache Spark 型整合分析引擎，可用於大規模資料處理。
• Azure 監視器 會收集和分析應用程式遙測，例如效能計量和活動記錄。
• Azure Log Analytics 是一種工具，可用來編輯及執行具有資料的記錄查詢。

案例詳細資料

您的開發小組可以使用可觀察性模式和計量來尋找瓶頸，並改善巨量資料系統的效能。 您的小組必須對大規模應用程式上的大量計量串流執行負載測試。

此案例提供效能微調的指引。 由於此案例會對每位客戶進行記錄呈現效能挑戰，因此會使用 Azure Databricks，以健全方式監視這些專案：

• 自訂應用程式計量
• 串流查詢事件
• 應用程式記錄訊息

Azure Databricks 可以將此監視資料傳送至不同的記錄服務，例如 Azure Log Analytics。

此案例概述一組由客戶分組並儲存在 GZIP 封存檔案中的大型資料擷取。 在即時 Apache Spark™ 使用者介面之外，Azure Databricks 無法使用詳細的記錄，因此您的小組需要一種方式來儲存每位客戶的所有資料，然後進行基準測試和比較。 在大型資料案例中，請務必尋找最佳組合執行程式集區和虛擬機器 （VM） 大小，以取得最快的處理時間。 在此商務案例中，整體應用程式會依賴擷取和查詢需求的速度，讓系統輸送量不會意外地隨著工作量增加而降低。 此案例必須保證系統符合與客戶建立的服務等級協定（SLA）。

潛在的使用案例

可受益于此解決方案的案例包括：

• 系統健康情況監視。
• 效能維護。
• 監視日常系統使用量。
• 找出在未解決時可能導致未來問題的趨勢。

考量

這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。

考慮此架構時，請記住下列幾點：

• Azure Databricks 可以自動設定大型作業所需的運算資源，以避免其他解決方案所引進的問題。 例如，在 Apache Spark 上使用 Databricks 優化的自動調整，過度布建可能會導致資源的次佳使用。 或者，您可能不知道作業所需的執行程式數目。

• Azure 佇列儲存體中的佇列訊息大小最多可達 64 KB。 佇列可能包含數百萬個佇列訊息，最多可達儲存體帳戶的總容量限制。

成本最佳化

成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素 概觀。

使用 Azure 定價計算機 來預估實作此解決方案的成本。

部署此案例

若要取得程式的所有記錄和資訊，請設定 Azure Log Analytics 和 Azure Databricks 監視程式庫。 監視程式庫會將 Apache Spark 層級事件和 Spark 結構化串流計量從您的作業串流至 Azure 監視器。 您不需要對這些事件和計量對應用程式程式碼進行任何變更。

為巨量資料系統設定效能微調的步驟如下：

1. 在Azure 入口網站中， 建立 Azure Databricks 工作區 。 複製並儲存 Azure 訂用帳戶識別碼（GUID）、資源組名、Databricks 工作區名稱和工作區入口網站 URL 以供稍後使用。

2. 在網頁瀏覽器中，移至 Databricks 工作區 URL 並 產生 Databricks 個人存取權杖 。 複製並儲存出現的權杖字串（開頭 dapi 為 和 32 個字元的十六進位值），以供稍後使用。

3. 將 mspnp/spark-monitoring GitHub 存放庫複製到本機電腦。 此存放庫具有下列元件的原始程式碼：

   • 用來建立 Azure Log Analytics 工作區的 Azure Resource Manager （ARM） 範本，也會安裝預先建置的查詢以收集 Spark 計量
   • Azure Databricks 監視程式庫
   • 將應用程式計量和應用程式記錄從 Azure Databricks 傳送至 Azure 監視器的範例應用程式

4. 使用 Azure CLI 命令部署 ARM 範本， 建立具有預先建置 Spark 計量查詢 的 Azure Log Analytics 工作區。 從命令輸出中，複製並儲存新 Log Analytics 工作區產生的名稱（格式 為 spark-monitoring-randomized-string >< ）。

5. 在Azure 入口網站中，複製並儲存您的 Log Analytics 工作區識別碼和金鑰 ，以供稍後使用。

6. 安裝 IntelliJ IDEA 的 Community Edition，這是一種整合式開發環境 （IDE），其內建支援 JAVA 開發工具組 （JDK） 和 Apache Maven 。 新增 Scala 外掛程式 。

7. 使用 IntelliJ IDEA 建 置 Azure Databricks 監視程式庫 。 若要執行實際的建置步驟，請選取 [檢視 > 工具 Windows > Maven ] 以顯示 [Maven 工具] 視窗，然後選取 [ 執行 Maven 目標 > mvn 套件]。

8. 使用 Python 套件安裝工具，安裝 Azure Databricks CLI ，並使用您稍早複製的 Databricks 個人存取權杖設定驗證。

9. 使用您稍早複製的 Databricks 和 Log Analytics 值來修改 Databricks init 腳本，然後使用 Azure Databricks CLI 將 init 腳本和 Azure Databricks 監視程式庫複製到 Databricks 工作區，以設定 Azure Databricks 工作區。

10. 在您的 Databricks 工作區入口網站中， 建立及設定 Azure Databricks 叢集 。

11. 在 IntelliJ IDEA 中， 使用 Maven 建置範例應用程式 。 然後在 Databricks 工作區入口網站中，執行範例應用程式以產生 Azure 監視器的範例記錄和計量。

12. 在 Azure Databricks 中執行範例作業時，請移至 Azure 入口網站，以在 Log Analytics 介面 中 檢視和查詢事件種類（應用程式記錄和計量）：

    1. 選取 [資料表 > 自訂記錄 ] 以檢視 Spark 接聽程式事件的資料表架構（ SparkListenerEvent_CL ）、Spark 記錄事件（ SparkLoggingEvent_CL ），以及 Spark 計量（ SparkMetric_CL）。
    2. 選取 [查詢 > 總管] [已儲存的 查詢 > Spark 計量]，以檢視並執行您在建立 Log Analytics 工作區時新增的查詢。

    在下一節中深入瞭解如何檢視和執行預先建置和自訂查詢。

查詢 Azure Log Analytics 中的記錄和計量

存取預先建置的查詢

下列列出擷取 Spark 計量的預先建置查詢名稱。

撰寫自訂查詢

您也可以在 Kusto 查詢語言 （KQL） 中 撰寫自己的查詢。 只要選取可編輯的頂端中間窗格，然後自訂查詢以符合您的需求。

下列兩個查詢會從 Spark 記錄事件提取資料：

SparkLoggingEvent_CL | where logger_name_s contains "com.microsoft.pnp"

SparkLoggingEvent_CL
| where TimeGenerated > ago(7d)
| project TimeGenerated, clusterName_s, logger_name_s
| summarize Count=count() by clusterName_s, logger_name_s, bin(TimeGenerated, 1h)

這兩個範例是 Spark 計量記錄檔上的查詢：

SparkMetric_CL
| where name_s contains "executor.cpuTime"
| extend sname = split(name_s, ".")
| extend executor=strcat(sname[0], ".", sname[1])
| project TimeGenerated, cpuTime=count_d / 100000

SparkMetric_CL
| where name_s contains "driver.jvm.total."
| where executorId_s == "driver"
| extend memUsed_GB = value_d / 1000000000
| project TimeGenerated, name_s, memUsed_GB
| summarize max(memUsed_GB) by tostring(name_s), bin(TimeGenerated, 1m)

查詢術語

下表說明建構應用程式記錄和計量查詢時所使用的一些詞彙。

下列各節包含此案例中用於監視系統輸送量、Spark 作業執行狀態和系統資源使用量的一般計量。

系統輸送量

Spark 作業執行狀態

系統資源使用量

決定如何將合併成 GZIP 封存檔案的客戶輸入與特定的 Azure Databricks 輸出檔案產生關聯，因為 Azure Databricks 會將整個批次作業當作一個單位來處理。 在這裡，您會將細微性套用至追蹤。 您也可以使用自訂計量，將一個輸出檔追蹤至原始輸入檔。

如需每個計量的詳細定義，請參閱 此網站上的儀表板 中的視覺效果，或參閱 Apache Spark 檔中的計量 一節。

評估效能微調選項

基準定義

您和開發小組應該建立基準，以便比較應用程式的未來狀態。

以數量方式測量應用程式的效能。 在此案例中，關鍵計量是作業延遲，通常是大部分資料前置處理和擷取。 嘗試加速資料處理時間，並專注于測量延遲，如下圖所示：

測量作業的執行延遲：整體作業效能的粗略檢視，以及從開始到完成的作業執行持續時間（微批次時間）。 在上圖中，在 19：30 標記處，處理作業需要大約 40 秒的時間。

如果您進一步瞭解這 40 秒，您會看到下列資料以取得階段：

在 19：30 的標記中，有兩個階段：橙色階段為 10 秒，綠色階段為 30 秒。 監視階段尖峰，因為尖峰表示階段中的延遲。

調查特定階段的執行速度緩慢。 在資料分割案例中，通常至少有兩個階段：一個階段可讀取檔案，另一個階段用來隨機顯示、分割和寫入檔案。 如果您在寫入階段大多有高階段延遲，在資料分割期間可能會發生瓶頸問題。

觀察工作當作業中的階段會循序執行，而先前的階段會封鎖後續階段。 在階段內，如果某個工作執行隨機分割區的速度比其他工作慢，叢集中的所有工作都必須等候較慢的工作完成，讓階段完成。 然後工作就是監視資料扭曲和可能瓶頸的方法。 在上圖中，您可以看到所有工作平均分散。

現在監視處理時間。 因為您有串流案例，請查看串流輸送量。

在上述串流輸送量/批次延遲圖表中，橙色線條代表輸入速率（每秒輸入資料列）。 藍色線條代表處理速率（每秒處理的資料列數）。 在某些時候，處理速率不會擷取輸入速率。 潛在的問題是輸入檔案堆積在佇列中。

因為處理速率與圖形中的輸入速率不符，因此請查看改善處理速率以完整涵蓋輸入速率。 其中一個可能的原因是導致瓶頸的每個分割區索引鍵中的客戶資料不平衡。 如需下一個步驟和潛在解決方案，請利用 Azure Databricks 的延展性。

資料分割調查

首先，進一步識別 Azure Databricks 所需的調整執行程式數目。 套用在執行中執行程式中，以專用 CPU 指派每個分割區的經驗法則。 例如，如果您有 200 個分割區索引鍵，CPU 數目乘以執行程式的數目應該等於 200。 （例如，與 25 個執行程式結合的八個 CPU 是一個很好的比對。使用 200 個分割區索引鍵時，每個執行程式只能處理一項工作，以減少瓶頸的機會。

由於此案例中有一些緩慢的資料分割，因此請調查工作期間的高差異。 檢查工作工期的任何尖峰。 一個工作會處理一個分割區。 如果工作需要更多時間，分割區可能會太大並造成瓶頸。

錯誤追蹤

新增錯誤追蹤的儀表板，讓您可以找出客戶特定的資料失敗。 在資料前置處理中，有時候檔案已損毀，且檔案內的記錄不符合資料架構。 下列儀表板會擷取許多不正確的檔案和不良記錄。

此儀表板會顯示用於偵錯的錯誤計數、錯誤訊息和工作識別碼。 在訊息中，您可以輕鬆地將錯誤追蹤回錯誤檔案。 讀取時發生數個檔案錯誤。 您可以檢閱頂端時間軸，並在圖表中特定點調查 （16：20 和 16：40）。

其他瓶頸

如需更多範例和指引，請參閱 針對 Azure Databricks 中的效能瓶頸進行疑難排解。

效能微調評估摘要

在此案例中，這些計量識別出下列觀察：

• 在階段延遲圖表中，寫入階段需要大部分的處理時間。
• 在工作延遲圖表中，工作延遲是穩定的。
• 在串流輸送量圖表中，輸出速率低於某個點的輸入速率。
• 在任務的工期資料表中，由於客戶資料不平衡，因此工作差異。
• 若要在資料分割階段取得優化的效能，調整執行程式的數目應該符合資料分割的數目。
• 有追蹤錯誤，例如不正確的檔案和不正確的記錄。

若要診斷這些問題，您使用了下列計量：

• 作業延遲
• 階段延遲
• 工作延遲
• 串流輸送量
• 每個階段的任務工期（最大值、平均數、最小值）
• 錯誤追蹤（計數、訊息、工作識別碼）

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

• David McGhee |主體計畫管理員

若要查看非公用LinkedIn設定檔，請登入 LinkedIn。

下一步

• 閱讀 Log Analytics 教學課程 。
• 在 Azure Log Analytics 工作區中監視 Azure Databricks
• 使用 Spark 計量部署 Azure Log Analytics
• 可觀察性模式

相關資源

• 傳送 Azure Databricks 應用程式記錄檔至 Azure 監視器
• 使用儀表板將 Azure Databricks 計量視覺化
• 監視雲端應用程式的最佳做法
• 重試模式