hadoop_NameNode_DataNode详解

 

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进行了重写：

 

[root@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下

[root@master name]# cd current/
[root@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的实验：

 

 

文件大小

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




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


查看此时 data/current下文件
[root@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



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



再次查看

[root@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
[root@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>