调度最佳实践

为了确保生产管道的调度可以轻松管理，我们制定了一套调度指南。使用本页面管理您负责的调度。

概览清单

• 每个数据集应仅由一个调度搭建。
  • 您可以通过在数据沿袭图中选择节点颜色下拉菜单中的调度计数来查看每个数据集上的调度数量。
• 您必须为每个原始数据连接同步设置一个强制搭建调度。
  • 其他调度上不应有强制搭建。强制搭建应仅用于数据连接同步。
• 尽量避免使用完全搭建，而是使用连接搭建。
• 您的调度应仅搭建您拥有的数据集；您的调度不应搭建您不拥有的数据集。
• 您的调度不应搭建回收站中的数据集。使用升级助手调查和补救包含被删除资源的调度。
• 在您的调度中添加重试（我们建议重试三次，间隔一到三分钟）。
• 避免在管道的每个步骤上有多个调度；相反，将数据集合并到逻辑调度中。

示例

一个包含不必要调度的管道，应将其合并为一个调度：

使用连接搭建将数据集合并到逻辑调度中：

使用以下指导来为您的管道设置有效的调度系统。

最佳实践

每个管道一个调度

在大多数情况下，每个管道应该只有一个调度。事实上，管道中的每个数据集应该只与一个计划搭建相关联。由两个不同的调度搭建的数据集可能导致排队，并减慢两个调度的速度。保持您的调度集简单明了，以明确每个调度的职责，并使得在某个数据集的搭建失败时更容易调试。这也可能有助于管道维护；当您想配置管道时，您只需检查或修改一个地方。

对于以多个连续步骤运行的管道，可以例外处理；以下描述了一些此类示例：

1. 如果管道有多个终端节点，您可以考虑为每个节点设置单独的调度。在下面显示的示例管道中，最自然的方法是设置三个调度：定义在Apex 1、Apex 2和Apex 3上。然而，在Shared上创建一个调度并将此数据集视为其他管道的输入可能也是有益的。
2. 如果您的管道使用验证表，您可能需要为它们设置单独的调度。
3. 请参阅稳定性建议以获取有关如何有效处理此类复杂管道的更多信息。

项目范围的调度

所有调度应尽可能地为项目范围，以便调度的成功运行不依赖于单个用户（调度所有者）的权限。否则，调度所有者的权限可能会更改，阻止调度的数据集搭建。这一点尤其重要，因为调度的所有权可能会在调度编辑后更改，因为最后一个修改调度的用户成为调度的所有者。

有些情况下无法为项目范围调度：

• 权限被切断的变换
• Contour任务
• Fusion同步

每个用户范围调度一个所有者

对于无法为项目范围的调度，最好由单个用户拥有给定管道上的所有调度。此用户通常是“服务用户”（不与单个人绑定的特殊用户账户）。或者，单个所有者可以是团队负责人，负责项目中调度的所有修改。

让单个用户拥有管道上的调度可以减少复杂性，并保护调度不受用户权限或团队组成更改的不利影响。

如上所述，重要的是要注意，最后一个修改调度的用户成为调度的所有者。如果多个用户配置文件正在管理调度，并且团队中的访问权限不一致，您可能会遇到难以追踪的权限错误，如果您不考虑所有权更改。

使用重试

在配置调度时使用重试。重试是任务的一部分；如果任务因可重试的异常而失败，搭建编排层将重新启动同一任务的新尝试，而不使搭建失败。

我们建议将调度配置为至少三次重试，重试之间至少间隔一分钟。这使平台能够自动拦截可能失败的任务，并在同一搭建中重新触发它们。额外的一分钟间隔为平台提供了从导致任务首次失败的瞬态问题中恢复的机会。

在某些情况下，您可能不希望在任务上启用重试。例如，具有非常严格的服务级别协议（SLA）的管道，您希望在出现故障时立即收到警报，或者具有非幂等副作用的变换。

无多数据集强制搭建

调度可以启用“强制搭建”选项，其中调度中的所有数据集都将被搭建，无论其是否过时。此选项对于数据连接同步非常有用，因为它们在平台中始终是最新的，因此除非使用强制搭建，否则不会作为计划搭建的一部分。但是，我们不建议对任何派生数据集使用多数据集调度和强制搭建选项，因为这在资源使用方面可能代价高昂。相反，拆分您的调度，以便必须强制搭建的数据集位于其自己的调度中。

调度中包含和排除的内容

明确说明您的调度中包含的内容。明确忽略管道之外的数据集。搭建解析可能很复杂，但明确包含的内容比隐含更具透明性。

• 在我们的示例管道截图中，Owned By Someone应从定义在Apex 2上的调度中忽略。同样适用于Cleaned 1和Cleaned 2——在它们中的任何一个上触发任务将立即因缺乏权限而导致搭建失败。

此外，调度不应依赖或尝试搭建的数据集包括：

• **当前在回收站中：**为了补救现有的包含被删除资源的调度，请使用升级助手调查您拥有的调度，以便从调度中取消删除或排除相关资源。
• **由Contour生成：**为了使调度被视为“生产就绪”，我们需要能够查看对管道的更改，并在出现问题时恢复到以前的版本。Contour不支持此类工作流程，我们不鼓励用户在生产管道中使用它们。
• **由代码工作簿和代码工作区生成：**这不是像Contour输出数据集那样的严格规则，但我们不鼓励在生产管道中使用代码工作簿和代码工作区。代码工作簿和代码工作区非常适合解决方案迭代，但在更改管理和恢复方面不如代码库强大。了解代码工作簿、代码工作区和代码库之间的差异。

管道的所有输出应在您的调度中标记为“目标”。调度可以有一个或多个目标，即安装调度的数据集。调度还可以有一个或多个输出，即调度搭建的最终数据集，并且不在搭建中其他地方使用。在大多数情况下，目标数据集和输出数据集将相同，但在某些情况下（特别是多输出搭建），搭建可能具有不同的目标和输出数据集。通常规则是，管道的所有输出都应定义为目标。

快速失败

配置搭建，以便在任务失败时立即失败，通过在高级选项中勾选故障时中止搭建复选框。快速失败将更快地为您提供信号。

命名调度

所有调度都应有一个描述性名称。调度名称在管道随着时间的推移变得复杂和用户增加时非常有用。

描述性调度名称为与调度交互的人员提供有关调度意图的信息；例如，未来负责解决与您的调度相关问题的人。

如果您有多个摄取流，期望其他用户从您的管道中分叉任何路径，或者预计维护责任会随着时间的推移而变化，命名调度尤其重要。