パイプラインでのダーティデータブロック - DataWorks

データ品質監視ノードを使用すると、監視ルールを設定してデータソース内のテーブルの品質をチェックできます。ダーティデータの検出、行数の検証、null 値のチェックなどが可能です。このノードはスケジューリングパイプラインの一部として実行され、データ品質の問題が検出されると下流タスクを自動的にブロックし、ダーティデータが Extract, Transform, and Load (ETL) パイプライン全体に伝播するのを防ぎます。

仕組み

データ品質監視ノードが実行されると、設定された各ルールが監視対象テーブルに対して評価されます。ルールチェックでアノマリーが返された場合、ノードは設定された処理ポリシーを適用します。つまり、現在のノードを停止して下流タスクをブロックするか、アラートを送信しながら続行するかのいずれかです。

制限事項

サポートされるデータソース： MaxCompute、E-MapReduce、Hologres、CDH Hive、AnalyticDB for PostgreSQL、AnalyticDB for MySQL、StarRocks
ノードごとに 1 つのテーブル： 各ノードは 1 つのテーブルを監視しますが、ノードに対して複数の監視ルールを設定できます。複数のテーブルを監視するには、複数のデータ品質監視ノードを作成します。
ワークスペースのバインド： 監視対象テーブルは、ノードと同じワークスペースにバインドされたデータソースに属している必要があります。
パーティションの監視： パーティションテーブルの場合は、パーティションフィルター式を指定します。非パーティション化テーブルの場合、デフォルトでテーブル全体が監視されます。
DataStudio でのみ管理されるルール： DataStudio で作成されたルールは、DataStudio でのみ実行、変更、公開、管理できます。Data Quality モジュールでは、これらのルールを表示することはできますが、定期実行をトリガーしたり、そこで管理したりすることはできません。
公開によるルールの置換： ノード内の監視ルールを変更してノードを再公開すると、元の監視ルールは置き換えられます。

前提条件

開始する前に、以下が準備されていることを確認してください。

データ開発 (DataStudio) でビジネスフローが作成されていること。詳細については、「ビジネスフローの作成」をご参照ください。
データソースが作成され、現在のワークスペースにバインドされており、ターゲットテーブルがデータソース内にすでに作成されていること。詳細については、「データソース管理」、「Resource Management」、「ノード開発」をご参照ください。
Serverless リソースグループが作成されていること。データ品質監視ノードは Serverless リソースグループでのみ実行されます。詳細については、「Resource Management」をご参照ください。
(オプション、RAM ユーザーの場合) タスク開発用の Resource Access Management (RAM) ユーザーが、[開発] または [ワークスペース管理者] ロールでワークスペースに追加されていること。ワークスペース管理者ロールには広範な権限があるため、慎重に付与する必要があります。詳細については、「ワークスペースメンバーの追加」をご参照ください。

ステップ 1：データ品質監視ノードの作成

DataWorks コンソールにログインします。上部のナビゲーションバーで、対象のリージョンを選択します。左側のナビゲーションウィンドウで、[データ開発と O&M] > [データ開発] を選択します。ドロップダウンリストから対象のワークスペースを選択し、[データ開発へ] をクリックします。
DataStudio で、対象のビジネスフローを右クリックし、[ノードの作成] > [データ品質] > [データ品質監視] を選択します。
[ノードの作成] ダイアログボックスで、名前を入力し、[確認] をクリックします。

ステップ 2：監視ルールの設定

1. 監視対象テーブルの選択

[テーブルの追加] をクリックします。[テーブルの追加] ダイアログボックスで、対象のテーブルを検索して選択します。

2. データ範囲の設定

非パーティション化テーブル： デフォルトでテーブル全体が監視されます。このステップはスキップしてください。
パーティションテーブル： 監視するパーティションを選択します。必要に応じてスケジューリングパラメーターを使用します。[プレビュー] をクリックして、パーティションフィルター式の結果を確認します。

3. ルールの作成またはインポート

設定されたルールはデフォルトで有効になります。新しいルールを作成するか、既存のルールをインポートします。

ルールの作成

[ルールの作成] をクリックして、テンプレートまたはカスタム SQL ステートメントから監視ルールを作成します。

システムテンプレートから作成

プラットフォームには、組み込みのテーブルレベルおよびフィールドレベルのルールテンプレートが用意されています。テンプレートを選択して、ルールを迅速に作成します。左側のシステムテンプレートリストからテンプレートを見つけて [+使用] をクリックすることもできます。

