Hadoop十年解读与发展预测

编者按：Hadoop于2006年1月28日诞生，至今已有10年，它改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，形成了自己的极其火爆的技术生态圈，并受到非常广泛的应用。在2016年Hadoop十岁生日之际，InfoQ策划了一个Hadoop热点系列文章，为大家梳理Hadoop这十年的变化，技术圈的生态状况，回顾以前，激励以后。本文是Cloudera资深工程师讲解Hadoop，让您一篇文章就能了解Hadoop的过去和未来。

“昔我十年前，与君始相识。”

——白居易，《酬元九对新栽竹有怀见寄》

一瞬间Hadoop也到了要初中择校的年龄了。

十年前还没有Hadoop，几年前国内IT圈里还不知道什么是Hadoop，而现在几乎所有大型企业的IT系统中有已经有了Hadoop的集群在运行了各式各样的任务。

2006年项目成立的一开始，“Hadoop”这个单词只代表了两个组件——HDFS和MapReduce。到现在的10个年头，这个单词代表的是“核心”（即Core Hadoop项目）以及与之相关的一个不断成长的生态系统。这个和Linux非常类似，都是由一个核心和一个生态系统组成。

现在Hadoop俨然已经成为企业数据平台的“新常态”。我们很荣幸能够见证Hadoop十年从无到有，再到称王。在我们感动于技术的日新月异时，希望能通过本文能为Hadoop的昨天、今天和明天做出一点自己的解读，算是为Hadoop庆祝10岁生日献上的礼物。

Hadoop编年史

