大數(shù)據(jù)時代為什么語必言Hadoop？

最近知乎上有這樣一個問題“為什么很多公司都采用Hadoop方案處理大數(shù)據(jù)業(yè)務(wù)”，引來很多回答，筆者整理如下，其觀點或有時而可商，歡迎討論。

      先說一說什么樣的公司比較傾向于使用Hadoop。有人認(rèn)為，使用Hadoop的前提是自身有沒有收集并分析數(shù)據(jù)的需要，并且數(shù)據(jù)量是否一直在增長并且不可丟棄。

      目前看起來，此類數(shù)據(jù)多數(shù)為日志數(shù)據(jù)，分析用戶習(xí)慣，或者就是傳感器之類的數(shù)據(jù)，分析環(huán)境等監(jiān)控內(nèi)容的變化規(guī)律。也有很多公司不使用Hadoop，比如多 數(shù)從事政府行業(yè)或者部分企業(yè)系統(tǒng)開發(fā)的公司，他們對系統(tǒng)的易部署及易維護(hù)性要求更高，雖然也會遇到一部分?jǐn)?shù)據(jù)量較大，不過通常使用NoSQL數(shù)據(jù)庫就能夠 滿足需要了，很少使用Hadoop。

      這又回到了一句老話，任何技術(shù)，都是為了解決問題而存在的，沒有必要為了技術(shù)而技術(shù)!

      那么，使用Hadoop的公司為什么選擇Hadoop呢？選擇Hadoop，其實是選擇的的MapReduce，把大塊的任務(wù)切分為若干份小任務(wù)，由集群的每臺服務(wù)器來計算，最后把結(jié)果合并。

      有人認(rèn)為，主要有三點：1，可以解決問題; 2，成本低 ; 3，成熟的生態(tài)圈。

一、Hadoop為大數(shù)據(jù)而生

      在那個沒有Hadoop的時代，大家是怎么處理大量數(shù)據(jù)的呢？IBM的大型機(jī)是一個很不錯的解決方案。

      中國的銀行系統(tǒng)目前很大一部分還在大型機(jī)上。但是大型機(jī)太貴了，實在是太貴了。

      于是Google來了，經(jīng)過謹(jǐn)慎的思考，Google的工程師們發(fā)現(xiàn)實際上使用一個簡單得分布式計算模型MapReduce就能完成他們的需求。然后他們就搞了一個MapReduce。然后就寫了幾篇關(guān)于這種計算方法的論文。

      有了思想，而且有了Google這么大數(shù)據(jù)量的數(shù)據(jù)驗證，復(fù)制技術(shù)就很容易了。于是大家就開始搞，然后大家就搞出來一個Hadoop。而且Hadoop是Apache 下的項目，正所謂大樹底下好乘涼。

      Hadoop底層的分布式文件系統(tǒng)具有高拓展性，通過數(shù)據(jù)冗余保證數(shù)據(jù)不丟失和提交計算效率，同時可以存儲各種格式的數(shù)據(jù)。同時其還支持多種計算框架，既可以進(jìn)行離線計算也可以進(jìn)行在線實時計算。

二，為什么成本可以控制的低

      確定可以解決我們遇到的問題之后，那就必須考慮下成本問題了。

      1， 硬件成本

      Hadoop是架構(gòu)在廉價的硬件服務(wù)器上，不需要非常昂貴的硬件做支撐

      2， 軟件成本

      開源的產(chǎn)品，免費的，基于開源協(xié)議，可以自由修改，可控性更大

      3，開發(fā)成本

      因為屬于二次開發(fā)，同時因為有非常活躍的社區(qū)討論，對開發(fā)人員的能力要求相對不高，工程師的學(xué)習(xí)成本也并不高

      4，維護(hù)成本

      當(dāng)集群規(guī)模非常大時，開發(fā)成本和維護(hù)成本會凸顯出來。但是相對于自研系統(tǒng)來說的話，還是便宜的很多。

      某司自研同類系統(tǒng)幾百名工程師近4年的投入，燒錢億計，都尚未替換掉Hadoop。

      5，其他成本

      如系統(tǒng)的安全性，社區(qū)版本升級頻繁而現(xiàn)實是無法同步進(jìn)行升級所引入的其他隱形成本。

三、成熟的生態(tài)圈

      部分系統(tǒng)歸類：

      部署，配置和監(jiān)控 Ambari，Whirr

      監(jiān)控管理工具 Hue, karmasphere, eclipse plugin, cacti, ganglia

      數(shù)據(jù)序列化處理與任務(wù)調(diào)度 Avro, Zookeeper

      數(shù)據(jù)收集 Fuse,Webdav, Chukwa, Flume, Scribe ， Nutch

      數(shù)據(jù)存儲 HDFS

      類SQL查詢數(shù)據(jù)倉庫 Hive

      流式數(shù)據(jù)處理 Pig

      并行計算框架 MapReduce， Tez

      數(shù)據(jù)挖掘和機(jī)器學(xué)習(xí) Mahout

      列式存儲在線數(shù)據(jù)庫 HBase

      元數(shù)據(jù)中心 HCatalog （可以和Pig，Hive ,MapReduce等結(jié)合使用）

      工作流控制 Oozie，Cascading

      數(shù)據(jù)導(dǎo)入導(dǎo)出到關(guān)系數(shù)據(jù)庫 Sqoop，F(xiàn)lume， Hiho

      數(shù)據(jù)可視化 drilldown，Intellicus

傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)倉庫VS.Hadoop

      再從傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)倉庫這邊看，一方面吃著現(xiàn)有的蛋糕，另一方面也一直在嘗試數(shù)據(jù)量更大、擴(kuò)展性更好的解決方案，從share-everything到 share-storage到share-nothing，比如現(xiàn)在的MPP解決方案，也在大數(shù)據(jù)業(yè)務(wù)中分了一杯羹。不過數(shù)據(jù)庫基因的解決方案，還是要面 臨擴(kuò)展性的問題，我們的經(jīng)驗是大概百節(jié)點級別，遠(yuǎn)遠(yuǎn)不如hadoop的擴(kuò)展性。

      hadoop最偉大的地方，嚴(yán)格說是google的偉大，就是在擴(kuò)展性瓶頸方面的突破了。擴(kuò)展性一直是所謂大數(shù)據(jù)（以前叫海量數(shù)據(jù)）處理的瓶頸，擴(kuò)展性上 去了，有更多機(jī)器來干活，那同時能干的活也就多了嘛。以前處理海量數(shù)據(jù)的思路，是搞一臺超級牛的機(jī)器，比如高性能計算機(jī)，比如大型機(jī)、小型機(jī);后來一臺機(jī) 器怎么也不夠用了，就搞個幾臺連起來一起用，比如網(wǎng)格，比如分布式數(shù)據(jù)庫數(shù)據(jù)倉庫，不過這擴(kuò)展性也就是幾臺十幾臺級別的，再多也無法提高了;而 hadoop，放棄磁盤陣列而使用本地硬盤作為存儲，使得網(wǎng)絡(luò)連接方式大大簡化，從軟件層面來解決很多硬件問題，比如硬盤故障，減少對硬件的依賴，這些保 證了hadoop甩出其他方案幾個量級的擴(kuò)展性能，人類看到了處理大數(shù)據(jù)的曙光。