注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。

稳定性建议

本页面涵盖了随着时间推移创建有弹性和稳定的管道的关键建议。

所有更改的版本管理

每一个生成数据集的逻辑都应该进行版本管理。这使得跟踪发生在管道中的回归和更改变得更容易。实际上,这归结为:

  1. 在设置生产级管道时,避免使用Contour代码工作簿,因为在这些工具中跟踪修改更具挑战性。这些工具非常适合开发阶段,但随着管道的成熟,功能应该在变换中重写,理想情况下使用PythonJava
  2. 确保在所有代码库上锁定master分支,所有更改都需要代码审阅者的拉取请求和批准。
  3. 在合并时,我们建议始终使用压缩合并,因为这会在master上留下更干净的提交历史。

隔离常见数据质量错误

“敏感”或“不稳定”的数据集应该通过验证步骤与管道的其余部分隔离开来。尤其是,Fusion中创建的数据集、手动数据上传和其他类型的上传容易出现数据质量问题,这些问题可能会影响整个管道。

在下面的示例中,假设名为Fusion的数据集经常遇到数据质量问题(模式更改、解析错误、不完整数据等),最终影响了管道的其余部分。

解决方案是创建一个Fusion验证数据集,如果某些验证步骤通过,则从Fusion中复制数据。

带有Fusion Sheets和手动上传验证数据集的数据沿袭图示例

fusion validation example

Copied!
1# 示例验证代码 2@transform( 3 input=Input("/MyProject/Fusion"), 4 validated_input=Output("/MyProject/Fusion Validated"), 5) 6def validate(input, validated_input): 7 # 获取输入数据框的列数据类型 8 found_dtypes = input.dataframe().dtypes 9 10 # 验证列数量是否不少于8 11 assert len(found_dtypes) >= 8, "Schema break, column count too low" 12 13 # 验证是否存在名为 'hours' 的列且其数据类型为 int 14 assert ("hours", "int") in found_dtypes, "'hours' has to be an int" 15 16 # 将验证后的数据写入输出 17 validated_input.write_dataframe(input.dataframe())

创建一个事件驱动的计划,以在Fusion更新时搭建Fusion Validated

Fusion Validated视为其他管道的输入。从搭建中忽略它,并在其上添加相关的健康检查。搭建状态很重要,因为您可能需要联系负责更新Fusion的人,以便告知他们潜在的出错或问题。

同样的推理适用于Manual UploadManual Upload Validated数据集。

示例数据沿袭图,突出显示从Apex 1搭建中排除的数据集

validated datasets

您不必在搭建中明确排除数据连接同步,因为编排系统始终认为它们是最新的。上图中它被染成蓝色意味着将触发摄取。

处理共享资源

在您的项目中,您可能有一个属于许多不同管道的数据集。如果您的搭建没有完美对齐,某些管道可能会在搭建此数据集时被阻塞。

在这种情况下,您应该考虑创建一个新管道,以所需频率搭建此共享数据集,并将共享数据集作为其他管道的输入(在计划中忽略它)。但请注意,此类操作会显著增加管道设置的复杂性。我们的建议是不要执行此操作,除非绝对必要。

另一个不那么侵入性的解决方法是仅在一个管道/计划中搭建共享资源,并在所有其他管道中将其视为输入。例如,在前面的图中,将Shared视为其中一个管道的输入(即从所有计划中排除,除一个计划外)。

避免部分运行

您应避免仅运行管道的一部分或在数据集上运行“完整搭建”。

管道要么是最新的,要么不是。如果您仅运行管道的一部分(例如,仅导出阶段),您可能会处于不一致的状态,从而难以评估管道是否健康。如果您在终端数据集上运行“完整搭建”,此搭建将缺少管道应运行的所有相关选项(重试、失败策略、忽略等)。无论何时需要手动启动搭建,您应在计划概览页面上使用“立即运行计划”按钮,以根据计划配置运行搭建。