データ品質の確保

データ品質とは、データが目的に合った状態であることです。必須の値が埋まっている (完全性)、同じデータが重複していない (一意性)、値が決まった範囲や形式にある (妥当性)、ほかのデータと矛盾しない (一貫性)、十分に新しい (鮮度) といった観点で測ります。品質の悪いデータが分析やに流れると、誤った判断につながります。

DEA では、データ処理の中で品質チェック (空のフィールドのチェックなど) を実行すること、品質ルールを定義すること、そしてやなどで検証とクリーニングを行うことが問われます。中心になる道具はです。

Point

DQDL = Data Quality Definition Language の略で、Glue Data Quality のルールを書くための言語です。
Completeness = 完全性、Uniqueness = 一意性、Validity = 妥当性、Consistency = 一貫性、Freshness = 鮮度 です。
Quarantine = 隔離 は、品質ルールに合わない行を別の場所へ分けることです。
和訳
- Quarantine: 隔離
- Weblio英和辞書「quarantine」

概要

品質チェックは、パイプラインの「入口」と「出口」に置くのが基本です。

品質の観点	何を確かめるか	のルールの例
完全性	必須の列が空でない	`IsComplete "order_id"`、`Completeness "email" > 0.95`
一意性	主キーが重複しない	`IsUnique "order_id"`、`IsPrimaryKey "order_id"`
妥当性	値が範囲・形式・選択肢に合う	`ColumnValues "age" between 0 and 120`、`ColumnValues "status" in ["NEW","SHIPPED"]`
一貫性	ほかのデータと矛盾しない	`ReferentialIntegrity "customer_id" "customers.id" = 1.0`
鮮度	データが新しい	`DataFreshness "updated_at" <= 24 hours`
量	件数が急減・急増していない	`RowCount > 1000`、`RowCount >= min(last(7))`
照合 (移行元との一致)	参照データと件数や合計が一致する	`RowCountMatch "src" = 1.0` (行数の比)、`AggregateMatch "sum(amount)" "sum(src.amount)" = 1.0` (合計の比)

主要技術

①AWS Glue Data Quality の2つの入口 ⚠️ 頻出

は、オープンソースの Deequ を基にしたの品質検査の機能です。使う場所が2つあります。

入口	対象	向く場面
Data Catalog のテーブル	カタログに登録済みのテーブル (、、などのテーブル、のビュー)	保存済みのデータの品質を定期的に評価する (保存されたデータの品質)。ルールの推奨機能で、データからルールを自動で提案させられます。
ジョブ	ETL の処理中のデータ	に書き込む前に不良なデータを見つけて止める (移動中のデータの品質)。不合格の行を特定して隔離できます。

ETL ジョブでは、Glue Studio のビジュアルエディタで「Evaluate Data Quality」の変換を追加するか、スクリプトで EvaluateDataQuality を呼びます。

⚠️ 頻出: 「データレイクに書き込む前に、不良なレコードを見つけて取り除きたい」は Glue ETL ジョブの中の Data Quality です。「カタログのテーブルの品質を定期的に評価したい、ルールを自動で提案してほしい」は Data Catalog 側の Data Quality です。

②DQDL によるルールの定義

ルールはで、Rules = [ ... ] の中に並べて書きます。

Rules = [
    IsComplete "order_id",
    IsUnique "order_id",
    ColumnValues "amount" > 0,
    ColumnValues "order_date" > (now() - 3 days),
    ColumnValues "country" in ["JP","US"],
    Completeness "email" > 0.95 where "channel = 'web'",
    RowCount >= min(last(7))
]

書き方	意味
ルールの種類	IsComplete、Completeness、IsUnique、Uniqueness、IsPrimaryKey、ColumnValues、ColumnLength、ColumnDataType、RowCount、DataFreshness、ReferentialIntegrity、DatasetMatch、CustomSql、DetectAnomalies など 25 を超える種類があります。
しきい値	`with threshold > 0.9` で「90% 以上の行が条件を満たせば合格」にできます。
複合ルール	`and` / `or` で組み合わせます。各ルールは括弧で囲みます。
where 句	条件に合う行だけを対象にします。
動的ルール	`last(k)` で過去の実行の値と比べます。`RowCount >= min(last(7))` (直近 7 回の最小値以上) のように、しきい値を固定せず過去の傾向から判定します ( ジョブで使えます)。
アナライザー	`Analyzers = [ ... ]` で、合否を判定せずに統計だけを集めます。の材料になります。
NULL / EMPTY / WHITESPACES_ONLY	空の値、空文字、空白だけの値を区別して検査します。

ルールの合格の割合が、データ品質スコアになります。

Point

空のフィールドのチェックは、IsComplete (1件でも空なら不合格) と Completeness (空でない割合をしきい値と比べる) を使い分けます。
Is で始まるルールは「すべての行で成り立つか」、そうでないルールは「割合や値をしきい値と比べる」と覚えます。

③ML による異常検知

の動的ルールやアナライザーで集めた統計をもとに、で異常 (例: いつもより件数が極端に少ない、ある列の値の分布が急に変わった) を検知できます。しきい値を決めにくい指標でも、過去の傾向から外れた変化を見つけられます。検知した内容は「観測 (observation)」として提示され、ルールに取り込めます。

