主要是对于CDH平台上的大数据组件优化,后续再添加。
目录
1. HDFS
1. 设置HDFS多个存储目录
原理:将数据分不到多个磁盘,不会只占用某个磁盘,导致某些磁盘频繁使用,某些磁盘空闲。
优化:dfs.datanode.data.dir 添加dfs不同磁盘存储位置
2. 设置Namenode与Datanode通讯的线程数量 :
原理:过小会导致Datanode延迟或者断开,集群规模大时必须设置,默认为10,通常需要重新配置。
优化:dfs.namenode.handler.count = 20 * log2N
N为集群规模,比如:集群规模为8台时,此参数设置为60
3. 设置编辑日志存储与镜像文件存储不同路径
原理:将两者储路径分开,将达到最低写入延迟
优化:编辑日志存储路径 dfs.namenode.edits.dir
镜像文件存储路径 dfs.namenode.name.dir
2. Yarn
1. Yarn节点可使用的内存 :yarn.nodemanager.resource.memory-mb
原理: 合理设置内存分配,提高资源利用,防止oom
优化:默认是8G,一般会根据节点将节点上,除了其他组件需要的内存,其余内存全部分配给YARN
2. Yarn单个任务可申请的最小/最大物理内存量 :yarn.scheduler.minimum-allocation-mb / maximum
原理:合理设置内存分配,提高资源利用,防止oom
优化:最小默认1G,一般默认
最大默认8G,一般调整为64G或更大,不能超过设置(yarn节点可用内存*节点数)的总和
3. Yarn节点可用虚拟CPU数量 :yarn.nodemanager.resource.cpu-vcores
原理:该节点上Yarn可使用的虚拟CPU个数,充分利用CPU资源,增加计算效率
优化:默认是各节点核心数(CDH),其他默认8个,一般会调整为节点核心75%左右
4. Yarn单个任务可申请的最小/最大虚拟CPU数量 :yarn.scheduler.minimum-allocation-vcores /maximum
原理:合理设置,充分利用CPU资源,增加计算效率
优化:最小默认1个,一般默认
最大默认节点核心数(CDH),其他默认32个,一般为集群总核心数的75%左右
5. Yarn为MR App Master分配的内存 :yarn.app.mapreduce.am.resource.mb
原理:设定MR AppMaster使用的内存,因为AppMaster是由Container开启,所以不能超过Container最小内存
优化:最小默认1G,少于Container最小内存
即:少于yarn.scheduler.minimum-allocation-mb
6. Yarn为MR App Master分配的虚拟CPU数量 :yarn.app.mapreduce.am.resource.cpu-vcores
原理:设定MR AppMaster使用的cpu数量
优化:最小默认1个,根据实际情况调整,可不变动
3. Flume
1. Flume内存参数设置及优化
原理:根据服务器配置适当增大Flume堆内存,提高执行效率和稳定性
优化:调整Flume GC overhead
编辑配置文件
/opt/cloudera/parcels/CDH/lib/flume/conf/flume-env.sh
添加
export JAVA_OPTS="-Xms100m -Xmx2000m -Dcom.sun.management.jmxremote"
一般设置为4G或更高
-Xmx与-Xms最好设置一致,减少内存抖动带来的性能影响,如果设置不一致容易导致频繁full gc。
2. 设置Flume batchSize大小
原理:Event 数据量达到多大时处理一次
优化:默认为100,例如:Event 1K左右时,调整为500-1000
3. Source选择
原理:Taildir Source支持断点续传、多目录。Flume1.6以前需要自己自定义Source记录每次读取文件位置,实现断点续传。
Exec Source可以实时搜集数据,但是在Flume不运行或者Shell命令出错的情况下,数据将会丢失。
Spooling Directory Source监控目录,不支持断点续传。
优化:防止数据丢失,选择Taildir Source
实时需求,选择Exec Source
3. Channel类型选择
原理:Memory Channel传输数据速度更快,但因为数据保存在JVM的堆内存中,Agent进程挂掉会导致数据丢失,
适用于对数据质量要求不高的需求。
File Channel传输速度相对于Memory慢,但数据安全保障高,Agent进程挂掉也可以从失败中恢复数据。
Kafka Channel省去Flume Sink,提高了效率
优化:数据要求高,选择File Channel
数据要求不严格,但要求速度,选择Memory Channel
Flume连接Kafka,选择Kafka Channel
4. FileChannel优化
优化:1.通过配置dataDirs指向多个路径,每个路径对应不同的硬盘,增大Flume吞吐量
2.checkpointDir和backupCheckpointDir配置在不同硬盘对应的目录中,保证checkpoint如果损坏,
可以使用backupCheckpointDir快速恢复数据
5. HDFS Sink
原理:HDFS存入大量小文件的影响
元数据层面:每个小文件都有一份元数据,其中包括文件路径,文件名,所有者,所属组,权限,
创建时间等,这些信息都保存在Namenode内存中。所以小文件过多,会占用Namenode服务器大量内存,
影响Namenode性能和使用寿命
计算层面:默认情况下MR会对每个小文件启用一个Map任务计算,非常影响计算性能。同时也影响磁盘寻址时间。
优化:HDFS小文件处理,合理设置以下参数
hdfs.rollInterval=3600,hdfs.rollSize=134217728,hdfs.rollCount =0
hdfs.roundValue=10,hdfs.roundUnit= second
设置文件内容达到128M,或者一定时间生成文件,减少小文件生产数量。
6. Fiume小文件合并
优化:调整hdfs.rollInterval 按时间生成文件
hdfs.rollSize 按大小生成
hdfs.rollCount 按数量生成
4. Kafka
如果写入文件过量造成NameNode宕机,调高Kafka的存储大小,控制从Kafka到HDFS的写入速度。
高峰期的时候用Kafka进行缓存,高峰期过去数据同步会自动跟上。
5. Hive
1. 输出合并小文件
SET hive.merge.mapfiles = true; 默认true,在Map任务结束时合并小文件
SET hive.merge.mapredfiles = true; 默认false,在MapReduce任务结束时合并小文件
SET hive.merge.size.per.task = 268435456; 默认256M,每次合并的文件大小
SET hive.merge.smallfiles.avgsize = 16777216;
当输出文件的平均大小小于该值时,启动一个独立的MapReduce任务进行小文件合并
2. Hive基于MR时的优化
1. 增加Maptask和Reducetask运行内存:
默认1G,开发调到4-6G,实际配置的内存需要根据自己机器内存大小及应用情况进行修改
mapreduce.map.memory.mb=2048
mapreduce.map.java.opts=-Xmx1024M
mapreduce.reduce.memory.mb=3072
mapreduce.reduce.java.opts=-Xmx2560M
2. shuffle优化:环形缓冲区大小默认100M,调整为200M或更大。
默认阈值80%,调整为90-95
原因:减少溢写文件个数
3. reduce优化:拉取个数默认5个,可以设置10个或更大,拉取内存可以设置调大
原因:增加并行度
*. 运行内存不足容易导致的情况:
Hive使用过多内存而被NodeManager kill
即从节点上运行的Container试图使用过多的内存,而被NodeManager kill掉
应调整Yarn和maptask/reduceTask内存参数
Maptask运行内存应大于或者等于Container的最小内存,即
mapreduce.map.memory.mb >= yarn.scheduler.minimum-allocation-mb
3. 尽量使用MapJoin
原理:不指定MapJoin,Hive解析器会将Join操作转换为Common Join,即在Reduce阶段完成Join
优化:指定MapJoin,在Map端进行Join,避免Reduce端Join
4. 行列过滤
原理:select * 会全表扫描,降低效率
分区取数据时,使用外连接,如果将副表过滤条件写到where后面,会先关联全表再过滤
优化:select中指定需要的列,如果有分区尽量使用分区过滤
分区取数据使用外连接时,先对副表过滤,再关联
6. Sqoop
1. Hive和MySQL导出导入存在Null值
原理:Hive的Null底层是以"\N"存储,MySQL底层是以Null存储
优化:Sqoop导出时加参数 --input-null-string、--input-null-non-string
导入时加 --null-string、--null-non-string
2. 数据一致性
原理:如果导入过程中Map任务失败,导致只导入部分数据
优化:建立临时表,导入完成再从临时表导入目标表
添加参数 --staging-table、--clear-staging
7. 其他优化
1. 元数据备份
原理:如数据损坏,可能整个集群无法运行
优化:至少要保证每日零点之后备份到其它服务器两个复本