Hadoop/Spark生態圈裏的新氣象【轉】

引伸閱讀： 

https://databricks.com/blog/2015/04/28/project-tungsten-bringing-spark-closer-to-bare-metal.html

http://blog.csdn.net/ytbigdata/article/details/50721174-Spark的下一代引擎-Project Tungsten啓示錄

使人驚訝的是，Hadoop在短短一年的時間裏被從新定義。讓咱們看看這個火爆生態圈的全部主要部分，以及它們各自具備的意義。

　　對於Hadoop你須要瞭解的最重要的事情就是 ，它再也不是原來的Hadoop。

　　這邊廂，Cloudera有時換掉HDFS改用Kudu，同時宣佈Spark是其圈子的核心(於是一律取代發現的MapReduce);那邊廂，Hortonworks加入了Spark陣營。在Cloudera和Hortonworks之間，「Hadoop」集羣中惟一能夠確信的項目就是 YARN。可是Databricks(又叫Spark人)偏心Mesos而不是YARN;順便說一句，Spark不須要HDFS。

　　不過，分佈式文件系統依然有用。對Cloudera的Impala來講，商業智能是一種理想的使用場合;而分佈式列式存儲系統Kudu針對商業智能進行了優化。Spark很適合處理許多任務，但有時候你須要像Impala這樣的大規模並行處理(MPP)解決方案來達到目的，而Hive還是一種有用的文件到表管理系統。即便你由於專一於Spark的內存中實時分析技術而沒有使用Hadoop，到頭來仍可能處處使用Hadoop的部分。

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

　　如今你須要知道這個新的Hadoop/Spark生態圈裏面有什麼?我在去年探討過這個話題，但出現了許多新氣象，這回我幾乎從頭開始來介紹。

Spark

　　Spark的運行速度正如其名;更重要的是，API用起來容易得多，所需的代碼比以前的分佈式計算模式來得少。IBM承諾會培訓100萬名新的 Spark開發人員，爲這個項目備好了龐大資金，Cloudera宣佈Spark是咱們知道與其一個平臺(One Platform)計劃配套的全部項目的核心，加上Hortonworks全力支持Spark，鑑於這種形勢，咱們能夠確定地說，業界已將「技術環球小姐」(Tech Miss Universe)這頂桂冠授予了Spark(希望這回沒有弄錯)。

　　成本因素也在推進Spark迅猛崛起。過去在內存中分析數據成本高昂，但由了雲計算和更高的計算彈性，沒法裝入到內存(至少在分佈式計算集羣上)中的工做負載的數量在日益減小。一樣，咱們談論的不是你的全部數據，而是爲了計算結果而須要的一小部分數據。

　　Spark仍然不盡如人意――若是在生產環境中使用它，咱們確實看到了這一幕，可是缺點值得忍受。Spark其實速度快得多，並且徹底有了改進。

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

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

2. Hive

　　Hive讓你能夠對文本文件或結構化文件執行SQL查詢。那些文件一般駐留在HDFS上，這時你可使用Hive，Hive能夠將文件編入目錄，並暴露文件，好像它們就是表。你經常使用的SQL工具能夠經過JDBC或ODBC鏈接到Hive。

　　簡而言之，Hive是一個乏味、緩慢但又有用的工具。默認狀況下，它將SQL任務轉換成MapReduce任務。你能夠切換它，使用基於DAG的Tez，而Tez的速度快得多。還能夠切換它，使用Spark，不過「alpha」這個詞沒法體現真正體驗。

　　你須要知道Hive，由於許多Hadoop項目一開始「就讓咱們將數據轉儲到某個地方」，而後「順便提一下，咱們想在經常使用的SQL圖表工具中看看數據。」Hive是最直觀簡單的辦法。若是你想高效地查看數據，可能須要其餘工具(好比Phoenix或Impala)。

3. Kerberos

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

4. Ranger/Sentry

　　若是你不使用Ranger或Sentry，那麼大數據平臺的每個部分都將進行本身的驗證和受權。不會有集中控制，每一個部分都會以本身的獨特方式看世界。

　　那麼該選擇哪個：Ranger仍是Sentry?這麼說吧，眼下Ranger彷佛有點領先，較爲全面，不過它是Hortonworks的產物。 Sentry則是Cloudera的產物。各自支持Hadoop堆棧中相應廠商支持的那一部分。若是你沒打算得到Cloudera或 Hortonworks的支持，那麼我要說，Ranger是眼下更勝一籌的解決方案。然而，Cloudera走在Spark的前面，該公司還宣佈了安全方面的重大計劃，做爲「一個平臺」戰略的一部分，這勢必會讓Sentry處於領先。(坦率地說，若是Apache運做正常，它會對這兩家廠商施加壓力，共同開發一款解決方案。)

