格物致知

4.     从系统实现角度进行优化

4.1    在可移植性和性能之间进行权衡

论文[16]主要针对HDFS进行了优化，它分析了HDFS性能低下的两个原因：调度延迟和可移植性假设。

（1） 调度延迟

Hadoop采用的是动态调度算法，即：当某个tasktracker上出现空slot时，它会通过HEARBEAT（默认时间间隔为3s，当集群变大时，会适当调大）告诉jobtracker，之后jobtracker采用某种调度策略从待选task中选择一个，再通过HEARBEAT告诉tasktracker。从整个过程看，HDFS在获取下一个task之前，一直处于等待状态，这造成了资源利用率不高。此外，由于tasktracker获取新task后，其数据读取过程是完全串行化的，即：tasktracker获取task后，依次连接namenode，连接datanode并读取数据，处理数据。在此过程中，当tasktracker连接namenode和datanode时，HDFS仍在处于等待状态。

为了解决调度延迟问题，可以考虑的解决方案有：重叠I/O和CPU阶段（pipelining），task预取（task prefetching），数据预取（data prefetching）等

（2）可移植性假设

为了增加Hadoop的可移植性，它采用java语言编写，这实际上也潜在的造成了HDFS低效。Java尽管可以让Hadoop的可移植性增强，但是它屏蔽了底层文件系统，这使它没法利用一些底层的API对数据存储和读写进行优化。首先，在共享集群环境下，大量并发读写会增加随机寻道，这大大降低读写效率；另外，并发写会增加磁盘碎片，这将增加读取代价（HDFS适合文件顺序读取）。

为了解决该问题，可以考虑的解决方案有：修改tasktracker上的线程模型，现在Hadoop上的采用的模型是one thread per client，即每个client连接由一个线程处理（包括接受请求，处理请求，返回结果）；修改之后，可将线程分成两组，一组用于处理client通信（Client Thread），一组用于存取数据（Disk Threads，可采用one thread per disk）。

Read more…

1.     概述

随着企业要处理的数据量越来越大，MapReduce思想越来越受到重视。Hadoop是MapReduce的一个开源实现，由于其良好的扩展性和容错性，已得到越来越广泛的应用。Hadoop作为一个基础数据处理平台，虽然其应用价值已得到大家认可，但仍存在很多问题，以下是主要几个：

（1）     Namenode/jobtracker单点故障。 Hadoop采用的是master/slaves架构，该架构管理起来比较简单，但存在致命的单点故障和空间容量不足等缺点，这已经严重影响了Hadoop的可扩展性。

（2）     HDFS小文件问题。在HDFS中，任何block，文件或者目录在内存中均以对象的形式存储，每个对象约占150byte，如果有1000 0000个小文件，每个文件占用一个block，则namenode需要2G空间。如果存储1亿个文件，则namenode需要20G空间。这样namenode内存容量严重制约了集群的扩展。

（3）     jobtracker同时进行监控和调度，负载过大。为了解决该问题，yahoo已经开始着手设计下一代Hadoop MapReduce（见参考资料1）。他们的主要思路是将监控和调度分离，独立出一个专门的组件进行监控，而jobtracker只负责总体调度，至于局部调度，交给作业所在的client。

（4）     数据处理性能。 很多实验表明，其处理性能有很大的提升空间。Hadoop类似于数据库，可能需要专门的优化工程师根据实际的应用需要对Hadoop进行调优，有人称之为“Hadoop Performance Optimization” (HPO)。

为了提高其数据性能，很多人开始优化Hadoop。总结看来，对于Hadoop，当前主要有几个优化思路：

（1）  从应用程序角度进行优化。由于mapreduce是迭代逐行解析数据文件的，怎样在迭代的情况下，编写高效率的应用程序，是一种优化思路。

（2）  对Hadoop参数进行调优。当前hadoop系统有190多个配置参数，怎样调整这些参数，使hadoop作业运行尽可能的快，也是一种优化思路。

（3） 从系统实现角度进行优化。这种优化难度是最大的，它是从hadoop实现机制角度，发现当前Hadoop设计和实现上的缺点，然后进行源码级地修改。该方法虽难度大，但往往效果明显。

以上三种思路出发点均是提高hadoop应用程序的效率。实际上，随着社会的发展，绿色环保观念也越来越多地融入了企业，因而很多人开始研究Green Hadoop，即怎样让Hadoop完成相应数据处理任务的同时，使用最少的能源（见参考资料[14][15]）。

本文主要介绍了当前学术界的一些优化思路，有人试图从Hadoop自动配置角度对Hadoop进行优化，但更多的是从系统实现角度进行优化，概括其优化点和实验效果如下：

Read more…

2月22日，Cloudera 发布了 Cloudera’s Distribution for Apache Hadoop version 3 beta 4- CDH3b4，这个版本将是 CDH3 正式版发布前的最后一个beta版本，正式版即将公布。从官方通告来看，它归并了很多Yahoo!  贡献的代码（Hadoop 0.20.100 分支），据称减少了NameNode的内存使用，并提高了MapReduce的调度吞吐量，支持更多的RPC服务器。除此之外，其内部组件的版本也得到了相应的提升：

