このトピックでは、Data Quality を使用してテーブルデータのデータ品質を監視する方法について説明します。
前提条件
データが同期および処理されます。 詳細については、「データの同期」および「データの処理」をご参照ください。
ApsaraDB RDS for MySQL テーブル ods_user_info_d の基本的なユーザー情報は、Data Integration を使用して MaxCompute テーブル ods_user_info_d_odps に同期されます。
Object Storage Service (OSS) の user_log.txt にあるユーザーの Web サイトアクセスログは、Data Integration を使用して MaxCompute テーブル ods_raw_log_d_odps に同期されます。
収集されたデータは、DataStudio で基本的なユーザープロファイルデータに処理されます。
背景情報
Data Quality は、異種データソースのデータ品質のチェック、アラート通知の構成、データソースの管理を可能にするエンドツーエンドのプラットフォームです。 Data Quality は、データセット内のデータを監視します。 Data Quality を使用して、MaxCompute テーブルを監視できます。 オフラインの MaxCompute データが変更されると、Data Quality はデータをチェックし、そのデータを使用するノードをブロックします。 これにより、ダウンストリームデータがダーティデータの影響を受けるのを防ぎます。 さらに、Data Quality を使用すると、チェック結果の履歴を管理できます。 これにより、データ品質を分析および評価できます。
この例では、Data Quality を使用して、ユーザープロファイル分析ケースのソースデータの変更と、抽出、変換、書き出し (ETL) 操作がソースデータで実行されたときに生成されるダーティデータをできるだけ早く検出します。 次の表に、ユーザープロファイルデータの分析および処理手順の監視要件を示します。
テーブル名 | 詳細な要件 |
ods_raw_log_d_odps | 生ログデータテーブルに同期される行数が 0 であるかどうかを毎日監視するルールを構成します。 このルールは、無効なデータ処理を防ぐのに役立ちます。 |
ods_user_info_d_odps | ユーザー情報テーブルに同期される行数が 0 であるかどうかを毎日監視する強いルールと、テーブル内のビジネスプライマリキーが一意であるかどうかを毎日監視する弱いルールを構成します。 これらのルールは、無効なデータ処理を防ぐのに役立ちます。 |
dwd_log_info_di_odps | 個別のルールは必要ありません。 |
dws_user_info_all_di_odps | 個別のルールは必要ありません。 |
ads_user_info_1d_odps | ユーザー情報テーブルの行数の変動を毎日監視するルールを構成します。 このルールは、毎日のユニークビジター (UV) の変動を観察するために使用され、アプリケーションの状態をできるだけ早く把握するのに役立ちます。 |
テーブル別設定ページに移動する
Data Quality ページに移動します。
DataWorks コンソール にログオンします。 上部のナビゲーションバーで、目的のリージョンを選択します。 左側のナビゲーションウィンドウで、データ开発と操作とメンテナンス＞[データ品質] を選択します。 表示されるページで、ドロップダウンリストから目的のワークスペースを選択し、[データ品質に移動] をクリックします。
テーブル別設定ページに移動します。
Data Quality ページの左側のナビゲーションウィンドウで、 を選択します。 テーブル別設定ページで、次のフィルター条件に基づいて目的のテーブルを見つけます。
接続セクションで、MaxCompute を選択します。
MaxCompute カテゴリで、本番環境の現在のプロジェクトを選択します。 この例では、workshop2024_01 が使用されています。
テーブル別設定ページの右側で、フィルター条件を指定して、監視を構成する
ods_raw_log_d_odps、ods_user_info_d_odps、およびads_user_info_1d_odpsテーブルを見つけます。
検索結果で目的のテーブルを見つけ、アクション列の [モニターの作成] をクリックします。 テーブルのテーブル品質詳細ページが表示されます。 次のセクションでは、各テーブルの構成について説明します。
監視ルールの構成
ods_raw_log_d_odps テーブルの監視ルールの構成
ods_raw_log_d_odps テーブルは、OSS から同期されたユーザーの Web サイトアクセスログを格納するために使用されます。 テーブルのビジネスプロパティに基づいて、テーブルの行数が 0 であるかどうかを監視する監視ルールを構成できます。 次に、監視ルールをモニターに関連付けて、テーブルの品質チェックをトリガーできます。
1. モニターの構成
モニターを使用して、テーブルの指定された範囲 (パーティション) のデータの品質が期待どおりであるかどうかを確認できます。
この手順では、モニターの [データ範囲] パラメーターを dt=$[yyyymmdd-1] に設定する必要があります。 モニターが実行されると、モニターはパラメーター値に一致するデータパーティションを検索し、データの品質が期待どおりであるかどうかを確認します。
この場合、ods_raw_log_d_odps テーブルにデータを書き込むために使用されるスケジューリングノードが実行されるたびに、モニターがトリガーされ、モニターに関連付けられているルールを使用して、指定された範囲のデータの品質が期待どおりであるかどうかがチェックされます。
次の手順を実行する必要があります。
[モニター] タブで、[モニターの作成] をクリックします。
モニターのパラメーターを構成します。
次の表に、主要なパラメーターを示します。
パラメーター
説明
[データ範囲]
dt=$[yyyymmdd-1]
[トリガー方法]
トリガー方法。 このパラメーターを本番環境でのノードスケジューリングによってトリガーされるに設定し、データ同期中に作成された
ods_raw_log_d_odpsノードを選択します。[監視ルール]
このパラメーターを構成する必要はありません。 監視ルールは、「監視ルールの構成」セクションで構成されます。
説明モニターの構成方法の詳細については、「単一テーブルの監視ルールの構成」をご参照ください。
この例では、監視ルールは、スケジューリングノードによって毎日生成されるテーブルデータが期待どおりであるかどうかを監視するように構成されています。 テーブルは常に、データタイムスタンプが前日であるデータを生成します。 パーティションの追加ダイアログボックスで、スケジューリング時間パラメーターの値が現在の日で、結果パラメーターの値が前日である場合、テーブルデータは期待どおりです。
2. 監視ルールの構成
ods_raw_log_d_odps テーブルは、OSS から同期されたユーザーの Web サイトアクセスログを格納するために使用されます。 このテーブルは、ユーザープロファイル分析シナリオのソーステーブルとして使用されます。 無効なデータ処理とデータ品質の問題を防ぐために、テーブルの行数が 0 より大きいかどうかを監視する強いルールを作成して構成する必要があります。 このルールは、同期タスクがテーブルの関連パーティションにデータを書き込んだかどうかを判断するのに役立ちます。
ods_raw_log_d_odps テーブルの関連パーティションの行数が 0 の場合、アラートがトリガーされ、[ods_raw_log_d_odps] ノードは失敗して終了し、[ods_raw_log_d_odps] ノードの子孫ノードの実行がブロックされます。
次の手順を実行する必要があります。
[モニターパースペクティブ] セクションの [ルール管理] タブで、モニターを選択します。 この例では、
raw_log_number_of_table_rows_not_0モニターが選択されています。 次に、タブの右側にある [ルールの作成] をクリックします。 [ルールの作成] パネルが表示されます。ルールを作成する[ルールの作成] パネルの [システムテンプレート] タブで、[テーブルが空ではない] ルールを見つけて、[使用] をクリックします。 パネルの右側で、[重要度] パラメーターを [強いルール] に設定します。
説明この例では、ルールは強いルールとして定義されています。 これは、
ods_raw_log_d_odpsテーブルの行数が 0 であることが判明した場合、アラートがトリガーされ、子孫ノードの実行がブロックされることを示します。[決定] をクリックします。
説明監視ルールに構成されている他のパラメーターについては、「単一テーブルの監視ルールの構成」をご参照ください。
3. モニターのテスト実行を実行する
テスト実行を実行して、モニターに関連付けられている監視ルールの構成が期待どおりに機能するかどうかを確認できます。 ルールの構成が正しく、期待どおりであることを確認するには、モニターに関連付けられているルールを作成した後に、モニターのテスト実行を実行します。
[モニターパースペクティブ] セクションの [ルール管理] タブで、モニターを選択します。 この例では、
raw_log_number_of_table_rows_not_0モニターが選択されています。 次に、タブの右側にある [テスト実行] をクリックします。 [テスト実行] ダイアログボックスが表示されます。[テスト実行] ダイアログボックスで、[スケジューリング時間] パラメーターを構成し、[テスト実行] をクリックします。
テスト実行が完了したら、[詳細の表示] をクリックして、データがテストに合格したかどうかを確認します。
4. モニターをサブスクライブする
Data Quality は、監視およびアラート機能を提供します。 モニターをサブスクライブして、データ品質の問題に関するアラート通知を受信できます。 これにより、データ品質の問題をできるだけ早く解決し、データセキュリティ、データの安定性、データ生成の適時性を確保できます。
[モニターパースペクティブ] セクションの [ルール管理] タブで、モニターを選択します。 この例では、
raw_log_number_of_table_rows_not_0モニターが選択されています。 次に、タブの右側にある [アラートサブスクリプション] をクリックします。アラートサブスクリプションダイアログボックスで、[通知方法] および [受信者] パラメーターを構成し、[アクション] 列の [保存] をクリックします。
サブスクリプションの構成が完了したら、左側のナビゲーションウィンドウで を選択します。 次に、モニターページで [マイサブスクリプション] を選択して、サブスクライブ済みのモニターを表示および変更します。
ods_user_info_d_odps テーブルの監視ルールの構成
ods_user_info_d_odps テーブルは、ApsaraDB RDS for MySQL から同期された基本的なユーザー情報を格納するために使用されます。 テーブルのビジネスプロパティに基づいて、テーブルの行数が 0 であるかどうかを監視するルールと、プライマリキー値が一意であるかどうかを監視するルールを構成できます。 次に、ルールをモニターに関連付けて、テーブルの品質チェックをトリガーできます。
1. モニターの構成
モニターを使用して、テーブルの指定された範囲 (パーティション) のデータの品質が期待どおりであるかどうかを確認できます。
この手順では、モニターの [データ範囲] パラメーターを dt=$[yyyymmdd-1] に設定する必要があります。 モニターが実行されると、モニターはパラメーター値に一致するデータパーティションを検索し、データの品質が期待どおりであるかどうかを確認します。
この場合、ods_user_info_d_odps テーブルにデータを書き込むために使用されるスケジューリングノードが実行されるたびに、モニターがトリガーされ、モニターに関連付けられているルールを使用して、指定された範囲のデータの品質が期待どおりであるかどうかがチェックされます。
次の手順を実行する必要があります。
[モニター] タブで、[モニターの作成] をクリックします。
モニターのパラメーターを構成します。
次の表に、主要なパラメーターを示します。
パラメーター
説明
[データ範囲]
dt=$[yyyymmdd-1]
[トリガー方法]
トリガー方法。 このパラメーターを本番環境でのノードスケジューリングによってトリガーされるに設定し、データ同期中に作成された
ods_user_info_d_odpsノードを選択します。[監視ルール]
このパラメーターを構成する必要はありません。 監視ルールは、「監視ルールの構成」セクションで構成されます。
説明モニターの構成方法の詳細については、「単一テーブルの監視ルールの構成」をご参照ください。
2. 監視ルールの構成
ods_user_info_d_odps テーブルは、ApsaraDB RDS for MySQL から同期された基本的なユーザー情報を格納するために使用されます。 このテーブルは、ユーザープロファイル分析シナリオのソーステーブルとして使用されます。 無効なデータ処理とデータ品質の問題を防ぐために、テーブルの行数が 0 より大きいかどうかを監視する強いルールを作成して構成する必要があります。 このルールは、同期タスクがテーブルの関連パーティションにデータを書き込んだかどうかを判断するのに役立ちます。
監視ルールが有効になった後、ods_user_info_d_odps テーブルの関連パーティションの行数が 0 の場合、アラートがトリガーされ、[ods_user_info_d_odps] ノードは失敗して終了し、[ods_user_info_d_odps] ノードの子孫ノードの実行がブロックされます。
次の手順を実行する必要があります。
[モニターパースペクティブ] セクションの [ルール管理] タブで、モニターを選択します。 この例では、
user_info_quality_controlモニターが選択されています。 次に、タブの右側にある [ルールの作成] をクリックします。 [ルールの作成] パネルが表示されます。ルールを作成する[ルールの作成] パネルの [システムテンプレート] タブで、[テーブルが空ではない] ルールを見つけて、[使用] をクリックします。 パネルの右側で、[重要度] パラメーターを [強いルール] に設定します。
説明この例では、ルールは強いルールとして定義されています。 これは、
ods_user_info_d_odpsテーブルの行数が 0 であることが判明した場合、アラートがトリガーされ、子孫ノードの実行がブロックされることを示します。[ルールの作成] パネルの [システムテンプレート] タブで、[一意の値。固定値] ルールを見つけて、[使用] をクリックします。 パネルの右側で、次の図に示すように、[ルールスコープ]、[監視しきい値]、および [重要度] パラメーターを構成します。
[ルールスコープ]:
uid(STRING)に設定します。[監視しきい値]:
標準しきい値パラメーターの場合、比較演算子を = に設定し、値を 0 に設定します。[重要度]:
弱いルールに設定します。
[決定] をクリックします。
説明監視ルールに構成されている他のパラメーターについては、「単一テーブルの監視ルールの構成」をご参照ください。
3. その他の構成
モニターのテスト実行とモニターのサブスクライブを実行する操作は、「ods_raw_log_d_odps テーブルの監視ルールの構成」セクションで説明されている操作と同じです。
ads_user_info_1d_odps テーブルの監視ルールの構成
ads_user_info_1d_odps テーブルは最終結果テーブルです。 テーブルのビジネスプロパティに基づいて、テーブルの行数の変動を監視するルールと、プライマリキー値が一意であるかどうかを監視するルールを最終結果テーブルに構成できます。 これにより、毎日の UV の変動を観察し、オンライントラフィックの変動をできるだけ早く把握できます。 次に、ルールをモニターに関連付けて、テーブルの品質チェックをトリガーできます。
1. パーティションフィルター式の構成
モニターを使用して、テーブルの指定された範囲 (パーティション) のデータの品質が期待どおりであるかどうかを確認できます。
この手順では、モニターの [データ範囲] パラメーターを dt=$[yyyymmdd-1] に設定する必要があります。 モニターが実行されると、モニターはパラメーター値に一致するデータパーティションを検索し、データの品質が期待とおりであるかどうかを確認します。
この場合、ads_user_info_1d_odps テーブルにデータを書き込むために使用されるスケジューリングノードが実行されるたびに、モニターがトリガーされ、モニターに関連付けられているルールを使用して、指定された範囲のデータの品質が期待どおりであるかどうかがチェックされます。
次の手順を実行する必要があります。
[モニター] タブで、[モニターの作成] をクリックします。
モニターのパラメーターを構成します。
次の表に、主要なパラメーターを示します。
パラメーター
説明
[データ範囲]
dt=$[yyyymmdd-1]
[トリガー方法]
トリガー方法。 このパラメーターを本番環境でのノードスケジューリングによってトリガーされるに設定し、データ同期中に作成された
ads_user_info_1d_odpsノードを選択します。[監視ルール]
このパラメーターを構成する必要はありません。 監視ルールは、「監視ルールの構成」セクションで構成されます。
説明モニターの構成方法の詳細については、「単一テーブルの監視ルールの構成」をご参照ください。
2. 監視ルールの構成
ads_user_info_1d_odps テーブルは、ユーザープロファイル分析に使用されます。 毎日の UV の変動を検出するには、テーブルの集計データの行数の変動を監視するルールと、テーブルのプライマリキー値が一意であるかどうかを監視するルールを作成して構成する必要があります。 これにより、毎日の UV の変動を観察し、オンライントラフィックの変動をできるだけ早く把握できます。
監視ルールが有効になった後、ads_user_info_1d_odps テーブルに繰り返されるプライマリキーが存在する場合、アラートがトリガーされます。 7 日以内の ads_user_info_1d_odps テーブルの行数の変動率が 10% を超えて 50% 未満の場合、警告アラートがトリガーされます。 7 日以内の ads_user_info_1d_odps テーブルの行数の変動率が 50% 以上の場合、重大なアラートがトリガーされます。
[処理ポリシー] はモニターで構成されます。
ルールが強いルールとして定義され、重大なしきい値を超えた場合、処理ポリシーは [ブロック] です。 これは、テーブルでデータ品質の問題が検出された場合、テーブルにデータを書き込むために使用される本番環境のスケジューリングノードが識別され、システムがノードの実行状態を失敗に設定することを示します。 この場合、ノードの子孫ノードを実行できなくなり、本番リンクがブロックされ、ダーティデータの拡散が防止されます。他の例外が検出された場合、処理ポリシーは [アラート] です。 これは、テーブルでデータ品質の問題が検出された場合、システムがモニターで構成された通知方法を使用してアラート受信者にアラート通知を送信することを示します。
監視ルールを構成する際には、次の点に注意してください。
ルールが強いルールとして定義され、重大なしきい値を超えた場合、重大なアラートが報告され、子孫ノードがブロックされます。 他の例外が発生した場合、アラートは報告されますが、子孫ノードはブロックされません。
ルールが弱いルールとして定義され、重大なしきい値を超えた場合、重大なアラートが報告されますが、子孫ノードはブロックされません。 他の例外が発生した場合、アラートは報告されますが、子孫ノードはブロックされません。
次の手順を実行する必要があります。
[モニターパースペクティブ] セクションの [ルール管理] タブで、モニターを選択します。 この例では、
ads_user_info_quality_controlモニターが選択されています。 次に、タブの右側にある [ルールの作成] をクリックします。 [ルールの作成] パネルが表示されます。ルールを作成する[ルールの作成] パネルの [システムテンプレート] タブで、[行数。7 日間のボラティリティ] ルールを見つけて、[使用] をクリックします。 パネルの右側で、次の図に示すように、[監視しきい値] および [重要度] パラメーターを構成します。
[監視しきい値]:
赤のしきい値パラメーターの場合、比較演算子を > に設定し、値を 50% に設定します。オレンジのしきい値パラメーターの場合、比較演算子を > に設定し、値を 10% に設定します。標準しきい値パラメーターの場合、比較演算子を <= に設定し、値を 10% に設定します。
[重要度]:
弱いルールに設定します。
[システムテンプレート] タブで、[テーブルが空ではない]ルールを見つけて、[使用]をクリックします。 パネルの右側で、[重要度]パラメーターを[強いルール]に設定します。
[決定] をクリックします。
説明監視ルールに構成されている他のパラメーターについては、「単一テーブルの監視ルールの構成」をご参照ください。
3. その他の構成
モニターのテスト実行とモニターのサブスクライブを実行する操作は、「ods_raw_log_d_odps テーブルの監視ルールの構成」セクションで説明されている操作と同じです。
次のステップ
データが処理された後、DataAnalysis を使用してデータを視覚化できます。 詳細については、「ダッシュボードでデータを視覚化する」をご参照ください。