所以，在我看来我们需要找到一种手段，首先第一我能优化我的方案，第二优化用户作业。前面说过比较难实现就是如果从配置上讲，最好能配置资源，当然动态配置是因为你需要了解，思考，去模拟用户作业到底是怎么执行的才能去做，而我们这里提出一个比较确切，比较简单方式，我不需要了解这些配置，我从tasks静态解决这些问题。
我们看一下Hadoop MapReduce，来看一下Task Runtime，可以看到是通过Task的JVIM，这只是一个框架，这里讲的是去负责启动用户，用户进城之后通过管道，标准输入，标准输出来做，这样的话其实很难做到对用户进程的控制。为什么要用JAVA呢？这是Hadoop最早提出来JAVA需要跨平台，做系统软件你知道用JAVA实现跨平台很难，对于现在国内互联网公司来说，所有服务器，以及系统都是定制的，他不需要跨平台的功能。
第二个因为JAVA编程语言特性大家都知道，Hadoop为了更好的收缩性，他分装了很多层，在编程者看来这是有必要进行简化的。第三个最重要就是JNI，Hadoop是怎么做的？压缩都是本地库，压缩方法有很多，比如Linux自带的，包括LGO，包括Google最近开源压缩库都是C++本地，只能通过JNI，因为JNI比传统高效一点，所以在Hadoop里面是通过JNI来做的。
第四点你本身的程序是独立于框架的，所以你框架是很难做影响的。这一页就给大家介绍一下现有实现的四个问题，我们怎么来解决。这是我们的目标，我们总目标基于原来框架，我们目标有两点，第一就是提升整个集群的资源利用率，第二就是附带解决开发效率的问题。提升资源利用率，如果我们想象把整个框架和用户，这幅图，如果整个框架和应用绑定起来，和用户能绑定起来，我就能做最简单的编译优化，用最简单的方式去进行实现。
第二，我们希望用C++来实现，为什么？因为我是做Hadoop出身的，所以我用Hadoop创始人那一句话有两点，因为你的MapReduce是C++密集型计算，当然你这里不是内容密集型，因为每一个tasks执行都会推出，但如果在2.0，你的tasks为了更高效不推出去接新的tasks，对于C++来说，JAVA用的久人也知道，最近JAVA最新JNI优化器优化之后，比C++性能差不了太多，原来大家认为差5倍，4倍，现在差2，3倍，当然差距还是有。选择C++的话，一方面比JAVA效能高，另外相对全面应用也有好处，第三点JAVA是虚拟机自己控制，而C++里面可以更快释放。所以，对于资源管理更好，当然这些不是我的观点。
前面回顾一下我介绍的背景，因为我们的集群在不断的扩张，而且我们集群的使用效率会有一些问题，基于这种现状，我们除了在作业召集的优化，我们还做了tasks级别的优化，我们是要解决两个问题。第一要提升资源效率，框架的资源效率，第二我们希望把框架和应用程序绑定起来，这样在优化框架同时能优化应用程序，静态的方式。具体该怎么做，我们介绍一下。MFramework Model，首先看一下整个框架中位置，第二看一下功能模型什么样子，第三实际处理模型什么样子，第四看一下接口提供哪些编程接口，最后对比一下HCE和现有的Hadoop。
Overviwe，整个HCE的位置就如红字所设，是相当于一个处理引擎。说白了实现了Hadoop里面非调度那层，因为在Hadoop里面调度是有JAVA做的，执行是有C++做的，因为调度没必要做成C++，非内存密集型。所以，你只需要关注，这样你可以把Hadoop分成两层，第一层是调度，第二层是调度，执行用C++执行，调度用JAVA。
因为附带会提供一些其他的编程语言接口，因为传统现在一些编程语言接口用的比较多，Hadoop作为用户一般是用JAVA，还有以数据仓库来做，通过多变，HCE本身是C++实现的，他最终提供是C++接口。C++大家都知道，支持其他编程语言接口非常方便。因为其他脚本语言，所有都是基于C实现的，换句话你只需要做一个最简单解释器就能实现对接，而且更高效。
他底层是基于HDCSS，尤其在国内很多系统都是用C++实现的。如果用HadoopC++实现数据库的话，C++框架直接去接C++的数据库会更高效，不然的话你JAVA想把MapReduce加在C++实现的框架上，必须要实现语言转换。所以，他对底层支持也会更好一些。整个数据通路，一般传统数据分析流程是前端WAP抓到数据之后，给到最前端的中间件，或者KV，Data，他们通过一些云传输，像开源，或者通过一些大块传输传给后台的分析系统，分析系统做一些计算，或者做一些MPI计算，这样有上层JAVA进行读取相关数据分析，反馈用户最经典就是Twitter的方式，通过简单实施流处理。
因为实施流处理不能脱离，因为有窗口概念，最终结果可能还是需要P处理来校验，这方面不多说。我们还是回到MapReduce本身，本身我们一下具体该怎么做。MapReduce阶段本身的Map阶段，首先他是有读文件，一个任务会把文件读进来，第二是做一些Map处理，相当于是去引用用户的一些方法，因为在一个Map处理里面，你用户计算的这且东西越来越大内存可能放不下。因为你每台机器可能跑8个Map，16个Map，内存放不下的时候要设置起来，有一个设置阶段。还有我先写一个临时目录，最后再提交到正式目录这么一个过程。Reduce有一些Shuffling为什么重点关注Map没有重点关注Reduce，那会我讲的时候第三页，我说过，有一个图，本身Reduce个数就比Map要少很多，一般轻量级计算少5-10倍很正常，而且Reduce的计算是很轻量级的。
所以，你用框架去优化就够了，不用对Reducetasks做额外优化。而且Reduce很大一部分是在Shuffling因为你是并行计算，多个Reduce需要知道输出结果，就需要有Shuffling，多点到多点的数据传输，在Web2.0需要其他方式实现，我通过实现Shuffling脱离，把这部分单独剥离出去，相当于有三个阶段，总的来说还是有两个阶段，Shuffling相当于有一个独立的服务，当Reduce输出外之后会通知Shuffling进程，相当于服务托管，说我算完了，Shuffling服务把他把Reduce输出结果拖到Reduce阶段，传统Reduce是要站槽位，占资源那一刹那并不能计算，把Shuffling脱离出去之后就不用占用这部分资源。
所以，HCE不解决这个问题，HCE只解决Map问题，而Shuffling的问题要留在2.0解决。看这个图一个首先会通过Map会产生多个文件，之后会进行排序，做一些设置，最后合成整个输出，把这个文件再Shuffling到其他Reduce处理节点上进行处理。HCE其实主要是解决Map端，因为Map端后面测试我们可以看到，Map端实际上占性能开销最大还是OI相关的，以及比较占CPU资源的槽，我们就需要进行独立解决。
推荐阅读
时至今日，“Big data”(大数据)时代的来临已经毋庸置疑，尤其是在电信、金融等行业，几乎已经到了“数据就是业务本身”的地步。这种趋势已经让很多相信数据之力量的企业做出改变。恰逢此时，为了让更多的人了解和使>>>详细阅读
本文标题：百度杨栋：HCE助MapReduce提升资源利用率
地址：http://www.lgo100.com/a/kandian/20120305/36929.html
网友点评
精彩导读
科技快报
品牌展示