Apache Samza 于 2013 年在 LinkedIn 诞生，并于 2014 年成为 Apache 的*项目。现在，LinkedIn 有 3000 多个应用程序在使用它，用它来进行异常检测、欺诈检测、监控性能、通知、实时分析，等等。
如果你对这个领域有一定了解的话，那么你该知道，Apache Kafka 是另一个主要的实时数据处理框架，它最初也是由 LinkedIn 开发的。Kafka 成为 LinkedIn 跟踪数据的标准传输机制，并且每天都会向 Kafka 生成大量数据，应用程序从 Kafka 中获取洞见。
这些应用程序在消费 Kafka 的消息时需要处理一些常见的问题，例如检查点、本地状态管理、处理故障、伸缩处理，等等。Apache Samza 就是为解决流式处理中的这些问题而构建的。但问题是，这在过去可能是有意义的，但在今天还是这样的吗？
这听起来是一个奇怪的问题。毕竟，数据仍然在源源不断地流入，而且还在不断增加。不同之处在于，还有很多其他框架被构建用于满足完全相同的需求：Apex、Flink、Spark 和 Storm（这些还只是 Apache 的开源项目，当然还有其他一些专有的解决方案）。
LinkedIn Samza 团队负责人 Samarth Shetty 表示，当他们开始接触流式处理时，已有的流式处理框架很少能够帮助他们应对 LinkedIn 的规模或技术问题。因此，他们认为最好的办法是开发自己的框架：
“我们必须在 Samza 中加入增量快照和主机粘性（Host Affinity）等功能。当时的 Apache Flink 等框架还没有提供这些功能。Kafka Streams 非常适合用于处理 Kafka 中的事件，但在 LinkedIn，我们需要处理来自不同系统的事件，例如 Azure EventHubs、AWS Kinesis 等。
Samza 提供了轻松连接到不同系统的能力。流式处理是 LinkedIn 的一个非常重要的应用场景，因此，我们致力于构建一个最好的框架。随着时间的推移，我们相信我们已经开发出了最先进的流式处理框架之一，最适合用来满足 LinkedIn 规模的处理需求。”
在某种程度上，这有点类似于机器学习领域的框架格局：有很多可用的框架，该如何选择？当然，有选择并不是件坏事，但“很多”和“太多”之间存在着一个界限。Facebook PyTorch 团队负责人 Soumith Chintala 也表达了类似的观点：我们想要一些对我们来说有用的东西，所以我们决定自己去构建。
兼容 Beam
然而，与 Kafka 和 Confluent 不同的时，Samza 并没有发展成为拥有独立供应商的产品。Shetty 说，LinkedIn 有一群工程师致力于从事流式处理开发工作，而 Samza 是这些工作不可或缺的一部分。他又补充说，他们并没有将 Samza 看成是一个产品：
“我们将其视为一个开源项目。LinkedIn 一直以来都是以这种方式参与开源的——当我们认为我们构建的工具也能为其他公司带来价值时，那么在可能的情况下，我们希望将它们交给社区。
虽然目前没有与 Samza 挂钩的供应商，但包括 Slack、TripAdvisor、Redfin 和 Optimizely 在内的多家公司正在生产环境中使用它。我们认为，能够吸引其他组织使用 Samza 的一个事实是，它已经经过大规模的实战考验，因为 LinkedIn 就在使用它。”
我们知道，Apex 背后的供应商 DataTorrent 最近破产了。或许在这个时候，这个领域没有足够的空间容纳更多的开放核心的流式处理平台供应商。所以，如果你想要使用 Samza，必须想清楚，并自己想办法在生产环境中运行它，即使是最新的 1.0 版本也是这样。不过，在其他方面倒是发生了一些变化，可能会带来更广泛的影响。
Samza 提供了一组新的 API，与 Apache Beam 兼容。Apache Beam 是一个开源项目，提供了一组统一的 API，用于跨执行引擎移植处理管道，包括 Samza、Spark 和 Flink。Beam 还支持使用其他编程语言进行数据处理，包括数据科学领域的宠儿——Python。
在某种程度上，Samza 团队已经意识到，虽然稳定性和性能是 Samza 的核心优势，但它的编程 API 却相当低级。Samza 提供了一组简单的基于回调的 API，可用于指定消息级别的操作。
开发人员必须基于这组 API 自行实现复杂的操作，如窗口操作和连接操作。此外，需要使用 Kafka 主题将多个 Samza 作业连接在一起，这使得构建应用程序非常耗时且容易出错。
Samza 1.0 提供了一组高级 API，开发人员可以通过组合多个运算符来构建复杂的数据管道。但 Samza 团队不满足于此，他们又向前迈进了一步，让他们的 API 与 Apache Beam 兼容。
也就是说，现在可以使用 Java、Scala 或 Python 在 Beam 上开发流式应用程序，并且可以将它们移植到支持它们的框架中，甚至可以在 Google Cloud Dataflow 上运行它们——至少在理论上是这样的。
Flink 和 Spark 都提供了 Beam API 之外的专有扩展，而 Spark 创建者对支持 Beam 并不是很感兴趣。Spark 对 Beam 的支持主要是由社区提供的。
SQL 和 DevOps
但这些并非 Samza 1.0 的全部，因为它还带来了一些更重要的新功能：SQL 和 DevOps 改进。Samza 团队意识到，即使他们的 API 得到了升级，但并非所有人都喜欢使用 API。非工程师更愿意通过 SQL 访问数据，而 Samza 正在提供这样的功能。
我们说“正在”，是因为从技术层面看是可以实现 SQL 功能，但仍然需要通过 API 调用来使用这个功能。这种使用方式违背了降低使用门槛的目标，但 Shetty 指出，他们也正在为 SQL 创建交互式的 shell。SQL 已经成为流式处理的香馍馍——Kafka、Flink 和 Spark 都支持 SQL。
Samza 1.0 的另一个改进方面是集群管理器的独立性。在 Samza 1.0 之前，Samza 需要借助 YARN 进行资源管理和应用程序的分布式执行。虽然使用 YARN 没有什么问题，但用户希望能够灵活地在任意环境中运行流式处理。Samza 1.0 通过提供独立运行模式来解决这个问题。
这种模式允许将 Samza 作为库嵌入到应用程序中，并在任意资源管理器中运行。但还存在几个问题：独立模式还不支持像窗口和连接这样的有状态流式处理，并且对 Kubernetes 的支持还不够。Samza 团队正在努力解决这些问题。Samza 1.0 还支持表和流的连接，并改进了 Samza 应用程序的可测试性。
Samza 1.0 带来了巨大的改进。它背后的团队似乎意识到它的短板，并努力解决这些问题。他们也意识到了它的优势，例如 Samza 在一台机器上每秒可以处理 120 万条消息。
但问题是你应不应该使用它？如果你确信自己可以搭建、开发、部署和维护它，那么绝对值得一试。
但无论你是否会使用它，Samza 1.0 都是一个重要的里程碑。因为在 Apache Beam 似乎陷入僵局的时候，Samza 拉了它一把。并非每家公司都会像 LinkedIn 那样，并非每家公司都有建立和维护自己的框架的必要。但在目前看来，基于 Beam 进行开发似乎是可移植性方面的最佳选择。
Samza 1.0 发布详细公告：
https://engineering.linkedin.com/blog/2018/11/samza-1-0--stream-processing-at-massive-scale
英文原文：
https://www.zdnet.com/article/real-time-data-processing-just-got-more-options-linkedin-releases-apache-samza-1-0-streaming/
今日彩蛋
实时流计算可以说是现在大数据领域最火的技术关键词，以 MapReduce 为大数据的缘起，流式处理是如何发展到今天的这幅模样？你可以在 AI 前线 后台回复关键词：流处理，获取干货文章，进一步了解大数据系统发展的历史轨迹。