

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 將規劃開銷降至最低
<a name="minimize-planning-overhead"></a>

如 [Apache Spark 中討論的關鍵主題](key-topics-apache-spark.md)所述，Spark 驅動程式會產生執行計畫。根據該計畫，任務會指派給 Spark 執行器以進行分散式處理。不過，如果有大量小型檔案或 包含大量分割區， AWS Glue Data Catalog Spark 驅動程式可能會成為瓶頸。若要識別高規劃開銷，請評估下列指標。

## CloudWatch 指標
<a name="overhead-metrics"></a>

檢查** CPU 負載**和**記憶體使用率**是否有下列情況：
+ Spark 驅動程式 **CPU 負載**和**記憶體使用率**會記錄為高。一般而言，Spark 驅動程式不會處理您的資料，因此 CPU 負載和記憶體使用率不會遽增。不過，如果 Amazon S3 資料來源有太多小型檔案，列出所有 S3 物件和管理大量任務可能會導致資源使用率過高。
+ 在 Spark 執行器中開始處理之前有很長的間隙。在下列範例螢幕擷取畫面中，Spark 執行器的 CPU 負載太低，直到 10：57，即使 AWS Glue 任務是從 10：00 開始。這表示 Spark 驅動程式可能需要很長的時間才能產生執行計畫。在此範例中，擷取 Data Catalog 中的大量分割區，並列出 Spark 驅動程式中的大量小型檔案需要很長的時間。

    
![\[顯示驅動程式和執行器的圖表。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/images/cpu-load-2.png)

## Spark 使用者介面
<a name="overhead-spark"></a>

在 Spark UI 的任務****索引標籤上，您可以看到**提交**的時間。在下列範例中，Spark 驅動程式在 10：56：46 啟動 job0，即使 AWS Glue 任務在 10：00：00 啟動。



![\[""\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/images/jobs.png)


您也可以在**任務索引標籤上查看任務 （所有階段）：成功/總**時間。 ****在此情況下，任務數量會記錄為 `58100`。如[平行處理任務](parallelize-tasks.md)頁面的 Amazon S3 一節中所述，任務數量大約對應至 S3 物件數量。這表示 Amazon S3 中大約有 58，100 個物件。

如需此任務和時間軸的詳細資訊，請檢閱**階段**索引標籤。如果您發現 Spark 驅動程式存在瓶頸，請考慮下列解決方案：
+ 當 Amazon S3 有太多檔案時，請考慮[平行處理任務](parallelize-tasks.md)頁面的*太多分割區*區段中有關過度平行處理的指引。
+ 當 Amazon S3 有太多分割區時，請考慮[減少資料掃描](reduce-data-scan.md)頁面的*太多 Amazon S3 分割區*區段中有關過度分割區的指引。如果有許多分割區可降低從 Data Catalog 擷取分割區中繼資料的延遲，請啟用[AWS Glue 分割區索引](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)。如需詳細資訊，請參閱[使用 AWS Glue 分割區索引改善查詢效能](https://aws.amazon.com/blogs/big-data/improve-query-performance-using-aws-glue-partition-indexes/)。
+ 當 JDBC 有太多分割區時，請降低該`hashpartition`值。
+ 當 DynamoDB 有太多分割區時，請降低該`dynamodb.splits`值。
+ 當串流任務具有太多分割區時，請降低碎片的數量。