扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
本篇内容介绍了“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对比哪个好用”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流