不一样的哈。不是一个层次的东西。
调度平台指的是在指定时间自动帮你提交某个任务，或者每天定时提交某个任务等。
后者是flink内部的机制，指提交任务后，这个任务的每个subtask应该使用哪台机器哪个slot去执行。
penguin. 于2021年1月7日周四 下午12:50写道：
> 赵一旦：
> 你说的任务调度平台是指通过这种平台来完全控制flink中的task到具体某个节点的调度吗？
> 我想的是flink自己内部的task到节点的调度。比如说通过修改flink现在的调度部分的代码来实现。
> 是不是这两种都可以用来实现 根据我们自己的需求来决定将task具体调度哪个节点中。
赵一旦：
所以目前是否有办法来实现在提交任务后，将这个任务的subtask调度到指定机器的某个slot来执行呢。
在 2021-01-07 12:57:35，"赵一旦" 写道：
>不一样的哈。不是一个层次的东西。
>调度平台指的是在指定时间自动帮你提交某个任务，或者每天定时提交某个任务等。
>
>后者是flink内部的机制，指提交任务后，这个任务的每个subtask应该使用哪台机器哪个slot去执行。
>
>penguin. 于2021年1月7日周四 下午12:50写道：
>
>> 赵一旦：
>>
能否 将集群部署在yarn上，然后通过实现yarn的接口来做呢？好像yarn是提供了一个可插拔的接口进行资源调度之类的。
在 2021-01-07 13:05:59，"赵一旦" 写道：
>没有的。
>
>penguin. 于2021年1月7日周四 下午1:04写道：
>
>> 赵一旦：
>> 所以目前是否有办法来实现在提交任务后，将这个任务的subtask调度到指定机器的某个slot来执行呢。
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 在 2021-01-07 12:57:35，"赵一旦" 写道：
>>
没有的。
penguin. 于2021年1月7日周四 下午1:04写道：
> 赵一旦：
> 所以目前是否有办法来实现在提交任务后，将这个任务的subtask调度到指定机器的某个slot来执行呢。
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 在 2021-01-07 12:57:35，"赵一旦" 写道：
> >不一样的哈。不是一个层次的东西。
> >调度平台指的是在指定时间自动帮你提交某个任务，或者每天定时提交某个任务等。
> >
> >后者是flink内部的机制，指提交任务后，这个任务的每个subtask应该使用哪台机器哪个slot去执行。
> >
>
我在知网的一篇论文中看到有作者做的flink任务调度，但是发了邮件很久也没人回复。
在 2021-01-07 10:21:27，"赵一旦" 写道：
>是的，之前有人给过我回复，说当前flink的调度信息不足，导致无法做到很理想的调度。
>
>penguin. 于2021年1月7日周四 上午10:11写道：
>
>>
>> 我在jira上看到好像有人在做，但是好像无法获取到更多的信息。也不知道他们是怎么做的。主要应该是找到进行任务调度那块的代码，不过源码注释好像很少，很困难。
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 在
我从kafka消费一条数据，然后将消息进行切分，再发送到下游的kafka中，但是这样不能保证在一个事务里面。
例如：我将一条数据切分成10条，然后再第五条的时候抛出一个异常，但是前四条已经发送到下游的kafka了。
我设置了事务id，隔离级别，client
id，enable.idempotence,max.in.flight.requests.per.connection,retries
但是没有效果。
--
Sent from: http://apache-flink.147419.n8.nabble.com/
Hi，
大家好，咨询一个问题，我们有个实时任务运行在Flink1.11.2版本，使用rocksdbstatebackend，最近报警出现了物理内存超限被kill的异常信息，我们查看了监控taskmanager
heap使用量没有超限，direct内存使用量也维持在一个平稳的范围内没有超限，也没有报oom，这种情况是非堆内存异常是吗？完整报错信息如下：
Dump of the process-tree for container_e06_1603181034156_0137_01_02 :
|- PID PPID PGRPID SESSID CMD_NAME
你说的是任务调度有2层含义。一种任务调度平台（这个很常见）。还是flink自身的task的schedule，这个是很复杂。
penguin. 于2021年1月7日周四 上午10:32写道：
>
>
>
> 我在知网的一篇论文中看到有作者做的flink任务调度，但是发了邮件很久也没人回复。
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 在 2021-01-07 10:21:27，"赵一旦" 写道：
> >是的，之前有人给过我回复，说当前flink的调度信息不足，导致无法做到很理想的调度。
> >
> >penguin. 于2021年1月7日周四 上午10:11写道：
目前现状：公司flink任务都是跑在flin1.7当中，通过公司开发的流计算平台进行提交到flink yarn集群，flink on yarn
基于flink
session进行部署，运行任务有接近500个流式任务，许多都是有状态应用，现在如果想把flink集群升级到1.11或者1.12，如何平滑的进行版本升级，而不影响现有的任务？
是的，之前有人给过我回复，说当前flink的调度信息不足，导致无法做到很理想的调度。
penguin. 于2021年1月7日周四 上午10:11写道：
>
> 我在jira上看到好像有人在做，但是好像无法获取到更多的信息。也不知道他们是怎么做的。主要应该是找到进行任务调度那块的代码，不过源码注释好像很少，很困难。
>
>
>
>
>
>
>
>
>
> 在 2021-01-06 13:06:20，"赵一旦" 写道：
> >我不是很清楚，不过难度应该很大，不然社区早改了。当前任务经常导致机器资源不均衡，这个问题很常见。
> >
> >penguin. 于2021年1月6日周三
谢谢回复，
听起来是可以的
我先尝试一下这种方案
-
Thanks!
Jacob
--
Sent from: http://apache-flink.147419.n8.nabble.com/
我在jira上看到好像有人在做，但是好像无法获取到更多的信息。也不知道他们是怎么做的。主要应该是找到进行任务调度那块的代码，不过源码注释好像很少，很困难。
在 2021-01-06 13:06:20，"赵一旦" 写道：
>我不是很清楚，不过难度应该很大，不然社区早改了。当前任务经常导致机器资源不均衡，这个问题很常见。
>
>penguin. 于2021年1月6日周三 上午11:15写道：
>
>> Hi，请问大家知道怎么更改flink默认的任务调度方式吗？
Flink 那个两个CVE的Patch 会打在1.10.4这个版本吗。目前修复版本是 1.11.3 1.12.0 ，很多生成还都在1.10 不好直接升级的。
Hi
可以使用 numRestarts [1]
指标进行报警，不过需要维护状态，也就是该值增大时报警。对于旧版本Flink，可以使用以及废弃的fullRestarts 指标。
[1]
https://ci.apache.org/projects/flink/flink-docs-stable/ops/metrics.html#availability
祝好
唐云
From: bradyMk
Sent: Wednesday, January 6, 2021 18:57
To:
赵一旦：
你说的任务调度平台是指通过这种平台来完全控制flink中的task到具体某个节点的调度吗？
我想的是flink自己内部的task到节点的调度。比如说通过修改flink现在的调度部分的代码来实现。
是不是这两种都可以用来实现 根据我们自己的需求来决定将task具体调度哪个节点中。
在 2021-01-07 12:24:42，"赵一旦" 写道：
>你说的是任务调度有2层含义。一种任务调度平台（这个很常见）。还是flink自身的task的schedule，这个是很复杂。
>
>penguin. 于2021年1月7日周四 上午10:32写道：
>
>>
Hi Luna,
可以找到对应的commit，将其修改cherry pick到自己的工程重新打包
祝好~
Luna Wong 于2021年1月7日周四 上午10:44写道：
> Flink 那个两个CVE的Patch 会打在1.10.4这个版本吗。目前修复版本是 1.11.3 1.12.0 ，很多生成还都在1.10
> 不好直接升级的。
>
我们当前的实现是，每分钟调用yarn的rest api 获取作业状态，和实时计算平台上的作业状态对比，如果挂掉就电话报警，同时平台上作业状态修改为运行异常
在 2021-01-06 16:35:05，"bradyMk" 写道：
>Hi，请教大家一个问题：
>
>目前使用grafana监控flink的作业，想实现一个任务挂掉就报警的功能，初步想法是：监控checkpoint
>size的指标，一旦这个指标为0，就认为任务挂掉，但实际操作后，发现了两个问题：
>
>① 如果kill掉任务，grafana上的flink所有指标都会一直保持最后接收到的值不变；
>②
snapshot阶段如果后端处理的慢，就容易反压，反压会造成debezium执行select * from xxx的时候会花较长时间。
这个报错一般是mysql本身的原因。出现通信错误的原因挺复杂的，需要单独看。我的原因比较坑，定位也花了些时间！！！公司DBA会进行sql语句执行时长监控，并kill掉相应的sql，从而造成上述通信异常问题，
还有一些原因比如空闲时间太长了，mysql server也会断开连接。常见的这些是改mysql的配置，社区的jark
wu有一些分享配置，mysql-cdc-connector的github上也有分享。比如wait_timeout之类的。
通过k8s-session部署的flink 集群，三个节点，job提交上去后为什么只占用一个task
manager的节点。目前这样，导致数据倾斜，每次checkpoint 都会失败
./bin/flink run -m yarn-cluster -yn 2 -yjm 1024 -ytm 1024
./examples/batch/WordCount.jar
java.lang.Exception: unable to establish the security context
at
org.apache.flink.runtime.security.SecurityUtils.install(SecurityUtils.java:73)
at
通过k8s-session部署的flink 集群，三个节点，job提交上去后为什么只占用一个task
manager的节点。目前这样，导致数据倾斜，每次checkpoint 都会失败
通过k8s-session部署的flink 集群，三个节点，job提交上去后为什么只占用一个task
manager的节点。目前这样，导致数据倾斜，每次checkpoint 都会失败
如上，同一个作业，数据也是相同的，配置差异就是有两阶段聚合，线上作业运行一断时间后
1、开两阶段聚合， 运行一段时间就会core，并且从checkpoint恢复时，必core，作业重启不了。每次都显示jvm heap不足。
2、关闭两阶段聚合，其它内存配置不变，作业运行没问题。
查看线上的core的时候的dump文件，发现一处疑似泄漏的地方。
请问下local agg操作是不是会用到java heap做聚合操作？聚合的数据量没控制好，容易引发内存问题？
Hi，请教大家一个问题：
目前使用grafana监控flink的作业，想实现一个任务挂掉就报警的功能，初步想法是：监控checkpoint
size的指标，一旦这个指标为0，就认为任务挂掉，但实际操作后，发现了两个问题：
① 如果kill掉任务，grafana上的flink所有指标都会一直保持最后接收到的值不变；
② 如果cancel掉任务，grafana上的flink所有指标都会突然中断；
所以，我上面说的想法永远都不会出发告警，因为这个checkpoint size的指标在任务挂掉也不会归为0值；
hi，
可以先做如下尝试：
export HADOOP_USER_NAME=your user
export HADOOP_CONF_DIR=your hadoop conf dir
export HADOOP_CLASSPATH=`/opt/app/hadoop/bin/hadoop classpath`
-
Thanks!
Jacob
--
Sent from: http://apache-flink.147419.n8.nabble.com/
tableEnv.executeSql
会返回TableResult，可以从中获取JobClient，检查JobStatus，在Future中CallBack
写逻辑执行后续sql。不知道是否满足你的需求？
Jacob <17691150...@163.com> 于2021年1月6日周三 下午2:13写道：
> Dear All,在Flink SQL
>
>
可以尝试用yarn application -list 去定期查找你的任务来判断任务是否挂掉
bradyMk 于2021年1月6日周三 下午4:35写道：
> Hi，请教大家一个问题：
>
> 目前使用grafana监控flink的作业，想实现一个任务挂掉就报警的功能，初步想法是：监控checkpoint
> size的指标，一旦这个指标为0，就认为任务挂掉，但实际操作后，发现了两个问题：
>
> ① 如果kill掉任务，grafana上的flink所有指标都会一直保持最后接收到的值不变；
> ② 如果cancel掉任务，grafana上的flink所有指标都会突然中断；
>
>
Hi~
我现在也有在用这个办法，可我任务特别多的话，还要求及时报警并发送消息到钉钉群到邮件，这种方法就不太好了
-
Best Wishes
--
Sent from: http://apache-flink.147419.n8.nabble.com/
Hi all,
我写了一个测试demo，设置了水印从数据中提取，但在cep的pattern里within()还是按processing time而不是event
time来触发？
flink??1.10.1
3
??kafka??hdfs
??
part-0-1
part-1-1
part-1-2
...
如题，反压的原因，不考虑计算压力大，并行度不合理等问题。
比如是否可能和网络也有关呢？
考虑如下case，A->B->C这么一个拓扑，我A（source）结点反压100%，数据彻底不再发送，但B和C都不反压。但是B、C都是非常简单（不可能存在性能问题）。那这还有什么解释吗？
比如，A和B之间网络是否可能出问题呢？
此外，从机器cpu等监控来看，出现反压后，cpu
idle提升，即反压到cpu利用率直接降低，且cpu在附近实际无升高的迹象。因此不会是瞬间有压力来导致反压。
我当前怀疑和网络有关，有人知道如何确认吗。这种case是否有可能自动恢复呢。
我比较倾向于是网络原因。但flink的日志目前无法很明显反映和确认。期望有人从flink反压机制角度考虑下，有没有因为网络“抖动”，比如长连接断开等问题导致反压的case。而且这种情况是否会自动恢复呢？从我的几次经验来看我不重启就不恢复。。。
赵一旦 于2021年1月6日周三 下午11:43写道：
> 如题，反压的原因，不考虑计算压力大，并行度不合理等问题。
> 比如是否可能和网络也有关呢？
>
> 考虑如下case，A->B->C这么一个拓扑，我A（source）结点反压100%，数据彻底不再发送，但B和C都不反压。但是B、C都是非常简单（不可能存在性能问题）。那这还有什么解释吗？
32 matches
Mail list logo
