Hadoop，凉了？那还需要它吗？

戳蓝字“大数据手稿笔记”关注我们哦！

整合自田晓旭，infoQ等信息，有删改

近日，Hadoop 领域发生几件不太美好的事情，先是 MapR 宣布如果无法获得新的投资，就必须要裁员百余人，并关闭硅谷总部，再是 Cloudera 股价暴跌 43%，估值缩水。

上上上周，外媒爆料曾经估值 10 亿美元的 MapR 向加州就业发展局提交文件，称如果找不到新的投资人，公司将裁员 122 人。

上上周，美股开盘之后，Cloudera 股价暴跌 43%，曾经 41 亿美元的估值缩水为 14 亿美元；眼看 Hadoop 三大商业公司起高楼，为何忽然之间楼斜了呢？

1

Hadoop的“辉煌”历史

项目起源

Hadoop由 Apache Software Foundation 公司于 2005 年秋天作为Lucene的子项目Nutch的一部分正式引入。它受到最先由 Google Lab 开发的 Map/Reduce 和 Google File System(GFS) 的启发。

2006 年 3 月份，Map/Reduce 和 Nutch Distributed File System (NDFS) 分别被纳入称为 Hadoop 的项目中。

Hadoop 是最受欢迎的在 Internet 上对搜索关键字进行内容分类的工具，但它也可以解决许多要求极大伸缩性的问题。例如，如果您要 grep 一个 10TB 的巨型文件，会出现什么情况？在传统的系统上，这将需要很长的时间。但是 Hadoop 在设计时就考虑到这些问题，采用并行执行机制，因此能大大提高效率。

发展历程

Hadoop原本来自于谷歌一款名为MapReduce的编程模型包。谷歌的MapReduce框架可以把一个应用程序分解为许多并行计算指令，跨大量的计算节点运行非常巨大的数据集。使用该框架的一个典型例子就是在网络数据上运行的搜索算法。Hadoop[3] 最初只与网页索引有关，迅速发展成为分析大数据的领先平台。

目前有很多公司开始提供基于Hadoop的商业软件、支持、服务以及培训。Cloudera是一家美国的企业软件公司，该公司在2008年开始提供基于Hadoop的软件和服务。GoGrid是一家云计算基础设施公司，在2012年，该公司与Cloudera合作加速了企业采纳基于Hadoop应用的步伐。Dataguise公司是一家数据安全公司，同样在2012年该公司推出了一款针对Hadoop的数据保护和风险评估的软件。

名字起源

Hadoop这个名字不是一个缩写，而是一个虚构的名字。该项目的创建者，Doug Cutting解释Hadoop的得名 ：“这个名字是我孩子给一个棕黄色的大象玩具命名的。我的命名标准就是简短，容易发音和拼写，没有太多的意义，并且不会被用于别处。小孩子恰恰是这方面的高手。”

Hadoop的发音是 [hædu:p]。

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 可以平稳运行，因为一个错误的配置都会严重降低整个系统的性能。同时，这种粒度控制的级别可以和工具的灵活度和适应性级别不匹配。

2

抱团取暖，裁员闭店，Hadoop 三大发行商遭“团灭”

在 Hadoop 的发展史上，有三家公司不得不提，分别是 Cloudera、Hortonworks 和 MapR。

这三家公司同属于 Hadoop 发行版提供商。所谓的“发行版”，其实是开源文化特有的，虽然在很多外行眼中，发行版只是将开源代码打包，然后在添加一些自己独创的边角料。但其实发行版真正比拼的是对海量生态系统组件的价值筛选、兼容和集成保证以及支撑服务。

同样是提供发行版，这三家公司的商业模式可以说是完全不同。Cloudera 主要是发布 Hadoop 商业版和商用工具，其核心组件 CDH 开源免费，与 Apache 社区同步；而数据治理和系统管理组件闭源，用户需要获得商业许可，除了之外，商业组件也会提供企业生产环境中必需的运维功能。

Hortonworks 的商业模式是 100% 完全开源的策略，所有产品开源，用户可免费使用。真正用来盈利的是技术服务支持。

MapR 的商业模式遵循了传统软件厂商的模式，采用私有化实现，用户通过购买软件许可来使用。

虽然三家公司的商业模式不尽相同，但是都曾从 Hadoop 中获得了红利，Cloudera 的估值在顶峰时高达 41 亿美元，而 Hortonworks 和 MapR 的估值也曾超过 10 亿美元。

不过，最近剧情急转直下，2018 年 10 月，Cloudera 和 Hortonworks 宣布合并，Cloudera 的股东将拥有新公司 60% 的股权，Hortonworks 的股东持有 40% 的股权。合并时，双方对于未来的盈利能力信心十足，“到 2020 年预计每年收入有望超过 10 亿美元。”

