このトピックでは、Data Quality の監視ルールを使用して、データ同期ノードが毎日スケジュールされるときに発生する例外を検出する方法について説明します。 このトピックでは、ユーザー情報テーブル ods_user_info_d_emr を使用し、ユーザー情報テーブルに同期される行数が 0 より大きいかどうかを監視する強いルールと、テーブル内のビジネス プライマリキーが一意であるかどうかを監視する弱いルールをテーブルに対して設定します。 テーブルを生成するデータ同期ノードが毎日スケジュールされると、ルールがトリガーされ、ノードのダウンストリームコンピューティングの信頼性を確保するために、欠落しているソースデータと重複するプライマリキーの例外がリアルタイムで検出されます。 Data Quality で監視ルールを設定してデータ品質を監視するには、以下のセクションを参照してください。
前提条件
データが同期および処理されています。
ApsaraDB RDS for MySQL テーブル ods_user_info_d の基本的なユーザー情報は、Data Integration を使用して E-MapReduce (EMR) Hive テーブル ods_user_info_d_emr に同期されます。
Object Storage Service (OSS) の user_log.txt 内のユーザーの Web サイトアクセスログは、Data Integration を使用して EMR Hive テーブル ods_raw_log_d_emr に同期されます。
収集されたデータは、Data Studio で基本的なユーザープロファイルデータに処理されます。
データ品質監視要件の分析
この例では、Data Quality を使用して、ユーザープロファイル分析ケースのソースデータの変更と、ソースデータに対して抽出、変換、書き出し (ETL) 操作が実行されたときに生成されるダーティデータを迅速に検出します。 次の表に、ユーザープロファイルの分析および処理手順の監視要件を示します。
テーブル名 | 詳細な要件 |
ods_raw_log_d_emr | 生ログデータテーブルに同期される行数が毎日 0 より大きいかどうかを監視する強いルールを設定します。 これにより、生ログデータを毎日確実に取得でき、データの欠落による後続のコンピューティングへの影響を防ぎます。 |
ods_user_info_d_emr | ユーザー情報テーブルに同期される行数が毎日 0 より大きいかどうかを監視する強いルールと、テーブル内のビジネス プライマリキーが一意であるかどうかを毎日監視する弱いルールを設定します。 これにより、ユーザー情報を毎日確実に取得でき、データの重複を防ぎ、後続のコンピューティングの精度を確保できます。 |
dwd_log_info_di_emr | 監視ルールを設定せずにノードを実行します。 |
dws_user_info_all_di_emr | 監視ルールを設定せずにノードを実行します。 |
ads_user_info_1d_emr | ユーザー情報テーブルの行数の変動を毎日監視するルールを設定します。 このルールは、毎日のユニークビジター (UV) の変動を観察するために使用され、アプリケーションの状態をできるだけ早く把握するのに役立ちます。 |
以下のセクションの手順を実行して、ods_user_info_d_emr テーブルの監視ルールを設定し、定期的なスケジューリングに基づいて生成されるテーブルデータの品質を監視できます。
ステップ 1: テーブル別設定ページに移動する
Data Quality ページに移動します。
DataWorks コンソール にログインします。 上部のナビゲーションバーで、目的のリージョンを選択します。 左側のナビゲーションウィンドウで、 を選択します。 表示されるページで、ドロップダウンリストから目的のワークスペースを選択し、[データ品質に移動] をクリックします。
テーブル別設定ページに移動します。
Data Quality ページの左側のナビゲーションウィンドウで、 を選択します。 テーブル別設定ページで、次のフィルター条件に基づいて目的のテーブルを検索します。
接続セクションで、E-MapReduce を選択します。
テーブル別設定ページの右側で、フィルター条件を指定して
ods_user_info_d_emrテーブルを見つけます。
検索結果で目的のテーブルを見つけ、アクション列の [ルール管理] をクリックします。 テーブルのテーブル品質詳細ページが表示されます。 以下のセクションでは、テーブルの設定について説明します。
ステップ 2: 監視ルールを設定する
このセクションでは、指定されたパーティションにデータが含まれているかどうかを監視するルールを ods_user_info_d_emr テーブルに設定します。 設定には、監視ルールの作成、ルールのトリガー方法の指定、ルールによって検出された例外の処理ポリシーの指定が含まれます。
監視範囲を選択します。
[監視] タブで、[監視の作成] をクリックします。
[データ範囲] パラメーターを
dt=$[yyyymmdd-1]に設定します。説明定期的なスケジューリングに基づいて生成されたテーブルデータを監視するには、データ範囲パラメーターの値が、当日テーブルに生成されたパーティションに対応していることを確認してください。
監視ルールを作成します。
このセクションでは、テーブルの行数が 0 より大きいかどうかを監視するルールを
ods_user_info_d_emrテーブルに設定します。 監視ルールを設定する方法の詳細については、「単一テーブルの監視ルールを設定する」をご参照ください。[監視の作成] ページで、[ルールの作成] をクリックします。 [ルールの作成] パネルが表示されます。
[ルールの作成] パネルの [システムテンプレート] タブで、[テーブルが空でない] ルールを見つけて [使用] をクリックします。 パネルの右側で、[重要度] パラメーターを [強いルール] に設定します。
説明この例では、ルールは 強い ルールとして定義されています。これは、
ods_user_info_d_emrテーブルの行数が 0 であることが検出された場合、アラートがトリガーされ、子孫ノードの実行がブロックされることを示します。[ルールの作成] パネルの [システムテンプレート] タブで、[一意の値。固定値] ルールを見つけて [使用] をクリックします。 パネルの右側で、[ルール範囲]、[監視しきい値]、[重要度] パラメーターを設定します。
[ルール範囲]:
uid(STRING)に設定します。[監視しきい値]:
標準しきい値パラメーターで、比較演算子を = に設定し、値を 0 に設定します。[重要度]:
弱いルールに設定します。
[決定] をクリックして、設定した監視ルールを保存します。
ルールのトリガー方法を指定します。
トリガー方法パラメーターを [本番環境でのノードスケジューリングによってトリガーされる] に設定し、データ同期の際に作成された
ods_user_info_d_emrノードを選択します。ルールによって検出された例外の処理ポリシーを指定します。
ビジネス要件に基づいて、処理ポリシーを [ノードの実行をブロックする] または [受信者にアラート通知を送信する] に設定します。
設定が完了したら、[保存] をクリックして、モニターの設定を保存します。
ステップ 3: モニターのテスト実行を実行する
設定が完了したら、テスト実行を実行して、モニターに関連付けられている監視ルールが期待どおりに機能するかどうかを確認できます。 ルールの設定が正しく、期待どおりであることを確認するには、ルールを作成してモニターに関連付けた後、モニターのテスト実行を実行して、モニターの監視効果を確認します。
[ルール管理] タブの [監視パースペクティブ] セクションで、作成したモニターを選択します。 次に、タブの右側にある [テスト実行] をクリックします。 [テスト実行] ダイアログボックスが表示されます。
[テスト実行] ダイアログボックスで、[スケジューリング時間] パラメーターを設定し、[テスト実行] をクリックします。
テスト実行が完了したら、[詳細の表示] をクリックして、データがテストに合格したかどうかを確認します。
ステップ 4: モニターをサブスクライブする
監視ルールを設定した後、次の操作を実行して、アラート通知方法とアラート通知の送信先受信者を設定できます。
[ルール管理] タブの [監視パースペクティブ] セクションで、作成したモニターを選択します。
タブの右側にある [アラートサブスクリプション] をクリックします。
アラートサブスクリプションダイアログボックスで、[通知方法] パラメーターと [受信者] パラメーターを設定し、[アクション] 列の [保存] をクリックします。
サブスクリプションの設定が完了したら、左側のナビゲーションウィンドウで を選択します。 次に、監視ページで [マイサブスクリプション] を選択して、サブスクライブ済みのモニターを表示および変更します。
次のステップ
データが処理された後、DataAnalysis を使用してデータを視覚化できます。 詳細については、「ダッシュボードでデータを視覚化する」をご参照ください。