第4章 数据采集模块

4.1 Hadoop安装
HDFS专栏有hadoop的群集搭配
4.1.1 项目经验之HDFS存储多目录
若HDFS存储空间紧张，需要对DataNode进行磁盘扩展
1.在DataNode节点增加磁盘并进行挂载

2.在hdfs-site.xml文件中配置多目录，注意新挂载磁盘的网文权限问题

  <name>dfs.datanode.data.dir</name>
<value>file:///${hadoop.tmp.dir}/dfs/data1,file:///hd2/dfs/data2,file:///hd3/dfs/data3,file:///hd4/dfs/data4</value>
</property>

3.增加磁盘后，保证每一个目录数据均衡
开启数据均衡命令：

bin/start-balancer.sh -threshold 10

对于参数10，代表的是集群中各个节点的磁盘空间利用率相差不超过10%，可根据实际情况进行调整
停止数据均衡命令

bin/stop-balancer.sh

4.1.2 项目经验之支持LZO压缩配置
1）先下载lzo的jar项目
https://github.com/twitter/hadoop-lzo/archive/master.zip
2）下载后的文件名是hadoop-lzo-master，它是一个zip格式的压缩包，先进行解压，然后用maven编译。生成hadoop-lzo-0.4.20.jar。
3）将编译好后的hadoop-lzo-0.4.20.jar 放入hadoop-2.7.7/share/hadoop/common/
4）同步hadoop-lzo-0.4.20.jar到hadoop13、hadoop14

xsync hadoop-lzo-0.4.20.jar

5）core-site.xml增加配置支持LZO压缩

<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>

6）同步core-site.xml到hadoop13、hadoop14

xsync core-site.xml

7）启动及查看集群

sbin/start-dfs.sh
sbin/start-yarn.sh

（1）web和进程查看
 Web查看：http://hadoop12:50070
 进程查看：jps查看各个节点状态。
（2）当启动发生错误的时候：
 查看日志：/export/servers/hadoop-2.7.7/logs
 如果进入安全模式，可以通过hdfs dfsadmin -safemode leave
 停止所有进程，删除tmp和log文件夹，然后hdfs namenode -format 来格式化
4.1.3 项目经验之LZO创建索引

1）创建LZO文件的索引，LZO压缩文件的切片特性依赖于其索引，故我们需要手动为LZO压缩文件创建索引。若无索引，则LZO文件的切片只有一个
2）测试
1.将bigtable.lzo(150M）上传到群集的根目录

hadoop fs -mkdir /input
hadoop fs -put bigtable.lzo /input

2.执行wordcount程序

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.7.jar wordcount /input /output1

切片一个
3.对上传的LZO文件创建索引

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/common/hadoop-lzo-0.4.20.jar com.hadoop.compression.lzo.DistributedLzoIndexer /input/bigtable.lzo

4.再次执行Wordcount程序

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.7.jar wordcount /input /output2

切片两个
4.1.4 项目经验之基准测试
1） 测试HDFS写性能
测试内容：向HDFS集群写10个128M的文件

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.7-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB

提问如果1T数据需要好久
1024*1024/19.84秒
2）测试HDFS读性能
测试内容：读取HDFS集群10个128M的文件

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.7-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB

3）删除测试生成数据

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.7-tests.jar TestDFSIO -clean

4）使用Sort程序评测MapReduce
（1）使用RandomWriter来产生随机数，每个节点运行10个Map任务，每个Map产生大约1G大小的二进制随机数

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.7.jar randomwriter random-data

（2）执行Sort程序

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.7.jar sort random-data sorted-data

（3）验证数据是否真正排好序了

hadoop jar /export/servers/hadoop-2.7.7/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.7.jar testmapredsort -sortInput random-data -sortOutput sorted-data

4.1.5 项目经验之Hadoop参数调优
1）HDFS参数调优hdfs-site.xml
（1）dfs.namenode.handler.count=20 * log2(Cluster Size)，比如集群规模为8台时，此参数设置为60
2的三次方
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。设置该值的一般原则是将其设置为集群大小的自然对数乘以20，即20logN，N为集群大小。
（2）编辑日志存储路径dfs.namenode.edits.dir设置与镜像文件存储路径dfs.namenode.name.dir尽量分开，达到最低写入延迟
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）。
3）Hadoop宕机
（1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）
（2）如果写入文件过量造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。高峰期的时候用Kafka进行缓存，高峰期过去数据同步会自动跟上。