如何通过Hadoop任务日志快速识别数据倾斜？

Question

在Hadoop任务执行过程中，数据倾斜常导致个别Reduce任务远慢于其他任务，显著延长作业总耗时。如何通过任务日志快速识别数据倾斜？一个典型问题是：多个Reduce任务在相同时间内处理的数据量差异巨大，日志中表现为某些任务的“GC时间过长”、“输入记录数异常偏高”或“Shuffle读取数据量远超平均值”。例如，通过查看YARN Container日志中的Map-Reduce Shuffle Phase，发现某Reduce读取字节数达数百MB甚至GB，而其余仅几MB，即可判定存在数据倾斜。此外，任务进度长期停滞在99%或100%，个别任务重试多次仍失败，也往往是倾斜所致。关键在于结合ResourceManager页面与Task Attempt日志，快速定位异常指标。

Answer 1

一、数据倾斜的定义与典型表现

在Hadoop MapReduce任务执行过程中，数据倾斜是指某些Reducer接收到的数据量远大于其他Reducer，导致整体作业进度被个别慢任务拖慢的现象。这种不均衡通常发生在Shuffle阶段，当Map输出的Key分布极不均匀时，部分Reducer需要处理海量数据，而其余Reducer早早完成。

典型的症状包括：

• 任务进度长期卡在99%或100%
• 个别Reduce任务持续运行数小时，而其他任务几分钟内完成
• YARN Container日志中显示“GC time exceeded”警告
• Shuffle Read Bytes差异巨大：某任务读取GB级数据，其余仅MB级
• 频繁的任务重试（Task Attempt）且均失败于同一节点

二、通过YARN ResourceManager定位异常任务

首先应访问YARN的ResourceManager Web UI（默认端口8088），进入具体应用的ApplicationMaster页面。重点关注以下指标：

监控项	正常值参考	异常表现
Total Reduce Tasks	100	-
Completed Reduces	99/100 长时间停滞	最后一个任务迟迟不完成
Avg Shuffle Read	50MB	某任务读取 >1GB
GC Time (per task)	<30s	>300s
Task Duration	平均 5min	最长达 2h+

三、深入Task Attempt日志分析

点击未完成的Reduce任务，查看其对应的Task Attempt日志（stdout/stderr）。关键日志片段示例如下：

[INFO] ShuffleSchedulerImpl: Received 1.2 GB of data from 45 map outputs
[WARN] YarnChild: Exceeded GC time limit (80%) in 180 seconds
[ERROR] Runner: Task attempt failed due to excessive memory pressure
    

上述日志表明该Reduce在Shuffle阶段接收了异常大量数据，并因GC耗时过长被系统判定为超限。可通过如下命令直接提取容器日志：

yarn logs -applicationId application_123456789_0001 -containerId container_e03_123456789_0001_01_000002

四、自动化检测脚本辅助诊断

对于高频调度任务，可编写Python脚本定期抓取YARN REST API数据，自动识别潜在倾斜：

import requests
def check_skew(app_id):
    url = f"http://rm-host:8088/ws/v1/cluster/apps/{app_id}/attempts"
    resp = requests.get(url).json()
    shuffle_reads = [t['shuffleFinishTime'] - t['mergeFinishTime'] for t in resp['remoteProcessTree']]
    if max(shuffle_reads) > 10 * sum(shuffle_reads)/len(shuffle_reads):
        print("Potential skew detected!")
    

五、基于Mermaid的故障排查流程图

构建标准化的数据倾斜识别路径：

graph TD
            A[作业卡在99%?] -->|Yes| B{检查RM界面Reduce进度}
            B --> C[是否存在单个慢任务?]
            C -->|Yes| D[查看对应Task Attempt日志]
            D --> E[分析Shuffle Read Bytes/GC Time]
            E --> F{是否显著高于均值?}
            F -->|Yes| G[确认数据倾斜]
            F -->|No| H[考虑网络或磁盘问题]
            C -->|No| I[检查Mapper输出分布]

六、常见根源与扩展思考

数据倾斜的根本原因往往源于业务逻辑设计，例如：

• 按用户ID聚合时，少数超级用户产生90%的数据
• 使用DISTRIBUTE BY constant导致所有数据流向单一Reducer
• Join操作中大表与小表未启用Map Join

高级场景下，还需结合Hive执行计划（EXPLAIN EXTENDED）分析Operator级别的行数膨胀情况，进一步定位倾斜源头。