Re: 回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-10 文章 bradyMk
Hi~ 我这边测试了一下,分配同样的slot和内存,100个key和1亿个key,速度上并没有明显差异 - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

Re: 回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-07 文章 赵一旦
其实我那个问题是针对502347601讲的,10亿 -> ckpt性能问题,是否有什么经验或者实验说明。 至于bradyMk你说的8个key和100个key那个不算的哈。8个key和100个key这不能反映性能的哈,8个key限制了并行度,同时也会导致很大的数据倾斜。你起码要保证比如1w个key去和10亿个key对比,这样才能说明是否对ckpt性能有影响。 你说的8个key会反压,肯定是并行不够,或者数据倾斜啦。 xuhaiLong 于2020年12月7日周一 上午11:53写道: > 这个我也不太清楚,没有做过对应的是测试。 > > > @吴磊 想到一个问题,如果 process

回复: 回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-06 文章 xuhaiLong
这个我也不太清楚,没有做过对应的是测试。 @吴磊 想到一个问题,如果 process 中使用了 agg state,keyBy(userId % 10) 后会有问题吧?使用 mapState 做 agg 操作? 在2020年12月6日 20:30,赵一旦 写道: 所以说,ckpt的性能/时间和key的数量有关对吗?即使总体数据量不变,key少些,每个key的状态变大,会降低ckpt时间? 按照你们的分析来看?? bradyMk 于2020年12月4日周五 下午7:23写道: 对对对,可以取hashCode,我短路了,谢谢哈~ - Best Wishes -- Se

Re: 回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-06 文章 bradyMk
在保证数据量不变的情况下,我并没有测试10亿个key的性能,但我测试了只有8个key的性能,发现背压严重;现在用了100个key,消费正常;所以,我认为,ckpt的性能/时间和key的数量还是有关的 - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

Re: 回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-06 文章 赵一旦
所以说,ckpt的性能/时间和key的数量有关对吗?即使总体数据量不变,key少些,每个key的状态变大,会降低ckpt时间? 按照你们的分析来看?? bradyMk 于2020年12月4日周五 下午7:23写道: > 对对对,可以取hashCode,我短路了,谢谢哈~ > > > > - > Best Wishes > -- > Sent from: http://apache-flink.147419.n8.nabble.com/ >

Re: 回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 bradyMk
对对对,可以取hashCode,我短路了,谢谢哈~ - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

回复: re:Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 xuhaiLong
Subject: Re: re:Re: 回复:一个关于实时合并数据的问题 所以您说的这个思路应该是和我上面说的是一样的了吧,根据10亿id做keyby,不会有什么问题么? - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

Re: re:Re: re:Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 bradyMk
这样啊。。那请问如果id是字符串的话,有什么好办法去减少分组么? - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

re:Re: re:Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 502347601
hello~ 不能按照keyId来keyby,这样state的个数也就10亿个了,checkpoint会有性能问题。你可以先求余一下,比如求余分成10组。类似这样keyid%10。 -- Original Message -- From: "bradyMk"; Date: 2020-12-04 18:05 To: "user-zh"; Subject: Re: re:Re: 回复:一个关于实时合并数据的问题 所以您说的这个思路应该是和我上面说的是一样的了吧,根据

Re: re:Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 bradyMk
所以您说的这个思路应该是和我上面说的是一样的了吧,根据10亿id做keyby,不会有什么问题么? - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

re:Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 502347601
嗯嗯是的,所以你需要keyby下~  -- Original Message -- From: "bradyMk"; Date: 2020-12-04 17:58 To: "user-zh"; Subject: Re: 回复:一个关于实时合并数据的问题 Hi~ 可是MapState是只针对keyby后的流才能用啊 - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

Re: 回复:一个关于实时合并数据的问题

2020-12-04 文章 bradyMk
Hi~ 可是MapState是只针对keyby后的流才能用啊 - Best Wishes -- Sent from: http://apache-flink.147419.n8.nabble.com/

一个关于实时合并数据的问题

2020-12-04 文章 bradyMk
想请教各位一个问题:目前有一个这样的需求: 数据流40W/s,数据有id,time,type等字段,id有10亿个,现在想30分钟内,同一个id的信息只保存一条,时间的话要用事件的事件,不能用处理的时间。 本人现在的思路是:根据id分组,然后做增量ck,状态信息存储每个id的最后的时间,然后每来一条数据会读取状态信息,然后做时间判断。但是发现这样做背压很高,数据消费很慢 请问各位,我这种思路是否可行?根据id分组会产生10亿个分组,这样会影响什么?还有其他更好的方法么? 谢谢各位解答疑惑! - Best Wishes -- Sent from: http://