このトピックでは、Data Quality を使用してテーブルデータの品質をモニタリングする方法について説明します。
本チュートリアルでは、ETL パイプライン内のダーティデータを Data Quality で検出し、不良データが拡散する前にダウンストリームタスクをブロックする方法を紹介します。Data Quality はデータセット内のデータをモニタリングし、現在は MaxCompute テーブルをサポートしています。
前提条件
開始する前に、以下の作業を完了していることを確認してください。
基本概念
データ品質のチェックには、以下の 2 つのオブジェクトが連携して機能します。
| 概念 | 説明 |
|---|---|
| 品質モニター | 「どのデータをチェックするか」を定義します — 評価対象のデータ範囲（パーティション）と、チェックをトリガーするスケジューリングノード |
| 品質ルール | 「何を検証するか」を定義します — 検証対象の具体的な条件（行数、一意性、変動率）および、条件違反時の処理内容 |
各品質モニターは、1 つ以上の品質ルールに関連付けられます。スケジューリングタスクが完了すると、関連付けられた品質モニターが起動し、指定されたパーティションに対してすべての関連ルールが実行されます。
ルールの種類と影響
ルールの構成を開始する前に、各ルールタイプがトリガーされた際の動作を理解してください。
| ルールタイプ | アラートタイプ | 影響 |
|---|---|---|
| 強制ルール | 赤色アラート | 対象テーブルへ書き込むスケジューリングノードのステータスが 失敗 に設定されます。すべてのダウンストリームノードがブロックされ、実行できなくなります。 |
| ソフトルール | 警告またはエラー アラート | 登録済みのすべての通知チャネルにアラートが送信されます。ダウンストリームノードは引き続き実行されます。 |
データ損失が許容できない場合にパイプラインの実行をブロックするには、強制ルールを使用します。たとえば、ソーステーブルが空の場合、同期タスクが失敗したことを意味します。一方、パイプラインを停止せずに調査が必要な異常を検出する場合は、ソフトルールを使用します。
モニタリング対象テーブル
本チュートリアルでは、ユーザーペルソナ分析パイプライン内の以下の 3 つのテーブルをモニタリングします。
| テーブル | ルール | ルールタイプ | 目的 |
|---|---|---|---|
ods_raw_log_d | テーブル行数 > 0 | 強力 | OSS 同期でレコードが書き込まれていない場合、処理を停止する |
ods_user_info_d | テーブル行数 > 0 | 強 | RDS 同期でレコードが書き込まれていない場合、処理を停止する |
ods_user_info_d | ビジネスプライマリキーの一意性 | ソフト | パイプラインをブロックせずに uid の重複値を検出する |
ads_user_info_1d | テーブル行数 > 0 | 強 | 最終出力テーブルが空でないことを保証する |
ads_user_info_1d | 行数の 7 日間変動率 | ソフト | 異常な UV 変動を検出する |
dwd_log_info_di および dws_user_info_all_di の中間テーブルは、個別にモニタリングしません。
ルール構成ページへの移動
DataWorks コンソール にログインします。上部ナビゲーションバーでご利用のリージョンを選択します。左側ナビゲーションウィンドウで、データガバナンス > Data Quality を選択します。ドロップダウンリストからご利用のワークスペースを選択し、Data Quality へ移動 をクリックします。
左側ナビゲーションウィンドウで、ルールの構成 > テーブル別に構成 をクリックします。データソース を
MaxComputeに、データベース を本番用プロジェクト（例：workshop2024_01）に設定します。対象テーブルを検索し、操作 列の ルール管理 をクリックします。
ods_raw_log_d の品質モニタリングルールの構成
このテーブルは OSS からウェブサイトのアクセスログを受信します。テーブルが空の場合、同期タスクが失敗したことを意味し、その後の変換処理は実行できません。そのため、行数が 0 の場合に即座にノードを失敗状態にし、すべてのダウンストリームタスクをブロックするために、強制ルールを使用します。
ステップ 1：品質モニターの作成
品質モニタリング タブで、品質モニターの作成 をクリックします。
以下のパラメーターを構成します。
dt=$[yyyymmdd-1]式は、前日のパーティションを対象としています。スケジューリングタスクは当日実行されますが、前日のデータを処理するため、この式により、モニターが正しいパーティションをチェックすることを保証します。品質モニターのパラメーターの完全な一覧については、「単一テーブルのルール構成」をご参照ください。
パラメーター 値 データ範囲 dt=$[yyyymmdd-1]トリガー方法 本番スケジューリングによってトリガーされます。データの同期 で作成した ods_raw_log_d品質ルールの選択 空白のままにしてください。次のステップで構成します。
ステップ 2：品質ルールの作成
ルール管理 タブをクリックします。品質モニタリングの視点 で、先ほど作成した品質モニター（例：
raw_log_number_of_table_rows_not_0）を選択し、ルールの作成 をクリックします。システムテンプレート で テーブル行数が 0 より大きい を見つけ、使用 をクリックし、重要度 を 強制ルール に設定します。
OK をクリックします。
ods_raw_log_dのパーティションの行数が 0 の場合、モニターが赤色アラートを発行し、ods_raw_log_dノードのステータスが「失敗」に設定され、すべてのダウンストリームノードがブロックされます。パラメーターの詳細については、「単一テーブルのルール構成」をご参照ください。
ステップ 3：品質モニターのテスト実行
本番環境での運用に依存する前に、ルールが正しく構成されていることをテストで確認します。
ルール管理 タブで、品質モニタリングの視点 から品質モニターを選択し、
テスト実行 をクリックします。ダイアログボックスで スケジュール時刻 を選択し、テスト実行 をクリックします。
テストが完了したら、詳細の表示 をクリックして、テストが正常に完了したことを確認します。
ステップ 4：アラートのサブスクライブ
ルール違反が発生した際に通知を受け取れるよう、モニターをサブスクライブします。
ルール管理 タブで、品質モニタリングの視点 から品質モニターを選択し、
アラートのサブスクライブ をクリックします。サブスクライブ方法 および 受信者 を追加し、操作 列の 保存 をクリックします。
左側ナビゲーションウィンドウで、O&M > モニタリング をクリックし、マイサブスクリプション を選択して、サブスクリプションの確認または変更を行います。
ods_user_info_d の品質モニタリングルールの構成
このテーブルは ApsaraDB RDS for MySQL から基本的なユーザー情報を受信し、ユーザーペルソナ分析のソーステーブルとして機能します。2 つのルールを構成します。1 つはテーブルが空の場合の失敗を検出する強制ルール、もう 1 つはパイプラインをブロックせずに重複するユーザー ID を検出するソフトルールです。
ステップ 1：品質モニターの作成
品質モニタリング タブで、品質モニターの作成 をクリックします。
以下のパラメーターを構成します。
品質モニターのパラメーターの完全な一覧については、「単一テーブルのルール構成」をご参照ください。
パラメーター 値 データ範囲 dt=$[yyyymmdd-1]トリガー方法 本番スケジューリングによってトリガーされます。データの同期 で作成した ods_user_info_d品質ルールの選択 空白のままにしてください。次のステップで構成します。
ステップ 2：品質ルールの作成
ルール管理 タブをクリックします。品質モニタリングの視点 で、先ほど作成した品質モニター（例：
user_info_quality_control）を選択し、ルールの作成 をクリックします。システムテンプレート で テーブル行数が 0 より大きい を見つけ、使用 をクリックし、重要度 を 強制ルール に設定します。行数が 0 の場合、
ods_user_info_dノードが失敗状態になり、すべてのダウンストリームノードがブロックされます。システムテンプレート で 一意値カウント（固定値） を見つけ、使用 をクリックし、以下のように構成します。このルールは、
uidの値が一意でないパーティションを検出し、パイプラインの実行をブロックしません。パラメーター 値 ルール範囲 uid(STRING)モニタリングしきい値 通常しきい値 = 0 重要度 ソフトルール OK をクリックします。
パラメーターの詳細については、「単一テーブルのルール構成」をご参照ください。
ステップ 3 および 4：テスト実行とサブスクライブ
ods_raw_log_d の品質モニタリングルールの構成 で説明した手順に従ってください。
ads_user_info_1d の品質モニタリングルールの構成
このテーブルはユーザーペルソナ分析の最終結果テーブルです。トラフィックの異常を示す可能性のある異常な日次ユニーク訪問者（UV）の変動を検出するソフトルールと、テーブルが空でないことを保証する強制ルールの 2 つを構成します。
ステップ 1：品質モニターの作成
品質モニタリング タブで、品質モニターの作成 をクリックします。
以下のパラメーターを構成します。
品質モニターのパラメーターの完全な一覧については、「単一テーブルのルール構成」をご参照ください。
パラメーター 値 データ範囲 dt=$[yyyymmdd-1]トリガー方法 本番スケジューリングによってトリガーされます。 で作成した ads_user_info_1dデータの変換 ノードを選択します。品質ルールの選択 空白のままにしてください。次のステップで構成します。
ステップ 2：品質ルールの作成
ルール管理 タブをクリックします。品質モニタリングの視点 で、先ほど作成した品質モニター（例：
ads_user_info_quality_control）を選択し、ルールの作成 をクリックします。システムテンプレート で 行数、7 日間変動率 を見つけ、+使用 をクリックし、以下のように構成します。このルールは、日次行数が過去 7 日間の平均から大きく逸脱した場合を検出します。変動率が 50% を超えるとエラー アラートが発行され、10% ～ 50% の間では警告アラートが発行されます。
パラメーター 値 モニタリングしきい値 — エラー > 50% モニタリングしきい値 — 警告 > 10% モニタリングしきい値 — 通常 ≤ 10% 重要度 ソフトルール システムテンプレート で テーブル行数が 0 より大きい を見つけ、使用 をクリックし、重要度 を 強制ルール に設定します。
OK をクリックします。
パラメーターの詳細については、「単一テーブルのルール構成」をご参照ください。
ステップ 3 および 4：テスト実行とサブスクライブ
ods_raw_log_d の品質モニタリングルールの構成 で説明した手順に従ってください。
次のステップ
データ品質モニタリングを導入することで、不良データがダウンストリームのコンシューマーに到達する前に自動的にブロックされるようになります。ユーザーペルソナデータの可視化については、「データの可視化」をご参照ください。