说几个flink好做spark却不好做的场景

经常有粉丝问我该选flink和spark streaming？

业务选型对新手来说是件非常困难的事情，对于经验丰富又经常思考的人来说就很简单。

选型的时候个人准备知识：

1.深入了解框架。

2.深入了解框架的周边生态。

3.深入了解你自己的业务场景。

就拿flink和spark streaming来说吧，要是理解其设计灵感就会很简单的理解该选谁：

spark 是做批处理起家，然后以微批的形式开创了流处理。使用场景很显而易见了，允许一点延迟，批量处理，吞吐量优先地，而且spark streaming贡献者这么多依然很稳定。

flink是以流处理起家，然后以流处理的灵感去创建批处理。那就很适合实时性高的场景了。目前还是存在bug的。

这样貌似还是很抽象，就以具体场景来说吧，flink好做而spark streaming不好做的：

1.全局去重，全局聚合操作，比如distinct ，uv等业务场景。flink适合，spark streaming做起来比较麻烦，后者要借助状态算子或者第三方存储，比如redis，alluxio等。

2.开窗操作且要求同一个窗口多次输出。这个可以用flink的trigger，spark streaming比较麻烦。

3.仅一次处理。spark streaming实现仅一次处理大部分都是依赖于输出端的幂等性。而flink，可以通过其分布式checkpoint的性质结合sink的事物来实现，也即分布式两段提交协议。当然，flink也可以利用sink的幂等性来实现仅一次处理。

4.更容易实现ddl，dml等完整的sql支持，进而实现完全sql实现业务开发，类似blink。spark streaming需要微批rdd转化为表，也是一个临时小表，不是全局的。

5.状态管理。flink可以方便地使用文件后端实现大状态管理，但是频繁发作也会引发linux系统操作文件的一些bug。当然，spark streaming可以灵活的使用第三方接口比如alluxio等也很方便。

6.小点。异步IO，测输出，迭代流等。强业务相关了。

还有什么场景需要补充，想起来再说吧。