為什麼很多公司的大數據相關業務都基於 Hadoop 方案？

01-18

典型的譬如 Apple :Apple - Jobs at Apple
相關鏈接: The Key For Hadoop Adoption: Learning How To Make Big Data Small

謝邀。

選擇Hadoop的原因最重要的就是這三點：1，可以解決問題； 2，成本低； 3，成熟的生態圈。

一，Hadoop幫助我們解決了什麼問題

無論國內還是國外的大公司對於數據都有著無窮無盡的渴望，都會想盡一切辦法收集一切數據，

因為通過信息的不對稱性可以不斷變現，而大量的信息是可以通過數據分析得到的。

數據的來源途徑非常的多，數據的格式也越來越多越來越複雜，隨著時間的推移數據量也越來越大。

因此在數據的存儲和基於數據之上的計算上傳統資料庫很快趨於瓶頸。

而Hadoop正是為了解決了這樣的問題而誕生的。其底層的分散式文件系統具有高拓展性，通過數據冗餘保證數據不丟失和提交計算效率，同時可以存儲各種格式的數據。

同時其還支持多種計算框架，既可以進行離線計算也可以進行在線實時計算。

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

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

1，硬體成本

Hadoop是架構在廉價的硬體伺服器上，不需要非常昂貴的硬體做支撐

2，軟體成本

開源的產品，免費的，基於開源協議，可以自由修改，可控性更大

3，開發成本

因為屬於二次開發，同時因為有非常活躍的社區討論，對開發人員的能力要求相對不高，工程師的學習成本也並不高

4，維護成本

當集群規模非常大時，開發成本和維護成本會凸顯出來。但是相對於自研系統來說的話，還是便宜的很多。

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

5，其他成本

如系統的安全性，社區版本升級頻繁而現實是無法同步進行升級所引入的其他隱形成本。

三，成熟的生態圈有什麼好處

成熟的生態圈代表的未來的發展方向，代表著美好的市場前景，代表著更有錢途的一份工作(好吧，「三個代表」).

