Re: 如何监控kafka延迟

2021-07-28 文章 jie mei
sorry, metrics 项没复制全,应该是taskmanager_job_task_operator_KafkaConsumer_records-lag-max。 我们主要是通过 grafana 的图标来展现来监控延迟等信息,简单的报警页可以通过grafana来配置。细粒度到任务级别的报警,grafana配置起来有点繁琐,不过可能可以通过grafana 的 rest api 自动生成。 jie mei 于2021年7月28日周三 下午5:58写道: > hi,all > > 我们是通过 grafana 对采集到的 flink kafka 的

Re: 如何监控kafka延迟

2021-07-28 文章 jie mei
hi,all 我们是通过 grafana 对采集到的 flink kafka 的 metrics(taskmanager_job_task_operator_KafkaConsumer_records) 配置报警规则来报警的。 xuhaiLong 于2021年7月28日周三 下午5:46写道: > 参考下kafka_exporter,获取所有的 group 的消费情况,然后配置不同的规则去监控。 > > > 在2021年7月28日 17:39,laohu<2372554...@qq.com.INVALID> 写道: > Hi comsir > > kafka的控制台能力比较弱,想知道

Re: 分组滚动窗口 无法触发计算,由于 watermark 没有被生成,或者被计算。

2021-04-11 文章 jie mei
此外,在事件时间,场景下,如果一个 Stream A 有消息, 另一个 Stream B 没有消息进行 UNION ALL。那么 Stream B 的消息永远是一个 Long.MIN_VALUE, 进行水印对其的时候,UNION ALL 后的水印取所有 CHANNEL 的最小水印,也就是 Long.MIN_VALUE, 这就导致分组滚动窗口一致得不到计算。 jie mei 于2021年4月12日周一 上午11:24写道: > 问题已经解决,因为我的 StreamEnv 默认设置为事件时间。去掉就可以了,这导致了watermark没有生成。 > > jie mei

Re: 分组滚动窗口 无法触发计算,由于 watermark 没有被生成,或者被计算。

2021-04-11 文章 jie mei
问题已经解决,因为我的 StreamEnv 默认设置为事件时间。去掉就可以了,这导致了watermark没有生成。 jie mei 于2021年4月12日周一 上午1:49写道: > 大家好,我有一个 Flink 程序, 使用事件时间做分组窗口计算,但是无法触发窗口计算。我Debug到 WindowOperator, 下, > 发现 WindowOperator 的 TriggerContext中的当前水印一直是一个负数, StreamTaskNetworkInput 中的 > processElement 方法没有接受到 wat

分组滚动窗口 无法触发计算,由于 watermark 没有被生成,或者被计算。

2021-04-11 文章 jie mei
大家好,我有一个 Flink 程序, 使用事件时间做分组窗口计算,但是无法触发窗口计算。我Debug到 WindowOperator, 下, 发现 WindowOperator 的 TriggerContext中的当前水印一直是一个负数, StreamTaskNetworkInput 中的 processElement 方法没有接受到 watermark 消息, recordOrMark.isWatermark() == false。 我自己的怀疑难道是事件时间每设置对? 但是对比了文档,应该是可以的。下面是我的 DDL create table input_table ( `dim`

[讨论] Flink Connector 并行写入数据方案

2021-03-31 文章 jie mei
Hi, Community 我想发起一个初步的讨论,关于如何扩大 Flink 写入数据的并行度,并且能够分表,可选事务支持的方案。 该方案应该支持三种场景: 1) 至少一次: 不支持或者有限支持 update 的存储,通常通过查询去重。 例如 ClickHouse 2) 相同主键或分区内有序: 支持 Upsert,但不支持事务或者跨行事务的存储,例如 ElasticSearch, MongoDB 3) 事务:支持跨行事务的存储,例如 MySQL。 另外说一下,第二种情况和第三种情况的一个重要区别是,当 CheckPoint 失败,第二种情况会从上一个快照重新执行, 那么会存在旧的数据

Re: flink jdbc connector 在checkpoint的时候如何确保buffer中的数据全都sink到数据库

2020-12-09 文章 jie mei
所以at-least-once都不一定能保证。 > > 修复应该很简单的,@jie mei 你有兴趣帮忙修复吗? > > 祝好, > Leonard > > > > 在 2020年12月10日,11:22,jie mei 写道: > > Hi,Jark > > 好的,我会就此创建一个issue > > Jark Wu 于2020年12月10日周四 上午11:17写道: > >> Hi Jie, >> >> 看起来确实是个问题。 >> sink 返

Re: flink jdbc connector 在checkpoint的时候如何确保buffer中的数据全都sink到数据库

2020-12-09 文章 jie mei
gt; wrote: > > > Hi, > >是的,感觉你是对的。 > > `JdbcOutputFormat` 会被 wrap 在 `OutputFormatSinkFunction` 中,而 > > `OutputFormatSinkFunction` 没有继承 `CheckpointedFunction`,所以没法在 > snapshotState > > 时候调用format.flush。 > >WDYT @Jark @ Leonard > > >

flink jdbc connector 在checkpoint的时候如何确保buffer中的数据全都sink到数据库

2020-12-09 文章 jie mei
Hi, Community JDBC connector似乎无法确保buffer中的数据在checkpoint的时候全部入库。这是因为 OutputFormat中没有一个接口,供checkpoint的时候调用。 从JDBC的connector的 代码来看,只能设定一个超时时间用以刷新数据,但还是可能存在丢数据的case。 我的问题是:是否有办法强制刷新buffer中的数据入库? @Public public interface OutputFormat extends Serializable { /** * Configures this output format

动态表 Change Log 格式

2020-12-04 文章 jie mei
Hi, Community Flink 动态表的 Change Log 会有四种消息(INSERT, UPDATE_BEFORE, UPDATE_AFTER, DELETE). 其中 UPDATE_BEFORE 对应的是更新之前的完整记录,UPDATE_AFTER 对应的是更新之后的完整记录吗? 我的问题特意强调完整记录,是为了确认 Change Log 的内容是更新后的完整数据,而不是 Set A = 'a' 这样的操作日志/更新语句。 此外,Delete语句对应的数据是完整记录还是操作日志呢? 这意味着Table Sink的时候,只需要获得INSERT, UPDATE