Lakeflow pipelines 全体でデータセットを整理する
LakeFlow Pipelinesを使用して、1つから数百までのデータセットを単一のパイプラインで処理します。ドメイン、周期、依存関係に基づいてどのデータセットをまとめるかを決定し、所有権、レイテンシ、またはスケールが異なる場合は作業を別々のパイプラインに分割します。
概要
チュートリアルでは決して取り上げられないものの、実際のデプロイメントでは重要となる決定事項があります。それは、どのテーブルを同じパイプラインにまとめるべきか、そしていつ別のパイプラインとして分離すべきかという点です。これを誤ることは、チームが自らを追い詰めてしまう最も一般的な原因の1つです。典型的な失敗パターンは、 すべて を1つの巨大なパイプラインに詰め込み、後になってからスケーリング、同時実行性、影響範囲の問題に直面し、その解決に苦労することです。
唯一の正解はありませんが、各方向に作用する明確な力があり、設計前に知っておくべき重要な制約が1つあります。
ガイドライン
ドメイン、共有ケイデンス、依存関係に基づいてデータセットをグループ化し、所有権、レイヤー、レイテンシの境界で分割します。単一のパイプラインにおける独立して更新可能なデータセットの数は、並列更新の上限を十分に下回るようにしてください。
設計する前に同時実行制限を把握しておきましょう
単一のTriggerパイプライン更新は最大 16のデータセット更新を並行して 実行します。これは、すべてを一つのパイプラインにまとめるチームにとって最もよくある驚きです。約16個以上のデータセットが同時に実行できると、余ったものは並列に動かず最初の16個の後ろにキューイングされるため、コンピュートが可能でも更新時間が長く伸びてしまうのです。もし数十の独立したデータセットがあり、更新時間が気になるなら、それだけでもすべてを一つのパイプラインに詰め込むべきではありません。
同じパイプラインに属するもの
構造やスケジュールを共有するデータセットは、まとめて管理してください：
- 注文用のブロンズ、シルバー、ゴールドテーブルなど、1つの依存関係チェーンまたは1つの論理ドメインを形成するデータセット。接続された有向非巡回グラフ（DAG）を維持することで、パイプラインはそれを一貫した単位としてスケジュール、チェックポイント、および完全更新できるようになり、リネージも読みやすくなります。See LakeFlow Pipelines.
- 同じ鮮度要件と実行頻度を共有するデータセット（一緒に更新されるべきもの、同じTriggerで更新されるもの、同じトランザクション境界内にあるものなど）。
- グラフ全体が並列更新の上限内に収まり、許容可能な時間内に更新される程度に、集計されたデータセットが十分に小さいこと。
個別のパイプラインに含めるべきもの
所有権、レイヤー、レイテンシーが異なる場合は、データセットを分割する:
- 異なるドメインまたはチーム。 所有権を分ける場合は通常、パイプラインも分けるべきです。これにより、あるチームの変更や障害が他のチームの作業を妨げることがなくなります。
- 独立してスケーリングまたはスケジュールするレイヤー。 広く推奨されている分割方法は、取り込み（ブロンズ）と変換（シルバーおよびゴールド）を別々のパイプラインに分離することです。これにより、取り込みが遅延または失敗しても変換が滞ることはなく、それぞれが必要に応じてコンピュートサイズを調整できます。
- 異なるレイテンシープロファイル。 連続的で低レイテンシのストリームは、1日1回のバッチ集約とパイプラインを共有しるべきではありません。トリガー モードと連続パイプラインモードの比較を参照してください。
- 並列更新制限を超えるデータセット （これらはキューに入れられます）。
データセットを単独で実行するには、スタンドアロンのパイプラインを検討します。単 独パイプラインとLakeFlow Pipelinesを参照してください。
実践的な経験則
一つのモノリシックなパイプラインにdefaultにしたり、すべてのテーブルを個別のパイプラインに分割したりもしないでください。ドメイン別+ 共有ケイデンス+依存関係 でグループ化し、 所有権、レイヤー、レイテンシ の境界で分割し、単一パイプラインの独立して更新可能なデータセット数を並列更新の上限以下に快適に保つことができます。迷ったときは、1つの巨大なパイプラインよりもドメインにアライメントされた中規模パイプラインをいくつか用意しましょう。すでに本番運用のモノリスを分割するよりも、後で2つの小さなパイプラインをMergeする方がはるかに簡単です。
制限事項
- 1 回のTriggerによる更新では、最大 16 件のデータセット更新が並行して実行されます。 その上限を超えるデータセットは並行して実行されるのではなくキューに入れられるため、コンピュートが利用可能な場合でも、多数の独立したデータセットを持つパイプラインの更新には時間がかかる可能性があります。
- 複数のパイプラインに分割すると、エンドツーエンドの可視性が一部損なわれます。 分割する場合は、システムテーブル (
system.lakeflow.pipelines,system.lakeflow.job_run_timeline) を活用し、Lakeflow Job で各パーツをオーケストレーションすることで、フロー全体の単一のエンドツーエンドビューを維持できます。「ワークフローでのパイプラインのラン」を参照してください。