针对 Flink 批处理能力现状怎么样？（与 spark 对比）

跑批还是用spark吧，flink反压那块会产生太多阻塞

1)flink datastream api 批处理走batch mode，针对 反压stage，可以细粒度 操控并行度 、slot group 、opertor chain 大概就能解决掉吧。
-- 最近看到 flink 1.15 新增的一个特性——批处理自适应调度器：可以根据 数据量的大小 ，自动推导并行度。
2）flinksql 批处理，针对反压stage, 如果部署在k8s上，利用弹性扩缩容特性，主动给更多资源呢？
@青牛

你好，我认为目前做批处理还是spark合适点。目前flink跑任务如果不开ck假如因为资源网络问题导致某个taskmanager挂了，整个作业就失败了。而spark跑任务executor挂了会另起一个节点接着跑。另外我觉得spark的rdd/dataframe更灵活点，比如调用缓存api更便捷点。flink虽然有算子chain合并优化序列化和网络io，但是在flinksql方式有些却不适合(datastream模式还好)，比如读取某个源的表5个并行度，去关联维表，记得默认是source和join算子chain在一起。如果不单独设置join并行度而数据量比较大的情况下，这个时候并行度设置更大合适点。flinksql目前似乎无法单独设置某个运行算子的并行度，这让用户使用起来不太好扩展。