組み込みルールテンプレートに基づくルール設定のパラメーター

次の表に、ルールパラメーターを示します。

パラメーター	説明
ルール名	監視ルールの名前。
テンプレート	実行するルール検証のタイプ。利用可能な組み込みテンプレートについては、「組み込みルールテンプレートの表示」をご参照ください。説明平均値、合計、最小値、最大値のフィールドレベルのルールは、数値フィールドにのみ適用されます。
ルール範囲	ルールの範囲。テーブルレベルのルールは現在のテーブルに適用されます。フィールドレベルのルールは特定のフィールドに適用されます。
比較方法	データが期待値を満たしているかどうかをルールが判断する方法。[手動設定] または [インテリジェント動的しきい値] を選択します。詳細については、以下の比較方法の表をご参照ください。
監視しきい値	比較方法と組み合わせて使用されるしきい値。詳細については、以下の比較方法の表をご参照ください。
問題データを保持	有効になっていてチェックが失敗した場合、システムは問題のある行を格納するテーブルを作成します。MaxCompute テーブルおよび特定のルールタイプでのみ利用可能です。ルールが [無効] の場合、問題データは保持されません。
ステータス	本番環境でルールがアクティブかどうか。[無効] のルールは、テスト実行やスケジューリングノードによってトリガーできません。
重要度	ルール違反が関連するスケジューリングノードをブロックするかどうかを決定します。強制ルールは、重大なしきい値を超えた場合にノードをブロックしますが、ソフトルールはブロックしません。2 つのルール強度の動作の違いについては、「ステップ 3：処理ポリシーの設定」をご参照ください。
設定ソース	ルール設定のソース。デフォルト値は [Data Quality] です。
説明	ルールのオプションの説明。

比較方法としきい値

比較方法	仕組み	しきい値パラメーター
手動設定	チェック出力と、固定された期待値または定義した変動範囲を比較します。数値出力の場合：サポートされる演算子は「より大きい」、「以上」、「に等しい」、「に等しくない」、「より小さい」、「以下」です。変動出力の場合：サポートされる演算子は絶対値、上昇、および下降です。	通常のしきい値：チェック結果がこの範囲内にある場合、データは期待通りです。赤色のしきい値：チェック結果がこの境界を越えた場合、データは期待通りではありません。変動ルールの場合、ビジネス運用に影響しない警告のためのオレンジ色のしきい値を設定することもできます。
インテリジェント動的しきい値	システムがインテリジェントアルゴリズムを使用して、適切なしきい値を自動的に決定します。手動でのしきい値設定は不要です。カスタム SQL、カスタム範囲、または動的しきい値ルールにのみ適用されます。	オレンジ色のしきい値：チェック結果が、ビジネス運用に影響しないアノマリーを示します。

比較方法が [インテリジェント動的しきい値] に設定されている場合は、[重要度] パラメーターを設定します。

カスタムテンプレートから作成

このメソッドを使用する前に、[Data Quality] > [品質資産] > [ルールテンプレートライブラリ] に移動して、カスタムルールテンプレートを作成します。その後、そのテンプレートに基づいて監視ルールを作成します。詳細については、「カスタムルールテンプレートの作成と管理」をご参照ください。

左側のテンプレートリストからカスタムテンプレートを見つけて [+使用] をクリックすることもできます。

カスタムルールテンプレートに基づくルール設定のパラメーター

以下のパラメーターは、カスタムテンプレートルールに固有のものです。その他のパラメーターについては、上記のシステムテンプレートのパラメーター表をご参照ください。

パラメーター 説明

FLAG パラメーター ルールの SQL ステートメントが実行される前に実行される SET 文。

SQL 完全なチェックロジックを定義する SQL ステートメント。ステートメントは単一の数値 (1 行 1 列) を返す必要があります。パーティションフィルター式は角括弧 [] で囲みます。例：SELECT count(*) FROM ${tableName} WHERE ds=$[yyyymmdd];。${tableName} 変数は、監視対象のテーブル名に自動的に置き換えられます。このパラメーターが設定されている場合、モニター設定の [データ範囲] パーティション設定は上書きされます。ルールは、この SQL ステートメントの WHERE 句に基づいてチェックするパーティションを決定します。

