Hadoop面临的困难

Hadoop的发展与面临的困境
Apache Hadoop技术经常与大数据概念联系在一起，它们常常同时出现在各种行业会议和媒体报道中。

Hadoop是一个开源技术，它允许公司存储和分析分布式计算环境的海量数据。

它的出现肯定对提升大数据的影响力有重要作用。

不过，Hadoop现在仍存在一些问题。

人们开始认识到，大数据和Hadoop并不是同义词。

这是因为他们下载Hadoop之后，并不意味着就能够玩儿转大数据，它仅仅只是一个工具。

”
大数据与Hadoop从幕后走到台前，Hadoop最初由互联网巨头谷歌和雅虎共同开发，现在已经转移到Apache软件基金会。

在赢得了大数据必备工具的称号并开始出现一些成功案例之后，这项技术及其醒目的logo从2011年起名声大振。

以eBay为例，这家知名电商平台在几次大会上都介绍了它的三层数据分析平台。

结构化数据位于第一层：一个用于保存内部业务项目（如支撑商业智能仪表板和报表）的企业数据仓库。

第二层由Teradata数据管理平台组成，用于存储大容量半结构化信息。

而非结构化数据（如文本信息）则保存在第三层，它是一个用于深度研究、分析和实验的Hadoop集群。

Hadoop是一个分布式文件系统，它的数据（结构化、半结构化和非结构化）存储功能优于关系型数据库。

因此，它非常适合那些需要收集大量数据的公司使用，而不会影响他们的传统关系数据库。

Hadoop使用户能够查看原始数据，这在一定程度上改变了数据仓库使用者的工作方式。

她说：“在数据仓库领域，我们鼓励提出业务需求，鼓励严格的数据质量要求，但是不鼓励独立加载数据。

但是在大数据领域，这一方式得到了颠覆。

”
Apache Hadoop困境
Hadoop还有其他优点。

例如， MapReduce能够以并行方式处理大数据集。

根据行业分析师Philip Russom的观点，它是一个通用执行引擎，甚至能够处理手工编码的代码。

但是，如果要使用MapReduce，程序员必须能够操作它的语言。

有一些工具并未被广泛熟悉，如Hive，它使用一种类SQL的语言（HQL）访问数据。

今天，Hadoop似乎已经毫无争议地成了企业大数据技术标准，看上去Hadoop将根植企业，其地位在未来十年似乎都不会动摇。

但是我们禁不住疑问：“企业真的会为一个盛极而衰的技术买单吗?”
起源：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页面，并最终为用户呈现日常搜索结果。

我们再回头看看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)才能与谷歌的技术抗衡。

增量索引过滤器(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所做的那样。