本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 最佳实践
<a name="best-practices"></a>

使用 AWS Glue 开发时，请考虑采用以下最佳实践。

## 先在本地开发
<a name="run-locally"></a>

为了在构建 ETL 作业时节省成本和时间，请先在本地测试您的代码和业务逻辑。有关设置 Docker 容器以帮助您在 Shell 和集成式开发环境 (IDE) 中测试 AWS Glue ETL 作业的说明，请参阅博客文章[使用 Docker 容器在本地开发和测试 AWS Glue 作业](https://aws.amazon.com/blogs/big-data/develop-and-test-aws-glue-version-3-0-jobs-locally-using-a-docker-container/)。

## 使用 AWS Glue 交互式会话
<a name="dev-endpoint"></a>

AWS Glue 交互式会话提供了一个无服务器的 Spark 后端，以及一个与 PyCharm、IntelliJ 和 VS Code 等笔记本和 IDE 集成的开源 Jupyter 内核。通过使用交互式会话，您可以使用 AWS Glue Spark 后端和您选择的 IDE 在真实数据集上测试代码。要开始使用，请[按照 AWS Glue 交互式会话入门](https://docs.aws.amazon.com/glue/latest/dg/interactive-sessions.html)中的步骤操作。

## 使用分区来查询您需要的确切内容
<a name="partitioning"></a>

*分区*是指根据特定的列或键将大型数据集划分为较小的分区。对数据进行分区后，AWS Glue 可以对满足特定分区标准的数据子集执行选择性扫描，而不是扫描整个数据集。这样可以更快、更高效地处理查询，尤其是在处理大型数据集时。

根据将要针对数据运行的查询对数据进行分区。例如，如果大多数查询都针对特定列进行筛选，则对该列进行分区可以显著缩短查询时间。要了解有关分区数据的更多信息，请参阅 AWS Glue 中的[使用分区数据工作](https://aws.amazon.com/blogs/big-data/work-with-partitioned-data-in-aws-glue/)。

## 优化内存管理
<a name="memory"></a>

在编写 AWS Glue ETL 作业时，内存管理至关重要，因为它们在 Apache Spark 引擎上运行，而该引擎针对内存中处理进行了优化。博客文章《[在 AWS Glue 中优化内存管理](https://aws.amazon.com/blogs/big-data/optimize-memory-management-in-aws-glue/)》详细介绍了以下内存管理技术：
+ AWS Glue 的 Amazon S3 列表实施
+ 分组
+ 不包括不相关的 Amazon S3 路径和存储类别
+ Spark 和 AWS Glue 读取分区
+ 批量插入
+ 连接优化
+ PySpark 用户定义函数 (UDF)
+ 增量处理

## 使用高效的数据存储格式
<a name="storage-formats"></a>

在创作 ETL 作业时，建议以基于列的数据格式输出转换后的数据。列式数据格式，例如 Apache Parquet 和 ORC，通常用于大数据存储和分析。它们旨在最大限度地减少数据移动并最大限度地提高压缩率。这些格式还允许将数据拆分到多个读取器，从而在查询处理期间增加并行读取。

压缩数据还有助于减少存储的数据量，并提高读/写操作性能。AWS Glue 原生支持多种压缩格式。有关高效数据存储和压缩的更多信息，请参阅[构建高性能的数据管道](https://docs.aws.amazon.com/whitepapers/latest/aws-glue-best-practices-build-performant-data-pipeline/building-a-performance-efficient-data-pipeline.html#file-formats-and-data-compression)。

## 使用适当的扩展类型
<a name="scaling"></a>

了解何时进行水平扩展（更改员工人数）或垂直扩展（更改员工类型）对于 AWS Glue 非常重要，因为这会影响 ETL 工作的成本和绩效。

通常，具有复杂转换的 ETL 作业的内存密集度更高，需要垂直扩展（例如，从 G.1X 工作线程类型迁移到 G.2X 工作线程类型）。对于包含大量数据的计算密集型 ETL 作业，建议进行横向扩展，因为 AWS Glue 旨在跨多个节点并行处理这些数据。

密切监控 Amazon CloudWatch 中的 AWS Glue 作业指标可帮助您确定性能瓶颈是由内存不足还是计算不足引起的。有关 AWS Glue 工作线程类型和扩展的更多信息，请参阅[扩展 Apache Spark 作业和 AWS Glue 对数据进行分区的最佳实践](https://aws.amazon.com/blogs/big-data/best-practices-to-scale-apache-spark-jobs-and-partition-data-with-aws-glue/)。