【51CTO專稿】使用大數(shù)據(jù)技術有著強烈的吸引力，而如今沒有比Apache Hadoop更誘人的大數(shù)據(jù)技術了，這種可擴展的數(shù)據(jù)存儲平臺是許多大數(shù)據(jù)解決方案的核心。

[[79727]]

但是盡管Hadoop頗具吸引力，想了解Hadoop能夠為企業(yè)扮演什么角色、如何最有效地部署它，仍要面臨一條很陡的學習曲線。換句話說，學起來很費勁。

只有明白了Hadoop的有所為而有所不為，你才能更清楚地了解如何才能最有效地把它部署到你自己的數(shù)據(jù)中心或云環(huán)境。然后，才可以為部署的Hadoop落實最佳實踐。

Hadoop的有所不為

我們不打算花大量的時間來解釋何謂Hadoop，因為許多技術文檔和媒體報道已對此作了深入介紹。一言以蔽之，知道Hadoop的兩個主要組件很重要：一個是用于存儲的Hadoop分布式文件系統(tǒng)（HDFS），另一個是MapReduce框架，讓你可以對Hadoop里面存儲的任何數(shù)據(jù)執(zhí)行批量分析任務。值得一提的是，這種數(shù)據(jù)不一定是結構化數(shù)據(jù)，這使得Hadoop非常適合分析和處理來自社交媒體、文檔和圖形等來源的數(shù)據(jù)：即并不容易適用于行和列的任何數(shù)據(jù)。

這倒不是說，你無法將Hadoop用于結構化數(shù)據(jù)。實際上，市面上有許多解決方案可以充分利用Hadoop的這個優(yōu)點：每TB比較低的存儲開支，以便將結構化數(shù)據(jù)存儲在Hadoop中，以取代關系數(shù)據(jù)庫系統(tǒng)（RDBMS）。但是如果你的存儲需求不是那么大，那么在Hadoop和RDBMS之間來回轉移數(shù)據(jù)毫無必要。

你不想使用Hadoop的一個方面是事務型數(shù)據(jù)。顧名思義，事務型數(shù)據(jù)異常復雜，因為電子商務網站上的交易事務會生成許多步驟，而這些步驟都必須迅速加以實現(xiàn)。這種場景根本就不適合使用Hadoop。

Hadoop也不適合用于要求延遲時間極短的結構化數(shù)據(jù)集，比如當網頁由典型的LAMP堆棧中的MySQL數(shù)據(jù)庫來呈現(xiàn)時。這需要速度快，而Hadoop很難滿足這樣的要求。

Hadoop的有所為

由于批量處理功能，Hadoop應該部署在這些場合：索引編制、模式識別、推薦引擎建立和情緒分析；在所有這些場合下，數(shù)據(jù)大量生成，存儲在Hadoop中，然后最終使用MapReduce函數(shù)來進行查詢。

但是這并不意味著，Hadoop會取代你數(shù)據(jù)中心里面目前的組件。恰恰相反，Hadoop會集成到你現(xiàn)有的IT基礎設施里面，以便充分利用進入到貴企業(yè)的海量數(shù)據(jù)。

比如說，設想一個相當?shù)湫偷姆荋adoop企業(yè)網站在處理商業(yè)交易。據(jù)Cloudera的教育服務主管Sarah Sproehnle聲稱，來自其一個客戶的流行網站的日志每天晚上都要經歷抽取、轉換和加載（ETL）的過程——這個過程可能最多耗時3小時，然后把數(shù)據(jù)存儲到數(shù)據(jù)倉庫中。這時，存儲過程將被啟動，另外過兩小時后，被清理的數(shù)據(jù)將駐留在數(shù)據(jù)倉庫中。不過，最終的數(shù)據(jù)集將只有原始大小的五分之一——這意味著，就算可以從整個原始數(shù)據(jù)集獲取什么價值，現(xiàn)在這個價值也蕩然無存了。

Hadoop集成到這家企業(yè)后，情況大為改觀：節(jié)省了時間和精力。來自Web服務器的日志數(shù)據(jù)不用經歷ETL操作，而是直接被完整地發(fā)送到了Hadoop里面的HDFS。然后，對日志數(shù)據(jù)執(zhí)行同樣的清理過程，現(xiàn)在只使用MapReduce任務。一旦數(shù)據(jù)清理完畢，隨后被發(fā)送到數(shù)據(jù)倉庫。但是這個操作要迅速得多，這歸因于省去了ETL這一步，加上MapReduce操作速度快。而且，所有數(shù)據(jù)仍然保存在Hadoop里面，準備回答網站操作人員之后可能提出來的任何額外問題。