但是，事情发展并不如预期，合并半年多后，2019 年 6 月 6 日美股开盘，Cloudera 股价暴跌 43%，曾经 41 亿美元的估值缩水为 14 亿美元。

相比于抱团取暖的 Cloudera 和 Hortonworks，MapR 的处境更为艰难了，甚至走到了“闭店裁员”的窘境，“如果再获得新的资金注入，MapR 可能会裁员 122 人，并关闭位于 Santa Clara 的总部。”据外媒报道，MapR 裁员将于 6 月 14 日生效，但是就在前几日，有消息称 MapR 将寻找新资金的最后期限延长到了 7 月 9 日。

眼看 Hadoop 三大商业公司起高楼，为何忽然之间楼斜了呢？

众说纷纭，有人说是因为数据库的发展，有人说是因为云计算的崛起，还有人说是自身模式有问题？…为了弄清楚原因，我们采访了多位各领域的技术专家。

3

公有云会给 Hadoop 致命一击吗？

在很多分析文章中，都把 Hadoop 近日来的“颓势”归因为公有云的发展，Hadoop 的出现代表了当时革命性的技术，而云计算代表了数据处理的新方法，解决了与 Hadoop 相同的问题。Hadoop 主要是应用了比之前廉价的存储，但是云计算的出现，让存储变得更加廉价，且用户体验也获得了成倍提升。

云计算厂商打造了完全集成的一站式云原生服务，并且在云上提供了很多组件来替代原有的 Hadoop 组件，例如 AWS 的 S3 替代了 HDFS，K8S 替代了 Yarn。而 Hadoop 因其庞然的架构，本身并不适合以弹性灵活快速扩展的公用云环境。

公有云的出现给了 Hadoop 一定的压力，但会成为 Hadoop 的致命一击吗？

综合多位技术专家的意见，答案是否定的。

“云计算厂商提供的托管服务在部署和运维上给予了用户太多便利，且从计算资源角度来看，云厂商大大降低了用户的成本，尤其是竞价实例，在给终端用户节省成本的同时，也做到了资源的合理利用和自身利益的最大化。”

“支撑大部分实体经济的企业，例如制造业、金融业、政府等强监管行业，还远远没有达到把企业全量数据存放到公有云的阶段，甚至会出于数据安全的考虑，永远不放在公有云上。”也就是说，公有云也不是银弹，即使发展得更好，也不可能完全侵占 Hadoop 的应用场景。

云会威胁 Cloudera 吗？Cloudera 创始人 Mike Olson 是这样回答的：“如果五年后我们只是一个本地部署供应商，我们将成为一个注脚。我们的大好机会是帮助客户迁移到云，并提供云和本地部署之间的可移植性。由于我们在早期所做的赌注，我们可以让用户在不编码到专有 API 的情况下进行迁移。我们与所有的超大规模云提供商都有良好的合作关系。当然，他们在某种程度上与我们竞争，但我的机会不是击败 Redshift 。Redshift 的目的是帮助那些希望训练机器学习模型的客户在所有云提供商中提供这种能力。而我们的目标是将客户想要的所有可移植性与他们需要的法规和遵从性功能集成并提供给他们。”

4

MongoDB 和 Elasticsearch 会是 Hadoop 的竞争对手吗？

在一篇外媒的分析文章中，提出了这样一个观点：在受欢迎指数、收益等方面，大数据其他开源供应商（如 Elastic 和 MongoDB 公司）和 Hadoop 三大商业公司呈现出了此消彼长的态势，之前没有人认为 MongoDB 和 Elasticsearch 这样的技术以及它们背后的公司能够挑战 Hadoop 及相关产品，但是现在它们做到了。

事实真如这篇文章分析的那样吗？MongoDB、Elasticsearch 和 Hadoop 真的已经成为了竞争关系吗？

MongoDB 和 Elasticsearch 的技术专家大家的观点出奇的一致，那就是从目前来看，MongoDB 和 Elasticsearch 与 Hadoop 并不构成竞争关系，甚至连重合点都很少。

“MongoDB 和 Elasticsearch 与 Hadoop 在本质上是离线处理和在线处理两个完全不同的方向，”MongoDB 中文社区主席唐建法这样认为：“Hadoop 的底层存储是基于无索引的 HDFS ，核心应用场景是对海量结构化、非结构化数据的永久存储和离线分析，例如客户肖像、流失度分析、日志分析、商业智能等。而 MongoDB 和 Elasticsearch 的核心场景是实时交互，通常用于人机交互场景，例如电商移动应用，其特征是响应时间一般是毫秒级到秒级。”

当然，它们之间也不是完全没有竞争的地方，但 MongoDB 、Elasticsearch 真正竞争的是 Hadoop 内的生态组件，例如 HBase、Hive、Impala 等。以 Elasticsearch 为例，它满足了比较基础的即席查询需求、在线业务检索需求，甚至是轻量的 BI 需求，这些在功能上与 Hadoop 会有所重合。