5. HBase/Phoenix

　　HBase是一種徹底能夠接受的列式數據存儲系統。它還內置到你經常使用的Hadoop發行版中，它獲得Ambari的支持，與Hive能夠順暢地鏈接。若是你添加Phoenix，甚至可使用經常使用的商業智能工具來查詢HBase，好像它就是SQL數據庫。若是你經過Kafka和Spark或 Storm獲取流數據，那麼HBase就是合理的着陸點，以便該數據持久化，至少保持到你對它進行別的操做。

　　使用Cassandra之類的替代方案有充分理由。但若是你使用Hadoop，那就已經有了HBase――若是你向Hadoop廠商購買支持服務，已經有了支持HBase的功能――因此這是個良好的起點。畢竟，它是一種低延遲、持久化的數據存儲系統，爲原子性、一致性、隔離性和持久性(ACID)提供了至關給力的支持。若是Hive和Impala的SQL性能沒有引發你的興趣，你會發現HBase和Phoenix處理一些數據集比較快。

6. Impala

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

　　Impala和Hive之間的最大區別在於，你鏈接經常使用的商業智能工具時，「日常事務」會在幾秒鐘內運行，而不是幾分鐘內運行。Impala在許多應用場合能夠取代Teradata和Netezza。對不一樣類型的查詢或分析而言，其餘結構可能必不可少(針對這種狀況，可着眼於Kylin和 Phoenix之類的技術)。但一般來講，Impala讓你能夠避開討厭的專有MPP系統，使用單一平臺來分析結構化數據和非結構化數據，甚至部署到雲端。

　　這與使用正宗的Hive存在諸多重疊，但Impala和Hive的操做方式不同，有着不一樣的最佳適用場合。Impala獲得Cloudera的支持，但未獲得Hortonworks的支持，Hortonworks改而支持Phoenix。雖然運行Impala不太複雜，可是你使用Phoenix能夠實現一樣的一些目標，Cloudera現正將注意力轉向Phoenix。

7. HDFS(Hadoop分佈式文件系統)

　　因爲Spark大行其道，所謂的大數據項目不斷遷移到雲端，HDFS不如去年來得重要。可是它仍然是默認技術，也是概念上比較簡單的實現分佈式文件系統的技術之一。

8. Kafka

　　分佈式消息系統(如Kafka提供的系統)會徹底淘汰像ActiveMQ這樣的客戶機/服務器工具。即使Kafka沒有用在大多數流數據項目上，至少也用在許多流數據項目。它也很簡單。若是你使用其餘消息傳遞工具，會以爲它有點原始簡陋，但在大多數狀況下，你不管如何也不須要MQ類解決方案提供的細粒度路由選項。

9. Storm/Apex

　　Spark處理流數據不是很擅長，可是Storm如何呢?它速度更快，延遲更低，並且耗用更少的內存――大規模獲取流數據時，這點很重要。另外一方面，Storm的管理工具較爲遜色，API也不如Spark的API同樣好。Apex更新更好，但尚未獲得普遍部署。我仍會在默認狀況下選擇Spark 處理不須要亞秒級的任何事務。

10. Ambari / Cloudera Manager

　　我見過有人不用Ambari或Cloudera Manager，試着監視和管理Hadoop集羣。效果很差。這兩種解決方案在比較短的時間裏，讓Hadoop環境的管理和監控功能取得了長足發展。不妨與NoSQL領域做個比較：NoSQL領域在這方面遠遠不如Hadoop同樣先進，儘管用的是更簡單的軟件，組件數量少得多，你確定很想知道那些 NoSQL人員把大量資金究竟花在了哪裏。

11. Pig

　　我想這恐怕是Pig最後一年上個人名單。Spark的速度快得多，能夠用於許多一樣的ETL場合，而Pig Latin(沒錯，他們就是這麼稱呼這門語言的)有點怪異，並且經常使人沮喪。正如你想象，在Spark上運行Pig須要費老大的勁。

　　從理論上來講，在Hive上執行SQL的人能夠改用Pig，就像他們過去由SQL改用PL/SQL那樣，但事實上，Pig不如PL/SQL來得簡單。介於普通SQL和正宗Spark之間的技術可能還有生存餘地，但我認爲Pig不是這種技術。來自另外一個方向的是Apache Nifi，這讓你能夠作一些一樣的ETL，可是少用或不用代碼。咱們已經使用Kettle減小了編寫的ETL代碼數量，這至關棒。

12. YARN/ Mesos

　　YARN和Mesos讓你可以跨集羣執行任務隊列和調度操做。每一個人都在嘗試各類方法：Spark到YARN、Spark到Mesos、Spark 到YARN到Mesos，等等。但要知道，Spark的獨立模式對於忙碌的多任務多用戶集羣來講不是很切實際。若是你不專門使用Spark，仍運行 Hadoop批處理任務，那麼眼下就選擇YARN。

