Meng Yan ( 孟岩 )’s Weblog

微软著名的C++大师Herb Sutter在2005年初的时候曾经写过一篇重量级的文章：”The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software“，预言OO之后软件开发将要面临的又一次重大变革-并行计算。 摩尔定律统制下的软件开发时代有一个非常有意思的现象：”Andy giveth, and Bill taketh away.”。不管CPU的主频有多快，我们始终有办法来利用它，而我们也陶醉在机器升级带来的程序性能提高中。 我记着我大二的时候曾经做过一个五子棋的程序，当时的算法就是预先设计一些棋型（有优先级），然后扫描棋盘，对形势进行分析，看看当前走哪部对自己最重要。当然下棋还要堵别人，这就需要互换双方的棋型再计算。如果只算一步，很可能被狡猾的对手欺骗，所以为了多想几步，还需要递归和回朔。在当时的机器上，算3步就基本上需要3秒左右的时间了。后来大学毕业收拾东西的时候找到这个程序，试了一下，发现算10步需要的时间也基本上感觉不出来了。 不知道你是否有同样的经历，我们不知不觉的一直在享受着这样的免费午餐。可是，随着摩尔定律的提前终结，免费的午餐终究要还回去。虽然硬件设计师还在努力：Hyper Threading CPU（多出一套寄存器，相当于一个逻辑CPU）使得Pipeline尽可能满负荷，使多个Thread的操作有可能并行，使得多线程程序的性能有5%-15%的提升；增加Cache容量也使得包括Single-Thread和Multi-Thread程序都能受益。也许这些还能帮助你一段时间，但问题是，我们必须做出改变，面对这个即将到来的变革，你准备好了么？ Concurrency Programming != Multi-Thread Programming。很多人都会说MultiThreading谁不会，问题是，你是为什么使用/如何使用多线程的？我从前做过一个类似AcdSee一样的图像查看/处理程序，我通常用它来处理我的数码照片。我在里面用了大量的多线程，不过主要目的是在图像处理的时候不要Block住UI，所以将CPU Intensive的计算部分用后台线程进行处理。而并没有把对图像矩阵的运算并行分开。 我觉得Concurrency Programming真正的挑战在于Programming Model的改变，在程序员的脑子里面要对自己的程序怎样并行化有很清楚的认识，更重要的是，如何去实现（包括架构、容错、实时监控等等）这种并行化，如何去调试，如何去测试。 在Google，每天有海量的数据需要在有限的时间内进行处理（其实每个互联网公司都会碰到这样的问题），每个程序员都需要进行分布式的程序开发，这其中包括如何分布、调度、监控以及容错等等。Google的MapReduce正是把分布式的业务逻辑从这些复杂的细节中抽象出来，使得没有或者很少并行开发经验的程序员也能进行并行应用程序的开发。 MapReduce中最重要的两个词就是Map（映射）和Reduce（规约）。初看Map/Reduce这两个词，熟悉Function Language的人一定感觉很熟悉。FP把这样的函数称为”higher order function”（”High order function”被成为Function Programming的利器之一哦），也就是说，这些函数是编写来被与其它函数相结合（或者说被其它函数调用的）。如果说硬要比的化，可以把它想象成C里面的CallBack函数，或者STL里面的Functor。比如你要对一个STL的容器进行查找，需要制定每两个元素相比较的Functor（Comparator），这个Comparator在遍历容器的时候就会被调用。 拿前面说过图像处理程序来举例，其实大多数的图像处理操作都是对图像矩阵进行某种运算。这里的运算通常有两种，一种是映射，一种是规约。拿两种效果来说，”老照片”效果通常是强化照片的G/B值，然后对每个象素加一些随机的偏移，这些操作在二维矩阵上的每一个元素都是独立的，是Map操作。而”雕刻”效果需要提取图像边缘，就需要元素之间的运算了，是一种Reduce操作。再举个简单的例子，一个一维矩阵（数组）[0,1,2,3,4]可以映射为[0,2,3,6,8]（乘2），也可以映射为[1,2,3,4,5]（加1）。它可以规约为0（元素求积）也可以规约为10（元素求和）。 面对复杂问题，古人教导我们要“分而治之”，英文中对应的词是”Divide and Conquer“。Map/Reduce其实就是Divide/Conquer的过程，通过把问题Divide，使这些Divide后的Map运算高度并行，再将Map后的结果Reduce（根据某一个Key），得到最终的结果。 Googler发现这是问题的核心，其它都是共性问题。因此，他们把MapReduce抽象分离出来。这样，Google的程序员可以只关心应用逻辑，关心根据哪些Key把问题进行分解，哪些操作是Map操作，哪些操作是Reduce操作。其它并行计算中的复杂问题诸如分布、工作调度、容错、机器间通信都交给Map/Reduce Framework去做，很大程度上简化了整个编程模型。 MapReduce的另一个特点是，Map和Reduce的输入和输出都是中间临时文件（MapReduce利用Google文件系统来管理和访问这些文件），而不是不同进程间或者不同机器间的其它通信方式。我觉得，这是Google一贯的风格，化繁为简，返璞归真。 接下来就放下其它，研究一下Map/Reduce操作。（其它比如容错、备份任务也有很经典的经验和实现，论文里面都有详述） Map的定义： Map, written by the user, takes [...]