Dataphin では、テーブルの品質ルールを作成することで、テーブルの品質モニタリングを簡素化できます。このトピックでは、テーブルのグローバル品質ルールを設定する方法について説明します。
前提条件
品質ルールを設定する前に、監視対象を追加する必要があります。詳細については、「監視対象の追加」または「」をご参照ください。
権限
スーパー管理者、品質管理者、および「[品質ルール]-[管理]」権限を持つカスタムグローバルロールは、品質ルールのスケジューリング、アラート、例外アーカイブテーブル、スコアリングの重み、ランタイム設定などを設定できます。
品質オーナーは、自身のモニタリングオブジェクト上の品質ルールに対して、スケジューリング、アラート、例外アーカイビングテーブル、スコアリングの重み、およびランタイム設定を設定できます。
品質オーナーと標準ユーザーは、グローバルデータテーブルを含むデータソースの同期読み取り権限も必要です。この権限を申請するには、データソース権限の申請をご参照ください。
サポートされている操作権限はオブジェクトによって異なります。詳細については、「品質ルールの操作権限」をご参照ください。
検証ルール
テーブルが品質ルールに基づいて検証される際、 弱いモニタリングルール がトリガーされた場合、異常を迅速に対処できるよう、システムがアラートを送信します。 強いモニタリングルール がトリガーされた場合、システムは関連するタスクを自動的に停止してダーティデータがダウンストリームに流れるのを防ぎ、アラートを送信します。
ドライランと実行
ドライランと実行では、その実行と結果が異なります。ドライラン は、品質ルールの動作を検証するためのシミュレーション実行であり、その結果は品質レポートに表示されません。実行 は、指定されたタイムウィンドウ内に品質ルールを検証し、その結果を品質レポートに出力します。
品質ルールの設定
Dataphin ホームページで、上部のメニューバーから [ガバナンス] > [データ品質] を選択します。
左側のナビゲーションペインで[品質ルール]をクリックし、[グローバルデータテーブル]ページで、対象オブジェクトの名前をクリックして[品質ルールの詳細]ページを開き、品質ルールを設定します。
[品質ルール詳細] ページで、 [品質ルールの作成] をクリックします。
[品質ルールの作成] ダイアログボックスで、パラメーターを設定します。
パラメータ
説明
基本情報
ルール名
品質ルールのカスタム名です。最大 256 文字まで指定できます。
ルールの強度
[弱いルール] または [強いルール] を選択できます。
[弱いルール]: [弱いルール] を選択すると、検証結果が異常な場合にアラートが生成されますが、後続のタスクはブロックされません。
[強ルール]: [強ルール] を選択すると、検証結果が異常な場合にアラートがトリガーされます。 下流タスク (コードチェックスケジューリングやタスクトリガースケジューリングなど) が存在する場合は、破損データの拡散を防ぐためにタスクはブロックされます。 下流タスク (定期的な品質スケジューリングなど) が存在しない場合は、アラートのみがトリガーされます。
説明
品質ルールのカスタムの説明です。最大 128 文字まで指定できます。
設定方法
[テンプレートから作成]： 汎用システムテンプレートまたはカスタムビジネステンプレートを使用して、品質ルールを迅速に作成します。
[システムテンプレート]： テンプレートの組み込みパラメータは設定可能です。汎用ルールの作成に適しています。
[カスタムテンプレート]： パラメータはテンプレートに事前設定されており、設定は不要です。通常、ビジネスロジックを含むルールの作成に使用されます。
[カスタム SQL]： SQL を使用してデータ品質モニタリングルールを柔軟に定義します。この方法は複雑なシナリオに適しています。
ルールテンプレート
ドロップダウンリストからルールテンプレートを選択します。オプションには、[完全性]、[一意性]、[適時性]、[有効性]、[一貫性]、[安定性]、および [カスタム SQL] が含まれます。
[完全性]： [フィールドのNULL値検証] および [フィールドの空文字列検証] が含まれます。
[一意性]： [フィールドの一意性検証]、[フィールドグループ数の検証]、および [重複フィールド値数の検証] が含まれます。
[適時性]： [時間関数の比較]、[単一テーブル内の時間フィールドの比較]、および [2つのテーブル間の時間フィールドの比較] が含まれます。
[有効性]： [フィールド形式の検証]、[フィールド長の検証]、[フィールド値の範囲検証]、[コードテーブル参照比較]、および [データ標準コードテーブル参照比較] (データ標準モジュールが必要です) が含まれます。
[一貫性]： [単一テーブル内のフィールド値の一貫性比較]、[単一テーブル内のフィールドの統計値の一貫性比較]、[単一フィールドのビジネスロジック一貫性比較]、[2つのテーブル間のフィールド値の一貫性比較]、[2つのテーブル間のフィールドの統計値の一貫性比較および2つのテーブル間のフィールドのビジネスロジック一貫性比較]、および [2つのクロスソーステーブル間のフィールドの統計値の一貫性比較] が含まれます。
[安定性]： [テーブルの安定性検証]、[テーブルの変動検証]、[フィールドの安定性検証]、および [フィールドの変動検証] が含まれます。
[カスタム SQL]： [カスタム統計メトリクスの検証] および [カスタムデータ詳細の検証] が含まれます。
詳細については、「テンプレートタイプの説明」をご参照ください。
ルールタイプ
テンプレートの基本属性で、説明やフィルタリングに使用されます。
[モニタリング粒度]
設定タイプが [カスタム SQL] の場合、モニタリング粒度を設定できます。[テーブル全体] を選択するか、特定の [フィールド] を指定できます。
[テンプレート設定]
[テンプレート情報]
品質ルールテンプレートを選択すると、その設定情報が表示されます。設定情報を変更する必要がある場合は、「品質ルールテンプレート」で変更できます。
ルール設定
ルール設定
ルール設定は、選択したルールテンプレートによって異なります。詳細については、「テーブルパラメータ設定」をご参照ください。
[検証テーブルのデータフィルタリング]： デフォルトでは無効です。この機能を有効にすると、フィルタ条件、パーティションフィルタリング、または通常のデータフィルタリングを設定できます。フィルタ条件は、検証 SQL に直接追加されます。検証テーブルにパーティションフィルタリングが必要な場合は、スケジューリング設定でパーティション式を設定します。式を設定すると、検証パーティションが品質レポートを表示するための最小粒度として使用されます。
ルールテンプレートを2 つのテーブルの一貫性/統計値の一貫性比較または2 つのテーブルの一貫性/クロスソース統計値の一貫性比較に設定すると、[比較テーブルのデータフィルタリング] を有効にできます。これにより、比較テーブルに対してフィルター条件、パーティションフィルタリング、または通常のデータフィルタリングを設定できます。フィルター条件は、検証 SQL に直接追加されます。
検証設定
ルール検証
データ品質ルールが検証されると、結果は異常検証設定と比較されます。結果が条件を満たす場合、検証は失敗し、アラートなどの後続プロセスがトリガーされます。
異常検証に使用できるメトリクスは、テンプレートと設定内容によって決まります。検証は、複数の基準に対して AND/OR ロジックをサポートします。実際の設定では、3 つ未満の基準を使用することを推奨します。
詳細については、「検証設定」をご参照ください。
Archive Configuration
Exception Archiving
This feature is disabled by default. When you enable it, you can archive abnormal data to files or tables, and then download and analyze the archived data after a quality validation.
[Archive Mode] supports [Archive Only Anomalous Fields] and [Archive Full Records].
[Archive Only Abnormal Fields]: Deduplicates and archives only the current monitored field. This is suitable for scenarios where abnormal data can be uniquely identified by a single field.
[Archive Entire Record]: Archives the entire record that contains anomalous data. Use this option when the entire record is required to locate the anomalous data. [Note]: Because archiving the entire record significantly increases the amount of archived data, we recommend that you archive only anomalous fields in most cases.
[Archive Location] supports [Default File Server] and [Custom Exception Archive Table]. If you have not created an exception archive table, you can click [Manage Exception Archive Tables] to create one. For more information, see Add an exception archive table.
[Default file server]: The system file server that is configured when you deploy Dataphin. You can directly download exception data from the Validation Record-Validation Details page or access the default file server to obtain the exception data. When you use the default file server, each validation run archives a maximum of 100 exception data records. This is suitable for scenarios where you validate small volumes of data.
[Custom exception archive table]: If you want to store more exception data or consolidate exception data from different validation records for subsequent comparative analysis, you can specify a custom archive table. Each quality rule can record a maximum of 10,000 exception records per run. In addition to downloading exception data for a single validation run from the validation records page, you can also directly access the archive table and customize its lifecycle for greater flexibility.
説明You can download a summary of the exception data generated by all rules in the current run. The download is limited to 10,000 entries. To view more data, archive the data to a specified exception archive table and then access the table directly to retrieve it.
An exception archive table must meet specific format requirements. Otherwise, an error may occur when you write data to the table, which affects its use. For more information, see Add an exception archive table.
When the compute engine is Transwarp TDH 6.x or Transwarp TDH 9.3.x and you select a custom exception archive table, you can select [Display field descriptions in the exception data table header]. After you select this option, the fields in the downloaded exception data table will contain comment information.
サービスプロパティ設定
プロパティ
ビジネス属性の入力形式は、品質ルール属性の設定によって異なります。たとえば、管理部門属性が「ビッグデータ部門」、「ビジネス部門」、「テクノロジー部門」をオプションに持つ複数選択の列挙型として設定されている場合、品質ルールを作成する際、この属性はこれらのオプションを含む複数選択ドロップダウンリストとして表示されます。
ルールオーナーフィールドは、最大長 256 文字のカスタム入力フィールドです。したがって、品質ルールを作成する際、このフィールドに入力する値はこの制限を超えることはできません。
属性フィールドが [値の範囲] を受け付ける場合、設定方法は次のとおりです。
範囲：連続した数値または日付の範囲に使用します。演算子として [>]、[>=]、[<]、または [<=] を選択できます。詳細については、「品質ルールプロパティを作成および管理する」をご参照ください。
スケジューリングプロパティ設定
[スケジューリング方法]
設定済みのスケジューリングタスクを選択できます。スケジューリング方法を決定していない場合は、品質ルールを作成してから後でスケジューリングを設定できます。新しいスケジューリングタスクを作成するには、「スケジューリングタスクの作成」をご参照ください。
品質スコア設定
[スコアリング方法]
サービスは、品質検証ステータスとデータコンプライアンス率の 2 つのスコアリング方法をサポートします。
[品質検証ステータス]： スコアは、現在のルールに従って正常に実行された最新の検証レコードのステータスに基づきます。検証に合格した場合のスコアは 100、不合格の場合のスコアは 0 です。
[データコンプライアンス率]： 品質スコアは、現在のルールの正常に完了した最新の検証レコードにおける有効なデータの割合です。たとえば、データ形式の有効性が 80% の場合、品質スコアは 80 です。
ルールテンプレートによって、サポートされるスコアリング方法が異なります。[品質検証ステータス] のスコアリング方法は次のとおりです。
一意性ルールのカテゴリにおける、フィールドグループ数および重複フィールド値数の検証。
一貫性ルールのカテゴリには、単一テーブルフィールド統計の一貫性比較、およびクロスソース 2 テーブルフィールド統計の一貫性比較が含まれます。
安定性ルールのカテゴリ。
カスタム SQL ルールのカテゴリにおけるカスタム統計メトリクスの検証。
[品質スコアの重み]
品質ルールの品質スコアの重みは、監視対象オブジェクトの品質スコアを計算するために使用されます。1 から 10 の整数を選択できます。
[OK] をクリックして、ルール設定を完了します。
[SQL プレビュー] をクリックして、現在の設定の SQL を最後に保存された設定と比較します。
説明必要な情報が不完全な場合、SQL のプレビューは使用できません。
左側には、最後に保存した設定の SQL のプレビューが表示されます。設定が保存されていない場合、この部分は空欄になります。右側には、現在の設定の SQL のプレビューが表示されます。
ルール設定リスト
ルール設定ページでは、設定したテーブルルールを表示し、表示、編集、ドライラン、実行、削除などの操作を実行できます。
エリア | 説明 |
① フィルタと検索エリア | 名前でオブジェクトまたはルールを検索します。 ルールタイプ、ルールテンプレート、ルールの強度、ドライランステータス、有効ステータスでフィルタリングします。 説明 品質ルールに検索およびフィルタリング可能なビジネス属性が設定され、有効になっている場合、それらの属性で検索またはフィルタリングできます。 |
② リストエリア | このエリアには、ルール設定リストが表示されます。リストには、オブジェクトタイプ/名前、ルール名/ID、ドライランステータス、有効ステータス、ルールタイプ、ルールテンプレート、ルールの強度、スケジューリングタイプ、および関連ナレッジベースドキュメントの情報が含まれます。[更新] の前にある
|
③ 操作エリア | 次の操作を実行できます： 表示、クローン、編集、ドライラン、実行、スケジューリング設定、ナレッジベースドキュメントの関連付け、品質スコアの設定、削除。
|
④ 一括操作エリア | 次の一括操作を実行できます： ドライラン、実行、スケジューリング設定、有効化、無効化、ビジネス属性の変更、ナレッジベースドキュメントの関連付け、品質スコアの設定、ルールのエクスポート、削除。
|
アイコンをクリックして、ルールリストに表示する列を選択します。
アイコンをクリックして [ドライランログを表示] します。スケジューリングタスクの作成
ルールのスケジューリングタスクを設定する際、既存のタスクを再利用してプロセスを高速化できます。各テーブルには最大 20 のスケジューリングタスクを設定できます。
1 つのルールに対して最大 10 個のスケジューリングタスクを設定できます。
スケジューリング設定が同一の場合、システムは自動的に重複を排除します。
チェック範囲は、各品質チェックのデータ範囲を制御するフィルター条件として機能します。また、品質レポートなどの下流コンポーネントの基本単位としても機能し、最小の表示粒度を定義します。
[Quality Rule Details] ページで、 [Scheduling Configuration] タブをクリックし、 [Create Scheduling Task] をクリックして [Create Scheduling Task] ダイアログボックスを開きます。
[Create Scheduling Task] ダイアログボックスで、パラメータを設定します。
パラメータ
説明
スケジューリング名
スケジューリングタスクのカスタム名を入力します。最大 64 文字です。
スケジューリングタイプ
サポートされているタイプは、 [時間ベースのスケジューリング] と [タスクトリガーのスケジューリング] です。
[時間ベースのスケジューリング]：設定されたスケジュールに基づいて品質チェックを定期的に実行します。このタイプは、データが比較的一定の時間に生成されるシナリオに適しています。
[スケジューリング周期]：品質ルールの実行はコンピューティングリソースを消費します。本番タスクへの影響を避けるため、複数の品質ルールを同時に実行しないことを推奨します。サポートされているスケジューリング周期は、 [Day]、 [Week]、 [Month]、 [Hour]、および [Minute] です。
システムタイムゾーン (つまり、ユーザーセンターのタイムゾーン) がスケジューリングタイムゾーン (つまり、 [Management Center] > [System Settings] > [Basic Settings] で設定されたタイムゾーン) と異なる場合、ルールはシステムタイムゾーンに基づいて実行されます。
[タスクトリガーのスケジューリング]：指定されたタスクが正常に実行された後、または実行される前に、設定された品質ルールを実行します。次のノードタイプのタスクに基づいて品質ルールをトリガーできます：SQL、オフラインパイプライン、Python、Shell、Virtual、Dlink、Spark_jar、Hive_MR、およびデータベース 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 (コンピューティングエンジン)、Transwarp TDH 6.x、および Transwarp TDH 9.3.x です。
[トリガー時間]：品質チェックがトリガーされるタイミングを選択します。 [Trigger after all tasks succeed]、 [Trigger after each task succeeds]、または [Trigger before each task runs] を選択できます。
[トリガータスク]：本番プロジェクトからタスクノードを選択して品質ルールをトリガーします。タスクをノードの出力名で検索することもできます。トリガータスクは、次のロールを持つユーザーが選択できます：
Prod/Basic プロジェクトのプロジェクト管理者、Prod プロジェクトの Ops システムロールを持つユーザー、Basic プロジェクトの Developer システムロールを持つユーザー、および Prod/Basic プロジェクトで [Project Quality Management] - [Quality Rule Management] 権限を持つカスタムプロジェクトロールを持つユーザーは、本番プロジェクトからタスクノードを選択できます。
Prod/Basic プロジェクトで [Quality Rule] - [Management] 権限を持つカスタムグローバルロールを持つユーザーは、すべての本番プロジェクトからタスクノードを選択できます。
説明ルールの実行と結果生成の遅延を防ぐため、 [Trigger after all tasks succeed] オプションを使用する場合は、すべてのトリガータスクで同じスケジューリング周期を使用することを推奨します。
[スケジューリング条件]
デフォルトでは無効です。有効にすると、システムはタスクを実行する前にスケジューリング条件が満たされていることを確認します。条件が満たされていない場合、スケジュールされた実行はスキップされます。
[業務日]/[実行日]： [時間ベースのスケジューリング] と [タスクトリガーのスケジューリング] の両方に日付条件を設定できます。 [時間ベースのスケジューリング] は 実行日 条件をサポートしていない点にご注意ください。 [一般カレンダー] または [カスタムカレンダー] を使用できます。カスタムカレンダーの作成方法については、「Create a public calendar」をご参照ください。
[一般カレンダー] を選択した場合、 [月]、 [曜日]、または [日付] に基づいて条件を設定できます。例：
[カスタムカレンダー] を選択した場合、 [日付タイプ] または [タグ] に基づいて条件を設定できます。例：
[インスタンスタイプ]： スケジューリングタイプ が [タスクトリガーのスケジューリング] の場合、インスタンスタイプを設定できます。オプションは [定期インスタンス]、 [バックフィルインスタンス]、および [手動インスタンス] です。例：
説明少なくとも 1 つの条件を設定する必要があります。条件を追加するには、 [+ Add Condition] ボタンをクリックします。
最大 10 個のスケジューリング条件を設定できます。
スケジューリング条件間の関係を and または or に設定できます。
[チェック範囲式]
このパラメータは編集可能なドロップダウンリストです。チェック範囲を直接入力できます (例：
ds='${yyyyMMdd}')。組み込みのパーティション式を選択して変更し、設定を高速化することもできます。パーティション式の詳細については、「Built-in partition expression types」をご参照ください。説明検証に複数の条件がある場合は、 and または or を使用してそれらを連結できます (例：
province="Zhejiang" and ds<=${yyyyMMdd})。品質ルールにフィルター条件が設定されている場合、そのフィルター条件は and 演算子を使用してチェック範囲式と結合されます。チェック中、両方の条件がデータをフィルタリングするために適用されます。
チェック範囲式はフルテーブルスキャンをサポートしています。
注：フルテーブルスキャンは大量のリソースを消費し、一部のシナリオではサポートされていません。フルテーブルスキャンを避けるため、パーティション式を設定することを推奨します。
[チェック日]
デフォルト値は現在の業務日です。
[OK] をクリックして、スケジューリング設定を完了します。
スケジューリング設定リスト
スケジューリングタスクが作成されると、スケジューリング設定リストで表示、編集、クローン、または削除できます。
エリア | 説明 |
① フィルターと検索エリア | スケジューリング名で検索できます。 [時間ベースのスケジューリング] または [タスクトリガーのスケジューリング] でフィルタリングできます。 |
② リストエリア | このエリアには、各スケジューリングタスクの [Scheduling Name]、 [Scheduling Type]、 [Last Modified By]、および [Last Modified Time] が表示されます。 |
③ アクションエリア | スケジューリングタスクを編集、クローン、または削除できます。
|
アラート設定
品質ルールごとに異なる通知チャネルを設定することで、アラートを区別できます。たとえば、強ルールの例外には電話アラートを設定し、弱ルールの例外には SMS アラートを設定できます。1 つのルールが複数のアラート設定をトリガーする場合、どの設定を有効にするかを決定するポリシーを定義できます。
監視対象ごとに最大 20 個のアラート設定を作成できます。
[Quality rule details] ページで、[Alert configuration] タブをクリックし、次に [New alert configuration] をクリックして [New alert configuration] ダイアログボックスを開きます。
[New alert configuration] ダイアログボックスで、パラメータを設定します。
パラメータ
説明
[スコープ]
この設定が適用されるルールを指定します。[All rules]、[All strong rules]、[All weak rules]、または [Custom] を選択できます。
説明1 つの監視対象オブジェクトに対して、「すべてのルール」、「すべての強力なルール」、「すべての弱いルール」の 3 つのスコープごとに 1 つのアラートを設定できます。新しいルールは、ルールの強度に基づいて、対応するアラートに自動的に照合されます。これらのアラート設定のいずれかを変更する必要がある場合は、既存の設定を変更できます。
カスタムスコープの場合、現在の監視対象に設定されている最大 200 個のルールを選択できます。
[アラート設定名]
アラート設定名は監視対象ごとに一意である必要があり、256 文字を超えることはできません。
[アラート受信者]
アラート受信者と通知チャネルを設定します。少なくとも 1 つのアラート受信者と 1 つの通知チャネルを選択する必要があります。
[アラート受信者]：カスタム、オンコールスケジュール、品質オーナーの 3 種類のアラート受信者から選択できます。
最大 5 人のカスタムアラート受信者と最大 3 つのオンコールスケジュールを設定できます。
[通知チャネル]：サポートされているチャネルには、電話、メール、SMS、DingTalk、Lark、WeCom、およびカスタムチャネルが含まれます。これらのチャネルは [Configure Channel Settings] で管理できます。
[OK] をクリックしてアラート設定を保存します。
アラート設定リスト
アラート設定を作成した後、リストで並べ替え、編集、または削除できます。
エリア | 説明 |
① 並べ替えエリア | 品質ルールが複数の設定に一致した場合、どのアラート設定を有効にするかを決定するポリシーを設定します：
|
② リストエリア | 各アラート設定の名前、スコープ、特定の受信者、およびそれに対応する通知チャネルを表示します。 [スコープ]：カスタムアラート設定の場合、設定された監視対象と品質ルールの名前を表示できます。ルールが削除されると、その名前は表示されなくなります。この場合、アラート設定を更新することを推奨します。
|
③ 操作エリア | このエリアでは、アラート設定を編集または削除できます。
|
アイコンをドラッグして順序を変更します。[Actions] 列の [Move to Top] および [Move to Bottom] アイコンを使用して順序を変更することもできます。順序を変更した後、[Done sorting] をクリックして変更を保存します。
例外アーカイブテーブルの追加
例外アーカイブテーブルは、品質ルールのチェックに失敗したレコードを保存します。
[品質ルールの詳細] ページの [例外アーカイブ] タブで、[+ 例外アーカイブテーブルの追加] をクリックします。[例外アーカイブテーブルの追加] ダイアログボックスが表示されます。
[例外アーカイブテーブルの追加] ダイアログボックスで、パラメーターを設定します。
[方法] で、[新しいテーブルの作成] または [既存のテーブルの選択] を選択します。例外アーカイブテーブルには特別な品質チェック列が含まれているため、例外データは元のデータテーブルに書き込まれません。
[新規テーブルの作成]：テーブルにカスタム名を入力できます。デフォルト名は current_table_name_exception_data です。テーブルを追加すると、同じデータベースまたはデータソースに新しいテーブルが作成されます。名前には、英字、数字、アンダースコア (_)、ピリオド (.) を使用でき、128 文字を超えることはできません。
監視対象が物理テーブルの場合、システムは監視対象テーブルのプロジェクトにアーカイブテーブルを作成します。
監視対象テーブルがディメンション論理テーブルまたはファクト論理テーブルの場合、システムはデフォルトで同じプロジェクトにアーカイブテーブルを作成します。また、同じワークスペース内のプロジェクトを
projectA.table_nameのように手動で指定することもできます。監視対象がサマリー論理テーブルの場合、テーブル名にプロジェクトを指定してください。指定しない場合、システムは同じワークスペース内のいずれかのプロジェクトにアーカイブテーブルを自動的に作成します。
アーカイブテーブルには、監視対象テーブルのすべての列と必要な検証列を含める必要があります。スクリプト形式は次のとおりです：
create table current_table_name_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_timestmap timestamp comment 'データ型: TIMESTAMP (小文字で記述)', col_timestmap_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 (小文字で記述)', col_array_02 array<string> comment '21', col_map map<string,string> comment 'データ型: MAP (小文字で記述)', col_map_02 map<string,int> comment '22', ds string comment '日付パーティション (yyyyMMdd)' ) partitioned by (dataphin_quality_validate_date string comment '検証日 (パーティション列)');
[既存のテーブルを選択]: 同じプロジェクトまたはデータソースからテーブルを選択できます。アーカイブテーブルには、監視対象テーブルのすべての列と、必要な検証列を含める必要があります。[例外アーカイブテーブルの DDL を表示] をクリックすると、必要な DDL ステートメントを確認できます。スクリプト形式は次のとおりです。
create table current_table_name_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_timestmap timestamp comment 'データ型: TIMESTAMP (小文字で記述)', col_timestmap_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 (小文字で記述)', col_array_02 array<string> comment '21', col_map map<string,string> comment 'データ型: MAP (小文字で記述)', col_map_02 map<string,int> comment '22', ds string comment '日付パーティション (yyyyMMdd)' ) partitioned by (dataphin_quality_validate_date string comment '検証日 (パーティション列)');
[ライフサイクル]: この設定は、コンピューティングエンジンとして MaxCompute を使用するテーブルでのみ利用可能です。 新しいテーブルを作成する場合、カスタムの日数を入力するか、プリセットから [7 日]、[14 日]、[30 日]、または [360 日] を選択できます。 既存のテーブルを選択した場合、設定されているライフサイクルが表示されます。
[最大アーカイブ数]: この設定は、コンピューティングエンジンとして MaxCompute または Hadoop シリーズを使用するテーブルでのみ利用可能です。この設定は、1 回の品質ルール実行からアーカイブする例外レコードの最大数を指定します。例外数がこのしきい値を超えた場合、システムは指定された数のレコードのみをアーカイブします。超過したレコードはアーカイブテーブルに保存されませんが、ログで表示できます。デフォルトは、チェックあたり 10,000 レコードです。[10,000]、[100,000]、[500,000]、または [すべて] を選択するか、任意の正の整数を入力できます。
説明アーカイブテーブルのデータ量が大きいと、クエリのパフォーマンスに影響を与える可能性があります。ビジネスニーズに基づいてこの設定をしてください。
[OK] をクリックして例外アーカイブテーブルを追加します。
[作成後にアクティブなアーカイブテーブルとして設定] を選択できます。これにより、後で品質ルールを作成する際に、このテーブルが自動的にアーカイブ先として設定されます。
例外アーカイブテーブルリスト
テーブルを追加すると、リストの最初のテーブルがデフォルトでアクティブなアーカイブテーブルとして設定されます。例外アーカイブテーブルの名前をクリックして、そのテーブル構造を表示できます。他のテーブルをアクティブなアーカイブテーブルとして設定したり、削除したり、設定を編集したりすることもできます。
[アクティブアーカイブテーブルとして設定]: テーブルをアクティブとして設定すると、監視対象オブジェクトに対してカスタム例外テーブルを使用するように設定されたすべての品質ルールからの例外データの保存先になります。
[削除]: この操作では、例外アーカイブテーブルへの参照のみが削除されます。物理テーブルは削除されません。
[編集]: このオプションは、コンピューティングエンジンとして MaxCompute または Hadoop シリーズを使用するテーブルでのみ使用できます。ライフサイクルと最大アーカイブ数を変更できます。
品質レポート
[品質レポート] をクリックすると、現在の品質ルールの [ルールチェック概要] と [ルールチェック詳細] が表示されます。
異常な結果、パーティション時間、またはルール名やオブジェクト名のキーワードによって、ルールチェック詳細を素早くフィルターすることができます。
[操作] 列の
アイコンをクリックすると、ルールチェック詳細が表示されます。[操作] 列の
アイコンをクリックすると、実行ログが表示されます。
品質ルールの権限管理
[権限管理] をクリックして、どのメンバーが検証レコードの詳細、クオリティルールの詳細、およびクオリティレポートを表示できるかを決定する [詳細表示権限] を設定します。
[詳細表示権限]：[すべてのメンバー] または [現在のオブジェクトの品質管理権限を持つメンバーのみ] を選択します。
[OK] をクリックして権限設定を保存します。
品質ルールの実行設定
品質ルール タスクがタイムアウトした場合、実行ステータスは失敗に設定されます。対応する実行ログは、検証レコードの詳細ページで確認できます。
品質ルール タスクがリトライされた場合、検証レコードの詳細ページで各試行の実行ログを確認できます。
1 つの監視対象では、すべての品質ルール (新規作成されたルールや未実行のルールを含む) が、次回の実行で最新の実行設定を使用します。
[Run Configuration] タブをクリックし、ページ下部の [Edit] をクリックしてパラメーターを設定します。
パラメーター
説明
[範囲]
[All Rules]、[All Strong Rules]、[All Weak Rules]、または [Custom] を選択できます。
[実行タイムアウト]
品質ルール タスクの合計実行時間 (開始から終了まで。リソース待機およびスケジューリング待機を除く) が設定したしきい値を超えると、システムはタスクを自動的に終了し、ステータスを「失敗」に設定します。デフォルトは 1 時間です。0 ～ 2 時間の範囲で、小数点第2位までのカスタム時間を設定できます。
[自動リトライ]
失敗した品質ルール タスクに対して、[リトライ回数] と [リトライ間隔] に基づいて自動リトライを設定できます。この機能はデフォルトで無効です。有効にすると、リトライ回数と間隔を設定できます。
[リトライ回数]：失敗した品質ルール タスクの自動リトライの最大回数です。デフォルトは 1 です。1 ～ 3 の整数を設定できます。
[リトライ間隔]：自動リトライの試行間隔 (分) です。デフォルトは 0 です。0 ～ 10 の整数を設定できます。
[OK] をクリックして、実行設定を保存します。
次のステップ
品質ルールを設定後、グローバルデータテーブルのルールリストページでルールを確認できます。詳細については、「モニタリングオブジェクトリストの表示」または「」をご参照ください。