メインコンテンツまでスキップ
に最終更新

Lakeflow pipelines の本番運用対応

Production readiness is the point where a pipeline can run unattended against real business data, and this page gives you a checklist to confirm you're there before you rely on it.

Overview​

本番運用可能なパイプラインは、スケジュールに基づいて実際のビジネスデータに対して実行され、ダウンストリームのコンシューマーによって報告されるのではなく、障害が自動的にキャッチされます。準備状況とは、データ品質、信頼性、観測可能性、デプロイメント、コスト、ガバナンスにわたるチェックリストのことです。

Lakeflow pipelinesは、これらの次元に直接マッピングするいくつかの組み込みプリミティブを提供します。準備ができているかどうかを直感で判断しようとするのではなく、以下のチェックリストを順に確認し、チェックが入っていない項目は既知の不足事項として捉えてください。ほとんどの条件が満たされていれば、パイプラインは本番運用での稼働準備が整っています。チェックが入っていない項目が複数ある場合は、それらを優先順位の高いタスクリストとして扱ってください。まずはデータ品質と通知から始めましょう。これらは追加コストが最も安く、検出されずに不良のランを検出しやすいものです。

チェックリスト​

本番運用対応の各側面について以下のチェックリストを確認し、チェックが入っていない項目は、パイプラインを運用する前に解消すべき既知のギャップとして扱ってください。

データ品質​

  • 不正なデータを受け取る可能性のあるすべてのデータセットには、「クリーンな入力を想定する」というドキュメント文字列のコメントだけでなく、少なくとも1つのエクスペクテーション（expect、expect_or_drop、またはexpect_or_fail）が定義されています。
  • You've deliberately chosen warn versus drop versus fail per constraint: fail for conditions that should stop the world (such as a broken primary key), drop for records you can safely discard (with a quarantine table capturing what was dropped), and warn only where you actively watch the trend.
  • パイプラインUIの データ品質 tabを確認したか、イベントログを少なくとも1回クエリしたことで、エクスペクテーションが存在することだけでなく、現在のエクスペクテーションの合格率を把握できるようになりました。「パイプラインのエクスペクテーションを使用してデータ品質を管理する」を参照してください。

Reliability​

  • You've consciously chosen between triggered and continuous pipeline mode. Triggered is the right default for the vast majority of pipelines. Reserve continuous for genuine sub-minute latency needs, since it requires an always-on cluster. See Triggered vs. continuous pipeline mode.
  • The pipeline is scheduled through the job scheduler or a Lakeflow Job rather than someone remembering to select Start . See Run pipelines in a workflow.
  • 失敗通知はEメール、Webhook、またはイベントフック用に構成されているため、関係者が気づく前にランの失敗を知ることができます。
  • ストリーミングソースについては、チェックポイントの失敗時に何が起こるかをテスト済みであり、インシデント発生時に初めて知るのではなく、回復手順を把握している状態にします。ストリーミングチェックポイントの失敗からパイプラインを回復するを参照してください。
  • パイプラインは個人のユーザーIDではなく Service Principal として実行されるため、無人自動化においてより安全で安定した実行が可能になります。

Observability​

  • イベント log の場所を把握しており、リネージ、データ品質メトリクス、またはリソース使用量について、それに対して少なくとも 1 回クエリーを実行したことがある。イベントlogはパイプラインの主要な可観測性プリミティブであり、パイプライン UI はそのビューです。「パイプラインの監視」を参照してください。
  • system.lakeflow.pipelines と関連するシステムテーブルを確認したか、小さなダッシュボードを作成したことで、パイプラインの健全性をUIでの目視だけでなく、クエリで確認できるようになりました。
  • 現在の更新期間を把握し、更新ごとに期間が長くなっているか、安定しているかを確認できます。

Deployment and change management​

  • パイプラインは UI で手動作成されるのではなく、バンドルを通じて定義およびデプロイされるため、コードレビューとバージョン管理が可能です。「ソース管理されたパイプラインを作成する」を参照してください。
  • You have at least a dev and a prod target (ideally dev, staging, and prod) so changes get validated somewhere before they hit real data.
  • 環境固有の値（カタログ名、スケジュール、ソースパス）はハードコーディングではなくパイプライン構成を通じてパラメーター化されるため、同じコードをターゲット間でクリーンに昇格させることができます。

コンピュートとコスト​

  • Serverless コンピュートとクラシック コンピュートのどちらかを明示的に選択し（新しいパイプラインには Serverless が default の推奨事項です）、クラシックを選択した場合はその理由を文書化しました。「Serverless パイプラインの構成」を参照してください。
  • If on classic compute, enhanced autoscaling is enabled rather than a fixed cluster size, so the pipeline doesn't silently starve for workers under load.
  • You've looked at system.billing.usage at least once for this pipeline's Databricks unit (DBU) consumption and it isn't a surprise number.

ガバナンス​

  • Target tables live in Unity Catalog with an intentional catalog and schema layout (for example, separate catalogs or schemas per environment), not the legacy Hive metastore.
  • ソースオブジェクトおよびターゲットオブジェクトへのアクセスは最小特権の原則に従います。つまり、パイプラインのService Principalは必要なもののみを読み書きでき、それ以外の権限は持ちません。「パイプラインの ID、アクセス許可、および特権の管理」を参照してください。

その他のリソース​

このページの見出し