共计 2907 个字符，预计需要花费 8 分钟才能阅读完成。
Netflix 目前领有私有云上最简单的数据平台之一，数据科学家和数据开发工程师在该平台上每天运行着大量批处理和流解决工作。随着咱们的付费订阅用户在寰球范畴内的增长以及 Netflix 正式进入游戏赛道，批、流解决工作的数量也迅速减少。咱们的数据平台基于诸多分布式系统构建而成，因为分布式系统的固有个性，运行在数据平台上的工作不可避免地隔三差五呈现问题。对这些问题进行定位剖析是件很繁琐的事，波及从多个不同零碎收集日志和相干指标，并对其进行剖析以找出问题的根本原因。在咱们以后规模上，如果人工手动地定位和解决问题，即便是解决一小部分异样工作，也会给数据平台团队带来微小的运维累赘。另外，这种手动定位问题的形式，对平台用户工作效率上造成影响也不可小觑。
以上问题促使咱们尽可能被动地检测和解决生产环境中的失败工作，尽量避免使团队工作效率升高的异样。于是咱们在数据平台中设计、开发了一套名为 Pensive 的主动诊断和修复零碎。指标是对执行失败和执行工夫过长的工作进行故障诊断，并尽可能在无需人工干预的状况下对其进行修复。随着咱们的平台一直倒退，不同的场景和问题 (scenarios and issues) 都可能会造成工作失败，Pensive 必须被动在平台级别实时检测所有的问题，并诊断对相干工作的影响。
Pensive 由两个独立的零碎组成，别离反对批工作和流工作的主动诊断。本文将简略介绍这两个零碎的性能，以及它们是如何在离线平台 (Big Data Platform) 和实时计算平台 (Real-time infrastructure) 中执行主动诊断和修复。
批工作主动诊断系统 – Batch Pensive
图 1：批工作主动诊断系统架构图
数据平台中的批处理工作流工作应用 Netfix 自研的调度服务 Meson 调度执行，调度服务通过启动容器运行工作流节点，容器则运行在 Netflix 自研的容器治理平台 Titus 上。这些工作流节点通过 Genie(相似 Apache Livy) 提交执行 Spark 和 TrinoDb 作业。如果工作流节点失败，调度服务会向 Pensive 发送错误诊断申请。Pensive 从相干数据平台组件中收集该节点执行过程中产生的失败日志，而后提取剖析异样堆栈。Pensive 依赖于基于正则表达式的规定引擎来进行异样诊断，这些规定是在一直的实际中总结演绎进去的。零碎依据规定断定谬误是因为平台问题还是用户 Bug 造成的、谬误是否是长期抖动造成的(transient)。如果有个一条规定命中谬误，Pensive 会将无关该谬误的信息返回给调度服务。如果谬误是长期抖动造成的，调度服务将应用指数退却策略（exponential backoff）重试执行该节点几次。
Pensive 最外围的局部是 对谬误进行分类的规定。随着平台的倒退，这些规定须要一直被欠缺和改良，以确保 Pensive 维持较高的谬误诊断率。最后，这些规定是由平台组件负责人和用户依据他们的教训或遇到的问题而奉献的。咱们当初则采纳了更零碎的办法，将未知谬误输出到机器学习零碎，而后由机器学习工作对这些问题进行聚类，以针对常见谬误演绎出新的正则表达式。咱们将新正则提交给平台组件负责人，而后由相干负责人确认谬误起源的分类以及它是否是长期抖动性的。将来，咱们心愿将这一过程自动化。
检测平台级别的问题
Pensive 能够对单个工作流节点的失败进行谬误分类，然而通过应用 Kafka 和 Druid 对 Pensive 检测到的所有谬误进行实时剖析，咱们能够疾速辨认影响所有工作流工作的平台问题。单个失败工作的诊断被存储在 Druid 表中后，咱们的监控和警报系统 Atlas 会对表中的数据每分钟进行一次聚合，并在因平台问题导致工作失败数量突增时发送告警。这大大减少了在检测硬件问题或新上线零碎中的 Bug 所需的工夫。
流工作主动诊断系统 – Streaming Pensive
图 2：批工作主动诊断系统架构图
Netflix 数据平台中的实时计算基于 Apache Flink 实现。大多数 Flink 工作运行在 Keystone 流工作解决平台上，该平台封装了底层 Flink 工作详细信息，给用户提供了生产 Kafka 音讯和将处理结果写入到不同数据存储系统（如 AWS S3 上的 ElasticSearch 和 Iceberg）的能力。
因为数据平台治理着 Keystone 的数据处理流程，用户心愿 Keystone 团队可能被动检测和修复平台问题，而无需他们的任何参加。此外，因为 Kafka 中的数据个别不会长期存储，这就须要咱们及时地、在数据过期之前解决问题。
对于运行在 Keystone 上的每个 Flink 工作，咱们会监控消费者的滞后水平 (lag) 指标。如果超过阈值，Atlas 会向 Streaming Pensive 发送告诉。
与批工作诊断系统一样，Streaming Pensive 也是基于规定引擎来诊断谬误。然而，除了日志之外，Streaming Pensive 还会查看 Keystone 中多个组件的各种指标。谬误可能呈现在任何一个组件中，如源头的 Kafka、Flink 工作或者 Sink 端数据存储系统。Streaming Pensive 对这些日志和指标进行诊断，并尝试在问题产生时主动修复。咱们目前可能主动修复的一些场景如下：
- 如果 Streaming Pensive 发现一个或多个 Flink Task Manager 内存不足，零碎能够减少 Task Manager 数重新部署 Flink 集群。
- 如果 Streaming Pensive 发现 Kafka 集群上的写入音讯速率忽然减少，它能够长期减少 topic 数据保留的大小和保留工夫，这样咱们就不会在消费者滞后时失落任何数据。如果峰值在一段时间后隐没，Streaming Pensive 能够主动复原到之前的配置。否则，它将告诉工作负责人，排查是否存在导致写入速度突增的谬误，或者是否须要从新调整消费者以解决更高的写入速度。
只管咱们的主动诊断成功率很高，但依然存在无奈实现自动化的状况。如果须要人工干预，Streaming Pensive 将告诉相干组件团队，以便及时采取措施解决问题。
将来布局
Pensive 对 Netflix 数据平台的日常运行至关重要。它帮忙工程团队加重运维累赘，让他们专一于解决更要害和更具挑战性的问题。但咱们的工作还远未实现，将来还有很多工作要做。以下是咱们将来的布局：
- Batch Pensive 目前仅反对诊断失败的工作，咱们心愿后续扩大反对工作性能诊断以确定工作执行变慢的起因。
- 主动配置批处理工作流工作，以便它们能胜利执行或疾速且高效的执行。其中一个方向是 Spark 工作内存主动调优，是一项颇具挑战性的工作。
- 应用机器学习分类器来欠缺 Pensive（的规定）。
- 实时计算平台最近上线了 Data Mesh 性能，咱们须要扩大 Streaming Pensive 来反对该性能的诊断。
致谢
感激 Netflix 数据平台的离线计算团队和实时计算团队的帮忙和反对，如果没有他们这项工作是无奈实现的。在咱们致力于改善 Pensive 的过程中，他们始终是咱们的松软的支柱。
原文
Auto-Diagnosis and Remediation in Netflix Data Platform