看了几篇文章,记录下:
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