• 2002年10月，Doug Cutting和Mike Cafarella创建了开源网页爬虫项目Nutch。
• 2003年10月，Google发表Google File System论文。
• 2004年7月，Doug Cutting和Mike Cafarella在Nutch中实现了类似GFS的功能，即后来HDFS的前身。
• 2004年10月，Google发表了MapReduce论文。
• 2005年2月，Mike Cafarella在Nutch中实现了MapReduce的最初版本。
• 2005年12月，开源搜索项目Nutch移植到新框架，使用MapReduce和NDFS(Nutch Distributed File System )来运行，在20个节点稳定运行。
• 2006年1月，Doug Cutting加入雅虎，Yahoo!提供一个专门的团队和资源将Hadoop发展成一个可在网络上运行的系统。
• 2006年2月，Apache Hadoop项目正式启动以支持MapReduce和HDFS的独立发展。
• 2006年2月，Yahoo!的网格计算团队采用Hadoop。
• 2006年3月，Yahoo!建设了第一个Hadoop集群用于开发。
• 2006年4月，第一个Apache Hadoop发布。
• 2006年4月，在188个节点上（每个节点10GB）运行排序测试集需要47.9个小时。
• 2006年5月，Yahoo!建立了一个300个节点的Hadoop研究集群。
• 2006年5月，在500个节点上运行排序测试集需要42个小时（硬件配置比4月的更好）。
• 2006年11月，研究集群增加到600个节点。
• 2006年11月，Google发表了Bigtable论文，这最终激发了HBase的创建。
• 2006年12月，排序测试集在20个节点上运行1.8个小时，100个节点上运行3.3小时，500个节点上运行5.2小时，900个节点上运行7.8个小时。
• 2007年1月，研究集群增加到900个节点。
• 2007年4月，研究集群增加到两个1000个节点的集群。
• 2007年10月，第一个Hadoop用户组会议召开，社区贡献开始急剧上升。
• 2007年，百度开始使用Hadoop做离线处理。
• 2007年，中国移动开始在“大云”研究中使用Hadoop技术。
• 2008年，淘宝开始投入研究基于Hadoop的系统——云梯，并将其用于处理电子商务相关数据。
• 2008年1月，Hadoop成为Apache顶级项目。
• 2008年2月，Yahoo!运行了世界上最大的Hadoop应用，宣布其搜索引擎产品部署在一个拥有1万个内核的Hadoop集群上。
• 2008年4月，在900个节点上运行1TB排序测试集仅需209秒，成为世界最快。
• 2008年6月，Hadoop的第一个SQL框架——Hive成为了Hadoop的子项目。
• 2008年7月，Hadoop打破1TB数据排序基准测试记录。Yahoo!的一个Hadoop集群用209秒完成1TB数据的排序 ，比上一年的纪录保持者保持的297秒快了将近90秒。
• 2008年8月，第一个Hadoop商业化公司Cloudera成立。
• 2008年10月，研究集群每天装载10TB的数据。
• 2008年11月，Apache Pig的最初版本发布。
• 2009年3月，17个集群总共24000台机器。
• 2009 年3月，Cloudera推出世界上首个Hadoop发行版——CDH（Cloudera‘s Distribution including Apache Hadoop）平台，完全由开放源码软件组成。
• 2009年4月，赢得每分钟排序，59秒内排序500GB（在1400个节点上）和173分钟内排序100TB数据（在3400个节点上）。
• 2009年5月，Yahoo的团队使用Hadoop对1 TB的数据进行排序只花了62秒时间。
• 2009年6月，Cloudera的工程师Tom White编写的《Hadoop权威指南》初版出版，后被誉为Hadoop圣经。
• 2009年7月 ，Hadoop Core项目更名为Hadoop Common;
• 2009年7月 ，MapReduce 和 Hadoop Distributed File System (HDFS) 成为Hadoop项目的独立子项目。
• 2009年7月 ，Avro 和 Chukwa 成为Hadoop新的子项目。
• 2009年8月，Hadoop创始人Doug Cutting加入Cloudera担任首席架构师。
• 2009年10月，首届Hadoop World大会在纽约召开。
• 2010年5月 ，Avro脱离Hadoop项目，成为Apache顶级项目。
• 2010年5月 ，HBase脱离Hadoop项目，成为Apache顶级项目。
• 2010年5月，IBM提供了基于Hadoop 的大数据分析软件——InfoSphere BigInsights，包括基础版和企业版。
• 2010年9月，Hive( Facebook) 脱离Hadoop，成为Apache顶级项目。
• 2010年9月，Pig脱离Hadoop，成为Apache顶级项目。
• 2010年-2011年，扩大的Hadoop社区忙于建立大量的新组件（Crunch，Sqoop，Flume，Oozie等）来扩展Hadoop的使用场景和可用性。
• 2011年1月，ZooKeeper 脱离Hadoop，成为Apache顶级项目。
• 2011年3月，Apache Hadoop获得Media Guardian Innovation Awards 。
• 2011年3月， Platform Computing 宣布在它的Symphony软件中支持Hadoop MapReduce API。
• 2011年5月，Mapr Technologies公司推出分布式文件系统和MapReduce引擎——MapR Distribution for Apache Hadoop。
• 2011年5月，HCatalog 1.0发布。该项目由Hortonworks 在2010年3月份提出，HCatalog主要用于解决数据存储、元数据的问题，主要解决HDFS的瓶颈，它提供了一个地方来存储数据的状态信息，这使得 数据清理和归档工具可以很容易的进行处理。
• 2011年4月，SGI（Silicon Graphics International）基于SGI Rackable和CloudRack服务器产品线提供Hadoop优化的解决方案。
• 2011年5月，EMC为客户推出一种新的基于开源Hadoop解决方案的数据中心设备——GreenPlum HD，以助其满足客户日益增长的数据分析需求并加快利用开源数据分析软件。Greenplum是EMC在2010年7月收购的一家开源数据仓库公司。
• 2011年5月，在收购了Engenio之后， NetApp推出与Hadoop应用结合的产品E5400存储系统。
• 2011年6月，Calxeda公司发起了“开拓者行动”，一个由10家软件公司组成的团队将为基于Calxeda即将推出的ARM系统上芯片设计的服务器提供支持。并为Hadoop提供低功耗服务器技术。
• 2011年6月，数据集成供应商Informatica发布了其旗舰产品，产品设计初衷是处理当今事务和社会媒体所产生的海量数据，同时支持Hadoop。
• 2011年7月，Yahoo!和硅谷风险投资公司 Benchmark Capital创建了Hortonworks 公司，旨在让Hadoop更加可靠，并让企业用户更容易安装、管理和使用Hadoop。
• 2011年8月，Cloudera公布了一项有益于合作伙伴生态系统的计划——创建一个生态系统，以便硬件供应商、软件供应商以及系统集成商可以一起探索如何使用Hadoop更好的洞察数据。
• 2011年8月，Dell与Cloudera联合推出Hadoop解决方案——Cloudera Enterprise。Cloudera Enterprise基于Dell PowerEdge C2100机架服务器以及Dell PowerConnect 6248以太网交换机。
• 2012年3月，企业必须的重要功能HDFS NameNode HA被加入Hadoop主版本。
• 2012年8月，另外一个重要的企业适用功能YARN成为Hadoop子项目。
• 2012年10月，第一个Hadoop原生MPP查询引擎Impala加入到了Hadoop生态圈。
• 2014年2月，Spark逐渐代替MapReduce成为Hadoop的缺省执行引擎，并成为Apache基金会顶级项目。
• 2015年2月，Hortonworks和Pivotal抱团提出“Open Data Platform”的倡议，受到传统企业如Microsoft、IBM等企业支持，但其它两大Hadoop厂商Cloudera和MapR拒绝参与。
• 2015年10月，Cloudera公布继HBase以后的第一个Hadoop原生存储替代方案——Kudu。
• 2015年12月，Cloudera发起的Impala和Kudu项目加入Apache孵化器。

技术篇

现在Hadoop在一月发布了2.7.2的稳定版， 已经从传统的Hadoop三驾马车HDFS，MapReduce和HBase社区发展为60多个相关组件组成的庞大生态，其中包含在各大发行版中的组件就有25个以上，包括数据存储、执行引擎、编程和数据访问框架等。

Hadoop在2.0将资源管理从MapReduce中独立出来变成通用框架后，就从1.0的三层结构演变为了现在的四层架构：

1. 底层——存储层，文件系统HDFS
2. 中间层——资源及数据管理层，YARN以及Sentry等
3. 上层——MapReduce、Impala、Spark等计算引擎
4. 顶层——基于MapReduce、Spark等计算引擎的高级封装及工具，如Hive、Pig、Mahout等等

我们欣慰地看到开源文化为Hadoop社区和生态带来的蓬蓬发展，但又确实存在一些碎片化和重复化现象。复杂的生态和过多的组件几乎让很多企业仍然等待一个像以前IBM一样的巨头厂商能提供标准化的解决方案。不过随着围绕Hadoop和Spark的生态圈日益稳固，核心会变得稳定得多。

