隨著大數(shù)據(jù)在各個(gè)業(yè)務(wù)領(lǐng)域的發(fā)展和應(yīng)用，相關(guān)的技術(shù)和工具也層出不窮，其中Hadoop框架受到更多的關(guān)注和應(yīng)用。Facebook分析主管Ken Rudin最近在紐約舉行的一個(gè)Strata+Hadoop世界大會發(fā)表主題演講時(shí)表示，不要小看關(guān)系型數(shù)據(jù)庫技術(shù)的價(jià)值。他認(rèn)為，Hadoop編程框架可能是“大數(shù)據(jù)”運(yùn)動的代名詞，但它并不是企業(yè)從大規(guī)模存儲的非結(jié)構(gòu)化信息中得到價(jià)值的唯一工具。

有很多很普及的大數(shù)據(jù)的觀念需要被質(zhì)疑，首先一點(diǎn)就是人們普遍認(rèn)為你可以簡單地利用Hadoop，并且Hadoop易于使用。問題是，Hadoop是一項(xiàng)技術(shù)，而大數(shù)據(jù)和技術(shù)無關(guān)。大數(shù)據(jù)是和業(yè)務(wù)需求有關(guān)的。事實(shí)上，大數(shù)據(jù)應(yīng)該包括Hadoop和關(guān)系型數(shù)據(jù)庫以及任何其它適合于我們手頭任務(wù)的技術(shù)。

Rudin說，F(xiàn)acebook的業(yè)務(wù)模式依賴于其對于超過10億社交媒體用戶的用戶資料和活動數(shù)據(jù)的處理，從而提供有針對性的廣告。然而，對于我們需要做的事情而言，Hadoop并不總是最好的工具。

例如，在Hadoop中對一個(gè)數(shù)據(jù)集做廣泛并且探索性的分析是很有意義的，但關(guān)系型存儲對于那些尚未發(fā)現(xiàn)的東西進(jìn)行運(yùn)行分析則更好。Hadoop對于在一個(gè)數(shù)據(jù)集中尋找最低水平的細(xì)節(jié)也很好用，但關(guān)系型數(shù)據(jù)庫對于數(shù)據(jù)的存儲轉(zhuǎn)換和匯總則更有意義。因此底線是，對于你的任何需求，要使用正確的技術(shù)。

他表示，還有另一個(gè)假設(shè)，認(rèn)為大數(shù)據(jù)單純的行為分析提供了寶貴的價(jià)值：“問題是這分析給那些無人問津的問題得出了更加聰明的答案。要弄清楚什么是正確的問題依然是一門藝術(shù)”。Facebook一直專注于雇傭合適的員工來運(yùn)行他們的分析操作，那些人不僅要在統(tǒng)計(jì)學(xué)專業(yè)獲得博士學(xué)位，并且還要精通業(yè)務(wù)。

當(dāng)你面試員工時(shí)，不要只關(guān)注于“我們怎么計(jì)算這個(gè)指標(biāo)”，相反，你應(yīng)該給他們一個(gè)商業(yè)案例來研究，并且問他們在這個(gè)案例中哪個(gè)是最重要的指標(biāo)。企業(yè)也應(yīng)該嘗試著去培養(yǎng)，人人參與分析。

據(jù)Rudin透露，F(xiàn)acebook運(yùn)營一個(gè)內(nèi)部的“數(shù)據(jù)培訓(xùn)營”，一個(gè)教導(dǎo)員工如何分析的時(shí)長兩周的項(xiàng)目。產(chǎn)品經(jīng)理、設(shè)計(jì)師、工程師甚至財(cái)務(wù)部門工作人員都要參加。每個(gè)人都參與其中的意義就在于，每個(gè)人可以用一個(gè)共同的數(shù)據(jù)語言，來互相討論數(shù)據(jù)的問題和麻煩。

Facebook還改變了統(tǒng)計(jì)人員和業(yè)務(wù)團(tuán)隊(duì)的組織方法。如果統(tǒng)計(jì)人員保持獨(dú)立，他們往往會坐在那里等待來自業(yè)務(wù)領(lǐng)域的請求找上門來，再回應(yīng)他們，而不是主動去做。但是如果統(tǒng)計(jì)人員被放置到業(yè)務(wù)部門，你會發(fā)現(xiàn)多個(gè)團(tuán)體將會試圖冗余地解決問題。

Facebook已經(jīng)采用了“嵌入式”模式，其中分析師被放在業(yè)務(wù)團(tuán)隊(duì)中，但他們要向一些更高級別的分析師報(bào)告，這有助于避免重復(fù)的勞動。

