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

[bradyMk]

Hi~

我这边测试了一下，分配同样的slot和内存，100个key和1亿个key，速度上并没有明显差异



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

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

[赵一旦]

其实我那个问题是针对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 中使用了 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
> --
> Sent from: http://apache-flink.147419.n8.nabble.com/
>
>

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

[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
--
Sent from: http://apache-flink.147419.n8.nabble.com/

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

[bradyMk]

在保证数据量不变的情况下，我并没有测试10亿个key的性能，但我测试了只有8个key的性能，发现背压严重；现在用了100个key，消费正常；所以，我认为，ckpt的性能/时间和key的数量还是有关的



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

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

[赵一旦]

所以说，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: 回复：一个关于实时合并数据的问题

[bradyMk]

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



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

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

[xuhaiLong]

id 是字符串 走哈希取余试试看？


在2020年12月4日 18:12，502347601<502347...@qq.com> 写道：
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/

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

[bradyMk]

这样啊。。那请问如果id是字符串的话，有什么好办法去减少分组么？



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

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

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



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

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

[bradyMk]

所以您说的这个思路应该是和我上面说的是一样的了吧，根据10亿id做keyby，不会有什么问题么？



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

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

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

[bradyMk]

Hi~

可是MapState是只针对keyby后的流才能用啊



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