流处理的前世今生（九）Netflix的私人订制 Mantis

摘要：总部位于美国加利福尼亚州洛斯加托斯的Netflix是全球最大的流媒体视频服务平台。每年投资数百亿美元制作原创内容，著名作品有《怪奇物语》《鱿鱼游戏》《纸牌屋》等。网飞技术能力领先，拥有先进的视频压缩技术，强大的大数据分析和雄厚的云计算基础设施。

总部位于美国加利福尼亚州洛斯加托斯的Netflix 是全球最大的流媒体视频服务平台。每年投资数百亿美元制作原创内容，著名作品有《怪奇物语》《鱿鱼游戏》《纸牌屋》等。网飞技术能力领先，拥有先进的视频压缩技术，强大的大数据分析和雄厚的云计算基础设施。

在开源领域，网飞贡献了非常多的项目，包括：

Eureka - 服务发现框架Zuul - API网关Ribbon - 客户端负载均衡器Hystrix - 熔断器模式实现Genie - 分布式作业执行服务Atlas - 内存时序数据库Security Monkey - 云安全监控Scumblr - 安全智能框架Metaflow - 机器学习工作流管理Polynote - 多语言notebook环境Spectator - 客户端度量库Spinnaker - 多云持续交付平台

这其中，涵盖了从微服务框架，数据处理平台，安全工具，机器学习，到DevOps，可谓应有尽有。那今天，我们就来看看以一个由Netflix贡献的流数据处理项目，Mantis。

Netflix Mantis是一个实时流处理平台，自2014年以来在Netflix每日处理数万亿个事件和PB级数据。Mantis的独特之处在于其独特的作业链架构，该架构支持流作业之间的直接内存通信，创造了一种微服务风格的流处理方法。这种设计结合其响应式编程模型和复杂的自动扩缩容能力，使Mantis在运营用例中特别具有成本效益，而传统流处理平台往往会过度配置资源。

Netflix从2014年1月开始开发Mantis，当时他们发现在快速扩展的微服务架构中，运营数据的生产和收集存在关键缺口。原始工程团队以及Netflix平台工程组围绕几个核心原则设计了Mantis。

团队改变生成和收集运营数据的方式：

应该能够访问原始事件。 应用程序应该能够自由发布每一个事件。如果在这个阶段降低粒度，比如通过预聚合或采样，那么在获得洞察时就已经处于劣势，因为原始形式的数据已经丢失了。应该能够实时访问这些数据。 运营的本质上具有时间敏感性。随着规模的扩大，这变得越来越重要，因为在更短的时间内影响会变得更大。应该能够对这些数据提出新问题，而不一定需要向我们的应用程序添加新的instrumentation（植入采集点）。 尽管建立了严格的机制来使这些系统具有弹性，但不可能提前知道我们的系统可能遇到的每一种可能的故障模式。当这些故障不可避免地发生时，重要的是我们能够用这些数据得出新的洞察

需要一种新的执行环境：

能够以低延迟处理大容量数据运营负担低 需要一个托管平台，其中大部分运营任务代表用户自动处理。我们不需要运营监控系统的额外开销。具有弹性和韧性 需要一个高度可靠的系统，能够从节点故障中自动恢复，并能够根据数据量动态扩展资源。流服务生态系统 许多用例往往需要相同的数据。通过允许作业相互发现并通过共享数据和结果协作，可以最大化代码和数据的重用。

在2019年10月，Netflix宣布以Apache License 2.0的许可证开源Mantis。开源系统包括多个代码仓库：主要的mantis平台、用于Web界面的mantis-ui、用于命令行工具的mantis-cli、用于Kubernetes部署的mantis-helm，以及用于查询语言的mantis-mql。

在Netflix，Mantis为直接影响数百万用户的关键运营系统提供动力。例如一个主要的运营指标每秒流开始数（Started stream per second），这是Netflix针对全球观众成功视频播放尝试的主要性能指标。该系统为内容、设备和地理区域的特定组合提供细粒度告警。

上下文告警代表了Mantis最复杂的应用之一，实时分析数百万个微服务交互，以关联Netflix复杂分布式架构中的问题。Mantis将平均检测时间从数十分钟减少到几秒钟，展示了对平台的运营影响。

Mantis实现了一种基于作业的架构，其中应用程序构建为"Mantis作业"，由源、处理阶段和接收器组成。编程模型使用RxJava进行非阻塞流处理，作业分为可以独立扩展的逻辑阶段。

典型的Mantis作业结构遵循以下模式：

MantisJob.source(Netflix.PlayAttempts).stage(new GroupByMovieIdStage).stage(new AnomalyDetectionStage).sink(Alerting.email).config(SLA.lowLatency).create

