Hadoop处于风雨飘摇中
作者簡介: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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Spark与Flink:对比与分析
- 下一篇: Hadoop vs Spark