存储层

HDFS已经成为了大数据磁盘存储的事实标准，用于海量日志类大文件的在线存储。经过这些年的发展，HDFS的架构和功能基本固化，像HA、异构存储、本地数据短路访问等重要特性已经实现，在路线图中除了Erasure Code已经没什么让人兴奋的feature。随着HDFS越来越稳定，社区的活跃度页越来越低，同时HDFS的使用场景也变得成熟和固定，而上层会有越来越多的文件格式封装：列式存储的文件格式，如Parquent，很好的解决了现有BI类数据分析场景；以后还会出现新的存储格式来适应更多的应用场景，如数组存储来服务机器学习类应用等。未来HDFS会继续扩展对于新兴存储介质和服务器架构的支持。随着数据量的增大，跨机房部署相信也终会在基线版本中实现。基于HDFS的存储机制，

将HBase作为存储层似乎有点牵强：其底层使用HDFS作为文件存储。不过在逻辑角度，还是倾向与将HBase定位为存储层或数据访问层，因为其提供了另外一种场景的数据存储和访问方案。2015年HBase 发布了1.0版本，这也代表着 HBase 走向了稳定。最新HBase新增特性包括：更加清晰的接口定义，多Region 副本以支持高可用读，Family粒度的Flush以及RPC读写队列分离等。未来HBase不会再添加大的新功能，而将会更多的在稳定性和性能方面进化，尤其是大内存支持、内存GC效率等。

Kudu是Cloudera在2015年10月才对外公布的新的分布式存储架构，与HDFS完全独立。其实现参考了2012年Google发表的Spanner论文。鉴于Spanner在Google 内部的巨大成功，Kudu被誉为下一代分析平台的重要组成，用于处理快速数据的查询和分析，填补HDFS和HBase之间的空白。其出现将进一步把Hadoop市场向传统数据仓库市场靠拢。

另一方面，分布式内存文件系统也在兴起，旨在消除不同任务或不同计算框架间的数据共享时的转化代价，并提供内存缓存以提高热数据处理性能。这一市场以前使用第三方Redis或Memcached，到后来能为分析提供更多原生支持的Tachyon或Ignite，而现在又迎来了新贵Arrow。

Apache Arrow项目为列式内存存储的处理和交互提供了规范。目前来自Apache Hadoop社区的开发者们致力于将它制定为大数据系统项目的事实性标准。

Arrow项目受到了Cloudera、Databricks等多个大数据巨头公司支持，很多committer同时也是其他明星大数据项目（如HBase、Spark、Kudu等）的核心开发人员。再考虑到Tachyon等似乎还没有找到太多实际接地气的应用场景，Arrow的高调出场可能会成为未来新的内存分析文件接口标准。

管控层

管控又分为数据管控和资源管控。

随着Hadoop集群规模的增大以及对外服务的扩展，如何有效可靠的共享利用资源是管控层需要解决的问题。脱胎于MapReduce1.0的YARN成为了Hadoop 2.0通用资源管理平台。由于占据了Hadoop的地利，业界对其在资源管理领域未来的前景非常看好。传统其他资源管理框架如Mesos，还有现在兴起的Docker等都会对YARN未来的发展产生影响。如何提高YARN性能、如何与容器技术深度融合，如何更好的适应短任务的调度，如何更完整的多租户支持、如何细粒度的资源管控等都是企业实际生产中迫在眉睫的需求，需要YARN解决。要让Hadoop走得更远，未来YARN需要做的工作还很多。

另一方面大数据的安全和隐私越来越多的受到关注。Hadoop依靠且仅依靠Kerberos来实现安全机制，但每一个组件都将进行自己的验证和授权策略。开源社区似乎从来不真正关心安全问题，如果不使用来自Hortonworks的Ranger或来自Cloudera 的Sentry这样的组件，那么大数据平台基本上谈不上安全可靠。

Cloudera刚推出的RecordService组件使得Sentry在安全竞赛中拔得先机。RecordService不仅提供了跨所有组件一致的安全颗粒度，而且提供了基于Record的底层抽象（有点像Spring，代替了原来Kite SDK的作用），让上层的应用和下层存储解耦合的同时、提供了跨组件的可复用数据模型。

计算引擎层

Hadoop生态和其他生态最大的不同之一就是“单一平台多种应用”的理念了。传的数据库底层只有一个引擎，只处理关系型应用，所以是“单一平台单一应用”；而NoSQL市场有上百个NoSQL软件，每一个都针对不同的应用场景且完全独立，因此是“多平台多应用”的模式。而Hadoop在底层共用一份HDFS存储，上层有很多个组件分别服务多种应用场景，如：

• 确定性数据分析：主要是简单的数据统计任务，例如OLAP，关注快速响应，实现组件有Impala等；
• 探索性数据分析：主要是信息关联性发现任务，例如搜索，关注非结构化全量信息收集，实现组件有Search等；
• 预测性数据分析：主要是机器学习类任务，例如逻辑回归等，关注计算模型的先进性和计算能力，实现组件有Spark、MapReduce等；
• 数据处理及转化：主要是ETL类任务，例如数据管道等，关注IO吞吐率和可靠性，实现组件有MapReduce等
• …