看圖(引自：Hadoop Ecosystem Map ? myNoSQL）

部分系統歸類：

部署，配置和監控 Ambari，Whirr

監控管理工具 Hue, karmasphere, eclipse plugin, cacti, ganglia

數據序列化處理與任務調度 Avro, Zookeeper

數據收集 Fuse,Webdav, Chukwa, Flume, Scribe ， Nutch

數據存儲 HDFS

類SQL查詢數據倉庫 Hive

流式數據處理 Pig

並行計算框架 MapReduce， Tez

數據挖掘和機器學習 Mahout

列式存儲在線資料庫 HBase

元數據中心 HCatalog （可以和Pig，Hive ,MapReduce等結合使用）

工作流控制 Oozie，Cascading

數據導入導出到關係資料庫 Sqoop，Flume， Hiho

數據可視化 drilldown，Intellicus使用到的公司也非常的多

（引自： A New Version of the Hadoop Ecosystem Map）

謝邀！

首先先說兩個常識。

任何技術的產生都是為了解決問題。

任何技術的產生都不是憑空的，都是以其他技術或者思想為基礎的。

其次，不要過度誇大某些技術和神話某些技術。

接著說題主的問題。

提到Hadoop就要提到Goolge，不但要提到Google，還要提到IBM。

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

中國的銀行系統目前很大一部分還在大型機上。但是大型機太貴了，實在是太貴了。

於是Google這個顛覆者來到了這個世界上，其實分散式計算的思想早就有了，Google只不過是把它簡化了而已。

沒錯，是簡化了。

以前的分散式計算很大力氣都花費在每個節點的計算同步和節點間數據交換上面。

建立這樣一個系統實在是太複雜了，於是很多人放棄了。即便是有些人成功的建立起了一個小型的系統，但是將其搬到大量節點上也是有很多的問題。

於是分散式計算實際上還是處於實驗環境中，或者小範圍的使用。

於是Google來了，經過謹慎的思考，Google的工程師們發現實際上使用一個簡單得分散式計算模型MapReduce就能完成他們的需求。

畢竟他們當時的需求還很簡單。

而且那個時候的Google畢竟還不像現在這麼有錢，能省一點是一點，能用PC的就別上大型機了。

反正存的也就是一些網頁，又不是用戶的真金白銀。

然後他們就搞了一個MapReduce。然後就寫了一篇關於這種計算方法的論文。

有了思想，而且有了Google這麼大數據量的數據驗證，copy技術就easy了。於是大家就開始搞，然後大家就搞出來一個Hadoop。

然後發現這玩意還真不錯，幾台機器就能搞，幾十台也能用，公司大了，幾百台，幾千台也OK。

其實這個玩意那個時候還真沒前面幾位回答的那麼複雜和神秘，我知道有個小公司就是自己的系統。

其實騰訊等公司也有自己存儲系統。只是不叫這個而且沒有開源而已。

我現在公司有個team做雲計算的，自己也用C++弄了一個出來。

真的沒有那麼神秘。

既然說到沒那麼複雜了，為啥大家還對Hadoop趨之若鶩呢，以至於做大數據的沒寫過MR代碼，你都不好意思和人打招呼。

最大的原因我覺得就是Hadoop是一個正確的時間出生，然後形成了一個事實的標準。

既然有人做了輪子，自己又何必再搞一套。

不要高看我們碼農，大部分碼農其實是很懶的，能搞過來直接用，誰還吃多了編一套。

有那空多看兩個島國妹子，追求一下唯美的藝術比啥不強。

於是乎Hadoop就有了社區，然後就有了生態，然後就有了一群人搖旗吶喊。

然後Hadoop就慢慢成了大數據分散式計算領域的No1.

既然都是事實標準了，那麼接下來的一切就順理成章了。

他也就成了大多數公司的解決方案。

首先，選擇Hadoop，其實是選擇的的MapReduce，把大塊的任務切分為若干份小任務，由集群的每台伺服器來計算，最後把結果合併。

這個思想是解決大數據的最直接的方案，一台機器放不下的數據，我用多台機器來解決。這和分治演算法的思路是一致的。

那麼，為什麼選擇Hadoop？

因為開源，免費，上萬開發者維護了很多年了，資料也很多，使用起來比較容易，出了問題一般之前也有人給你踩過坑寫過資料了。

當然了，國內一些實力強的大公司，喜歡自己開發一套MapReduce，其實思想都擺在那裡，就是實現而已，有些公司不喜歡用Java，所以就用C、C++自己做。比如騰訊，從Google挖了一批人，來了就先搞一套自己的GFS和MapReduce，實際效果如何呢？開發了一年多，bug很多，只是靠內部關係在推，當初如果直接用Hadoop，也許沒這麼曲折，據了解搜搜拆分之後，也轉到HBase和Hadoop了。

Apache在分散式領域除了Hadoop，還有HBase和Zookeeper這兩大殺器。HBase我不太熟，Zookeeper基本是目前分散式一致協作演算法里的頭牌了，大公司有自己搞MapReduce的，但是自己搞分散式協作演算法的不多，基本都直接用zookeeper了，為什麼？因為實現起來太難太複雜。

謝邀

hadoop的伺服器為社區伺服器，成本比較低，幾乎所有人都可以使用

能夠處理PB級別的雜亂無章的數據，在處理失敗的儲存數據後，可以使用個人認為最好的分散式計算處理，另外個人最看重的hadoop的高擴展性：計算機集簇間分配數據並完成計算任務的，這些集簇可以方便地擴展到各類型的節點中。

高效性，
能夠在節點之間動態地移動數據，並保證各個節點的動態平衡，因此處理速度非常快（基本，可靠的一點）

高容錯性，能夠自動保存數據的多個副本，並且能夠自動將失敗的任務重新分配。脫離落後的人工處理系統，拜託複雜的環境和不確定性。

謝邀！這是個好問題，試著通俗易懂地說說，歡迎討論。hadoop現在很紅火，大數據也是，現在是個公司只要有點能號稱「大數據」的數據量，都緊跟時代要搞大數據分析，怎麼搞呢，首先想到的就是hadoop了。如果說為什麼現在很多公司都基於hadoop方案搞大數據業務，是因為它太有名了，太流行，大家都用，至少都去嘗試。

如果問hadoop是怎麼紅火起來的，這就要說說歷史了。08年我們開始搞hadoop，那時候互聯網還在oracle，對於hadoop這玩意到底行不行，我們心裡說實話沒有底。google是當時我們幾乎唯一的信心來源，想想自己用的gmail、google搜索、google地圖等大數據業務還不錯，google號稱有多少多少節點的大集群，而hadoop就是模仿google做的，這條路應該還是可行的。

後來互聯網開始嘗試hadoop，越來越多的國內外案例湧來，信心來源也越來越豐富，問題已經不是hadoop能不能用，而是是否適合用hadoop了。很快，大家不滿足於只是hadoop，一系列衍生項目提出來，滿足各種附加需求。同時，大家也很快發現了mapreduce不能解決所有問題，只適合離線批量處理場景，各種解決其他oracle解決不了的問題的方案應運而生。

從傳統資料庫數據倉庫這邊看，一方面吃著現有的蛋糕，另一方面也一直在嘗試數據量更大、擴展性更好的解決方案，從share-everything到share-storage到share-nothing，比如現在的MPP解決方案，也在大數據業務中分了一杯羹。不過資料庫基因的解決方案，還是要面臨擴展性的問題，我們的經驗是大概百節點級別，遠遠不如hadoop的擴展性。

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

隨著web2.0、web3.0、移動互聯網、物聯網等等事物的興起，人們創造了更多的數據，收集更多數據成為可能，業務的需求也促進了大數據技術包括hadoop的發展。畢竟，得數據能被很好的收集、整理，才有被進一步融合、分析、應用、創造價值的可能。

hadoop以及大數據技術發展到現在，最重要的是怎麼用好這些技術，如何選擇合適的技術方案來解決需要的問題，有必要時，如何混搭多種技術方案，以及，對於某個技術方案，如何優化使得針對特定應用場景的效果最佳。這需要廣大從業者不斷摸索、積累。

理性地說，很多大數據的業務涉及大量非結構化數據，傳統的關係型資料庫無法有效解決，利用Hadoop的方案至少可以解決存儲的問題。

但同時有很多非理性的原因，比如大家盲目的追捧類似Google，Facebook等公司的一些解決方案。實際上Hadoop在解決大量的非結構化數據存儲的問題上是有優越性的，但同時在數據的深度挖掘、靈活分析、靈活查詢的角度上是有很多不足的。請大家根據具體情況審慎選擇資料庫工具，現在很多數據應用都已經不再是單一資料庫產品可以圓滿的解決了，通常需要多種資料庫產品混合配合使用。

大數據方面，Google是技術標杆。Mapreduce的思想就是從Google那裡傳出來的，Hadoop是其開源實現。既然Google都用這種技術，而且Hadoop是Apache 下的項目，正所謂大樹底下好乘涼，所以大家也就放心使用了。這是它被廣泛使用的真正起因。

之後使用起來確實能解決問題，社區環境也不錯，其他優點上面張宇昆已經說了，於是使用的就越來越廣。但現在像spark，storm等一些實時性更好的方案也發展的不錯，但大多數數據分析任務對實時性要求並不是很高，所以Mapreduce的形式就足夠了，而且難度不是太高，很多應屆生也能參與其中。

我覺得大數據業務基於Hadoop是不言自明的。隨著數據量的急劇增加，從TB-&>PB, 不是某幾台伺服器能Hold住的。「去中心化」(de-centralization)一直是系統架構發展的趨勢。當我們用分散式的伺服器集群來完成巨大的計算任務時，勢必有兩個方面的分布化：

1）數據

2）計算

可以說Hadoop提供了這樣的分散式計算平台。其分散式文件系統(HFDS)，很好地解決了數據的分散式存儲。而Map-Reduce則解決了計算的分布化，先在各台伺服器上Map，再逐步Reduce。

Hadoop技術的穩定性和成熟度都很高，用戶群大，而且開源，所以成為很多公司首選的平台。

但是Hadoop也有其自身的局限，或者說，隨著社會技術商業的發展，有了新的挑戰。這表現在：

1) Map-Reduce計算範式的局限

