Dataphin を使用してデータテーブルのデータ品質ルールを作成することで、品質モニタリングを効率化できます。このトピックでは、グローバルデータテーブルのデータ品質ルールを設定する方法について説明します。
前提条件
品質ルールを設定するには、モニタリングオブジェクトを追加する必要があります。手順については、「モニタリングオブジェクトの追加」または「」をご参照ください。
アクセス許可
スーパー管理者、品質管理者、および [品質ルール] - [管理] 権限が付与されたカスタムグローバルロールのユーザーは、品質ルールのスケジューリング、アラーム、例外アーカイブテーブル、スコアリングの重みを設定できます。
品質オーナーは、自身のモニタリングオブジェクトの品質ルールのスケジューリング、アラーム、例外アーカイブテーブル、スコアリングの重みを設定できます。
品質オーナーと標準ユーザーは、グローバルデータテーブルのデータソースに対する読み取り権限も必要です。この権限を申請するには、データソース権限の申請をご参照ください。
利用可能な操作権限は、オブジェクトによって異なります。詳細については、品質ルールの操作権限をご参照ください。
検証ルール
テーブルを品質ルールに基づいて評価した際に、弱いモニタリングルール がトリガーされると、システムはアラートを送信します。強いモニタリングルール がトリガーされると、ダーティデータがダウンストリームに流れるのを防ぐためにタスクを停止し、アラートを送信します。
試行とスケジュール実行
試行とスケジュール実行では、実行方法と結果の扱いが異なります。試行は、品質ルールが想定どおりに動作することを確認するために、実行をシミュレートします。試行の結果は、品質レポートには表示されません。スケジュール実行は、指定した時刻に品質ルールを実行し、その結果を品質レポートに記録します。
品質ルールの設定
Dataphin ホームページで、上部のナビゲーションバーから [ガバナンス] > [データクオリティ] を選択します。
左側のナビゲーションペインで [品質ルール] をクリックし、[グローバルデータテーブル] ページで対象オブジェクトの名前をクリックして [品質ルールの詳細] ページに移動します。
[品質ルール詳細] ページで、[品質ルールの作成] をクリックします。
[品質ルールの作成] ダイアログボックスで、パラメーターを設定します。
パラメーター
説明
基本情報
ルール名
品質ルールのカスタム名です。名前は最大 256 文字まで入力できます。
ルールの強度
選択可能なオプションは[弱いルール]と[強いルール]です。
[弱いルール]: [弱いルール] を選択した場合、品質ルールの検証に失敗しても、システムはアラームを発生させますが、下流タスクノードはブロックしません。
[強ルール]: [強ルール] を選択した場合、品質ルールチェックが異常な結果を返すと、アラームがトリガーされます。 下流タスク (コードチェックのスケジューリングやタスク起動スケジューリングなど) がある場合、ダーティデータの拡散を防ぐために下流タスクはブロックされます。 下流タスクがない場合 (定期的な品質スケジューリングなど)、アラームのみがトリガーされます。
説明
品質ルールのカスタム説明です。説明は最大 128 文字まで入力できます。
設定方法
[テンプレートから作成]:汎用システムテンプレートまたはカスタムビジネステンプレートを使用して、品質ルールを迅速に作成します。
[システムテンプレート]:テンプレートには設定可能な組み込みパラメーターが用意されています。この方法は、汎用ルールの作成に適しています。
[カスタムテンプレート]:テンプレートには、追加の設定が不要な事前設定済みパラメーターが用意されています。この方法は、通常、ビジネスロジックを含むルールの作成に使用されます。
[カスタム SQL]:SQL を使用してカスタム品質モニタリングルールを柔軟に定義できます。この方法は、柔軟で複雑なシナリオに適しています。
ルールテンプレート
ドロップダウンリストからルールテンプレートを選択します。オプションには、[完全性]、[一意性]、[適時性]、[有効性]、[一貫性]、[安定性]、および [カスタム SQL] が含まれます。
[完全性]:[フィールド NULL 値検証] および [フィールド空文字列検証] が含まれます。
[一意性]:[フィールド一意性検証]、[フィールドグループ数検証]、および [フィールド重複値数検証] が含まれます。
[適時性]:[時間関数比較]、[単一テーブル時間フィールド比較]、および [2 テーブル時間フィールド比較] が含まれます。
[有効性]:[フィールド形式検証]、[フィールド長検証]、[フィールド値範囲検証]、[コードテーブル参照比較]、および [データ標準コードテーブル参照比較] (データ標準モジュールが必要) が含まれます。
[一貫性]:[単一テーブルフィールド値一貫性比較]、[単一テーブルフィールド統計一貫性比較]、[単一フィールドビジネスロジック一貫性比較]、[2 テーブルフィールド値一貫性比較]、[2 テーブルフィールド統計一貫性比較]、[2 テーブルフィールドビジネスロジック一貫性比較]、および [クロスソース 2 テーブルフィールド統計一貫性比較] が含まれます。
[安定性]:[テーブル安定性検証]、[テーブル変動性検証]、[フィールド安定性検証]、および [フィールド変動性検証] が含まれます。
[カスタム SQL]:[カスタム統計検証] および [カスタムデータ詳細検証] が含まれます。
詳細については、「テンプレートタイプの説明」をご参照ください。
ルールタイプ
ルールタイプはテンプレートによって決まり、テンプレートの最も基本的な属性です。説明とフィルタリングに使用できます。
[モニタリング粒度]
設定方法が [カスタム SQL] の場合、モニタリング粒度を [テーブル全体] または特定の [フィールド] に設定できます。
[テンプレート設定]
[テンプレート情報]
品質ルールテンプレートを選択すると、その設定情報が表示されます。設定を変更するには、品質ルールテンプレートに移動してください。
ルール設定
ルール設定
設定オプションは、選択したルールテンプレートによって異なります。詳細については、「データテーブルパラメーター設定」をご参照ください。
[検証テーブルデータのフィルタリング]:デフォルトでは無効になっています。有効にすると、パーティションフィルターや一般的なデータフィルターなど、検証テーブルのフィルター条件を設定できます。フィルター条件は検証 SQL に直接追加されます。検証テーブルでパーティションフィルタリングが必要な場合は、スケジューリング設定でパーティション式を設定することを推奨します。これにより、検証されたパーティションが品質レポートを表示するための最小粒度として設定されます。
ルールテンプレートが consistency/Two-Table Field Statistic Consistency Comparison または consistency/Cross-Source Two-Table Field Statistic Consistency Comparison の場合、[比較対象テーブルデータのフィルター] を有効にできます。有効にすると、パーティションフィルターや一般的なデータフィルターなど、比較対象テーブルのフィルター条件を設定できます。フィルター条件は、検証 SQL に直接追加されます。
検証設定
ルール検証
システムは、検証結果を設定された例外条件と比較します。結果がこれらの条件を満たす場合、検証は失敗し、アラートなどの後続プロセスがトリガーされます。
例外検証に使用できるメトリクスは、テンプレートとその設定によって異なります。AND / OR ロジックで複数の条件を使用できます。実際の設定では、3 つ未満の条件を使用することを推奨します。
詳細については、「検証設定の説明」をご参照ください。
アーカイブ設定
例外のアーカイブ
デフォルトでは、この機能は [無効] になっています。[有効] にすると、異常なデータをファイルまたはテーブルにアーカイブできます。品質検証後、アーカイブされた異常なデータをダウンロードして分析できます。
[アーカイブモード] には [異常フィールドのみアーカイブ] と [全レコードをアーカイブ] があります。
[異常フィールドのみアーカイブ]:現在の監視対象フィールドのみを重複排除してアーカイブします。これは、単一のフィールドで異常なデータを識別するのに十分な場合に適しています。
[完全レコードのアーカイブ]:異常なデータを含むレコード全体をアーカイブします。これは、異常なデータを特定するために完全なレコードが必要な状況に適しています。
説明 注意:完全レコードのアーカイブはアーカイブされるデータ量を大幅に増加させるため、通常の状況では [異常フィールドのみアーカイブ] することを推奨します。
[アーカイブ場所] は [デフォルトのファイルサーバー] と [例外アーカイブテーブル] をサポートしています。例外アーカイブテーブルを作成していない場合は、[例外アーカイブテーブルの管理] をクリックして作成できます。詳細については、「例外アーカイブテーブルの追加」をご参照ください。
[デフォルトファイルサーバー]:Dataphin のデプロイ時に設定されたシステムファイルサーバーです。[検証レコード] - [検証詳細] ページから例外データを直接ダウンロードするか、デフォルトファイルサーバーに直接アクセスして例外データを取得できます。デフォルトファイルサーバーを使用する場合、各検証で最大 100 件の例外データエントリがアーカイブされるため、少量のデータの検証に適しています。
[異常データアーカイブテーブル]: より多くの異常データを保存したり、比較分析のために異なる検証レコードから異常データを統合したりする場合、独自のアーカイブテーブルを指定できます。各品質ルールは、1回の実行あたり最大 10,000 件の異常データエントリを記録できます。検証レコードページで単一の検証から異常データを迅速にダウンロードできるほか、アーカイブテーブルに直接アクセスしてそのライフサイクルをカスタマイズすることで、より高い柔軟性が得られます。
説明You can download the consolidated exception data that is generated by all rules for the current run. The download is limited to 10,000 records. If you want to view more data, archive the data to the specified exception archive table and then access the table directly.
An exception archive table must meet specific format requirements. Otherwise, an error may occur when you write data, which affects its use. For more information, see Add an exception archive table.
ビジネスプロパティ設定
プロパティ情報
ビジネスプロパティの入力方法は、品質ルールのプロパティ設定によって異なります。たとえば、プロパティの値タイプが、ビッグデータ部門、ビジネス部門、テクノロジー部門などのオプションを持つ列挙型 (複数選択) に設定されている場合、品質ルールを作成する際に、これらのオプションを含む複数選択ドロップダウンリストが表示されます。
プロパティの値タイプが長さ 256 のカスタム入力に設定されている場合、品質ルールを作成する際に、そのプロパティに最大 256 文字まで入力できます。
プロパティの入力方法が [範囲] の場合は、次のように設定します。
範囲: 通常、連続した数値または日付の範囲に使用されます。演算子 [>]、[>=]、[<]、および [<=] を使用できます。プロパティ設定の詳細については、「品質ルールプロパティの作成と管理」をご参照ください。
スケジューリングプロパティ設定
[スケジューリング方法]
事前設定されたスケジュールを選択します。スケジューリング方法は、品質ルールを作成した後に設定することもできます。新しいスケジュールを作成するには、スケジュールの作成をご参照ください。
品質スコア設定
[スコアリング方法]
有効な値は、[品質検証ステータス] と [データ適合率] です。
[品質検証ステータス]:最後に成功した実行の検証ステータスに基づいてルールをスコアリングします。検証に合格すると 100 点、不合格の場合は 0 点になります。
[データ適合率]:最後に成功した実行の正常データの割合 (適合率) をスコアとして使用します。たとえば、データ形式の有効性が 80% の場合、品質スコアは 80 になります。
利用できるスコアリング方法は、ルールテンプレートによって異なります。以下のテンプレートは、[品質検証ステータス] スコアリング方法のみをサポートしています。
一意性カテゴリ:フィールドグループ数検証およびフィールド重複値数検証。
一貫性カテゴリ:単一テーブルフィールド統計一貫性比較およびクロスソース 2 テーブルフィールド統計一貫性比較。
安定性カテゴリのすべてのテンプレート。
カスタム SQL カテゴリ:カスタム統計検証。
[品質スコアの重み]
ルールの品質スコアの重みです。この値は、監視対象の合計品質スコアを計算するために使用されます。1 から 10 の整数を選択できます。
[OK] をクリックして、ルール設定を保存します。
[SQL のプレビュー] をクリックすると、現在の設定を最後に保存されたバージョンと比較し、SQL の変更を確認できます。
説明主要な情報が不完全な場合、SQL のプレビューは使用できません。
左側のペインには、最後に保存された設定の SQL プレビューが表示されます。設定が保存されていない場合は空です。右側のペインには、現在の設定の SQL プレビューが表示されます。
ルール設定リスト
ルール設定リストページでは、設定されたデータテーブルルールに関する情報を表示し、表示、編集、テスト実行、実行、削除などの操作を実行できます。

