流处理的前世今生（六） 生不逢时的中庸之道Apache Samza

欢迎大家来到IT世界,在知识的湖畔探索吧!

Apache Samza最初由LinkedIn开发，创始人Jay Kreps（Confluent的创始人和CEO） 和其团队在LinkedIn工作期间发现开发者使用微服务发送和接收Kafka消息时出现了一些通用模式。Samza与Apache Kafka一同开发，两者最初都由LinkedIn创建。Samza于2013年加入Apache基金会 ，并于2015年1月22日正式成为Apache顶级项目 。该项目在2015到2017年得到了快速的发展。在团队包括Martin Kleppmann（Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems的作者）、Chinmay Soman 、Jakob Homan（Hadoop,Kafka,Airflow等项目的开发者）、Yi Pan等优秀工程师的共同工作下，添加了有状态处理、批处理、SQL、YARN、独立部署等现代流处理系统的核心功能。

Samza在LinkedIn、Uber、TripAdvisor、Slack等多家大公司的生产环境中得到了验证。Uber工程师表示”Apache Samza在过去一年半中为Uber的近实时用例提供支持，涵盖业务指标分析、机器学习特征提取以及欺诈检测、动态定价等关键应用”

但是项目目前面临一些发展挑战，社区活跃度有所下降，创始人反思认为”回过头看，我认为我们提出了错误的用例。Samza的架构更适合SQL和ETL用例，一些用户开始迁移到其他平台，如Uber从”Storm迁移到Apache Samza，现在又迁移到Flink” 。

为什么一个有诸多明星工程师主导的开源项目会走向没落呢？

我们来仔细看看这个项目。

Apache Samza是一个分布式流处理框架，它使用Apache Kafka进行消息传递，使用Apache Hadoop YARN提供容错、处理器隔离、安全性和资源管理。Samza代表了轻量级库（如Kafka Streams）和重量级平台（如Flink）之间的中间解决方案，提供强大的状态管理和运维稳定性。

应用代码太复杂，我就不贴在这里了，大家可以看看这里的例子。

架构概览

Samza架构遵循与Hadoop类似的模式（Hadoop也使用YARN作为执行层、HDFS作为存储层、MapReduce作为处理API）：

• 流处理层：Apache Kafka用于数据传输和消息传递
• 执行层：Apache Hadoop YARN用于资源管理和容器编排
• 处理层：Samza API用于流处理逻辑

Samza通过逻辑上将应用程序分解为多个任务来扩展您的应用程序。任务是应用程序的并行处理单位。每个任务从输入流的一个分区消费数据。

• 任务：并行处理的基本单位。每个任务处理输入流的一个分区，没有跨分区状态共享，支持独立执行。
• 容器：物理执行单位（JVM进程），运行一个或多个任务。应用程序通常跨多个主机分布多个容器。
• 协调器：管理跨容器的任务分配，监控容器健康状况，并在故障期间处理任务重新分配。协调器是可插拔的，支持独立部署和YARN部署模式。

欢迎大家来到IT世界,在知识的湖畔探索吧!

source https://www.researchgate.net/publication//figure/fig4/AS:4833@47/The-Apache-Samza-Architecture.png

Samza提供可扩展的高性能存储，使您能够构建有状态的流处理应用程序。这是通过为每个Samza任务关联其自己的本地数据库实例（又称状态存储）来实现的。

• 本地状态存储：每个任务维护自己的嵌入式数据库（通常是RocksDB）
• 变更日志流：状态变更被复制到Kafka主题以实现容错
• 主机亲和性：任务优先调度到包含其本地状态快照的主机上

这样的设计有不少优点：

• 优秀的状态管理
• Samza管理流处理器状态的快照和恢复。当处理器重启时，Samza将其状态恢复到一致的快照。Samza构建用于处理大量状态（每个分区许多GB）。
• 增量检查点：Samza的检查点机制确保每个任务也将其状态存储的内容与最后处理的偏移量一致地存储。检查点是增量刷新的，即状态存储只刷新自上一个检查点以来的增量，而不是刷新其整个状态。
• 性能优势：
• 本地状态访问消除了网络延迟
• 每个节点的吞吐量约为110万消息/秒，仅使用rocksdb时平均CPU利用率约为77%
• 通过主机亲和性支持TB级状态，停机时间最短
• 运维简单性
• Samza作为嵌入式库：轻松集成到现有应用程序中，无需启动和运营单独的流处理集群
• 双重部署模型：Samza是唯一为这两种部署选项提供一流支持的系统。一些系统（如Kafka-streams）只支持嵌入式库模型，而其他系统（如Flink、Spark streaming等）只为流处理提供框架模型。
• 成熟的容错机制
• 消息持久性：Samza使用Kafka保证消息按写入分区的顺序处理，且不会丢失任何消息。
• 状态恢复：从变更日志流自动恢复状态
• 主机亲和性：最小化故障期间的状态重构时间
• 线程灵活性
• Samza提供灵活的线程模型来运行每个任务。运行应用程序时，可以控制处理数据所需的工作线程数量。支持同步和异步处理模型，具有可配置的并行性。

但同时，Samza也有很多问题

• 与Kafka和YARN紧耦合
• Apache Samza严重依赖Apache Kafka进行消息传递，和Apache YARN进行资源管理，这可能在设置和维护方面引入额外的复杂性。
• 运维开销：
• 需要Kafka集群进行消息传递
• 需要YARN集群进行资源管理
• 因为依赖Kafka，又增加了对ZooKeeper依赖（当时还没有Kraft）
• 复杂的多系统管理
• 有限的处理模型
• Samza是一个纯流处理框架，不支持批处理。与Flink或Spark等统一批处理/流处理系统不同，Samza纯粹专注于流处理，在混合工作负载环境中限制了通用性。
• 相比现代替代方案的API复杂性
• 要在Samza中定义流拓扑，必须在编译前明确定义Samza任务的输入和输出。一旦应用程序编译完成，拓扑就被固定，因为定义嵌入在分发到YARN的应用程序包中。
• 相比现代声明式框架的更低级API
• 需要更多样板代码
• 对于复杂的流处理模式不够直观
• 有限的SQL支持
• 虽然Samza已添加SQL功能，Samza SQL提供声明式SQL接口来创建应用程序，但相比Flink或ksqlDB等系统，SQL支持不够成熟。

总结

Samza在拥有诸多明星工程师参与的情况下，社区去不温不火，github只有不到1000的点赞，这里的原因大致有以下一些：

1. 技术路线选择失误：架构定位不清晰，被更专业化的解决方案超越 ，如果专注做ETL也许会更好。
2. 生态系统碎片化：过度依赖外部系统（Kafka，Yarn，个人认为YARN是最大的败笔），增加了采用门槛
3. 市场时机问题：在流处理领域快速演进期，未能跟上创新步伐。（主要还是竞争对手非常强大）
4. 用户需求变化：市场更倾向于要么极简（Kafka Streams）要么全功能（Flink）的方案，像Samza这种中间方案，并不能被用户所接受。

“生当作人杰，死亦为鬼雄；至今思项羽，不肯过江东。” 在我们这个激烈竞争的领域，你最好是那个行业的翘楚，似乎并没有中间的道路。