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

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

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

不過，分布式文件系統(tǒng)依然有用。對Cloudera的Impala來說，商業(yè)智能是一種理想的使用場合;而分布式列式存儲系統(tǒng)Kudu針對商業(yè)智能進行了優(yōu)化。Spark很適合處理許多任務，但有時候你需要像Impala這樣的大規(guī)模并行處理(MPP)解決方案來達到目的，而Hive仍是一種有用的文件到表管理系統(tǒng)。即使你因為專注于Spark的內(nèi)存中實時分析技術而沒有使用Hadoop，到頭來仍可能到處使用Hadoop的部分。

Hadoop絕對沒有消亡，不過我確信，知名研究機構Gartner的下一篇文章會這么認為。但Hadoop絕不再是原來的Hadoop。

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

Spark

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

成本因素也在推動Spark迅猛崛起。過去在內(nèi)存中分析數(shù)據(jù)成本高昂，但由了云計算和更高的計算彈性，無法裝入到內(nèi)存(至少在分布式計算集群上)中的工作負載的數(shù)量在日益減少。同樣，我們談論的不是你的所有數(shù)據(jù)，而是為了計算結果而需要的一小部分數(shù)據(jù)。

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

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

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

2. Hive

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

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

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

3. Kerberos

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

4. Ranger/Sentry

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

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

5. HBase/Phoenix

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

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

6. Impala

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

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

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

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

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

8. Kafka

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

9. Storm/Apex

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

10. Ambari / Cloudera Manager

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

11. Pig

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

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

12. YARN/ Mesos

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

13. Nifi /Kettle

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

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

14. Knox

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

你需要知道Knox，因為如果有人想要邊緣保護，這是提供這種保護的“欽定”方式。坦率地說，要是有小小的修改，或者面向HTTPD的mod_proxy的附件，它會更實用，并提供一系列更廣泛的驗證選項。

15. Scala/ Python

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

尤其是對Spark而言，Java落后于Scala，可能甚至落后于Python。本人其實并不喜歡Python，但它得到了Spark及其他工具相當有力的支持。它還有成熟的代碼庫;就許多數(shù)據(jù)科學、機器學習和統(tǒng)計應用而言，它將是首選語言。Scala是Spark的第一選擇，也越來越多是其他工具集的第一選擇。對于“偏運算”的數(shù)據(jù)，你可能需要Python或R，因為它們的代碼庫很強大。

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

16. Zeppelin/ Databricks

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

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

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

值得關注的新技術

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

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

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

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

我寧愿遺忘的技術

下面是我會很高興地扔到窗外的技術。我之所以這么任性，是因為已出現(xiàn)了更出色地執(zhí)行同一功能的新技術。

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

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

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

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

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

現(xiàn)在是大好時機

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

下一大增長點將來自治理和技術的應用，以及讓云計算化(cloudification)和容器化更容易管理、更簡單的工具。這類進步給錯過第一波熱潮的廠商帶來了大好機會。

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