HDFS是什么?

HDFS：分布式文件系统

• 本质：将多台机器的文件系统在逻辑上进行合并，构建了一个整体统一的入口，最终真正存储数据的还是每一台Linux机器
• 理解：HDFS就是专门帮别人存储的公司，这个公司由很多个仓库组成，每个仓库【Linux文件系统】分配了一个员工【DataNode】
  • 如果你有一个大的存储任务，提交给了HDFS这个公司
  • HDFS这个公司会把大的存储拆分成若干个小的存储
  • 交给每个员工存入每个员工对应的仓库
• 你也可以想象：HDFS = 菜鸟物流：自己做不做物流？不做
  • 菜鸟物流是将多家物流公司统一了业务
  • 申通、韵达…….

HDFS功能以及应用场景

HDFS ：分布式文件系统提供分布式的读写任务

• 写：将大文件分块，存储在每台DataNode上，存储元数据
• 读：根据元数据获取这个文件的所有块，合并返回

应用场景

• 适合于离线的大量数据并且修改业务比较少的场景
• 不适合于
  • 读写比较快
  • 频繁修改
  • 小数据量：不适合存储小文件，会导致HDFS的读写性能非常差
    • 小文件越多，表示元数据的记录就越多，索引就越慢

特点

• 分块：将大文件拆分
• 副本：每个块进行备份存储

HDFS主从节点的功能

• 主：NameNode
  • 接客：接受所有客户端的读写请求
  • 管理：管理所有从节点的死活
    • 管理所有DataNode的状态：心跳机制
    • 管理数据的安全：汇报机制
    • 维护内存元数据
  • 理解：整个公司的领导
• 从：DataNode：每台存储的机器上的进程
  • 用于管理每台机器上的数据的读写
  • 理解：每个仓库的管理员

HDFS中的重要端口

• HDFS:NameNode
  • 8020:rpc协议端口,用于内部通信和任务提交
  • 50070:http协议端口,用于网页的访问

HDFS写流程

HDFS读流程

HDFS的数据安全

• 数据安全
  • 副本机制
  • 安全模式
• 元数据安全
  • 内存元数据：NameNode启动时读取了fsimage加载到内存中
    • 后期数据的增删改查修改的都是内存元数据【最快】
  • 文件元数据：fsimage：格式化的时候产生的
  • 问题：内存元数据与文件元数据不一致
  • 解决：
  • 元数据更改日志：edits
  • NameNode启动就需要将edits文件与fsimage进行合并，得到最新的元数据
  • | 机器不停机的，假设过了一年
  • | edits存储了一年的元数据变化，fsimage还是一年之前的元数据
  • |
  • 这样做不合适，容易出问题，性能非常差
  • |
  • SecondaryNameNode：负责定期将edits文件与fsimage文件合并，生成最新的fsimage
    • 条件1：达到一定时间就合并一次
    • 条件2：edits文件达到一定大小合并一次
    • 两个条件满足其一，就触发一次合并

Hadoop的HA【HDFS的HA】

什么叫HA，解决什么问题？

• 单点问题：主服务进程只有一个，一旦故障整个集群不可用
  • Hadoop1：存在单点故障无法解决
  • Hadoop2：HA，2个NameNode以及2个ResourceManager
  • Hadoop3：HA，多个主节点
• 怎么解决
  • 两个NameNode或者两个ResourceManager
  • 一个是active的工作状态
  • 一个是standby的备份状态
  • 如果active故障，standby自动切换为active状态，接替原来的工作

问题1：两个NameNode，如何决定谁是active，谁是standby？

zookeeper专门帮其他的分布式框架解决问题

• 1-数据一致性的问题
• 2-选举
  • 方案一：所有的主节点，共同创建同一个临时节点file，谁创建成功谁就是active，另外一个作为standby，并且设置对file的监听，一旦active创建的file消失，说明active故障，其他的所有standby的节点再次选举，去创建临时节点
  • 方案二：所有的主节点，共同创建同一个临时序列节点，谁的编号最小，谁就是active
• ZKFC：zookeeper failover controler
  • 这是Hadoop的进程，用于辅助NameNode连接Zookeeper，相当于中介
  • 每一个 NameNode都会有这样的一个进程
    • 监听NameNode
    • 帮助NameNode进行选举和监听active
• 为什么不让NameNode自己去做呢？
  • Hadoop中：YARN中ResourceManager是自己向Zookeeper中进行注册以及选举的
  • NameNode必须依靠ZKFC实现选举​
  • HDFS的源码修改起来非常的麻烦，由Hadoop1发展而来，根本没有这样的接口
    • 无法直接基于源码进行修改，添加了额外的一个进程来实现
  • YARN是Hadoop2才引入的，YARN在设计的时候就考虑到了这个问题，源码中直接就实现了这个功能

问题2：有了两个NameNode，客户端怎么请求？

客户端是无法知道谁是active，谁是standby的，必须请求active

• 解决：将所有的NameNode构建成一个整体：nameservice
• 所有的客户端直接请求这个整体，在整体内部，转发这个请求给active
• 问题：我在用HA模式测试JavaAPI的时候，访问不到hdfs

conf.set("fs.defaultFS","hdfs://mycluster")

• 客户端知不知道没有cluster对应的 是什么？
  • 不知道
• 怎么能让客户端知道这是HA结构
  • 方案一：一定要将core-site.xml和hdfs-site.xml放入程序的resources目录中
  • 方案二：将HA所有的配置写入conf对象

问题3：有两个NameNode，DataNode向谁注册？

• DataNode要向所有的NameNode注册
• 但是只有active的NameNode会管理DataNode

问题4：如果active的NN故障，standby的NN要接替它的工作，如何保证这两个NN之间的元数据是一致的？

• 提供一致性的服务保证：这两个NN的元数据一模一样才能完美的替代
• 解决：journalnode【就是一个小的分布式文件系统，对存储没有限制】
  • Hadoop自带的日志存储节点，设计有点类似于Zookeeper
  • active的NN将自己元数据的变化日志edits文件，存储在journalnode中
  • standby的NN从journalnode中获取元数据的变化，并同步
• Standby状态的 NameNode
  • 实现与active的NameNode的元数据同步
  • 实现SecondaryNameNode的功能
  • 将edits文件与自己的fsimage合并，生成最新的fsimage
  • 并且会将这个fsimage发送给active的NameNode
• 理论上来说，可以通过zookeeper来保证一致性的服务
  • Hadoop没有这么做，edits文件非常大，zookeeper单个节点最多存储1M
    • 不能满足
  • 如果利用zookeeper来存储，会导致Hadoop高度依赖zookeeper
    • 如果zookeeper有问题，Hadoop会有很大的问题