Flink keyby问题

我们生产的时候，按照 业务 逻辑 比如 电商 店铺 进行key by 之后，进行 窗口 process 计算，我们发现 key by 的维度越细，任务就越不稳定，并且我们发现 每个 key 都有属于自己的process context ，这里就会造成很大的 flink 内部的内存占用，以及效率问题。 key by 的 逻辑很重要，尤其是 有使用状态后端 的场景 。 所以个人认为 key by 的列 最好是根据你 的任务的 并行度来进行设计 ，key by 的作用应该是对数据进行路由操作， 将数据均匀的发往 下游的 operator , 粒度不能太细，容易造成上面的问题，也不能太粗，容易数据倾斜。

keyby会导致shuffle，shuffle会导致Task之间的数据交换，这都是有额外的序列化、反序列化以及I/O开销的，所以keyby肯定会影响吞吐，具体影响程度要看单条数据的大小；这个是Flink的固有机制，没有解

keyby后，数据会根据key值发往下游的operator。建议你看下graph中哪个task产生了反压，是不是和IO相关。