HDFS
Hadoop 1.0:
- 3个组件:
- Namenode
- SecondNamenode
- Datanode
namenode(主节点,master,只有一个,单点故障的风险)中间存储信息(元数据)
2种映射关系:
- path -> blockid list 列表
- blockid 数据块 -> datanode 节点地址
元数据存在内存中
元数据进行持久化 — 磁盘fsimage — 目的:避免数据丢失
fsimage : 元数据镜像文件
只有机器重启的时候加载fsimage
元数据持久化的过程 — SNN — secondnamenode
内存 -> edit log(磁盘)-> fsimage
SNN 存在意义 : 备份 / 数据恢复
namenode和 edit log关系:
namenode需要把每一次改动都存在 edit log ,整个过程谁来推动?(Datanode和namenode之间心跳机制)
namenode除了单点问题之外,还有不适合存储太多小文件的问题,因为内存有限
datanode (slave,从节点,多个机器)
- block 数据块 -> 真实输据
多副本机制 — 默认3副本 (作用:数据冗余,高可用)
本地化原则 (就近原则):mapreduce:主(jobtracker - namenode),从(tasktracker - datanode)
可靠性保证 :
- 数据校验
目的 : 保证数据完整性 (通过crc32校验算法)
整个数据传输过程,输据需要校验几次?- client给datanode写数据:要针对写的数据,每个检查单元(512字节)
- 每一个单元创建一个单独的校验码(crc32) , 数据和校验码统一发送给Datanode
- Datanode 接受输据的时候 : 用同样的加密算法,生成校验码,并校验
- 在后台还会运行一个扫描进程:DataBlockScanner(定期校验)
- 一旦检测出现问题,通过心跳,通知NN,让NN发起DN修复 (拷贝没有问题的备份)
- client给datanode写数据:要针对写的数据,每个检查单元(512字节)
2.可靠性保证 :
- 心跳
- 多副本机制
- crc32
- SNN (secondnamenode)
- 回收站 ( .Trash 目录)
Hadoop 2.0:
-
HA 高可用 : 解决了单点故障问题
1.0里有一个SNN,但是不可靠
如何便可靠:需要两个NN,一个active,一个standby(备用)
为了保证两个NN的数据一致性,Datanode要对两个NN同时发送心跳 -
虽然Datanode同时发送心跳,但是为什么还需要JN?
2种映射关系:
path -> blockid list 列表 :JN
blockid 数据块 -> datanode 节点地址 : Datanode心跳
分工不同::: -
HDFS2.0 需要引入zookeeper , (zookeeper目的:协调分布式集群中各个节点工作有序进行,完成故障转移)
-
在2.0,引入zkfc(ZookeeperFailoverController)进程,和NN部署到同一个机器上,目的:负责自己管辖之内的NN进行健康检查
zkfc 进程会在zookeeper上注册一个临时节点
目的:监控NN,一旦NN挂掉,相对应的临时节点消失,接下来开始选主(申请锁)流程 -
JN目的:让activeNN和standbyNN保持输据同步(文件 -> block)
同步问题:需要以来JN(JournalNodes)守护进程,完成元数据的一致性 -
JN 角色有两种选择:
1) NFS — 网络系统 (network file system)
需要额外的磁盘空间
2)QJM — 最低法人管理机制 (投票)
不需要额外的磁盘空间
需要用2n+1台机器存储edit log (奇数是为了投票)
QJM本质是小集群
好处:
* 不需要空间
* 无但点问题
* 不会因为个别机器延迟,影响整体性能
* 只需要通过简单的系统配置可以实现 -
NN 和 JN 通常不再一个机器上
FC 和 NN 在同一个机器上
RM(Yarn主) 和 NN(HDFS主) 通常在同一台机器上
zookeeper 需要单独维护一套独立集群
HDFS Federation(联邦) : 水平扩展
集群中提供多个Name Node,每个NameNode负责管理一部分DataNode
每一个NN只管理自己管辖之内的DN
目的:减轻单一NN压力,将一部分文件转移到其他NN上管理
如果集群中一个目录比较大,那么可以用单独的NN维护起来
横向亏站,突破了NN的限制
不同的NN,会可以访问所有的DN吗? 会的
联邦的本质:将元数据管理NN和存储DN进行解耦
可以把联邦和高可用同时体现出来
快照:真实数据(不是元数据) ::: 数据备份/灾备/快速恢复
本质:仅仅记录block列表和大小而已,并不涉及数据本身的复制
某个目录的某一时刻的镜像
创建和恢复,都非常快 — 瞬间完成,高效
HDFS快照是一个只读的基于时间点文件系统拷贝
HDFS快照是对目录进行设定,是某个目录的某一个时刻的镜像
- 快照可以是整个文件系统的也可以是一部分
- 常用来作为数据备份,防止用户错误操作和容灾恢复
- Snapshot并不会影响HDFS的正常操作:修改会按照时间的反序记录,这样可以直接读取到最新的数据
- 快照数据是当前数据减去修改部分计算出来的
- 快照会存储在snapeshottable的目录下
快照的各种命令
hdfs dfsadmin -allowSnapshot /user/spark
hdfs dfs -createSnapshot /user/spark s0
hdfs dfs -renameSnapshot /user/spark s0 s_init
hdfs dfs -deleteSnapshot /user/spark s_init
hdfs dfsadmin -disallowSnapshot /user/spark
缓存(集中式缓存 — 不局限具体的机器的cpu和操作系统层面上的优化)
对于重复访问的文件很有用
优点:速度快
- 允许用户指定要缓存的HDFS路径
- 明确的锁定可以阻止频繁使用的数据被从内存中清除
- 集中化缓存管理对于重复访问的文件很有用
- 可以换成目录或文件,但目录是非递归的
权限控制 ACL
类似于linux系统acl
例:rwx - rwx - rwx
自己 - 组 - 其他
设置权限: setacl命令
需要开启功能:
dfs.permissions.enableddfs.namenode.acls.enabledhadoop fs -getfacl /input/aclhdfs dfs -setfacl -m user:mapred:r-- /input/aclhdfs dfs -setfacl -x user:mapred /input/acl