使用 Lakeflow 管道可以在单一管道中处理从一个到数百个数据集不等。 根据域名、节奏和依赖关系决定哪些数据集应归为一体，并在拥有权、延迟或规模不同时将工作拆分成不同的流水线。
Overview
在教程中通常不会遇到的一个问题，在实际部署中却变得很重要：哪些表应该属于同一条流水线，什么时候又应该单独作为一条流水线？ 把这件事搞错，是团队把自己逼入绝境的最常见方式之一。 经典的失败模式是把 所有东西 都塞进一个庞大的管道，之后又遇到扩展、并发和爆炸半径的问题，这些问题难以解决。
没有唯一正确的答案，但每个方向都有明显的力量牵引，还有一个值得你在设计前了解的硬性约束。
Guidelines
按域、共享节奏和依赖分组数据集，并在拥有权、层级和延迟边界处拆分。 将任一条流水线中可独立更新的数据集数量控制在明显低于并行更新上限的水平。
在设计之前了解并发限制
一次触发的流水线更新最多可同时运行 16次数据集更新。 这是把所有内容都放进同一条流水线的团队最常遇到的意外情况：一旦可并发运行的数据集数量大致超过 16 个，超出的数据集就会排在前 16 个之后等待，而不是并行运行，因此即使仍有可用的计算资源，总更新时间也会被拉长。 如果你有数十个彼此独立的数据集，并且在意实际更新时间，仅这一点就足以成为不把它们都放进同一个管道中的理由。
哪些项属于同一管道
当数据集共享结构或排程时，保持它们的统一：
- 这些数据集构成一个依赖链或一个逻辑域，比如订单的青铜、银和金表。 保持一个连通的有向无环图（DAG）在一起，使流水线能够调度、检查点并作为一个连贯单元进行全面刷新，同时保持谱系的可读性。 请参阅 使用 Lakeflow 管道流以增量方式加载和处理数据。
- 具有相同新鲜度要求和运行频率的数据集，例如应当一同更新、由同一触发条件触发并处于同一事务边界内的数据集。
- 总体规模足够小的数据集，使整个图形都能轻松保持在并行更新上限之内，并在可接受的时间内完成刷新。
什么应该放在独立的管道里
当数据集在所有权、层级或延迟上不同时，将其拆分：
- 不同的领域或团队。 独立所有权通常意味着不同的管道，这样一个团队的变动或失败不会阻碍另一个团队的变动。
- 要单独缩放或调度的图层 一种被广泛推荐的拆分方式是，将数据摄取（青铜层）与数据转换（白银层和黄金层）分成不同的管道，这样即使数据摄取变慢或失败，也不会拖慢数据转换，而且双方都可以根据各自的需求配置计算资源。
- 不同的延迟特征。 连续、低延迟的流不应与一天一次的批处理聚合共享流水线。 请参阅触发与连续管道模式。
- 这些数据集会让你超过并行更新的限制 ，否则会排队。
为了单独运行一组数据集，可以考虑一个独立的流水线。 参见 独立管道与湖流量管道。
实用的经验法则
不要默认采用单体管道，也不要把每个数据表都拆分为各自独立的管道。 按领域 + 共享更新节奏 + 依赖关系分组，按所有权、层级和延迟边界拆分，并将任何单一流水线中可独立更新的数据集数量控制在并行更新上限之下。 拿不准时，优先采用按领域划分的几条中型流水线，而不是一条庞大的流水线。 日后合并两条小流程，要比拆分一个已经上线的单体应用容易得多。
局限性
- 一次触发的更新最多可同时运行16个数据集更新。 超过该上限的数据集会排队等待，而不是并发运行，因此即使有可用的计算资源，包含数十个独立数据集的流水线更新时间也可能会更长。
- 拆分为多个管道会牺牲部分端到端可见性。 拆分时，可依托系统表（
system.lakeflow.pipelines、system.lakeflow.job_run_timeline），并使用 Lakeflow Job 将各个部分协调起来，这样你仍然可以获得整个流程的统一端到端视图。 请参阅 工作流中的运行管道。