パラメーター	説明
FLAG パラメーター	ルールの SQL ステートメントが実行される前に実行される SET 文。
SQL	完全なチェックロジックを定義する SQL ステートメント。ステートメントは単一の数値 (1 行 1 列) を返す必要があります。パーティションフィルター式は角括弧 `[]` で囲みます。例：`SELECT count() FROM ${tableName} WHERE ds=$[yyyymmdd];`。`${tableName}` 変数は、監視対象のテーブル名に自動的に置き換えられます。このパラメーターが設定されている場合、モニター設定の [データ範囲]* パーティション設定は上書きされます。ルールは、この SQL ステートメントの WHERE 句に基づいてチェックするパーティションを決定します。

カスタム SQL ステートメントから作成

このメソッドを使用すると、テンプレートなしでカスタムチェックロジックを直接定義できます。

カスタム SQL ステートメントに基づくルール設定のパラメーター

以下のパラメーターは、カスタム SQL ルールに固有のものです。その他のパラメーターについては、上記のシステムテンプレートのパラメーター表をご参照ください。

パラメーター 説明

FLAG パラメーター ルールの SQL ステートメントが実行される前に実行される SET 文。

SQL 完全なチェックロジックを定義する SQL ステートメント。ステートメントは単一の数値 (1 行 1 列) を返す必要があります。パーティションフィルター式は角括弧 [] で囲みます。例：SELECT count(*) FROM <table_name> WHERE ds=$[yyyymmdd];。<table_name> を実際のテーブル名に置き換えます。このパラメーターが設定されている場合、モニター設定の [データ範囲] パーティション設定は上書きされます。ルールは、この SQL ステートメントの WHERE 句に基づいてチェックするパーティションを決定します。

パラメーター	説明
FLAG パラメーター	ルールの SQL ステートメントが実行される前に実行される SET 文。
SQL	完全なチェックロジックを定義する SQL ステートメント。ステートメントは単一の数値 (1 行 1 列) を返す必要があります。パーティションフィルター式は角括弧 `[]` で囲みます。例：`SELECT count() FROM <table_name> WHERE ds=$[yyyymmdd];`。`<table_name>` を実際のテーブル名に置き換えます。このパラメーターが設定されている場合、モニター設定の [データ範囲]* パーティション設定は上書きされます。ルールは、この SQL ステートメントの WHERE 句に基づいてチェックするパーティションを決定します。

既存ルールのインポート

対象テーブルの監視ルールが [Data Quality] モジュールにすでに存在する場合、それらをインポートしてルールを迅速にクローンできます。ルールが存在しない場合は、まず Data Quality モジュールで作成する必要があります。詳細については、「単一テーブルのルールの設定」をご参照ください。これにより、テーブルレベルとフィールドレベルの両方のルールを一括でインポートできます。

[ルールのインポート] をクリックします。ルール ID または名前、ルールテンプレート、または関連する範囲でインポートするルールを検索して選択します。

データ品質監視ノードを公開すると、ルールの詳細は [Data Quality] モジュールで表示できますが、ルールの変更や削除などの管理操作はそこでは利用できません。

4. 計算リソースの設定

品質ルールチェックに使用する計算リソースグループを選択します。これにより、どのデータソースが監視タスクを実行するかが指定されます。デフォルトでは、監視対象テーブルのデータソースが使用されます。

別のデータソースを選択した場合は、そのデータソースが監視対象テーブルにアクセスできることを確認してください。

ステップ 3：処理ポリシーの設定

ノード設定ページの [処理ポリシー] セクションで、チェックのアノマリーに対するノードの応答方法と通知の配信方法を設定します。

例外カテゴリと処理ポリシー

次の表は、各例外タイプ、それをトリガーするもの、および各ポリシーがパイプラインの実行にどのように影響するかを示しています。

