Amazon DEA-C01: データ品質、検証、可観測性 — 学習ガイド
こちらの一部です: Amazon Data Engineer Associate DEA-C01 — 学習ガイド. 検証済みの解答で練習: Amazon試験ハブ, または時間制限付き模擬試験に挑戦: ExamRoll.io.
このドメインは、データの正確性を保証し、異常を検出し、パイプラインの信頼性を維持するために使用されるエンドツーエンドのプラクティスとAWSサービスを対象としています。強力な検証と可観測性により、下流工程での不具合を減らし、SLAを遵守し、安全な再処理を可能にします。データエンジニアは、Glue Data Quality、検証フレームワーク、CloudWatchの異常検知、DLQ、べき等な設計を組み合わせて、堅牢なパイプラインを構築する必要があります。
AWS Glue Data Qualityのルールと評価
Glue Data Qualityは、Data Quality Definition Language (DQDL) のルールセットを使用して、データセットに関するアサーション(行数、NULLのしきい値、一意性、カスタムSQLチェックなど)を定義します。ルールセットは、コンソールまたはCLI(例:aws glue create-data-quality-ruleset --name MyRuleset --rules file://dqdl.json)で作成します。ルールセットは、Glue ETLジョブにアタッチするか、StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun APIを通じて独立して実行し、S3、カタログテーブル、またはGlue DynamicFramesに保存されたデータセットを評価できます。
主要な設定詳細と決定基準:
- DQDLの構造:ルールには、ruleName、expression(DQDLまたはSQL)、severity、および失敗時のアクションが含まれます。重要なチェックが失敗したときにジョブをFAILさせるには、失敗時のアクションを明示的に設定します。そうしないと、Glueは実行を失敗させずに結果をログに記録する場合があります。
- 評価コンテキスト:ジョブパラメータまたは評価実行の入力として、テーブルまたはS3パスの参照とサンプリングオプション(フルスキャン vs. サンプル)を提供し、コストとカバレッジのバランスを取ります。
- 出力:ルールの評価結果は、GlueメトリクスとAmazon S3にJSON形式で書き込まれます。これらのアーティファクトを監査や自動修復に利用します。
Glue Data Qualityと外部フレームワークの使い分け:
- Glueジョブやリネージにネイティブに統合される標準的なスキーマ、完全性、単純な一意性ルールには、Glue DQDLを使用します。
- より豊富なエクスペクテーションライブラリ、表現力豊かなチェック、または複数のシステム間で共有されるエクスペクテーションスイートが必要な場合は、Great Expectations(次のサブドメインを参照)を使用します。
パイプラインにおけるデータ検証パターン
検証は、イングレス、変換、シンクといった複数のタッチポイントで行われます。一般的なパターンは次のとおりです。
- パイプラインに入る前に、Lambda/Kinesisのプロデューサーでスキーマや基本的な値の範囲を軽量に事前チェックし、不正な行を拒否またはルーティングする。
- Glue ETL (Spark) ジョブ内で、DQDLルールセットとコード内の明示的な検証を用いたサーバーサイド検証を行う。Glue Studioでは、ルールセットを参照するData Qualityトランスフォームを追加します。CLIでは、
--arguments '{"--enable-glue-datacatalog":""}'を渡すか、ジョブパラメータに含めて評価実行をトリガーします。 - Glue Python ShellまたはGlue Sparkジョブに統合されたGreat Expectationsによる変換後検証を行う。エクスペクテーションをS3(
expectations/ディレクトリ)にデプロイし、S3のエクスペクテーションをジョブ環境に同期させた後、ジョブ内でDataContext(root_dir="/tmp/ge")を使用してDataContextをロードします。
検証オプションの比較:
- Glue DQDL
- 長所:ネイティブ統合、低い運用オーバーヘッド、結果をGlueカタログ/メトリクスに書き込む
- 短所:複雑な論理的エクスペクテーションには表現力が劣る
- Great Expectations
- 長所:豊富なエクスペクテーション、データドキュメント、統合されたチェックポイント、拡張可能なバックエンド
- 短所:S3でのエクスペクテーションアーティファクトのパッケージングと管理、およびGlueジョブでのオーケストレーションが必要
- コード(Spark/DataFrame)による手動チェック
- 長所:完全な柔軟性、カスタムロジックに対する高いパフォーマンス
- 短所:メンテナンス負荷が高い、追加作業なしでは標準化されたレポート作成ができない
ストリーミングの場合、処理中のレコードを検証し、失敗した場合は破棄するのではなく、SQS DLQ(AWS CLIまたはコンソールでmaxReceiveCountを持つRedrivePolicyを設定)にプッシュします。バッチの場合、検証レポートのアーティファクトを生成し、ポリシーに基づいて出力を失敗させるか隔離します。
異常検知とデータドリフトのモニタリング
オペレーショナルメトリクス(処理済みレコード数、エラー率、ジョブ実行時間)には、CloudWatchの異常検知を使用します。CLIで aws cloudwatch put-anomaly-detector --namespace "Glue" --metric-name "JobRunTime" --statistic "Average" --single-metric-anomaly-detector '{"MetricName":"JobRunTime","Namespace":"Glue","Stat":"Average","Dimensions":[...]}' を使用してディテクターを作成し、その異常検知帯を参照するCloudWatchアラームを作成します。データレベルのドリフト(分布の変化、NULL率の変動)については、Glue DataBrewのプロファイルジョブ(aws databrew create-profile-job)をスケジュール実行して統計、ヒストグラム、分位数を計算し、そのプロファイルをベースラインとしてS3に保存します。
異常検知アラームと静的しきい値アラームの決定基準:
- メトリクスのパターンに季節性がある、または変動する場合は、CloudWatchの異常検知を選択します。過去の振る舞いを学習し、手動でのしきい値チューニングを削減します。
- 予測可能性が高い二値的な条件(例:ジョブがX時間以上スタックしている)には、静的しきい値アラームを使用します。
自動ドリフト検出の場合:
- DataBrewのプロファイルジョブを定期的(データのベロシティに応じて日次/週次)にスケジュール実行し、メトリクスのベースライン(NULL率、カーディナリティ、パーセンタイル)を取得します。
- 新しいプロファイルの出力を、Glueのルールセット(カスタムSQLチェック)またはベースライン統計を参照するGreat Expectationsのカスタムエクスペクテーションのいずれかを使用して、ベースラインプロファイルと比較します。
- ドリフトがポリシーのしきい値を超えた場合、または異常検知ディテクターが異常なメトリクスの振る舞いを検出した場合に、SNS / EventBridgeを使用してアラートを送信します。
SLA管理とパイプラインの信頼性
SLA管理は、可観測性を修復と信頼性エンジニアリングに結びつけます。すべてのパイプラインに、スループット(レコード/秒)、レイテンシー(取り込み→シンク)、エラーレート、ジョブ/ランタイム、ダウンストリームのカウントといったベースラインメトリクスを実装してください。Glueジョブ(ジョブ実行メトリクス)、Kinesis/Kafkaのコンシューマーラグ、およびPutMetricData経由のカスタムアプリケーションメトリクスにはCloudWatch Metricsを使用します。
信頼性パターンと設定の詳細:
- デッドレターキュー(SQS DLQ):ストリーミングコンシューマー(Lambda、Kinesisコンシューマー)には、DLQを設定し、RedrivePolicy(maxReceiveCount)をセットします。DLQの保持期間と別の処理ジョブを使用して、DLQメッセージを検査し、再処理します。
- べき等な設計:シンクがべき等な書き込みをサポートするようにします。例:
- DynamoDB:PutItemを条件付き式またはべき等性トークンのための複合キーと共に使用します。
- S3:アトミックなリネームパターンで書き込むか、コンテンツベースのキー(レコードのハッシュ)を使用することで、リプレイが重複ではなく上書きするようにします。
- Redshift/Glue ETL:ステージングとキーによるMERGEを使用して、再処理後に重複排除します。
- チェックポイント:Kinesis/DynamoDBコネクタのチェックポイントを有効にし、コンシューマーのチェックポイント頻度を管理して、再処理ウィンドウと重複リスクのバランスを取ります。
リトライ vs フェイルファストの判断基準:
- 一時的な障害(ダウンストリームのスロットリングなど)に対しては、指数関数的バックオフ付きのリトライを実装し、最大リトライ回数を超えた後にのみDLQを使用します。
- データ品質の障害(スキーマの不一致など)に対しては、即座に失敗させ(フェイルファスト)、問題のあるレコードを隔離用のS3プレフィックスにメタデータと共に書き込み、手動レビューができるようにします。
一般的な落とし穴と判断基準
- Glue Data Qualityのルールは、デフォルトでは障害をログに記録するだけでジョブを失敗させません。重要なチェックに対しては、ルールのアクションをFAILに設定し、ルールセットの評価をジョブ実行にアタッチしてください。
- DLQのないストリーミングパイプラインは、失敗したレコードを破棄または失います。常にSQS DLQ(または永続的なS3ステージング)と、検査および再処理のための再駆動ポリシーを設定してください。
- べき等性なしの再処理は、重複レコードを生成します。決定論的なキーを設計するか、シンクでupsert/mergeセマンティクスを使用するか、S3にはコンテンツベースのオブジェクトキーを適用してください。
- ベースラインなしのデータドリフト検出は、ノイズの多いアラートを生成します。Glue DataBrewのプロファイルジョブをスケジュールしてベースライン統計を作成・保存し、新しいプロファイルをそれらと比較してください。
- 静的なCloudWatchのしきい値への過度な依存は、誤検知を引き起こします。季節性/変動性のあるメトリクスにはCloudWatchの異常検知を使用し、静的なしきい値は譲れない上限値のために確保してください。
- maxReceiveCountを高く設定しすぎると、DLQへのルーティングが遅れ、処理レイテンシーが増加します。永続的に失敗するメッセージがタイムリーにDLQに届くよう、賢明なmaxReceiveCountを選択してください。
実践的な問題:ユースケースシナリオ
Streamline Retail社は、夜間のETL後に頻繁にダウンストリームのレポートエラーに直面しています。具体的には、時折発生するスキーマの急な変化、サイレントなルール違反、失敗した実行を再処理した際の重複注文などです。
- スキーマ、nullのしきい値、order_idの一意性について、Glue Data Qualityルール(DQDL)を実装します。失敗時のアクションをジョブをFAILさせるように設定し、評価アーティファクトをS3に発行します。
- 複雑なビジネスチェック(テーブル間の注文の整合性など)のために、Glue Python ShellステップにGreat Expectationsを追加します。expectationをS3に保存し、パイプラインでチェックポイントを実行します。
- DataBrewのプロファイルジョブをスケジュールして、毎日のベースライン(カーディナリティ、null率、パーセンタイル)をキャプチャし、自動比較を使用してドリフトを検出します。
- ストリーミング注文イベントに対して、適切なRedrivePolicyを持つSQS DLQを設定し、DLQメッセージをべき等に(order_idを重複排除キーとして使用して)処理するためのリプレイジョブを作成します。
- ジョブのランタイムとエラーカウントに対してCloudWatchの異常検知器を実装します。異常ベースのアラームをSNSにアタッチして、オンコールエスカレーションを行います。
AWSのベストプラクティスの論理的根拠:迅速な統合のためのネイティブなGlueの品質管理、表現力のためのGreat Expectations、ベースライン統計のためのDataBrew、そして適応的なモニタリングのためのCloudWatch異常検知器を組み合わせます。DLQとべき等なシンクは、SLAを維持しながら安全なリトライと再処理のループを完成させます。
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →