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.

このドメインは、AWS データプラットフォーム全体でデータの検出、クエリ、統制を可能にするメタデータレイヤーを対象としています。効果的なカタログ化とメタデータ管理は、分析における摩擦を減らし、下流のコンシューマーがスキーマ、パーティション、アクセスポリシー、リネージを見つけられるようにします。この分野の AWS サービス—Glue Data Catalog, Glue Schema Registry, Lake Formation, Athena との統合, DataBrew—は、検出、スキーマの進化、ガバナンス、プロファイリングのための補完的なツールを提供します。これらのサービスがどのように連携し、その設定詳細や典型的な障害モードを理解することは、運用の信頼性とセキュリティにとって不可欠です。

AWS Glue Data Catalog の構造とオペレーション

Glue Data Catalog は、データベース、テーブル、パーティション、接続、およびユーザー定義の分類子のための、リージョンごとにある一元化されたメタデータリポジトリです。中核となる要素は以下の通りです。

• Database: 論理的なコンテナです (aws cli を使用:

undefined

)。

• Table: データセット (serde, 入出力フォーマット, カラム, tableType EXTERNAL_TABLE) を記述します。コンソール、Glue API、または CloudFormation を介して作成/更新できます。例:

undefined

。

• Partition: パーティションキーの値と S3 プレフィックス間のマッピングです。パーティションは Glue クローラー (

undefined

) によって管理されるか、明示的に追加 (

undefined

) できます。

運用パターン:

• 検出のためのクローラー: 進化する S3 レイアウトに合わせてクローラーをスケジュールし、分類子の順序 (CSV/JSON/Parquet) を選択し、増分更新のためのクローラーポリシーを設定します。
• プログラムによる制御: イベント駆動で S3 にデータが到着する場合は、クローラーのみに依存するのではなく、Glue API や Lambda を使用してパーティションを追加することを推奨します。
• カタログのレプリケーション: Glue Data Catalog はリージョナルです。マルチリージョンでの読み取りには、各リージョンでクローラーを実行するか、メタデータを複製する自動化を構築するか、リソースリンクパターンを使用することを検討します。設計上の決定は、コスト、一貫性の要件、クロスリージョンクエリのパターンに依存します。

決定基準:

• スキーマ検出が必要で、データフォーマットが異種である場合はクローラーを使用します。厳密なスキーマや、大量で予測可能なデータセットには、明示的なテーブル作成を使用します。
• 高頻度で小規模なファイルが到着する場合は、クローラーの遅延を避け、Glue API のコストを削減するために、batch-create-partition または Lambda ベースのパーティション管理を使用します。

スキーマの検出と進化

Schema Registry と Glue のスキーマは、ストリーミングおよび長期的なプロデューサー/コンシューマー契約のために Avro, JSON, Protobuf をサポートします。主な機能は以下の通りです。

• コンソールまたは CLI を介してスキーマを登録します (

undefined

)。

• 互換性モード: BACKWARD (コンシューマーは新しいデータを読み取れる)、FORWARD (新しいコンシューマーは古いデータを読み取れる)、FULL (両方)。コンシューマーのデプロイパターンに基づいて選択します。
• スキーマの強制: ストリーミングの場合、レジストリを Kinesis Data Streams, MSK, または Kafka クライアントおよび AWS SDK と統合し、埋め込まれたスキーマバージョンと検証を用いてシリアライズ/デシリアライズします。

実用的な設定と進化のパターン:

• 多くのコンシューマーがいる Avro の場合、BACKWARD 互換性を使用して、デフォルト値を持つ新しいフィールドの追加を許可します。破壊的な削除は避けてください。
• チーム間で厳密な契約の進化が求められる場合、FULL 互換性を要求し、スキーマ検証を実行する CI ステップを通じてスキーマの変更をゲートします。
• フィールドがオプショナルでスキーマが流動的な JSON の場合、寛容なデフォルト値を持つスキーマ進化を使用しつつ、サイレントなコンシューマーの破損を防ぐためにカタログでメタデータをバージョニングします。

決定基準:

• ストリーミングイベントや、複数のコンシューマーが正規のスキーマを必要とする場合は Schema Registry を使用します。フォーマット (Parquet/ORC) が読み取り時スキーマを提供するバッチデータセットには、Glue のテーブルスキーマを使用します。
• すべてのコンシューマーを制御できるか (FORWARD を調整できるか)、または安全な追加的変更が必要か (BACKWARD を選択) を評価して、互換性モードを選択します。

Lake Formation によるデータリネージとガバナンス

Lake Formation は Glue Data Catalog 上に構築され、きめ細かなアクセス制御、監査、リネージ制御を提供します。主な機能は以下の通りです。

• LF-Tags: データベース、テーブル、カラムに適用されるタグベースのアクセス制御です。Lake Formation で LF-Tags を作成し、キー:値のペアを割り当て、リソースベースの許可ではなくタグベースの許可を通じて IAM プリンシパルに権限を付与します。
• 列レベルの制御: LF-Tags を使用して列をマスクまたは制限します。Lake Formation コンソールまたは

undefined

を使用して列レベルの権限を設定します。

• リネージと監査: CloudTrail と Glue ジョブのメトリクスを有効にして ETL ジョブのリネージをキャプチャします。Glue ジョブブックマークとカタログ内のジョブブックマークメタデータを使用して、処理済みのデータを追跡します。

設定パターン:

• 小さく一貫性のある LF-Tag キーのセット (例: sensitivity:public/private/PII) を定義し、テーブル作成時または Glue クローラーを介して、クローラー設定や後処理コードを使用してタグ付けを自動化します。
• Lake Formation の委任された管理者 (Delegated Admin) ロールを介して管理を委任し、IAM レベルの S3 アクセスを制限しながら、分析チームに Lake Formation の権限を付与します。

決定基準:

• 多くのコンシューマーにまたがる一元化された、列レベルの、タグベースの制御が必要な場合や、ガバナンス/監査性が必須である場合は Lake Formation を使用します。
• アクセス制御の要件がシンプル (バケットレベル) であれば、IAM+S3 ポリシーで十分な場合があります。きめ細かく、カタログと統合された制御には Lake Formation を使用します。

AthenaとGlueカタログの統合

AthenaはメタデータのためにGlueデータカタログに依存します。一般的な統合ポイントと運用上の調整項目は次のとおりです。

• パーティションの処理: AthenaはGlueカタログからパーティションを読み取ります。新しいS3パーティションが追加された場合、カタログを更新する必要があります。選択肢は以下の通りです。
  • AthenaからMSCK REPAIR TABLE db.table;を実行するか、そのSQLを指定してaws athena start-query-executionを使用し、テーブルのロケーション配下で発見されたパーティションを更新します。
  • S3のPUTイベントでaws glue batch-create-partitionを使用してプログラムでパーティションを追加します（イベント駆動フローに推奨）。
  • projection.enabled=true、projection.year.type=integer、projection.month.range=1、projection.year.range=2018,2026のようなテーブルプロパティを設定してパーティション射影を使用します。これにより、Glueのルックアップが完全に不要になり、非常に多くのパーティションがある場合に不可欠です。
• クエリパフォーマンスとコストのトレードオフ:
  • パーティション射影はGlue API呼び出しをなくし、多数の小さなパーティションに対するレイテンシーを大幅に削減しますが、決定論的なパーティション命名規則が必要です。
  • MSCK REPAIR TABLEは、時折発生するアドホックなデータ到着にはシンプルですが、大規模なデータセットでは遅くなる可能性があります。

Glue DataBrewによる補完:

• ノーコードでのプロファイリングと変換にはDataBrewを使用します。DataBrewをGlueカタログのテーブルまたはS3パスに向け、プロファイリングジョブを実行し、レシピを作成し、出力をS3に戻すか、新しいGlueテーブルとして公開します。
• 複雑なSparkロジックが必要な場合に、Glue ETLで後で本番化するための変換を生成したり、探索的な品質チェックにDataBrewを使用します。

決定基準:

