如今，大數(shù)據(jù)已經(jīng)成為時代的主題，企業(yè)對大數(shù)據(jù)的應(yīng)用也愈加深入，隨著大數(shù)據(jù)的普及，有很多大數(shù)據(jù)的觀念需要被質(zhì)疑，首先一點就是人們普遍認(rèn)為你可以簡單地利用Hadoop，并且Hadoop易于使用。

      問題是，Hadoop是一項技術(shù)，而大數(shù)據(jù)和技術(shù)無關(guān)。大數(shù)據(jù)是和業(yè)務(wù)需求有關(guān)的。事實上，大數(shù)據(jù)應(yīng)該包括Hadoop和關(guān)系型數(shù)據(jù)庫以及任何其它適合于我們手頭任務(wù)的技術(shù)。

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

      對于Hadoop如何組合和處理大數(shù)據(jù)的技巧和方法，數(shù)據(jù)專家Anoop曾經(jīng)在另一篇文章中提到過，一般情況下，為了得到最終的結(jié)果，數(shù)據(jù)需要加入多個數(shù)據(jù)集一起被處理和聯(lián)合。Hadoop中有很多方法可以加入多個數(shù)據(jù)集。MapReduce提供了Map端和Reduce端的數(shù)據(jù)連接。這些連接是非平凡的連接，并且可能會是非常昂貴的操作。Pig和Hive也具有同等的能力來申請連接到多個數(shù)據(jù)集。Pig提供了復(fù)制連接，合并連接和傾斜連接（skewed join），并且Hive提供了map端的連接和完整外部連接來分析數(shù)據(jù)。

      在大數(shù)據(jù)/Hadoop的世界，一些問題可能并不復(fù)雜，并且解決方案也是直截了當(dāng)?shù)模媾R的挑戰(zhàn)是數(shù)據(jù)量。在這種情況下需要不同的解決辦法來解決問題。一些分析任務(wù)是從日志文件中統(tǒng)計明確的ID的數(shù)目、在特定的日期范圍內(nèi)改造存儲的數(shù)據(jù)、以及網(wǎng)友排名等。所有這些任務(wù)都可以通過Hadoop中的多種工具和技術(shù)如MapReduce、Hive、Pig、Giraph和Mahout等來解決。這些工具在自定義例程的幫助下可以靈活地擴(kuò)展它們的能力。

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

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