DEA / ドメイン2 データストア管理

重要な内容

AWS Glue Data Catalog とクローラー

に置いたファイルは、そのままでは「どの列が、どの型で、どこにあるか」が分かりません。 Data Catalog は、そのテーブル定義 (メタデータ) を一元的に持つ技術データカタログです。・・・Glue ジョブは、同じカタログを見て同じデータを読みます。DEA-C01 では、カタログを使ったデータの利用、との関係、によるスキーマの検出、パーティションの同期、新しい接続の作成 (タスク 2.2 のスキル 2.2.1〜2.2.5) が問われます。

Point
  • メタデータ (metadata): データについてのデータです。テーブル名、列名と型、S3 の場所、ファイル形式、パーティションなどです。
  • Hive メタストア: Apache Hive のテーブル定義を保管する仕組みです。Spark や Presto も使う、Hadoop の世界の標準のカタログです。
  • クローラー (crawler): データを読みに行き、スキーマを推測してカタログに書き込むプログラムです。
  • 和訳

概要

概要の図 Glue 接続 表・列・行の権限 S3 のデータ Glue クローラー分類子でスキーマを推測 RDS などの DB Glue Data Catalogデータベース・テーブル・パーティション Athena Redshift Spectrum EMR の Spark / Hive Glue ジョブ Lake Formation
単位内容
カタログアカウントとごとに1つ (他のカタログをでつなげられる)
データベーステーブルをまとめる入れ物
テーブル列と型、データの場所 ( のパス)、形式 (SerDe)、
パーティションパーティションキーの値と、その値のデータの場所
接続 などのデータストアへ届くための情報 (URL、、認証情報)

カタログはメタデータだけを持ち、データ本体は S3 などに置いたままです。カタログに登録されていても、権限がなければ読めません。権限の管理は が担います (「AWS Lake Formation」の章)。

主要技術

①技術データカタログと Hive メタストア ⚠️ 頻出

Data Catalog は と互換です。そのため、AWS のサービスだけでなく、 上の ・Hive・ なども共通のカタログとして使えます。

選択肢内容向くケース
Glue Data Catalogでマネージド。・・Glue・EMR・ が共有するAWS のサービスで共通のカタログを持つ (推奨)
EMR クラスター内の Hive メタストアクラスターのローカルに置くクラスターを止めるとメタデータも消える。一時的な検証のみ
外部の Hive メタストア ( / の MySQL)自分で運用する既存の Hive メタストアの資産と運用を続ける

EMR を Glue Data Catalog につなぐと、クラスターを作り直してもテーブル定義が残り、Athena から同じテーブルを読めます。Athena も、外部の Hive メタストアに のコネクタでつなげます。

カタログに登録したテーブルは、名前で読むだけでよくなります。

利用するサービスカタログの使い方
AthenaSELECT * FROM sales_db.orders のように、データベースとテーブルの名前で問い合わせる
Redshift SpectrumCREATE EXTERNAL SCHEMA ... FROM DATA CATALOG で外部スキーマとして参照する
Glue ジョブcreate_dynamic_frame.from_catalog(database=..., table_name=...) でテーブルを読み、書き込み時にカタログを更新する
EMRSpark や Hive からテーブル名で読む

別のアカウントのカタログも、定義を複製せずに使えます。Athena では、持ち主のアカウントが Glue Data Catalog のリソースポリシー (カタログの設定の「アクセス許可」) で利用側のロールに読み取りを許可し、利用側が持ち主のアカウント ID をカタログ ID として Athena のデータソースに登録すると、カタログ名.データベース.テーブル で問い合わせられます。データ本体の のポリシーでも利用側のロールを許可します。Lake Formation で権限を管理している場合は、Lake Formation の共有を使います (「AWS Lake Formation」の章)。

②クローラーによるスキーマの検出 ⚠️ 頻出

は、データストアを読み、 (classifier) で形式とスキーマを推測し、カタログにテーブルとパーティションを作成・更新します。