Hadoop 的發展是源於Google的GFS、MapReduce和BigTable。Google當年開發MapReduce主要是為搜索引擎服務的，先映射再化簡。但是，在大數據的場景下，很多機器學習的演算法無法改造成Map-Reduce的方式，或者效率很低。這就有了AllReduce的方式。

2) 不支持實時性(real-time)

Hadoop從一開始就是為批處理式的計算任務提供支持的。所以對實時性的效應很差，或者還需要一個應對實時性的大數據架構，這就是storm等的價值了。可參考 Nathan Marz的新書《Big Data》

3) 基於java的開發

我個人一直對Hadoop用java開發持保留意見。如果把Hadoop比喻為分散式操作系統，其性能和資源佔用率會很關鍵。用C++寫會好許多。

不管以後怎麼發展，我覺得Hadoop在分散式文件系統上的價值和優勢，總是必須的。這部分是所有大數據系統的基石。而MapReduce的計算範式被改造的可能會很大。會出現很多其它的分散式計算形態，比如Spark, Storm。但它們都不會取代Hadoop，而是補充。因為在數據存儲上，還要仰仗Hadoop。

google基礎設施天下第一，這套技術棧就是他發的論文，hadoop等都是clone

首先謝邀，很久不上知乎了。

關於大公司為什麼使用Hadoop，樓上已經有很多人說很多好處了，我就不再複述，使用的前提還是自身有沒有收集並分析數據的需要，並且數據量是否一直在增長並且不可丟棄，目前看起來，此類數據多數為日誌數據，分析用戶習慣，或者就是感測器之類的數據，分析環境等監控內容的變化規律。

