Lakeflow pipelines の本番運用対応
本番運用対応とは、パイプラインが実際のビジネスデータに対して無人で実行できる状態を指します。このページでは、パイプラインを信頼して運用する前に、その状態にあることを確認するためのチェックリストを提供します。
概要
本番運用可能なパイプラインは、スケジュールに基づいて実際のビジネスデータに対して実行され、ダウンストリームのコンシューマーによって報告されるのではなく、障害が自動的にキャッチされます。準備状況とは、データ品質、信頼性、観測可能性、デプロイメント、コスト、ガバナンスにわたるチェックリストのことです。
Lakeflow pipelinesは、これらの次元に直接マッピングするいくつかの組み込みプリミティブを提供します。準備ができているかどうかを直感で判断しようとするのではなく、以下のチェックリストを順に確認し、チェックが入っていない項目は既知の不足事項として捉えてください。ほとんどの条件が満たされていれば、パイプラインは本番運用での稼働準備が整っています。チェックが入っていない項目が複数ある場合は、それらを優先順位の高いタスクリストとして扱ってください。まずはデータ品質と通知から始めましょう。これらは追加コストが最も安く、検出されずに不良のランを検出しやすいものです。
チェックリスト
本番運用対応の各側面について以下のチェックリストを確認し、チェックが入っていない項目は、パイプラインを運用する前に解消すべき既知のギャップとして扱ってください。
データ品質
- 不正なデータを受け取る可能性のあるすべてのデータセットには、「クリーンな入力を想定する」というドキュメント文字列のコメントだけでなく、少なくとも1つのエクスペクテーション（
expect、expect_or_drop、またはexpect_or_fail）が定義されています。 - 制約ごとに
warn、drop、failを意図的に選択しました。failは（壊れた主キーなど）処理を停止すべき条件用、dropは（ドロップされたものをキャプチャする検疫テーブルを使用して）安全に破棄できるレコード用、warnは傾向を積極的に監視する場合のみに使用します。 - パイプラインUIの データ品質 tabを確認したか、イベントログを少なくとも1回クエリしたことで、エクスペクテーションが存在することだけでなく、現在のエクスペクテーションの合格率を把握できるようになりました。「パイプラインのエクスペクテーションを使用してデータ品質を管理する」を参照してください。
信頼性
- Trigger モードと 連続 パイプラインモードのどちらかを意識的に選んでいます。トリガーはほとんどのパイプラインで正しいdefaultです。常時稼働のクラスターが必要となるため、1分未満のレイテンシが真に必要とされる場合にのみ、継続的な処理を優先してください。See Triggered vs. continuous Triggerモードと連続パイプラインモードの比較を参照してください。
- パイプラインは、誰かが忘れずに 起動 を選択するのではなく、ジョブスケジューラまたはLakeflow Jobを通じてスケジュールされます。「ワークフローでのパイプラインの実行」を参照してください。
- 失敗通知はEメール、Webhook、またはイベントフック用に構成されているため、関係者が気づく前にランの失敗を知ることができます。
- ストリーミングソースについては、チェックポイントの失敗時に何が起こるかをテスト済みであり、インシデント発生時に初めて知るのではなく、回復手順を把握している状態にします。ストリーミングチェックポイントの失敗からパイプラインを回復するを参照してください。
- パイプラインは個人のユーザーIDではなく Service Principal として実行されるため、無人自動化においてより安全で安定した実行が可能になります。
可観測性
- イベント log の場所を把握しており、リネージ、データ品質メトリクス、またはリソース使用量について、それに対して少なくとも 1 回クエリーを実行したことがある。イベントlogはパイプラインの主要な可観測性プリミティブであり、パイプライン UI はそのビューです。「パイプラインの監視」を参照してください。
-
system.lakeflow.pipelinesと関連するシステムテーブルを確認したか、小さなダッシュボードを作成したことで、パイプラインの健全性をUIでの目視だけでなく、クエリで確認できるようになりました。 - 現在の更新期間を把握し、更新ごとに期間が長くなっているか、安定しているかを確認できます。
デプロイメントと変更管理
- パイプラインは UI で手動作成されるのではなく、バンドルを通じて定義およびデプロイされるため、コードレビューとバージョン管理が可能です。「ソース管理されたパイプラインを作成する」を参照してください。
- 少なくとも
devとprodのターゲット（理想的にはdev、staging、prod）があり、実際のデータに反映される前にどこかで変更が検証されるようになっています。 - 環境固有の値（カタログ名、スケジュール、ソースパス）はハードコーディングではなくパイプライン構成を通じてパラメーター化されるため、同じコードをターゲット間でクリーンに昇格させることができます。
コンピュートとコスト
- Serverless コンピュートとクラシック コンピュートのどちらかを明示的に選択し（新しいパイプラインには Serverless が default の推奨事項です）、クラシックを選択した場合はその理由を文書化しました。「Serverless パイプラインの構成」を参照してください。
- クラシックコンピュートを使用している場合、固定クラスターサイズではなく強化オートスケールが有効になるため、負荷がかかってもパイプラインでワーカーが不足して停止することはありません。
- このパイプラインの Databricks ユニット（DBU）消費量について
system.billing.usageを少なくとも 1 回確認しており、驚くような数値ではありません。
ガバナンス
- ターゲットテーブルは、レガシーな Hive metastore ではなく、意図的なカタログおよびスキーマのLayout（環境ごとに個別のカタログやスキーマを分けるなど）を持つ Unity Catalog 内に配置されます。
- ソースオブジェクトおよびターゲットオブジェクトへのアクセスは最小特権の原則に従います。つまり、パイプラインのService Principalは必要なもののみを読み書きでき、それ以外の権限は持ちません。「パイプラインの ID、アクセス許可、および特権の管理」を参照してください。