<property>
       <name>dfs.client.buffer.dir</name>
       <value>/tmp/hadoop/dfs/client</value>
       <final>true</final>
</property>

         估计明年主要工作都集中在P2P-CDN的仿真器上，之前做过一些调研，是关于PlanetLab的，而国内关注的人极少，只有少数一些大学的实验室有过相关的应用，而且由于Cernet作为一个整体被除名，中国的使用人数应当大减了。就实验室的项目来说，原本我以为是要设计一个P2P-CDN的混合系统，现在已经变更为设计一个P2P-CDN的模拟器，所以PlanetLab是不可能得到应用，不过这里的一些信息可能对需要它的人有用。

—————–华丽丽的分割线———————

         PlanetLab是一个全球性的研究网络，用于新型网络服务的开发。自从2003年起，超过1,000个来自顶级学术机构和业界实验室在PlanetLab上开发了新技术包括：分布式存储、网络印射、P2P系统、DHT（分布式哈希表）和查询处理。并且值得关注的是在这个平台上，P2P分布式计算的项目很多，甚至是基于P2P的CDN实现和部署。

 http://www.planet-lab.org/

         截止至2009年12月，PlanetLab目前拥有1063个节点和491个站点，很多世界一流大学和行业研究实验室成为PlanetLab计划的联盟成员，其中包括AT&T实验室、剑桥大学、法国电信、HP、Google、NEC实验室、哈佛大学、普林斯顿大学和加州大学伯克利分校连同中国华为集团、以及Internet2机构。2009年5月，PlanetLab中心升级至4.3版本，可以支持新的节点类型（如无线节点），同时加入一些新的GUI特性。

          PlanetLab的主要目标之一是用作重叠网络的一个测试床。研究组能够请求一个PlanetLab分片，其中他们能够试验各种全球规模的服务，包括文件共享和网络内置存储、内容分发网络、路由和组播重叠网、QoS重叠网、可扩展的对象定位、可扩展的事件传播、异常检测机制和网络测量工具。目前有数百个活跃的研究项目运行于PlanetLab之上。

         对研究人员而言使用PlanetLab的好处是：可以在真实世界条件下大规模试验新服务，因为节点广泛分布于Internet，是一个由遍布世界各地的服务器组成的网络，能够观察并对网络行为做出反应；从位于许多数据源和数据终点的邻近范围而受益；从分布于多个管理的边界而受益。

         PlanetLab是一个大规模互联网服务的测试床，在其上更多的狭窄定义的虚拟测试床能够被部署）。网络研究人员能够使用这项基础设施来试验对于Internet协议簇的修改和扩展。除了支持短期试验外，PlanetLab也设计用来支持长期运行的服务，这些服务支持一个用户基础（用户群）。即PlanetLab不但是一个测试床，也是一个部署平台，支持一个应用的无缝迁移，从早期原型，通过多次设计迭代，最后转变为一项持续演进的成熟服务。

          2004 年12月27日中国教育和科研计算机网(CERNET)宣布，CERNET已加入PlanetLab，首先在中国20个城市的25所大学( 包括清华，北大，北航，北邮 )中设立50个 PlanetLab节点，这使得CERNET成为亚洲第一个地区性PlanetLab研究中心，但是在2009年6月1日，PlanetLab重新考虑了CERNET地位，指出PlanetLab接受的成员是研究机构/大学，而不是“国家组织”如CERNET，因此要求所有CERNET地址的中国大学重新申请为独立成员。个人不能直接参与到PlanetLab中，必须是PlanetLab的成员。截止到写这篇文章为止，国内也仅有少数的大学通过审批，更多的则是处于pending状态，更多被除名的大学则没有重新提交过申请。

          建立在PlanetLab之上的一些成功案例，在这里主要是针对P2P-CDN系统来说明的：

CoralCDN

基于P2P的CDN网络：www.coralcdn.org/

CoralCDN是一个免费的P2P内容分发网络，由世界范围内的web代理和域名服务器组成，它允许用户在之上建立一个高性能大需求的web网站。它于2004年的3月，在PlanetLab上进行测试。可以免费地下载CoralCDN的源代码，源代码是由C++完成的，超过一万行。

CoDeeN：A Content Distribution Network for PlanetLab

主页：http://codeen.cs.princeton.edu/

CoDeeN是由普林斯顿大学开发的学术性的CDN网络实验平台，且这个CDN网络由众多的PlanetLab节点组成，当前很多缓存服务器部署在PlanetLab的节点之上，这些缓存服务器同时作为request redirectors和server surrogates，它们相互合作提供了一个快速而健壮的web内容分发服务。

同时，它还包括以下的子项目：

• CoBlitz, a scalable Web-based distribution service for large files.
• CoDeploy, an efficient synchronization tool for PlanetLab slices.
• CoDNS, a fast and reliable name lookup service.
• CoTop, a command-line activity monitoring tool for PlanetLab.
• CoMon, a Web-based general node/slice monitor that monitors most PlanetLab nodes.
• CoVisualize, a visualization tool graphically displaying PlanetLab activity.

最后，特别推荐一篇文章：http://ww2.cs.mu.oz.au/~apathan/CDNs.html，具体描述了CDN技术的前沿方向。