没有大神懂这个的吗？帮忙分析下。
赵一旦 <
[hidden email]> 于2020年12月22日周二 上午12:05写道：
> 目前来说，按照我讲的方式去实现应该不难。我怕的是flink在恢复keyedState的时候，无法适应我的这种partition机制。
>
> 现有的机制，restore的时候实际是 keyGroup 到window并行实例之间的一个重分配。
>
> 换成我的partition机制后，能否还正常restore呢？
>
> 赵一旦 <
[hidden email]> 于2020年12月22日周二 上午12:03写道：
>
>> 如题，目前对于OperatorState来说，API层面有2个接口，即CheckpointedFunction和ListCheckpointed
>> 。即UDF中有入口对restore做自定义。
>>
>> 问题（1）KeyedState的恢复则相对黑盒。想知道相关实现在哪。
>>
>> 引申问题（2），我的原始目的为。我期望实现
>> keyBy(...).timwWindow(x).xxx()这种统计。在保留keyBy的keySelector机制前提下（即window算子部分仍然会按照key分窗口统计），通过重写部分flink的api层代码方式，强制去除keyBy中加入的
>> KeyGroupStreamPartitioner
>> ，换成使用可传入的自定义Partitioner。目的呢是希望解决“数据倾斜”，但我不想通过双层keyBy解决，因为本身key数量很少（假设100），即使是双层，那么第一层需要将key起码扩大1000倍我感觉才能足够均衡。如果能仅仅扩大比如30倍（这个倍数可以考虑和下游window算子并发一致），然后在partition中实现类似rebalance的分发机制。
>> 当然，更高级的可能还可以做智能的，比如部分key扩大，部分key不扩大。
>>
>>
>> 描述比较乱，换言之，我就直接非KeyedStream情况下，使用dataStream.flatMap，然后flatMap中使用MapState统计。类似这种效果。当然我还是希望通过改造window实现，因为window部分还有watermark以及分窗机制，flatMap需要自己实现分窗。
>>
>>
Locked
