hdfs1.0
HDFS 系统架构


Block:数据块,磁盘读写的基本单位
– HDFS默认数据块大小64MB
– 磁盘块一般为512B
– 原因:块增大可以减少寻址时间,降低寻址时间/文件传输时间,若寻址时间为10ms,磁盘传输速率为100MB/s,那么该比例仅为1%
– 数据块过大也不好,因为一个MapReduce通常以一个块作为输入,块过大会导致整体任务数量过小,降低作业处理速度
Block副本放置策略(机架感知策略)
• 第一个副本,在客户端相同的节点(如果客户端是集群外的一台机器,就随机算节 点,但是系统会避免挑选太满或者太忙的节点)
• 第二个副本,放在不同机架(随机选择)的节点
• 第三个副本,放在与第二个副本同机架但是不同节点上。
数据完整性校验
• 不希望在存储和处理数据时丢失或损坏任何数据
• HDFS 会对写入的数据计算校验和,并在读取数据时验证校验和
• 两种检验方法:
– 校验和
• 检测损坏数据的常用方法是在第一次进行系统时计算数据的校验和,在通道传输过程中,如果新生成的校验和不完全匹配原始的校验和,那么数据就会被认为是被损坏的。
– 数据块检测程序DataBlockScanner
• 在DataNode节点上开启一个后台线程,来定期验证存储在它上所有块,这个是防止物理介质出现损减情况而 造成的数据损坏。
容错- 可靠性措施
• 一个名字节点和多个数据节点
• 数据复制(冗余机制)
– 存放的位置(机架感知策略)
• 故障检测
– 数据节点
• 心跳包(检测是否宕机)
• 快报告(安全模式下检测)
• 数据完整性检测(校验和比较)
– 名字节点(日志文件,镜像文件)
• 空间回收机制
– Trash目录
HDFS 特点
• 能做什么
– 存储并管理PB级数据
– 处理非结构化数据
– 注重数据处理的吞吐量(延迟不敏感)
– 应用模式:write-once-read-many存取模式(无数据一致性问题)
• 不适合做
– 存储小文件(不建议)
– 大量随机读(不建议)
– 需要对文件修改(不支持)
– 多用户写入(不支持)
HDFS 写流程

HDFS读流程

NameNode
功能
• 管理着文件系统命名空间
– 维护着文件系统树及树中的所有文件和目录
• 存储元数据
– NameNode保存元信息的种类有:
• 文件名目录名及它们之间的层级关系
• 文件目录的所有者及其权限
• 每个文件块的名及文件有哪些块组成
• 元数据保存在内存中
– NameNode元信息并不包含每个块的位置信息
• 保存文件,block,datanode之间的映射关系
Hadoop更倾向存储大文件原因
一般来说,一条元信息记录会占用200byte内存空间。假设块大 小为64MB,备份数量是3 ,那么一个1GB大小的文件将占用 16*3=48个文件块。如果现在有1000个1MB大小的文件,则会占 用1000*3=3000个文件块(多个文件不能放到一个块中)。我们 可以发现,如果文件越小,存储同等大小文件所需要的元信息就越多,所以hadoop更喜欢大文件。
NameNode其它注意点
• 元信息持久化
– 在NameNode中存放元信息的文件是 fsimage。在系统运行期间 所有对元信息的操作都保存在内存中并被持久化到另一个文件 edits中。并且edits文件和fsimage文件会被 SecondaryNameNode周期性的合并
• 运行NameNode会占用大量内存和I/O资源,一般NameNode不会存储用户数据或执行MapReduce任务。
• 全Hadoop系统只有一个NameNode
– 导致单点问题
– 两种解决方案:
• 将hadoop元数据写入到本地文件系统的同时再实时同步到一个远程 挂载的网络文件系统(NFS)。
• 运行一个secondary NameNode,它的作用是与NameNode进行交 互,定期通过编辑日志文件合并命名空间镜像,当NameNode发生故 障时它会通过自己合并的命名空间镜像副本来恢复。需要注意的是 secondaryNameNode保存的状态总是滞后于NameNode,所以这 种方式难免会导致丢失部分数据(后面会详细介绍)。
DataNode
功能
• 负责存储数据块,负责为系统客户端提供数据块的读写服务
• 根据NameNode的指示进行创建、删除和复制等操作
• 心跳机制,定期报告文件块列表信息
• DataNode之间进行通信,块的副本处理
SecondNameNode



浙公网安备 33010602011771号