設定内容
データソース、 ( など)、、 / MongoDB、・・ のテーブル
分類子組み込みの分類子 (CSV、、、、 など) で足りなければ、カスタム分類子 (Grok、XML、JSON、CSV) を作る
接続JDBC のデータベース、DocumentDB / MongoDB をクロールするときは の接続が必須 (S3 はネットワーク型の接続を任意で付ける)
サンプリングDynamoDB や DocumentDB / MongoDB では、データの一部だけを読んでスキーマを推測し、クロールの時間とソースへの負荷を減らせる
ロールデータを読む権限とカタログに書く権限を持つロール
スケジュール、または cron 形式のスケジュール。Glue ワークフローのトリガーからも起動できる
出力書き込むデータベース、テーブル名の接頭辞
再クロールの方針内容向くケース
すべてのフォルダをクロール毎回全体を読み直す既存のファイルのスキーマも変わり得る
新しいフォルダのみクロール (増分)前回以降に増えたフォルダだけを読む日付のパーティションが毎日増えるだけ
イベントに基づいてクロールS3 のイベント通知 ( 経由) で変更のあったフォルダだけを読む大量のファイルがあり、全体の一覧取得が遅い
構成の工夫内容
各 S3 パスに単一のスキーマを作成互換性のあるスキーマのファイルを1つのテーブルにまとめ、細かいテーブルが大量にできるのを防ぐ
テーブルの場所の階層を指定どのフォルダの階層をテーブルにし、どこからをパーティションにするかを決める
テーブル数のしきい値想定外に大量のテーブルができたらクローラーを止める

「新しいフォルダのみ」の増分クロールは、既存のフォルダの変更や削除を検出しません。この設定にするとスキーマ変更ポリシーは「ログのみ」に固定されるため、大きなスキーマ変更があったときは一時的に全体のクロールへ戻します。

クローラーが対応するのは S3、JDBC、DynamoDB などの保管されたデータで、 や のようなデータストリームはクロールできません。ストリーミングの ジョブのソースは、カタログにテーブルを手で作ります (Kafka なら Kafka 型の Glue 接続を参照させます)。

クローラーは、同じプレフィックスの下にスキーマの違うファイルが混在すると、テーブルを分けたり、パーティションごとに別のテーブルを作ったりします。データの置き方をそろえることが、クローラーを正しく動かす前提です。

③スキーマ変更ポリシー

スキーマが変わったデータを見つけたとき、がカタログをどう変えるかを決めます。

対象選択肢
変更されたスキーマData Catalog のテーブル定義を更新する / 新しい列だけを追加する / 変更を無視して更新しない (ログにだけ残す)
削除されたオブジェクトカタログからテーブルとパーティションを削除する / 無視する / テーブルを非推奨としてマークする

本番のテーブル定義を、上流の想定外の変更で勝手に書き換えられたくない場合は、「更新しない (ログのみ)」や「新しい列だけを追加」を選びます。手で調整したテーブル定義を守りたいときも同じです。パーティションのスキーマをテーブルから継承する設定にすると、パーティションごとの型のずれを防げます。スキーマの変化への対処全般は「スキーマの進化とデータ特性の変化」の章で扱います。

④パーティションとカタログの同期 ⚠️ 頻出

に新しい日付のフォルダが増えても、カタログにそのパーティションが登録されていなければ、 や の結果に出てきません。同期の方法は複数あります。

方法内容向くケース
(増分・イベント)新しいフォルダを見つけてパーティションを追加するスキーマの検出も一緒に任せたい
MSCK REPAIR TABLE (Athena)Hive 形式 (key=value) のフォルダを走査して足りないパーティションを追加するたまに一括で直す。パーティションが多いと遅い。Hive 形式でないパスには使えない
ALTER TABLE ADD PARTITION指定したパーティションを登録する取り込みジョブが、書いたパーティションを自分で登録する
ジョブのカタログ更新 の書き込み時に enableUpdateCatalog と partitionKeys を指定し、新しいパーティションを登録するGlue の で書いたデータ
Glue (BatchCreatePartition) などからパーティションを登録するで即座に登録したい
(Athena)値の範囲や形式をテーブルのプロパティに書き、Athena が計算で求める。カタログにパーティションを登録しない日付などの規則的なパーティションが大量にあり、登録が追いつかない

