[Hadoop培训笔记]04-HDFS详细分析（一）

最新推荐文章于 2022-02-11 11:45:43 发布

Babyfacer

最新推荐文章于 2022-02-11 11:45:43 发布

阅读量4.7k

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/babyfacer/article/details/17551615

Big Data 专栏收录该内容

9 篇文章

订阅专栏

本文介绍了Hadoop集群搭建过程中的常见问题及解决方案，包括HDFS集群搭建、配置优化、小文件处理策略等内容。探讨了NameNode和DataNode的异常排查方法，并分析了HDFS的架构特点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

注：开源力量Hadoop Development网络培训个人笔记，培训链接：http://new.osforce.cn/course/52

Q&A：

1）搭建HDFS集群的时候，NameNode和DataNode这两个进程会挂掉？
      查看Log，查看相关的异常信息。
      a、如果namenode没有正常启动，原因是在启动之前没有格式化。我们需要format
      b、如果datanode没有正常启动，或启动后又关闭，原因是namespace ID不一样
      正确的步骤是：
      a、rm -rf 本地的存储目录（/tmp/hadoop-<user_name>）
      b、hadoop namenode -format
      c、执行脚本 start-dfs.sh

2）dfsadmin -setQuota的问题
dfsadmin -setQuota 限制文件数量
dfsadmin -setSpaceQuota 限制磁盘空间

3）什么样的文件算是小文件？在哪里配置？
数据块的默认大小是64M，如果一个文件的大小小于64M，那么它也要占据一个数据块的大小。这样会浪费空间，所以要使用archive的方式来实现归并小文件。
数据块的大小可以使用dfs.block.size这个属性进行配置

4）start-dfs.sh的告警信息
     unable to load native-hadoop library for your platform...
     using built-in java classes
     没有找到native库，使用内置的java code

5）重复运行wordcount，提示output目录存在
可以使用命令行或者HDFS API直接删除，或修改源代码，增加强制的目录替换功能

6）默认的hadoop conf路径变成了etc/hadoop
调用start-dfs.sh之前，它会source一下hadoop-config.sh，然后再去执行hadoop-daemon.sh，接下来执行hadoop脚本，执行java程序

HDFS详细分析（一）

1、HDFS架构
     FastDFS，MooseFS，以文件为基本存储单位：
       -- 难以并行化处理（一个节点只能处理一个文件，无法同时处理一个文件）；
       -- 难以实现负载均衡（文件大小不同，无法实现负载均衡，用户需要自己控制文件大小）
     HDFS优点：
       -- 适合大数据处理（支持GB，TB，PB级别的数据存储，支持百万规模以上的文件数量）
       -- 适合批处理（支持离线的批量数据处理，支持高吞吐率）
       -- 高容错性（以数据块存储，可以保存多个副本，容易实现负载均衡）
     HDFS缺点：
       -- 小文件存取（占用namenode大量内存，浪费磁盘空间）
       -- 不支持并发写入（同一时刻只能有一个进程写入，不支持随机修改）

看HDFS源代码前，导入至eclipse中，出现javax.servlet, javax.servlet.jsp, ant三个需要寻找jar文件才能解析。我从网上下载了加进去。不过觉得eclipse既然知道ant目录，为何不能定位不清楚。暂时没时间解决，就没追究了。

首先分析的是 org.apache.hadoop.hdfs/DistributedFileSystem.java，open(Path, int)方法，NameNode.java等

2、SecondaryNamenode
      1）不是NameNode的备份
      2）周期性合并fsimage和editslog，并推送给NameNode
      3）辅助恢复NameNode
      4）SecondaryNameNode的作用现在可以被两个节点替换，checkpoint node与backup node

配置core-sites.xml

<configuration>
  <property>
    <name>fs.default.name</name>
    <value>hdfs://192.168.56.101:9100</value>
  </property>


<property>
<name>fs.checkpoint.period</name>
<value>30</value>
<description>The number of seconds between two periodic checkpoints.</description>
</property>

<!-- <property>
<name>fs.checkpoint.size</name>
<value>67108864</value>
<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> -->

<property>
<name>fs.checkpoint.dir</name>
<value>/tmp/hadoop/secondarynamenode</value>
<description>Determines where on the local filesystem the DFS secondary name node
should store the temporary images to merge. If this is a comma-delimited list of
directories then the image is replicated in all of the directories for redundancy.</description>
</property>