基于Stage的扩展方法允许单阶段作业进行基本转换，多阶段作业进行复杂处理管道。每个阶段包含执行相同计算的同质工作节点，网络拓扑确保一个阶段中的工作节点连接到前一阶段的所有工作节点。

核心API和SDK包括Mantis Runtime执行环境、用于作业生命周期管理的RESTful控制平面API、用于应用程序发布事件的mantis-publish库，以及用于作业间通信的Job Connector组件。WebSocket流式传输通过 /api/v1/jobConnectbyid/jobID 端点实现实时作业输出访问。

Mantis查询语言（MQL）提供类似SQL的流处理能力：

SELECT * FROM defaultStream WHERE status==500 AND userId IS NOT NULLGROUP BY deviceTypeWINDOW TUMBLING 5 MINUTES

source https://netflix.github.io/mantis/images/MantisArchitecture.png

具有智能调度的主从架构

Mantis的控制平面使用Akka actors进行领导者选举，其中每个作业集群、作业和工作节点都建模为Actor。Mantis Master处理作业生命周期管理、资源调度和元数据管理，同时注册为Mesos框架以接收资源提供。

Mantis代理（agent）形成运行在EC2实例上的Mesos代理集群，在资源隔离容器中执行工作节点。每个工作节点接收用于跟踪和替换的唯一标识符，提供复杂的资源分配，具有装箱、资源亲和性、任务局部性和可用区平衡能力。

作业管理架构使用作业集群作为模板（类似于类定义），包含构件定义、配置参数和资源需求。作业代表运行实例，具有可配置的SLA管理来控制最小和最大实例数。

作业链和流微服务

直接的作业间通信消除了传统的中间持久化层，作业通过内存套接字连接进行通信。作业连接器实现这种直接通信，而源作业充当数据代理，通过MQL接口向下游作业提供数据。

流微服务架构将每个作业视为独立可部署的微服务，具有专用资源、服务发现能力和用于实时数据访问的流API。这种方法使基于浏览器的客户端能够通过WebSocket流式传输作业输出，同时维护RESTful管理接口。

网络通信层使用RxNetty 0.4进行非阻塞I/O，采用异步、事件驱动模式。数据流遵循推送模型，源作业根据查询订阅向下游消费者流式传输数据，内置的RxJava背压向上游传播以防止系统过载。

复杂的自动扩缩容算法和资源管理

集群级根据资源需求自动调整EC2实例数量，作业级为每个处理阶段独立扩缩容，通过监控CPU、内存等指标和高级PID控制算法来维持最优资源利用率。。

处理保证和容错机制

默认数据处理语义是至多一次交付（At most once），其中亚秒级处理优先于保证数据完整性。当源数据来自Kafka时可使用增强的至少一次语义（At least once），而恰好一次处理（Excat Once）存在于Netflix的内部版本中，但不在开源版本中（也就是说最强功能没有开源）。

工作节点替换和故障处理自动用相同索引标识符替换失败的工作节点，同时为可以快速重建状态的场景维护快速状态重建能力。系统实现自动恢复，为运营监控场景提供可接受的数据丢失权衡。

总结一下

Netflix的Mantic在流处理领域有着独特优势

大规模生产验证是Mantis的主要竞争优势，在Netflix连续运行超过10年，处理前所未有的数据量。该平台的运营重点使其区别于面向分析的解决方案，提供专为监控、警报和异常检测设计的亚秒级延迟能力。通过创新架构实现成本效益 源于按需响应模型，其中资源成本与实际数据消耗保持一致，作业链消除冗余数据处理，智能自动扩缩容防止传统流架构中典型的过度配置。流微服务架构通过直接的作业间通信实现独特的数据重用模式，消除中间持久化层，降低多阶段处理管道的运营复杂性。

但是Mantic也存在着极为明显的限制

有限的恰好一次语义 在开源版本中限制了需要严格数据一致性保证的功能。生态系统成熟度落后于成熟的Apache项目，与Kafka Streams或Apache Flink等替代方案相比，社区规模较小，第三方集成较少。陡峭的学习曲线和运维的复杂性 源于需要RxJava专业知识的响应式编程模型、需要Mesos基础设施知识的平台复杂性（另一个也采用了Mesos的流处理框架Apache Apex也没有避免退役的命运），以及与通用流框架相比有限的分析能力。状态管理限制限制了有状态数据处理能力，与Apache Flink的高级时态处理相比只有基本的窗口函数。

我个人认为，Mantis最大的问题是，它是为了netflix的特有问题所设计的，虽然， Netflix把它开源，作为一个通用的流处理项目来维护，但是我们看到从用例到架构设计，无疑都是为了Netflix的特有上下文来安排的。这样的项目，虽然具有一定的通用性，但是很难和一开始就以通用问题为目标而设计的产品来竞争。