作者簡(jiǎn)介：Andrew C. Oliver是養(yǎng)貓達(dá)人，副業(yè)是軟件顧問。他是Mammoth Data公司（前身是Open Software Integrators）總裁兼創(chuàng)始人，這家大數(shù)據(jù)咨詢公司的總部設(shè)在北卡羅來納州達(dá)勒姆。

令人驚訝的是，Hadoop在短短一年的時(shí)間里被重新定義。讓我們看看這個(gè)火爆生態(tài)圈的所有主要部分，以及它們各自具有的意義。

對(duì)于Hadoop你需要了解的最重要的事情就是，它不再是原來的Hadoop。

這邊廂，Cloudera有時(shí)換掉HDFS改用Kudu，同時(shí)宣布Spark是其圈子的核心（因而一概取代發(fā)現(xiàn)的MapReduce）；那邊廂，Hortonworks加入了Spark陣營(yíng)。在Cloudera和Hortonworks之間，“Hadoop”集群中唯一可以確信的項(xiàng)目就是YARN。但是Databricks（又叫Spark人）偏愛Mesos而不是YARN；順便說一句，Spark不需要HDFS。

不過，分布式文件系統(tǒng)依然有用。對(duì)Cloudera的Impala來說，商業(yè)智能是一種理想的使用場(chǎng)合；而分布式列式存儲(chǔ)系統(tǒng)Kudu針對(duì)商業(yè)智能進(jìn)行了優(yōu)化。Spark很適合處理許多任務(wù)，但有時(shí)候你需要像Impala這樣的大規(guī)模并行處理（MPP）解決方案來達(dá)到目的，而Hive仍是一種有用的文件到表管理系統(tǒng)。即使你因?yàn)閷Ｗ⒂赟park的內(nèi)存中實(shí)時(shí)分析技術(shù)而沒有使用Hadoop，到頭來仍可能到處使用Hadoop的部分。

Hadoop絕對(duì)沒有消亡，不過我確信，知名研究機(jī)構(gòu)Gartner的下一篇文章會(huì)這么認(rèn)為。但Hadoop絕不再是原來的Hadoop。

現(xiàn)在你需要知道這個(gè)新的Hadoop/Spark生態(tài)圈里面有什么？我在去年探討過這個(gè)話題，但出現(xiàn)了許多新氣象，這回我?guī)缀鯊念^開始來介紹。

1. Spark

Spark的運(yùn)行速度正如其名；更重要的是，API用起來容易得多，所需的代碼比之前的分布式計(jì)算模式來得少。IBM承諾會(huì)培訓(xùn)100萬名新的Spark開發(fā)人員，為這個(gè)項(xiàng)目備好了龐大資金，Cloudera宣布Spark是我們知道與其一個(gè)平臺(tái)（One Platform）計(jì)劃配套的所有項(xiàng)目的核心，加上Hortonworks全力支持Spark，鑒于這種形勢(shì)，我們可以肯定地說，業(yè)界已將“技術(shù)環(huán)球小姐”（Tech Miss Universe）這頂桂冠授予了Spark（但愿這回沒有弄錯(cuò)）。

成本因素也在推動(dòng)Spark迅猛崛起。過去在內(nèi)存中分析數(shù)據(jù)成本高昂，但由了云計(jì)算和更高的計(jì)算彈性，無法裝入到內(nèi)存（至少在分布式計(jì)算集群上）中的工作負(fù)載的數(shù)量在日益減少。同樣，我們談?wù)摰牟皇悄愕乃袛?shù)據(jù)，而是為了計(jì)算結(jié)果而需要的一小部分?jǐn)?shù)據(jù)。

Spark仍然不盡如人意――如果在生產(chǎn)環(huán)境中使用它，我們確實(shí)看到了這一幕，但是缺點(diǎn)值得忍受。Spark其實(shí)速度快得多，而且完全有了改進(jìn)。

具有諷刺意味的是，Spark方面動(dòng)靜最大的恰恰與流數(shù)據(jù)有關(guān)，而這是Spark的最大軟肋。Cloudera宣布旨在讓Spark流數(shù)據(jù)技術(shù)適用于80%的使用場(chǎng)合，就考慮到了這一缺陷。不過，你可能仍需要探究替代方案，以實(shí)現(xiàn)亞秒級(jí)或大容量的數(shù)據(jù)獲取（而不是數(shù)據(jù)分析）。

Spark不僅避免了需要MapReduce和Tez，還可能避免了Pig之類的工具。此外，Spark的RDD/DataFrames API并不是進(jìn)行抽取、轉(zhuǎn)換和加載（ETL）及其他數(shù)據(jù)轉(zhuǎn)換的糟糕方法。與此同時(shí)，Tableau及其他數(shù)據(jù)可視化廠商已宣布打算直接支持Spark。

2. Hive

Hive讓你可以對(duì)文本文件或結(jié)構(gòu)化文件執(zhí)行SQL查詢。那些文件通常駐留在HDFS上，這時(shí)你可以使用Hive，Hive可以將文件編入目錄，并暴露文件，好像它們就是表。你常用的SQL工具可以通過JDBC或ODBC連接到Hive。

簡(jiǎn)而言之，Hive是一個(gè)乏味、緩慢但又有用的工具。默認(rèn)情況下，它將SQL任務(wù)轉(zhuǎn)換成MapReduce任務(wù)。你可以切換它，使用基于DAG的Tez，而Tez的速度快得多。還可以切換它，使用Spark，不過“alpha”這個(gè)詞無法體現(xiàn)真正體驗(yàn)。

你需要知道Hive，因?yàn)樵S多Hadoop項(xiàng)目一開始“就讓我們將數(shù)據(jù)轉(zhuǎn)儲(chǔ)到某個(gè)地方”，然后“順便提一下，我們想在常用的SQL圖表工具中看看數(shù)據(jù)。”Hive是最直觀簡(jiǎn)單的辦法。如果你想高效地查看數(shù)據(jù)，可能需要其他工具（比如Phoenix或Impala）。

3. Kerberos

我討厭Kerberos，它也不是那么喜歡我。遺憾的是，它又是唯一為Hadoop全面實(shí)施的驗(yàn)證技術(shù)。你可以使用Ranger或Sentry等工具來減少麻煩，不過仍可能要通過Kerberos與活動(dòng)目錄進(jìn)行集成。

4. Ranger/Sentry

如果你不使用Ranger或Sentry，那么大數(shù)據(jù)平臺(tái)的每一個(gè)部分都將進(jìn)行自己的驗(yàn)證和授權(quán)。不會(huì)有集中控制，每個(gè)部分都會(huì)以自己的獨(dú)特方式看世界。

那么該選擇哪一個(gè)：Ranger還是Sentry？這么說吧，眼下Ranger似乎有點(diǎn)領(lǐng)先，較為全面，不過它是Hortonworks的產(chǎn)物。Sentry則是Cloudera的產(chǎn)物。各自支持Hadoop堆棧中相應(yīng)廠商支持的那一部分。如果你沒打算獲得Cloudera或Hortonworks的支持，那么我要說，Ranger是眼下更勝一籌的解決方案。然而，Cloudera走在Spark的前面，該公司還宣布了安全方面的重大計(jì)劃，作為“一個(gè)平臺(tái)”戰(zhàn)略的一部分，這勢(shì)必會(huì)讓Sentry處于領(lǐng)先。（坦率地說，如果Apache運(yùn)作正常，它會(huì)對(duì)這兩家廠商施加壓力，共同開發(fā)一款解決方案。）

5. HBase/Phoenix

HBase是一種完全可以接受的列式數(shù)據(jù)存儲(chǔ)系統(tǒng)。它還內(nèi)置到你常用的Hadoop發(fā)行版中，它得到Ambari的支持，與Hive可以順暢地連接。如果你添加Phoenix，甚至可以使用常用的商業(yè)智能工具來查詢HBase，好像它就是SQL數(shù)據(jù)庫(kù)。如果你通過Kafka和Spark或Storm獲取流數(shù)據(jù)，那么HBase就是合理的著陸點(diǎn)，以便該數(shù)據(jù)持久化，至少保持到你對(duì)它進(jìn)行別的操作。

使用Cassandra之類的替代方案有充分理由。但如果你使用Hadoop，那就已經(jīng)有了HBase――如果你向Hadoop廠商購(gòu)買支持服務(wù)，已經(jīng)有了支持HBase的功能――所以這是個(gè)良好的起點(diǎn)。畢竟，它是一種低延遲、持久化的數(shù)據(jù)存儲(chǔ)系統(tǒng)，為原子性、一致性、隔離性和持久性（ACID）提供了相當(dāng)給力的支持。如果Hive和Impala的SQL性能沒有引起你的興趣，你會(huì)發(fā)現(xiàn)HBase和Phoenix處理一些數(shù)據(jù)集比較快。

6. Impala

Teradata和Netezza使用MPP來處理跨分布式存儲(chǔ)的SQL查詢。Impala實(shí)際上是基于HDFS的一種MPP解決方案。

Impala和Hive之間的最大區(qū)別在于，你連接常用的商業(yè)智能工具時(shí)，“平常事務(wù)”會(huì)在幾秒鐘內(nèi)運(yùn)行，而不是幾分鐘內(nèi)運(yùn)行。Impala在許多應(yīng)用場(chǎng)合可以取代Teradata和Netezza。對(duì)不同類型的查詢或分析而言，其他結(jié)構(gòu)可能必不可少（針對(duì)這種情況，可著眼于Kylin和Phoenix之類的技術(shù)）。但通常來說，Impala讓你可以避開討厭的專有MPP系統(tǒng)，使用單一平臺(tái)來分析結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，甚至部署到云端。

這與使用正宗的Hive存在諸多重疊，但I(xiàn)mpala和Hive的操作方式不一樣，有著不同的最佳適用場(chǎng)合。Impala得到Cloudera的支持，但未得到Hortonworks的支持，Hortonworks改而支持Phoenix。雖然運(yùn)行Impala不太復(fù)雜，但是你使用Phoenix可以實(shí)現(xiàn)同樣的一些目標(biāo)，Cloudera現(xiàn)正將注意力轉(zhuǎn)向Phoenix。

7. HDFS（Hadoop分布式文件系統(tǒng)）

由于Spark大行其道，所謂的大數(shù)據(jù)項(xiàng)目不斷遷移到云端，HDFS不如去年來得重要。但是它仍然是默認(rèn)技術(shù)，也是概念上比較簡(jiǎn)單的實(shí)現(xiàn)分布式文件系統(tǒng)的技術(shù)之一。

8. Kafka

分布式消息系統(tǒng)（如Kafka提供的系統(tǒng)）會(huì)完全淘汰像ActiveMQ這樣的客戶機(jī)/服務(wù)器工具。即便Kafka沒有用在大多數(shù)流數(shù)據(jù)項(xiàng)目上，至少也用在許多流數(shù)據(jù)項(xiàng)目。它也很簡(jiǎn)單。如果你使用其他消息傳遞工具，會(huì)覺得它有點(diǎn)原始簡(jiǎn)陋，但在大多數(shù)情況下，你無論如何也不需要MQ類解決方案提供的細(xì)粒度路由選項(xiàng)。

9. Storm/Apex

