目前雲驅動數據處理和分析呈上升趨勢，我們在本文中來分析下，Apache Hadoop 在 2019 年是否還是一個可選方案。

從我第一次使用 Apache Hadoop 生態系統開始，圍繞著“大數據”和“機器學習”兩個術語，很多事情已經變得很不一樣。在本文中，我們來分析下從那之後發生了什麼，以及它在 2019 年與高效的託管雲服務相比又如何。

歷史回顧

Apache Hadoop 是提供“可靠的、可擴展的、分佈式計算”的開源框架， 它基於 Google 2003 年發佈的白皮書 “MapReduce：針對大數據的簡化數據處理”（點擊獲取），在 2006 問世。接下來，越來越多的工具（如 Yahoo 的 Pig）出現，Hortonworks、Cloudera 和 MapR 主要發行版一直在發佈，不斷刷新性能數據 (2008/2009)，Apache Hive 在 2010 年實現類 SQL 的支持， 像 YARN 這樣的資源調器也開始流行（2012/2013）。

大概在 2014/2015 年，Hadoop 有很多其他平臺所不具備的優勢—開源，突破了基於 Java 的 Map/Reduce 程序的限制，支持 Batch 和 Real-time 應用程序，能運行在所有能找到的舊硬件上，可以在本機運行（我的 2014 Macbook Pro 仍運行有本地 HDFS、YARN 和 Hive 實例 ），也可以在 Hortonworks 的 HDP、Cloudera 的 CDH 或者 MapR 上作為企業級解決方案運行。它使公司能夠收集、存儲和分析任何數據，並在公司的主要生產環境中被大量使用。

很多其他工具也支持該框架——下面的表格給出了本文會提到的組件列表的基本信息。

工具描述第一次發佈最近發佈YARN資源管理器和調度器20062019-02-06HbaseNoSQL 數據庫20082019-06-11Hive數據倉庫和 SQL 抽象20102019-05-14SqoopRDMBS 數據傳輸管道20092019-01-18Spark數據處理框架和計算引擎20142019-05-08Tez運行在 Hive 或 Pig 上的 DAG 計算框架20142019-03-29

可以看出，所有的最新發布都是在最近 6 個月內（從本文時間算起）。

不過任何事物都不可能沒有缺點——如大部分開源軟件一樣，尤其是模塊化地運行在幾百個甚至成千上萬臺機器上是一個很大的挑戰。配置、性能優化、工具選擇、維護、運維和開發都需要有資深專家的指導，來讓 Haoop 可以平穩運行，因為一個錯誤的配置都會嚴重降低整個系統的性能。同時，這種粒度控制的級別可以和工具的靈活度和適應性級別不匹配。

新興的雲市場

https://xkcd.com/1117/，CC BY-NC 2.5

然而，在過去的十幾年中，越來越多的公司從主要的雲服務，如 AWS、Google Cloud 和 Microsoft Azure 獲利。這有很多好處——如大量減少了本地基礎設施和管理的需求，提供靈活擴展的內存（ 從幾個 GB 到 TB）、存儲和 CPU，按使用付費的靈活計價模型，開箱即用的機器學習模型，可以和其他非“大數據”工具進行集成。

公司可以不再維護昂貴的內部裸機櫃，它可能一天中有 80% 處於空閒狀態，而在調度批處理運行時又導致資源受限和瓶頸，這取決於公司擁有的有領域專家或外部支持的工具，它們為大量的作業保留資源，這些作業可以在幾秒或幾分鐘內處理 TB 數量級的數據，僅需花費幾美元。

因此問題出現了——從那時起，Hadoop 發生了什麼——現在是否還需要它？

生態系統的整體變化情況

在深入到各個組件之前，我們從先簡要討論下發生了什麼。

2019 年早期，兩大提供商（Hortonworks 和 Cloudera）宣佈了兩個公司大規模的合併。這次合併對於所有熟悉這項技術的軟件工程師來說很有意義——兩個公司都工作在幾乎一樣的技術棧上，都深入到開源軟件，都通過便捷的管理和眾多可用工具來提供對 Hapoop 棧的支持或託管。Cloudera 側重於機器學習，而 Hortonwork 側重於數據獲取和聚合，並提供大力協作的可能性。他們在新聞稿中談到，在過去 12 月有 7.6 億美元的收益和 5 億美元的現金，無負債。

這次合併的戰略目標是專注於雲（有句話是：“雲，無處不在”）——不過是基於開源技術的雲。公司的目標是如同公有云提供商做到的一樣，讓用戶從 Hadoop 和（F）OSS（見上文）中受益。

