Hadoop實施已經(jīng)有快一個月了，對Hadoop的概念理解、使用，Linux與shell腳本，甚至mysql都有了更多的理解。
項目背景：用于互聯(lián)網(wǎng)信息收集后的關(guān)鍵詞匹配與內(nèi)容提取。
主要系統(tǒng)架構(gòu)分為互聯(lián)網(wǎng)爬蟲、分析、業(yè)務(wù)應(yīng)用三塊：
簡單架構(gòu)描述
由于我在當(dāng)中的角色主要負(fù)責(zé)分析架構(gòu)的搭建，所以其他兩塊都畫得簡單，下面也不會過多的描述。
Hadoop理解：提到Hadoop都想到的是云、分布式計算，在一段時間的實施之后有了一些具體的理解。
Hadoop的優(yōu)勢：
針對性能指標(biāo)，當(dāng)業(yè)務(wù)數(shù)據(jù)量總量或增速上升到一定級別，依靠關(guān)系型數(shù)據(jù)庫一定無法支持。對于非關(guān)系型數(shù)據(jù)庫，包括Nosql和Solr一類存儲方式，稍顯復(fù)雜，對于機器集群性能要求偏高（相對于文件系統(tǒng)）。從數(shù)據(jù)使用模式上來講，目前海量數(shù)據(jù)的常常是不包含復(fù)雜邏輯的簡單統(tǒng)計整理（比如上述系統(tǒng)中的關(guān)鍵詞匹配）。這時候文件系統(tǒng)的優(yōu)勢反而比較明顯（結(jié)構(gòu)簡單，邏輯簡單）。
如上述系統(tǒng)的應(yīng)用場景是怎么樣的呢，在一個強大的爬蟲系統(tǒng)之下，每個小時的數(shù)據(jù)增量在G到10G的級別，需要搜索所有的文件，獲取關(guān)鍵字的匹配，并且對匹配內(nèi)容進(jìn)行摘要。很類似我們windows里面的搜索功能，需要解決的就是如何在這樣增幅的文件系統(tǒng)之下，如何滿足業(yè)務(wù)系統(tǒng)的需求。
對分析系統(tǒng)有什么要求呢？
l 能夠建立集群，分布式的保存數(shù)據(jù)文件內(nèi)容（統(tǒng)一控制，可配置）。
l 有一定的保護(hù)機制，保證數(shù)據(jù)或節(jié)點丟失不會影響系統(tǒng)使用。
l 如果有一個任務(wù)腳本執(zhí)行框架機制就好了（用于并行計算）。
l 能夠進(jìn)行節(jié)點間的數(shù)據(jù)均衡。
l 能夠簡單的查看所有的狀態(tài)與日志（web客戶端）
可能主要是這些了。若自己實現(xiàn)，確實是個復(fù)雜而龐大的工程，現(xiàn)在我們有了Hadoop。
系統(tǒng)物理架構(gòu)：
我們使用了一臺服務(wù)器，利用虛擬化，安裝了7套64x位的CentOS。一個Namenode，6個Datanode，復(fù)制數(shù)設(shè)置為3。每個系統(tǒng)分配到一個cpu，2G內(nèi)存，Datanode掛載了500G的存儲空間。
理想的Hadoop的搭建環(huán)境，參照《Best Practices for Selecting Apache Hadoop Hardware》（http://hortonworks.com/blog/best-practices-for-selecting-apache-hadoop-hardware/）一文，以及一些其他的文章。
CPU：最好是雙CPU，8核左右。不用太高了。
內(nèi)存：推薦48G，但是4G應(yīng)該就可以運行Hadoop了。
硬盤：7200轉(zhuǎn)的SATA硬盤即可，Hadoop很占空間，所以盡量加。
網(wǎng)絡(luò)：內(nèi)部的數(shù)據(jù)交換要求非常高，內(nèi)網(wǎng)最好是千兆網(wǎng)卡，帶寬為1GB。
理想與現(xiàn)實，有錢與沒錢，呵呵。
系統(tǒng)軟件架構(gòu)：
Hadoop：版本使用的是1.0.3，再下來就是2了，為了盡量簡化應(yīng)用，所以不考慮2的新特性。對Hadoop沒有做太多的設(shè)置，基本基于默認(rèn)。70為Namenode，71-76為Datanode。
JDK：1.6.0_33 （64x）
系統(tǒng)實施過程：
HDFS部分：
爬蟲抓取數(shù)據(jù)，整理后存放在50文件服務(wù)器，70以外部掛載的形式讀取。網(wǎng)頁文件比較小，假如直接寫入Hadoop對Namenode負(fù)載過大，所以入庫前合并，將每小時網(wǎng)頁整合成為一個文件寫入HDFS，由于區(qū)分類別，所以每小時基本寫入10個文件左右，總量在5-8G，耗時在40-50分鐘。（這個過程中，由于爬蟲的IO過于頻繁，導(dǎo)致文件讀取困難，所以做了定時任務(wù)，每小時啟動一次，將需要處理的文件先拷貝到臨時區(qū)域，合并入庫之后再刪除。此處應(yīng)該是受到單核cpu的限制，所有操作均是串行，包括拷貝（cp）和合并入庫（java），所以Namenode嚴(yán)重建議配置稍高。）
此處沒有太多問題。
MapReduce部分：
寫入完成后，進(jìn)行分析工作，MapReduce。此處的工作過程為：數(shù)據(jù)庫定時生成關(guān)鍵詞列表文件。Job執(zhí)行時會讀取列表文件，匹配指定范圍內(nèi)的HDFS文件（過去一小時），匹配出對應(yīng)的表達(dá)式與HTML，Map過程結(jié)束。在Reduce階段，會將Map的所有數(shù)據(jù)入數(shù)據(jù)庫（Mysql）。
此處出現(xiàn)過一些問題，記錄下來。
1. Reduce階段需要加載Mysql的第三方驅(qū)動包。我在三個環(huán)境測試過（公司、家里、發(fā)布環(huán)境），使用 -libjars 一定可以，有的地方不需要也可以。不明確，懷疑與HADOOP_HOME環(huán)境變量有關(guān)。
2. MR過程中使用log4j打印日志，在Hadoop臨時目錄（如果你沒有配置dfs.name.dir，dfs.data.dir,mapred.local.dir.mapred.system.dir等目錄，這些都會在hadoop.tmp.dir當(dāng)中，我就偷懶都沒配置）mapred文件夾中查看一下。
整個過程實際上還是比較簡單的，基本編碼量就在Job的部分，但是一個Java文件就夠了。在目前初級階段應(yīng)該還是比較好用的。現(xiàn)在還沒有測試Job的執(zhí)行效率。完成后會繼續(xù)記錄下來。有什么問題可以提出。我想到什么也會在本文繼續(xù)更新。