Hadoop和Spark生态圈了解

作者簡介：Andrew C. Oliver是養貓達人，副業是軟體顧問。他是Mammoth Data公司（前身是Open Software Integrators）總裁兼創始人，這家大資料咨詢公司的總部設在北卡羅來納州達勒姆。

令人驚訝的是，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生态圈裡面有什麼？我在去年探讨過這個話題，但出現了許多新氣象，這回我幾乎從頭開始來介紹。

1. 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立方資料分析平台的廠商應該作好被颠覆的準備。