首先来了解一下HDFS的一些基本特性
HDFS设计基础与目标
- 硬件错误是常态。因此需要冗余
- 流式数据访问。即数据批量读取而非随机读写,Hadoop擅长做的是数据分析而不是事务处理
- 大规模数据集
- 简单一致性模型。为了降低系统复杂度,对文件采用一次性写多次读的逻辑设计,即是文件一经写入,关闭,就再也不能修改
- 程序采用“数据就近”原则分配节点执行
HDFS体系结构
- NameNode
- DataNode
- 事务日志
- 映像文件
- SecondaryNameNode
Namenode
- 管理文件系统的命名空间
- 记录每个文件数据块在各个Datanode上的位置和副本信息
- 协调客户端对文件的访问
- 记录命名空间内的改动或空间本身属性的改动
- Namenode使用事务日志记录HDFS元数据的变化。使用映像文件存储文件系统的命名空间,包括文件映射,文件属性等
Datanode
- 负责所在物理节点的存储管理
- 一次写入,多次读取(不修改)
- 文件由数据块组成,典型的块大小是64MB
- 数据块尽量散布道各个节点
读取数据流程
- 客户端要访问HDFS中的一个文件
- 首先从namenode获得组成这个文件的数据块位置列表
- 根据列表知道存储数据块的datanode
- 访问datanode获取数据
- Namenode并不参与数据实际传输
HDFS的可靠性
- 冗余副本策略
- 机架策略
- 心跳机制
- 安全模式
- 使用文件块的校验和 Checksum来检查文件的完整性
- 回收站
- 元数据保护
- 快照机制
我分别试验了冗余副本策略/心跳机制/安全模式/回收站。下面实验是关于冗余副本策略的。
环境:
- Namenode/Master/jobtracker: h1/192.168.221.130
- SecondaryNameNode: h1s/192.168.221.131
- 四个Datanode: h2~h4 (IP段:142~144)
为以防文件太小只有一个文件块(block/blk),我们准备一个稍微大一点的(600M)的文件,使之能分散分布到几个datanode,再停掉其中一个看有没有问题。
先来put一个文件(为了方便起见,建议将hadoop/bin追加到$Path变量后
:hadoop fs –put ~/Documents/IMMAUSWX201304
结束后,我们想查看一下文件块的情况,可以去网页上看,也可以在namenode上使用fsck命令来检查一下,关于fsck命令
:bin/hadoop fsck /user/hadoop_admin/in/bigfile -files -blocks -locations > ~/hadoopfiles/log1.txt
下面打印结果说明 个600M文件被划分为9个64M的blocks,并且被分散到我当前所有datanode上(共4个),看起来比较平均,
/user/hadoop_admin/in/bigfile/USWX201304 597639882 bytes, 9 block(s): OK Status: HEALTHY |
h1s,h2,h3,h4 四个DD全部参与,跑去h2 (142),h3(143) stop datanode, 从h4上面get,发现居然能够get回,而且初步来看,size正确,看一下上图中黄底和绿底都DEAD了,每个blk都有源可以取回,所以GET后数 据仍然是完整的,从这点看hadoop确实是强大啊,load balancing也做得很不错,数据看上去很坚强,容错性做得不错
再检查一下,我本来想测试safemode的,结果隔一会一刷,本来有几个blk只有1个livenode的,现在又被全部复制为确保每个有2个了!
hadoop_admin@h1:~/hadoop-0.20.2$ hadoop fsck /user/hadoop_admin/in/bigfile -files -blocks -locations |
我 决定再关一个datanode,结果等了好半天也没见namenode发现它死了,这是因为心跳机制,datanode每隔3秒会向namenode发送 heartbeat指令表明它的存活,但如果namenode很长时间(5~10分钟看设置)没有收到heartbeat即认为这个NODE死掉了,就会 做出BLOCK的复制操作,以保证有足够的replica来保证数据有足够的容灾/错性,现在再打印看看,发现因为只有一个live datanode,所以现在每个blk都有且只有一份
hadoop_admin@h1:~$ hadoop fsck /user/hadoop_admin/in/bigfile -files -blocks -locations
/user/hadoop_admin/in/bigfile/USWX201304 597639882 bytes, 9 block(s): Under replicated blk_-4541681964616523124_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_4347039731705448097_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_-4962604929782655181_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_2055128947154747381_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_-2280734543774885595_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_6802612391555920071_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_1890624110923458654_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_226084029380457017_1011. Target Replicas is 3 but found 1 replica(s).
Under replicated blk_-1230960090596945446_1011. Target Replicas is 3 but found 1 replica(s).
我现在把其中一个BLK从这个仅存的Datanode中移走使之corrupt,我想实验,重启一个DATANODE后,会不会复员
hadoop_admin@h4:/hadoop_run/data/current$ mv blk_4347039731705448097_1011* ~/Documents/
然 后为了不必要等8分钟DN发block report,我手动修改了h4的dfs.blockreport.intervalMsec值为30000,stop datanode,再start (另外,你应该把hadoop/bin也加入到Path变量后面,这样你可以不带全路径执行hadoop命令,结果,检测它已被损坏
hadoop_admin@h1:~$ hadoop fsck /user/hadoop_admin/in/bigfile -files -blocks -locations
/user/hadoop_admin/in/bigfile/USWX201304 597639882 bytes, 9 block(s): Under replicated blk_-4541681964616523124_1011. Target Replicas is 3 but found 1 replica(s). /user/hadoop_admin/in/bigfile/USWX201304: CORRUPT block blk_4347039731705448097 Status: CORRUPT
|
我现在启动一个DATANODE h1s(131),结果很快的在30秒之内,它就被hadoop原地满HP复活了,现在每个blk都有了两份replica
hadoop_admin@h1:~$ hadoop fsck /user/hadoop_admin/in/bigfile -files -blocks -locations
/user/hadoop_admin/in/bigfile/USWX201304 597639882 bytes, 9 block(s): Under replicated blk_-4541681964616523124_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_4347039731705448097_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_-4962604929782655181_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_2055128947154747381_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_-2280734543774885595_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_6802612391555920071_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_1890624110923458654_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_226084029380457017_1011. Target Replicas is 3 but found 2 replica(s).
Under replicated blk_-1230960090596945446_1011. Target Replicas is 3 but found 2 replica(s).
0. blk_-4541681964616523124_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
1. blk_4347039731705448097_1011 len=67108864 repl=2 [192.168.221.131:50010, 192.168.221.144:50010]
2. blk_-4962604929782655181_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
3. blk_2055128947154747381_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
4. blk_-2280734543774885595_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
5. blk_6802612391555920071_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
6. blk_1890624110923458654_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
7. blk_226084029380457017_1011 len=67108864 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
8. blk_-1230960090596945446_1011 len=60768970 repl=2 [192.168.221.144:50010, 192.168.221.131:50010]
发现这个文件被从131成功复制回了144 (h4)。
结论:HADOOP容灾太坚挺了,我现在坚信不疑了!
另外有一个没有粘出来的提示就是,h4 datanode上有不少重新format遗留下来的badLinkBlock,在重新put同一个文件的时候,hadoop将那些老旧残留的block文件全部都删除了。这说明它是具有删除无效bad block的功能的。
实验简单来讲就是
1. put 一个600M文件,分散3个replica x 9个block 共18个blocks到4个datanode
2. 我关掉了两个datanode,使得大部分的block只在一个datanode上存在,但因为9个很分散,所以文件能正确取回(靠的是checksum来计算文件值)
3. hadoop namenode很迅速的复制了仅有一个replica的block使之成为 3 replica(2) but only found 2
4. 我再关掉一个datanode,结果发现每个datanode被很均衡的分配了block,这样即使只有一个datanode,也因为之前有确保2个replicas的比率,所以依然healthy
5. 我从这个仅存的datanode中删除一个blk,namenode report这个文件corrupt,(我其实一直很希望能进safemode,结果-safemode get一直是OFF)
6. 然后我启动另外一个datanode,30秒不到,这个missing的block被从这个新启动的datanode中迅速“扩展”为2个replicas
容灾性非常可靠,如果使用至少三个rack的话,数据会非常坚挺,对HADOOP信任值 level up!
相关推荐
四、hadoop学习笔记之二:MapReduce基本编程 MapReduce编程模型包括Map阶段和Reduce阶段。Map阶段将输入数据分解为键值对,然后分发到各个节点处理;Reduce阶段则负责聚合Map阶段的结果,生成最终输出。开发者需要...
**Hadoop学习笔记详解** Hadoop是一个开源的分布式计算框架,由Apache基金会开发,主要用于处理和存储海量数据。它的核心组件包括HDFS(Hadoop Distributed File System)和MapReduce,两者构成了大数据处理的基础...
Hadoop学习笔记,自己总结的一些Hadoop学习笔记,比较简单。
Hadoop还涉及文件存储的模型,包括文件的线性切割、块的偏移量、块在集群节点中的分布存储、副本数设置以及追加数据的方式。Hadoop架构强调主从模式,即NameNode作为主节点管理元数据,DataNode作为从节点存储数据块...
Hadoop 学习笔记.md
【HADOOP学习笔记】 Hadoop是Apache基金会开发的一个开源分布式计算框架,是云计算领域的重要组成部分,尤其在大数据处理方面有着广泛的应用。本学习笔记将深入探讨Hadoop的核心组件、架构以及如何搭建云计算平台。...
首先,Hadoop的分布式文件系统(HDFS)是其核心组件之一,它具有高吞吐量的数据访问能力,非常适合大规模数据集的存储和处理。HDFS的设计是基于这样的理念:硬件故障是常态,因此它通过数据复制机制来实现高可靠性。...
云计算,hadoop,学习笔记, dd
在本篇"Hadoop学习笔记(三)"中,我们将探讨如何使用Hadoop的MapReduce框架来解决一个常见的问题——从大量数据中找出最大值。这个问题与SQL中的`SELECT MAX(NUMBER) FROM TABLE`查询相似,但在这里我们通过编程...
我学习hadoop的笔记,并在公司做的报告,给大家共享下
"Hadoop学习笔记整理" 本篇笔记对Hadoop进行了系统的介绍和总结,从大数据的基本流程到Hadoop的发展史、特性、集群整体概述、配置文件、HDFS分布式文件系统等方面都进行了详细的讲解。 一、大数据分析的基本流程 ...
HDFS简介.doc**、**Hadoop学习总结之四:Map-Reduce的过程解析.doc**、**Hadoop学习总结之五:Hadoop的运行痕迹.doc**、**Hadoop学习总结之二:HDFS读写过程解析.doc**:这些文档详细介绍了Hadoop分布式文件系统...
面对1T的数据,HDFS会将其分割成块(通常是128MB或256MB),并将这些块复制到多台机器上,通常每个块有3个副本,以确保数据的容错性和高可用性。NameNode作为主节点负责元数据管理,DataNode则实际存储数据,而...
1. 分布式文件系统(HDFS):HDFS设计用于将文件分布式存储在多台服务器上,提供了类似于传统文件系统的目录结构,可以创建、删除、修改和查看文件。与传统文件系统不同,HDFS跨越多台机器,并且文件会被切割成块并...
大数据之Hadoop学习教程+笔记合计_超详细完整.zip