这是我参与更文挑战的第26天,活动详情查看:更文挑战
1 Hadoop常用端口号
hadoop2.x | Hadoop3.x | |
---|---|---|
访问HDFS端口 | 50070 | 9870 |
访问MR执行情况端口 | 8088 | 8088 |
历史服务器 | 19888 | 19888 |
客户端访问集群端口 | 9000 | 8020 |
2 Hadoop配置文件以及简单的Hadoop集群搭建
- 配置文件:
Hadoop2.x core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml slaves
Hadoop3.x core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml workers
- 简单的集群搭建过程:
JDK安装
配置SSH免密登录
配置hadoop核心文件
格式化namenode
3 HDFS小文件处理
-
会有什么影响
-
存储层面:
1个文件块,占用namenode多大内存150字节
1亿个小文件*150字节
1个文件块 * 150字节
128G能存储多少文件块? 128*1024*1024*1024byte/150字节 = 9亿文件块 -
计算层面:
每个小文件都会起到一个MapTask,占用了大量计算资源
-
-
怎么解决
- 采用har归档方式,将小文件归档
- 采用CombineTextInputFormat
- 有小文件场景开启JVM重用;如果没有小文件,不要开启JVM重用,因为会一直占用使用到的task卡槽,直到任务完成才释放。 JVM重用可以使得JVM实例在同一个job中重新使用N次,N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间
<property>
<name>mapreduce.job.jvm.numtasks</name>
<value>10</value>
<description>How many tasks to run per jvm,if set to -1 ,there is no limit</description>
</property>
4 HDFS的NameNode内存
- Hadoop2.x系列,配置NameNode默认2000m
- Hadoop3.x系列,配置NameNode内存是动态分配的,NameNode内存最小值1G,每增加100万个block,增加1G内存。
5 Hadoop宕机
- 如果MR造成系统宕机。此时要控制Yarn同时运行的任务数,和每个任务申请的最大内存。调整参数:yarn.scheduler.maximum-allocation-mb(单个任务可申请的最多物理内存量,默认是8192MB)
- 如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小,控制从Kafka到HDFS的写入速度。例如,可以调整Flume每批次拉取数据量的大小参数batchsize。
6 Hadoop解决数据倾斜方法
- 提前在map进行combine,减少传输的数据量
在Mapper加上combiner相当于提前进行reduce,即把一个Mapper中的相同key进行了聚合,减少shuffle过程中传输的数据量,以及Reducer端的计算量。
如果导致数据倾斜的key大量分布在不同的mapper的时候,这种方法就不是很有效了。
-
导致数据倾斜的key 大量分布在不同的mapper
-
局部聚合加全局聚合。
第一次在map阶段对那些导致了数据倾斜的key 加上1到n的随机前缀,这样本来相同的key 也会被分到多个Reducer中进行局部聚合,数量就会大大降低。
第二次mapreduce,去掉key的随机前缀,进行全局聚合。
思想:二次mr,第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀,按原key进行reduce处理。
这个方法进行两次mapreduce,性能稍差。
-
增加Reducer,提升并行度
JobConf.setNumReduceTasks(int) -
实现自定义分区
根据数据分布情况,自定义散列函数,将key均匀分配到不同Reducer
-
7 项目经验之基准测试
搭建完Hadoop集群后需要对HDFS读写性能和MR计算能力测试。测试jar包在hadoop的share文件夹下。
集群总吞吐量 = 带宽*集群节点个数/副本数
例如:100m/s * 10台/ 3= 333m/s
注意:如果测试数据在本地,那副本数-1。因为这个副本不占集群吞吐量。如果数据在集群外,向该集群上传,需要占用带宽。本公式就不用减1。