Hadoop的應(yīng)用前提是”數(shù)據(jù)是有價值的！”，當(dāng)然，這一點已經(jīng)得到了幾乎所有人的認(rèn)可，并且在實際環(huán)境中，也都是這樣在做的，我們都希望從系統(tǒng)日志，網(wǎng)絡(luò)數(shù)據(jù)，社交信息等海量數(shù)據(jù)中發(fā)掘出有價值的信息，比如，用戶的行為，習(xí)慣等，而這些是做下一步市場營銷的有效決策依據(jù)。在Hadoop出現(xiàn)后，對于數(shù)據(jù)的發(fā)掘更是體現(xiàn)的***，尤其是從知名的互聯(lián)網(wǎng)公司開始，都已經(jīng)在使用或部署Hadoop環(huán)境。

面對如此誘惑，很多傳統(tǒng)的企業(yè)用戶都想?yún)⒖蓟ヂ?lián)網(wǎng)企業(yè)的做法，非常快速的部署Hadoop，從而快速整合和發(fā)掘既有數(shù)據(jù)的價值。但現(xiàn)實情況卻正應(yīng)了”理想很豐滿，現(xiàn)實太骨感“那句網(wǎng)絡(luò)流行語，想快速部署Hadoop，卻沒那么容易。為什么會出現(xiàn)這樣的問題呢，我想到的原因大概有幾點：

1. Hadoop提供給我們的只是一個框架，而不是一套完整的解決方案。

就像購買一套房子，建筑商交付的永遠(yuǎn)那都是一個基礎(chǔ)結(jié)構(gòu)，整體裝修部分還是要靠戶主自己按照自己的風(fēng)格和喜好進行設(shè)計和實施，而且，每個戶主對于裝修部分都會有自己的定義。Hadoop的部署恰是如此，每個企業(yè)中的Hadoop環(huán)境都可以說是唯一的，需要企業(yè)用戶對自己的數(shù)據(jù)環(huán)境有一個非常好的梳理和認(rèn)知。我需要分析哪些數(shù)據(jù)？需要得到什么樣的信息？這些信息我用來做什么？只有想明白這些問題后，Hadoop部署才會體現(xiàn)出它的價值。而這些，不僅僅是技術(shù)層面的問題，還要有管理層的認(rèn)知甚至是業(yè)務(wù)層面的配合。

2. 人力上的問題。

Hadoop屬于開源架構(gòu)，而開源有它先天不足或無法解決的問題，例如，由于場景的的唯一性導(dǎo)致的開源架構(gòu)下的開發(fā)和維護問題。Hadoop同樣會面對這樣的問題，而且，市場上當(dāng)前Hadoop方面的人才相對比較少，這些對于企業(yè)而言，都會增加不少部署和應(yīng)用上的難度。大量的開發(fā)工作需要大量的開發(fā)人員，個體的稀缺性又加重了開發(fā)方面的成本和難度。

3. 只有適合分布式架構(gòu)解決的問題才可以由Hadoop解決。

Hadoop不是”仙丹”，不能解決一切數(shù)據(jù)分析問題。面向結(jié)構(gòu)化的數(shù)據(jù)查詢和分析，傳統(tǒng)數(shù)據(jù)庫結(jié)構(gòu)還有它特有的優(yōu)勢。Hadoop是一個分布式架構(gòu)，而分布式架構(gòu)決定了其”只有適合分布式架構(gòu)解決的問題才可以由Hadoop解決”。例如，一個孕婦，需要10月懷胎才會有一個baby，而不是通過10個孕婦在1個月內(nèi)擁有一個baby。說到底，只有問題可以被拆分成若干子問題，且子問題是獨立的，也就是可以適用用“key-value”的迭代方式進行處理，最終可以推導(dǎo)出我們需要的結(jié)果。這樣的問題才是Haodop可以去解決的問題。

4. Hadoop不適合處理小文件。

其實大和小只是一個相對的概念，不存在絕對值的對比，之所以說Hadoop不適合處理小文件是由HDFS中的namenode局限性決定的，每個文件都會在namenode中保存相應(yīng)的元數(shù)據(jù)信息，為了提升效率，這些信息在使用的過程中都是被保存在內(nèi)存中的，如果小文件很多，則會消耗大量的namenode節(jié)點的內(nèi)存，而對于單節(jié)點來講，內(nèi)存的擴展是有其上限的。反之，如果是相對較大，例如上GB或更大的文件，相對消耗的內(nèi)存則會比較少。同時，在數(shù)據(jù)處理的過程中，系統(tǒng)開銷的占比會小很多。這些架構(gòu)上的特點和限制，決定了Hadoop更適合于處理“大”數(shù)據(jù)。當(dāng)然在技術(shù)實現(xiàn)上來看，殺雞用牛刀也是可以的，就看值不值得而已。

原文鏈接：http://www.36dsj.com/archives/10382