当前位置：首页 > news >正文

大数据中的各种场景数据倾斜的介绍

news 2026/7/2 10:15:26

数据倾斜的本质是分布式系统中负载分配不均。在理想的分布式计算中，数据应均匀分摊到各个节点；但在现实中，往往会变成“一个人干完所有人活，其他人都在等”。

数据倾斜的表层表现是某个分区、Task、Reducer 或 Kafka Partition 的数据量和处理时间远超其他节点。其深层原因通常集中在五点：业务数据本身的长尾分布（如头部用户、爆款商品）、空值或默认值聚集、分区或关联键选择不当、Shuffle 重分区不均匀，以及计算逻辑放大了局部压力。

从任务生命周期来看，倾斜可分为四类：

读倾斜：源头文件分块过大或压缩格式不可切分，导致个别 Map Task 过载。
算倾斜：最常见的一类，发生在 Shuffle 后的 Group By、Join、Sort 或 Window 等操作中，热点 Key 导致单点计算压力激增。
写倾斜：Join 后数据发生笛卡尔式膨胀，或动态分区一次性写出海量小文件，导致单点 I/O 阻塞。
文件操作倾斜：任务最终将海量临时文件移动到目标目录时，单点操作耗时极长。

无论在哪个计算引擎中，倾斜都有相似的“体感”：

进度假死：整体进度卡在 99%，仅剩 1-2 个 Task/Reducer 长时间运行。
指标两极分化：Spark UI 中个别 Task 的 Shuffle Read 高达十几 GB，而其他仅几 MB；Flink Web UI 中单个 Subtask 出现高反压和 Checkpoint 超时。
资源与异常报警：个别节点 CPU/内存打满，频繁 Full GC，甚至出现 OOM 崩溃。

MapReduce 的瓶颈集中在 Shuffle 后的 Reduce 阶段。

Reduce 聚合倾斜：Group By 维度过低（如按性别分组）或去重统计 Count Distinct 时，特殊值过多集中到单个 Reducer。
Join 关联倾斜：大表与小表关联时，小表 Key 过于集中；或大表与大表关联时，关联字段存在大量空值（Null），导致所有空值被哈希分配到同一个 Reducer。
输入读倾斜：HDFS 上的大文件、不可切分的压缩包或大量小文件，导致 Map 端切片不均。

Spark 的倾斜集中在 Shuffle 类算子（如 reduceByKey、groupByKey、join）。

Shuffle 分区倾斜：单个分区数据超过 500MB-1GB 时，极易引发磁盘溢写和网络拉取阻塞。
Join 与大 Key 倾斜：大表 Join 时，若关联键（如爆款商品 ID）极度集中，数据乘积会引发内存溢出；此外，开窗函数（Window）在特定时间窗口（如双11零点）数据暴增，或 Filter 过滤后剩余数据意外集中在少数分区，也会造成隐性倾斜。

在 Hive SQL 层面，不同 SQL 写法会触发不同的底层机制：

Flink 的倾斜不仅影响吞吐量，还会破坏状态的稳定性。

KeyBy 热点与状态倾斜：KeyBy 按哈希取模分区，热点 Key 会进入同一个 Subtask，导致本地状态（State）无限膨胀，引发 RocksDB 性能恶化、Checkpoint 超时和 OOM。
窗口与双流 Join 倾斜：滚动或滑动窗口触发时，短时间内大量数据涌入同一算子；双流 CoGroup 或 Interval Join 时，若关联键分布不均，会导致单点背压。
Source/Sink 与并行度错配：Kafka 分区数少于下游算子并行度，导致部分 Consumer 空载；或 Sink 端写入热点分区，造成外部系统拥塞。

Kafka 的倾斜发生在数据存储和消费链路中。

生产端分区倾斜：默认哈希策略下，若按头部商家 ActivityId 或 UserId 分区，会导致个别 Broker 磁盘 I/O 饱和，消息严重积压。
消费端倾斜：消费者组内分区分配不均，或个别消费者处理能力不足，导致消费延迟拉长。

排查应遵循“先看进度和 UI 指标 -> 抽样找热点 Key -> 判断属于读/算/写哪一类 -> 选择隔离、打散或预聚合策略”的闭环。

空值与异常值：在 ETL 阶段直接过滤，或赋随机值打散，处理后再 Union 回结果。
Group By 聚合：采用“加盐两阶段聚合”，先给热点 Key 加随机前缀做局部聚合，再去前缀全局汇总。
Join 关联：小表使用 MapJoin/Broadcast Join 广播进内存；大表大表拆分热点 Key 单独处理，或使用 AQE（自适应执行）自动优化。
实时流处理：Flink 中采用“两级 KeyBy”（先加盐打散预聚合，再原 Key 全局汇总），并对大状态开启 TTL 清理。
消息队列：Kafka 引入随机路由层或自定义分区器，打破强有序约束以实现物理均衡。
NoSQL：重构 RowKey 或文档 ID，加入 Salt 前缀或哈希前缀，确保数据均匀分布。