推奨されるヘルスチェック

このドキュメントでは、パイプラインの健全性を監視するためのヘルスチェック設定のベストプラクティスを紹介します。これらのガイドラインに従うことで、データが取り込まれ、ビルドされ、出力されることを確認するための、堅牢で効果的な監視を実現できるはずです。

これらのベストプラクティスでは、データセット内のコンテンツの品質、正確性、妥当性の確保については扱いません。これらを確保するには、パイプライン内で実施する適切な検証を判断できるよう、パイプラインについてより詳細で機能面に踏み込んだ知識が必要です。

また、これらのガイドラインは、ヘルスチェックの設定でよくある次のような落とし穴を避けるのにも役立つはずです。

• チェックが多すぎて、チェックの件数によるノイズが生じる
• チェックの種類が適切でなく、役に立たないアラートが発生する
• チェックが少なすぎて、問題が発生したときに兆候を捉えられない

前提知識

これらのガイドラインは、次の項目を理解していることを前提としています。

• Data Health
• スケジュール
  • スケジュールが監視の単位になります。つまり、これらのガイドラインでは、スケジュールの実行時に何が起こるかに基づいて、どこにどのチェックを設定するかを推奨します。
• Data Lineage

監視に関する重要な概念

監視の単位：解決済みスケジュール

解決済みスケジュールは、スケジュールに関わるさまざまなデータセットにロールを割り当てるための概念モデルです。スケジュールによってビルドできるために関わるデータセットもあります。つまり、これらはスケジュールのデータセット選択に含まれます。また、ビルドに必要な入力として関わるデータセットもあります。データセットのロールに応じて、異なるヘルスチェックが推奨されます。

このドキュメントでスケジュールの入力、中間、出力に言及する場合は、解決済みスケジュールを指します。これは、Data Lineage アプリケーションでのスケジュール設定とは異なります。

データセットは、スケジュール内で次のいずれかのロールを持ちます。

• 出力： スケジュールの最終ステップとなるデータセットです。スケジュールによってビルドされますが、スケジュール内のほかのデータセットでは使用されません
• 中間： スケジュールによってビルドされるデータセットのうち、スケジュールの出力ではないすべてのデータセットです。
• 入力： スケジュールによってビルドされませんが、スケジュールで使用されるデータセットです。入力は、スケジュールの外部で読み取りが行われる最初の層を構成します。たとえば、Data Connection の同期や、ご自身でビルドしない派生データセットなどです。

具体例として、スケジュールが次のデータセットをビルドする場合を考えます。

この場合、スケジュールを次のように分けることができます。

実際にビルドされるものを理解する

スケジュールの入力、出力、中間が何かを判断するには、Data Lineage でスケジュールを開くのが最も簡単です。Data Lineage でサイドバーからスケジュールを選択すると、スケジュールの色分けが適用され、スケジュールが何をビルドしようとするかを把握しやすくなります。

• ターゲット： ビルドが試行され、通常はスケジュールによってビルドされます。例外として、Data Connection で同期されるデータセットは、スケジュールで「強制ビルド」が設定されている場合にのみビルドされます。
• 除外： スケジュールによってビルドされることはありません。
• 入力（接続ビルドのみ）： 上流に別の入力がある場合を除き、スケジュールによってビルドされません。

データの古さについて少し補足します。実際には、すでに最新のデータセットもあり、それらを再計算するとリソースの無駄になるため、スケジュールがこのグラフ内のすべてをビルドすることはほとんどありません。ただし、スケジュールを解決するとは、スケジュールが処理しうるすべてのものを特定することだと理解しておくことが重要です。

対象と出力の違い

スケジュールは対象を指定して定義され、通常、対象は出力と同じです。ただし、対象と出力が異なる場合もあります。

1. データセットは、対象として明示的に定義されていなくても出力になることがあります。

output_c をビルドするスケジュールは、常に output_d もビルドする必要があります。これは、B、C、D の間のトランスフォームが、複数の出力を持つトランスフォームであるためです。

したがって、output_c を対象とするスケジュールでは、output_c と output_d の両方が出力になります。これは、output_d がスケジュールによってビルドされるデータセットであり、スケジュール内のほかのデータセットでは使用されないためです。

2. データセットは、「対象」として定義されていても「出力」ではないことがあります。

データセットがスケジュールの「対象」として定義されていても、スケジュール内のほかのデータセットで使用される場合は、「出力」データセットではなく「中間」データセットと見なされます。

この例では、dataset_c はスケジュールの「対象」ですが、「出力」とは見なされません。

スケジュールのどこにヘルスチェックを設定すべきですか？

以下のステップバイステップガイドは、ジョブステータスチェックとスケジュールステータスチェックの違い、およびデータ鮮度チェックと最終更新からの経過時間チェックの違いを理解していることを前提としています。これらのチェックの違いがわからない場合は、ヘルスチェックの種類を参照してください。

スケジュールに対するチェック

1. スケジュールステータスチェック： パイプライン内のすべての失敗を検出します。各データセットにジョブステータスチェックを設定する必要はありません。
2. スケジュール実行時間チェック： 競合の可能性や、パイプラインをブロックしているビルドを検出するのに役立ちます。このチェックは、次の原因による問題の検出にも役立ちます。
   • 異常な入力。たとえば、入力のキーの分布が変わると、結合に時間がかかることがあります。失敗するジョブで、あるステージのタスクが1個を除いてすべて完了している場合、結合の偏りを強く示しています。
   • コード変更によるパフォーマンスの低下。

