说几个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,测输出,迭代流等。强业务相关了。
还有什么场景需要补充,想起来再说吧。
欢迎加入浪尖知识星球。
星球。