记录下Flink开发过程中遇到的一些坑(持续更新)
以下记录的问题,Flink版本为1.10.0,Kafka版本为0.10.0.1。有些问题至今不知道原因是啥,如果有朋友知道的话,麻烦和我说下呗,感谢感谢!1.setStartFromEarliest不起作用在IDEA中调试,消费Kafka的数据,然后发现setStartFromEarliest不起作用,Consumer显示默认的offset还是latest。通过Con...
以下记录的问题,Flink版本为1.10.0,Kafka版本为0.10.0.1。有些问题至今不知道原因是啥,如果有朋友知道的话,麻烦和我说下,感谢感谢!
1. setStartFromEarliest不起作用
在IDEA中调试,消费Kafka的数据,然后发现setStartFromEarliest不起作用,Consumer显示默认的offset还是latest。通过Consumer中设置auto.offset.reset为earliest解决该问题
2. 闭包问题,导致程序无法运行
对DataStream进行null值过滤,即使用filter(x -> x != null),然后手贱点了下IDEA的自动优化,将代码改为filter(Objects::notNull),然后代码就不能正常消费了,后续改回来,又能正常消费了。
3. 两条流时间同步问题
业务上需要讲两条流相同时间段的数据汇聚在一起进行计算,并且我们的业务明确是不会出现数据乱序的问题。
之前的做法是先将两条流进行connect,然后一起设置WaterMark,再使用WindowFunction对同一时间窗口内的数据进行计算。实际运行过程中发现,由于数据肯定会先后到达的关系,而且还是两条流,所以出现了其中某一条流的数据达到了,另外一条流中的数据才到了60%...后面更改了下策略,先分别对两条流设置WaterMark,然后再进行union和window,两条流便不存在不同步的问题了。
后续分析下数据是如何分配到Window中以及WaterMark是如何流动的流程。
4. 还是闭包问题
在使用类似map算子时,有些时候写lambda表达式会报闭包错误,类型推断不出来,这个时候得使用匿名函数.....谨慎让IDEA帮你简化你的代码
5. Flink Job一直消费Kafka中同一批数据
debug了下,发现是程序发生异常了!但是这个异常在日志里面没看到...日志刷的太快,导致没看到。
6. 千万不要使用1.10版本的standalone
任务反复提交和Cancel会引起Metaspace内存一直扩大且无法被回收。
[FLINK-16408] Bind user code class loader to lifetime of a slot - ASF JIRA
升级版本到Flink1.11.0解决该问题
7. 任务失败也会导致Checkpoint的失败
建议此时查看日志,定位下问题在哪。Checkpoint失败可以查看JobManager的日志,然后定位出错的地方并修复。
8. Checkpoint默认保存在内存中,此时不宜保存太大的状态
建议此时查看日志,定位下问题在哪。Checkpoint失败
8. Per Job提交任务到Yarn上失败
注释掉flink-conf.yaml中的rest.port这个选项
要为有状态算子显式设置UID
不然Flink会默认设置一个UID,但是当作业拓扑发生变动时,默认的UID会改变,导致Flink会无法从旧的Savepoint中读取出状态。 用户可以再提交的时候选择 --allowNonRestoredState来强制回复启动,但是尽量别这样做。
要开启 Externalized Checkpoint + 设置作业重启作业
比起一般的Checkpoint区别在于其存储了Job Manager的元数据,即使Job Manager挂了仍可对作业进行恢复。 同时设置RETAIN_ON_CANCELLATION,防止作业卡死时停止作业会有丢失作业状态的风险。
Kafka Source开启Partition Discovery
防止Kafka Topic扩容那个时,读取不到新Partition中的内容。 有一个现实场景就是写入Kafka的时候,原先写入Kafka Partition数量太少了,需要扩容提高写入性能。这个时候下游的Flink作业如果不设置Parttion Didcovery的话,会读取不到部分数据。设
Flink 1.15之前的参数为: flink.partition-discovery.interval-millis
Flink 1.15之后的参数为: partition-discovery.interval.millis
ps: Flink 1.14是最后一个支持Java8的Flink版本
Kafka Sink使用默认的Partitioner时,并行度的数量要比Partition的数量大,不然某部分Partition会一直没有数据写入:
使用默认Partitioner情况下,每个Flink Task会固定写一个Partition,如果Flink Task数量小于Partition数量,那么就会有部分Partiton一直接受不到数据。
更多推荐
所有评论(0)