本文探讨了大数据计算中常见的数据倾斜问题，特别是在Flink中的表现和影响。通过一个计算各app PV的案例，解释了数据倾斜如何导致计算瓶颈，并提出通过LocalKeyBy策略在keyBy之前进行预聚合来减轻数据倾斜。然而，这种方法在故障恢复时可能无法保证Exactly Once，文章深入分析了这个问题并提出了改进方案。此外，还讨论了keyBy之前的数据倾斜以及解决思路。总结了判断数据倾斜的方法和解决策略，强调在解决数据倾斜时要考虑Exactly Once的保证。
在大数据计算场景，无论使用 MapReduce、Spark 还是 Flink 计算框架，无论是批处理还是流处理都存在数据倾斜的问题，通过本节学习产生数据倾斜的原因及如何在生产环境解决数据倾斜。
数据倾斜简介
分析一个计算各 app PV 的案例，如下图所示，圆球表示 app1 的日志，方块表示 app2 的日志，Source 端从外部系统读取用户上报的各 app 行为日志，要计算各 app 的 PV，所以按照 app 进行 keyBy，相同 app 的数据发送到同一个 Operator 实例中处理，keyBy 后对 app 的 PV 值进行累加来，最后将计算的 PV 结果输出到外部 Sink 端。
可以看到在任务运行过程中，计算 Count 的算子有两个并行度，其中一个并行度处理 app1 的数据，另一个并行度处理 app2 的数据。由于 app1 比较热门，所以 app1 的日志量远大于 app2 的日志量，造成计算 app1 PV 的并行度压力过大成为整个系统的瓶颈，而计算 app2 PV 的并行度数据量较少所以 CPU、内存以及网络资源的使用率整体都比较低，这就是产生数据倾斜的案例。
随着业务的不断发展，如果 a
订阅专栏 解锁全文
2379
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