其中，最耀眼的就是Spark了。IBM宣布培养100万名Spark开发人员，Cloudera在One Platform倡议中宣布支持Spark为Hadoop的缺省通用任务执行引擎，加上Hortonworks全力支持Spark，我们相信Spark将会是未来大数据分析的核心。

虽然Spark很快，但现在在生产环境中仍然不尽人意，无论扩展性、稳定性、管理性等方面都需要进一步增强。同时，Spark在流处理领域能力有限，如果要实现亚秒级或大容量的数据获取或处理需要其他流处理产品。Cloudera宣布旨在让Spark流数据技术适用于80%的使用场合，就考虑到了这一缺陷。我们确实看到实时分析（而非简单数据过滤或分发）场景中，很多以前使用S4或Storm等流式处理引擎的实现已经逐渐Kafka+Spark Streaming代替。

Spark的流行将逐渐让MapReduce、Tez走进博物馆。

服务层

服务层是包装底层引擎的编程API细节，对业务人员提供更高抽象的访问模型，如Pig、Hive等。

而其中最炙手可热的就是OLAP的SQL市场了。现在，Spark有70%的访问量来自于SparkSQL！SQL on Hadoop到底哪家强？Hive、Facebook的Pheonix、Presto、SparkSQL、Cloudera推的Impala、MapR推的Drill、IBM的BigSQL、还是Pivital开源的HAWQ？

这也许是碎片化最严重的地方了，从技术上讲几乎每个组件都有特定的应用场景，从生态上讲各个厂家都有自己的宠爱，因此Hadoop上SQL引擎已经不仅仅是技术上的博弈（也因此考虑到本篇中立性，此处不做评论）。可以遇见的是，未来所有的SQL工具都将被整合，有些产品已经在竞争钟逐渐落伍，我们期待市场的选择。

周边的工具更是百花齐放，最重要的莫过于可视化、任务管理和数据管理了。

有很多开源工具都支持基于Hadoop 的查询程序编写以及即时的图形化表示，如HUE、Zeppelin等。用户可以编写一些SQL或Spark代码以及描述代码的一些标记，并指定可视化的模版，执行后保存起来，就可供其他人复用，这钟模式也被叫做“敏捷BI”。这个领域的商业产品更是竞争激烈，如Tableau、Qlik等。

调度类工具的鼻祖Oozie能实现几个MapReduce任务串连运行的场景，后来的Nifi及Kettle等其他工具则提供了更加强大的调度实现，值得一试。

毫无疑问，相对与传统的数据库生态，Hadoop的数据治理相对简单。Atlas是Hortonworks新的数据治理工具，虽然还谈不上完全成熟，不过正取得进展。Cloudera的Navigator是Cloudera商业版本的核心，汇聚了生命周期管理、数据溯源、安全、审计、SQL迁移工具等一系列功能。Cloudera收购Explain.io以后将其产品整合为Navigator Optimizator组件，能帮助用户把传统的SQL应用迁移到Hadoop平台并提供优化建议，可以节省数人月的工作量。

算法及机器学习

实现基于机器学习的自动的智能化数据价值挖掘是大数据和Hadoop最诱人的愿景了，也是很多企业对大数据平台的最终期望。随着可获得的数据越来越多，未来大数据平台的价值更多的取决于其计算人工智能的程度。

现在机器学习正慢慢跨出象牙塔，从一个少部分学术界人士研究的科技课题变成很多企业正在验证使用的数据分析工具，而且已经越来越多的进入我们的日常生活。

机器学习的开源项目除了之前的Mahout、MLlib、Oryx等，今年发生了很多令人瞩目的大事，迎来了数个明星巨头的重磅加入：

• 2015年1月，Facebook开源前沿深度学习工具“Torch”。
• 2015年4月，亚马逊启动其机器学习平台Amazon Machine Learning，这是一项全面的托管服务，让开发者能够轻松使用历史数据开发并部署预测模型。
• 2015年11月，谷歌开源其机器学习平台TensorFlow。
• 同一月，IBM开源SystemML并成为Apache官方孵化项目。
• 同时，微软亚洲研究院将分布式机器学习工具DMTK通过Github开源。DMTK由一个服务于分布式机器学习的框架和一组分布式机器学习算法组成，可将机器学习算法应用到大数据中。
• 2015年12月，Facebook开源针对神经网络研究的服务器“Big Sur”，配有高性能图形处理单元（GPUs），转为深度学习方向设计的芯片。

产业篇

现在使用Hadoop的企业以及靠Hadoop赚钱的企业已经成千上万。几乎大的企业或多或少的已经使用或者计划尝试使用Hadoop技术。就对Hadoop定位和使用不同，可以将Hadoop业界公司划分为四类：

• 第一梯队：这类公司已经将Hadoop当作大数据战略武器。
• 第二梯队：这类公司将Hadoop 产品化。
• 第三梯队：这类公司创造对Hadoop整体生态系统产生附加价值的产品。
• 第四梯队：这类公司消费Hadoop，并给规模比第一类和第二类小的公司提供基于Hadoop的服务。

(点击放大图像)

时至今日，Hadoop虽然在技术上已经得到验证、认可甚至已经到了成熟期。但与之对应的以Hadoop为代表的大数据基础平台产业界仍然还在迷茫和探索。虽然大数据的市场很大，但单纯Hadoop产品和服务市场，和传统关系型事务数据库市场相比还不到1%。

