码迷,mamicode.com
首页 > 其他好文 > 详细

spark比flink好用的点

时间:2019-09-05 21:45:24      阅读:133      评论:0      收藏:0      [点我收藏+]

标签:tables   mys   出现   kafka集群   生产   strong   高性能   反序   导致   

也还是继续昨天的话题说吧。

纯手机手打,感觉有用麻烦点个赞。

开头还是那句话,spark是以批处理起家,发展流处理,所以微批处理吞吐优先,可以选用。

flink以实时处理起家,然后去做批处理,所以更适合实时性高的场景。

那么生产中真的都要求那么高的实时性吗?

比如10wqps的数据,假如实时处理,采用flink,sink是mysql,实时性高,事件驱动,每条都去插入或更新数据库,明显不靠谱,因为数据库扛不住。

假如此事你想在flink的sink处加上批处理,肯定是可以提高性能的,这就降低了实时性,而且也还有一个问题:

假如此事业务进行迁移,迁移到新的topic或者kafka集群,数据迁移之后,迁移flink任务。你会发现,假如最后一个批次没有达到批大小阈值,数据就不会刷出进而导致数据丢失了,因为没有新数据写入,不会触发sink往外刷新。

此种场景,还是要加一个超时检测线程,超时一定时间,进行刷出数据。

是不是颇为麻烦。

所以,其实,很多时候实时性可能也没那么重要。

还有就是spark streaming已然极其稳定了,flink的bug比较多。

举一个kafkajsontablesource的bug吧,就是数据格式是json的话,可以直接反序列化,解析注册为row,但是假如有一条数据不是json,那么就会导致flink任务挂掉,因为flink内部算子实现的是仅一次处理,不处理了这条数据不罢休。spark就不会出现。

还有一些就不列举了。

但是对于研发来说,都掌握还是最好的,而且flink在流处理领域确实还是很优秀的。

spark比flink好用的点

标签:tables   mys   出现   kafka集群   生产   strong   高性能   反序   导致   

原文地址:https://www.cnblogs.com/niejingsong/p/11469946.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!