除了竞争关系，这篇外媒评论文中还提到了一个重要观点，那就是 Hadoop 使用繁琐，用户体验糟糕，MongoDB 和 Elasticsearch 使用方便，而这也导致了 Hadoop 的“衰败”。

“Hadoop 使用繁琐”的观点得到了众多技术专家的赞同。Hadoop 的本质其实就是 HDFS 存储 +MapReduce 计算框架，但是 Hadoop 发行商为了提高自己的商业竞争力，在 Hadoop 技术上增加了各种组件。Elastic 社区首席架构师吴斌称，“假设你发现了一个符合需求的组件，那么在部署使用它之前，可能还需要部署它的存储和配置管理组件，这时就不得不把精力放在诸如 HDFS、Zookeeper 等组件之上。在真正使用服务之前，用户就在 HDFS 和 Zookeeper 上付出了不少代价，这个过程往往会让入门级选手心灰意冷，进而追求门槛更低的服务，例如 Elasticsearch 或者 MongoDB。”

即使成功迈过了入门的门槛，很多企业也会因为复杂性难以充分利用 Hadoop 。MongoDB 中文社区主席唐建法曾在两间银行看到过这样的情况，他们一家使用 MapR，一家使用 Cloudera，在系统上线 2 年后的今天，只完成了一个最简单的业务场景，行内一部分业务数据的归档功能。他们提到了一个共同的问题就是，如果说写进数据湖（Hadoop) 还算可以做得到， 把数据从里面读出来使用是更加困难的！

5

Hadoop 三大发行商的衰落是否代表了 Hadoop 的衰败？

“Hadoop 三大发行商的衰落是否代表了 Hadoop 的衰败？”这是很多人关心的问题，也是技术人在热情讨论的问题。首先，需要明确的是 Hadoop 三大发行商无法全权代表 Hadoop，其次，与前几年相比，Hadoop 的热度确实在下降。

与其说 Hadoop 衰败，倒不如说是 Hadoop 走下了神坛。早些年前，Hadoop 是与大数据划等号的存在，但是现在，大家对于大数据产品的需求更丰富了，眼光也更挑剔了。最早大家只要求能够处理海量数据，后来追求高效实时，而现在大家还要求经济便宜，功能丰富。

Hadoop 生态的衰败并非是指技术，而是市场炒作的一种理性回归。因为低成本、海量扩展能力，以及对半结构化、非结构化数据的支持，Hadoop 在大数据分析、历史数据归档方面是有独特地位的。如果 Hadoop 能够专注于擅长的离线场景，并提升用户使用体验，那么基于 Hadoop 的技术方案在未来还是很有前景的。

6

Hadoop 真正面临的竞争态势是什么？

既然 Hadoop 真正的竞争对手不是 MongoDB、Elasticsearch 等其它开源产品，也不是公有云，那么真正的对手是谁？

首先，我们不能简单的把 Hadoop 理解成一款产品，它是一种生态。所以，Hadoop 真正面临的其实是生态之争，而不是某款产品之争。

与 Elasticsearch 生态相比， Hadoop 的产品功能相对比较分散。Elastic Stack 的整合程度则非常高， 且 Elasticsearch 的分析速度更快更实时，从数据接入到前端分析展现都有完整的产品，打通了整条数据分析的链路，开箱即用，用户体验要好的多。”

而云计算厂商通常会选择更多的生态伙伴来一起合作，例如 Google 宣布将 MongoDB 纳入 Market Place 产品目录，AWS 与 MongoDB 签署全球金牌合作伙伴，腾讯云和 Elastic 达成合作。

与单个产品或环节的竞争不同，生态之间的竞争更加复杂多样，既包括了产业链上的生态，也包括了跨行业的生态，所以竞争结果不只是简单的争长竞短、你死我活，也有可能是互相融合、共同繁荣。Hadoop 生态与其它大数据生态各自有自己的使用场景和成熟的生态链，它们之间不只有竞争，更有互补的地方，从这个角度来看，Hadoop 未来的机会不是打败对手，而是做好自己。

虽然大数据依然如日中天，但该领域曾经的领头羊 Cloudera、Hortonworks 和 MapR 三家公司最近却步履蹒跚，多少掩盖了其几分风光。Cloudera 和 Hortonworks 合并，而 MapR 开始裁员。与此同时，大数据领域的其他开源供应商（如 Elastic 和 MongoDB 公司）却势头正猛。这到底是发生了什么事？虽然这背后可能有种种原因，但其中一个事实是：老牌 Hadoop 供应商把大赌注押在了错误的目标用户上，瞄准的是所谓数据中心的专职架构师。然而，市场已经转向了在云计算环境中寻求自由的个体开发人员。Hadoop 气数已尽？

7

Hadoop 还是数据处理的可选方案吗

在过去的十几年中，越来越多的公司从主要的云服务，如 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 的持续投资在未来可能会改变。