?????? flinksql ????orc????????
ORC?? ?? -- -- ??: "user-zh"
Re: Re: Flink任务每运行20天均会发生内部异常
Hi 数据量骤降的时候，观察作业是否存在反压，是否是状态后端在数据量增大后跟不上性能所致。 祝好 唐云 From: mayifan Sent: Tuesday, October 26, 2021 19:21 To: user-zh@flink.apache.org Subject: Re: Re: Flink任务每运行20天均会发生内部异常 非常感谢大佬的答复： 目前从任务来看的话总共存在三个任务，其中两个异常任务分别使用了1到2个MapState，过期时间均为1天或3天。 正常运行的任务使用了MapState及ListState各4个，过期时间为60min-120min。 异常任务在产生异常后从checkpoint重启又会恢复正常。 > -- 原始邮件 -- > 发 件 人："Caizhi Weng" > 发送时间：2021-10-26 18:45:44 > 收 件 人："flink中文邮件组" > 抄 送： > 主 题：Re: Flink任务每运行20天均会发生内部异常 > > Hi！ > > 听起来和 state 过期时间非常有关。你配置了哪些和 state 过期相关的参数？是否有 20 天过期的 state？ > > mayifan 于2021年10月26日周二 下午4:43写道： > > > Hi！ > > > > 麻烦请教大家一个问题。 > > > > > > 有三个Flink任务以yarn-per-job模式运行在Flink-1.11.2版本的集群上，均使用RocksDB作为状态后端，数据以增量的方式写入RocksDB，且均配置了状态过期时间。 > > > > > > 任务逻辑大致都是通过状态与历史数据进行自关联或双流join，每输入一条数据都会产出等量、1/2或多倍的数据到下游，当数据无法通过状态关联，任务则无法向下游产出数据。 > > > > > > 奇怪的是三个任务中有两个任务存在异常，异常现象是每次当任务启动运行至第20个工作日，都会非常准时的产生下游数据输出骤降的现象，输出与输入的数据量级差数十倍，并且此时任务中没有任何异常日志。 > > > > > > > > > > 问题：目前怀疑是集群配置或RocksDB状态的问题，但是没有任何思路或排查线索，请问这种现象是怎样产生的？应该怎样排查？
Re: flink 以阿里云 oss 作为 checkpoint cpu 过高
Hi 可以使用jstack，async profiler [1] 等工具勘察一下checkpoint期间的CPU栈。oss需要先写本地再上传，确实可能CPU消耗多一些，但是明显高很多有一些超出预期。 [1] https://github.com/jvm-profiling-tools/async-profiler 祝好 唐云 From: Lei Wang Sent: Tuesday, October 19, 2021 14:01 To: user-zh@flink.apache.org Subject: Re: flink 以阿里云 oss 作为 checkpoint cpu 过高 确实是跟 OSS 有关，我换成 HDFS 作为 checkpoint 后端就没有这种现象了，但我也不明白为什么会这样。 程序中设置了增量 checkpoit，但 flink web UI 中显示的 checkpoint data size 一直不断变高，三天就到了 1G On Mon, Oct 18, 2021 at 10:44 AM Michael Ran wrote: > 应该和OSS没关系吧，毕竟只是个存储。 > 我们CPU 你先看看消耗在哪个线程或者方法类呗 > > > > 在 2021-10-08 16:34:47，"Lei Wang" 写道： > > > > flink 程序以 RocksDB 作为 stateBackend， aliyun OSS 作为 checkpoint 数据最终的物理位置。 > 我们的监控发现节点 cpu 间隔性地变高，这个间隔时间恰好就是程序的 checkpoint 时间间隔。 > > > > > > > 这个可能的原因是什么？会跟 OSS 有关吗？ > > > 谢谢， > 王磊
Re: 关于作业失败从checkpoint重启，触发了过期的窗口计算
Hi， 先问个版本问题，你的Flink版本是1.3 而不是1.13？ Checkpoint里面会存储timer，所以重启之后会触发窗口的计算，但确实这种一天的窗口累计有点太多了，除非你的作业存在比较严重的反压，导致checkpoint内积攒了大量没有触发的timer。 祝好 唐云 From: claylin <1012539...@qq.com.INVALID> Sent: Friday, October 29, 2021 11:33 To: user-zh Subject: 关于作业失败从checkpoint重启，触发了过期的窗口计算 作业失败后从checkpoint重启，重启后会触发之前已经过期的时间窗口计算，求问这个该怎么解决。我的运行环境是flink1.3/1.4+sql举例：作业每小时做一次checkpoint，状态设置了1小时过期，状态后端使用rocksdb，同时使用了一天的滚动时间窗口，然后今天15点30分重启，但是重启后会有昨天的窗口计算结果触发。 按理说不应该会触发已经过期的窗口计算，而且flink 1.3/1.4 下 state.backend.rocksdb.timer-service.factory 这个配置默认是rocksdb， 也就是说rocksdb里面存储了状态的有效时间， 不管怎么样也不应该触发已经过期的窗口计算， 请问大家有没有遇到过这种问题，怎么解决。
回复: flink sql消费kafka各分区消息不均衡问题
Hi casel.chan： 请问你是sink端数据不均衡还是source端数据不均衡。 如果是写入端 ，看看你是否自定义了分区字段，flink 默认是策略应该不会造成数据不均衡，但是无法保证 分区有序性。同时也可以关注下 下游消费者 是否会有消费不同分区 处理性能不同问题。 --- Best, WuKong 发件人： casel.chen 发送时间： 2021-10-29 09:30 收件人： user-zh@flink.apache.org 主题： flink sql消费kafka各分区消息不均衡问题 flink sql消费kafka消息做数据同步，前期没有出现堆积不均的问题，这两天发现某些kafka分区积压特别多，会是什么原因造成的？怎样解决呢？从统计结果上看，消息还算均匀地打到各个kafka分区上。作业没有开窗和聚合，只是攒一批写一批这样子的。注：作业是跑在k8s上的 | 分区 ID | 客户端 | 最大位点 | 消费位点 | 堆积量 | | 0 | n/a | 155,397,108 | 155,396,747 | 361 | | 1 | n/a | 155,215,444 | 155,215,108 | 336 | | 2 | n/a | 155,369,596 | 155,369,258 | 338 | | 3 | n/a | 155,422,750 | 155,422,337 | 413 | | 4 | n/a | 155,163,343 | 154,489,738 | 673,605 | | 5 | n/a | 155,401,388 | 154,702,173 | 699,215 | | 6 | n/a | 155,372,040 | 154,651,398 | 720,642 | | 7 | n/a | 155,208,461 | 154,528,301 | 680,160 | | 8 | n/a | 155,383,486 | 154,696,404 | 687,082 | | 9 | n/a | 155,391,068 | 154,668,426 | 722,642 | | 10 | n/a | 155,139,417 | 154,450,377 | 689,040 | | 11 | n/a | 155,411,848 | 155,411,518 | 330 |
??????????
-- -- ??: "sh_0...@126.com"
退订
sh_0...@126.com
Re: 一些关于flink rabbitmq connector的疑问
Thanks @Qingsheng and @Leonard. Let's work together to improve the quality of different connectors. Regards. On Fri, Oct 29, 2021 at 2:39 PM Qingsheng Ren wrote: > Hi Ken, > > Thanks for reaching out and sorry for making confusion! > > Like Leonard mentioned we definitely honor every connector in Flink > community. And under the situation that we have more and more connectors to > maintain and limited guys and resources focusing on connector-wise issues, > some connectors like Kafka and JDBC might receive more support. > > I’m very glad to see that RabbitMQ connector has a lot of active users, > and also will be appreciate if friends from RabbitMQ side could help us > improve RabbitMQ connector, like migrating to FLIP-27 Source API and > FLIP-143 Sink API~ > > 感谢联系，也很抱歉之前的表述产生了误解！ > > 如 Leonard 所说我们重视 Flink 社区中的每一个 connector。考虑到目前我们有越来越多的 connector > 需要维护，并且专注于 connector 的人手和资源都比较有限，有些像 Kafka 和 JDBC 这样的 connector 可能会获得更多的支持。 > > 非常开心能看到 RabbitMQ connector 有如此多的活跃用户，也希望来自 RabbitMQ 社区的朋友能够帮助我们改进 RabbitMQ > connector，比如迁移至 FLIP-27 Source API 和 FLIP-143 Sink API～ > > > > > 2021年10月29日 下午12:52，Leonard Xu 写道： > > > > Hi, Peng > > > > There’s no doubt that RabbitMQ is a good open source community with > active users. > > I understand what @renqschn means is that Flink RabbitMQ Connector is > one connector with few users among the many connectors in the Flink > project. From my observation, the connector that is used more in the Flink > project should be Kafka. Filesystem, JDBC and so on. So, please help us to > promote Flink in the RabbitMQ community and let more RabbitMQ users know > and then use the Flink RabbitMQ Connector, which will give the Flink > community more motivation to improve the Flink RabbitMQ Connector. > > > > Best, > > Leonard > > > >> 在 2021年10月29日，11:13，Ken Peng 写道： > >> > >> I am one of the Forum Moderators for RabbitMQ, which does have a lot of > >> active users. :) > >> If you have any questions about RMQ please subscribe to its official > group > >> and ask there. > >> rabbitmq-users+subscr...@googlegroups.com > >> > >> Regards. > >> > >> > >> On Fri, Oct 29, 2021 at 11:09 AM 任庆盛 wrote: > >> > >>> 您好， > >>> > >>> 从代码来看 RabbitMQ Sink 的确没有语义保证。目前 RabbitMQ > >>> 由于社区用户不多，相对的维护频率也比较低，如果感兴趣的话也欢迎您参与社区的贡献～ > >>> > >>> > >>> > 2021年10月28日 下午7:53，wx liao 写道： > > 你好： > > >>> > 冒昧打扰，最近项目在使用flink,sink端是rabbitmq,但是查看项目源码发现RMQSink好像并没有对消息不丢失做保证，没有看到有使用waitForConfirm()或者是confirm > >>> listener,想问一下RMQSink部分是否没有保证at least once?希望可以得到解答，谢谢。 > >>> > >>> > > > >