</configuration>

namenode格式化，执行start-dfs.sh后，在相应目录能看到fsimage等相关文件的存在，如下所示：

xwchen@ubuntu:/tmp/hadoop/secondarynamenode$ tree
├── current
│   ├── edits
│   ├── fsimage
│   ├── fstime
│   └── VERSION
├── image
│   └── fsimage
└── in_use.lock

xwchen@ubuntu:/tmp/hadoop-xwchen/dfs/namesecondary$ tree
.
├── current
│   ├── edits
│   └── fsimage
├── image
│   └── fsimage
└── lastcheckpoint.tmp
    ├── edits
    ├── fsimage
    ├── fstime
    └── VERSION

查看VERSION（保存了HDFS的版本号）信息，有类似如下信息：

namespaceID=1852621341    //是文件系统的唯一标识，是在文件系统初次格式化时生成的
cTime=0    //此处为0
storageType=NAME_NODE    //表示此文件夹中保存的是元数据节点的数据结构
layoutVersion=-41   //是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号

checkpoint node与secondary namenode的作用及配置完全相同
启动命令 bin/hdfs namenode -checkpoint
这是hadoop 2.0.3的命令，对应 hadoop 1.2.1中的 bin/hadoop namenode ，但1.2.1不存在checkopint参数。参看下面命令对比：

xwchen@ubuntu:~/hadoop/hadoop-1.2.1/bin$ ./hadoop namenode --help
Usage: java NameNode [-format [-force ] [-nonInteractive]] | [-upgrade] | [-rollback] | [-finalize] | [-importCheckpoint] | [-recover [ -force ] ]

xwchen@ubuntu:~/hadoop/hadoop-2.0.3-alpha/bin$ ./hdfs namenode --help
Usage: java NameNode [-backup] | [-checkpoint] | [-format [-clusterid cid ] [-force] [-nonInteractive] ] | [-upgrade] | [-rollback] | [-finalize] | [-importCheckpoint] | [-initializeSharedEdits] | [-bootstrapStandby] | [-recover [ -force ] ]

Backup Node
1）提供了一个真正意义上的备用节点
2）Backup Node在内存中维护了一份从Namenode同步过来的fsimage，同时它还从namenode接收edits文件的日志流，并把它们持久化硬盘
3）Backup Node在内存中维护和NameNode一样的Metadata数据
4）启动命令bin/hdfs namenode -backup

测试（hadoop 1.2.1）：

./hadoop fs -put a.txt /       //put some files in namenode
./haddop fs -put hadoop /      //same as above
./hadoop fs -lsr               //check if put successful
jps                            //check namenode process id
kill -9 8026                   //kill namenode process
rm -rf /tmp/hadoop-xwchen/dfs/name/*    //delete namenode info
cd /tmp/hadoop/secondarynamenode/       //plan to use secondary namenode to recover
rm -rf in_use.lock             //delete lock file to use the backup image

xwchen@ubuntu:/tmp/hadoop/secondarynamenode$ tree    //check edits and fsimage files are available
.
├── current
│   ├── edits
│   ├── fsimage
│   ├── fstime
│   └── VERSION
└── image
    └── fsimage


xwchen@ubuntu:~/hadoop/hadoop-1.2.1/bin$ ./hadoop namenode -importCheckpoint    //import check point

./hadoop-daemon.sh start namenode    //restart namenode after recover data from check point
./hadoop fsck /    //check if healthly
./hadoop fs -lsr /

hdfs-site.xml: dfs.backup.address, dfs.backup.http.address
core-site.xml: fs.checkpoint.period, fs.checkopint.size, fscheckpoint.dir, fs.checkpoint.edits.dir

3、HDFS副本放置策略

机架感知：
大型Hadoop集群是以机架的形式来组织的，同一个机架上不同节点间的网络状况比不同机架之间的更为理想。另外NameNode设法将数据块副本保存在不同的机架上以提高容错性。

说明：
1）当没有配置机架信息时，所有的机器Hadoop都默认在同一个默认的机架下，名为“/default-rack”，这种情况下，任何一台datanode机器，不管物理上是否属于同一个机架，都会被认为时在同一个机架下。
2）一旦配置topology.script.file.name，就按照网络拓扑结构来寻找datanode。topology.script.file.name这个配置选项的value指定为一个可执行程序，通常为一个脚本。

源代码在org.apache.hadoop.net中