想了解Hadoop，有必要明白這個重要的一點：千萬不要把它看作是取代你現(xiàn)有的基礎設施，而是補充數(shù)據(jù)管理和存儲功能的一種工具。使用Apache Flume或Apache Sqoop之類的工具，你就能把現(xiàn)有系統(tǒng)與Hadoop聯(lián)系起來，并且對你的數(shù)據(jù)進行處理——不管數(shù)據(jù)有多大。Apache Flume可以將數(shù)據(jù)從RDBMS獲取到Hadoop，并將數(shù)據(jù)從Hadoop獲取到RDBMS；Apache Sqoop則可以將系統(tǒng)日志實時抽取到Hadoop。你只要為Hadoop添加節(jié)點，就可以執(zhí)行數(shù)據(jù)存儲和處理任務。

所需的硬件和成本

那么，我們又需要多少的硬件呢？

估計Hadoop所需的硬件有點不一樣，這取決于你是在問哪家廠商。Cloudera的清單詳細地列出了Hadoop的典型從屬節(jié)點應該有怎樣的硬件配置：

•中檔處理器

•4GB至32 GB內存

•每個節(jié)點連接至千兆以太網，并配備一只萬兆以太網架頂式交換機

•專用的交換基礎設施，以避免Hadoop擁塞網絡

•每個機器4至12個驅動器，非RAID配置方式

另一家Hadoop經銷商Hortonworks的硬件規(guī)格大同小異，不過網絡方面的信息來得模糊一點，那是由于任何某家企業(yè)添加到Hadoop實例的工作負載可能不一樣。

Hortonworks的首席技術官Eric Baldeschwieler寫道：“一條經驗法則就是，要關注網絡成本與計算機成本之比，網絡成本盡量控制在總成本的20%左右。網絡成本應包括你的整個網絡、核心交換機、機架交換機和所需的任何網卡等。”

至于Cloudera，它估計每個節(jié)點所需的成本在3000美元至7000美元之間，具體取決于你確定每個節(jié)點有什么樣的硬件規(guī)格。

Sproehnle也概述了一條很容易遵守的經驗法則，幫助你規(guī)劃Hadoop容量。由于Hadoop具有線性擴展的特性，你只要添加一個節(jié)點，就可以增加存儲和處理能力。這使得規(guī)劃起來簡單直觀。

比如說，要是你的數(shù)據(jù)每個月增加1TB，那么規(guī)劃方法如下：Hadoop將數(shù)據(jù)復制三次，所以你需要3TB的原始存儲空間才能容納新增加的1TB數(shù)據(jù)。留出一點額外空間（Sproehnle估計要預留30%），以便處理數(shù)據(jù)操作；這樣一來，每個月實際需要的存儲空間是4TB。如果你使用4個1 TB驅動器的機器作為節(jié)點，每個月就需要一個新的節(jié)點。

好就好在，所有新的節(jié)點一旦連接上，就可以立即投入使用，從而讓你的處理和存儲能力增強X倍，其中X指節(jié)點的數(shù)量。

不過，安裝和管理Hadoop節(jié)點其實并非易事，但是市面上有許多工具可以助你一臂之力。Cloudera 管理器、Apache Ambari（這是Hortonworks用于其管理系統(tǒng)的工具）和MapR控制系統(tǒng)都是同樣卓有成效的Hadoop集群管理工具。如果你使用一套“純粹”的Apache Hadoop解決方案，還可以關注Platform Symphony MapReduce、StackIQ Rocks + Big Data和Zettaset Data Platform等第三方Hadoop管理系統(tǒng)。

當然，說到為貴企業(yè)部署一款Hadoop解決方案，本文介紹的這些內容只是皮毛而已。也許最寶貴的心得在于明白這一點：Hadoop并非旨在取代你目前的數(shù)據(jù)基礎設施，而是只是起到互補作用。

一旦弄清楚了這個重要的區(qū)別，就比較容易開始考慮Hadoop可以如何幫助貴企業(yè)，沒必要對你現(xiàn)有的數(shù)據(jù)流程進行大刀闊斧的改動。

原文： What Hadoop can, and can't do