パーティション射影は Athena だけが使います。Redshift Spectrum や は、カタログに登録されたパーティションを読むため、射影だけでは見えません。また、射影を有効にすると、Athena はカタログに登録されたパーティションを無視します。

パーティションが非常に多いテーブルでは、パーティションインデックスを作ると、条件に合うパーティションの取得が速くなります (クローラーは S3 のテーブルに既定で作成します)。1つのテーブルに3つまで作れます。Redshift Spectrum、EMR、Glue の Spark DataFrame はインデックスが有効になれば使い、Athena はテーブルのプロパティ partition_filtering.enabled を true にすると使います。射影と違い、カタログに登録したパーティションをどのエンジンからも使い続けられます。

MSCK REPAIR TABLE はパーティションを追加するだけで、削除はしません。S3 から消したパーティションがカタログに残ったときは ALTER TABLE DROP PARTITION で消します。パーティションが多いと時間切れで途中までしか追加されないこともあるため、日々の追加には ALTER TABLE ADD PARTITION などを使います。

⑤カタログ用の接続の作成

のデータベースや 内のデータストアをクロールしたり、 ジョブで読み書きしたりするには、Glue 接続を作ります。

接続の種類用途
JDBC、、、の DB
/ MongoDBドキュメントデータベース
や自前の Kafka をストリーミングジョブのソースにする
ネットワークVPC 内の 以外のデータストアへ届く経路だけを定義する
などのコネクタSalesforce などのアプリケーションへの接続
設定の要点内容
VPC・・Glue はそのサブネットに を作って接続する。セキュリティグループには、同じグループからのすべての を許可する自己参照のルールが必要
S3 への経路VPC 内で動く Glue が S3 を読むため、S3 の VPC (ゲートウェイ型) か ゲートウェイが必要
認証情報ユーザー名とパスワードを直接書かず、 のシークレットを参照する
接続のテストコンソールの「接続のテスト」で、経路と認証を確かめる

接続の経路 (NAT の を許可リストに入れる、オンプレミスへの到達など) は「データソースへの接続 (JDBC/ODBC と許可リスト)」の章で扱います。

試験対策

①判断マトリクス

問題文のキーワード選ぶもの
・・ で同じテーブル定義を共有 Data Catalog
EMR を作り直してもテーブル定義を残したいEMR のメタストアに Glue Data Catalog を使う
のデータのスキーマを自動で検出して登録
独自形式のログのスキーマを推測させたい (Grok など)
毎日増える日付のフォルダだけを登録クローラーの「新しいフォルダのみ」
大量のファイルがありクロールが遅いS3 イベントに基づくクロール
上流の変更で本番のテーブル定義を書き換えさせないスキーマ変更ポリシーで「更新しない (ログのみ)」
新しいパーティションが Athena の結果に出ないMSCK REPAIR TABLE、ALTER TABLE ADD PARTITION、クローラー
パーティションが大量で登録が追いつかない (Athena)
Glue ジョブで書いたパーティションを自動で登録enableUpdateCatalog と partitionKeys
内の を Glue で読む 接続 + 自己参照の + S3 の VPC
接続のパスワードを安全に管理

②よくある誤答

  • を設定すれば からも新しいパーティションが見えると考えること。射影は だけの機能です。
  • Hive 形式でないパス (/2026/10/17/) に MSCK REPAIR TABLE を使うこと。認識されないため、ALTER TABLE ADD PARTITION か射影を使います。
  • を毎回全件で動かし続けること。増分やイベントに基づくクロールで時間と費用を減らします。
  • Data Catalog に登録すればアクセス制御も終わると考えること。権限は と で管理します。
  • のローカルの に本番のテーブル定義を置くこと。クラスターの停止で消えます。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください