翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ベストプラクティス
<a name="best-practices"></a>

AWS Glue を使用して開発するときは、次のベストプラクティスを考慮します。

## まずローカルで開発します。
<a name="run-locally"></a>

ETL ジョブの構築にかかるコストと時間を節約するには、まずコードとビジネスロジックをローカルでテストします。シェルと統合開発環境 (IDE) の両方で AWS Glue ETL ジョブをテストするのに役立つ Docker コンテナのセットアップ手順については、ブログポスト[「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 インタラクティブセッションは、PyCharm、IntelliJ、VS Code などのノートブックおよび IDE と統合するオープンソースの Jupyter カーネルと統合できるサーバーレスの Spark バックエンドを提供します。インタラクティブセッションを使用すると、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 パスとストレージクラスを除外する
+ スパークと 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>

水平スケール (ワーカー数の変更) や垂直スケール (ワーカータイプの変更) のタイミングを理解することは、ETL ジョブのコストやパフォーマンスに影響を与えかねないため、AWS Glue にとって重要です。

一般に、変換が複雑な ETL ジョブはメモリを大量に消費し、垂直スケーリング (たとえば G.1X から G.2X ワーカータイプへの移行) が必要です。AWS Glue は複数のノードで並列にデータを処理するように設計されているため、大量のデータを扱う計算集約的な ETL ジョブの場合は、水平スケーリングを推奨します。

Amazon CloudWatch で AWS Glue ジョブメトリクスを綿密に監視すると、パフォーマンスのボトルネックの原因がメモリ不足かコンピューティング不足かを判断するのに役立ちます。AWS Glue ワーカーの種類とスケーリングの詳細については、[「AWS Glue によるApache Spark ジョブのスケーリングとデータ分割のベストプラクティス」](https://aws.amazon.com/blogs/big-data/best-practices-to-scale-apache-spark-jobs-and-partition-data-with-aws-glue/)を参照してください。