虽然很多高调的创业公司上线也拿到引人注目的风险投资，但只是到达大数据部署和早期成熟阶段。

其中最能代表Hadoop发展轨迹的莫过于商业公司推出的Hadoop发行版了。自从2008年Cloudera成为第一个Hadoop商业化公司，并在2009年推出第一个Hadoop发行版后，很多大公司也加入了做Hadoop产品化的行列。“发行版”这个词是开源文化特有的符号，看起来任何一个公司只要将开源代码打个包，再多多少少加个佐料就能有一个“发行版”，然而背后是对海量生态系统组件的价值筛选、兼容和集成保证以及支撑服务。

• 2012年以前的发行版基本为对Hadoop打补丁为主，出现了好几个私有化Hadoop版本，所折射的是Hadoop产品在质量上的缺陷。同期HDFS、HBase等社区的超高活跃度印证了这个事实。
• 而之后的公司更多是工具、集成、管理，所提供的不是“更好的Hadoop”而是如何更好的用好“现有”的Hadoop。
• 2014年以后，随着Spark和其他OLAP产品的兴起，折射出来是Hadoop善长的离线场景等已经能够很好的解决，希望通过扩大生态来适应新的硬件和拓展新的市场。

对于开源产品，一直有拥抱开源和提供私有化这两种流派，商业模式要么是提供技术支持服务，要么是提供私有化的增强版本。对于Hadoop的产品化也不例外。但就目前的情况看，曾经私有化Hadoop版本的代表Pivotal和Intel都已经放弃，IBM几乎事实上放弃了自有Hadoop，再考虑到之前Taobao放弃私有Hadoop路线，似乎证明了在像Hadoop这样生态庞大、发展迅速的产品，与局部私有增强带来的好处相比，长期独立站在世界的对立面并不断地与整体社区版本做代码合并似乎是越来越不可承受之痛。

如今，主要的Hadoop产品化厂商只剩下了三家厂商，并且使用了三种截然不同的商业模式。过去几年，虽然尚无任何数据现实三家厂商实现财务盈利，但在资本市场都名声赫赫，且不断收购扩张。从另外一个角度说明，Hadoop市场仍然再初级发展阶段。

Cloudera提出了Hybrid Open Source的架构：核心组件名称叫CDH（Cloudera‘s Distribution including Apache Hadoop），开源免费并与Apache社区同步，用户无限制使用，保证Hadoop基本功能持续可用，不会被厂家绑定；数据治理和系统管理组件闭源且需要商业许可，支持客户可以更好更方便的使用Hadoop技术，如部署安全策略等。Cloudera也在商业组件部分提供在企业生产环境中运行Hadoop所必需的运维功能，而这些功能并不被开源社区所覆盖，如无宕机滚动升级、异步灾备等。

(点击放大图像)

Hortonworks采用了100%完全开源策略，产品名称为HDP（Hortonworks Data Platform）。所有软件产品开源，用户免费使用，Hortonworks提供商业的技术支持服务。与CDH相比，管理软件使用开源Ambari，数据治理使用Atlas，安全组件使用Ranger而非Sentry，SQL继续紧抱Hive大腿。

(点击放大图像)

MapR采用了传统软件厂商的模式，使用私有化的实现。用户购买软件许可后才能使用。其OLAP产品主推Drill，又不排斥Impala。

(点击放大图像)

不过，三家厂商的处境有所不相同。Hortonworks虽然业绩不断进步，但直到现在仍未能实现盈利。上市后市值未能走高，可见市场对于Hadoop纯服务公司的未来价值增值期望不高。而另厢Cloudera估值近50亿美金，最后一轮收到的来自Intel的7.8亿美元已经超过Hortonworks最近6.8亿的估值，被誉为2016年最有希望上市的高科技软件公司。

现在，Cloudera和Hortonworks的定位已经不是Hadoop发行版软件开发商了，而是现代化的数据管理和分析平台建设厂家，足见其“狼子野心”。

另一方面，传统企业数据管理软件巨头仍然对即有格局信心满满，对于Hadoop产品还是观望态度，通常OEM发行版厂商而非自己研发Hadoop产品，如Oracle、Dell，Teradata公司的大数据一体机都是采用OEM化Cloudera的企业版本产品。

现在主流的公有云如AWS、Azure等都已经在原有提供虚拟机的IaaS服务之外，提供基于Hadoop的PaaS云计算服务。未来这块市场的发展将超过私有Hadoop部署。

作为大数据基础设施平台的Hadoop虽然是技术上是核心，但商业上还只是整个大数据生态系统中非常小的部分，如最新的大数据版图所示：

(点击放大图像)

应用篇

Hadoop平台释放了前所未有的计算能力，同时大大降低了计算成本。底层核心基础架构生产力的发展，必然带来的是大数据应用层的迅速建立。

对于Hadoop上的应用大致可以分为这两类：

IT优化

将已经实现的应用和业务搬迁到Hadoop平台，以获得更多的数据、更好的性能或更低的成本。通过提高产出比、降低生产和维护成本等方式为企业带来好处。

这几年Hadoop在数个此类应用场景中已经被证明是非常适合的解决方案，包括：