例外カテゴリ	意味	ポリシー：無視しない	ポリシー：無視
強制ルール - エラーアラート	強制ルールの赤色のしきい値を超えました。監視対象データは期待値を満たしておらず、下流の操作に影響を与える可能性があります。	現在のノードは停止し、失敗に設定されます。下流のノードは実行されません。	パイプラインは続行します。
強制ルール - 警告アラート	強制ルールのオレンジ色のしきい値がトリガーされました。アノマリーは存在しますが、下流の操作には影響しません。	現在のノードは停止します。下流のノードは実行されません。	パイプラインは続行します。
強制ルール - チェック失敗	モニターの実行に失敗しました (たとえば、監視対象のパーティションが生成されなかった、または SQL ステートメントが失敗した)。	現在のノードは停止します。下流のノードは実行されません。	パイプラインは続行します。
ソフトルール - エラーアラート	ソフトルールの赤色のしきい値を超えました。	現在のノードは停止します。下流のノードは実行されません。	パイプラインは続行します。
ソフトルール - 警告アラート	ソフトルールのオレンジ色のしきい値がトリガーされました。	現在のノードは停止します。下流のノードは実行されません。	パイプラインは続行します。
ソフトルール - チェック失敗	ソフトルールのモニターの実行に失敗しました。	現在のノードは停止します。下流のノードは実行されません。	パイプラインは続行します。

ビジネスへの影響評価に基づいて処理ポリシーを設定します。

無視しない： 指定された例外カテゴリが検出されると、ノードは停止し、そのステータスは失敗に設定されます。下流のノードは実行されず、パイプラインをブロックしてダーティデータが広がるのを防ぎます。必要に応じて複数の例外カテゴリを追加します。例外が下流に大きな影響を与える場合は、このポリシーを使用します。
無視： 例外は記録され、下流のノードは実行を継続し、パイプラインはブロックされません。

通知設定

例外通知の配信方法を設定します。例外が発生すると、プラットフォームは指定されたメソッドを使用して通知を送信します。

メール、メールとショートメッセージ、または電話： 現在のアカウント内のユーザーから受信者を選択します。メールアドレスと電話番号が正しく設定されていることを確認してください。詳細については、「アラート連絡先の表示と設定」をご参照ください。
Webhook： Webhook URL を入力します。Webhook URL の取得方法の詳細については、「Webhook URL の取得」をご参照ください。

ステップ 4：スケジューリングの設定

ノードを定期的に実行するには、右側のペインで [プロパティ] をクリックし、スケジューリングプロパティを設定します。詳細については、「ノードのスケジューリングプロパティの設定」をご参照ください。

ノードを送信する前に、[再実行] と [親ノード] のプロパティを設定してください。

ステップ 5：タスクのデバッグ

(オプション) リソースグループを選択し、スケジューリングパラメーターに値を割り当てます。ツールバーのアイコンをクリックします。[パラメーター] ダイアログボックスで、スケジューリングリソースグループを選択し、タスクで使用されるスケジューリングパラメーターに値を割り当てます。詳細については、「タスクのデバッグプロセス」をご参照ください。
タスクを保存して実行します。[保存] アイコンをクリックしてタスクを保存し、次に [実行] アイコンをクリックして実行します。実行が完了したら、ノード設定ページの下部で結果を表示します。実行が失敗した場合は、エラーメッセージを確認してトラブルシューティングを行います。
(オプション) スモークテストを実行します。スケジューリングノードタスクが開発環境で期待通りに実行されることを確認するために、ノードを送信するとき、または送信後にスモークテストを実行します。詳細については、「スモークテストの実行」をご参照ください。

ステップ 6：タスクの送信と公開

ノードを送信して公開すると、設定された品質ルールも送信されて公開されます。公開後、ノードはスケジューリング設定に従って定期的に実行されます。

[保存] アイコンをクリックしてノードを保存します。
[送信] アイコンをクリックしてノードを送信します。[送信] ダイアログボックスで、[変更の説明] を入力します。必要に応じて、送信後にコードレビューを実行するかどうかを選択します。

送信する前に [再実行] と [親ノード] のプロパティを設定してください。コードレビューは設定の品質を保証するのに役立ちます。送信されたノードは、レビュー担当者が承認した後にのみ公開できます。詳細については、「コードレビュー」をご参照ください。
標準モードのワークスペースを使用している場合は、ノード設定ページの右上隅にある [デプロイ] をクリックして、タスクを本番環境に公開します。詳細については、「タスクの公開」をご参照ください。

次のステップ

タスクの O&M： タスクが公開されると、定期的に実行されます。ノード設定ページの右上隅にある [オペレーションセンター] をクリックして、ノードのステータスやトリガーされたルールの詳細など、定期タスクのスケジューリングと実行ステータスを表示します。詳細については、「定期タスクの管理」をご参照ください。
[Data Quality]： 品質ルールが公開された後、Data Quality モジュールに移動してルールの詳細を表示します。ルールの変更や削除などの管理操作はそこでは利用できません。詳細については、「Data Quality」をご参照ください。