Spark處理流數(shù)據(jù)不是很擅長(zhǎng)，但是Storm如何呢？它速度更快，延遲更低，而且耗用更少的內(nèi)存――大規(guī)模獲取流數(shù)據(jù)時(shí)，這點(diǎn)很重要。另一方面，Storm的管理工具較為遜色，API也不如Spark的API一樣好。Apex更新更好，但還沒有得到廣泛部署。我仍會(huì)在默認(rèn)情況下選擇Spark處理不需要亞秒級(jí)的任何事務(wù)。

10. Ambari / Cloudera Manager

我見過有人不用Ambari或Cloudera Manager，試著監(jiān)視和管理Hadoop集群。效果不好。這兩種解決方案在比較短的時(shí)間里，讓Hadoop環(huán)境的管理和監(jiān)控功能取得了長(zhǎng)足發(fā)展。不妨與NoSQL領(lǐng)域作個(gè)比較：NoSQL領(lǐng)域在這方面遠(yuǎn)遠(yuǎn)不如Hadoop一樣先進(jìn)，盡管用的是更簡(jiǎn)單的軟件，組件數(shù)量少得多，你肯定很想知道那些NoSQL人員把大量資金究竟花在了哪里。

11. Pig

我想這恐怕是Pig最后一年上我的名單。Spark的速度快得多，可以用于許多同樣的ETL場(chǎng)合，而Pig Latin（沒錯(cuò)，他們就是這么稱呼這門語言的）有點(diǎn)怪異，而且常常令人沮喪。正如你想象，在Spark上運(yùn)行Pig需要費(fèi)老大的勁。

從理論上來說，在Hive上執(zhí)行SQL的人可以改用Pig，就像他們過去由SQL改用PL/SQL那樣，但事實(shí)上，Pig不如PL/SQL來得簡(jiǎn)單。介于普通SQL和正宗Spark之間的技術(shù)可能還有生存余地，但我認(rèn)為Pig不是這種技術(shù)。來自另一個(gè)方向的是Apache Nifi，這讓你可以做一些同樣的ETL，但是少用或不用代碼。我們已經(jīng)使用Kettle減少了編寫的ETL代碼數(shù)量，這相當(dāng)棒。

12. YARN/ Mesos

YARN和Mesos讓你能夠跨集群執(zhí)行任務(wù)隊(duì)列和調(diào)度操作。每個(gè)人都在嘗試各種方法：Spark到Y(jié)ARN、Spark到Mesos、Spark到Y(jié)ARN到Mesos，等等。但要知道，Spark的獨(dú)立模式對(duì)于忙碌的多任務(wù)多用戶集群來說不是很切實(shí)際。如果你不專門使用Spark，仍運(yùn)行Hadoop批處理任務(wù)，那么眼下就選擇YARN。

13. Nifi /Kettle

Nifi將不得不竭力避免僅僅是Oozie的改進(jìn)版。諸多廠商聲稱Nifi是物聯(lián)網(wǎng)的解決之道，不過那是營(yíng)銷聲勢(shì)而已。實(shí)際上，Nifi好比為Hadoop與Spring整合。你需要通過轉(zhuǎn)換和隊(duì)列來管道傳輸數(shù)據(jù)，然后按時(shí)間表將數(shù)據(jù)放在某個(gè)地方――或者基于觸發(fā)器，處理來自諸多來源的數(shù)據(jù)。添加一個(gè)漂亮的圖形用戶界面（GUI），Nifi就成了。其魅力在于，有人為它編寫了一大批的連接件。

如果今天你需要這個(gè)，但想要更成熟一點(diǎn)的技術(shù)，不妨使用Pentaho公司的Kettle（以及其他相關(guān)工具，比如Spoon）。這些工具在生產(chǎn)環(huán)境中頗有成效已有一段時(shí)間。我們用過它們。坦率地說，它們很不賴。

14. Knox