入力に対するチェック

パイプラインのすべての解決済み入力にチェックを設定してください。パイプラインが失敗した場合、根本原因を突き止められることが重要です。入力の鮮度低下やスキーマの破壊的変更は発生するものです。入力にチェックを設定すると、これらを検出しやすくなります。注：現時点では、特定のデータセットに設定できる同じ種類のチェックは1個だけです。設定しようとしたチェックがすでに存在する場合は、そのチェックをフォローするだけで構いません。

1. スキーマチェック： 列が追加または削除された場合や、パイプラインが依存する列名やデータ型が予期せず変更された場合に警告します。
2. 最終更新からの経過時間（TSLU）［任意］： パイプラインの入力にデータが予定どおりに届いていることを確認できます。パイプラインが予定どおりにビルドされない場合の根本原因分析に役立ちます。これは任意のチェックであり、想定される更新頻度を正確に把握している場合にのみ設定してください。
   • 入力データセットを上流の所有者がすでに監視している場合も、このチェックの適用は避けてください（上流データセットにチェックを追加する権限自体がない可能性もあります）。
   • 「空のトランザクションを無視」を有効にすることを推奨します。
3. ジョブまたはスケジュールのステータス： 任意ですが、Data Connection の同期や、所有者が明確に定義されていないデータセットには推奨されます。スケジュールは一緒にビルドされるパイプラインの単位を表すため、スケジュールステータスを推奨します。入力データセットのビルドが上流データセットで失敗し、キャンセルまたは中止されて個別のジョブが実行されなかった場合にもアラートを受け取れるため、ジョブステータスよりもスケジュールステータスの使用を推奨します。

出力に対するチェック

パイプラインのすべての解決済み出力にチェックを設定してください（これらはスケジュールによってビルドされますが、同じスケジュール内のほかのデータセットでは使用されないことを思い出してください）。

1. 最終更新からの経過時間チェック（TSLU）： このチェックを使用して、パイプラインが必要な頻度で更新されていることを確認します。
   • 例：パイプラインが24時間ごとに実行される想定の場合（たとえば、毎日午前9時に実行され、ビルドの平均所要時間が1時間）、次のいずれかを設定できます。
     • 「最終更新からの経過時間」のしきい値を26時間に設定し（ビルド時間を考慮し、多少の余裕を持たせるため）、チェックが自動的に更新されるようにします。
     • しきい値を2時間に設定し、チェックをスケジュールに従って実行します。この例では毎日午前11時です。ヒント：「自動的に解決」フラグをオンにしてください。そうしないと、ビルドの完了が少し遅れただけでも、パイプラインは丸24時間にわたって異常とみなされます。
     • 出力データセットにスケジュールステータス、スケジュール実行時間、TSLU のチェックを設定すると、スケジュールステータスやスケジュール実行時間に何らかの問題があることを早期に警告できます。最終的に TSLU のアラートが発生した場合は、何らかの問題がある可能性が高く、誰かが調査する必要があります。
2. スキーマチェック： パイプラインの出力が Contour、Slate、Object Explorer などのほかのアプリケーションでユーザーに利用される場合は、このチェックを使用します。出力スキーマに破壊的変更が発生すると警告するため、必要に応じて対応し、下流のアプリケーションを更新したり、ユーザーに知らせたりできます。

任意のチェック

必要に応じて、別のアプリケーションでユーザーが直接または同期を通じて利用する重要な中間データセットにチェックを設定します。

1. スキーマチェック： 出力と同様に、ユーザーがアプリケーションでデータセットを利用している場合（Contour であっても、同期を通じた利用であっても）、スキーマの変更によって不具合が生じたり、手動での追加対応が必要になったりすることがあります。
2. データ鮮度： データセットの内容が鮮度の要件を満たしていることを確認するために使用します（ソースシステムでデータセットに行が追加された時点を示す、適切なタイムスタンプ列がある場合）。
3. 最終更新からの経過時間チェック： パイプラインの中間に重要なデータセット（たとえば、ほかの多くのユーザーが使用するデータセット）がある場合、上流の遅延などによって予定どおりに更新されないことがあります。パイプラインの入力チェックで検出できることが望ましいですが、TSLU チェックの追加も役立ちます。
4. 同期がある場合：
   • 同期ステータスチェック： 同期されるデータセットに設定してください（Slate のような Foundry アプリケーションへの同期でも、外部システムへの同期でも）。
   • 同期鮮度チェック： データ鮮度および TSLU と併せて評価すると特に役立ちます。問題が a) データセットが予定どおりに更新されなかった、b) データセットは更新されたものの、ソースシステムが新しいデータを提供しなかった、c) データセットには新しいデータがあるものの、同期が更新されていない、のいずれであるかをすばやく特定できます。

概要テーブル

上記で説明したベストプラクティスを、すぐに参照できるように次のテーブルにまとめています。

[*] 入力、中間、出力のいずれのデータセットでも該当する場合があります。ユーザー向けデータセットとは、Contour などのアプリでユーザーが直接利用するデータセットです。