13. Nifi /Kettle

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

　　若是今天你須要這個，但想要更成熟一點的技術，不妨使用Pentaho公司的Kettle(以及其餘相關工具，好比Spoon)。這些工具在生產環境中很有成效已有一段時間。咱們用過它們。坦率地說，它們很不賴。

14. Knox

　　雖然Knox是很強大的邊緣保護機制，但它的做用就是，爲用Java編寫的反向代理系統提供驗證。它不是寫得很好;舉例說，它掩蓋了錯誤。另外，儘管它使用了URL重寫，但僅僅在後面添加一個新服務就須要完整的Java實現。

　　你須要知道Knox，由於若是有人想要邊緣保護，這是提供這種保護的「欽定」方式。坦率地說，要是有小小的修改，或者面向HTTPD的mod_proxy的附件，它會更實用，並提供一系列更普遍的驗證選項。

15. Scala/ Python

　　從技術上來講，你能夠用Java 8處理Spark或Hadoop任務。但實際上，支持Java 8是過後添加的功能，那樣銷售人員能夠告訴大公司它們仍能夠利用原來的Java開發人員。事實上，Java 8是一門新語言，若是你使用得當的話――在在種狀況下，我認爲Java 8拙劣地模仿Scala。

　　尤爲是對Spark而言，Java落後於Scala，可能甚至落後於Python。本人其實並不喜歡Python，但它獲得了Spark及其餘工具至關有力的支持。它還有成熟的代碼庫;就許多數據科學、機器學習和統計應用而言，它將是首選語言。Scala是Spark的第一選擇，也愈來愈可能是其餘工具集的第一選擇。對於「偏運算」的數據，你可能須要Python或R，由於它們的代碼庫很強大。

　　記住：若是你用Java 7編寫任務，那太傻了。若是使用Java 8，那是因爲有人對你老闆撒了謊。

16. Zeppelin/ Databricks

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

　　最終，你的數據被記錄並執行，圖表很漂亮!

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

值得關注的新技術

　　我還不會將這些技術應用到生產環境，可是必定要了解它們。

　　Kylin ：一些查詢須要更低的延遲，因而你一頭有HBase;另外一頭，更龐大的分析查詢可能不適合HBase――所以另外一頭使用 Hive。此外，一再合併幾個表來計算結果速度緩慢，因此「預合併」(prejoining)和「預計算」( precalculating)這些數據處理成數據立方(Cube)對這類數據集來講是一大優點。這時候，Kylin有了用武之地。

　　Kylin是今年的後起之秀。咱們已經看到有人將Kylin用於生產環境，不過我建議仍是謹慎一點爲好。由於Kylin並不適用於一切，其採用也不如Spark來得普遍，可是Kylin也受到一樣熱烈的追捧。眼下，你對它應該至少了解一點。

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

我寧願遺忘的技術

　　下面是我會很高興地扔到窗外的技術。我之因此這麼任性，是由於已出現了更出色地執行同一功能的新技術。

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

　　不妨舉例說明：隱藏錯誤，功能不是失靈就是與文檔描述的不同、XML錯誤方面的說明文檔徹底不正確、支離破碎的驗證器，不一而足。Oozie徹底自吹自擂。它寫得不好勁;要是哪裏出了問題，連基本的任務都會變成須要一週才搞得定。因爲Nifi及其餘工具取而代之，我沒期望會大量使用Oozie。

　　MapReduce ：Hadoop的這個處理核心在漸行漸遠。DAG算法能夠更有效地利用資源。Spark使用更好的API在內存中處理數據。因爲內存變得愈來愈便宜，向雲計算遷移的步伐加快，支持繼續使用MapReduce的成本緣由漸漸站不住腳。

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

　　與MapReduce同樣，使用Tez的成本緣由(磁盤與內存)漸漸站不住腳。繼續使用它的主要緣由是：面向一些流行Hadoop工具的Spark 綁定不太成熟，或者根本就沒有準備好。然而，因爲Hortonworks加入了向Spark靠攏的陣營，Tez到年末以前彷佛不太可能有一席之地。要是你如今不知道Tez，也不用心煩。

如今是大好時機

　　Hadoop/Spark領域在不斷變化。儘管存在一些碎片化現象，不過隨着圍繞Spark的生態圈日益穩固，核心會變得穩定得多。

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

 

　　若是你尚未採用大數據技術，眼下正是趁機進入的大好時機。發展太快了，啥時行動永遠不會太晚。同時，主攻遺留MPP立方數據分析平臺的廠商應該做好被顛覆的準備。