検知には過去 3 回以上の実行の統計が必要で、平日と週末のような季節性も自動で学びます。異常の観測そのものは品質スコアに影響せず、Analyzers は合否を判定しないため、それだけではジョブを止められません。合否で止めたいときは、動的ルールや DetectAnomalies のルールにします。なお、動的ルールと Analyzers はジョブで使う機能で、Data Catalog 側の評価では使えません。

④違反したときの扱い ⚠️ 頻出

品質ルールに違反したとき、パイプラインをどう動かすかを決めます。

扱い	内容	向く場面
ジョブを失敗させる (停止)	ルールが不合格ならジョブを止め、データを書き込みません	不良なデータが下流に流れると影響が大きい (財務の集計など)
隔離する	不合格の行だけを別のの場所に書き、合格した行は書き込みます	一部の不良は許容し、処理は続けたい
結果を記録して続ける	結果をのと S3 に出し、処理は続けます	品質の傾向を監視したい
通知する	結果のイベントをで受け、で知らせます	担当者が確認して対応する

Studio の Evaluate Data Quality では、ルールセットが不合格のときの動作を「なし (続ける、既定)」「ターゲットに書き込んだ後でジョブを失敗させる」「ターゲットに書き込まずにジョブを失敗させる」から選びます。

通知には2つの経路があります。評価が終わると Data Quality Evaluation Results Available のイベントが EventBridge に送られ、state (FAILED など) や score (例: 0.7 以下) で絞り込んで SNS やに渡せます。また、不合格のルール数を表す glue.data.quality.rules.failed のメトリクスが CloudWatch に出るため、1 以上でにできます。どちらも、評価の設定で CloudWatch へのメトリクスの公開を有効にしておくことが前提です。Data Catalog 側の評価は、コンソールから週次などのスケジュールで定期実行できます (スケジュールは EventBridge に作られます)。

ジョブでは、行ごとの判定結果 (行レベルの結果) を出力できるため、DataQualityEvaluationResult の列で合格と不合格の行を分け、不合格の行を隔離用の場所へ書き出せます。

⑤Lambda と Athena による検証とクリーニング

以外にも、規模と場面に合わせて検証の道具を選びます。

道具	向く場面	例
	ファイルが届いた時点の軽い検証	に CSV が届いたら、ヘッダーの列名と行数を確かめ、不正なら隔離用のプレフィックスへ移して通知します。
	保存済みのデータの検証をで	`SELECT COUNT() FROM t WHERE order_id IS NULL` で空の件数を調べ、重複は `GROUP BY order_id HAVING COUNT() > 1` で探します。クリーニングした結果をで新しいテーブルにします。
	大量のデータのクリーニング	重複の除去 (`dropDuplicates`)、空の値の補完、型の変換を行います。
	コードを書かずにクリーニング	画面で変換を組み立てます (#56)。
、Jupyter Notebook、 Data Wrangler	目で見て異常を探す	分布やをグラフで確かめます (#55、#59)。

⑥処理中によくある品質チェック

チェック	理由
空のフィールド (必須の列)	結合キーや集計の対象が空だと、結果が欠けます。
重複	「少なくとも1回」の配信や再実行で、同じレコードが入ることがあります。
型と形式	日付の形式が混在すると、パーティションや比較が壊れます。
範囲と許容値	ありえない値 (未来の注文日、負の数量) を見つけます。
件数の比較	入力件数と出力件数を比べ、処理中の取りこぼしを見つけます。
参照の整合性	ファクトテーブルのキーがディメンションテーブルにあるかを確かめます。
スキーマ	想定外の列の追加や削除で、下流の処理が壊れないかを確かめます。

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの	理由
の処理中に空のフィールドや重複を検査	ETL ジョブの Data Quality (IsComplete、IsUnique)	書き込み前に不良を見つけます。
不合格の行だけを分けて、処理は続けたい	行レベルの結果で隔離用のに書き出す	合格した行は下流へ流せます。
不良なデータが1件でもあれば止めたい	ルール不合格でジョブを失敗させる	下流に流しません。
カタログのテーブルの品質を定期的に評価、ルールを自動で提案	Data Catalog 側の Data Quality とルールの推奨	保存済みのデータを評価します。
件数のしきい値を決めにくい、過去の傾向と比べたい	動的ルール (`last()`) /	過去の実行の値と比べます。
品質の結果で通知	+	結果のイベントを受けて知らせます。
ファイル到着時の軽い検証		イベントで即座に検査できます。
保存済みのデータをで検証・クリーニング	(検証の SQL と )	サーバー管理なしで実行できます。
コードを書かずに品質ルールを定義	のデータ品質ルール	画面で定義し、プロファイルジョブで検証します。

②よくある誤答

品質チェックを分析の段階 (ダッシュボード) でだけ行うこと。不良なデータは書き込み前に見つけるのが原則です。
不良が見つかったらデータをすべて捨てること。要件によっては不合格の行だけを隔離し、後で直して再処理します。
件数の急減を固定のしきい値だけで見ること。データ量が日々変わる場合は動的ルールやが向きます。