挺喜欢这句话：“坚持，是基于 你对某件事的热爱，才能有动力坚持下去。
在学习的过程中，需要战胜自己的惰性和骄傲！”好了，下面说下如何提升
集群的性能：
在硬件方面，第一，商业硬件并不等同于低端硬件。低端机器常常使用
便宜的零部件，其故障率远高于更昂贵的机器。当用户管理几十台、上百台
甚至几千台机器时，便宜的零部件故障率更高，导致维护成本更高；第二，
不推荐使用大型数据库级别的机器，因为性价比太低了。
在相同硬件的情况下，一个配置好的的集群要比配置糟糕的集群在性能上
快数倍乃至数十倍。
首先说下对于map/reduce槽位的配置还有job对java虚拟机的配置，一般
情况下，如果NN为8核的服务器，map的数量应该配置为6，reduce的数量为2，
也就是说，NN的槽位总数相加和等于CPU的数量，同时map槽位数大概是reduce
槽位数的三倍；因为我们需要DN的计算能力强一些，因此，在服务器相同配置
的条件下，可以把map/reduce的槽位总和设置为CPU数量的2倍，同时map数是
reduce数量的3倍。
Hadoop性能优化：Hadoop机架感知实现及配置：分布式的集群通常包含非常多的机器，由于受到机架槽位和交换机网口的限制，通常大型的分布式集群都会跨好几个机架，由多个机架上的机器共同组成一个分布式集群。机架内的机器之间的网络速度通常都会高于跨机架机器之间的网络速度，并且机架之间机器的网络通信通常受到上层交换机间网络带宽的限制。
具体到Hadoop集群，由于Hadoop的HDFS对数据文件的分布式存放是按照分块block存储，每个block会有多个副本(默认为3)，并且为了数据的安全和高效，所以Hadoop默认对3个副本的存放策略为：
1.在本地机器的hdfs目录下存储一个block ；
2.在另外一个rack的某个datanode上存储一个block ；
3.在该机器的同一个rack下的某台机器上存储最后一个block ；
这样的策略可以保证对该block所属文件的访问能够优先在本rack下找到，如果整个rack发生了异常，也可以在另外的rack上找到该block的副本。这样足够的高效，并且同时做到了数据的容错。但是，Hadoop对机架的感知并非是自适应的，亦即，Hadoop集群分辨某台slave机器是属于哪个rack并非是只能的感知的，而是需要Hadoop的管理者人为的告知Hadoop哪台机器属于哪个rack，这样在Hadoop的namenode启动初始化时，会将这些机器与rack的对应信息保存在内存中，用来作为对接下来所有的HDFS的写块操作分配datanode列表时（比如3个block对应三台datanode）的选择datanode策略，做到Hadoop
allocate block的策略：尽量将三个副本分布到不同的rack。接下来的问题就是：通过什么方式能够告知Hadoop namenode哪些slaves机器属于哪个rack？以下是配置步骤。
默认情况下，Hadoop的机架感知是没有被启用的。所以，在通常情况下，Hadoop集群的HDFS在选机器的时候，是随机选择的，也就是说，很有可能在写数据时，Hadoop将第一块数据block1写到了rack1上，然后随机的选择下将block2写入到了rack2下，此时两个rack之间产生了数据传输的流量，再接下来，在随机的情况下，又将block3重新又写回了rack1，此时，两个rack之间又产生了一次数据流量。在job处理的数据量非常的大，或者往Hadoop推送的数据量非常大的时候，这种情况会造成rack之间的网络流量成倍的上升，成为性能的瓶颈，进而影响作业的性能以至于整个集群的服务。要将Hadoop机架感知的功能启用，配置非常简单，在namenode所在机器的Hadoop-site.xml配置文件中配置一个选项：topology.script.file.name。这个配置选项的value指定为一个可执行程序，通常为一个脚本，该脚本接受一个参数，输出一个值。接受的参数通常为某台datanode机器的ip地址，而输出的值通常为该ip地址对应的datanode所在的rack，例如”/rack1”。Namenode启动时，会判断该配置选项是否为空，如果非空，则表示已经用机架感知的配置，此时namenode会根据配置寻找该脚本，并在接收到每一个datanode的heartbeat时，将该datanode的ip地址作为参数传给该脚本运行，并将得到的输出作为该datanode所属的机架，保存到内存的一个map中。至于脚本的编写，就需要将真实的网络拓朴和机架信息了解清楚后，通过该脚本能够将机器的ip地址正确的映射到相应的机架上去。一个简单的实现如下：
#!/usr/bin/perl -w
use strict;
my $ip = $ARGV[0];
my $rack_num = 3;
my @ip_items = split /\./, $ip;
my $ip_count = 0;
foreach my $i (@ip_items) {
$ip_count += $i;
}
my $rack = "/rack".($ip_count % $rack_num);
print "$rack";
写入数据
当没有配置机架信息时，所有的机器Hadoop都默认在同一个默认的机架下，名为 “/default-rack”，这种情况下，任何一台datanode机器，不管物理上是否属于同一个机架，都会被认为是在同一个机架下，此时，就很容易出现之前提到的增添机架间网络负载的情况。例如，对没有机架信息的Hadoop HDFS启动instance上传一个文件，其block信息如下：
在没有机架信息的情况下，namenode默认将所有的slaves机器全部默认为在/default-rack下，根据Hadoop代码的分析也能知道哦啊，此时在写block时，三个datanode机器的选择完全是随机的。而当配置了机架感知信息以后，Hadoop在选择三个datanode时，就会进行相应的判断：
1.如果上传本机不是一个datanode，而是一个客户端，那么就从所有slave机器中随机选择一台datanode作为第一个块的写入机器(datanode1)。而此时如果上传机器本身就是一个datanode（例如mapreduce作业中task通过DFSClient向hdfs写入数据的时候），那么就将该datanode本身作为第一个块写入机器(datanode1)。
2.随后在datanode1所属的机架以外的另外的机架上，随机的选择一台，作为第二个block的写入datanode机器(datanode2)。
3.在写第三个block前，先判断是否前两个datanode是否是在同一个机架上，如果是在同一个机架，那么就尝试在另外一个机架上选择第三个datanode作为写入机器(datanode3)。而如果datanode1和datanode2没有在同一个机架上，则在datanode2所在的机架上选择一台datanode作为datanode3。
4.得到3个datanode的列表以后，从namenode返回该列表到DFSClient之前，会在namenode端首先根据该写入客户端跟datanode列表中每个datanode之间的“距离”由近到远进行一个排序。如果此时DFS写入端不是datanode，则选择datanode列表中的第一个排在第一位。客户端根据这个顺序有近到远的进行数据块的写入。在此，判断两个datanode之间“距离”的算法就比较关键，Hadoop目前实现如下，以两个表示datanode的对象DatanodeInfo(node1,node2)为例:
a)首先根据node1和node2对象分别得出两个datanode在整个hdfs集群中所处的层次。这里的层次概念需要解释一下：每个datanode在hdfs集群中所处的层次结构字符串是这样描述的，假设hdfs的拓扑结构如下：每个datanode都会对应自己在集群中的位置和层次，如node1的位置信息为“/rack1/datanode1”,那么它所处的层次就为2，其余类推。
b)得到两个node的层次后，会沿着每个node所处的拓朴树中的位置向上查找，如“/rack1/datanode1”的上一级就是“/rack1”，此时两个节点之间的距离加1，两个node分别同上向上查找，直到找到共同的祖先节点位置，此时所得的距离数就用来代表两个节点之间的距离。所以，如上图所示，node1和node2之间的距离就为4.
5.当根据“距离”排好序的datanode节点列表返回给DFSClient以后，DFSClient便会创建Block OutputStream，并想这次block写入pipeline中的第一个节点（最近的节点）开始写入block数据。
6.写完第一个block以后，依次按照datanode列表中的次远的node进行写入，直到最后一个block写入成功，DFSClient返回成功，该block写入操作结束。
通过以上策略，namenode在选择数据块的写入datanode列表时，就充分考虑到了将block副本分散在不同机架下，并同时尽量的避免了之前描述的网络多于开销。对配置了机架信息的Hadoop HDFS启动instance上传一个文件，其block信息如下：在配置了机架信息的情况下，为了减少机架间的网络流量，namenode会将其中两个副本写在同一个机架上，并且为了尽量做到容错，会将第三个block写道另一个机架上的datanode上