日次スケジュールで実行されるデータパイプラインは、ソースデータが到着しなかったり、抽出・変換・書き出し (ETL) 操作によって重複したプライマリキーが生成されたりして、サイレントに失敗することがあります。データ品質モニタリングルールを設定して、これらの問題がダウンストリームの計算に到達する前にキャッチし、チェックが失敗したときにパイプラインをブロックするか、アラートを送信します。
このチュートリアルでは、ods_user_info_d_starrocks に対して2つのルールを構成します。1つはテーブルがデータを受信したことを確認する強制ルール、もう1つは重複プライマリキーを検出する緩和ルールです。
前提条件
開始する前に、次のことを確認してください。
ApsaraDB RDS for MySQL テーブル
ods_user_info_dから E-MapReduce (EMR) Serverless StarRocks インスタンス内のods_user_info_d_starrocksへ、Data Integration を介して基本ユーザー情報を同期済みであること。Object Storage Service (OSS) 内の
user_log.txtから同じ EMR Serverless StarRocks インスタンス内のods_raw_log_d_starrocksへ、Data Integration を介してウェブサイトアクセスログを同期済みであること。収集したデータを Data Studio で基本ユーザープロファイルデータに処理済みであること。
モニタリング要件
次の表は、ユーザープロファイル分析パイプライン内の各テーブルのモニタリング要件について説明しています。このチュートリアルでは、ods_user_info_d_starrocks に焦点を当てます。
| テーブル | モニタリング要件 |
|---|---|
ods_raw_log_d_starrocks | 強制ルール: 日次同期行数 > 0 |
ods_user_info_d_starrocks | 強制ルール: 行数 > 0; 緩和ルール: ビジネスプライマリキーの一意性 |
dwd_log_info_di_starrocks | ルールなし |
dws_user_info_all_di_starrocks | ルールなし |
ads_user_info_1d_starrocks | 日次行数変動のモニタリングルール (UV観測) |
ルールの仕組み
モニタリングルールは、*合格* 条件を定義します。Data Quality がチェックを実行すると、データがその条件を満たしているかどうかを評価します。条件が満たされない場合、ルールは失敗します。
| ルールタイプ | 失敗時 | 使用するタイミング |
|---|---|---|
| 強制ルール | アラートが発生し、ダウンストリームノードがブロックされます | 違反した場合にダウンストリームの処理が無意味になる条件 (空のパーティションなど) |
| 弱いルール | アラートが発生しますが、ダウンストリームノードは続行されます | 調査する価値のあるデータ品質の問題を示すが、パイプラインのブロックを必要としない条件 |
ステップ1: テーブル別設定ページへの移動
DataWorks コンソールにログインします。上部のナビゲーションバーで、目的のリージョンを選択します。左側のナビゲーションウィンドウで、[データガバナンス] > [Data Quality] を選択します。表示されたページで、目的のワークスペースを選択し、[Data Quality に移動] をクリックします。
Data Quality ページの左側ナビゲーションウィンドウで、[ルールの設定] ＞ [テーブル別に設定] を選択します。
テーブル別設定ページで、次によってフィルタリングします。
データベースの種類: [StarRocks]
テーブル:
ods_user_info_d_starrocks
検索結果で、操作列の[ルール管理]をクリックします。テーブル品質の詳細ページが開きます。
ステップ2: モニタリングルールの構成
モニタリング範囲の選択
[モニター] タブで、[モニターの作成] をクリックします。
[データ範囲] パラメーターを
dt=$[yyyymmdd-1]に設定します。定期的なスケジュールによって生成されたテーブルデータをモニターするには、データ範囲の値が現在の日にテーブルに対して生成されたパーティションに対応していることを確認してください。
モニタリングルールの作成
このセクションでは、ods_user_info_d_starrocks に対して2つのルールを構成します。
毎日少なくとも1行が同期されたことを確認する強制ルール。これは、ソースデータが到着しなかったケースを検出します。
uid列に重複値がないことを検証する緩和ルール。これは、重複プライマリキーを発生させる ETLエラーを検出します。
強制ルールの作成:
[モニターの作成] ページで、[ルールの作成] をクリックします。[ルールの作成] パネルが開きます。
「[システムテンプレート]」タブで、テーブルが空でないを見つけ、「[使用]」をクリックします。
パネルの右側で、[重要度] を 厳格なルール に設定します。簡単に言うと、このルールは行数が 0 より大きい場合に合格します。不合格の場合（行数 = 0）、アラートが発生し、後続ノードがブロックされます。
弱いルールを作成する：
[システムテンプレート] タブで、[一意の値。固定値] を見つけ、[使用] をクリックします。
次のパラメーターを構成します。簡単に言えば、このルールは重複する
uid値の数が0に等しい場合に合格します。重複が検出された場合、アラートが発生しますが、パイプラインは実行を続行します。パラメーター 値 ルール スコープ uid(STRING)モニタリングしきい値 0(期待される重複数)重要度 弱いルールルールを保存するには、[OK] をクリックします。
トリガーメソッドと例外処理ポリシーの設定
トリガーメソッドを [本番環境でのノードスケジューリングによってトリガー] に設定し、データ同期中に作成された
ods_user_info_d_starrocksノードを選択します。例外処理ポリシーの下で、次のいずれかの操作を選択します。
[ノードの実行をブロック]
[受信者にアラート通知を送信]
[保存] をクリックします。
ステップ3: モニターのテスト
ルールが本番環境に移行する前にテストを実行し、構成が正しいことを確認します。
[ルール管理] タブの [モニターパースペクティブ] セクションで、作成したモニターを選択します。
タブの右側にある[テスト実行]をクリックします。
「テスト実行」ダイアログボックスで、「スケジュール時間」パラメーターを設定し、「テスト実行」をクリックします。
テストが完了したら、データが検証チェックを通過するかどうかを確認するために、[詳細の表示] をクリックします。
ステップ4: モニターアラートのサブスクライブ
「[モニター パースペクティブ]」セクションの「[ルール管理]」タブで、モニターを選択します。
タブの右側にある [アラート購読] をクリックします。
アラートサブスクリプション ダイアログボックスで、[通知方法] および [受信者] を設定し、操作列の [保存] をクリックします。
後でサブスクリプションを表示または変更するには、左側のナビゲーションウィンドウで [Quality O&M] > [モニター] を選択し、次に [マイサブスクリプション] を選択します。
次のステップ
データが処理された後、DataAnalysis を使用して結果を視覚化します。詳細については、「ダッシュボードでデータを視覚化する」をご参照ください。