• パーティションが多数あり、予測可能なスキーマ（日付ベース/数値ベース）に従う場合は、パーティション射影を使用します。
• イベント駆動型のニアリアルタイムな取り込みには、プログラムによるGlueパーティションの更新を使用します。
• MSCK REPAIR TABLEは、時折のバックフィルや自動化が利用できない場合にのみ実行します。

一般的な落とし穴と決定基準

• S3へのデータ到着後にGlueパーティションが更新されないためAthenaクエリが失敗する: クローラーのみに依存することを避けてください。時折の更新にはMSCK REPAIR TABLEを実行するか、S3イベントでaws glue batch-create-partitionを呼び出すか、大規模で予測可能なパーティションセットにはパーティション射影を実装します。
• 間違ったスキーマレジストリの互換性モードを選択するとコンシューマーが壊れる: 追加的な変更とコンシューマーの安定性のためにはBACKWARDを選択し、プロデューサーが古いコンシューマーとの互換性を維持する必要がある場合はFORWARDを、両方向で安全でなければならない場合はFULLを選択します。CIでコンシューマーのスキーマに対して変更を検証します。
• Glueデータカタログがグローバルであると仮定する: カタログはリージョナルです。クロスリージョンアクセスのためには、レプリケーションを設計するか、ターゲットリージョンでカタログを実行します。Glueのメタデータがリージョン間で自動的に利用可能であると仮定しないでください。
• IAMのS3アクセス権は付与するが、Lake Formationの権限は付与しない: AthenaとLake Formationはカタログレベルの権限を強制します。IAMポリシーに加えて、常にLake Formationの権限（およびLF-Tagsが使用されている場合はそれも）を付与してください。
• 過剰なパーティション粒度: 細かすぎるパーティションを多用すると、クエリ計画とメタデータのオーバーヘッドに悪影響を及ぼします。より粗い粒度のパーティション（分単位ではなく日単位など）を優先するか、パーティション射影を使用します。
• DataBrewのロール権限を軽視する: DataBrewジョブには、GlueとS3の権限を持つサービスロールが必要です。データセットが暗号化されている場合は、ロールにGlue:GetTable、S3の読み書き、およびkms:Decryptの権限があることを確認してください。

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

Acme Retail社は、日付/時間パーティションを持つ時間単位の売上ファイルをS3に受信し、アナリストはAthenaでデータをクエリします。ロード後、パーティションがGlueデータカタログに表示されないため、ユーザーはクエリの失敗や古い結果を目にします。

1. S3のPUTイベント通知を実装してLambda関数を呼び出し、その関数がaws glue batch-create-partitionをコールして新しいパーティションを即座に登録します。
2. 古いデータやバックフィルについては、MSCK REPAIR TABLE db.sales_hourly;を実行するAthenaクエリをスケジュールするか、既知の範囲に対してターゲットを絞ったaws glue batch-create-partitionを実行します。
3. パーティションが厳密な日付/時間の命名規則に従う場合は、Glueテーブルでパーティション射影を有効にし（projection.enabled=trueを設定し、年/月/日/時間のプロパティを定義）、カタログ更新コストを排除します。
4. テーブルに機密性を示すLF-Tagsを追加し、アナリストにLake Formationの権限を付与して、Athenaクエリが許可され、ガバナンスが効くようにします。
5. ステージング環境でGlue DataBrewを使用して新しい時間単位のファイルをプロファイリングし、スキーマのドリフトを検出します。スキーマの変更が見つかった場合は、Glue Schema Registryに新しいスキーマバージョンを登録し、本番環境への展開前に互換性を検証します。

論理的根拠: 自動的なパーティション登録または射影により、Athenaクエリを失敗させるメタデータの遅延が解消されます。これをLake Formationのガバナンスと組み合わせることで安全なアクセスが保証され、DataBrewによるプロファイリングがスキーマのドリフトを早期に検出し、Glue Schema Registryがストリーミングおよびバッチのコンシューマーを互換性のないスキーマ変更から保護します。

← データストレージとレイクアーキテクチャ · すべてのドメイン · データ変換と処理 →

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

Amazonを閲覧 →