チェックの種類

このページでは、Data Health で利用可能な各種チェック、つまりジョブレベルのチェック、ビルドレベルのチェック、新鮮度チェックについて概説します。

ジョブレベルチェック対ビルドレベルチェック

ジョブステータス、ビルドステータス & ビルド期間 の理解

以下の定義は、Foundry におけるジョブとビルドの内容を明確にします：

ジョブ: 単一の変換のロジックによって定義された Spark の計算です。言い換えると、ジョブは単一のデータセット（または複数出力の変換が使用された場合は複数）を生成する単一の変換です。ジョブは一連のステージに分割されます。
ビルド: ターゲットデータセットが定義されたジョブの集合（スケジュールで定義されたもの、またはメインのビルドアプリケーションページに表示されるデータセットから見ることができます）。

ジョブとビルドが正常に実行されていることを確認するために、以下の Data Health チェックを使用します：

ジョブステータス: これは、インストールされているデータセットが再読み込みされたり、任意のビルドの一部として作成されたりするたびにトリガーされます。ターゲットデータセットが正常にビルドされれば、ジョブステータスチェックは成功します。ただし、ビルドが下流で失敗しても成功します。ただし、ビルドがターゲットデータセットの上流で失敗すると、ターゲットデータセットは「キャンセルされた」ビルドとして登録され、ジョブステータスはターゲットデータセットの評価対象になりません。
ビルド期間 & ビルドステータス: これらはビルド（すべての中間データを含む）のステータスを監視するのに役立ちます。ただし、これらは出力（ビルドのターゲットデータセット）にインストールされたときにのみトリガーされます。
- これらは出力にのみインストールするべきです。スケジュールの中間でこれらのチェックをインストールすることは意味がありません。スケジュールがビルドされたときにはトリガーされません。
- 一般的に、すべてのスケジュールは出力にビルドステータスをインストールすることが推奨されます。ビルドステータスがある場合、同じスケジュールによってビルドされる他のデータセットにジョブステータスチェックをインストールする必要も推奨もありません。なぜなら、すべてのジョブの失敗がビルドステータスチェックをオフにするからです。

ジョブステータスチェックまたはビルドステータスチェックをいつどこに配置するかを判断しようとするときは、適用するヘルスチェックの選択に関するガイドを参照してください。

チェック自体についての詳細と更なる説明については、ビルドステータスとジョブステータスのチェックリファレンスを参照してください。

新鮮度チェック

同期新鮮度、データ新鮮度 & 最終更新からの経過時間 の理解

これら3つのチェックはすべて「新鮮度」（つまり、データのある側面がどれだけ最新であるか）に関心がありますが、新鮮度を評価する方法はそれぞれ異なります：

最終更新からの経過時間: これはデータセットの新鮮度を評価します。現在の時間と最後にコミットされたトランザクションの間に経過した時間を計算します（トランザクションが空でも構いません。空のトランザクションはデータセットのデータを変更しません）。
データ新鮮度: これはデータセットのデータの新鮮度を評価します。最後にコミットされたトランザクションとタイムスタンプ行の最大値との間に経過した時間を計算します。このチェックはトランザクションがコミットされたときにのみ実行されます。
同期新鮮度: これは同期されたデータセットのデータの新鮮度（例：Phonograph テーブル）を評価します。データセットの最新の同期時間と日時行の最大値との間に経過した時間を計算します。

データ新鮮度と同期新鮮度の両方について、行がソースシステムに追加されたときのタイムスタンプが列に表示されることが理想的です。

新鮮度チェックをいつどこに配置するかを判断しようとするときは、適用するヘルスチェックの選択に関するガイドを参照してください。

チェック自体についての詳細については、最終更新からの経過時間、データ新鮮度、および同期新鮮度のチェックリファレンスを参照してください。

ヘルスチェックが失敗したときにビルドを中止できますか？

ほとんどの標準的なヘルスチェックは、ジョブが完了するのを待ってから計算を行う依存性があります。データセットがコードリポジトリで作成された場合、ビルド時に実行するチェックを定義するために Data Expectations を使用できます。これにより、エラー時にビルドを中止して、Data Health を使用してチェックを監視することができます。