Lakeflow pipelines 全体でデータセットを整理する
Use Lakeflow pipelines to process anywhere from one to hundreds of datasets in a single pipeline. Decide which datasets belong together based on domain, cadence, and dependencies, and split work into separate pipelines when ownership, latency, or scale differ.
Overview
チュートリアルでは決して取り上げられないものの、実際のデプロイメントでは重要となる決定事項があります。それは、どのテーブルを同じパイプラインにまとめるべきか、そしていつ別のパイプラインとして分離すべきかという点です。これを誤ることは、チームが自らを追い詰めてしまう最も一般的な原因の1つです。典型的な失敗パターンは、 すべて を1つの巨大なパイプラインに詰め込み、後になってからスケーリング、同時実行性、影響範囲の問題に直面し、その解決に苦労することです。
There's no single right answer, but there are clear forces pulling in each direction and one hard constraint worth knowing before you design.
ガイドライン
ドメイン、共有ケイデンス、依存関係に基づいてデータセットをグループ化し、所有権、レイヤー、レイテンシの境界で分割します。単一のパイプラインにおける独立して更新可能なデータセットの数は、並列更新の上限を十分に下回るようにしてください。
Know the concurrency limit before you design
A single triggered pipeline update runs at most 16 dataset updates in parallel . This is the most common surprise for teams who put everything in one pipeline: once you have more than roughly 16 datasets that could otherwise run concurrently, the extra ones queue behind the first 16 rather than running in parallel, so total update time stretches out even though there's compute available. If you have dozens of independent datasets and you care about wall-clock update time, that alone is a reason not to cram them all into one pipeline.
同じパイプラインに属するもの
構造やスケジュールを共有するデータセットは、まとめて管理してください：
- Datasets that form one dependency chain or one logical domain, such as the bronze, silver, and gold tables for orders. Keeping a connected directed acyclic graph (DAG) together lets the pipeline schedule it, checkpoint it, and full-refresh it as a coherent unit, and keeps lineage readable. See Load and process data incrementally with Lakeflow pipeline flows.
- 同じ鮮度要件と実行頻度を共有するデータセット（一緒に更新されるべきもの、同じTriggerで更新されるもの、同じトランザクション境界内にあるものなど）。
- グラフ全体が並列更新の上限内に収まり、許容可能な時間内に更新される程度に、集計されたデータセットが十分に小さいこと。
個別のパイプラインに含めるべきもの
Split datasets apart when they differ in ownership, layer, or latency:
- 異なるドメインまたはチーム。 所有権を分ける場合は通常、パイプラインも分けるべきです。これにより、あるチームの変更や障害が他のチームの作業を妨げることがなくなります。
- 独立してスケーリングまたはスケジュールするレイヤー。 広く推奨されている分割方法は、取り込み（ブロンズ）と変換（シルバーおよびゴールド）を別々のパイプラインに分離することです。これにより、取り込みが遅延または失敗しても変換が滞ることはなく、それぞれが必要に応じてコンピュートサイズを調整できます。
- Different latency profiles. A continuous, low-latency stream shouldn't share a pipeline with a once-a-day batch aggregate. See Triggered vs. continuous pipeline mode.
- Datasets that push you past the parallel-update limit and would otherwise queue.
To run a set of datasets in isolation, consider a standalone pipeline. See Standalone pipelines vs. Lakeflow pipelines.
実践的な経験則
Don't default to one monolithic pipeline, and don't shatter every table into its own pipeline either. Group by domain + shared cadence + dependency , split at ownership, layer, and latency boundaries, and keep any single pipeline's independently updatable dataset count comfortably under the parallel-update ceiling. When in doubt, prefer a handful of medium pipelines aligned to domains over one giant pipeline. It's far easier to merge two small pipelines later than to carve up a monolith that's already in production.
制限事項
- 1 回のTriggerによる更新では、最大 16 件のデータセット更新が並行して実行されます。 その上限を超えるデータセットは並行して実行されるのではなくキューに入れられるため、コンピュートが利用可能な場合でも、多数の独立したデータセットを持つパイプラインの更新には時間がかかる可能性があります。
- 複数のパイプラインに分割すると、エンドツーエンドの可視性が一部損なわれます。 分割する場合は、システムテーブル (
system.lakeflow.pipelines,system.lakeflow.job_run_timeline) を活用し、Lakeflow Job で各パーツをオーケストレーションすることで、フロー全体の単一のエンドツーエンドビューを維持できます。「ワークフローでのパイプラインのラン」を参照してください。