Hadoop即将过时了吗？

 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 所做的那样。