作者簡介：George Gilbert是Wikibon研究公司的大數(shù)據(jù)和數(shù)據(jù)分析分析師。

摘要：Hadoop或因身份危機而丟掉大數(shù)據(jù)領導者的寶座。

去年，我們都知道企業(yè)界的大數(shù)據(jù)意味著。它意味著Hadoop，它處于大幅采用浪潮的鼎盛時期。如今，大數(shù)據(jù)仍然追波逐浪，但目前還不清楚Hadoop是否跟得上勢頭。

Hadoop的成功在生態(tài)系統(tǒng)方面帶來了意想不到的影響。Hadoop這個名頭始終適用于幾大廠商中任何一家組織并監(jiān)管的一系列開源大數(shù)據(jù)工具，其中以Cloudera、Hortonworks和MapR為首。但是，我們看到類似的、創(chuàng)新的開源工具遍地開花，它們在建立替代的生態(tài)系統(tǒng)，比如Spark、Kafka、Mesos、S3和Cassandra。說實話，這樣的工具有幾十種。這一批新工具迅速崛起，有可能排擠Hadoop，進而丟掉新興的大數(shù)據(jù)生態(tài)系統(tǒng)的“當家花旦”這一稱號。

Hadoop的身份危機給大數(shù)據(jù)專業(yè)人士帶來了挑戰(zhàn)，因為該生態(tài)系統(tǒng)現(xiàn)在包括種類極其廣泛的工具，以至于削弱了生態(tài)系統(tǒng)的一致連貫性：

• Splunk是一個替代者。它與其說是一種工具包，還不如說是一種應用軟件，所以它直接提供了價值，而不是要求為期6個月至9個月的試點，它需要的專業(yè)開發(fā)人員和管理技能也要少得多。

• 基于持續(xù)處理的實時應用軟件，比如Kafka、Spark和Flink，將Hadoop逼到了絕境，因為Hadoop是為批處理而設計的。

• 由于工具數(shù)量猛增，Hadoop廠商在工具如何協(xié)同運行方面已失去了太多的控制權(quán)。當一系列工具廣為人知的時候，Hadoop可以用自己的管理工具將它們連接起來，幫助簡化它們?nèi)绾螀f(xié)同運行。

回顧歷程，才能洞察未來

Hadoop的傳統(tǒng)強項一直在于它為客戶提供的靈活性。客戶頭一次使用自己動手（DIY）的方法，利用開源組件組裝分析數(shù)據(jù)管道。與此同時，沒有哪一家企業(yè)組織開發(fā)所有的組件。這種隨心所欲的治理方法及客戶需求促使大數(shù)據(jù)工具的數(shù)量和質(zhì)量出現(xiàn)了顯著增長，Hadoop廠商可以借助這些工具，組織并監(jiān)管它們發(fā)行的一系列工具。

我們參加2015年在圣何塞召開的Hadoop峰會時，“三大Hadoop”發(fā)行版廠商：Cloudera、Hortonworks和MapR基本上就大數(shù)據(jù)管理平臺應該包括哪些部分達成了相當廣泛的共識。即使人們的注意力開始遠離MapReduce，Hadoop的核心對所有使用場合來說仍包括Hadoop分布式文件系統(tǒng)（HDFS）和YARN。每家Hadoop發(fā)行版廠商還加入了另外20個至30個Apache項目，這些項目使得每一個發(fā)行版都大同小異。最后，發(fā)行版廠商添加了管理工具，幫助整合當初開發(fā)時完全缺乏集中協(xié)調(diào)的所有這些組件。即便發(fā)行版仍然相當笨拙，大數(shù)據(jù)專業(yè)人士仍通常了解每個部分的功能、它與其他部分是怎么協(xié)同工作的。

快進到幾周前召開的2016年Hadoop峰會。

開源大數(shù)據(jù)軟件產(chǎn)品數(shù)量激增的步伐有增無減，而這是個問題。三巨頭當初就哪些部分屬于Hadoop生態(tài)系統(tǒng)方面達成的脆弱共識在漸漸瓦解。

