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 进行了分析。
