开发者社区> 问答> 正文

请教关于KeyedState的恢复机制

如题,目前对于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需要自己实现分窗。*来自志愿者整理的flink邮件归档

展开
收起
又出bug了-- 2021-12-02 11:52:40 509 0
1 条回答
写回答
取消 提交回答
  • 目前来说,按照我讲的方式去实现应该不难。我怕的是flink在恢复keyedState的时候,无法适应我的这种partition机制。 

    现有的机制,restore的时候实际是 keyGroup 到window并行实例之间的一个重分配。 

    换成我的partition机制后,能否还正常restore呢?*来自志愿者整理的FLINK邮件归档

    2021-12-02 14:36:35
    赞同 展开评论 打赏
问答地址:
问答排行榜
最热
最新

相关电子书

更多
事务、全局索引、透明分布式 立即下载
运用新技术解决有状态应用的冷热迁移挑战 迁移策略+新容器运行时 立即下载
微信SQLite数据库损坏恢复实践 立即下载

相关实验场景

更多