對于Hadoop如何組合和處理大數(shù)據(jù)的技巧和方法，數(shù)據(jù)專家Anoop曾經(jīng)在另一篇文章中提到過，一般情況下，為了得到最終的結(jié)果，數(shù)據(jù)需要加入多個(gè)數(shù)據(jù)集一起被處理和聯(lián)合。Hadoop中有很多方法可以加入多個(gè)數(shù)據(jù)集。MapReduce提供了Map端和Reduce端的數(shù)據(jù)連接。這些連接是非平凡的連接，并且可能會是非常昂貴的操作。Pig和Hive也具有同等的能力來申請連接到多個(gè)數(shù)據(jù)集。Pig提供了復(fù)制連接，合并連接和傾斜連接（skewed join），并且Hive提供了map端的連接和完整外部連接來分析數(shù)據(jù)。一個(gè)重要的事實(shí)是，通過使用各種工具，比如MapReduce、Pig和Hive等，數(shù)據(jù)可以基于它們的內(nèi)置功能和實(shí)際需求來使用它們。至于在Hadoop分析大量數(shù)據(jù)，Anoop指出，通常，在大數(shù)據(jù)/Hadoop的世界，一些問題可能并不復(fù)雜，并且解決方案也是直截了當(dāng)?shù)?，但面臨的挑戰(zhàn)是數(shù)據(jù)量。在這種情況下需要不同的解決辦法來解決問題。一些分析任務(wù)是從日志文件中統(tǒng)計(jì)明確的ID的數(shù)目、在特定的日期范圍內(nèi)改造存儲的數(shù)據(jù)、以及網(wǎng)友排名等。所有這些任務(wù)都可以通過Hadoop中的多種工具和技術(shù)如MapReduce、Hive、Pig、Giraph和Mahout等來解決。這些工具在自定義例程的幫助下可以靈活地?cái)U(kuò)展它們的能力。

事實(shí)上，與Rudin持相同觀點(diǎn)的還有數(shù)據(jù)專家Joe Brightly，他也總結(jié)了Hadoop不適合數(shù)據(jù)分析的幾個(gè)理由，其中包括：

“Hadoop是一個(gè)框架，不是一個(gè)解決方案”——他認(rèn)為在解決大數(shù)據(jù)分析的問題上人們誤認(rèn)為Hadoop可以立即有效工作，而實(shí)際上“對于簡單的查詢，它是可以的。但對于難一些的分析問題，Hadoop會迅速敗下陣來，因?yàn)樾枰阒苯娱_發(fā)Map/Reduce代碼。出于這個(gè)原因，Hadoop更像是J2EE編程環(huán)境而不是商業(yè)分析解決方案?！?所謂框架意味著你一定要在之上做個(gè)性化和業(yè)務(wù)相關(guān)的開發(fā)和實(shí)現(xiàn)，而這些都需要成本。

Hadoop的子項(xiàng)目Hive和Pig 都不錯，但不能逾越其架構(gòu)的限制。”——Joe提出“Hive 和Pig 都是幫助非專業(yè)工程師快速有效使用Hadoop的完善工具，用于把分析查詢轉(zhuǎn)換為常用的SQL或Java Map/Reduce 任務(wù)，這些任務(wù)可以部署在Hadoop環(huán)境中。”其中Hive是基于Hadoop的一個(gè)數(shù)據(jù)倉庫工具，它可以幫助實(shí)現(xiàn)數(shù)據(jù)匯總、即時(shí)查詢以及分析存儲在Hadoop兼容的文件系統(tǒng)的大型數(shù)據(jù)集等。而Pig是并行計(jì)算的高級數(shù)據(jù)流語言和執(zhí)行框架。但作者認(rèn)為“Hadoop的Map/Reduce框架的一些限制，會導(dǎo)致效率低下，尤其是在節(jié)點(diǎn)間通信的情況（這種場合需要排序和連接）?！?/p>

Joe總結(jié)道：“Hadoop是一個(gè)用來做一些非常復(fù)雜的數(shù)據(jù)分析的杰出工具。但是具有諷刺意味的是，它也是需要大量的編程工作才能得到這些問題的答案。” 這一點(diǎn)不止在數(shù)據(jù)分析應(yīng)用方面，它其實(shí)反映了目前使用開源框架時(shí)候不得不面對的選型平衡問題。當(dāng)你在選型開源框架或代碼的時(shí)候，既要考慮清楚它能夠幫到你多少，節(jié)省多少時(shí)間和成本，提高多少效率。也要知道由此而產(chǎn)生多少新增的成本，比如工程師的學(xué)習(xí)成本、開發(fā)和維護(hù)成本，以及未來的擴(kuò)展性，包括如果使用的框架升級了，你和你的團(tuán)隊(duì)是否要做相應(yīng)的升級；甚至還要有安全性方面的考慮，畢竟開源框架的漏洞也是眾所周知的。