本篇内容介绍了“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对比哪个好用”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
