apache-flink
您好! 我们在使用flink-1.12.0-scala2.12版本时遇到以下问题无法解决: 1、flink作业一切正常运行一个月左右时莫名重启,且重启失败。 2、重启前10分钟整看不到一条业务日志,从最后一条正常业务日志至第一条重启开始日志之间刚好间隔10分钟,此10分钟内jobmanager与taskmanager均无任何日志。 3、重启原因日志日志中没有任何信息,只是报出开始重启。 4、重启因为checkpoint未完成而无法成功,自动重启尝试多次均是如此。 5、以flink on yarn模式部署使用(hadoop版本2.6.5),查看yarn-nodemanager日志可见container异常退出,退出码:143。 6、作业处理数据tps在2万左右,正常时间查看日志及各项指标均正常,作业中未使用窗口或状态缓存等操作,均是每条消息处理后发往下游。 7、作业有监听zookeeper,zookeeper中存放了该作业所需配置且配置可能随时更改,zookeeper中配置更改则此flink作业自动重新从flink中拉取并更新内存中的配置。 8、此作业之前曾在flink-1.11版本同样on yarn运行1年左右,未出现同样问题。 每次都是长时间运行后出现问题,故测试环境复现困难,且日志信息很少,感觉无从下手,望各位专家解答困惑。 -- 杨扬 银联数据服务有限公司 研究院 电话:021-60269751 邮箱:yangya...@cupdata.com
Re: akka.framesize配置问题
您好。 报错没有影响Flink任务正常运行,而且所有作业均在每天固定时间4点30分左右报错,比较符合您所说的情况。 但是还想请教下外部非预期的API请求,必须是访问了Flink服务的相关端口才有可能出现这个问题吧? > 在 2022年8月19日,下午4:37,Weihua Hu 写道: > > Hi, > > 看这个报错没有影响 Flink 任务的运行,不太像是 Flink 内部的通信。可以检查下是否有外部非预期的 API 请求(可能是安全的定期扫描?) > > Best, > Weihua > > > On Fri, Aug 19, 2022 at 3:31 PM 杨扬 <mailto:yangya...@cupdata.com>> wrote: > 各位大佬好! > 最近将升级flink至1.14.2版本后出现附件图片中告警,每天固定时间告警几次。 > 经过初步排查属于akka.framesize设置问题,默认值太小需要调大,但是感觉需要调大的过多了,想请教下直接调教至200M以上是否合理? > PS:使用 flink on yarn 模式,application模式启动。 > > > -- > 杨扬 > 银联数据服务有限公司 研究院 > 电话:021-60269751 > 邮箱:yangya...@cupdata.com <mailto:yangya...@cupdata.com> > > > > > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。
基于savepoint重启作业无法保证端到端一致性
各位好! 目前有一flink作业,source与sink均为kafka。 在换版时(未修改任何代码)基于官网文档命令,创建savepoint并停止作业;而后基于之前创建的savepoint启动作业。 现在发现如此操作无法实现启停前后数据无缝对接,会出现一定的数据重复。 想请教这个问题是savepoint设计时本身就无法保证启停前后端到端一致性,还是我们哪里操作不当呢?
Re: 基于savepoint重启作业无法保证端到端一致性
kafka-2.4.1 flink-1.14.2 > 在 2022年8月26日,下午4:42,Hangxiang Yu 写道: > > flink会保证自身的exactly once语义,端到端的exactly once的语义是需要source和sink保证幂等的; > 你用的kafka是哪个版本? > > On Fri, Aug 26, 2022 at 4:08 PM 杨扬 wrote: > >> 各位好! >>目前有一flink作业,source与sink均为kafka。 >>在换版时(未修改任何代码)基于官网文档命令,创建savepoint并停止作业;而后基于之前创建的savepoint启动作业。 >>现在发现如此操作无法实现启停前后数据无缝对接,会出现一定的数据重复。 >> >>想请教这个问题是savepoint设计时本身就无法保证启停前后端到端一致性,还是我们哪里操作不当呢? >> >> >> >> >> >> >> > > -- > Best, > Hangxiang. > > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。
Re: 基于savepoint重启作业无法保证端到端一致性
指定了,依然无法保证。 > 在 2022年8月26日,下午5:28,gulugulucxg 写道: > > flinkKafkaProducer指定EXACTLY_ONCE语义了吗 > > > > > > > > > > > > > > > > > > 在 2022-08-26 16:50:33,"杨扬" 写道: >> kafka-2.4.1 >> flink-1.14.2 >> >> >> >> >>> 在 2022年8月26日,下午4:42,Hangxiang Yu 写道: >>> >>> flink会保证自身的exactly once语义,端到端的exactly once的语义是需要source和sink保证幂等的; >>> 你用的kafka是哪个版本? >>> >>> On Fri, Aug 26, 2022 at 4:08 PM 杨扬 wrote: >>> >>>> 各位好! >>>> 目前有一flink作业,source与sink均为kafka。 >>>> 在换版时(未修改任何代码)基于官网文档命令,创建savepoint并停止作业;而后基于之前创建的savepoint启动作业。 >>>> 现在发现如此操作无法实现启停前后数据无缝对接,会出现一定的数据重复。 >>>> >>>> 想请教这个问题是savepoint设计时本身就无法保证启停前后端到端一致性,还是我们哪里操作不当呢? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Best, >>> Hangxiang. >>> >>> === >>> 此邮件已由 Deep Discovery Email Inspector 进行了分析。 >> > > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。
Re: 某作业计算算子处于busy状态
目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量1TPS左右,资源是足够的吧? > 在 2022年9月15日,下午7:27,yidan zhao 写道: > > busy那就提升并发度看看效果? > > 杨扬 mailto:yangya...@cupdata.com>> 于2022年9月15日周四 > 14:51写道: > 各位好! > 目前有一flink作业,大致分为3个阶段: > 读取kafka中数据(1个source,并行度3)-> 进行数据筛选和条件判断(没有窗口操作,并行度25)-> > 结果写入kafka(20多个sink,每个sink并行度3)。可参考附件图片。 > > 目前存在的问题是:作业在运行一段时间后,中间25并行度的一系列计算算子会变为busy状态(会达到50%以上),端到端的信息延迟增加,偶尔延迟会达到2秒以上。此时作业日志并没有报错、异常、告警等信息。 > > > 上述问题因为没有日志异常告警信息,本人有些无从下手解决。猜测是否因为sink数据量太多且每个sink并行度都是3会导致中间25个并行度的一系列算子和sink之间的交互产生大量shuffle引起?望各位大佬帮忙分析一下这个问题 > > > > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。
Re: 某作业计算算子处于busy状态
还有一个现象,观察到 taskHeap内存占用在逐步升高,作业刚启动的时候占用在10%左右,一周后增加至25%左右,两周后增加至50%左右,上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态,端到端延迟已经达到了10s左右,作业已经不可用需要重启了。 > 在 2022年9月15日,下午8:58,yidan zhao 写道: > > 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。 > > yidan zhao 于2022年9月15日周四 20:57写道: >> >> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。 >> >> 杨扬 于2022年9月15日周四 20:02写道: >>> >>> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量1TPS左右,资源是足够的吧? >>> >>> >>> >>> >>>> 在 2022年9月15日,下午7:27,yidan zhao 写道: >>>> >>>> busy那就提升并发度看看效果? >>>> >>>> 杨扬 mailto:yangya...@cupdata.com>> 于2022年9月15日周四 >>>> 14:51写道: >>>> 各位好! >>>> 目前有一flink作业,大致分为3个阶段: >>>> 读取kafka中数据(1个source,并行度3)-> 进行数据筛选和条件判断(没有窗口操作,并行度25)-> >>>> 结果写入kafka(20多个sink,每个sink并行度3)。可参考附件图片。 >>>> >>>> 目前存在的问题是:作业在运行一段时间后,中间25并行度的一系列计算算子会变为busy状态(会达到50%以上),端到端的信息延迟增加,偶尔延迟会达到2秒以上。此时作业日志并没有报错、异常、告警等信息。 >>>> >>>> >>>> 上述问题因为没有日志异常告警信息,本人有些无从下手解决。猜测是否因为sink数据量太多且每个sink并行度都是3会导致中间25个并行度的一系列算子和sink之间的交互产生大量shuffle引起?望各位大佬帮忙分析一下这个问题 >>>> >>>> >>>> >>>> === >>>> 此邮件已由 Deep Discovery Email Inspector 进行了分析。 >>> > > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。
Re: 某作业计算算子处于busy状态
flink内存泄漏有什么排查的指标或者工具吗? 比如大致定位泄漏的位置之类的。 > 在 2022年9月19日,下午5:41,yidan zhao 写道: > > 那你代码检查下有没有内存泄露呢。 > > 杨扬 于2022年9月19日周一 11:21写道: >> >> 还有一个现象,观察到 >> taskHeap内存占用在逐步升高,作业刚启动的时候占用在10%左右,一周后增加至25%左右,两周后增加至50%左右,上述指的是GC后观察到的内存占用值。两周后计算算子几乎一直100%busy状态,端到端延迟已经达到了10s左右,作业已经不可用需要重启了。 >> >> >> >> >>> 在 2022年9月15日,下午8:58,yidan zhao 写道: >>> >>> 本身低延迟一定程度上就是靠“资源低利用率”实现的。资源高利用率情况,就是尽可能满负荷够用就行的意思。 >>> >>> yidan zhao 于2022年9月15日周四 20:57写道: >>>> >>>> 资源足够,busy 50%+,延迟如果也可接受的话,其实就不算问题。2s延迟不算高。 >>>> >>>> 杨扬 于2022年9月15日周四 20:02写道: >>>>> >>>>> 目前并发度已经设定为25,每个slot内存为4G,已经使用100G内存,峰值流量1TPS左右,资源是足够的吧? >>>>> >>>>> >>>>> >>>>> >>>>>> 在 2022年9月15日,下午7:27,yidan zhao 写道: >>>>>> >>>>>> busy那就提升并发度看看效果? >>>>>> >>>>>> 杨扬 mailto:yangya...@cupdata.com>> 于2022年9月15日周四 >>>>>> 14:51写道: >>>>>> 各位好! >>>>>> 目前有一flink作业,大致分为3个阶段: >>>>>> 读取kafka中数据(1个source,并行度3)-> 进行数据筛选和条件判断(没有窗口操作,并行度25)-> >>>>>> 结果写入kafka(20多个sink,每个sink并行度3)。可参考附件图片。 >>>>>> >>>>>> 目前存在的问题是:作业在运行一段时间后,中间25并行度的一系列计算算子会变为busy状态(会达到50%以上),端到端的信息延迟增加,偶尔延迟会达到2秒以上。此时作业日志并没有报错、异常、告警等信息。 >>>>>> >>>>>> >>>>>> 上述问题因为没有日志异常告警信息,本人有些无从下手解决。猜测是否因为sink数据量太多且每个sink并行度都是3会导致中间25个并行度的一系列算子和sink之间的交互产生大量shuffle引起?望各位大佬帮忙分析一下这个问题 >>>>>> >>>>>> >>>>>> >>>>>> === >>>>>> 此邮件已由 Deep Discovery Email Inspector 进行了分析。 >>>>> >>> >>> === >>> 此邮件已由 Deep Discovery Email Inspector 进行了分析。 >> > > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。
sql查询数据库不走索引
各位好! 目前有一使用flink-sql编写的作业,其中存在通过jdbc查询mysql中某张表A需求,A表“b字段”为索引字段,但是flink-sql查询无法走到该表索引查询,为全表扫描查询。 代码类似于 CREATE TABLE A ( b decimal(4, 0), ..., ... ) WITH ( 'connector' = 'jdbc', 'url' = 'jdbc:mysql://100.191.200.10:/lldb', 'username' = 'test', 'password' = 'Test!123', 'table-name' = ‘A’ ) select * from A where b = 1234; 此时发送至数据库的查询为select * from A去掉了后面的where筛选条件,从而无法使用b字段索引查询,变为全表扫描。 此问题是否有办法解决呢?难道flink-sql是先在数据库中全表扫描,再在flink中执行筛选?这样数据库的查询效率极低。
Re: sql查询数据库不走索引
各位大佬好! 目前升级到了flink1.17+jdbc-3.0,经过测试依然没有实现谓词下推,想请教下这是为什么? > 在 2022年12月5日,下午3:05,rovo98 写道: > > 你好,请留意您使用的 flink 版本。在 flink 1.17, jdbc-3.0.0 版本之前,jdbc connector 没有实现 > SupportsFilterPushDown 接口(谓词下推),所以发送至数据库的查询是 select xxx from table_name > 的全表扫描形式。 > > > 如有需要可参考 FLINK-16024 对您使用的 jdbc connector 版本进行修改。 > > > > > https://issues.apache.org/jira/browse/FLINK-16024 > https://github.com/apache/flink/pull/20140 > > > -- 原始邮件 -- > 发件人: > "user-zh" > > 发送时间: 2022年12月5日(星期一) 下午2:43 > 收件人: "user-zh" > 主题: sql查询数据库不走索引 > > > > 各位好! > > 目前有一使用flink-sql编写的作业,其中存在通过jdbc查询mysql中某张表A需求,A表“b字段”为索引字段,但是flink-sql查询无法走到该表索引查询,为全表扫描查询。 > 代码类似于 > CREATE TABLE A ( > b decimal(4, 0), > ..., > ... > ) WITH ( > 'connector' = 'jdbc', > 'url' = 'jdbc:mysql://100.191.200.10:/lldb', > 'username' = 'test', > 'password' = 'Test!123', > 'table-name' = ‘A’ > ) > select * from A where b = 1234; > 此时发送至数据库的查询为select * from A去掉了后面的where筛选条件,从而无法使用b字段索引查询,变为全表扫描。 > > 此问题是否有办法解决呢?难道flink-sql是先在数据库中全表扫描,再在flink中执行筛选?这样数据库的查询效率极低。 > === > 此邮件已由 Deep Discovery Email Inspector 进行了分析。