雖然Knox是很強(qiáng)大的邊緣保護(hù)機(jī)制，但它的作用就是，為用Java編寫的反向代理系統(tǒng)提供驗(yàn)證。它不是寫得很好；舉例說，它掩蓋了錯(cuò)誤。另外，盡管它使用了URL重寫，但僅僅在后面添加一個(gè)新服務(wù)就需要完整的Java實(shí)現(xiàn)。

你需要知道Knox，因?yàn)槿绻腥讼胍吘壉Ｗo(hù)，這是提供這種保護(hù)的“欽定”方式。坦率地說，要是有小小的修改，或者面向HTTPD的mod_proxy的附件，它會(huì)更實(shí)用，并提供一系列更廣泛的驗(yàn)證選項(xiàng)。

15. Scala/ Python

從技術(shù)上來說，你可以用Java 8處理Spark或Hadoop任務(wù)。但實(shí)際上，支持Java 8是事后添加的功能，那樣銷售人員可以告訴大公司它們?nèi)钥梢岳迷瓉淼腏ava開發(fā)人員。事實(shí)上，Java 8是一門新語言，如果你使用得當(dāng)?shù)脑挩D―在在種情況下，我認(rèn)為Java 8拙劣地模仿Scala。

尤其是對(duì)Spark而言，Java落后于Scala，可能甚至落后于Python。本人其實(shí)并不喜歡Python，但它得到了Spark及其他工具相當(dāng)有力的支持。它還有成熟的代碼庫(kù)；就許多數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)和統(tǒng)計(jì)應(yīng)用而言，它將是首選語言。Scala是Spark的第一選擇，也越來越多是其他工具集的第一選擇。對(duì)于“偏運(yùn)算”的數(shù)據(jù)，你可能需要Python或R，因?yàn)樗鼈兊拇a庫(kù)很強(qiáng)大。

記住：如果你用Java 7編寫任務(wù)，那太傻了。如果使用Java 8，那是由于有人對(duì)你老板撒了謊。

16. Zeppelin/ Databricks

大多數(shù)人在iPython Notebook中首次碰到的Notebook概念很流行。編寫一些SQL或Spark代碼以及描述代碼的一些標(biāo)記，添加一個(gè)圖形，動(dòng)態(tài)執(zhí)行，然后保存起來，那樣別人就能從你的結(jié)果獲得一些東西。

最終，你的數(shù)據(jù)被記錄并執(zhí)行，圖表很漂亮！

Databricks有良好的開端，自我上一次表示對(duì)它膩味以來，其解決方案已經(jīng)成熟起來。另一方面，Zeppelin是開源的，沒必要非得從Databricks購(gòu)買云服務(wù)。你應(yīng)該知道其中一款這樣的工具。學(xué)會(huì)一款，學(xué)另一款不會(huì)太費(fèi)勁。

值得關(guān)注的新技術(shù)

我還不會(huì)將這些技術(shù)應(yīng)用到生產(chǎn)環(huán)境，但是一定要了解它們。

Kylin：一些查詢需要更低的延遲，于是你一頭有HBase；另一頭，更龐大的分析查詢可能不適合HBase――因此另一頭使用Hive。此外，一再合并幾個(gè)表來計(jì)算結(jié)果速度緩慢，所以“預(yù)合并”（prejoining）和“預(yù)計(jì)算”（ precalculating）這些數(shù)據(jù)處理成數(shù)據(jù)立方（Cube）對(duì)這類數(shù)據(jù)集來說是一大優(yōu)勢(shì)。這時(shí)候，Kylin有了用武之地。

Kylin是今年的后起之秀。我們已經(jīng)看到有人將Kylin用于生產(chǎn)環(huán)境，不過我建議還是謹(jǐn)慎一點(diǎn)為好。因?yàn)镵ylin并不適用于一切，其采用也不如Spark來得廣泛，但是Kylin也受到同樣熱烈的追捧。眼下，你對(duì)它應(yīng)該至少了解一點(diǎn)。