• 历史日志数据在线查询：传统的解决方案将数据存放在昂贵的关系型数据库中，不仅成本高、效率低，而且无法满足在线服务时高并发的访问量。以HBase为底层存储和查询引擎的架构非常适合有固定场景（非ad hoc）的查询需求，如航班查询、个人交易记录查询等等。现在已经成为在线查询应用的标准方案，中国移动在企业技术指导意见中明确指明使用HBase技术来实现所有分公司的清账单查询业务。
• ETL任务：不少厂商已经提供了非常优秀的ETL产品和解决方案，并在市场中得到了广泛的应用。然而在大数据的场景中，传统ETL遇到了性能和QoS保证上的严重挑战。多数ETL任务是轻计算重IO类型的，而传统的IT硬件方案，如承载数据库的小型计算机，都是为计算类任务设计的，即使使用了最新的网络技术，IO也顶多到达几十GB。采用分布式架构的Hadoop提供了完美的解决方案，不仅使用share-nothing的scale-out架构提供了能线性扩展的无限IO，保证了ETL任务的效率，同时框架已经提供负载均衡、自动FailOver等特性保证了任务执行的可靠性和可用性。
• 数据仓库offload：传统数据仓库中有很多离线的批量数据处理业务，如日报表、月报表等，占用了大量的硬件资源。而这些任务通常又是Hadoop所善长的

经常被问到的一个问题就是，Hadoop是否可以代替数据仓库，或者说企业是否可以使用免费的Hadoop来避免采购昂贵的数据仓库产品。数据库界的泰斗Mike Stonebroker在一次技术交流中说：数据仓库和Hadoop所针对的场景重合型非常高，未来这两个市场一定会合并。我们相信在数据仓库市场Hadoop会迟早替代到现在的产品，只不过，那时候的Hadoop已经又不是现在的样子了。就现在来讲，Hadoop还只是数据仓库产品的一个补充，和数据仓库一起构建混搭架构为上层应用联合提供服务。

(点击放大图像)

业务优化

在Hadoop上实现原来尚未实现的算法、应用，从原有的生产线中孵化出新的产品和业务，创造新的价值。通过新业务为企业带来新的市场和客户，从而增加企业收入。

Hadoop提供了强大的计算能力，专业大数据应用已经在几乎任何垂直领域都很出色，从银行业（反欺诈、征信等）、医疗保健（特别是在基因组学和药物研究），到零售业、服务业（个性化服务、智能服务，如UBer的自动派车功能等）。

在企业内部，各种工具已经出现，以帮助企业用户操作核心功能。例如，大数据通过大量的内部和外部的数据，实时更新数据，可以帮助销售和市场营销弄清楚哪些客户最有可能购买。客户服务应用可以帮助个性化服务; HR应用程序可帮助找出如何吸引和留住最优秀的员工等。

不过，互联网以外的传统行业内部，现在大数据的应用和业务普遍尚处在探索阶段，虽然不少企业已经从数据和深度挖掘数据价值中得到的甜头，但更多的企业在实现数据分析时缺少业务的指导和支撑，可量化可规模化的大数据业务闭环尚未建立，更多是站在改善用户体验等角度改善现有运营效率。

虽然行业性的大数据新兴业务解决方案尚未出现，但很多新兴的公司信心满满的进入这个市场，并收到资本市场的热捧，或提供辅助工具，或提供Big Data-as-a-Service服务，或提供基于大大数据的商业设计咨询，目的是适应大数据以及分析专家和需要他们所服务客户的需求，包括大数据准备评估、路线图、预测操作界面、算法和一些针对特定市场和企业消费分析解决方案等等。如Palantir、营销的大数据分析工具 Qubit、针对CRM领域的人工智能Neokami等等。

为什么Hadoop如此成功？

这个问题似乎是个马后炮，但当我们今天惊叹于Hadoop在短短10年时间取得如此统治性地位的时候，确实会自然而然地思考为什么这一切会发生。基于与同期其他项目的比较，我们认为有很多因素的综合作用造就了这一奇迹：

• 技术架构：Hadoop推崇的本地化计算理念，其实现在可扩展性、可靠性上的优势，以及有弹性的多层级架构等都是领先其他产品而获得成功的内在因素。没有其他任何一个这样复杂的系统能快速的满足不断变化的用户需求。
• 硬件发展：摩尔定律为代表的scale up架构遇到了技术瓶颈，不断增加的计算需求迫使软件技术不得不转到分布式方向寻找解决方案。同时，PC服务器技术的发展使得像Hadoop这样使用廉价节点组群的技术变为可行，同时还具有很诱人的性价比优势。
• 工程验证：Google发表GFS和MapReduce论文时已经在内部有了可观的部署和实际的应用，而Hadoop在推向业界之前已经在Yahoo等互联网公司验证了工程上的可靠性和可用性，极大的增加了业界信心，从而迅速被接纳流行。而大量的部署实例又促进了Hadoop的发展喝成熟。
• 社区推动：Hadoop生态一直坚持开源开放，友好的Apache许可基本消除了厂商和用户的进入门槛，从而构建了有史以来最大最多样化最活跃的开发者社区，持续地推动着技术发展，让Hadoop超越了很多以前和同期的项目。
• 关注底层：Hadoop 的根基是打造一个分布式计算框架，让应用程序开发人员更容易的工作。业界持续推动的重点一直在不断夯实底层，并在诸如资源管理和安全领域等领域不断开花结果，为企业生产环境部署不断扫清障碍。

下一代分析平台

