您的位置:知识库 » 开源

Hadoop的那些事儿

作者: 张巡  发布时间: 2010-12-01 12:01  阅读: 3692 次  推荐: 2   原文链接   [收藏]  

  文/张巡

  在说Hadoop之前,作为一个铁杆粉丝先粉一下Google。Google的伟大之处不仅在于它建立了一个强悍的搜索引擎,它还创造了几项革命性的技术:GFS,MapReduce,BigTable,即所谓的Google三驾马车。Google虽然没有公布这几项技术的实现代码,但它发表了详细的设计论文,这给业界带来了新鲜气息,很快就出现了类似于Google三驾马车的开源实现,Hadoop就是其中的一个。

  关于MapReduce  

  Hadoop说起来很简单,一个存储系统(HDFS),一个计算系统(MapReduce)。仅此而已。模型虽然简单,但我觉得它的精妙之处也就在这里。目前,通过提高CPU主频来提升计算性能的时代已经结束了,因此并行计算、分布式计算在业界发展了起来,但是这也往往意味着复杂的设计与实现,如果能找到一种方法,只需要写简单的程序就能实现分布式计算,那就太好了。

  我们可以回想下当初做的课堂作业,它可能是一个处理数据的程序,没有多线程,没有进程间通信,数据输入都是来自键盘(stdin),处理完数据之后打印到屏幕(stdout),这时的程序非常简单。后来我们学习了多线程、内存管理、设计模式,写出的程序越来越大,也越来越复杂。但是当学习使用Hadoop时,我们发现又回到了最初,尽管底层是一个巨大的集群,可是我们操作文件时就像在本地一样简单,写MapReduce程序时也只需要在单线程里实现数据处理。

  Hadoop就是这样一个东西,简单的文件系统(HDFS),简单的计算模型(MapReduce)。这其中,我觉得HDFS是很自然的东西,如果我们自己实现一个,也很可能是这样的。但是仔细琢磨下MapReduce,会发现它似乎是个新奇事物,不像HDFS的界面那样通俗易懂老少皆宜。MapReduce虽然模型简单,却是一个新的、不广为人所知的概念。比如说,如果说要简化计算,为何要做成Map和Reduce两个阶段,而不是一个函数足矣呢?另外,它也不符合我们耳熟能详的那些设计模式。一句话,MapReduce实在太另类了。

  Hadoop的思想来源于Google的几篇论文,Google的那篇MapReduce论文里说:Our abstraction is inspired by the map and reduce primitives present in Lisp and many other functional languages。这句话提到了MapReduce思想的渊源,大致意思是,MapReduce的灵感来源于函数式语言(比如Lisp)中的内置函数map和reduce。函数式语言也算是阳春白雪了,离我们普通开发者总是很远。简单来说,在函数式语言里,map表示对一个列表(List)中的每个元素做计算,reduce表示对一个列表中的每个元素做迭代计算。它们具体的计算是通过传入的函数来实现的,map和reduce提供的是计算的框架。不过从这样的解释到现实中的MapReduce还太远,仍然需要一个跳跃。再仔细看,reduce既然能做迭代计算,那就表示列表中的元素是相关的,比如我想对列表中的所有元素做相加求和,那么列表中至少都应该是数值吧。而map是对列表中每个元素做单独处理的,这表示列表中可以是杂乱无章的数据。这样看来,就有点联系了。在MapReduce里,Map处理的是原始数据,自然是杂乱无章的,每条数据之间互相没有关系;到了Reduce阶段,数据是以key后面跟着若干个value来组织的,这些value有相关性,至少它们都在一个key下面,于是就符合函数式语言里map和reduce的基本思想了。

  这样我们就可以把MapReduce理解为,把一堆杂乱无章的数据按照某种特征归纳起来,然后处理并得到最后的结果。Map面对的是杂乱无章的互不相关的数据,它解析每个数据,从中提取出key和value,也就是提取了数据的特征。经过MapReduce的Shuffle阶段之后,在Reduce阶段看到的都是已经归纳好的数据了,在此基础上我们可以做进一步的处理以便得到结果。这就回到了最初,终于知道MapReduce为何要这样设计。

  Hadoop, More and More

  Hadoop/MapReduce的Job是一个昙花一现的东西,它仅仅是一个计算过程而已,所有数据都是从HDFS来,到HDFS去。当最后一个Reduce完成之后,整个Job就消失了,只在历史日志中还保存着它曾经存在的证据。

  Hadoop中的节点是对等的,因此每个节点都是可替代的。也因此,JobTracker可以把任务分配到任何一个节点执行,而不影响最后的产出结果。如果不是这样,就破坏了Hadoop的对等性。对等性可以说是Hadoop扩展能力、容错能力的基础,它意味着计算不再局限于单个节点的能力。当然事情总有两面性,对等性造成的结果是,如果我们想让某些节点做特殊的事情,会发现很困难。

  就像很多分布式系统中的文件、对象一样,Hadoop对数据的操作是原子性的,一个Job跑完之后,最终的数据是在一瞬间呈现的,如果Job失败了,则什么都没有,连部分数据也得不到。由于Job中的task都是并行的,因此这里适用于木桶理论,最后一个完成的那个task决定了整个Job完成的时刻。所以如果Hadoop发现某些Task特别慢,会在其它节点运行这些Task的副本,当其中某个副本完成后,Hadoop将Kill掉其余的副本,这也是基于对等性的一个应用,使得那些慢的节点不会拖慢Job。如果某个task在重试若干次之后仍然失败了,那么整个Job宣告失败。

  Hadoop包括HDFS、MapReduce,此外还有Hbase、Hive等,普通的应用大概是存储海量的数据,并进行批量的处理、数据挖掘等,不过也有些比较巧妙的实际应用,比如用Hadoop搭建HTTP下载服务器,或FTP服务器等,还有人用Hadoop搭建视频点播服务器。我觉得Hadoop对这些应用的最大价值是可以降低硬件成本,以前也许需要购买昂贵的硬件,现在购买廉价的服务器就可以实现。不过,做这些应用都需要对Hadoop做定制,修改代码啥的,似乎还没有整体的解决方案。

  Hadoop是Java写的。可能有不少人会想,如果Hadoop是用C或C++写的,会不会更快些?关于这个问题网上也有不少讨论,简单地说就是,不会更快。而且我觉得需要强调的一点是,当面对Hadoop要面对的问题域时,编程语言不是首先要考虑的问题,或者说,依赖于具体的实现方案。Hadoop要处理的是大批量数据,它强调的是吞吐量,当整个集群跑起来之后,系统的瓶颈往往是在磁盘IO和网络IO,这种情况下,用C/C++实现Hadoop不见得比Java实现性能更高。相反,由于Java语言的严谨、统一和一些高级特性,用Java实现Hadoop对开发者而言会更容易。一般来讲,无论是用C++写还是用Java写,当系统发展较成熟时,都已经经过了相当的优化,这时系统的瓶颈往往不在于软件了,而在于硬件的限制。当然,这并非意味着目前Hadoop已经实现得很好了,Hadoop还有很大的优化空间,它的开发进程依然火爆,很多人在优化Hadoop,还包括用C++来改写Hadoop的部分代码的。另外,对于超大的集群(比如几千台服务器),调度器的优化也很关键,否则它就可能成为整个集群的瓶颈。我想这就是Hadoop虽然已经广泛应用,但是版本号依然还是零点几的原因吧。

  虽说Hadoop的模型很简单,但是开发Hadoop的Job并不容易,在业务逻辑与HadoopAPI之间,我们还必须写大量的胶水代码,这无异于在WindowsSDK基础上写一个画图板程序,或者在Linux系统调用基础上写一个支持多用户在线的聊天服务器,这些似乎都不难,但是比较繁琐,需要堆砌大量代码,写完一个之后,你大概不会再写第二个。我把这种情况称为用汇编语言写程序,也就是说,你面对的是业务问题,却必须不遗巨细与机器打交道。

  面对上述困境,人们想出了很多解决办法,开发出高级语言来屏蔽底层的细节,让开发过程更加简单,我把这种情况称为用脚本写程序,可以很快的修改&调试。其中Facebook开发了Hive,这是类似于SQL的脚本语言,开发者基本上只要面对自己的业务数据,就能写出Hive脚本,虽然有一定的入门门槛,但是比起用HadoopAPI写程序,可以称得上是巨简单了。另外Yahoo开发了PIG-latin,也是类SQL的脚本语言,Hive和PIG都有很广泛的应用

2
0
标签:Hadoop

开源热门文章

    开源最新文章

      最新新闻

        热门新闻