版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/yidan7063/article/details/85158961
参考学习博客然后写的学习笔记:
- KeyedState - 这里面的key是我们在SQL语句中对应的GroupBy/PartitioneBy里面的字段，key的值就是groupby/PartitionBy字段组成的Row的字节数组，每一个key都有一个属于自己的State，key与key之间的State是不可见的;
- OperatorState - Apache Flink内部的Source Connector的实现中就会用OperatorState来记录source数据读取的offset。
OperatorState并行度改变时比较简单，如上面保存kafka offset的例子。
OperatorState采用了List的数据结构的设计，在改变并发时，通过取模的方式分配分区。新增分区的offset需要远程拉取。
KeyedState并发度改变，因为KeyedState保存的状态往往挺大的，不在使用OperatorState并行度改变的方法。可以看出每次修改并行度如果按照取模的算法，对算子状态就是灾难。大量的算子无法在使用原本本地的状态，只能从远程拉取状态进行同步。OperatorState的算法是先以maxParallelism为标准
1.hash(key)%maxParallelism ->key-group 利用key的hash值对maxParallelism取模,分配key到对应的key-group上
2.key-group/真正的并发度得到平均值 将余数平分给task编号靠前的算子 ->得到每个task上面的key-group数量
3.每个task顺序的取到自己的key-group
从图中可以看出大部分算子还是落到了本地。
可以看出所有的前提都是基于maxParallelism,如果maxParallelism发生改变会导致key-group重新分组，最后每个task上的key-group都会改变。这样对状态本地化改动比较大。所以在Flink中maxParallelism默认为4096.
努力吧，皮卡丘