hadoop_NameNode_DataNode详解

gbless

　　hadoop配置文件含义解释:
　　
　　1 hdfs-site.xml 和 hdfs-default.xml 的区别：
　　

 
　　上图明确指出： hdfs的核心文件hdfs-default.xml禁止修改，如果想要自定义内容，请在hdfs-site.xml 内修改， 看单机版hadoop配置时的 hdfs-site.xml，其中对参赛fs.default.name和hadoop.tmp.dir进行了重写：

[iyunv@master conf]# cat  core-site.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!-- Put site-specific property overrides in this file. -->
<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://master:9000</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/usr/local/hadoop/tmp</value>
</property>  
</configuration>

　　NameNode详解:
　　是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。接收用户的操作请求。
(见源码)
文件包括：
fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
edits:操作日志文件。
fstime:保存最近一次checkpoint的时间
以上这些文件是保存在linux的文件系统中。
　　文件系统镜像simage ： 存在位置：/usr/local/hadoop/tmp/dfs/name/current下

[iyunv@master name]# cd current/
[iyunv@master current]# ls
edits  fsimage  fstime  VERSION


　　如果此文件丢失，则整个hdfs宕掉，其路径配置在 hdfs-default.xml内，贴出如下：

<property>
<name>dfs.name.dir</name>
<value>${hadoop.tmp.dir}/dfs/name</value>
<description>Determines where on the local filesystem the DFS name node
should store the name table(fsimage).  If this is a comma-delimited list
of directories then the name table is replicated in all of the
directories, for redundancy. </description>
</property>
在文件 core.site.xml中， hadoop.tmp.dir配置如下，
<property>
<name>hadoop.tmp.dir</name>
<value>/usr/local/hadoop/tmp</value>
</property>  

那么上述两部分(hdfs-default.xml + core-site.xml )综合得到的结果是：
dfs.name.dir保持位置为
${hadoop.tmp.dir}/dfs/name = /usr/local/hadoop/tmp/dfs/name
其中current是固定写法

　　edits: 存放用户的操作日志， 用户的操作都是一个事务，要么成功，要么失败下回滚
　　每次用户操作hdfs时，产生的edits会记录操作结果，然后根据fstime（合并时间），由secondnamenode将当次的edits日志内容更新到 fsimage中，然后edits清空。
　　上述合并操作交给 secondnamenode原因如下：
　　namonode响应用户请求，内存消耗大，如果此时在处理 edits和fsimage的合并，更加消耗内存，因为这合并工作交给 secondenamenode操作
　　合并时间fstime,  看文件 core-default.xml

<property>
<name>fs.checkpoint.period</name>
<value>3600</value> 3600秒
<description>The number of seconds between two periodic checkpoints.
</description>
</property>
<property>
<name>fs.checkpoint.size</name>
<value>67108864</value>   大约64M  看下面的解释，这个触发的优先级更高
<description>The size of the current edit log (in bytes) that triggers
a periodic checkpoint even if the fs.checkpoint.period hasn't expired.
</description>
</property>

　　Datanode详解:
　　 
　　作用:提供真实文件数据的存储服务,是一个文件管理系统，
　　你可以类比于MySQL， mysql仅仅是一个数据库管理软件，它将数据转换为mysql坑理解的格式(eg: 表-->记录-->字段)然后存储在window/linux操作系统下的物理磁盘中。
　　同样，通过客户端用户操作的文件通过hdfs处理，将文件划分成hdfs世界里的块，然后存储在linux系统管理的硬盘中。
　　hdfs文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是64MB，以一个256MB文件，共有256/64=4个Block.
　　不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。
　　针对于块的介绍引申1--Block的历史：
　　块并不是hdfs独有的概念， 这种数据基本存储单位出现在别的系统中，名词不一样而已，
　　eg: window的簇  ,Linux 为Block
　　hdfs借鉴linux的Block概念，但是又区别于linxu，Linux中Block是最小存储单元，即使物理文件没这么大，那么也要占用一个Block大小的物理空间，而在hdfs中，如果一个文件没有达到hdfs一个Block大小下，占用的是实际物理空间，而非一个Block(64M)
　　针对于块的介绍引申2---为何要划分快：
　　0 hdfs操作的文件很大， 如果原封不动的存储硬盘，并作为一个基本单位存储的话，
　　1 那么读写时都要打开此文件，加载内存耗费很大资源，读写速度自然很慢，
　　2 对这么大的文件操作时，文件独占，其余进程不能操作此文件，使用率降低
　　3 文件某块破坏，那么整个文件就废了，丢失概率为100%，而分块存储即使坏了
　　也就坏了某一块而已，丢失率远低于100%
　　针对于块的介绍引申3--64M是写死的吗？
　　1 这个64M可以修改，不是固定死的
　　其配置信息hdfs-default.xml：

<property>
<name>dfs.block.size</name>
<value>67108864</value>  64M
<description>The default block size for new files.</description>
</property>

　　针对hdfs 如果文件大于1个Block下文件大小是否占用下一整个Block的实验：

文件大小
[iyunv@master local]# ls -l
-rwxr--r--  1 root root 84927175 Jul 19 19:12 jdk-6u24-linux-i586.bin


先清空hdfs下文件
[iyunv@master local]# hadoop fs -rmr hdfs://master:9000/*  

查看此时 data/current下文件
[iyunv@master current]# ls -l
total 16
-rw-r--r-- 1 root root 674 Aug  3 06:34 dncp_block_verification.log.curr
-rw-r--r-- 1 root root 158 Jul 30 06:41 VERSION

上传文件
[iyunv@master local]# hadoop fs -put jdk-6u24-linux-i586.bin hdfs://master:9000/

再次查看
[iyunv@master current]# ls -l
total 83724
-rw-r--r-- 1 root root 17818311 Aug  3 07:10 blk_4635014670961317001
-rw-r--r-- 1 root root   139215 Aug  3 07:10 blk_4635014670961317001_1022.meta
-rw-r--r-- 1 root root 67108864 Aug  3 07:10 blk_9146814489152210513
-rw-r--r-- 1 root root   524295 Aug  3 07:10 blk_9146814489152210513_1022.meta
-rw-r--r-- 1 root root      674 Aug  3 06:34 dncp_block_verification.log.curr
-rw-r--r-- 1 root root      158 Jul 30 06:41 VERSION
[iyunv@master current]#
上传完毕后 在查看 data/current下文件详细
其中 xx.meta是校对文件， 可以看到，
排除原本就有的VERSION， dncp_block_verification.log.curr
和上传文件对应的 xx.meta校验文件后，新上传的文件jdk-6u24-linux-i586.bin（>64M, 84927175 ）
被hdfs划分为两个block, blk_9146814489152210513-->67108864字节     blk_4635014670961317001-->17818311字节
两者大小和为84927175字节

　　datanode副本(理解为家里大门钥匙，分别放在不同的地方)，默认配置写在 hdfs-default.xml中

<property>
<name>dfs.replication</name>
<value>3</value>   默认节点个数
<description>Default block replication.
The actual number of replications can be specified when the file is created.
The default is used if replication is not specified in create time.
</description>
</property>