Atlas/Navigator：Atlas是Hortonworks新的數(shù)據(jù)治理工具。它甚至還談不上完全成熟，不過正取得進(jìn)展。我預(yù)計(jì)它可能會(huì)超過Cloudera的Navigator，但如果歷史重演的話，它會(huì)有一個(gè)不太花哨的GUI。如果你需要知道某個(gè)表的世系，或者沒必要逐列（tagging）地映射安全，那么Atlas或Navigator可能正是你需要的工具。如今治理是個(gè)熱門話題。你應(yīng)該知道這其中一項(xiàng)新技術(shù)的功能。

我寧愿遺忘的技術(shù)

下面是我會(huì)很高興地扔到窗外的技術(shù)。我之所以這么任性，是因?yàn)橐殉霈F(xiàn)了更出色地執(zhí)行同一功能的新技術(shù)。

Oozie：在去年的All Things Open大會(huì)上，來自Cloudera的Ricky Saltzer為Oozie辯護(hù)，說它適用于原本旨在處理的任務(wù)――也就是把幾個(gè)MapReduce任務(wù)串連起來；人們對(duì)于Oozie頗為不滿是要求過高。我仍要說，Oozie一無是處。

不妨舉例說明：隱藏錯(cuò)誤，功能不是失靈就是與文檔描述的不一樣、XML錯(cuò)誤方面的說明文檔完全不正確、支離破碎的驗(yàn)證器，不一而足。Oozie完全自吹自擂。它寫得很差勁；要是哪里出了問題，連基本的任務(wù)都會(huì)變成需要一周才搞得定。由于Nifi及其他工具取而代之，我沒指望會(huì)大量使用Oozie。

MapReduce：Hadoop的這個(gè)處理核心在漸行漸遠(yuǎn)。DAG算法可以更有效地利用資源。Spark使用更好的API在內(nèi)存中處理數(shù)據(jù)。由于內(nèi)存變得越來越便宜，向云計(jì)算遷移的步伐加快，支持繼續(xù)使用MapReduce的成本原因漸漸站不住腳。

Tez：從某種程度上說，Tez是條沒人走的路――或者說是分布式計(jì)算這棵進(jìn)化樹上早已過時(shí)的分支。與Spark一樣，它也是一種DAG算法，不過有個(gè)開發(fā)人員稱之為是匯編語言。

與MapReduce一樣，使用Tez的成本原因（磁盤與內(nèi)存）漸漸站不住腳。繼續(xù)使用它的主要原因是：面向一些流行Hadoop工具的Spark綁定不太成熟，或者根本就沒有準(zhǔn)備好。然而，由于Hortonworks加入了向Spark靠攏的陣營(yíng)，Tez到年底之前似乎不太可能有一席之地。要是你現(xiàn)在不知道Tez，也不用心煩。

現(xiàn)在是大好時(shí)機(jī)

Hadoop/Spark領(lǐng)域在不斷變化。盡管存在一些碎片化現(xiàn)象，不過隨著圍繞Spark的生態(tài)圈日益穩(wěn)固，核心會(huì)變得穩(wěn)定得多。

下一大增長(zhǎng)點(diǎn)將來自治理和技術(shù)的應(yīng)用，以及讓云計(jì)算化（cloudification）和容器化更容易管理、更簡(jiǎn)單的工具。這類進(jìn)步給錯(cuò)過第一波熱潮的廠商帶來了大好機(jī)會(huì)。

如果你還沒有采用大數(shù)據(jù)技術(shù)，眼下正是趁機(jī)進(jìn)入的大好時(shí)機(jī)。發(fā)展太快了，啥時(shí)行動(dòng)永遠(yuǎn)不會(huì)太晚。同時(shí)，主攻遺留MPP立方數(shù)據(jù)分析平臺(tái)的廠商應(yīng)該作好被顛覆的準(zhǔn)備。

總結(jié)

以上是生活随笔為你收集整理的Hadoop和Spark生态圈了解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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