hdfs核心概念自查
什么是block块
hdfs中所说的block块 就是hdfs中对于文件在物理上的最小分割和存储管理单位
什么是副本
为了提高数据的可靠性 hdfs中任意一个文件的任意一个block块 都可以在集群上存储多份 每一份就是一个副本;
为什么要副本
为了提高数据的可靠性;一旦一个block块不可访问(比如所在datanode宕机,或者块文件损坏 或者所在的datanode网络不可达),则还可以从另外一个datanode上读写它的另一个副本;
block块的大小可否配置
可以通过参数来配置;默认是 dfs.blocksize = 128M
同一个集群是否可以存在不同的block块大小配置
block块大小的决定参数 是属于客户端参数 每个客户端在读写数据时都可以有自己独立的配置,因此 就算是同一个集群 也可以因为不同客户端的dfs.blocksize参数配置不同,而形成不同的block块大小
什么是元数据
元数据就是hdfs文件系统中 对于各目录 文件的描述信息 如:存在哪些目录 存在哪些文件 每个文件有哪些block块 每个block块位于哪些datanode 文件的大小 文件的块大小 文件的修改时间创建时间 文件的权限….等
hdfs的元数据由namenode管理
namenode对元数据的存储有三种形式:
- 运行时内存中的元数据存储对象
- 持久化镜像文件fsimage(就是内存中对象的序列化结果)
- edits log日志文件(为了加快元数据的持久化速度而记录的对元数据会产生变更影响的客户端操作 如创建文件 增加block等 后期可以在checkpoint时通过这些操作记录来更新持久化元数据镜像文件 或在nm重启时通过这些操作记录来恢复fsimage形成后发生的元数据变更)
namenode的元数据如何保障可靠性 高可用
namenode的元数据可靠性保障有如下几种机制:
- namenode上的元数据持久化存储目录可以配置多块磁盘 从而在单机内提高元数据的安全性;
- namenode上的元数据还可以由secondary namenode进行定期checkpoint形成持久化快照 并存储在secondary namenode上 从而一旦namenode机器发生严重故障乃至所有磁盘数据丢失时,还可以从secondary namenode上拷贝持久化快照而恢复(当然 可能有一部分丢失)
- namenode还支持部署成HA模式 在HA模式下 可以由多个namenode服务 active状态的namenode可以通过”共享edits日志”的方式 将元数据同步给各个standy状态的namenode 从而实现元数据的可靠性和可用性
hdfs的HA机制能大体描述一下吗
HDFS的HA 整体来说 就是通过配置多个namenode服务来提高集群的整体可靠性和可用性;在这多个namenode之中 会有一个active状态的nn处于正常工作状态和负责对客户端进行响应;而standy状态的nn 则主要进行元数据的拉取同步 随时准备替代出现故障的active nn节点;
HA中的关键设计点之一 就是如何在active nn和standby nn之间进行元数据的同步和一致性保证;
hdfs所采取的方案 宏观上来说就是:
- active nn 把edits log写入一个共享存储系统(如 journalnode集群 或者linux NFS)
- 然后各个standby nn则从这个共享系统中读取最新的edits log 并在自己本地进行fsimage和editslog数据的checkpoint合并操作
HA中的关键设计点之二,就是集群如何感知active nn发生了故障 并如何实现standby nn切换成active状态(即failover)
hdfs所采取的方式 粗略来说就是:通过每个nn节点上 启动failover controller服务 来监控nn的状态并及时发现故障和执行failover
元数据checkpoint的流程能大体说一下吗
- Secondary namenode定时向namenode发出checkpoint请求
- namenode收到checkpoint请求时 对正在写入的edits日志文件进行滚动切换 并相应secondary namenode
- Secondary namenode从namenode的元数据目录中下载未被合并过的edits log到自己本地,然后加载上一次的快照fsimage文件和本次的新edits log文件 在内存中进行合并 然后再将合并好的内存中的元数据 写入磁盘生成新的checkpoint快照fsimage文件
- 最后 secondary namenode将本次的新fsimage快照文件上传给namenode
hdfs的读数据流程能描述吗?
- 客户端向namenode发起读数据的请求
- namenode鉴权检查 状态检查通过后 相应目标文件的元数据给客户端(主要是文件的各个block块信息)
- 客户端根据文件的block块信息 找到对应的datanode请求读取第一个block块
- datanode收到请求后 从本地存储目录中读目标块 并向客户端传输
- 客户端收完第一个块后 如果还需要继续读取 则进而请求第二个块所在的datanode 重复上面的行为
hdfs的写数据流程能描述吗
- 客户端向namenode发起写数据的请求
- namenode鉴权检查 状态检查通过后 返回3个datanode机器给客户端以供写入第一个block块的数据
- 客户端收到可用datanode信息后 向其中一台请求建立写数据的pipeline管道
- 第一个datanode收到请求后 进而请求第二个 第二个datanode收到请求后进而请求第三个 然后从第三个逐级往前进行相应 最终相应到客户端 从而建立起传输pipeline管道
- 客户端开始通过pipeline向第一个datanode传入数据包 第一个datanode收到数据包时 一边写入到自己的本地存储 一边将数据包往下一个datanode传递 直到客户端完成第一个block的所有数据的写入
- 客户端如果还有更多数据要写入目标文件 则继续请求namenode 要到第二个block的可用目标datanode节点信息 然后循环往复上述过程
- 当整个文件的数据全部写完时 客户端会通知namenode namenode从而也进行该文件的写入完成后的关闭清理等操作
