AWS Glue（Data Catalog / Data Quality）｜AIP-C01

ひとことで言うと

Glue Data Catalogは70以上のデータソースを横断する中央メタデータ目録、Glue Data Qualityはその上でデータの健全性をルールで検査する仕組みです。

要するに、図書館の目録係と検品係です。Data Catalogが「どの棚に何があるか」を記録し、Data Qualityが「その本のページが欠けていないか」を確認します。RAGコーパスに欠陥のある文書が混じるのを防ぐのは検品係の仕事です。

自前でやると出てくる作業	Glue側の受け皿
S3上の生データのスキーマを毎回手で確認する	クローラがスキーマを自動推論しCatalogへ記録
どのデータセットが信頼できるか目視で判断する	Data Quality Definition Language（DQDL）でルール化しスコア化
品質が落ちたデータを後から探す	失敗レコードを特定・隔離（ETLジョブ側で対応）

用途	使い方	関連ドメイン
RAG取り込み前の文書品質検査	Glue ETLジョブでDQDLルールを評価し、悪いデータを事前に除外	D1.3
構造化データストアのメタデータ整備	クローラでスキーマ推論しData Catalogへ登録	D1.3, D1.4
ガバナンス・監査	Data Catalogのメタデータタグ＋CloudTrailで系譜を追跡	D3.3
機密データの検知	Glueのセンシティブデータ検出機能で個人情報を特定・是正	D3.2

問われ方	正解に寄る条件	引っかけ
「RAGに読ませる前にデータの欠損・重複を検査したい」	Glue Data Quality（DQDLルール、データ品質スコア）	Glue Data Wrangler（ML特徴量向けの対話的整形であり、ルールベース検査ではない）
「複数チームが同じS3データをスキーマ知らずに使っている」	Glue crawler → Data Catalog で中央目録を作る	各チームに個別のスキーマ定義を書かせる
「誰がどのテーブルにアクセスできるかを制御したい」	Data Catalogは目録にすぎず、権限はLake Formationが担当	Glue単体で列レベル権限まで制御できると誤答する

Glue Data Qualityのルールセットは1つにつき最大2,000ルール・65KBが上限です。超える場合は分割が必要。また入れ子（nested）やリスト型のデータは直接評価できず、事前にフラット化しないとルールが機能しません。

実務上のポイント	内容
Data Catalog向け評価	ルール推奨機能が使え非エンジニアでも設定しやすいが、失敗レコードの特定はETLジョブ側の機能で対応していない
ルールセットの紐付け	必ずData Catalog上のテーブルに紐づけて作成する。テーブルの無いS3プレフィックスには直接適用できない
メタデータ層の共有	Data CatalogはLake Formation・Athena・Redshift Spectrum・EMRと共有。1回整備すれば全体に効く

迷う相手	切り分けの一言
AWS Lake Formation	Data Catalog＝「何がどこにあるか」の目録。Lake Formation＝「誰が読めるか」の許可層。両者はセットで動く別サービス
SageMaker Data Wrangler	Data QualityはDQDLによるルール検査。Data Wranglerは対話的な特徴量エンジニアリング。目的が違う
Amazon Athena	Data Catalogはメタデータの置き場。Athenaはそのメタデータを使ってS3データをSQLで検索する側

Q1. RAGコーパスに欠損値だらけの文書が混ざらないようにするには？

Glue Data QualityでDQDLルール（NULL率・重複チェックなど）を定義し、評価してデータ品質スコアで判定します。Data Wranglerは対話的な特徴量整形が主目的で、ルールベースの品質ゲートではありません。

Q2. Glue Data Catalogだけで「特定チームには特定列を見せない」制御はできる？

できません。 Data Catalogはメタデータの目録にすぎず、列・行レベルの細かいアクセス制御はAWS Lake Formationが担当します。