注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
learn.palantir.comでも以下の内容をご覧いただけますが、アクセシビリティの観点から、ここに掲載しています。
Data Health のチェックは、ビルドが完了した後に、チェックのタイプに応じたさまざまなバックエンドプロセスを使用して実行されます。これらは、ビルドまたはジョブの完了後に変換コードとは別に実行されるため、ビルドを失敗させるためには使用できません。言い換えれば、主キーの一意性ヘルスチェックをインストールしても、失敗についての通知を受け取るだけで、望ましくないデータが下流に続く可能性があります。
対照的に、Foundry の Data Expectations ライブラリは、変換内で呼び出すことができ、(a) 満たされない場合にジョブが失敗するヘルスチェックを作成し、(b) 箱から出してすぐに使用できるデータヘルスチェックよりも細かい粒度を提供し、(c) リポジトリ内の設定管理の下にあり、(d) データの予想される形状とサイズについてのコード内のドキュメントのレイヤーを追加します。したがって、エンコードされた主キーデータ期待が失敗すると、ジョブが失敗し、予期しないデータは下流に伝播されません。さらに、エンコードされた期待は、Data Health アプリで設定した標準的なものと並んで表示されます。
多くの場合、前のチュートリアルで適用したデータヘルスチェックは、パイプラインの監視に十分です。完全な監視と保護プログラムは、より大きな粒度と制御のために Data Expectations フレームワークを活用すべきです。この短いチュートリアルでは、データ変換のいくつかにエンコードされたデータチェックを追加し、Data Health アプリケーションでそれらを表示します。
データ期待チェックをいつどのように適用するかを理解する。