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 | 資料總管和排程器 | 2006 | 2019-02-06 |
| Hbase | NoSQL 資料庫 | 2008 | 2019-06-11 |
| Hive | 資料倉庫和 SQL 抽象 | 2010 | 2019-05-14 |
| Sqoop | RDMBS 資料傳輸管道 | 2009 | 2019-01-18 |
| Spark | 資料處理架構和計算引擎 | 2014 | 2019-05-08 |
| Tez | 運作在 Hive 或 Pig 上的 DAG 計算架構 | 2019-03-29 |
可以看出，所有的最新釋出都是在最近 6 個月内（從本文時間算起）。
不過任何事物都不可能沒有缺點——如大部分開源軟體一樣，尤其是子產品化地運作在幾百個甚至成千上萬台機器上是一個很大的挑戰。配置、性能優化、工具選擇、維護、運維和開發都需要有資深專家的指導，來讓 Haoop 可以平穩運作，因為一個錯誤的配置都會嚴重降低整個系統的性能。同時，這種粒度控制的級别可以和工具的靈活度和适應性級别不比對。
新興的雲市場
然而，在過去的十幾年中，越來越多的公司從主要的雲服務，如 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 的相容性通常和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 是個強大的工具，它允許從不同的 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 的雲服務提供類似的功能。
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 的持續投資在未來可能會改變。
作者介紹：Christian Hollinger：寫過很多大資料、雲、分析方法和 UNIX 相關的文章，他是所有資料相關需求的進階顧問，對 Google Clound、Hadoop、Apache Storm、Heron、HBase、Kafka、Spark 等均有了解，對 Kerberos 知之甚少。
— THE END —
猜你喜歡：
◤半年文章精選系列◥
Flink從入門到放棄之源碼解析系列
- 《Flink元件和邏輯計劃》
- 《Flink執行計劃生成》
- 《JobManager中的基本元件(1)》
- 《JobManager中的基本元件(2)》
- 《JobManager中的基本元件(3)》
- 《TaskManager》
- 《算子》
- 《網絡》
- 《水印WaterMark》
- 《CheckPoint》
- 《任務排程及負載均衡》
- 《異常處理》
大資料成神之路-基礎篇
- 《HashSet》
- 《HashMap》
- 《LinkedList》
- 《ArrayList/Vector》
- 《ConcurrentSkipListMap》
- 《ConcurrentHashMap1.7》
- 《ConcurrentHashMap1.8 Part1》
- 《ConcurrentHashMap1.8 Part2》
- 《CopyOnWriteArrayList》
- 《CopyOnWriteArraySet》
- 《ConcurrentLinkedQueue》
- 《LinkedBlockingDeque》
- 《LinkedBlockingQueue》
- 《ArrayBlockingQueue》
- 《ConcurrentSkipListSet》
大資料成神之路-進階篇
- 《JVM&NIO基礎入門》
- 《分布式理論基礎和原理》
- 《分布式中的常見問題解決方案(分布式鎖/事務/ID)》
- 《Zookeeper》
- 《RPC》
- 《Netty入門篇》
- 《Netty源碼篇》
- 《Linux基礎》
Flink入門系列
- 《Flink入門》
- 《Flink DataSet&DataSteam API》
- 《Flink叢集部署》
- 《Flink重新開機政策》
- 《Flink分布式緩存》
- 《Flink廣播變量》
- 《Flink中的Time》
- 《Flink中的視窗》
- 《時間戳和水印》
- 《Broadcast廣播變量》
- 《Flink-Kafka-Connector》
- 《Flink之Table-&-SQL》
- 《Flink實戰項目之實時熱銷排行》
- 《Flink-Redis-Sink》
- 《Flink消費Kafka寫入Mysql》
Flink進階進階
- 《FaultTolerance》
- 《流表對偶(duality)性》
- 《持續查詢(ContinuousQueries)》
- 《DataStream-Connectors之Kafka》
- 《SQL概覽》
- 《JOIN 算子》
- 《TableAPI》
- 《JOIN-LATERAL》
- 《JOIN-LATERAL-Time Interval(Time-windowed)》
- 《Temporal-Table-JOIN》
- 《State》
- 《FlinkSQL中的回退更新-Retraction》
- 《Apache Flink結合Apache Kafka實作端到端的一緻性語義》
- 《Flink1.8.0釋出！新功能搶先看》
- 《Flink1.8.0重大更新-Flink中State的自動清除詳解》
- 《Flink在滴滴出行的應用與實踐》
- 《批流統一計算引擎的動力源泉—Flink Shuffle機制的重構與優化》
- 《HBase分享 | Flink+HBase場景化解決方案》
- 《騰訊基于Flink的實時流計算平台演進之路》
- 《Flink進階-Flink CEP(複雜事件處理)》
- 《Flink基于EventTime和WaterMark處理亂序事件和晚到的資料》
- 《Flink 最鋒利的武器：Flink SQL 入門和實戰》
- 《Flink Back Pressure》
- 《使用Flink讀取Kafka中的消息》
- 《Flink on YARN部署快速入門指南》
- 《Apache Flink狀态管理和容錯機制介紹》
Hadoop生态圈系列
- 《Hadoop極簡入門》
- 《MapReduce程式設計模型和計算架構架構原理》
- 《分布式檔案系統-HDFS》
- 《YARN》
- 《Hadoop機架感覺》
- 《HDFS的一個重要知識點-HDFS的資料流》
- 《Hadoop分布式緩存(DistributedCache)》
- 《如何從根源上解決 HDFS 小檔案問題》（https://dwz.cn/FqDPpRUc）
- 《Hadoop解決小檔案存儲思路》（https://dwz.cn/2oCdmCkw）
- 《Hadoop所支援的幾種壓縮格式》
- 《MapReduce Join》
- 《YARN Capacity Scheduler（容量排程器）》
- 《hadoop上搭建hive》
- 《基于Hadoop的資料倉庫Hive基礎知識》
- 《Hive使用必知必會系列》
- 《一個小知識點-Hive行轉列實作Pivot》
- 《面試必備技能-HiveSQL優化》
- 《HBase和Hive的差別和各自适用的場景》
- 《一篇文章入門Hbase》
- 《敲黑闆：HBase的RowKey設計》
- 《HBase讀寫優化》
- 《HBase在滴滴出行的應用場景和最佳實踐》
- 《Phoenix=HBase+SQL,讓HBase插上了翅膀》
- 《一個知識點将你拒之門外之Hbase的二級索引》（https://dwz.cn/umfBOZ5l）
- 《Phoenix重磅 | Phoenix核心功能原理及應用場景介紹》
- 《DB、DW、DM、ODS、OLAP、OLTP和BI的概念了解》
- 《Hive/HiveSQL常用優化方法全面總結》
實時計算系列(spark、kafka等)
- 《Spark Streaming消費Kafka資料的兩種方案》
- 《Apache Kafka簡單入門》
- 《你不得不知道的知識-零拷貝》
- 《Kafka在位元組跳動的實踐和災備方案》
- 《萬字長文幹貨 | Kafka 事務性之幂等性實作》
- 《Kafka最佳實踐》
- 《Kafka Exactly-Once 之事務性實作》
- 《Kafka連接配接器深度解讀之錯誤處理和死信隊列》
- 《Spark之資料傾斜調優》
- 《Structured Streaming 實作思路與實作概述》
- 《Spark記憶體調優》
- 《廣告點選數實時統計：Spark StructuredStreaming + Redis Streams》
- 《Spark Shuffle在網易的優化》
- 《SparkSQL極簡入門》
- 《下一代分布式消息隊列Apache Pulsar》
- 《Pulsar與Kafka消費模型對比》
- 《Spark SQL重點知識總結》
- 《Structured Streaming 之狀态存儲解析》
- 《周期性清除Spark Streaming流狀态的方法》
- 《Spark Structured Streaming特性介紹》
- 《Spark Streaming 反壓（Back Pressure）機制介紹》
- 《Spark 從 Kafka 讀數設定子并發度問題》
規範和系統設計
- 《阿裡雲10 PB+／天的日志系統設計和實作》
- 《阿裡雲Redis開發規範》
- 《Java中多個ifelse語句的替代設計》
- 《面試系列：十個海量資料處理方法大總結》
雜談
- 《作為面試官的一點點感悟，談談技術人的成長之路》
- 《成年人的世界沒有容易二字》
- 《我最近在關注的事》
- 《真香》
- 《簡單說說學習這件事》
- 《20多歲做什麼，将來才不會後悔》
- 《2019-05-12最近的總結》
- 《我軍新聞聯播氣勢+9999》