目前云驱动数据处理和分析呈上升趋势，我们在本文中来分析下，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 计算框架	2014	2019-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的持续投资在未来可能会改变。
.
作者介绍：

Christian Hollinger：写过很多大数据、云、分析方法和UNIX相关的文章，他是所有数据相关需求的高级顾问，对Google Clound、Hadoop、Apache Storm、Heron、HBase、Kafka、Spark等均有了解，对Kerberos知之甚少。

原文链接：
https://chollinger.com/blog/a-look-at-apache-hadoop-in-2019/

创作场景

2019 年，Hadoop 还是数据处理的可选方案吗？