AI前线导读：近日，LinkedIn正式发布了开源流式计算框架Samza的1.0版本。实时摄取和处理大量数据的能力对于越来越多的企业来说是一件非常有趣的事情。这是一个快速增长的领域，因为这些应用场景可以直接转化为商业利益。我们已经关注这个领域很长时间了，Apache Samza 1.0的发布是一个重新审视它的机会，我们拭目以待它将给这个领域带来哪些改变。
生于LinkedIn
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
英文原文：
扫一扫
807
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
