也还是继续昨天的话题说吧。
纯手机手打，感觉有用麻烦点个赞。
开头还是那句话，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在流处理领域确实还是很优秀的。