本篇内容介绍了“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进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
