对的是我!
2021年12月
保存中间变量可以用状态存*来自志愿者整理的flink邮件归档
从报错信息看是超时了,看看client与 JM 之间的网络是否通常把。*来自志愿者整理的flink邮件归档
这个问题是在1.12.1中修复的,1.12.0里面还不能支持给TM设置ServiceAccount 具体可以看下这个ticket,https://issues.apache.org/jira/browse/FLINK-20664
另外,1.12.1正在投票,最近就会发布*来自志愿者整理的flink邮件归档
为啥不用天级别的tumble window? 自动就帮你清楚 state 了*来自志愿者整理的flink邮件归档
我的也是flink 1.11.0版本的,也是使用的stmtSet.execute()方式,是可以正常运行的,你可以debug检查一下你要执行的SQL语句*来自志愿者整理的flink邮件归档
开启cleanFullSnapshot 并不会物理清除数据,只是确保checkpoint数据中没有相关过期数据*来自志愿者整理的flink邮件归档
是的哦,目前没有全局的配置*来自志愿者整理的flink邮件归档
你本地的数据肯定是过期了,checkpoint size没有变化是因为你的数据总量83MB,且之后没有插入新数据,导致没有触发RocksDB的compaction,所以本地的数据没有物理上清理,而在full snapshot时候,估计你并没有开启cleanFullSnapshot [1],所以导致full snapshot时候并没有删除掉过期数据。
其实你可以查询一下状态,默认情况下,已经过期的数据是无法再查询到了。
建议开启增量checkpoint即可,过期数据即使物理不删除,也因为过期而无法再读取到了,没必要过分关注UI上的checkpoint size。
[1] https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/state.html#cleanup-in-full-snapshot*来自志愿者整理的flink邮件归档
下游sink还没有完成, offset 不是在checkpoint 里面的吗?
下次启动会从你ck的位置恢复才对。
除非你sink 是异步操作,告诉上游你sink 完成了,实际你sink失败了 *来自志愿者整理的flink邮件归档
可以参考 zeppelin的方法,zeppelin支持多个版本的flink (1.10, 1.11, 1.12)
https://www.yuque.com/jeffzhangjianfeng/gldg8w/bam5y1 https://github.com/apache/zeppelin/tree/master/flink *来自志愿者整理的flink邮件归档
这种情况一般是kafka的某个分区,不存在数据,导致总体的watermark不前进。遇到这种情况一般是需要手动设置idle source[1]。但是社区的watemark push down存在一些问题[2],已经在修复了。
[1] https://ci.apache.org/projects/flink/flink-docs-master/dev/table/config.html#table-exec-source-idle-timeout [2] https://issues.apache.org/jira/browse/FLINK-20947?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel*来自志愿者整理的flink邮件归档
只要sliding出来才满足你每分钟执行的滑动要求吧?至于你只要最早/新的某一条,你可以从window groupby得出的流再次group by然后再用window时间筛选你要的数据。*来自志愿者整理的flink邮件归档
目前对于一些不是经常使用的功能,社区打算使用pod template来统一支持 我理解应该是可以满足你的需求的 这样更加灵活,也会有更好的扩展性,具体你可以看一下这个JIRA[1]
已经有了一个draft的PR,会很快在完成后提交正式PR,然后review 你也可以先试用一下,有问题及时反馈
[1]. https://issues.apache.org/jira/browse/FLINK-15656 *来自志愿者整理的flink邮件归档
key和value都是你自己设置的,看你需要设置什么类型哈。这个不是强制的。 你的map state的key和value在具体业务场景下需要什么类型,那个地方就设置什么类型的TypeInformation,懂吧。*来自志愿者整理的flink邮件归档
看着是Watch的时候报错了,你的K8s环境是怎么样的,如果Pod和K8s APIServer的网络状况不是很稳定会导致这个问题的 我这边在minikube和阿里云的ACK集群都做过测试,长时间运行(超过一周)并没有出现too old resource version等引起的JM重启 鉴于好几个人都反馈有这样的问题,会在1.12的下个bug fix(1.12.2)版本修复一下*来自志愿者整理的flink邮件归档
制就是这样的。如下是我之前做过的测试。 启动后等待若干检查点之后做如下操作文件系统上的检查点是否保留说明 WEB UI 点击 Cancel 方式取消任务 保留 合理,因为设置了 RETAIN_ON_CANCELLATION。 通过命令生成保存点:flink savepoint ${jobId} ${savepointDir} 保留 OK 通过命令取消任务:flink cancel ${jobId} 保留 OK 通过命令取消任务并生成保存点:flink cancel -s ${savepointDir} ${jobId} 保留 OK 通过命令停止任务(基于默认保存点目录):flink stop ${jobId} 不保留 注意别被特点坑 通过命令停止任务并生成保存点:flink stop -p ${savepointDir} ${jobId} 不保留 *注意别被特点坑 **来自志愿者整理的flink邮件归档
我们当前的实现是,每分钟调用yarn的rest api 获取作业状态,和实时计算平台上的作业状态对比,如果挂掉就电话报警,同时平台上作业状态修改为运行异常。 *来自志愿者整理的flink邮件归档
在Yarn部署的时候是依赖log4j.properties这个文件名来ship资源的,所以不能手动指定一个其他文件
但是你可以export一个FLINK_CONF_DIR=/path/of/your/flink-conf环境变量 在相应的目录下放自己的flink-conf.yaml和log4j.properties*来自志愿者整理的flink邮件归档
Sink 到内存里,然后你自己处理(print出来还是发送到web前端) 可以参考zeppelin源码 https://github.com/apache/zeppelin/tree/master/flink *来自志愿者整理的flink邮件归档
不是savepoint恢复任务的话,flink-kafka-connector会按照配置的消费策略来确定 Kafka 分区的起始位置。*来自志愿者整理的flink邮件归档