大数据组件部分优化

主要是对于CDH平台上的大数据组件优化，后续再添加。

目录

 

1. HDFS

2. Yarn

3. Flume

4. Kafka

5. Hive

6. Sqoop

7. 其他优化：

---

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. 元数据备份

原理：如数据损坏，可能整个集群无法运行
优化：至少要保证每日零点之后备份到其它服务器两个复本