Hadoop处于风雨飘摇中

作者简介：George Gilbert是Wikibon研究公司的大数据和数据分析分析师。

摘要：Hadoop或因身份危机而丢掉大数据领导者的宝座。

去年，我们都知道企业界的大数据意味着。它意味着Hadoop，它处于大幅采用浪潮的鼎盛时期。如今，大数据仍然追波逐浪，但目前还不清楚Hadoop是否跟得上势头。

Hadoop的成功在生态系统方面带来了意想不到的影响。Hadoop这个名头始终适用于几大厂商中任何一家组织并监管的一系列开源大数据工具，其中以Cloudera、Hortonworks和MapR为首。但是，我们看到类似的、创新的开源工具遍地开花，它们在建立替代的生态系统，比如Spark、Kafka、Mesos、S3和Cassandra。说实话，这样的工具有几十种。这一批新工具迅速崛起，有可能排挤Hadoop，进而丢掉新兴的大数据生态系统的“当家花旦”这一称号。

Hadoop的身份危机给大数据专业人士带来了挑战，因为该生态系统现在包括种类极其广泛的工具，以至于削弱了生态系统的一致连贯性：

• Splunk是一个替代者。它与其说是一种工具包，还不如说是一种应用软件，所以它直接提供了价值，而不是要求为期6个月至9个月的试点，它需要的专业开发人员和管理技能也要少得多。

• 基于持续处理的实时应用软件，比如Kafka、Spark和Flink，将Hadoop逼到了绝境，因为Hadoop是为批处理而设计的。

• 由于工具数量猛增，Hadoop厂商在工具如何协同运行方面已失去了太多的控制权。当一系列工具广为人知的时候，Hadoop可以用自己的管理工具将它们连接起来，帮助简化它们如何协同运行。

回顾历程，才能洞察未来

Hadoop的传统强项一直在于它为客户提供的灵活性。客户头一次使用自己动手（DIY）的方法，利用开源组件组装分析数据管道。与此同时，没有哪一家企业组织开发所有的组件。这种随心所欲的治理方法及客户需求促使大数据工具的数量和质量出现了显著增长，Hadoop厂商可以借助这些工具，组织并监管它们发行的一系列工具。

我们参加2015年在圣何塞召开的Hadoop峰会时，“三大Hadoop”发行版厂商：Cloudera、Hortonworks和MapR基本上就大数据管理平台应该包括哪些部分达成了相当广泛的共识。即使人们的注意力开始远离MapReduce，Hadoop的核心对所有使用场合来说仍包括Hadoop分布式文件系统（HDFS）和YARN。每家Hadoop发行版厂商还加入了另外20个至30个Apache项目，这些项目使得每一个发行版都大同小异。最后，发行版厂商添加了管理工具，帮助整合当初开发时完全缺乏集中协调的所有这些组件。即便发行版仍然相当笨拙，大数据专业人士仍通常了解每个部分的功能、它与其他部分是怎么协同工作的。

快进到几周前召开的2016年Hadoop峰会。

开源大数据软件产品数量激增的步伐有增无减，而这是个问题。三巨头当初就哪些部分属于Hadoop生态系统方面达成的脆弱共识在渐渐瓦解。

因而，客户随之困惑起来。层出不穷的技术在迅速带来新的营销术语，比新的技术、应用软件或客户还要快。我们在Hadoop峰会上一遍又一遍地听到客户说：我们失去了从生态系统太多的组件中进行选择，组装一条连贯的分析数据管道的能力。这就破坏了当初让Hadoop得以流行起来的“混合搭配”（mix-and-match）这一价值主张。

Hortonworks似乎势必会看到这股浪潮即将袭来。这家公司告诉我们，它会更加规范，界定如何为每一种使用场合选择合适的组件。而认识到大数据现在不再仅限于Hadoop，它宣布未来的大会将名为Dataworks，而不是Hadoop峰会。但最重要的是，业界也需要一家厂商，能够领导其他厂商围绕一种新平台达成共识，稳住生态系统越来越混乱的局面。

那么，究竟是什么因素“引发”大数据产品遍地开花？

微微星火可以燎原

意大利文艺复兴运动先驱但丁在写下那些话语的时候，显然没有想到Hadoop，但这就是我们今天所处的现状。Hadoop的开头很普通：雅虎和谷歌将它用作一种简单的、专业的产品，旨在索引网页，以便搜索。但是三大Hadoop厂商认识到，Hadoop的作用可能不仅限此，于是把自己扮演成了开源Hadoop平台的守护者，面向数据丰富的应用系统。

我们不妨更认真地探究一下Hadoop的定义方面达成的这种共识现在如何瓦解，以及为何如此。Spark能够持续处理数据，它正在迅速取代批处理技术MapReduce，作为Hadoop中的默认执行引擎。Spark为Hadoop带来了全新的使用场合。因而可以借助高级分析构建持续处理功能，而不是仅仅拥有数据流功能，作为批处理的一种辅助。

Hadoop厂商的竞争对手不是对方，而是更容易被开发人员和管理员访问及使用的大数据3.0云服务。

颇具讽刺意味的是，Spark具有的广度让我们有可能构建核心平台，一个全新的生态系统（包括构建大数据丰富应用程序的工具）围绕这个核心平台而建。现在用的是Cassandra，而不是HBase；现在用的是Docker容器和Mesos或Kubernetes，而不是YARN。现在用的是Kafka，而不是Flume。现在用的是S3或几乎任何商用对象存储系统，而不是HDFS这个最终的“蟑螂即幸存者”（cockroach-as-survivor）技术。

所有这些创新随之带来了管理和开发方面的复杂性。主流企业无力或不愿招聘稀缺、必要又昂贵的技术人才，而是日益求助于亚马逊、微软和谷歌，以及夯实其服务或基础设施的其他厂商，提供“XX即服务”这种简单性。

除了Hadoop外，这些云提供商对于分析即服务也有自己的见解。如今，客户可以选择运行在这些提供商的云端托管的Hadoop，换取一些专门、专有的功能，比如借助亚马逊Kinesis Firehose的弹性数据获取，或者Azure方面的机器学习API库。随着时间的推移，我们要求云提供商在其专有服务之间提供极其深度的整合。如果客户愿意放弃开源软件，云提供商可能会提供大数据分析套件在开发和管理方面的简单性，而这种大数据分析套件是作为一个单元而设计、构建、测试、运行和交付的。

如果传统的Hadoop厂商想在这个迅速扩大的生态系统里面竞争，它们要做的不仅仅是组织并监管一系列工具，还需要构建一个一致连贯的平台，可以隐藏众多工具在管理和开发方面的复杂性。