Hadoop——項目經驗

一、HDFS存儲多目錄

（1）給Linux系統新增加一塊硬盤

參考：https://www.cnblogs.com/yujianadu/p/10750698.html

（2）生產環境服務器磁盤情況

（3）在hdfs-site.xml文件中配置多目錄，注意新掛載磁盤的訪問權限問題

HDFS的DataNode節點保存數據的路徑由dfs.datanode.data.dir參數決定，其默認值爲file://${hadoop.tmp.dir}/dfs/data，若服務器有多個磁盤，必須對該參數進行修改。如服務器磁盤如上圖所示，則該參數應修改爲如下的值。

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

注意：因爲每臺服務器節點的磁盤情況不同，所以這個配置配完之後，不需要分發

二、集羣數據均衡

2.1 節點間數據均衡

（1）開啓數據均衡命令

start-balancer.sh -threshold 10

對於參數10，代表的是集羣中各個節點的磁盤空間利用率相差不超過10%，可根據實際情況進行調整。

（2）停止數據均衡命令

stop-balancer.sh

注意：由於HDFS需要啓動單獨的Rebalance Server來執行Rebalance操作，所以儘量不要在NameNode上執行start-balancer.sh，而是找一臺比較空閒的機器。

2.2 磁盤間數據均衡

（1）生成均衡計劃（我們只有一塊磁盤，不會生成計劃）

hdfs diskbalancer -plan hadoop103

（2）執行均衡計劃

hdfs diskbalancer -execute hadoop103.plan.json

（3）查看當前均衡任務的執行情況

hdfs diskbalancer -query hadoop103

（4）取消均衡任務

hdfs diskbalancer -cancel hadoop103.plan.json

三、支持LZO壓縮配置

LZO 是致力於解壓速度的一種數據壓縮算法，LZO 是 Lempel-Ziv-Oberhumer 的縮寫。這個算法是無損算法，參考實現程序是線程安全的。 實現它的一個自由軟件工具是lzop。最初的庫是用 ANSI C 編寫、並且遵從 GNU通用公共許可證發佈的。LZO 有用於 Perl、Python 以及 Java 的各種版本。代碼版權的所有者是 Markus F. X. J. Oberhumer。

3.1 hadoop-lzo編譯

hadoop本身並不支持lzo壓縮，故需要使用twitter提供的hadoop-lzo開源組件。hadoop-lzo需依賴hadoop和lzo進行編譯，編譯步驟如下。

環境準備

maven（下載安裝，配置環境變量，修改sitting.xml加阿里雲鏡像）
gcc-c++
zlib-devel
autoconf
automake
libtool
通過yum安裝即可，yum -y install gcc-c++ lzo-devel zlib-devel autoconf automake libtool

下載、安裝並編譯LZO

wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.10.tar.gz

tar -zxvf lzo-2.10.tar.gz

cd lzo-2.10

./configure -prefix=/usr/local/hadoop/lzo/

make

make install

編譯hadoop-lzo源碼

下載hadoop-lzo的源碼，下載地址：https://github.com/twitter/hadoop-lzo/archive/master.zip

解壓之後，修改pom.xml

 <hadoop.current.version>3.1.3</hadoop.current.version>

聲明兩個臨時環境變量

     export C_INCLUDE_PATH=/usr/local/hadoop/lzo/include
     export LIBRARY_PATH=/usr/local/hadoop/lzo/lib 

編譯
    進入hadoop-lzo-master，執行maven編譯命令

    mvn package -Dmaven.test.skip=true

進入target，hadoop-lzo-0.4.21-SNAPSHOT.jar 即編譯成功的hadoop-lzo組件

 

3.2 hadoop-lzo安裝、測試

將編譯好後的hadoop-lzo-0.4.20.jar 放入hadoop-3.1.3/share/hadoop/common/

[atguigu@hadoop102 common]$ pwd
/opt/module/hadoop-3.1.3/share/hadoop/common
[atguigu@hadoop102 common]$ ls
hadoop-lzo-0.4.20.jar

同步hadoop-lzo-0.4.20.jar到hadoop103、hadoop104

[atguigu@hadoop102 common]$ xsync hadoop-lzo-0.4.20.jar

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>

同步core-site.xml到hadoop103、hadoop104

[atguigu@hadoop102 hadoop]$ xsync core-site.xml

啓動及查看集羣

[atguigu@hadoop102 hadoop-3.1.3]$ sbin/start-dfs.sh
[atguigu@hadoop103 hadoop-3.1.3]$ sbin/start-yarn.sh

測試-數據準備

[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -mkdir /input
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -put README.txt /input

 

測試-壓縮

[atguigu@hadoop102 hadoop-3.1.3]$ hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount -Dmapreduce.output.fileoutputformat.compress=true -Dmapreduce.output.fileoutputformat.compress.codec=com.hadoop.compression.lzo.LzopCodec  /input /output

生成了對應的lzo壓縮文件

四、LZO創建索引

4.1 創建LZO文件的索引

LZO壓縮文件的可切片特性依賴於其索引，故我們需要手動爲LZO壓縮文件創建索引。若無索引，則LZO文件的切片只有一個。

hadoop jar /path/to/your/hadoop-lzo.jar com.hadoop.compression.lzo.DistributedLzoIndexer big_file.lzo

4.2 測試

（1）將bigtable.lzo（200M）上傳到集羣的根目錄

[atguigu@hadoop102 module]$ hadoop fs -mkdir /input
[atguigu@hadoop102 module]$ hadoop fs -put bigtable.lzo /input

（2）執行wordcount程序

[atguigu@hadoop102 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.LzoTextInputFormat /input /output1

明明是lzo文件，卻沒有支持切片？

（3）對上傳的LZO文件建索引

[atguigu@hadoop102 module]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/common/hadoop-lzo-0.4.20.jar  com.hadoop.compression.lzo.DistributedLzoIndexer /input/bigtable.lzo

（4）再次執行WordCount程序

[atguigu@hadoop102 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.LzoTextInputFormat /input /output2

4.3 問題

注意：如果以上任務，在運行過程中報如下異常

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 :

解決辦法：在hadoop102的/opt/module/hadoop-3.1.3/etc/hadoop/yarn-site.xml文件中增加如下配置，然後分發到hadoop103、hadoop104服務器上，並重新啓動集羣。
<!--是否啓動一個線程檢查每個任務正使用的虛擬內存量，如果任務超出分配值，則直接將其殺掉，默認是true -->

<property>
   <name>yarn.nodemanager.vmem-check-enabled</name>
   <value>false</value>
</property>

五、基準測試

在企業中非常關心每天從Java後臺拉取過來的數據，需要多久能上傳到集羣？消費者關心多久能從HDFS上拉取需要的數據？

爲了搞清楚HDFS的讀寫性能，生產環境上非常需要對集羣進行壓測。

HDFS的讀寫性能主要受網絡和磁盤影響比較大。爲了方便測試，將hadoop102、hadoop103、hadoop104虛擬機網絡都設置爲100mbps。

100Mbps單位是bit；10M/s單位是byte ; 1byte=8bit，100Mbps/8=12.5M/s。

測試網速：
（1）來到hadoop102的/opt/module目錄，創建一個

[atguigu@hadoop102 software]$ python -m SimpleHTTPServer

 開啓一個Python服務。

（2）在Web頁面上訪問
hadoop102:8000

 

 

 點擊一個文件下載，查看下載速度

 

 

 下載速度符合預期

 

5.1 測試HDFS寫性能

（1）寫測試底層原理

（2）測試內容：向HDFS集羣寫10個128M的文件

 

[atguigu@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB

2021-02-09 10:43:16,853 INFO fs.TestDFSIO: ----- TestDFSIO ----- : write
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:             Date & time: Tue Feb 09 10:43:16 CST 2021
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:         Number of files: 10
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:  Total MBytes processed: 1280
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:       Throughput mb/sec: 1.61
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:  Average IO rate mb/sec: 1.9
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:   IO rate std deviation: 0.76
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:      Test exec time sec: 133.05
2021-02-09 10:43:16,854 INFO fs.TestDFSIO:

注意：nrFiles n爲生成mapTask的數量，生產環境一般可通過hadoop103:8088查看CPU核數，設置爲（CPU核數 -  1）

這裏每臺虛擬機都是4核的，三臺共12核，測試程序運行還要佔用一個核，所以設置成11或10，較爲恰當。

• Number of files：生成mapTask數量，一般是集羣中（CPU核數 - 1），我們測試虛擬機就按照實際的物理內存-1分配即可。（目標，讓每個節點都參與測試）
• Total MBytes processed：單個map處理的文件大小
• Throughput mb/sec:單個mapTak的吞吐量

計算方式：處理的總文件大小/每一個mapTask寫數據的時間累加
集羣整體吞吐量：生成mapTask數量*單個mapTak的吞吐量

• Average IO rate mb/sec::平均mapTak的吞吐量

計算方式：每個mapTask處理文件大小/每一個mapTask寫數據的時間 全部相加除以task數量

• IO rate std deviation:方差、反映各個mapTask處理的差值，越小越均衡

注意：如果測試過程中，出現異常
①可以在yarn-site.xml中設置虛擬內存檢測爲false

<!--是否啓動一個線程檢查每個任務正使用的虛擬內存量，如果任務超出分配值，則直接將其殺掉，默認是true -->
<property>
     <name>yarn.nodemanager.vmem-check-enabled</name>
     <value>false</value>
</property>

②分發配置並重啓Yarn集羣

（3）測試結果分析
    ①由於副本1就在本地，所以該副本不參與測試

一共參與測試的文件：10個文件 * 2個副本 = 20個
壓測後的速度：1.61
實測速度：1.61M/s * 20個文件 ≈ 32M/s
三臺服務器的帶寬：12.5 + 12.5 + 12.5 ≈ 30m/s
所有網絡資源都已經用滿。

如果實測速度遠遠小於網絡，並且實測速度不能滿足工作需求，可以考慮採用固態硬盤或者增加磁盤個數。

  ②如果客戶端不在集羣節點，那就三個副本都參與計算

5.2 測試HDFS讀性能

（1）測試內容：讀取HDFS集羣10個128M的文件

[atguigu@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB

2021-02-09 11:34:15,847 INFO fs.TestDFSIO: ----- TestDFSIO ----- : read
2021-02-09 11:34:15,847 INFO fs.TestDFSIO:             Date & time: Tue Feb 09 11:34:15 CST 2021
2021-02-09 11:34:15,847 INFO fs.TestDFSIO:         Number of files: 10
2021-02-09 11:34:15,847 INFO fs.TestDFSIO:  Total MBytes processed: 1280
2021-02-09 11:34:15,848 INFO fs.TestDFSIO:       Throughput mb/sec: 200.28
2021-02-09 11:34:15,848 INFO fs.TestDFSIO:  Average IO rate mb/sec: 266.74
2021-02-09 11:34:15,848 INFO fs.TestDFSIO:   IO rate std deviation: 143.12
2021-02-09 11:34:15,848 INFO fs.TestDFSIO:      Test exec time sec: 20.83

（2）刪除測試生成數據

[atguigu@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean

（3）測試結果分析：爲什麼讀取文件速度大於網絡帶寬？由於目前只有三臺服務器，且有三個副本，數據讀取就近原則，相當於都是讀取的本地磁盤數據，沒有走網絡。

5.3 使用Sort程序評測MapReduce

（1）使用RandomWriter來產生隨機數，每個節點運行10個Map任務，每個Map產生大約1G大小的二進制隨機數

[atguigu@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar randomwriter random-data

（2）執行Sort程序

[atguigu@hadoop102 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）驗證數據是否真正排好序了

[atguigu@hadoop102 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

 

 

 

 

 

 

4.2.6 項目經驗之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>
dfs.namenode.handler.count=，比如集羣規模爲8臺時，此參數設置爲41。可通過簡單的python代碼計算該值，代碼如下。
[atguigu@hadoop102 ~]$ 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
>>> quit()
2）YARN參數調優yarn-site.xml
（1）情景描述：總共7臺機器，每天幾億條數據，數據源->Flume->Kafka->HDFS->Hive
面臨問題：數據統計主要用HiveSQL，沒有數據傾斜，小文件已經做了合併處理，開啓的JVM重用，而且IO沒有阻塞，內存用了不到50%。但是還是跑的非常慢，而且數據量洪峯過來時，整個集羣都會宕掉。基於這種情況有沒有優化方案。
（2）解決辦法：
NodeManager內存和服務器實際內存配置儘量接近，如服務器有128g內存，但是NodeManager默認內存8G，不修改該參數最多隻能用8G內存。NodeManager使用的CPU核數和服務器CPU核數儘量接近。
①yarn.nodemanager.resource.memory-mb    NodeManager使用內存數
②yarn.nodemanager.resource.cpu-vcores    NodeManager使用CPU核數