エリア | 説明 |
① フィルターと検索エリア | オブジェクト名またはルール名で迅速に検索できます。 ルールタイプ、ルールテンプレート、ルールの強度、テスト実行ステータス、およびアクティベーションステータスでフィルタリングできます。 説明 品質ルールのビジネスプロパティが検索可能またはフィルタリング可能に設定されており、有効になっている場合、それらのプロパティで検索またはフィルタリングできます。 |
② リストエリア | このエリアには、オブジェクトタイプ / 名前、ルール名 / ID、テスト実行ステータス、アクティベーションステータス、[ルールタイプ]、[ルールテンプレート]、[ルールの強度]、[スケジューリングタイプ]、および関連するナレッジベースドキュメント情報が表示されます。[更新] の前にある
|
③ アクションエリア | 次の操作を実行できます:[表示]、[クローン]、[編集]、[テスト実行]、[実行]、[スケジューリングの設定]、[ナレッジベースドキュメントの関連付け]、[品質スコア設定]、および [削除]。
|
④ 一括操作エリア | 次の操作を一括で実行できます:[テスト実行]、[実行]、[スケジューリングの設定]、[有効化]、[無効化]、[ビジネスプロパティの変更]、[ナレッジベースドキュメントの関連付け]、[品質スコア設定]、[ルールのエクスポート]、および [削除]。
|
スケジュールの作成
品質ルールのスケジュールを設定する際は、既存のスケジュール設定をすばやく適用できます。各テーブルは最大 20 件のスケジュールに対応しています。
1 つの品質ルールに対して、最大 10 件のスケジュールを設定できます。
システムは、同一のスケジュール設定を自動的に重複排除します。
検証範囲は、品質検証ステートメントのフィルター条件として機能し、チェックごとのデータ範囲を制御します。また、この範囲は、品質レポートなどの下流コンポーネントを表示する際の最小粒度も定義します。
[Quality Rule Details] ページで [Schedule Configuration] タブをクリックし、[Create Schedule] をクリックして [Create Schedule] ダイアログボックスを開きます。
[Create Schedule] ダイアログボックスで、次のパラメーターを設定します。
パラメーター
説明
スケジュール名
スケジュールの任意の名前です。名前は最大 64 文字です。
スケジュールタイプ
[時間ベースのスケジュール]と[タスクトリガースケジュール]があります。
[時間ベースのスケジュール]:設定した時刻に、定期的にデータ品質チェックを実行します。このスケジュールタイプは、一定間隔でデータが生成されるシナリオに適しています。
[スケジューリング周期]:品質ルールの実行にはコンピューティングリソースが必要です。本番タスクへの影響を避けるため、複数の品質ルールを同時に実行しないでください。スケジューリング周期には、[Day]、[Week]、[Month]、[Hour]、[Minute] の 5 種類があります。
システムタイムゾーン (ユーザーセンターのタイムゾーン) とスケジュールタイムゾーン ([Management Center] > [System Settings] > [Basic Settings] で設定) が異なる場合、ルールはシステムタイムゾーンに基づいて実行されます。
[タスクトリガースケジュール]:指定したタスクが成功した後、または実行前に、設定済みの品質ルールを実行します。次のノードタイプのタスクをスケジュールのトリガーとして選択できます:SQL、Offline Pipeline、Python、Shell、Virtual、Dlink、Spark_jar、Hive_MR、Database SQL。このスケジュールタイプは、テーブルを変更するタスクが固定の場合に適しています。
説明トリガーとして選択できるのは、本番環境のタスクのみです。品質ルールが強いルールとして設定されている場合、検証の失敗が本番タスクに影響する可能性があります。ビジネス要件に応じて、注意して実施してください。
対応エンジンタイプ:MaxCompute、E-MapReduce 3.X、E-MapReduce 5.x、CDH 5.X、CDH 6.X、FusionInsight 8.X、AsiaInfo DP 5.3、Cloudera Data Platform 7.x、Lindorm (compute engine)、Transwarp TDH 6.x、Transwarp TDH 9.3.x。
[トリガー条件]:品質チェックをトリガーするタイミングを選択します。有効な値:[Trigger after all tasks are successful]、[Trigger after each task is successful]、[Trigger before each task runs]。
[トリガータスク]:以下のロールを持つユーザーは、本番プロジェクト内のタスクノードをトリガーとして選択できます。また、出力名でノードを検索できます。
以下のロールを持つユーザーは、本番プロジェクト内のタスクノードを選択できます:Prod/Basic プロジェクトのプロジェクト管理者、Prod プロジェクトで O&M システムロールを持つユーザー、Basic プロジェクトで developer システムロールを持つユーザー、Prod/Basic プロジェクトで [Project Quality Management]-[Quality Rule Management] 権限を持つカスタムプロジェクトロールのユーザー。
[Quality Rule]-[Management] 権限を持つカスタムグローバルロールのユーザーは、任意の本番プロジェクトのタスクノードを選択できます。
説明トリガー条件 を [Trigger after all tasks are successful] に設定する場合は、同じスケジューリング周期のトリガータスクを選択してください。これにより、ルール実行の遅延や品質チェック結果の生成遅延を防止できます。
[スケジュール条件]
デフォルトでは無効です。有効にすると、スケジュール実行の前に、システムがスケジュール条件を満たしているかどうかを確認します。条件を満たす場合のみ品質ルールが実行されます。条件を満たさない場合、現在の実行はスキップされます。
[ビジネス日付]/[実行日]:スケジュールタイプを [時間ベースのスケジュール] (時間ベースのスケジュールでは実行日を使用できません) または [タスクトリガースケジュール] に設定した場合、日付を設定できます。[General Calendar] または [custom calendar] を選択できます。カレンダーのカスタマイズ方法については、パブリックカレンダーの作成をご参照ください。
[General Calendar] を選択した場合は、[Month]、[Week]、[Date] に基づいて条件を設定できます。例:

[Custom Calendar] を選択した場合は、[Date Type] または [Tag] に基づいて条件を設定できます。例:

[インスタンスタイプ]:スケジュールタイプとして [Task-triggered schedule] を選択した場合、[定期インスタンス]、[バックフィルインスタンス]、[手動インスタンス] を選択できます。次の図を参照してください:

説明少なくとも 1 つの条件を設定する必要があります。条件を追加するには、[+ Add Rule] をクリックします。
最大 10 件の条件を設定できます。
条件間の論理関係は AND または OR に設定できます。
[検証範囲式]
編集可能なドロップダウンリストで、検証するデータ範囲を定義できます。
ds='${yyyyMMdd}'などのカスタム式を入力するか、組み込みのパーティション式を選択して変更することで、より迅速に設定できます。組み込み式の詳細については、「組み込みパーティション式タイプ」をご参照ください。説明複数の条件を使用する場合は、and または or で連結します (例:
province="Zhejiang" and ds<=${yyyyMMdd})。品質ルールにもフィルター条件が設定されている場合、その条件は検証範囲式と AND 演算子で結合されます。
検証範囲式はフルテーブルスキャンに対応しています。
注:フルテーブルスキャンは大量のリソースを消費し、一部のシナリオではサポートされません。フルテーブルスキャンを避けるために、パーティション式を設定してください。
[デフォルトの範囲日付]
デフォルトは現在のビジネス日付です。
[OK] をクリックして、スケジュール設定を完了します。
スケジュール設定リスト
スケジュールを作成した後、スケジュール設定リストから、スケジュールを表示、編集、クローン、または削除できます。

