Netflix 实时流处理平台 Keystone 介绍

Netflix 近日在他们的技术博客上发表了一篇博文，探讨其实时流处理平台 Keystone 的设计考虑和见解。

Keystone 自 2015 年 12 月开始运营，随着 Netflix 订阅用户从 2015 年第 2 季度的 6500 万增长到本文写作时的 1.3 亿多，其规模大幅增长。Keystone最初是作为一个Apache Chukwa 管道，随着时间推移演变成了一个 Kafka 前端管道。据这篇博文介绍，早在2016 年，Netflix 就用36 个Kafka 集群每天处理超过7000 亿条消息。

Netflix 的架构由两个不同的实时流处理平台组成。Keystone 专注于数据分析， Mantis 专注于运营。Keystone 提供了数据管道功能和“流处理即服务”。数据管道几乎实时地生成、处理和分析来自 Netflix 运营的所有不同微服务的数据。流处理即服务允许内部用户在开发和运营自定义流处理应用程序时专注于业务应用程序逻辑。

Netflix 在构建和扩展平台时面临的主要挑战，与工程师在构建大规模分布式系统时面临的挑战类似。路由服务支持可调的至少一次交付的语义，并在延迟和消息交付之间进行折中。

Keystone 使用了 Apache Flink ，可以支持无状态和有状态的作业、突发或恒定流量、几秒到几小时的窗口大小、按需严格排序以及可配置的消息传递保证。资源争用也可能成为系统设计的一个问题，因为不同的作业可能在 CPU、内存、I/O 或网络带宽上存在竞争。系统用户有软件工程师也有业务分析师。所有这些挑战，再加上他们希望实现一个基于多租户云的系统，而该系统必须足够简单，以便其用户可以声明并执行作业，而且大多数作业无需依赖运营同事就可以完成，这些构成了一组有趣的设计需求。

Keystone 平台的理念可以总结为使用户完成任务。可调折中、关注点分离和子系统故障（可能发生并将要发生，被描述为“作为一流公民的失败”）是至关重要的基础。

Netflix 工程团队使用声明式协调协议来实现 Keystone 的设计。每个用户声明的目标状态都存储在 AWS RDS 中，并作为事实的唯一来源。例如，如果 Kafka 集群消失了，那么它仅基于 AWS RDS 数据就可以进行重建。

部署编排是通过持续交付工具 Spinnaker 实现的，每个作业都有一个独立的 Flink 集群。每个组件的惟一共享组件是用于协商一致的 ZooKeeper 和用于存储检查点状态的 S3。自助服务工具帮助用户通过路由作业的用户界面和流处理即服务的 CLI 接口来声明作业。

一组内部开发的、针对 Kafka、ElasticSearch 和 Hive 等的托管连接器可以帮助打算使用 Keystone 的开发人员更快地开发，而无需考虑平台的内部结构和消息解析。自定义领域专属语言（DSL）库抽象了过滤、投影和其他常用的数据转换任务。该平台通过 AWS RDS 协调机制提供自修复功能，在出现故障时，可以通过用户界面用需要的数据回填或回放作业。最后，该平台内置了监控和警报功能。

Keystone 平台的未来开发包括服务层、流媒体 SQL 支持和机器学习等功能，所有这些都将在未来的 Netflix 工程博客文章中详细介绍。

查看英文原文： Netflix Keystone Real-Time Stream Processing Platform