ドキュメントの検索
karat

+

K

APIリファレンス ↗
データ統合パイプラインのメンテナンスデータ期待値の定義
Feedback

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

データ期待値の定義

データ期待値は、データセットの入力や出力に対してコードで定義された一連の要件です。これらの要件、または「期待値」は、データパイプラインの安定性を向上させるチェックを作成するために使用できます。データセットのビルドの一部としてデータ期待値のチェックが失敗すると、時間とリソースを節約し、下流のデータでの問題を避けるために、ビルドを自動的に中止することができます。データ期待値は、監視のために Data Health と統合されています。

Python Transforms のドキュメントにある ガイド を見て始めるか、すべての利用可能な期待値の リファレンス を参照してください。

データ期待値を使用する利点

  • パイプライン保護 - 期待値はビルドの一部として実行されるため、期待値が失敗した場合にビルドを中止し、下流のリソースに伝播する悪いデータと失敗を防ぐことができます。
  • 変更管理 - 期待値はコードリポジトリで定義されているため、それらを変更するには保護されたブランチに設定されている同じプルリクエストレビュープロセスが必要です。
  • 事前テスト - 開発ブランチでそれらをビルドすることにより、保護されたブランチへの変更をマージする前にチェックの失敗を予測します。

用語

  • 期待値 - データ構造や内容に対する強く型付けされた要件(例:行が null ではない)
  • チェック - 意味のある期待値(複数の期待値の複合体であることができる)で、トランスフォームの単一のデータセット(出力または入力)に接続されています。チェックには、それを識別し、監視する際に使用される名前があります(例:「オブジェクトスキーマ検証」)。
    • 事前条件 - トランスフォームの入力に割り当てられたチェックで、通常はビルドを進行する前に入力の構造や内容に対する基本的な仮定を検証するために使用されます。
    • 事後条件 - トランスフォームの出力に割り当てられたチェックで、通常はデータセットの SLA が維持され、下流の依存関係が保護されることを保証するために使用されます。
  • チェック結果 - チェックが実行される(ビルド中)と生成され、期待値の結果とその分解に関する情報を含みます。チェック結果は Data Health で監視することができます。

それはどのように動作するのか?

定義

データ期待値は、関連するコードリポジトリ内のデータセットトランスフォームで定義されます。チェックはトランスフォームの入力と出力に適用できます(詳細については ガイド を参照してください)。チェック名は単一のトランスフォーム内で一意でなければなりません。

チェックは期待値とともに、ビルド時間中に失敗がどのように処理されるかを定義します。チェックが失敗すると、ビルドは警告とともに中止または再開されることができます。

チェックは、関連するブランチの CI 中に登録されます。保護されたブランチでの期待値の変更は、他のコード変更と同様にプルリクエストが必要となります。

保護されたブランチに変更を加えるときは、デフォルトのブランチへの変更をマージする前に、データ期待値が満たされていることを確認するために、開発ブランチでデータセットをビルドすることをお勧めします。

実行

登録されたチェックはビルドジョブの一部として実行されます。データ期待値が満たされないと、ビルドアプリケーションとデータセットの 履歴タブ で強調表示されます。チェックの定義がエラー時に FAIL を示している場合、ジョブのステータスは「中止」に変わり、適切なエラーが表示されます。ジョブタイムラインで「期待値」のインジケータを見つけることができます。インジケータをクリックすると、チェックの結果と異なる期待値の分解が表示されます。

事前条件が失敗すると、トランスフォームの出力(事前条件が定義されていた入力ではなく)が中止されます。入力データセットのビルドを中止するには、データ期待値を入力データセットトランスフォームの 事後条件 として定義する必要があります。

監視

各チェックの実行は、Data Health に報告される 結果 を生成します。最新のデータ期待値の結果は、通知と問題トリガーが設定できるデータセットプレビューアプリケーションの Health タブ で表示されます(他の Data Health チェックと同様)。

データセットのチェックは、その名前によって一意に識別されることを覚えておいてください。チェックの履歴、およびその個々の監視設定は、その名前が変わらない限り維持されます。チェックの名前を変更すると、古いチェックを削除し、その場所に新しいチェックを作成することと同等です。

インクリメンタル

すべてのチェックは、トランスフォームのインクリメンタルな性質に関係なく、完全なデータセットで実行されます。

例えば、インクリメンタルとして実行されるトランスフォームの出力にプライマリキーチェックがあると仮定します。データ期待値のチェックは常に 完全な データセットで実行されるため、新しいトランザクション(書き込みが予定されている)に新しいプライマリキーが含まれていて、同じプライマリキーが既に書き込まれていた場合(以前のトランザクションで)、チェックは失敗します。