エリア | 説明 |
① フィルター・検索 | 名前でスケジュールを検索します。 [時間ベースのスケジュール] または [タスクトリガースケジュール] でフィルタリングします。 |
② リスト | 各スケジュール設定の [スケジュール名]、[スケジュールタイプ]、[最終更新者]、[最終更新日時] を表示します。 |
③ 操作 | スケジュールを編集、クローン、または削除できます。
|
アラート設定
ルールごとに異なる通知方法を設定し、重大度に基づいてアラートのルーティングを行えます。たとえば、強いルールの例外には電話アラートを、弱いルールの例外には SMS アラートを設定できます。品質ルールが複数のアラート設定に一致する場合は、アクティベーションポリシーを定義して、どの設定を有効にするかを決定できます。
1 つの監視対象に対して作成できるアラート設定は最大 20 件です。
[Quality Rule Details] ページで [Alert Configuration] タブをクリックし、[Create Alert Configuration] ボタンをクリックします。[Create Alert Configuration] ダイアログボックスが表示されます。
[Create Alert Configuration] ダイアログボックスで、パラメーターを設定します。
パラメーター
説明
[範囲]
[All rules]、[All strong rules]、[All weak rules]、または [Custom] を選択します。
説明監視対象ごとに、次の範囲それぞれについて 1 件のアラート設定を作成できます:[All rules]、[All strong rules]、[All weak rules]。新しいルールは、強度に基づいて該当するアラート設定に自動的に一致します。これらの設定のいずれかを変更するには、既存の設定を編集する必要があります。
[Custom] を選択した場合、現在の監視対象に関連付けられている既存のルールを最大 200 件まで選択できます。
[アラート設定名]
名前は監視対象内で一意である必要があり、256 文字を超えることはできません。
[アラート受信者]
少なくとも 1 人のアラート受信者と 1 つの通知方法を指定してください。
[アラート受信者]:受信者タイプを選択します。サポートされるタイプはカスタム、オンコールスケジュール、品質オーナーです。
カスタムのアラート受信者は最大 5 人、オンコールスケジュールは最大 3 件まで設定できます。
[通知方法]:電話、メール、SMS、DingTalk、Lark、WeCom、またはカスタムチャネル など、1 つ以上の通知方法を選択します。これらの方法は、Channel Settings で管理します。
[OK] をクリックします。
アラート設定リスト
アラート設定を作成した後、リストでソート、編集、削除できます。

エリア | 説明 |
① ポリシーエリア | 品質ルールが複数のアラート設定に一致した場合のアクティベーションポリシーを設定します:
|
② リストエリア | 各アラート設定の名前、有効範囲、受信者、通知方法を表示します。 [有効範囲]:範囲がカスタムの場合、関連付けられているオブジェクトとルールの名前を確認できます。ルールが削除されると、ルール名は表示されなくなります。この場合は、アラート設定を更新することを推奨します。 |
③ 操作エリア | これらの操作を使用して、アラート設定を編集または削除します。
|
例外アーカイブテーブルの追加
例外アーカイブテーブルは、品質ルールに失敗したレコードを格納します。
[クオリティルール詳細] ページで、[例外アーカイブ] タブをクリックし、次に [+例外アーカイブテーブルの追加] をクリックして [例外アーカイブテーブルの追加] ダイアログボックスを開きます。
[例外アーカイブテーブルの追加] ダイアログボックスで、パラメーターを設定します。
[追加方法] では、[新しいテーブル] または [既存のテーブルを選択] を選択できます。 このプロセスでは、特別な品質検証フィールドが追加され、例外データは元のデータテーブルに書き込まれるのではなく、別のテーブルにアーカイブされます。
[新しいテーブル]: カスタムテーブル名を指定できます。デフォルト名は current_table_name_exception_data です。テーブルを追加すると、システムは同じデータベースまたはデータソースに新しいテーブルを作成します。名前には、英字、数字、アンダースコア (_)、およびピリオド (.) を使用でき、長さは最大 128 文字です。
監視対象テーブルが物理テーブルの場合、システムは監視対象テーブルと同じプロジェクトに例外アーカイブテーブルを作成します。
監視対象テーブルがディメンション論理テーブルまたはファクト論理テーブルの場合、システムはデフォルトで同じプロジェクトに例外アーカイブテーブルを作成します。監視対象テーブルのモジュール内でプロジェクトを手動で指定することもできます。例:
projectA.table_name。監視対象テーブルが集計論理テーブルの場合、アーカイブテーブルには同じモジュール内のプロジェクト名を指定することを推奨します。そうしない場合、システムは監視対象テーブルのモジュール内のプロジェクトにアーカイブテーブルを自動的に作成します。
例外アーカイブテーブルには、監視対象テーブルのすべてのフィールドと、品質検証フィールドを含める必要があります。スクリプトの形式は次のとおりです:
create table 当前表名_exception_data (dataphin_quality_tenant_id varchar(64) comment 'テナント ID' , dataphin_quality_rule_id varchar(64) comment '品質ルール ID', dataphin_quality_rule_name varchar(256) comment '品質ルール名', dataphin_quality_column_name varchar(1024) comment '検証対象のフィールド名', dataphin_quality_watch_task_id varchar(128) comment '監視対象のタスク ID', dataphin_quality_rule_task_id varchar(64) comment 'ルールタスク ID', dataphin_quality_validate_time varchar(64) comment '品質チェックの時刻', dataphin_quality_archive_mode varchar(32) comment '例外アーカイブモード (ONLY_ERROR_FIELD/FULL_RECORD)', dataphin_quality_error_data string comment '例外データ', ljba_id bigint comment 'ljba のプライマリキー', ljb_id bigint comment 'ljb のプライマリキー', col_tinyint tinyint comment 'フィールドタイプは TINYINT、小文字', col_tinyint_02 tinyint comment '2', col_smallint smallint comment 'フィールドタイプは SMALLINT、小文字', col_smallint_02 smallint comment '4', col_int int comment 'フィールドタイプは INT、小文字', col_int_02 int comment '6', col_bigint bigint comment 'フィールドタイプは BIGINT、小文字', col_bigint_02 bigint comment '8', col_float float comment 'フィールドタイプは FLOAT、小文字', col_float_02 float comment '10', col_double double comment 'フィールドタイプは DOUBLE、小文字', col_double_02 double comment '11', col_decimal decimal(38,18) comment 'フィールドタイプは DECIMAL(38,18)、小文字', col_decimal_02 decimal(38,18) comment '12', col_varchar varchar(500) comment 'フィールドタイプは VARCHAR(500)、小文字', col_varchar_02 varchar(500) comment '13', col_char char(10) comment 'フィールドタイプは CHAR(10)、小文字', col_char_02 char(10) comment '14', col_string string comment 'フィールドタイプは STRING、小文字', col_string_02 string comment '15', col_date date comment 'フィールドタイプは DATE、小文字', col_date_02 date comment '16', col_datetime datetime comment 'フィールドタイプは DATETIME、小文字', col_datetime_02 datetime comment '17', col_timestamp timestamp comment 'フィールドタイプは TIMESTAMP、小文字', col_timestamp_02 timestamp comment '18', col_boolean boolean comment 'フィールドタイプは BOOLEAN、小文字', col_boolean_02 boolean comment '19', col_binary binary comment 'フィールドタイプは BINARY、小文字', col_binary_02 binary comment '20', col_array array<int> comment 'フィールドタイプは ARRAY<int>、小文字', col_array_02 array<string> comment '21', col_map map<string,string> comment 'フィールドタイプは MAP<string, string>、小文字', col_map_02 map<string,int> comment '22', ds string comment '日付パーティション (yyyyMMdd)' ) partitioned by (dataphin_quality_validate_date string comment '検証日 (パーティションフィールド)');
[既存のテーブルを選択]: 同じプロジェクトまたはデータソースからテーブルを選択できます。選択したテーブルには、監視対象テーブルのすべてのフィールドと品質検証フィールドを含める必要があります。[例外アーカイブテーブルの DDL を表示] をクリックすると、必要な CREATE TABLE ステートメントを表示できます。スクリプトの形式は次のとおりです。
create table 当前表名_exception_data (dataphin_quality_tenant_id varchar(64) comment 'テナント ID' , dataphin_quality_rule_id varchar(64) comment '品質ルール ID', dataphin_quality_rule_name varchar(256) comment '品質ルール名', dataphin_quality_column_name varchar(1024) comment '検証対象のフィールド名', dataphin_quality_watch_task_id varchar(128) comment '監視対象のタスク ID', dataphin_quality_rule_task_id varchar(64) comment 'ルールタスク ID', dataphin_quality_validate_time varchar(64) comment '品質チェックの時刻', dataphin_quality_archive_mode varchar(32) comment '例外アーカイブモード (ONLY_ERROR_FIELD/FULL_RECORD)', dataphin_quality_error_data string comment '例外データ', ljba_id bigint comment 'ljba のプライマリキー', ljb_id bigint comment 'ljb のプライマリキー', col_tinyint tinyint comment 'フィールドタイプは TINYINT、小文字', col_tinyint_02 tinyint comment '2', col_smallint smallint comment 'フィールドタイプは SMALLINT、小文字', col_smallint_02 smallint comment '4', col_int int comment 'フィールドタイプは INT、小文字', col_int_02 int comment '6', col_bigint bigint comment 'フィールドタイプは BIGINT、小文字', col_bigint_02 bigint comment '8', col_float float comment 'フィールドタイプは FLOAT、小文字', col_float_02 float comment '10', col_double double comment 'フィールドタイプは DOUBLE、小文字', col_double_02 double comment '11', col_decimal decimal(38,18) comment 'フィールドタイプは DECIMAL(38,18)、小文字', col_decimal_02 decimal(38,18) comment '12', col_varchar varchar(500) comment 'フィールドタイプは VARCHAR(500)、小文字', col_varchar_02 varchar(500) comment '13', col_char char(10) comment 'フィールドタイプは CHAR(10)、小文字', col_char_02 char(10) comment '14', col_string string comment 'フィールドタイプは STRING、小文字', col_string_02 string comment '15', col_date date comment 'フィールドタイプは DATE、小文字', col_date_02 date comment '16', col_datetime datetime comment 'フィールドタイプは DATETIME、小文字', col_datetime_02 datetime comment '17', col_timestamp timestamp comment 'フィールドタイプは TIMESTAMP、小文字', col_timestamp_02 timestamp comment '18', col_boolean boolean comment 'フィールドタイプは BOOLEAN、小文字', col_boolean_02 boolean comment '19', col_binary binary comment 'フィールドタイプは BINARY、小文字', col_binary_02 binary comment '20', col_array array<int> comment 'フィールドタイプは ARRAY<int>、小文字', col_array_02 array<string> comment '21', col_map map<string,string> comment 'フィールドタイプは MAP<string, string>、小文字', col_map_02 map<string,int> comment '22', ds string comment '日付パーティション (yyyyMMdd)' ) partitioned by (dataphin_quality_validate_date string comment '検証日 (パーティションフィールド)');
例外アーカイブテーブルを追加するには、[OK] をクリックします。
[作成後、自動的にアクティブなアーカイブテーブルとして設定する] を選択できます。このオプションを選択すると、テーブルが後続の品質ルールのアーカイブ先として自動的に設定されます。
例外アーカイブテーブルリスト
テーブルが正常に追加されると、システムは、デフォルトでリストの最初のテーブルをアクティブなアーカイブテーブルとして設定します。例外アーカイブテーブルの名前をクリックすると、そのスキーマを表示できます。他のテーブルをアクティブなアーカイブテーブルとして設定したり、削除したりすることもできます。
[アクティブアーカイブテーブルとして設定]: アクティブアーカイブテーブルは、カスタムアーカイブテーブルを使用するように設定されている監視対象オブジェクトのすべての品質ルールから例外データを受信します。
[削除]:この操作は、例外アーカイブテーブルへの参照のみを削除し、物理テーブル自体は削除しません。後で参照を再追加できます。
品質レポート
[品質レポート]をクリックして、現在の品質ルールの[ルール検証概要]と[ルール検証詳細]を表示します。
ルール検証詳細は、例外結果、パーティション時間、またはルールやオブジェクト名のキーワードでフィルターできます。
操作列で、
アイコンをクリックして、ルール検証詳細を表示します。操作列で、
アイコンをクリックして、実行ログを表示します。
品質ルールの権限管理
[権限管理] をクリックし、[詳細の表示] 権限を設定して、検証レコードの詳細、品質ルールの詳細、および品質レポートを表示できるメンバーを指定します。
[詳細の表示権限]:[すべてのメンバー] または [現在のオブジェクトに対する品質管理権限を持つメンバーのみ] を選択できます。
[OK] をクリックして権限管理設定を完了します。
次のステップ
品質ルールを設定した後、グローバルデータテーブルのルールリストページで確認できます。詳細については、「監視対象リストの表示」または「」をご参照ください。
