修复 Lakeflow 声明性管道中的高初始化时间

管道可以包含多个数据集，其中包含许多流，以使其保持最新状态。管道会自动管理更新和群集，以高效更新。但是，管理大量流会产生一些开销，有时这可能会导致处理期间大于预期的初始化甚至管理开销。

如果在等待触发的管道进行初始化（例如初始化时间超过 5 分钟）时遇到延迟，请考虑将处理拆分为多个管道，即使数据集使用相同的源数据也是如此。

注释

触发的管道在每次被触发时执行初始化步骤。连续管道仅在停止和重启时执行初始化步骤。本节最适合用于优化被触发的管道初始化。

何时考虑拆分管道

在某些情况下，由于性能原因，拆分管道可能很有利。

INITIALIZING阶段和SETTING_UP_TABLES阶段花费的时间比您希望的要长，这影响了整体流水线的时间。如果超过 5 分钟，通常可以通过拆分管道来提高效率。
在单个管道中运行多个（超过 30-40 个）流式处理表时，管理群集的驱动程序可能会成为瓶颈。如果驱动程序无响应，则流式处理查询的持续时间将增加，从而影响更新的总时间。
具有多个流式处理表流的触发管道可能无法并行执行所有可并行流更新。

本部分介绍单个管道中存在多个表和流时可能出现的一些性能问题。

运行的初始阶段可能是性能瓶颈，具体取决于管道的复杂性。

初始化阶段

在此阶段，将创建逻辑计划，包括用于生成依赖项关系图和确定表更新顺序的计划。

SETTING_UP_TABLES 阶段

在此阶段，将基于上一阶段中创建的计划执行以下过程：

为什么初始化和设置表可能需要更长的时间

对于多个数据集，具有多个流的大型管道可能需要更长的时间，原因如下：

对于具有许多流和复杂依赖项的管道，由于要完成的工作量，这些阶段可能需要更长的时间。
复杂的转换（包括 Auto CDC 转换）可能会导致性能瓶颈，因为根据定义的转换来具体化表的所需操作。
此外，在某些情况下，大量流可能会导致速度缓慢，即使这些流不是更新的一部分。例如，假设有一个管道包含 700 多个数据流，根据配置，每次触发事件涉及更新的流数少于 50 个。在此示例中，每次运行必须遍历所有 700 个表的一些步骤，获取数据帧，然后选择需要运行的数据流。

驱动程序管理运行中的更新。它必须为每个表执行一些逻辑，以确定群集中的哪些实例应处理每个流。当在单个管道中运行多个流表（超过 30-40 个）时，驱动程序可能会成为 CPU 资源的瓶颈，因为它负责处理整个集群的任务。

驱动程序还可以遇到内存问题。当并行流数为 30 或更多时，可能会更频繁地发生这种情况。没有特定数量的流或数据集可能会导致驱动程序内存问题，但取决于并行运行的任务的复杂性。

流式数据可以同时运行，但这需要驱动程序同时使用内存和CPU以支持所有流。在触发的管道中，驱动程序可能会同时并行处理一部分流，以避免内存和 CPU 资源的限制。

在所有这些情况下，拆分管道，以便每个管道中都有一组最佳流可以加快初始化和处理时间。

当所有流都位于同一管道中时，Lakeflow 声明性管道会为你管理依赖项。当有多个管道时，必须管理管道之间的依赖关系。

依赖可能有一个依赖于多个上游管道（而不是一个）的下游管道。例如，如果你有三个管道，pipeline_A、pipeline_B和pipeline_C，并且pipeline_C依赖于pipeline_A和pipeline_B，你希望pipeline_C只在pipeline_A和pipeline_B完成各自的更新后更新。解决此问题的一种方法是，将每个管道作为作业中的一个任务来协调依赖关系，并且正确建模这些依赖关系，因此仅在 pipeline_C 和 pipeline_A 均完成后才更新。
并发管道中可能有不同的流，这些流需要非常不同的时间来完成，例如，如果 flow_A 更新在 15 秒内且 flow_B 需要几分钟时间。在拆分管道之前查看查询时间，并将较短的查询组合在一起可能会有所帮助。

可以在开始之前可视化管道拆分。下面是处理 25 个表的源管道的图。单个根数据源拆分为 8 个段，每个段具有 2 个视图。

拆分为多个管道之前大量表的图形

拆分管道后，有两个管道。其中一个处理单个根数据源，以及 4 个段和关联的视图。第二个管道处理其余 4 段及其关联的视图。第二个管道依赖于第一个管道来更新根数据源。

显示从单个大型管道拆分出的两个管道的图表

在您规划管道拆分以实现负载均衡后，创建任何必要的新管道，并在不同的管道之间移动表以调整负载。无需完全刷新即可移动数据表。

此方法存在一些限制：