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在流处理领域确实还是很优秀的。