Map 和Reduce的Task数目

在不指定的情况下,Map 和Reduce Task 的数目由这样几个因素决定:

1.输入数据的块数,Map 输出数据的块数(Reduce数量是可以设定),一个块一般由一个task 来处理(一般,即文件格式是否支持切分)

2.输入数据的文件数量。一个文件至少需要1 个task 来处理(至少,即一个文件可能是存储于多个文件块)

3.是否对数据进行了压缩,压缩格式是否可切分(Splitable),如果不可分,即使文件大于64M,也只能由一个task 来处理 (不支持切分,顺序读取)


转载于:https://my.oschina.net/xiaotian120/blog/202742

### Hadoop Hive 执行 DDL 任务时遇到 `GC overhead limit exceeded` 错误解决方案 当执行Hive的DDL操作(如创建表、修改表结构等)时,如果遇到了`Error: GC overhead limit exceeded`错误,这通常意味着垃圾回收器花费过多的时间来清理堆空间中的对象。此问题可以通过调整JVM参数以及优化MapReduce作业配置来缓解。 对于仅存在映射阶段的任务而言,在面对大量数据输入的情况下,适当增加分配给Mapper进程的最大内存量是一个有效的策略[^1]。具体来说: - **增大 Map Reduce 阶段可用内存** 通过设置如下属性,可以为MapReduce过程提供更多的内存资源,从而减少因频繁触发垃圾收集而导致性能下降的风险: ```properties set mapreduce.map.memory.mb=5120; set mapreduce.reduce.memory.mb=5120; ``` 上述命令分别指定了每个Mapper/Reducer实例可使用的最大物理内存大小为5GB。同时还需要相应地提高Java应用程序启动选项里的-Xmx值,即指定初始Heap Size不超过总Memory Limit的80%左右较为合理: ```properties set mapreduce.map.java.opts=-Xmx4096m -XX:+UseConcMarkSweepGC; set mapreduce.reduce.java.opts=-Xmx4096m -XX:+UseConcMarkSweepGC; ``` 这里设置了Mapper与Reducer JVM的最大堆尺寸均为4G,并启用了CMS (Concurrent Mark Sweep) 垃圾回收算法以更好地管理长时间运行的应用程序内的对象生命周期[^2]。 - **控制并行度** 为了防止由于过度分割造成过多的小型分片进而引发不必要的开销,可以根据实际需求调整Split By字段的选择标准或是直接限制并发执行的地图任务数目。例如,在使用Sqoop工具从关系数据库迁移至HDFS的过程中,可通过 `-m` 参数手动设定导入线程的数量[^3]: ```bash /usr/bin/sqoop import \ --connect jdbc:mysql://hadoop01:3306/scrm \ --username root \ --password 123456 \ --query "select *,date_format(create_date_time,'%Y-%m-%d') as dt from employee where 1=1 and \$CONDITIONS" \ --hcatalog-database ods_dim \ --hcatalog-table ods_dim_scrm_employee_i \ --split-by id \ -m 1 ``` 该脚本将只启用单一线程来进行全量导出工作,有助于降低系统负载。 - **合并小文件** 有时即使已经增加了每项工作的内存限额,仍然会因为源目录下存在太多零碎的小文件而遭遇瓶颈。此时建议开启Combine Input Format功能,允许多个小型文件被组合成较大的批次供后续处理单元消费;另外还可以考虑提升每次Merge Task所能容纳的数据总量阈值,以此达到精简上游环节产生的中间产物的效果[^4]: ```sql SET hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET hive.merge.mapfiles = TRUE; SET hive.merge.size.per.task = 256000000L; ``` 以上措施能够有效改善由海量小规模记录所引起的效率低下状况。 最后值得注意的是,针对特定版本或环境下的特殊情形可能还需进一步微调其他相关联的参数配置,比如是否开启了压缩编码特性等等。总之应当依据具体的业务场景灵活运用这些方法论去解决问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值