Hadoop實(shí)施已經(jīng)有快一個(gè)月了，對Hadoop(1.0.3)的概念理解、使用，Linux 與 Shell腳本，甚至對 Mysql 都有了更多的理解。

項(xiàng)目背景：用于互聯(lián)網(wǎng)信息收集后的關(guān)鍵詞匹配與內(nèi)容提取。

主要系統(tǒng)架構(gòu)分為互聯(lián)網(wǎng)爬蟲、分析、業(yè)務(wù)應(yīng)用三塊：

由于我在當(dāng)中的角色主要負(fù)責(zé)分析架構(gòu)的搭建，所以其他兩塊都畫得簡單，下面也不會(huì)過多的描述。

Hadoop理解：提到Hadoop都想到的是云、分布式計(jì)算，在一段時(shí)間的實(shí)施之后有了一些具體的理解。

Hadoop的優(yōu)勢：

針對性能指標(biāo)，當(dāng)業(yè)務(wù)數(shù)據(jù)量總量或增速上升到一定級別，依靠關(guān)系型數(shù)據(jù)庫一定無法支持。對于非關(guān)系型數(shù)據(jù)庫，包括NoSQL和Solr一類存儲(chǔ)方式，稍顯復(fù)雜，對于機(jī)器集群性能要求偏高（相對于文件系統(tǒng)）。從數(shù)據(jù)使用模式上來講，目前海量數(shù)據(jù)的常常是不包含復(fù)雜邏輯的簡單統(tǒng)計(jì)整理（比如上述系統(tǒng)中的關(guān)鍵詞匹配）。這時(shí)候文件系統(tǒng)的優(yōu)勢反而比較明顯（結(jié)構(gòu)簡單，邏輯簡單）。

如上述系統(tǒng)的應(yīng)用場景是怎么樣的呢，在一個(gè)強(qiáng)大的爬蟲系統(tǒng)之下，每個(gè)小時(shí)的數(shù)據(jù)增量在G到10G的級別，需要搜索所有的文件，獲取關(guān)鍵字的匹配，并且對匹配內(nèi)容進(jìn)行摘要。很類似我們windows里面的搜索功能，需要解決的就是如何在這樣增幅的文件系統(tǒng)之下，如何滿足業(yè)務(wù)系統(tǒng)的需求。

對分析系統(tǒng)有什么要求呢？

○能夠建立集群，分布式的保存數(shù)據(jù)文件內(nèi)容（統(tǒng)一控制，可配置）。

• 有一定的保護(hù)機(jī)制，保證數(shù)據(jù)或節(jié)點(diǎn)丟失不會(huì)影響系統(tǒng)使用。
• 如果有一個(gè)任務(wù)腳本執(zhí)行框架機(jī)制就好了（用于并行計(jì)算）。
• 能夠進(jìn)行節(jié)點(diǎn)間的數(shù)據(jù)均衡。
• 能夠簡單的查看所有的狀態(tài)與日志（web客戶端）

可能主要是這些了。若自己實(shí)現(xiàn)，確實(shí)是個(gè)復(fù)雜而龐大的工程，現(xiàn)在我們有了Hadoop。

系統(tǒng)物理架構(gòu)：

我們使用了一臺(tái)服務(wù)器，利用虛擬化，安裝了7套64x位的CentOS。一個(gè)Namenode，6個(gè)Datanode，復(fù)制數(shù)設(shè)置為3。每個(gè)系統(tǒng)分配到一個(gè)cpu，2G內(nèi)存，Datanode掛載了500G的存儲(chǔ)空間。

理想的Hadoop的搭建環(huán)境，參照《Best Practices for Selecting Apache Hadoop Hardware》一文，以及一些其他的文章。

CPU：最好是雙CPU，8核左右。不用太高了。

內(nèi)存：推薦48G，但是4G應(yīng)該就可以運(yùn)行Hadoop了。

硬盤：7200轉(zhuǎn)的SATA硬盤即可，Hadoop很占空間，所以盡量加。

網(wǎng)絡(luò)：內(nèi)部的數(shù)據(jù)交換要求非常高，內(nèi)網(wǎng)最好是千兆網(wǎng)卡，帶寬為1GB。

理想與現(xiàn)實(shí)，有錢與沒錢，呵呵。

系統(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)實(shí)施過程：

HDFS部分：

爬蟲抓取數(shù)據(jù)，整理后存放在50文件服務(wù)器，70以外部掛載的形式讀取。網(wǎng)頁文件比較小，假如直接寫入Hadoop對Namenode負(fù)載過大，所以入庫前合并，將每小時(shí)網(wǎng)頁整合成為一個(gè)文件寫入HDFS，由于區(qū)分類別，所以每小時(shí)基本寫入10個(gè)文件左右，總量在5-8G，耗時(shí)在40-50分鐘。（這個(gè)過程中，由于爬蟲的IO過于頻繁，導(dǎo)致文件讀取困難，所以做了定時(shí)任務(wù)，每小時(shí)啟動(dòng)一次，將需要處理的文件先拷貝到臨時(shí)區(qū)域，合并入庫之后再刪除。此處應(yīng)該是受到單核cpu的限制，所有操作均是串行，包括拷貝（cp）和合并入庫（java），所以Namenode嚴(yán)重建議配置稍高。）

此處沒有太多問題。

MapReduce部分：

寫入完成后，進(jìn)行分析工作，MapReduce。此處的工作過程為：數(shù)據(jù)庫定時(shí)生成關(guān)鍵詞列表文件。Job執(zhí)行時(shí)會(huì)讀取列表文件，匹配指定范圍內(nèi)的 HDFS文件（過去一小時(shí)），匹配出對應(yīng)的表達(dá)式與HTML，Map過程結(jié)束。在Reduce階段，會(huì)將Map的所有數(shù)據(jù)入數(shù)據(jù)庫（Mysql）。

此處出現(xiàn)過一些問題，記錄下來。

1. Reduce階段需要加載Mysql的第三方驅(qū)動(dòng)包。我在三個(gè)環(huán)境測試過（公司、家里、發(fā)布環(huán)境），使用 -libjars 一定可以，有的地方不需要也可以。不明確，懷疑與HADOOP_HOME環(huán)境變量有關(guān)。

2. MR過程中使用log4j打印日志，在Hadoop臨時(shí)目錄（如果你沒有配置 dfs.name.dir，dfs.data.dir，mapred.local.dir.mapred.system.dir等目錄，這些都會(huì)在 hadoop.tmp.dir當(dāng)中，我就偷懶都沒配置）mapred文件夾中查看一下。

整個(gè)過程實(shí)際上還是比較簡單的，基本編碼量就在Job的部分，但是一個(gè)Java文件就夠了。在目前初級階段應(yīng)該還是比較好用的?，F(xiàn)在還沒有測試Job的執(zhí)行效率。完成后會(huì)繼續(xù)記錄下來。有什么問題可以盡量提出。我會(huì)繼續(xù)關(guān)注。

原文鏈接：http://blog.jobbole.com/25060/