ベストプラクティス

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

まずローカルで開発します。

ETL ジョブの構築にかかるコストと時間を節約するには、まずコードとビジネスロジックをローカルでテストします。シェルと統合開発環境 (IDE) の両方で AWS Glue ETL ジョブをテストするのに役立つ Docker コンテナのセットアップ手順については、ブログポスト「Docker コンテナを使って AWS Glue ジョブをローカルで開発・テストする」 を参照してください。

AWS Glue インタラクティブセッションを利用する

AWS Glue インタラクティブセッションは、PyCharm、IntelliJ、VS Code などのノートブックおよび IDE と統合するオープンソースの Jupyter カーネルと統合できるサーバーレスの Spark バックエンドを提供します。インタラクティブセッションを使用すると、AWS Glue Spark バックエンドと任意の IDE を使用して、実際のデータセットでコードをテストできます。開始するには、「AWS Glue インタラクティブセッション入門」の手順に従ってください。

パーティショニングを使用して、必要なものを正確にクエリします。

パーティショニングとは、大きなデータセットを特定の列やキーに基づいて小さなパーティションに分割することです。データがパーティショニングされている場合、AWS Glue はデータセット全体をスキャンするのではなく、特定のパーティショニング基準を満たすデータのサブセットに対して選択的スキャンを実行できます。これにより、特に大きなデータセットを扱う場合に、クエリ処理がより速く、より効率的になります。

そのデータに対して実行されるクエリに基づいてデータを分割します。たとえば、ほとんどのクエリが特定の列でフィルタリングされている場合、その列を分割することでクエリ時間を大幅に短縮できます。データのパーティショニングについて詳しくは、「AWS Glue での分割データの処理」を参照してください。

メモリ管理を最適化する

AWS Glue ETL ジョブはインメモリ処理向けに最適化された Apache Spark エンジン上で実行されるため、メモリ管理は極めて重要です。ブログ記事「AWS Glue におけるメモリ管理の最適化」では、以下のメモリ管理手法について詳しく説明しています。

効率的なデータストレージ形式を使用する

ETL ジョブを作成する場合、変換されたデータを列ベースのデータ形式で出力することをおすすめします。Apache Parquet や ORC などの列指向データ形式は、ビッグデータの保存や分析によく使用されます。データの移動を最小限に抑え、圧縮率を最大化するように設計されています。これらのフォーマットはまた、クエリ処理中の並列読み取りを増やすために、複数のリーダーにデータを分割することも可能です。

データを圧縮すると、保存されるデータ量が減り、読み取り/書き込み操作のパフォーマンスが向上します。AWS Glue は複数の圧縮形式をネイティブにサポートします。効率的なデータ保存と圧縮について詳しくは、「パフォーマンス効率の高いデータパイプラインの構築」を参照してください。

適切なスケーリングタイプを使用する

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

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

Amazon CloudWatch で AWS Glue ジョブメトリクスを綿密に監視すると、パフォーマンスのボトルネックの原因がメモリ不足かコンピューティング不足かを判断するのに役立ちます。AWS Glue ワーカーの種類とスケーリングの詳細については、「AWS Glue によるApache Spark ジョブのスケーリングとデータ分割のベストプラクティス」を参照してください。