Hadoop還是數據處理的可選方案嗎？

目前云驅動數據處理和分析呈上升趨勢，我們在本文中來分析下，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 https://www.b5b6.com/shujuku/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 和https://www.b5b6.com/shujuku/進行交互，不管通過增量集成或整個加載，或自定義 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，為更多邏輯分析、更少的聚合和傳統的https://www.b5b6.com/shujuku/建模奠定了基礎。

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

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

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

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

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

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