五、现有流处理框架介绍
5.1 Storm
Storm是最老的流媒体框架，技术成熟可靠。社区也很活跃。ali还开发了jstorm，对storm进行了拓展完善。后续jstorm也融入到storm中，对于storm也是一个质的提升。比较适合于基于事件的一些简单用例场景。
优点：
极低的延迟，真正的流媒体，成熟和高吞吐量
非常适合非复杂的流媒体用例
缺点：
不支持状态管理
没有事件时间处理，聚合，窗口，会话，水印等高级功能
至少保证一次
5.2 Spark Streaming
Spark已经成为批处理中hadoop的真正继承者，也是第一个完全支持Lambda架构的框架。受到各大企业欢迎，并被广泛采用。2.0版本之后，Spark除了Structured Streaming之外，还配备了许多优秀的功能，如定制内存管理（与flink类似）tungsten、watermarks, event time processing支持等。结构化流也更抽象，并且可以选择在微批处理之间切换2.3.0版本中的连续流模式。连续流模式有望像Storm和Flink那样提供低延迟，但它仍处于初始阶段，需要在操作中进行测试。
优点：
支持Lambda架构
高吞吐量，适用于不需要低延迟的应用场景
由于微批次性质，默认情况下容错
简单易用的高级API
社区活跃，且积极的改进
数据处理有且只有一次
缺点：
不是真正的流媒体，不适合低延迟要求
要调整的参数太多。很难做到最好
在许多高级功能中落后于Flink
5.3 Flink
和Spark一样，Flink也支持lambda架构。但是这种方法和实现与Spark的方法和实现完全不同。虽然Spark实际上是Spark-Streaming作为微批处理和Spark Batch特殊情况的批处理，但Flink本质上是一个真正的流引擎，将批处理作为带有限数据的流的特殊情况。虽然两个框架中的API从开发人员的角度来看都很相似，但它们在实现中没有任何相似之处。在Flink中，map，filter，reduce等各个函数实现为长时间运行的运算符（类似于Storm中的Bolt）。
Flink看起来像是Storm的真正继承者，就像Spark成功批量使用hadoop一样。
优点：
开源流媒体领域的创新领导者
第一个真正的流媒体框架，具有Event Time Processing, Watermarksd等所有高级功能
低延迟，高吞吐量，可根据要求进行配置
自动调整，需要调整的参数较少，调优方便
数据处理有且只有一次
得到像阿里巴巴等大公司的广泛接受
缺点：
社区没有Spark那么大，但是正在快速增长
目前还没有采用Flink Batch，仅适用于流媒体。
5.4 Kafka Steams
与其他流式框架不同，Kafka Streams是一个轻量级的流式处理类库。它对于来自Kafka的流数据，进行转换然后发送回kafka非常有用。我们可以将它看作类似于Java Executor服务线程池的库，却内置了对Kafka的支持。它可以与任何应用程序很好地集成，并且可以开箱即用。
由于其重量轻，可用于微服务类型的架构。在与Flink的性能方面没有匹配，但同时不需要单独的集群运行，非常方便，非常快速，易于部署和开始工作。根据相关应用程序的性质，无论是分布式节点还是单个节点，Kafka Streams都能支持。
优点：
非常轻量级的库，适用于微服务，物联网应用
完全一次（kafka 0.11起）
具备kafka所有的优良特性
支持Stream连接，内部使用rocksDb来维护状态
缺点：
与Kafka紧密相连，不能在没有Kafka的情况下使用
技术较新，尚未得到广泛使用
不适用于较为复杂，繁重的任务
5.5 Kafka Streams vs. Spark Streaming
真 . 实时
我在Hadoop之后接触的第一个大数据框架就是Spark，所以自然而然曾经对Spark Streaming有着特别的偏爱。但Spark Streaming作为micro-batch结构，天生不是纯正的“真”实时处理。有着秒级别的延时，并且每次处理单个micro-batch中的所有数据记录。相对而言，Flink和Kafka Streams 则是真正意义上的实时处理，每次处理单个数据记录。
Kafka系统内的轻度处理
同时，当我在工作中频繁使用Kafka作为系统中的数据总线后，一些较为轻度的数据处理，比如 filter，aggregation， join 等，如果使用Spark Streaming，需要将Kafka topic中的数据导入Spark Streaming，结果处理后再重新导入Kafka中相应的topic，显得十分繁琐。
而使用Kafka Streams可以便捷地从源topic取得数据，处理并放入另一个topic，所有工作可以在Kafka内部完成。
不再需要单独集群
Kafka Streams 直接集成于Kafka，因此不需要单独的集群来支持其运行，这大大减少了额外的维护成本。
六、流式框架比较
我们只能将技术与同类产品进行比较。虽然Storm，Kafka Streams和Samza对于更简单的用例看起来很棒，但真正的竞争显然是具有高级功能的重量级框架之间的比较：Spark vs Flink
当我们在对两个框架做比较时，通常会用数据说话。而基准测试是比较两个框架的常用方法。Spark在2.0版本之前流式处理做的并不是很好，2.0之后提出了结构化流媒体功能，也在不断的提升。
既然是用数据说话，那么就需要得到相同场景下两者的测试数据，而获取测试数据，没有比做一个poc更好的方法了。
截至今天，看起来Flink正在引领Streaming Analytics领域，首先拥有大部分流处理所需的功能，如完全一次，吞吐量，延迟，状态管理，容错，高级功能等。Flink仍在不断创新，如轻量级快照和堆外定制内存管理。
直到某些时候，Flink的一个重要问题是成熟度和采用水平，但现在像优步，阿里巴巴，CapitalOne这样的大公司正在大规模使用Flink流媒体来证明Flink Streaming的潜力。 最近，优步开放了他们最新的流媒体分析框架，名为AthenaX，它建立在Flink引擎之上。
七、如何选择最好的/最适合的流失处理框架？
作为开发人员，我们不能偏向于任何框架。我们应该记住，没有一个处理框架可以成为所有应用场景的灵丹妙药。每个框架都会有一些优势和一些限制。下面将分享一些可能有助于做出决定的关键点。
7.1 使用场景
如果用例很简单，而学习和实现起来很复杂，就不需要使用最新的和最好的框架。很大程度上取决于我们愿意为我们想要的回报付出多少投资。
7.2 未来的考虑
在系统调研阶段，我们很多时候都会考虑未来可能的用例都有哪些？未来可能会出现Event Time Processing，aggregation，stream joins等高级功能的需求吗？如果答案是肯定的或可能的话，那么值得考虑具有Spark Streaming或Flink等高级功能的框架。一旦投资并在一种技术中实施，以后切换框架并不容易，因为它涉及大量的工作和时间。
7.3 现有的技术堆栈
考虑现有技术堆栈可以说是一个比较重要的一点，毕竟结合已有技术框架在实现难度以及效率上会提升不少。如果现有的管道已经利用了Kafka，那么Kafka Streams或Samza可能更容易适应。类似地，如果处理管道基于Lambda架构并且Spark或Flink已经用于批处理，则考虑Spark Streaming或Flink Streaming是有意义的。
八、总结
以上对什么是流处理/流媒体、流处理的分类、流处理框架以及如何选择一一做了介绍。
总结出来有几个点：
8.1 延迟要求高
毫秒级：storm、kafka steams、flink
秒级：flink、spark streaming
8.2 功能复杂度
高级功能需求：flink、spark streaming
功能简单：storm、kafka streams
8.3 现有技术堆栈
以上几个框架对kafka的支持都已经做的很好了
如果已经使用了flink或者spark做批处理，那么可以考虑直接用spark streaming或者flink streaming
8.4 未来的考虑
这点还是要具体问题具体分析，很多情况下，一个框架是无法解决所有的应用场景的，有时候拆分处理也不失为一个好的选择。
Ref
