本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# DPU 容量規劃監控
您可以在 中使用任務指標 AWS Glue 來估計可用於向外擴展AWS Glue任務的資料處理單位 (DPUs) 數量。
**注意**
此頁面僅適用於 AWS Glue 0.9 和 1.0 版。較新版本的 AWS Glue 包含節省成本的功能，這些功能會在容量規劃時帶來額外的考量。
**Topics**
+ [已分析的程式碼](#monitor-debug-capacity-profile)
+ [在 AWS Glue 主控台上視覺化已分析的指標](#monitor-debug-capacity-visualize)
+ [判斷最佳 DPU 容量](#monitor-debug-capacity-fix)
## 已分析的程式碼
以下指令碼會讀取包含 428 個 gzip JSON 檔案的 Amazon Simple Storage Service (Amazon S3) 分割區。該指令碼套用對應來變更欄位名稱，並以 Apache Parquet 格式將它們轉換並寫入 Amazon S3。您將根據預設佈建 10 個 DPU 並執行此任務。
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet")
```
## 在 AWS Glue 主控台上視覺化已分析的指標
**任務執行 1：**在此任務執行中，我們將展示如何尋找叢集中是否存在佈建不足的 DPU。在 AWS Glue 中的任務執行功能顯示所有主動執行的執行器[數量](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors)、完成階段的[數量](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages)，以及所需執行器的最大[數量](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors)。
所需執行器最大數量的計算，是透過新增執行中任務和待處理任務總數除以每個執行器的任務。該結果是滿足目前負載所需的執行器總數的測量。
相反的，主動執行的執行器數量，會衡量有多少執行器正在執行主動 Apache Spark 任務。隨著任務的進行，所需的最大執行器可以更改，並且通常會在等待中的任務佇列降低時向下移動到任務的末端。
下圖中的水平紅線顯示了分配執行器的最大數量，這取決於您為任務分配的 DPU 數。在本例中，您需要為該任務執行分配 10 個 DPU。一個 DPU 保留給管理使用。另外九個 DPU 則會分別執行兩個執行器，且會保留其中一個執行器給 Spark 驅動程式。Spark 驅動程式會在主要應用程式內執行。因此，分配的執行器最大數量是 2\*9 - 1 = 17 個執行器。
如圖所示，所需執行器的最大數量在任務開始時從 107 開始，而中動執行器數量保持為 17。這與具有 10 個 DPU 的分配執行器最大數量相同。所需執行器最大數量和所分配執行器最大數量間的比率 (對於 Spark 驅動程式，兩者都新增 1 個) 會提供佈建不足因數：108/18 = 6 倍。您可以佈建 6 (佈建不足比率) \*9 (目前 DPU 容量 - 1) \+ 1 個 DPU = 55 個 DPU 來擴展該任務，即可以最高平行處理速度執行並加速完成。
AWS Glue 主控台會以靜態線 (表示分配執行器原始數量上限) 顯示詳細的任務指標。該主控台會透過指標的任務定義來計算分配執行器的上限。相反地，如需詳細任務執行指標，主控台會透過任務執行組態來計算分配執行器的上限，特別是針對任務執行分配的 DPU 數。若要檢視個別任務執行的指標，請選取任務執行並選擇 **View run metrics (檢視執行指標)**。
查看 Amazon S3 位元組[讀取](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes)和[寫入](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes)，請注意，該任務會在 Amazon S3 資料中花費所有的六分鐘串流，並將其平行寫出。分配的 DPU 上的所有核心都正在讀取和寫入 Amazon S3。所需執行器的最大數量為 107，也符合輸入 Amazon S3 路徑中的檔案數 – 428。每個執行器可以啟動四個 Spark 任務以處理四個輸入檔案 (JSON gzip)。
## 判斷最佳 DPU 容量
根據先前任務執行的結果，您可以將分配的 DPU 總數增加到 55，並查看任務的執行情況。該任務可在三個分鐘內完成 – 是先前所需時間的一半。此案例中的任務擴展並非線性的，因為它是一種短期執行任務。具有長期執行任務或大量任務的任務 (大量的最大所需執行器) 受益於接近線性的 DPU 擴展效能加速。
如上圖所示，主動執行器的總數達到最大分配數 – 107 個執行器。同樣地，所需執行器的最大數量永遠不會超過分配的執行器最大數量。所需的最大執行器數量是根據主動執行和等待中任務計數計算的，因此可能小於活動執行器的數量。這是因為可能有執行器在短時間內部分或完全閒置，且尚未淘汰。
此任務執行使用 6 倍以上的執行器從 Amazon S3 平行讀取和寫入。因此，此任務執行會為讀取和寫入使用更多的 Amazon S3 頻寬，並且更快完成。
### 識別過度佈建的 DPU
接下來，您可以判斷使用 100 DPU (99 \* 2 = 198 執行器) 擴展任務是否有助於進一步擴展。如下圖顯示，該任務仍然需要三分鐘來完成。同樣，任務不會超出 107 個執行器 (55 個 DPU 組態)，其餘 91 個執行器被過度佈建而完全不使用。這表示增加的 DPU 數量有時可能無法提高效能，這從所需的最大執行器數量中可以看出。
### 比較時間差異
下表中顯示的三個任務執行總結了 10 個 DPU、55 個 DPU 和 100 個 DPU 的任務執行時間。您可以使用監控第一個任務執行建立的評估來尋找 DPU 容量以改善任務執行時間。
| 任務 ID | DPU 數量 | 執行時間 |
| --- | --- | --- |
| jr\_c894524c8ef5048a4d9... | 10 | 6 分鐘。 |
| jr\_1a466cf2575e7ffe6856... | 55 | 3 分鐘。 |
| jr\_34fa1ed4c6aa9ff0a814... | 100 | 3 分鐘。 |