這不是新的研發成果——Hortonwork 在 2018 年 7 月的 3.0 發佈中已經包含對所有云服務的存儲支持（不是嚴格意義上的 HDFS）。

同時，競爭者 MapR （關注專有解決方案），在2019 年 5 月宣佈裁員，並最終在 2019 年 6 月宣佈出售公司的意向。該公司在業務模式貨幣化和大力推動原生雲運營方面陷入了掙扎。

在這期間，公有云市場只有一個方向：Skywards。AWS，GCP 和 Azure 的盈利在各自公司的贏利中佔很大的比例，看起來，每次新的會議都會展示在各自的技術領域的領先技術，幾乎沒有公司會依賴於它們的本地數據中心。

IBM仍認為 Hadoop 有價值。

從那以後開源領域發生了什麼？

上面的介紹當然不會激發我們的信心，我們還應該看看在過去這些年裡到底發生了什麼——雲服務商從數據獲取一直到機器學習和分析都提供了很棒而且易用的產品，同時，（F）OSS 領域也一直在發展。

Hadoop 概述

Hadoop 3.0增加了大量的功能。

YARN 現在支持Docker 容器、TensorFlow 的GPU 調度、更先進的調度功能，整個平臺提供對AWS S3的本地支持。

這些變化讓組織可以改變 Hadoop 集群的運行方式，放棄在 YARN 上運行絕大部分批處理作業、分隔本地 ML 作業的傳統方法，轉而採用更現代化的基於容器的方法，利用 GPU 驅動的機器學習，並把雲服務提供商集成到“混合”或原生雲模型中。

HBase

Apache HBase 是我既愛又恨的事物之一——它很快，很強大，一旦理解了其基礎知識，也很簡單，但是一旦規模大了，它也是一頭需要馴服的野獸。

建議改為：與 Spark 類似，Hbase 的主要版本也提升到了 2.x，但其變化沒有 Hive 等面向終端用戶的工具那麼明顯。HBase （開箱即用）提供基於 Ruby 的 shell 和針對不同語言的 API，它很少作為單獨的工具使用——Apache Phoenix是個特別的例外，本文不會涉及。

項目主頁提供了2.0.5、2.1.5、2.2.0版本的發佈說明，項目的JIRA中也有提供。

這樣說可能會讓一些人感覺不愉快——Hbase 是一個遵循 UNIX 思想的項目——做一件事並做對它——相對很多其它項目來說，這些年它的改進並不明顯。看看相關的工具、庫和框架能讓你有更好的總體瞭解。

Google 雲的 BigTable和 Hbase 可以互操作，作為一個原生雲託管服務，它可以和現有的所有 HBase 項一起使用。

Hive

Hive 的兼容性通常和Hadoop 的版本綁定在一起——Hive 3.x 和 Hadoop 3.x 一起，Hive 2.x 和 Hadoop 2.x 一起，以此類推。

Hive 專注於3.x 版本的分支，它從很受侷限、運行也不快的 Map-Reduce 驅動的 SQL 層轉為低時延、內存內驅動的強大分析框架。

Hive 的 LLAP（低時延分析處理）技術，在 Hive 2.0 第一次引入，它所提供的功能正如其名一樣。它在 YARN 上運行一個守護程序來協調作業的運行，這樣小的運行就由守護程序來進行安排，要更多資源的作業就交由成熟的 YARN 作業來完成。這種方式可以進行更快的查詢，同時仍可以讓用戶選擇運行很多需要訪問大量數據的作業，從而接近大型 RDMBS 集群如 Postgres 所能提供的功能。

而且，它也完全支持ACID 事務，對於 Hive 數據來說，這是一個很好的新功能。 Hive 舊版本依賴於不可變數據，只能使用 INSERT OVERWRITE 或 CTAS 語句來進行數據更新。

ACID 遇到了自身的挑戰和限制，它讓 Hive 和傳統的 RDMBS 或 Google 的 BigQuery （提供有限的更新支持）越來越相似。

Sqoop

Sqoop 是個強大的工具，它允許從不同的 RDMB 種獲取數據到 Hadoop。看起來似乎這是個不重要的任務，這項操作通常由 Informatica 或 Pentaho ETL 來完成。

和 HBase 一樣，它主要對內部進行改進。可以參考剛剛和 HDP 3.1 一起發佈的1.4.7的發佈說明。

