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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

吴磊
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: 回复:一个关于实时合并数据的问题



所以您说的这个思路应该是和我上面说的是一样的了吧,根据10亿id做keyby,不会有什么问题么?
----- Best Wishes
--
Sent from: http://apache-flink.147419.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

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

bradyMk
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

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

hailong
In reply to this post by 吴磊
id 是字符串 走哈希取余试试看?


在2020年12月4日 18:12,502347601<[hidden email]> 写道:
hello~&nbsp;不能按照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: 回复:一个关于实时合并数据的问题



所以您说的这个思路应该是和我上面说的是一样的了吧,根据10亿id做keyby,不会有什么问题么?
----- Best Wishes
--
Sent from: http://apache-flink.147419.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

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

bradyMk
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

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

nobleyd
所以说,ckpt的性能/时间和key的数量有关对吗?即使总体数据量不变,key少些,每个key的状态变大,会降低ckpt时间?
按照你们的分析来看??

bradyMk <[hidden email]> 于2020年12月4日周五 下午7:23写道:

> 对对对,可以取hashCode,我短路了,谢谢哈~
>
>
>
> -----
> Best Wishes
> --
> Sent from: http://apache-flink.147419.n8.nabble.com/
>
Reply | Threaded
Open this post in threaded view
|

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

bradyMk
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

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

hailong
In reply to this post by nobleyd
这个我也不太清楚,没有做过对应的是测试。


@吴磊 想到一个问题,如果 process 中使用了 agg state,keyBy(userId % 10) 后会有问题吧?使用 mapState 做 agg 操作?
在2020年12月6日 20:30,赵一旦<[hidden email]> 写道:
所以说,ckpt的性能/时间和key的数量有关对吗?即使总体数据量不变,key少些,每个key的状态变大,会降低ckpt时间?
按照你们的分析来看??

bradyMk <[hidden email]> 于2020年12月4日周五 下午7:23写道:

对对对,可以取hashCode,我短路了,谢谢哈~



-----
Best Wishes
--
Sent from: http://apache-flink.147419.n8.nabble.com/

Reply | Threaded
Open this post in threaded view
|

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

nobleyd
其实我那个问题是针对502347601讲的,10亿 -> ckpt性能问题,是否有什么经验或者实验说明。

至于bradyMk你说的8个key和100个key那个不算的哈。8个key和100个key这不能反映性能的哈,8个key限制了并行度,同时也会导致很大的数据倾斜。你起码要保证比如1w个key去和10亿个key对比,这样才能说明是否对ckpt性能有影响。
 你说的8个key会反压,肯定是并行不够,或者数据倾斜啦。

xuhaiLong <[hidden email]> 于2020年12月7日周一 上午11:53写道:

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

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

bradyMk
CONTENTS DELETED
The author has deleted this message.