http://www.kuqin.com/database/20120715/322528.html

Hadoop这个单词如今铺天盖地，几乎成了大数据的代名词。仅仅数年时间，Hadoop从边缘技术迅速成长为一个事实标准。如今想玩转大数据，搞企业分析或者商业智能，没有Hadoop还真不行。但Hadoop狂热的背后却酝酿着一场技术变革，Hadoop的核心技术在Google那里已经过时，因为Hadoop并不擅长处理“快数据”。

今天，Hadoop似乎已经毫无争议地成了企业大数据技术标准，看上去Hadoop将根植企业，其地位在未来十年似乎都不会动摇。但是GigaOM的专栏作家Mike Miller却发出了“不和谐”的声音：“企业真的会为一个盛极而衰的技术买单吗？”

起源：Google文件系统和Google MapReduce

为了探讨Hadoop的生命周期我们需要回溯Hadoop的灵感源泉——Google的MapReduce。为了迎接数据大爆炸的挑战，Google的工程师Jeff Dean和Sanjay Ghemawat架构了两个影响深远的系统：Google File System（GFS）和Google MapReduce（GMR）。前者是一个能在通用硬件上管理EB（Exabyte）级数据的出色的可行方案。后者则是一个同样出色的，能在通用服务器上大规模并行处理数据的模型设计实现。

GMR的出彩之处在于能够让普通的Google用户和开发者也能够进行高速、容错的大数据处理。GMR和GFS成了搜索引擎数据处理引擎的核心，该引擎抓取、分析并分级web页面，并最终为用户呈现日常搜索结果。

Hadoop生态系统

我们再回头看看Apache Hadoop的两大组成部分：Hadoop分布式文件系统和Hadoop，确实就是GFS和GMR的翻版。虽然Hadoop正在发展成为一个无所不包的数据管理和处理生态系统，但是在这个生态系统的核心，依然是MapReduce系统。所有的数据和应用最终都将降解为Map和Reduce的工作。

Google已经进化，Hadoop能否跟上？

有趣的事情是，GMR已经不再占据Google软件堆栈中的显赫位置。当企业被Hadoop解决方案锁定到MapReduce上时，Google却已经准备淘汰MapReduce技术。虽然Apache项目和Hadoop商业发行版本试图通过HBase、Hive和下一代MapReduce（亦即YARN）弥补Hadoop的短板。但笔者认为只有用全新的，非MapReduce架构的技术替代Hadoop内核（HDFS和Zookeeper）才能与谷歌的技术抗衡。（这里有一个更加技术性的阐述：gluecon-miller-horizon）

增量索引过滤器（Percolator for incremental indexing）和频繁变化数据集分析。Hadoop是一台大型“机器”，当启动并全速运转时处理数据的性能惊人，你唯一需要操心的就是硬盘的传输速度跟不上。但是每次你准备启动分析数据时，都需要把所有的数据都过一遍，当数据集越来越庞大时，这个问题将导致分析时间无限延长。

那么Google是如何解决让搜索结果返回速度越来越接近实时的呢？答案是用增量处理引擎Percolator代替GMR。通过只处理新增的、改动过的或删除的文档和使用二级指数来高效率建目录，返回查询结果。Percolator论文的作者写道：“将索引系统转换成增量系统…将文档处理延迟缩短了100倍。”这意味着索引web新内容的速度比用MapReduce快100倍！

类似大型强子对撞机产生的数据将不断变大，Twitter也是如此。这也是为什么HBase中会新增触发流程，而Twitter Storm正在成为实时处理流数据的热门技术。

用于点对点分析的Dremel。Google和Hadoop生态系统都致力于让MapReduce成为可用的点对点分析工具。从Sawzall到Pig和Hive，创建了大量的界面层，但是尽管这让Hadoop看上去更像SQL系统，但是人们忘记了一个基本事实——MapReduce(以及Hadoop)是为组织数据处理任务开发的系统，诞生于工作流内核，而不是点对点分析。

今天有大量的BI/分析查询都是点对点模式，属于互动和低延迟的分析。Hadoop的Map和Reduce工作流让很多分析师望而却步，而且工作启动和完成工作流运行的漫长周期对于很多互动性分析来说意味着糟糕的用户体验。于是，Google发明了Dremel（业界也称之为BigQuery产品）专用工具，可以让分析师数秒钟内就扫描成PB（Petabyte）的数据完成点到点查询，而且还能支持可视化。Google在Dremel的论文中声称：“Dremel能够在数秒内完成数万亿行数据的聚合查询，比MapReduce快上100倍！”

分析图数据的Pregel。Google MapReduce的设计初衷是分析世界上最大的数据图谱——互联网。但是在分析人际网络、电信设备、文档和其他一些图数据时就没有那么灵光了，例如MapReduce在计算单源最短路径（SSSP）时效率非常低下，已有的并行图算法库Parallel BGL或者CGMgraph又没有容错。

于是Google开发了Pregel，一个可以在分布式通用服务器上处理PB级别图数据的大型同步处理应用。与Hadoop经常在处理图数据时产生指数级数据放大相比，Pregel能够自然高效地处理SSSP或PageRank等图算法，所用时间要短得多，代码也简洁得多。

目前唯一能与Pregel媲美的开源选择是Giraph，这是一个早期的Apache孵化项目，调用了HDFS和Zookeeper。Githb上还有一个项目Golden Orb可用。

总结

总而言之，Hadoop是一个可以在普通通用硬件集群上进行大规模数据处理的优秀工具。但是如果你希望处理动态数据集、点对点分析或者图数据结构，那么Google已经为我们展示了大大优于MapReduce范型的技术选择。毫无疑问，Percolator、Dremel和Pregel将成为大数据的新“三巨头”，正如Google的老“三巨头”：GFS、GMR和BigTable所做的那样。