过去的十年中Apache Hadoop社区以疯狂的速度发展，现在俨然已经是事实上的大数据平台标准。我们经历了Hadoop实现这一愿景的巨大进步，见证了Hadoop 如何从一个存储和批处理架构慢慢转变为一个现代化的、模块化的数据平台。三年前，Hadoop通过Impala等分析型SQL引擎实现了互动的数据发现。两年前，Cloudera迎来了Apache Spark，并将其视为Hadoop生态系统的下一代数据处理层，能同时处理各种批次和流工作负载，为开发人员提供更好的易用性和更高的性能。

但仍有更多的工作要做！

大数据应用未来的价值在于预测，而预测的核心是分析。下一代的分析平台会是什么样呢？它必定会面临、同时也必须要解决以下的问题：

1. 更多更快的数据。未来的大数据来源更多的是来自物联网（IoT，Internet of Things），将有超过160亿的设备联网并不断产生数据。数据量更大，而且对数据处理的实时性要求的更高。
2. 更新的硬件特性及架构。Hadoop、Spark等技术兴起的重要推动原因都是硬件的发展。现在摩尔定律已经退出历史舞台，未来硬件架构可能呈现多样化发展，可靠性越来越高，存储和计算成本继续降低，内存的容量和速度越来越快，持久化或非挥发性存储的发展会对现有的存储设计带来新的技术和架构。
3. 更高级的分析。技术的发展背后总是业务需求的驱动。但现在的大数据项目多是初级阶段的IT系统，目的是解决目前IT有限的能力限制和成本压力，并非针对业务创造新的价值，甚至没有对业务有直接互动和反馈。未来的需求是要使用实时数据建立更好的模型，使用机器学习等高级数据分析技术，能够改善用户体验、优化业务运营，实现大数据业务的闭环。
4. 更安全。随着企业希望能把手里的数据资源开放变现，但频发的安全事故又让企业驻足不前，很少有人敢冒风险进行开放尝试。需要通过安全机制实时地保护用户和企业的资产；通过行为分析和稽查保证流程的正确性和结果的可信性。

因此，未来的几年，我们会继续见证“后Hadoop时代”的下一代企业大数据平台：

1. 内存计算时代的来临。随着高级分析和实时应用的增长，对处理能力提出了更高的要求，数据处理重点从IO重新回到CPU。以内存计算为核心的Spark将代替以IO吞吐为核心的MapReduce成为分布式大数据处理的缺省通用引擎。做为既支持批处理有支持准实时流处理的通用引擎，Spark将能满足80%以上的应用场景。Cloudera公司近日公布了One Platform的倡议，推动Spark成为Hadoop的默认数据处理引擎。为了最终取代MapReduce，Cloudera集中力量推动解决Spark现在企业大规模应用时在四个关键领域仍然存在的短板：管理，安全，规模和流。
然而，Spark毕竟核心还是批处理，擅长迭代式的计算，但并不能满足所有的应用场景。其他为特殊应用场景设计的工具会对其补充，包括：

a) OLAP。OLAP，尤其是聚合类的在线统计分析应用，对于数据的存储、组织和处理都和单纯离线批处理应用有很大不同。以Impala为代表的SQL-on-Hadoop引擎借鉴了传统数据处理和MPP等技术，底层使用HDFS存储，是传统BI系统很好的替代方案候选。

b) 知识发现。与传统应用解决已知问题不同，大数据的价值在于发现并解决未知问题。因此，要最大限度地发挥分析人员的智能，将数据检索变为数据探索。Apache Solr项目是一个功能丰富的可扩展的搜索解决方案，内包括了Apache Lucene和Apache Tika。Cloudera的Search将Solr集成到了Hadoop，并使用高度自动化的流水线为Hadoop上的数据创建索引，在提高部署效率的同时，提供了更加直观方便的大数据平台搜索引擎。

2. 统一数据访问管理。现在的数据访问由于数据存储的格式不同、位置不同，用户需要使用不同的接口、模型甚至语言。同时，不同的数据存储粒度都带来了在安全控制、管理治理上的诸多挑战。未来的趋势是将底层部署运维细节和上层业务开发进行隔离，因此，平台需要系统如下的功能保证：

a) 安全。能够大数据平台上实现和传统数据管理系统中相同口径的数据管理安全策略，包括跨组件和工具的一体化的用户权利管理、细粒度访问控制、加解密和审计。

b) 统一数据模型。通过抽象定义的数据描述，不仅可以统一管理数据模型、复用数据解析代码，还可以对于上层处理屏蔽底层存储的细节，从而实现开发/处理与运维/部署的解偶。

Cloudera最近发布的RecordService正是为此而生。Apache Sentry是Hadoop生态中负责跨组件统一访问控制的安全解决方案。RecordService和Sentry等组件结合，提供了跨整个平台的细粒度的统一访问控制策略，消除了Hive、HBase等组件分散而差异的访问粒度控制。DFS执行的新的核心服务。同时RecordService屏蔽了底层存储细节，向上暴露基于记录的面向对象的数据描述，为编程人员提供了更好的封装和抽象。

