Lakeflow管道的生产准备情况

生产就绪是指流水线已经能够在无人值守的情况下针对真实业务数据运行,而本页提供了一份检查清单,帮助你在依赖该流水线之前确认其已达到这一状态。

Overview

生产准备的流水线按计划运行,基于真实业务数据,故障会自动被发现,而非由下游用户报告。 准备度是涵盖数据质量、可靠性、可观察性、部署、成本和治理的检查清单。

Lakeflow 管道提供了几个内置的基础构件,它们直接映射到这些维度。 与其试图凭直觉判断自己是否准备好,不如按照下面的清单走一遍,把任何未勾选的选项都当作已知的空缺。 如果大部分复选框都已选中,该流水线就可以在生产环境中运行了。 如果有几项未勾选,就把它们当作优先处理的待办事项清单。 先从数据质量和通知开始,因为它们添加成本最低,也最有可能发现未被发现的不良运行。

清单

按照生产就绪情况的各个维度逐项检查以下清单,并将任何未勾选的项目视为在依赖该流水线之前需要补齐的已知差距。

数据质量

  • [ ] 每个可能接收坏数据的数据集至少定义了一个期望值(expectexpect_or_drop, 或 expect_or_fail),而不仅仅是文档字符串注释说“假设输入干净”。
  • [ ] 你已针对不同约束,有意识地选择使用 warndropfail:对于应当中止整个流程的情况(例如主键损坏),使用 fail;对于可以安全丢弃的记录,使用 drop(由隔离表记录被丢弃的内容);而 warn 仅在你会主动监控其趋势时才使用。
  • [ ] 你已经查看了流水线界面中 的数据质量 标签,或者至少查询过一次事件日志,并且知道你当前的期望通过率,而不仅仅是期望的存在。 请参阅通过管道预期管理数据质量

可靠性

  • [ ] 你已经明确选择了 触发式连续 流水线模式中的一种。 对于绝大多数管道来说,“触发”是合适的默认设置。 仅在确实需要亚分钟级延迟的场景中使用连续模式,因为它需要常开集群。 请参阅触发与连续管道模式
  • [ ] 流水线由作业调度器或 Lakeflow Job 进行调度,而不是依靠某人记得选择 开始。 请参阅 工作流中的运行管道
  • [ ] 失败通知可通过电子邮件、Webhook 或事件挂钩进行配置,这样你就能在利益相关者之前得知某次运行失败。
  • [ ] 对于流媒体源来说,你测试了检查点故障时的处理方式,并且知道恢复程序,而不是在事件发生时才发现。 参见 “从流检查点故障中恢复流水线”。
  • [ ] 流水线作为 服务主体运行,而非个人用户身份,使无人自动化的运行更加安全和稳定。

Observability

  • [ ] 你知道事件日志的位置,并且至少对它运行过一次关于血缘、数据质量指标或资源使用情况的查询。 事件日志是管道的主要可观测性原语,管道用户界面则是对其的视图。 参见 监控管道
  • [ ] 你已经检查了 system.lakeflow.pipelines 和相关的系统表,或者构建了一个小型仪表板,这样就可以通过查询了解流水线的健康状态,而不只是通过 UI 目测判断。
  • [ ] 你知道当前的更新耗时,并且可以判断它是呈上升趋势,还是在一次次更新中保持稳定。

部署与变更管理

  • [ ] 流水线通过捆绑包定义和部署,而非在界面中手动点击生成,因此可以进行代码审查和版本控制。 请参阅 创建源代码管理管道
  • [ ] 你至少要有一个 dev 和一个 prod 目标(理想情况下还应有 devstagingprod),这样更改在接触真实数据之前就能先在某处得到验证。
  • [ ] 环境特定的值(目录名称、调度、源路径)通过流水线配置参数化,而非硬编码,因此同一代码能在目标间干净利落地推广。

计算与成本

  • [ ] 你明确选择了无服务器和经典计算(无服务器是新流水线的默认推荐),并且说明了原因,如果你选择了经典。 请参阅 配置无服务器管道
  • [ ] 如果在经典计算中,启用了增强型自动扩展,而不是固定集群大小,这样流水线不会在负载下默默导致工人饥饿。
  • [ ] 你至少查看过一次 system.billing.usage 中此管道的 Databricks 单位 (DBU) 用量,而且这个数字并不令人意外。

Governance

  • [ ] 目标表存在于 Unity 目录中,采用有意的目录和模式布局(例如,每个环境单独的目录或模式),而非传统 Hive 元存储库。
  • [ ] 对源对象和目标对象的访问遵循最小权限:管道的服务主体只能读取和写入所需的内容,不能超过其他内容。 参见 管理流水线的标识、权限和特权

其他资源