目前雲驅動資料處理和分析呈上升趨勢，我們在本文中來分析下，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 的持續投資在未來可能會改變。

2019年，對於大的網際網路公司來說，已經漸漸開始不用Hadoop的MapReduce計算框架，不過對於一些小公司，還是會使用Hadoop作為資料處理的一種方案。

Hadoop自2006年開源以來，最初來源谷歌的兩篇文章，GFS和MapReduce。到現在還有很多網際網路公司進行使用。不過由於大的網際網路公司強大的自己研發實力，已經慢慢開始棄用Hadoop，轉而開始透過自研來解決公司的大資料計算場景。

Hadoop整體包含三個模組：MapReduce、HDFS、Yarn。MapReduce是Hadoop的分散式計算框架，在對大資料檔案進行資料處理的，會先對檔案進行分片，每一個都是一個人Map任務，所以一個大檔案，會有多個Map任務同時處理，每個Map任務只處理部分資料：

雖然Hadoop MapReduce計算框架分散式並行的處理資料，但是有一個問題就是，在進行資料Shuffle的時候，資料會臨時儲存在磁碟上，由於磁碟IO方面比較慢，有時候一個MapReduce任務可能執行好幾個小時。Shuffle的含義就是資料從Map任務段到Reduce任務段的過程。

小型網際網路公司有兩個特點，一個是公司業務場景沒有那麼複雜，另一個是資料體量不大。所以在技術選型時，不過要求特別複雜，只要能夠滿足業務場景即可。所以很多小公司在大資料技術選型時，都會使用Hadoop來作為大資料計算框架。

使用Hadoop作為資料處理方案，還有一個好處就是，便於統一管理和運維，小公司人員比較少，一般都是一個人負責叢集的搭建、運維、維護等。Hadoop包含了計算、儲存、資源管理，對於小公司來說，也已經夠使用了。

Hadoop MapReduce計算框架在大資料場景下，由於計算時間比較長，目前在網際網路公司慢慢被取代或者啟用了，很多公司開始使用別的計算框架，比如Spark。不過對於小型網際網路公司來說，一個是為了降低成本，二個是為了統一的維護和管理，在加上資料量比較小，所以還是會繼續使用Hadoop作為公司的大資料處理方案。