您好,登录后才能下订单哦!
本篇内容介绍了“spark和flink对比哪个好用”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
开头还是那句话,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对比哪个好用”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。