hadoop多目录与LZO压缩
1.HDFS存储多目录
存储多目录： namenode， datanode
namenode: 可以在当前节点中创建几个 namenode的多目录， 就是 虽说可以是多个目录，但是这个namenode多目录中，内容都是一样， 就相当把namenode， 多份保证他高可靠， 但是这个没有必要，因为namenode，由于是单节点，为防止单节点的风险，往往会与zookeeper配置建立，namenode集群， 只有一个namenode（leader）工作，其他namenode默默将（leader）同步过来。以防止 namenode挂了，及时顶替。
datanode： 会使用多目录， 因为这个多目录中存储的内容不一样。 并且dataNode中的数据量往往都很大。 并且存储在不同的磁盘上。所以就需要将这些磁盘和datanode的存储目录关联起来。 这种关联，我们称之为挂载。就是创建目录， 把某块磁盘挂载到这个目录上。（就相当于windows中，我们创建快捷方式）
1.namenode的本地目录可以配置多个,每个目录相同,增加可靠性在hdfs-site.xml文件中增加
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///${hadoop.tmp.dir}/dfs/name1,
file:///${hadoop.tmp.dir}/dfs/name2</value>
</property>
2配置之前,一定要先停止集群,在删除原来的数据,再格式化
!!!格式化生成目录与之前的目录不冲突即可!!
# stop-yarn.sh
# stop-dfs.sh
# rm -rf data/ logs/
# rm -rf data/ logs/
# rm -rf data/ logs/
# hdfs namenode -format
启动NN出现data/
# rm -rf data/
删除原先的存储路径设置
增加hdfs-site.xm
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>
</property>
分发一下
hdfs-site.xml
注意：每台服务器挂载的磁盘不一样，所以每个节点的多目录配置可以不一致。单独配置即可。
2集群数据均衡
1）节点间数据均衡
start-balancer.sh -threshold 10
对于参数10，代表的是集群中各个节点的磁盘空间利用率相差不超过10%，可根据实际情况进行调整。停止数据均衡命令：
stop-balancer.sh
2）磁盘间数据均衡
（1）生成均衡计划（我们只有一块磁盘，不会生成计划）
（2）执行均衡计划
（3）查看当前均衡任务的执行情况
（4）取消均衡任务
hdfs diskbalancer -plan node3
hdfs diskbalancer -execute node3.plan.json
hdfs diskbalancer -query node3
hdfs diskbalancer -cancel node3.plan.json
3 LZO 压缩配置
1）hadoop 本身并不支持 lzo 压缩，故需要使用 twitter 提供的 hadoop-lzo 开源组件。hadoop-lzo需依赖 hadoop 和 lzo 进行编译，编译步骤如下。
2）将编译好后的 hadoop-lzo-0.4.20.jar 放入
[itwise@node2 ~]$ cd /opt/module/hadoop3.1.3/share/hadoop/common/
3）同步 hadoop-lzo-0.4.20.jar 到 node3、node4
[itwise@node2 common]$ xsync hadoop-lzo-0.4.20.jar
4）core-site.xml 增加配置支持 LZO 压缩
cd /opt/module/hadoop-3.1.3/etc/hadoop/
[itwise@node2 hadoop]$vim core-site.xml
配置如下:
<configuration>
<property>
<name>io.compression.codecs</name>
<value>
org.apache.hadoop.io.compress.GzipCodec,
org.apache.hadoop.io.compress.DefaultCodec,
org.apache.hadoop.io.compress.BZip2Codec,
org.apache.hadoop.io.compress.SnappyCodec,
com.hadoop.compression.lzo.LzoCodec,
com.hadoop.compression.lzo.LzopCodec
</value>
</property>
<property>
<name>io.compression.codec.lzo.class</name>
<value>com.hadoop.compression.lzo.LzoCodec</value>
</property>
</configuration>
5）同步 core-site.xml 到 node3、node4
[itwise@node2 hadoop]$ my_rsync.sh core-site.xml
6）启动及查看集群
[itwise@node2 hadoop-3.1.3]$ sbin/start-dfs.sh
[itwise@node3 hadoop-3.1.3]$ sbin/start-yarn.sh
LZO 创建索引
创建 LZO 文件的索引，LZO 压缩文件的可切片特性依赖于其索引，故我们需要手动为LZO 压缩文件创建索引。若无索引，则 LZO 文件的切片只有一个。
测试
（1）将 bigtable.lzo（200M）上传到集群的根目录
[itwise@node2 module]$ hadoop fs -mkdir /input
[itwise@node2 module]$ hadoop fs -put bigtable.lzo /input
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce example-3.1.3.jar wordcount /input /output-lzo
并没有进行压缩，而仅仅是普通的MR程序，将统计结果输出到output-lzo
（2）执行 wordcount 程序并压缩,我们找一个大文件：bigtable.lzo,直接上传到 input目录中我们找一个大文件：bigtable.lzo,直接上传到 input目录中
mapreduce.output.fileoutputformat.compress 文件输出格式
mapreduce.output.fileoutputformat.compress.codec 文件输出的压缩方式
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduceexamples-3.1.3.jar wordcount -Dmapreduce.output.fileoutputformat.compress=true -
Dmapreduce.output.fileoutputformat.compress.codec=com.hadoop.compression.lzo.Lzo
pCodec /input /lzo-output
可以看到文件压缩是成功了，没有问题， 但是这个文件比较大 超过214.16M>128M, 应该进行分块，但是其实，是否对数据进行分块，这个需要索引配置：
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount -Dmapreduce.output.fileoutputfotmat.compress = true -Dmapreduce.output.fileoutputformat.compress.codec=com.hadoop.compression.1zo.Lzopcodec/input /1zo-output
（3）对上传的 LZO 文件建索引
[itwise@node2 ]$ hadoop jar/opt/module/hadoop3.1.3/share/hadoop/common/hadoop-lzo-0.4.20.jar com.hadoop.compression.lzo.DistributedLzoIndexer/input/bigtable.lzo
（4）创建LZO文件的索引，LZO压缩文件的可切片特性依赖于其索引，故我们需要手动为LZO压缩文件创建索引。若无索引，则LZO文件的切片只有一个。创建一个目录 lzo-input,把测试的数据上传到这个目录中。再次执行 WordCount 程序
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/common/hadoop-lzo-0.4.20.jar
com.hadoop.compression.lzo.DistributedLzoIndexer /lzo-input/bigtable.lzo
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduceexamples-3.1.3.jar wordcount -
Dmapreduce.job.inputformat.class=com.hadoop.mapreduce.LzoTextInputFormat /lzo-input /lzo-output
[itwise@node2 module]$ hadoop jar/opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar
wordcount -Dmapreduce.job.inputformat.class=com.hadoop.mapreduce.LzoText InputFormat /input /output2
注意：如果以上任务，在运行过程中报如下异常
Container [pid=8468,containerID=container_1594198338753_0001_01_000002] is running 318740992B beyond the 'VIRTUAL' memory limit. Current usage: 111.5 MB of 1 GB physical memory used; 2.4 GB of 2.1 GB virtual memory used. Killing container.
Dump of the process-tree for container_1594198338753_0001_01_000002 :
解决办法：在node2的/opt/module/hadoop-3.1.3/etc/hadoop/yarn-site.xml文件中增加如下配置，然后分发到node3、node4服务器上，并重新启动集群
<!--是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是
true -->
<property>
<name>yarn.nodemanager.pmem-check-enabled</name>
<value>false</value>
</property>
<!--是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是
true -->
<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
</property>:
4.基准测试
1） 测试HDFS写性能:注意写入6个文件,只能读取6个
测试内容：向HDFS集群写6个128M的文件
[itwise@node2 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 6 -fileSize 128MB
2）测试HDFS读性能
测试内容：读取HDFS集群6个128M的文件
[itwise@node2 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 6 -fileSize 128MB
错误读取:例题是10个文件,但是自己写入的是6个
3)删除测试生成数据
[itwise@node2 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean
4）使用Sort程序评测MapReduce(自己电脑未测试)
（1）使用RandomWriter来产生随机数，每个节点运行10个Map任务，每个Map产生大约1G大小的二
进制随机数
[itwise@node2 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar randomwriter random-data
（2）执行Sort程序
[itwise@node2 mapreduce]$ hadoop jar /opt/module/hadoop-
3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar sort random data sorted-data
（3）验证数据是否真正排好序了
[itwise@node2 mapreduce]$ hadoop jar /opt/module/hadoop-
3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar testmapredsort -sortInput random-data -sortOutput sorted-data
Hadoop参数调优
1）HDFS参数调优hdfs-site.xml
The number of Namenode RPC server threads that listen to requests from clients.If dfs.namenode.servicerpc-address is not configured then Namenode RPC server threads listen to requests from all nodes.
NameNode有一个工作线程池，用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。
对于大集群或者有大量客户端的集群来说，通常需要增大参数dfs.namenode.handler.count的默认值10。
<property>
<name>dfs.namenode.handler.count</name>
<value>10</value>
</property>
[itwise@node2 ~]$ python
#Python 2.7.5 (default, Apr 11 2018, 07:36:10)
#[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on
#linux2 Type "help", "copyright", "credits" or "license" for more information.
#导入包
>>> import math
#输出到控制台
>>> print int(20*math.log(8))
41
>>> print int(20*math.log(10))
46
退出
>>>quit()
2）YARN参数调优yarn-site.xml
（1）情景描述：总共7台机器，每天几亿条数据，数据源->Flume->Kafka->HDFS->Hive
面临问题：数据统计主要用HiveSQL，没有数据倾斜，小文件已经做了合并处理，开启的JVM重用，而且IO没有阻塞，内存用了不到50%。但是还是跑的非常慢，而且数据量洪峰过来时，整个集群都会宕掉。基于这种情况有没有优化方案。
（2）解决办法：
内存利用率不够。这个一般是Yarn的2个配置造成的，单个任务可以申请的最大内存大小，和Hadoop单个节点可用内存大小。调节这两个参数能提高系统内存的利用率。
（a）yarn.nodemanager.resource.memory-mb
表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。
（b）yarn.scheduler.maximum-allocation-mb
单个任务可申请的最多物理内存量，默认是8192（MB）。
用了不到50%。但是还是跑的非常慢，而且数据量洪峰过来时，整个集群都会宕掉。基于这种情况有没有优化方案。
（2）解决办法：
内存利用率不够。这个一般是Yarn的2个配置造成的，单个任务可以申请的最大内存大小，和Hadoop单个节点可用内存大小。调节这两个参数能提高系统内存的利用率。
（a）yarn.nodemanager.resource.memory-mb
表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。
（b）yarn.scheduler.maximum-allocation-mb
单个任务可申请的最多物理内存量，默认是8192（MB）。
