Hadoop的那些事儿

　　文/张巡

　　在说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都有很广泛的应用