如今，Hadoop已经成为了大数据的代名词，无处不在。在短短的几年中，Hadoop从一种边缘技术成为一种事实上的标准。你若想成为大数据分析师或商业智能分析师，那你必须对Hadoop了如指掌才可以。
毫无疑问，Hadoop作为大数据的标准分析工具已深深地植根于企业，至少在未来10年它的地位都不会被动摇。但Hadoop真如表面上那样前途无量吗？企业是否正在购买或使用一项“日落西山”技术，只是“夕阳无限好”？
Google文件系统和Google MapReduce
Hadoop的出现是受到最先由 Google Lab 开发的 Map/Reduce 和 Google File System(GFS) 启发。2006 年 3 月份，Map/Reduce 和 Nutch Distributed File System (NDFS) 分别被纳入称为 Hadoop 的项目中。面对数据大爆炸时代的到来，谷歌的两位工程师Jeff Dean and Sanjay Ghemawat设计并发布了两个开创性的系统：谷歌文件系统（GFS）和谷歌的MapReduce（GMR）。前者是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用,运行于廉价的普通硬件上，但可以提供容错功能,可以给大量的用户提供总体性能较高的服务；后者用于大规模数据集（大于1TB）的并行运算。
GMR的特色在于极大的方便了谷歌编程人员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上，并提高速度和容错能力。简而言之，GMR按比例将数据规模缩小，在兼顾所有数据的同时突出关键性数据。GFS和GMR逐渐成为处理器引擎的核心技术，用来抓取和分析数据、进行网页排序等，这些我们在Google.com日常搜索中都使用过。这显然是谷歌的一个主要优势。
由Hadoop分布式文件系统和Hadoop MapReduce组成的Apache Dadoop源于GFS和GMR的设计思路。Hadoop确实已经演变成一个生态系统，它几乎可以应对所有的数据管理和数据处理。但是，Hadoop的核心仍然是MapReduce系统。你写的代码最终都会变成映射（Map）和化简（Reduce），Hadoop为你运行这些代码。
谷歌发力，hadoop何去何从？
然而，最有趣的是，GMR不再允许这样卓越的东西存在于Google Stack中。正如企业正在锁定MapReduce一样，谷歌似乎正在舍弃它而大步向前。事实上，接下来本文讨论的许多技术都不是新出现的，这些技术可以追溯到过去的5-10年，GMR文章出现的几年后。
我希望以下这些技术能支撑后Hadoop时代。尽管许多Apache项目和商业Hadoop机构都在积极努力的通过各种技术如HBase、Hive和下一代MapReduce（aka YARN）来解决一些问题，但在我看来，这需要新的、基于non-MapReduce的架构做Hadoop的核心（HDFS和Zookeeper）才能与谷歌做真正的技术较量。
为增量索引而生的Percolator和频率分析正在改变数据集。Hadoop是一个大机器。一旦你将它开启并加速，它那非常擅长挖掘数据的功能就能展现出来，你的磁盘将以尽可能快的速度转动。然而，每次你要分析数据（比如添加，修改或删除数据后），你必须重新梳理整个数据集。如果你的数据集总是在扩大，这意味着你的分析时间也在无限制的延长。
那么，谷歌是如何实现实时结果搜索呢？是通过一个名叫Percolator的增量处理引擎取代了GMR。通过只处理新增的、修改过或删除的文件和使用辅助指标有效地编目和查询结果输出，谷歌才得以大幅降低搜索结果输出时间。Percolator论文的作者写道，“将索引系统转换为增量系统后，文件处理的平均时间延迟减少了100倍。”这意味着，与使用MapReduce系统相比，互联网上的新增内容被搜索到的时间快了100倍。
为特殊分析而生的Dremel。Google和Hadoop生态系统的相关机构都在非常努力使MapReduce成为一个可用的特色分析工具。从Sawzall到Pig和Hive，许多界面层已建成。然而，他们都忽视了一个基本的现实 —MapReduce是针对处理结构化数据建立的。它诞生于工作流的核心需求，而非非结构化数据的大爆炸。
与之形成鲜明对比的是，许多BI /分析查询是基于非结构化、互动、低延迟的分析。映射（Map）和化简（Reduce）工作流程不仅让许多分析师望而却步，而且这种工作流程也不利于互动式体验。因此，谷歌发明了Dremel（现在作为BigQuery呈现），专门为分析师在浏览PB级数据，应对及时响应特殊查询、预测和强大的可视化需求而建立的工具。
谷歌的BigQuery
谷歌的DREMEL文章指出，这是“能够运行超过万亿秒的行聚集查询”，文章同时指出，运行相同的需求，标准的MapReduce比DREMEL慢了约100倍。然而，最令人印象深刻的是谷歌产品系统所产生数据，DREMEL用不到10秒的时间即可完成查询任务，甚至比开始执行一个MapReduce的工作流程及其相关工作的典型延迟时间还要短。
为分析图表数据而生的Pregel。谷歌MapReduce建立的目的是抓取和分析世界上最大的图形数据结构—互联网。然而，MapReduce的一些核心假设是基本由人、电信设备、文件和其他图标数据组成的网络结构的基本概率。例如，若果要通过图表计算单源最短路径（SSSP）的话，需要复制图表到MapReduce，这种做法效率非常低。
因此，谷歌建立了Pregel—在分布式的普通硬件上同步处理PB级规模的应用。结果令人印象深刻。与Hadoop对比，Hadoop在图形处理时往往导致指数数据放大，Pregel却能够顺利且有效地在极短的时间内执行诸如SSSP或PageRank的图算法，而且代码并不复杂
虽然，Hadoop是一个用普通硬件处理大规模数据集群的非常棒的工具。但如果你想处理动态数据集，非结构化数据或图形数据结构，谷歌自己的行动清楚地表明了MapReduce模式的替代品—Percolator、Dremel 和Pregel组成了大数据时代一曲非常美妙的三重奏。如果它们对IT产生的影响不能与GFS、GMR和GigTable相媲美，那才会人感到震惊。
原文作者：Mike Miller 来源：GigaOM