记录一次流处理引擎选择的过程

先描述下项目需求，要处理的消息来源为RabbitMQ的队列A，队列A的数据是10万个点位（物联网采集点）数据每秒一次推送产生的，现在的需求是：要新增一些虚拟计算点位，点位建立规则是已有物理点位的计算表达式，比如V001为P001+2*P002。每个计算点位的计算间隔不一样。需要计算的点位数大概有上万个。

为了快速的计算这些计算点位，推送到客户端，我们需要一个分布式的流计算引擎作为基础。下面描述一下如何从可选的三个流计算引擎（Spark Streaming、Kafka Streaming和Flink）中做出最终的选择，希望能给你一些借鉴。

1、Spark Streaming

Spark Streaming官方不支持RabbitMQ作为Source和Sink，可以自定义实现，但是由于要考虑数据一致性，至少要实现At Least Once，实现会稍微复杂，容易出错，后续升级维护也会有问题。官方支持可用的消息队列只有Kafka。Kafka自带Streaming功能，在Kafka Steaming章节中详述。如果改造成Kafa后，Spark Streaming本身的功能能够满足，我们需要的流处理框架实际上是基于窗口的批处理，和Spark Streaming的设计正好吻合。

2、Kafka Streaming

既然决定使用Kafka，那么Kafka Streaming也成为流处理框架的备选项。Kafka Steaming实际上作为流处理框架已经比较成熟了，从Kafka 1.0开始到现在的Kafka 3.0，一直提供了基于Kafka流处理的框架Kafka Streaming。其好处在于：

• 轻量级框架，不用引入多余的服务，作为库集成在应用中，中间数据使用Kafka来存储。轻量级的优点是我们考虑Kafka Streaming的主要原因，对于受限资源的三台服务器，引入越少的服务越好，而且我们对于Streaming的功能要求并不要，只要能具备检查点、分布式处理、低延时、有基本计算算子等要求即可。
• 完全的流处理，能够支持Exactly Once数据一致性要求。不过这个功能对我们来说不是必须的，而且只支持事件粒度的流处理也给实现带来了麻烦。

基于上面的优点，我们依据项目需求使用Kafka Streaming进行了原型验证开发，但实现下来后，发现如下问题：

• 存在大量的中间结果在Kafka队列里，由于Kafka Streaming是基于Kafka实现的，轻量化的同时也带来了一些限制，对于常用的分组聚合计算，每次都要生成reparition和changelog队列数据，而Kafka Streaming和Flink中，这些数据在本地磁盘，无疑对性能有很大的影响。
• 不支持批量处理。对于我们的需求，实际上是要聚合一端时间窗口的数据后进行一次计算，本质上是连续的批处理，Spark Streaming和Flink都支持，但是Kafka Streaming只支持事件级的依次处理，而且每次处理的结果都要作为state数据保存在kafka队列里，这样反复的序列化域反序列化对于连续的小批量处理是一种极大的浪费。
• GKTable只支持changelog的Table。Kafka Streaming认为Table是对于changlog的一种重放，对于重复Key的两条数据会认为后者是前者的修改，但是在数据处理过程中，中间数据不可避免的会出现重复Key的数据。这样使得Join功能被大大限制了。

综上，我们慢慢不倾向于使用Kafka Streaming，即便是这么轻量的流处理框架。当然，最终的原因还是Flink更加合适。

3、Flink

Flink是最新一代的流处理框架。首先其种类繁多的Connector就让你觉得这个生态极其丰富，其中RabbitMQ的支持就在其中，虽然对于Exactly Once的数据一致性要求有很多的条件，但是我们的应用在处理是自动处理了重复数据的问题，所以在满足性能的前提下保证At Least Once的一致性就够了。

使用Flink虽然带来了新的服务组件，不过相比于Kafka Streaming的轻量化需要Kafka这个较重的消息队列，实际上是一种对换。Kafka需要Zookeeper，而新的KRaft官方不建议用于生产环境，实际也确实存在查询Broker状态不方便等问题。更重要的使用Flink，让我们可以继续使用RabbitMQ，这样使得原有的很多业务不需要更换RabbitMQ为Kafka，虽然我们使用的Spring Cloud Streaming屏蔽了这个差异，能让我们较快的完成替换。

使用Flink的额外好处在于它对于未来需求的支持，而且使用Standalone Session的部署能够较轻量的用于生产环境。

最后

最终我们选用了Flink作为流计算引擎。没有最好的技术，只有最适合的。技术决策的结果就是在不同的取舍里产生的。你完全可以有不同的选择，前提是你非常清楚选择给你带来得好坏。祝你好运~