3. 简化实时应用。现在用户不仅关心如何实时的收集数据，而且关心同时尽快的实现数据可见和分析结果上线。无论是以前的delta架构还是现在lambda架构等，都希望能够有一种解决快速数据的方案，使用HDFS和HBase的混合体，在快速更新数据的同时进行快速分析，然而结果复杂的架构令人望而却步，无论开发还是运维都不胜其繁。Cloudera最新公开的Kudu虽然还没有进入产品发布，但却是现在解决这个问题可能的最佳方案：采用了使用单一平台简化了快速数据的“存取用”实现，是未来日志类数据分析的新的解决方案。

最近新面世的这些项目将彻底改变Hadoop的存储架构,进一步巩固其安全基础，推动Hadoop不断发展和扩大，成为新一代的现代分析的领先平台。

下一个十年

Hadoop的未来是什么样的？10年以后大数据是不是已经进博物馆了？会不会有一个新公司成为数据管理界的新的巨头，犹如今日的Oracle？会不会有高富帅的企业已经有百万、千万甚至更多机器组成的数据中心？

有许多的可能，但我们相信Hadoop所“发明”的分布式计算框架仍然会是大数据的核心标志。

10 年前谁也没有料想到 Hadoop 能取得今天这样的成就，而如今一切均在眼前。Hadoop 之父 Doug Cutting 则认为 Hadoop 正处于蓬勃的发展期，而且这样的蓬勃发展至少还可以持续几十年。

10年以后的Hadoop应该只是一个生态和标准的“代名词”了，下层的存储层不只是HDFS、HBase和Kudu等现有的存储架构，上层的处理组件更会像app store里的应用一样多，任何第三方都可以根据Hadoop的数据访问和计算通信协议开发出自己的组件，用户在市场中根据自己数据的使用特性和计算需求选择相应的组件自动部署。

当然，有一些明显的趋势必然影响着Hadoop的前进：

• 云计算

  现在50%的大数据任务已经运行在云端，在3年以后这个比例可能会上升到80%。Hadoop在公有云的发展要求更加有保障的本地化支持。

• 硬件

  快速硬件的进步会迫使社区重新审视Hadoop的根基。回顾历史，任何一次硬件的革新都会翻开软件业的新篇章。现在CPU发展摩尔定律已经退出历史舞台，但新型的硬件，如3D point等即将登场企业数据中心。现在虽然尚未有与之相应的软件产品，但必然会出现，而Hadoop社区也绝不会袖手旁观。

• 物联网

  物联网的发展会带来海量的、分布的和分散的数据源。Intel CEO预测2020年将有500亿设备联网，会带来50万亿GB的数据；世界经济论坛预测2022年将有1万亿传感器入网；按照梅特卡夫定律，5年后全球IoT自动服务网的总体价值将是现在的517倍。Hadoop将适应这种发展。

以后的十年会发生什么？以下是笔者的一些猜想：

1. SQL和NoSQL市场会合并，NewSQL和Hadoop技术相互借鉴而最终走向统一，Hadoop市场和数据仓库市场会合并，然而产品碎片化会继续存在。
2. Hadoop与其他资源管理技术和云平台集成，融合docker和unikernal等技术统一资源调度管理，提供完整多租户和QoS能力，企业数据分析中心合并为单一架构。
3. 企业大数据产品场景化。以后直接提供产品和技术的公司趋于成熟并且转向服务。越来越多的新公司提供的是行业化、场景化的解决方案，如个人网络征信套件以及服务。
4. 大数据平台的场景“分裂”。与现在谈及大数据言必称Hadoop以及某某框架不同，未来的数据平台将根据不同量级的数据（从几十TB到ZB）、不同的应用场景（各种专属应用集群）出现细分的阶梯型的解决方案和产品，甚至出现定制化一体化产品。

无论10年或20年后的Hadoop看起来像什么样，无可质疑的是由于数据量、数据种类和数据速度的提升会带来更强大的使用用例。如何把原始数据转化为可执行的洞察力将是最清晰最有力的推动力量。正如Cloudera的首席科学家、Hadoop的创始人Doug Cutting所说：“我们在本世纪取得的大部分进展将来自于对所产生的数据的理解的增加。”

后记

笔者水平有限，加之时间紧迫，肤浅粗糙之处，还请各位读者原谅和指教。文中有些内容引自网络，某些出处未能找到，还请原作者原谅。

Hadoop的组件生态组件太多，参加Cloudera的全套Hadoop课程就需要花费1个月以上的时间，让人“累觉不爱”J。本文中只是蜻蜓点水，很多东西尚未详述，请参见相关产品手册。

欢迎访问网站，观看Doug Cutting关于Hadoop十年的视屏。

大数据的明天是美好的，未来Hadoop一定是企业软件的必备技能，希望我们能一起见证。

参考资料

1. Is Big Data Still a Thing? (The 2016 Big Data Landscape)
2. 解读2015之大数据篇：大数据的黄金时代
3. Happy 10th Birthday, Apache Hadoop
4. 大象的崛起！Hadoop七年发展风雨录

个人简介

陈飚，Cloudera售前技术经理、行业领域顾问、资深方案架构师，原Intel Hadoop发行版核心开发人员。2006年加入Intel编译器部门从事服务器中间件软件开发，擅长服务器软件调试与优化，曾带领团队开发出世界上性能领先的 XSLT 语言处理器。2010 年后开始Hadoop 产品开发及方案顾问，先后负责Hadoop 产品化、HBase 性能调优，以及行业解决方案顾问，已在交通、通信等行业成功实施并支持多个上百节点Hadoop 集群。

感谢杜小芳对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。