也有很多公司不使用Hadoop，比如多數從事政府行業或者部分企業系統開發的公司，他們對系統的易部署及易維護性要求更高，雖然也會遇到一部分數據量較大，不過通常使用NoSQL資料庫就能夠滿足需要了，很少使用Hadoop。

總結一句話，任何技術，都是為了解決問題而存在的，沒有必要為了技術而技術！

Presto 能處理300PB的數據

多數人錢不多，所以使用的基數大

就跟桌面文字處理都用office一樣，hadoop是事實上的大數據處理的標準。

======4.18更新=======

至於Hadoop為什麼能成為大數據處理的標準，在我看來，最主要的原因是HDFS。

作為開源的大數據解決方案，一旦企業使用了Hadoop，其數據就保存在HDFS上了，此後上任何大數據產品都要求能夠支持HDFS，所以我們看到不管是早期的Hive，HBase這樣默認Hadoop產品家族成員，還是後起的Impala這樣的SQL引擎，Spark這樣的快速大數據方案，其底層文件系統基本都是以HDFS為重點支持。不管你用什麼方案，都得先部署一套Hadoop。

目前看來，有望挑戰HDFS地位的，可能要看amplab/tachyon 有興趣同學可關注其作者新浪微博 @李浩源HY

大型開源軟體發展路徑都差不多… 商業企業牽頭，開源軟體追趕。大公司撐腰。就這麼簡單，你說這些軟體牛在哪？其實也沒啥的感覺…

樓上回答了很多。

舉一個不用的例子，曾經有baidu想自己研發一個類似的，然後失敗了

謝邀。

我總結幾點現在看到的：

1. 成本低，2. 開源，快速發展，3. 高擴展性，4. 高效

Hadoop毋庸置疑具備最高性價比，X86架構，高可用，高擴展，秒級查詢速度，這些都帶來了很大的商業價值。在去IOE風潮盛行的今天，還有哪種技術能夠讓想嘗試創新，擺脫License困擾的公司們以最快的速度，最小的代價去嘗試大數據呢？

謝邀，個人覺得主要有以下幾方面原因：

1. 成本低， hadoop開源，對機器要求低，所以成本低。

2. 有完善的生態環境，有良好的社區支持，也形成了良好的生態環境，各種周邊的工作如pig, hive oozie等都很完善。

3. 相較於其他的大數據系統，hadoop的從業人員最多，會有馬太效應的成分在裡面。

首先從應用場景方面，數據積累越來越多的不限於傳統資料庫，而包括了文本、多媒體等資源，這些數據形式的處理是基於資料庫的數據倉庫或者傳統分析軟體的弱項。

再者從應對數據量的增長帶來的壓力方面，HADOOP的存儲與計算能力可水平擴張，能力邊界不明顯（實際上因為具體的技術原因是有規模限制的，但是比起傳統方案來已經好過太多）。

第三從應用環境搭建維護的成本方面，其對硬體要求較低，不需要為其配置傳統高端計算、存儲，且因為可水平擴展的原因，規模成本可隨著需求逐步增加，避免一次性投資風險。

第四從技術成熟度方面，HADOOP社區活躍，軟體進化較快，從業人員供應相對較多，且有相對較多的真實應用案例，這使得應用風險相對較低。

基於以上這些原因，在做軟體選型的時候，HADOOP無疑是目前相對最經濟可靠的方案。

謝邀請。

我得一篇博客：為什麼出現Hadoop

就像寫個資訊網站都選PHP，寫個電商網站都選JAVA一樣，省心和從眾心理。

Hadoop可以做什麼？

1 離線數據分析，例如互聯網用戶行為日誌分析、金融行業的信用評估與風險控制；

2 可擴展的數據存儲，可以看成是EMC存儲的一種替代方案。

Hadoop做不了什麼？

1 速度比較低，不適合做實時查詢，比如在一些網站中取代 OracleMysql等傳統的關係型資料庫。即便是 Hbase也不行，速度依然很低。話說Storm可以嗎？不行。Storm是做實時流計算的，用於取代 OracleMysql等傳統的關係型資料庫依然不行。

當前如火如荼的大數據能夠替代 OracleMysql等傳統的關係型資料庫嗎？

1 淘寶的OceanBase（開源、免費）也許可以。

2 Apache Spark（開源、免費、基於內存）也許也可以。

3 國內也有結合傳統關係型資料庫優勢與大數據理論優勢的產品（引跑的DBOne, 一款商業產品，類似OceanBase,我們正在使用。比較擔心其在事物方面的蒼白）

Hadoop為什麼這麼火？

1 開源、免費、實用、省錢。

2 追風、炒作。