Hadoop优化学习

看了几篇文章，记录下：

 

Hadoop是基于hdfs分布式文件系统的，它体现的是一种“分而治之”的思想，将一个任务进行切割，分散到不同的slave 机器上面去做。

它有一个 master 的概念，负责 Namenode的工作，也有可能负责 JobTracker 的工作，它是分布式文件系统的管理者，负责命名空间，集群的配置，跟着slave 的启动和调度，负责存储检索 DataNode的 block 信息，它将文件系统的 Meta-data 信息存储在内存中。

dataNode  文件存储单元，它将自身的block信息同步给 Namenode。

 

secondNamenode 可以理解为 namenode 的备机，它通过 FSImage 和  edit  日志来做系统恢复，减少系统损失，类似 DB 的日志检查点功能 恢复系统。Namenode 重启的消耗 这是一个主要点，还有一个就是 同步dataNode 的block 信息，这个应该是 最耗时的，因为在分布式集群中这种block 的信息是巨大的，同步这类数据当然也是需要花费很长时间。类似 oracle 系统的日志redo 功能。根据网上其它同学的测试数据证实也是这样。

 

关于Hadoop 的性能优化：

一：Hadoop 的文件写入和检索，为了保障系统数据的安全性，默认系统是存储三分数据的，并将其中两份存在 一个机架，另外一份存储在另外一个机架。而系统默认是所有slave 是在一个rack 下的。而不同机架之间的速率传输是比同机架慢的，按照这个原理，在配置机器的写入存储的时需要考虑这个性能点的。否则会引起网络crack 之间的网络流量的串升，并影响到整体的性能。

 

在namenode所在机器的hadoop-site.xml配置文件中配置一个选项：
<property>
  <name>topology.script.file.name</name>
  <value>/path/to/script</value> #这里是个脚本，指定  rack 的计算规则
</property>

 

二：选用合适的 Writeable，比如 int  和  String的 转换是需要耗费性能的，所以要尽量的避免多余的此类操作。

三：block 快大小的设置对于性能的影响也是很明显的。快太小，会导致 Namenode 维护的block 信息巨大。小task 的切换也是开销，太大会导致空间浪费。

      针对很多小文件的应用，这个时候的可以考虑将文件以key-value 的形式组织，key是文件名，value是文件内容。然后组成一个 SequenceFile，提升系统的使用率。

 

主要参考 ：http://blog.csdn.net/AE86_FC