因而，客戶隨之困惑起來。層出不窮的技術在迅速帶來新的營銷術語，比新的技術、應用軟件或客戶還要快。我們在Hadoop峰會上一遍又一遍地聽到客戶說：我們失去了從生態(tài)系統(tǒng)太多的組件中進行選擇，組裝一條連貫的分析數(shù)據(jù)管道的能力。這就破壞了當初讓Hadoop得以流行起來的“混合搭配”（mix-and-match）這一價值主張。

Hortonworks似乎勢必會看到這股浪潮即將襲來。這家公司告訴我們，它會更加規(guī)范，界定如何為每一種使用場合選擇合適的組件。而認識到大數(shù)據(jù)現(xiàn)在不再僅限于Hadoop，它宣布未來的大會將名為Dataworks，而不是Hadoop峰會。但最重要的是，業(yè)界也需要一家廠商，能夠領導其他廠商圍繞一種新平臺達成共識，穩(wěn)住生態(tài)系統(tǒng)越來越混亂的局面。

那么，究竟是什么因素“引發(fā)”大數(shù)據(jù)產(chǎn)品遍地開花？

微微星火可以燎原

意大利文藝復興運動先驅(qū)但丁在寫下那些話語的時候，顯然沒有想到Hadoop，但這就是我們今天所處的現(xiàn)狀。Hadoop的開頭很普通：雅虎和谷歌將它用作一種簡單的、專業(yè)的產(chǎn)品，旨在索引網(wǎng)頁，以便搜索。但是三大Hadoop廠商認識到，Hadoop的作用可能不僅限此，于是把自己扮演成了開源Hadoop平臺的守護者，面向數(shù)據(jù)豐富的應用系統(tǒng)。

我們不妨更認真地探究一下Hadoop的定義方面達成的這種共識現(xiàn)在如何瓦解，以及為何如此。Spark能夠持續(xù)處理數(shù)據(jù)，它正在迅速取代批處理技術MapReduce，作為Hadoop中的默認執(zhí)行引擎。Spark為Hadoop帶來了全新的使用場合。因而可以借助高級分析構(gòu)建持續(xù)處理功能，而不是僅僅擁有數(shù)據(jù)流功能，作為批處理的一種輔助。

Hadoop廠商的競爭對手不是對方，而是更容易被開發(fā)人員和管理員訪問及使用的大數(shù)據(jù)3.0云服務。

頗具諷刺意味的是，Spark具有的廣度讓我們有可能構(gòu)建核心平臺，一個全新的生態(tài)系統(tǒng)（包括構(gòu)建大數(shù)據(jù)豐富應用程序的工具）圍繞這個核心平臺而建。現(xiàn)在用的是Cassandra，而不是HBase；現(xiàn)在用的是Docker容器和Mesos或Kubernetes，而不是YARN。現(xiàn)在用的是Kafka，而不是Flume。現(xiàn)在用的是S3或幾乎任何商用對象存儲系統(tǒng)，而不是HDFS這個最終的“蟑螂即幸存者”（cockroach-as-survivor）技術。

所有這些創(chuàng)新隨之帶來了管理和開發(fā)方面的復雜性。主流企業(yè)無力或不愿招聘稀缺、必要又昂貴的技術人才，而是日益求助于亞馬遜、微軟和谷歌，以及夯實其服務或基礎設施的其他廠商，提供“XX即服務”這種簡單性。

除了Hadoop外，這些云提供商對于分析即服務也有自己的見解。如今，客戶可以選擇運行在這些提供商的云端托管的Hadoop，換取一些專門、專有的功能，比如借助亞馬遜Kinesis Firehose的彈性數(shù)據(jù)獲取，或者Azure方面的機器學習API庫。隨著時間的推移，我們要求云提供商在其專有服務之間提供極其深度的整合。如果客戶愿意放棄開源軟件，云提供商可能會提供大數(shù)據(jù)分析套件在開發(fā)和管理方面的簡單性，而這種大數(shù)據(jù)分析套件是作為一個單元而設計、構(gòu)建、測試、運行和交付的。

如果傳統(tǒng)的Hadoop廠商想在這個迅速擴大的生態(tài)系統(tǒng)里面競爭，它們要做的不僅僅是組織并監(jiān)管一系列工具，還需要構(gòu)建一個一致連貫的平臺，可以隱藏眾多工具在管理和開發(fā)方面的復雜性。

總結(jié)

以上是生活随笔為你收集整理的Hadoop处于风雨飘摇中的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。