Amazon DEA-C01: データ変換と処理 — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

こちらの一部です： Amazon Data Engineer Associate DEA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

大規模処理のためのAmazon EMR

EMRは、カスタマイズ可能で大規模なビッグデータ処理（Spark、Hadoop、Presto、Flink）に最適なサービスです。クラスタレベルの制御、カスタムブートストラップアクション、または特殊なライブラリが必要な場合に使用されます。クラスタはCLIのaws emr create-clusterで作成し、--instance-groupsまたは--instance-fleetsのいずれかを選択します。インスタンスフリートは、柔軟なインスタンスタイプの組み合わせとスポット/オンデマンドの組み合わせを提供します。インスタンスグループは、よりシンプルで固定サイズのグループです。

考慮すべきEMRクラスタのパターン：

• 一時的なクラスタ（Transient clusters）: --auto-terminateを指定して起動し、ステップをサブミットすると、ステップ完了時にクラスタが終了します。コスト管理には適していますが、終了時に一時的なHDFSとローカルの状態は失われます。
• 長時間実行クラスタ（Long-running clusters）: 自動終了しません。対話的なワークロード、永続的なHDFS、または多くの小さなジョブがJVMのウォームアップから恩恵を受ける場合に使用します。クラスタの終了が想定される場合は、重要なデータをS3またはEBSをバックエンドとするHadoopストレージに永続化してください。

設定例：

• インスタンスグループのCLI: aws emr create-cluster --name Prod --release-label emr-6.6.0 --use-default-roles --instance-groups InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=4
• インスタンスフリートのCLIは--instance-fleetsを使用し、OnDemand/Spotの割り当てと複数のインスタンスタイプを指定して、回復性とコスト最適化を実現します。

Hadoopエコシステムコンポーネントに対する完全な制御、カスタムブートストラップスクリプト、または中間データのための永続的なHDFSが必要な場合はEMRを使用してください。それ以外の場合、Glueデータカタログと統合されたマネージドSpark ETLには、よりシンプルなGlue Sparkが適しています。

Glue DataBrewとビジュアルな変換

Glue DataBrewは、対話的に作業するデータアナリストやエンジニアを対象とした、データプロファイリング、クレンジング、変換のための視覚的なノーコード/ローコードツールです。S3またはGlueカタログからデータセットを作成し、コンソールで変換のレシピを構築し、サンプルでプレビューした後、ジョブを実行してレシピを大規模に適用します。DataBrewジョブはスケジュール実行するか、CLIのaws databrew start-job-run --name my-databrew-jobで実行できます。

DataBrewは、標準化、重複排除、型変換、組み込み関数による列レベルの変換といったデータ準備タスクに最適化されています。Glueカタログと統合され、出力はS3に書き込まれます。ビジネスユーザーがセルフサービスでのクリーニングや迅速なプロファイリングを必要とする場合はDataBrewを選択してください。重い変換ロジック、複雑な結合、または非常に大規模なデータセットには、Glue SparkまたはEMRが適しています。

ビジュアルベースとコードベースの変換の比較：

• Glue DataBrew
  • 長所: 迅速なプロファイリング、レシピベース、コーディング経験のないユーザーでもパイプラインを構築可能、統合されたスケジューリング。
  • 短所: 非常に大規模または非常に複雑な分散結合やカスタムライブラリには不向き。
• Glue Spark / EMR
  • 長所: 完全なプログラムによる制御、巨大なデータセットの処理、サードパーティライブラリのサポート。
  • 短所: 開発者のスキルとより多くの設定が必要。

よくある落とし穴と判断基準

• GlueジョブブックマークがJDBCソースで機能すると想定すること — ブックマークはS3オブジェクト/パーティションの状態のみを追跡します。JDBCの増分ロードには、ウォーターマーク列、変更データキャプチャ（CDC）を使用するか、進捗をDynamoDB/S3に保存してください。
• 一時的なEMRクラスタをステートフルなシステムのように扱うこと — 一時的なクラスタはステップ完了後に終了し、HDFSを失います。中間データはS3に永続化するか、耐久性のあるストレージとしてEBSボリュームを使用してください。
• ストリーミングパイプラインにおけるLambdaのコールドスタートを無視すること — コールドスタートはレイテンシーを増加させます。クリティカルパスではプロビジョニングされた同時実行で緩和するか、厳格な低レイテンシー要件のためには長時間実行されるコンピューティングを使用してください。
• Glue Pythonシェルで大規模な変換を実行すること — Pythonシェルジョブは1 DPUに制限されています。大規模なデータセットには、適切なworkerType/NumberOfWorkersを指定したGlue Sparkジョブを使用してください。
• EMRインスタンスタイプの不適切な設定: コストと柔軟性を重視しスポットインスタンスを活用する場合はインスタンスフリートを選択します。予測可能なインスタンス構成が必要な場合はインスタンスグループを使用します。
• 緊急のワークロードにGlue Flexを過度に使用すること — FLEXはコストを削減しますが、開始時間が遅れる可能性があります。予測可能な開始時間と実行時間が必要な場合はSTANDARDを使用してください。

実践的な問題：ユースケースシナリオ

AcmeRetail社は、夜間のクリックストリームParquetファイルを統合された顧客アクティビティテーブルに処理しており、緊急でないバックフィル（履歴データ補填）のコストを低く抑えつつ、何ヶ月分ものデータを再処理することを避けるために増分処理を望んでいます。

1. S3のパーティションレイアウト（year=/month=/day=）を使用し、Glueデータカタログにデータセットを登録します。
2. スキーマの柔軟性のためにDynamicFrame.from_catalogを読み取り、マッピングを適用し、複雑な結合のためにDataFrameに変換し、パーティション化されたParquetをS3に書き戻すGlue Sparkジョブ（glueetl）を作成します。
3. 夜間実行のためにGlueジョブブックマーク（job-bookmark-enable）を有効にし、新しいパーティションのみを処理します。JDBCによるエンリッチメントソースについては、処理済みの最大タイムスタンプを追跡するために、DynamoDBに永続化されたウォーターマーク列を実装します。
4. 定期的な夜間実行にはExecutionClass=STANDARDを使用します。緊急でない履歴データの再処理には、--execution-class FLEXで実行をサブミットしてコストを節約します。
5. CloudWatchメトリクスで監視し、ジョブの失敗に対してアラームを設定します。非常に大規模な処理やカスタムライブラリが必要な場合は、中間結果をS3に書き込み、自動終了するEMRの一時的なクラスタを検討します。

根拠: このアプローチは、スケーラブルな変換のためにGlueのマネージドSparkと半構造化入力のためのDynamicFrameを活用し、S3の増分処理にジョブブックマークを使用し、バックフィルのコストを削減するためにFLEXを使用することで、コスト、信頼性、運用上のシンプルさを維持します。

← データカタログ化とメタデータ管理 · すべてのドメイン · データオーケストレーションとワークフロー管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →