Hadoop近期學(xué)習(xí)與工作的心得與體會

      hadoop的學(xué)習(xí)與工作按計劃有序進行，根據(jù)計劃第二階段的學(xué)習(xí)可以告一段落，現(xiàn)在對這一階段的學(xué)習(xí)與工作做個總結(jié)。

      首先，我講一下我理解的hadoop是什么。我理解的hadoop是一個生態(tài)圈，這個生態(tài)圈有核心，有周邊。核心就是hadoop的mapreduce計算框架與hdfs分布式文件系統(tǒng)。周邊呢，有列式數(shù)據(jù)庫hbase，數(shù)據(jù)倉庫系統(tǒng)hive，與腳本語言pig以及機器學(xué)習(xí)工具mahout。此外還有重要的數(shù)據(jù)加載工作flume以及chukuwa，還有其它的組件目前還尚未了解。

      那么為什么使用hadoop呢？

      我從hadoop的兩個核心組件mapreduce計算框架與hdfs文件系統(tǒng)來理解。

hadoop的只有一個小小的抱負，那就是計算搜索引擎中的“頁面價值”（page rank），它將網(wǎng)頁的海量頁面抽象成平面向量，以頁面被其它頁面的引用作為向量值，假設(shè)頁面數(shù)據(jù)為n，那就形成n*n的對稱矩陳，可以想象頁面n的值非常的大，單機運算很難求出結(jié)果，因此就需要一種分布式的計算方法來達到這一運算需求，于是就有了mapreduce。另外一個問題就是海量數(shù)據(jù)如何存放的問題以及這些海量數(shù)據(jù)的可靠性的問題，對這些問題的回答，有一些回答其中就有raid技術(shù)、網(wǎng)格計算以及傳統(tǒng)rdbms等。

      對于raid技術(shù)，其實是這種海量存儲的一種可選方案，但是raid技術(shù)有問題，第一個問題就是raid技術(shù)并不能提高數(shù)據(jù)的吞吐能力，而海量數(shù)據(jù)明顯有這方面的需要，第二個問題就是raid技術(shù)對硬件有要求，往往需要較高的性能以及同廠商同型號甚至同批次，第三個問題是一旦raid中有磁盤故障，訪問速度立即大輻下降。此外raid技術(shù)實際并不完全可靠，raid中磁盤全部故障的情況并不少見。

      以及網(wǎng)格計算為代表的規(guī)模處理框架可能也是一種方案，但無論是網(wǎng)絡(luò)計算還是高性能計算都是使用SAN（存儲區(qū)域）技術(shù)進行運行的，也就是使用共享存儲的方式進行，那么這種方式存在的問題顯而易見，第一個問題就是數(shù)據(jù)必須本地化才能夠執(zhí)行，那么節(jié)點的網(wǎng)絡(luò)帶寬就是該系統(tǒng)的瓶頸，只能訪問百G規(guī)模的數(shù)據(jù)，而這個規(guī)模才是mapreduce開始發(fā)力的規(guī)模。

      那么傳統(tǒng)rdbms系統(tǒng)的表現(xiàn)如何呢？

      在說明這個問題之前我們先談一下硬盤，時至今日，我們在存儲大規(guī)模數(shù)據(jù)時，仍然使用硬盤。硬盤的有兩個問題至今未有實質(zhì)性的解決。

      第一，硬盤容量與訪問速度的不平衡發(fā)展，我們用一個列表來做對比。

      第二，硬盤尋址速度與傳輸速度的不平衡發(fā)展。也就是磁盤尋址時間的提升遠遠不及傳輸速率的提升，其原因是尋址是物理操作，而傳輸則取決于硬盤的帶寬。

      那么再說一下rdmbs系統(tǒng)，rdmbs系統(tǒng)的數(shù)據(jù)一般行式存儲，以Oracle為例，分段區(qū)塊存儲，一行數(shù)據(jù)往往比較小，為了精確定位到某一條具體的數(shù)據(jù)，oracle把塊設(shè)置的比較小，通常為一個或多個操作系統(tǒng)塊。那么方式尋址就是決定其性能的主要因素，而不是訪問的數(shù)據(jù)，因為比較小。如果是少量數(shù)據(jù)查詢或更新，那么就有比較有優(yōu)勢，因為她采用B樹索引精確定位。但是如果是大量的數(shù)據(jù)查詢或者更新，這種方式就比較落后，因為她需要不停地使用“排序/合并”(sort/merge)來重建數(shù)據(jù)庫。

      那么， hadoop是如何解決這些問題的呢？在存儲上，hadoop采用了類似raid的技術(shù)，那就是冗余技術(shù)，不同的是，hadoop hdfs采用了更高效合理的做法，以兩份冗余為例，hdfs上會有三份數(shù)據(jù)，hadoop把第一份數(shù)據(jù)保存在本地上，就是執(zhí)行保存操作的那個hdfs客戶端上，一份保存在與第一份數(shù)據(jù)在同一機架的不同結(jié)點上，第三份則是保存在不同機架的隨機結(jié)點上，另外對大文件以一定的算法進行分割后再進行保存，這就大大的降低了數(shù)據(jù)丟失的可能性了。 該存儲方式也解決了分布式運算中存在的數(shù)據(jù)本地化的問題，當任務(wù)降臨時，hadoop會優(yōu)先把任務(wù)本地化，假設(shè)集群中的所有結(jié)點都有這個任務(wù)源文件的分片，那么就可以在本地執(zhí)行任務(wù)，而不用進行數(shù)據(jù)的傳輸了，從而節(jié)省了帶寬，這種運算方式對比網(wǎng)格計算就能看到它的優(yōu)勢所在了。

      在應(yīng)對磁盤在容量與傳輸速度以及尋址與傳輸發(fā)展不平衡的問題上，hadoop采用了大塊的存儲方式，早期hdfs的版本為64MB，而在hadoop2，即yarn的版本上，我觀察到其默認的塊大小已經(jīng)為128MB了。 hadoop這種設(shè)計方式是為大數(shù)據(jù)的高吞吐而設(shè)計的，這種設(shè)計的依據(jù)是大數(shù)據(jù)往往以整個數(shù)據(jù)集作為分析的目標，此時磁盤尋址已經(jīng)不是主要問題，帶寬則是限制其性能的主要因素了。

hadoop的這種設(shè)計有效規(guī)避了rdbms由磁盤尋址帶來的性能問題。但hadoop的這種技術(shù)偏好是極其明顯的，一是高吞吐帶來的高延時，二是只適合于類似于系統(tǒng)日志的一次寫入多次讀取的場景，而對于隨機讀寫的場合，則力所不及。

      那么，hadoop用于何種場合呢？

      hadoop最初僅僅有一個小小的抱負，那就是從海量的網(wǎng)頁中取出最有價值的部分網(wǎng)頁提供給用戶，而今卻是廣泛應(yīng)用于各行各業(yè)了。大致有以下幾種企業(yè)會用：

      搜索引擎企業(yè)，yahoo、百度等。

      互聯(lián)網(wǎng)企業(yè)，如阿里、京東、騰訊等。

      電信運營商，移動、電信等。

      金融，四大行、以及部分保險公司。

      快遞，近些年，快遞行業(yè)的數(shù)據(jù)量也是海量增長。

      電力水力，智能電力、智能電網(wǎng)等。

      此外，hadoop有明顯的技術(shù)偏好，適用離線日志分析、大數(shù)據(jù)批量處理的場景，那就意味著不能對響應(yīng)速度有要求。如果需要實時分析、實時處理的場景，恐怕需要其它框架。

      最后，結(jié)合實際的工作，說一下咱們這邊hadoop的使用情況。

      許紀給出源數(shù)據(jù)文件和轉(zhuǎn)換程序，我們通過轉(zhuǎn)換程序生成csv數(shù)據(jù)文件，保存在windows的服務(wù)器上。 hadoop集群上有三個節(jié)點，我在三個節(jié)點上安裝了samba服務(wù)，建立了hadoop集群各節(jié)點與windows服務(wù)器的磁盤文件映射，這個工作是為了節(jié)省一部分磁盤空間。在hadoop集群各節(jié)點上又安裝了lzo壓縮程序。有了samba服務(wù)之后，hadoop節(jié)點可以訪問windows的文件了，我們把csv數(shù)據(jù)文件所在的目錄掛載到hadoop節(jié)點上，并使用lzo算法按年把csv壓縮成一個lzo文件。然后在hdfs上按年建立一個文件夾，將生成的當年的lzo文件存放在該文件夾下， 并建立該lzo文件的索引。 hadoop集群中也加入了lzo壓縮的配置，因此能夠讀取該lzo文件，并進行更新作業(yè)。更新作業(yè)的源程序里也指定輸入格式為lzo文件，以輸出為lzo文件。到這里更新操作已經(jīng)完成，生成了lzo文件作為輸出。在hive建表時，也指定以lzo文件作為數(shù)據(jù)來源。這樣的話，我們生成的lzo文件就可以順利地加載到hive中去。數(shù)據(jù)到hive之后，我們就可以使用hive的導(dǎo)出命令將id批量的導(dǎo)出到該節(jié)點的文件系統(tǒng)中，所在文件夾由samba服務(wù)的存在可以由windows服務(wù)器訪問，就可以復(fù)制到磁盤或U盤中了。

      該過程如下圖所示：

       圖1

      最后，談一下這一階段存在的問題以及困難，以及下一階段學(xué)習(xí)與工作的計劃安排。

      雖然解決了部分工作，但對hadoop存在的問題和困惑還是不少的，雖然查閱了不少資料，并且也在網(wǎng)上請教了一些人，一些問題和困惑至今未得到解答。

      首先的問題是，在做更新時，如果使用了reduce操作，在reduce操作達到33%左右時，卡住不動了，查看一下集群中的Contrainer，發(fā)現(xiàn)三個結(jié)點居然只有一個Yarn-master和一個yarn-child，而在map階段通常集群中會有12個contrainer，其中有一個yarn-master，11個yarn-child。

      其次，在使用MultiOutputs時，常常會交替出現(xiàn)如下三個錯誤：

      1、GC overheadlimit exceeded

     2、Java heap spacehadoop

   3、Error unableto create new native thread

      查看一下內(nèi)存使用情況，卻沒有出現(xiàn)內(nèi)存占用特別高的情況，【網(wǎng)上有關(guān)于jvm最多創(chuàng)建多少個線程的說法】。

      還有一個問題，就是中文支持的問題，目前我們的工作中只有英文，實際的分析操作有可能是中文的，如果對中文分析的話，現(xiàn)在的程序會報錯，網(wǎng)上有些解決方法，但是目前沒有試驗成功。

      最后一個問題是，當初在選型時，是以hbase作標準的，也就是說以hbase的版本選擇hadoop版本，最初使用的hbase版本為hbase-1.2.1，對hadoop支持最好的是hadoop-2.5.1，所以無論在測試還是實際使用，都沿用這個版本，導(dǎo)致如今使用的版本過高，一些組件如sqoop-1.4.6或sqoop-1.4.5與之不兼容，目前我正考慮降低版本使用如hadoop-2.2.0。

      學(xué)習(xí)與工作中也存在困難，第一個困難莫過于自己摸索，遇到如上的問題解答不了。

      第二個困難是，目前的集群環(huán)境仍然在虛擬機中進行，當虛擬機過大時，會生成幾百GB的大文件，如果突然斷電，這些文件又沒有正常關(guān)閉，那么這個虛擬機就會啟動不開，并且這個大文件將無法刪除，一直駐留在windows服務(wù)器上，除非重新安裝系統(tǒng)，格式化文件。

      最后，談一下一階段的學(xué)習(xí)與工作安排。

      下一階段主要的任務(wù)是mapreduce的編程，有人提議要研究100個場景才算熟練的編程，我認為尋找典型的場景比數(shù)目更重要吧，比如多個map或多個reduce的編程、多個job的編程、以及使用特別組件如MultiOutputs的編程等。

      另外尋找實際的項目資料，看看人家是如何架構(gòu)這些分析系統(tǒng)或者數(shù)據(jù)倉庫的，各個組件間是如何聯(lián)系使用的，為將來的架構(gòu)工作做準備。