要特別說明的是，大部分雲服務商缺乏比較工具。Sqoop 和數據庫進行交互，不管通過增量集成或整個加載，或自定義 SQL 的方式，然後存儲數據在 HDFS 上（如果需要，也會存儲在 Hive）。這樣，從可操作源系統中獲取沒有經過分析或 ETL 加載的數據就變得直接和簡單。事實上，AWS EMR 支持使用 Sqoop 將數據加載到 S3。

這點也存在爭議，我很願意研究其他 FOSS 工具，和存儲組件（S3、GCS 等）一樣，這些工具能給大型託管的、類似 SQL 的雲服務提供類似的功能。

Spark

Apache Spark（現在和 Hadoop 結合的不是很緊密，以後會這樣）從版本 1.6x 到2.x，有個主版本的變更，即修改了 API 並引入了很多新的功能。

2.x 和後續的版本針對不同平臺提供了更全面的 SQL 支持，大幅提高了 SQL 在 DataFrames/DataSets 上的操作性能（2-10 倍），對底層文件格式（ORC、Parquet）有了更多的支持，2.1 版本提供對 Kafka 的本地支持，2.2 上流數據處理更先進可靠，支持 Kubernetes，更新了 History server，2.3 版本加入了新的數據源 API（如本地讀取 CSV 文件），2.4 版本支持機器學習 /”深度學習”中先進的執行模式、高級函數等。

Java、Scala、Python 和 R 中可以使用 Spark，從而為有 SME 的組織提供多種流行語言的支持。

而且，Spark 框架從 Hadoop 剝離後，可以用在AWS EMR、Google Cloud Dataproc和 Azure HDInsights上，開發者可以直接把現有的 Spark 應用程序直接遷移到完全託管服務的雲上。

這樣可以使公司不僅可以重用現有的 IP，還可以對單個的外部服務提供商提供相對的獨立性。儘管我在以前發表的文章中曾高度評價過 GCP，這種獨立性可以成為一個戰略優勢。

TEZ

Apache TEZ 允許 Hive 和 PIG 運行 DAGs，而不能運行 M/R 作業。雖然它是一個 Hadoop 專有的組件，仍值得我們深入瞭解一下。

TEZ 的變更有時是用戶會接觸到的，如0.9.0版本上的新 TEZ 界面，但大多數還是內部修改，以獲取比舊版本更好的性能和可擴展性。它最大的優勢在於提供針對 M/R 作業的附加性能和監控能力。

結論是什麼呢?

我們花了很長的篇幅來談論了 Hadoop 的發展和相關的工具。但這意味著什麼呢？

有件事很清楚——在數據中心的裸機上運行一個開源技術棧有它的缺點，也有其優點。你擁有自己的數據，自己的技術棧，有能力把代碼提交到這個生態系統，來為開源做貢獻。你也有能力完成所需的功能，而不必非依賴第三方。

這種相對於雲服務提供商的獨立性讓公司對他們的數據有自主權，這樣不用受帶寬限制和監管限制（即自有軟件，沒有“不合規”的問題）。

Hadoop 的新功能和穩定性的提升讓平臺和工具（還包括所有我們在本文中沒有涉及到的）使用越來越方便和強大。ML 領域的發展，尤其是 Spark（ML）和 YARN，為更多邏輯分析、更少的聚合和傳統的數據庫建模奠定了基礎。

雲驅動的數據處理和分析穩步上升，Hadoop 的關注有所下降，可能會讓人覺得這是一個“非黑即白”的狀態——要麼在雲上，要麼在本地。

我不贊同這種觀點——混合方法可以將這兩個領域中最好的東西帶給我們。我們可以維護一個本地 Hadoop 實例，將它提交到，比如說一個託管的機器學習服務，如 BigQuery 上的Google Cloud AutoML上， 可以攜帶部分不含個人驗證信息的數據。

我們也可以將現有的 Hadoop 負載遷移到雲，如 EMR 或 Dataproc，利用雲的可擴展性和成本優勢，來開發可在不同雲服務上進行移植的軟件。

我能看到 Cloudera/Hortonwork 在以後採用的方式和上面第二種方法大致相同——利用 FOSS 的優勢，使用公有云服務提供的大量專有技術和高效的解決方案。

在某些情況下，如果沒有成熟的、多年的遷移經驗，想把遺留系統遷移到雲上並不可行——比如有 20 年或 30 年（或更早）歷史的管理企業日常運作的數據庫系統。不過，結合用戶自定義軟件和開源軟件的優勢，根據企業實際情況進行裁剪，是很有價值的。

最後，要看實際情況——Hadoop 當然不會消亡，但是來自 Amazon、Google 和 Microsoft 的持續投資在未來可能會改變。

.點擊“瞭解更多” 獲取更多優質閱讀