HDFS

hdfs基础知识，包括hdfs1.0和hdfs2.0的主要架构知识点，可以作为入门参考。

HDFS

• HDFS2.0
  • NameNode HA（高可用）
    • 解决 1.0 中只有一个NameNode，存在的单点故障
    • HDFS2.0 有两个NameNode
      • active NameNode
      • standby NameNode
    • 实现HA的关键问题
      • 1. NN的状态同步
        • 通过JournalNodes 共享存储（edit logs），完成元数据的一致性
        • DN 同时向两个NN 发送心跳，数据块报告
      • 2. 防止脑裂
        • JN 只接收一个NN 的写入（序号递增实现）
        • DN 只接受一个NN 的命令（序号递增实现）
      • 3. NN切换过程，客户端的连接不能断
        • 只有一个NN能响应客户端，RPC层封装一层， 重试机制连接NN，若干次失败后连接新的NN
    • ZKFC的设计（图中蓝色部分）
      • zookeeper功能 ：
        • 选主，完成故障转移
      • FailoverController功能：
        • 1. 监控NN的健康状态
        • 2. 向ZK定期发送心跳，使自己可以被选举。
        • 3. 当自己被ZK选为主时，通过RPC调用使相应的NN转换为active。
      • FC为什么要从NN分离出来
        • 使得主备选举成为可插拔式的插件
        • 也是功能性代码和应用分离的体现
      • 注：FC作为一个deamon守护进程，和NN部署在同一个机器上
    • NameNode之间共享数据
      • NFS（共享文件系统）
      • QJM（Quorum Journal Node） （最低法定人数管理机制） （用得多，这里作为主讲）
        • Active可以把editlog日志写到JN上，Standby只能从JN读取。
        • 每个写入的editlog有一个编号Epoch，JN会对比这个编号， 比自己保存的Epoch大或相同，则可以写，并更新Epoch到最新； Standby转换为Active时，会把Epoch+1，这样就防止之前的NN向JN写日志
        • 有2n+1台JN存储edit log，每次写操作只要其中 大多数JN返回成功（≥N+1）即认定写成功。 保证高可用；不会因为个别机器延迟，影响整体性能。 注：其细节基于Paxos（基于消息传递的一致性算法），这里不详述
    • 节点分配
      • Active NN和Standby NN的机器需要相同的硬件配置
      • FC和NN在同一台机器上
      • JN 进程相对来说比较轻量，可以同其他进程运行在同一台机器上
        • 集群中，最少要运行3个JN
      • NN和JN通常不在一台机器上
      • zookeeper通常是单独维护的一套独立集群
    • Standby NN
      • Standby定期从JN读取一批editlog，与active同步
      • 也执行namespace状态的checkpoints， 所以不需要（也不能）运行Secondary NN、 CheckpointNode和BackupNode这些守护进程
  • NameNode Federation（联盟架构）
    • 单个NameNode的局限性
      • Namespace（命名空间）的限制
        • 受单个机器内存限制，无法应对数据的飞速增长
        • namenode元数据信息，限制了集群中数据块，文件和目录的数目
      • 性能的瓶颈
        • 整个HDFS文件系统的性能受限于单个NameNode的吞吐量
      • 隔离问题
        • 某个用户提交的负载很大的job会减慢其他用户的job
    • 联盟架构设计
      • 为了水平扩展Namenode，Federation使用了多个 独立的Namenode/NameSpace，他们之间相互独立 且不需要互相协调，各自分工，管理自己的区域
      • 每个DataNode要向集群中所有的namenode注册， 且周期性的向所有namenode发送心跳和块报告， 并执行来自所有namenode的命令
    • Block Pool（块池）
      • 定义
        • 属于单个命名空间的一组block（块）
        • Block Pool是一个重新将block划分的逻辑概念， 而 DataNode是在物理上划分block
      • 特点与作用（略）
    • 联盟的优点
      • 实现NameNode的横向扩展,使得Hadoop集群的规模可以达到上万台
  • HDFS 快照
    • 概述
      • 快照是HDFS文件系统的只读的基于某时间点的镜像； 可以针对某个目录，或者整个文件系统做快照； 快照比较常见的应用场景是数据备份，防止用户错误操作和容灾恢复。
    • 快照实现
      • 快照文件只保存被快照目录的修改信息 （block块并不会被拷贝）
    • HDFS 快照特点
      • 快照的创建是瞬间的，代价为O(1)，取决于子节点扫描文件目录的时间。
      • 当且仅当做快照的文件目录下有文件更新时才会占用小部分内存， 占用内存的大小为O(M)，其中M为更改文件或者目录的数量；
      • 创建快照以后发生的修改操作，被按时间的倒序记录下来
      • 快照不会影响正常的HDFS操作
        • 当前的数据可以被直接获取
        • 快照数据是当前数据减去修改的部分计算出来的。
      • 注意：mv命令和del命令是不允许的，因为快照是只读的
    • 快照目录约束
      • 可以在任何被设置为snapshottable的目录上执行快照 （就是需要开启目录的快照功能，一般管理员才有权限）
      • 对一个目录最多可以创建65536个快照
      • 不允许嵌套
        • 也就是说，如果一个目录被设置为snapshottable， 那么它的父目录和子目录都不允许被设置为snapshottable。
      • 快照被存放在一个被命名为 ".snapshot" 的目录中
        • 例子：
          • 1. /demo/data 目录下启用快照
            • [root@hadoop2 hadoop]# hdfs dfsadmin -allowSnapshot /demo/data Allowing snapshot on /demo/data succeeded
          • 2. 创建快照
            • [root@hadoop2 hadoop]# hdfs dfs -createSnapshot /demo/data s0 Created snapshot /demo/data/.snapshot/s0
          • 3. 查看快照
            • ]# hdfs dfs -ls /demo/data/.snapshot/s0
    • 基本语法
      • 1. hdfs dfsadmin -allowSnapshot 路径
        • （开启指定目录的快照功能）
      • 2. hdfs dfsadmin -disallowSnapshot 路径
        • （禁用指定目录的快照功能，默认是禁用）
      • 3. hdfs dfs -createSnapshot 路径 名称
        • （创建快照，名称非必须，默认名是时间戳）
      • 4. hdfs dfs -renameSnapshot 路径 旧名称 新名称
        • （重命名快照）
      • 5. hdfs lsSnapshottableDir
        • （列出当前用户所有可快照目录）
      • 6. hdfs snapshotDiff 路径1 路径2
        • （比较两个快照目录的不同之处）
  • HDFS 缓存
    • 概述
      • 允许用户指定要缓存的HDFS路径
    • 优点：访问速度快
      • 明确的锁定可以阻止频繁使用的数据被从内存中清除
      • 集中化缓存管理对于重复访问的文件很有用
    • 注意点
      • 可以是目录或文件，但目录是非递归的（仅包含该目录下的文件，不包含子目录）
      • 这些DataNode的缓存也是由NameNode所管理
  • HDFS ACL（权限控制）
    • Hadoop从2.4.0开始支持
    • 目前HDFS的权限控制与Linux一致，包括用户、用户组、其他用户组三类权限
    • 首先参数上要开启基本权限和访问控制列表功能
      • dfs.permissions.enabled dfs.namenode.acls.enabled
    • 常用命令
      • hadoop fs -getfacl /input/acl hdfs dfs -setfacl -m user:mapred:r-- /input/acl hdfs dfs -setfacl -x user:mapred /input/acl
  • 异构层级存储结构
    • Hadoop在2.6.0版本中引入的新特性
    • 一个集群中，有多种不同的存储介质，比如有SSD、普通Disk磁盘、RAM等
    • 不同的任务对数据访问速度要求不一样，于是通过相应配置， 控制目录和文件写到什么样的介质上去，并且具备配额控制要求
    • 适用的场景如：冷热数据的存储
  • 集群搭建
    • 同时部署NameNode HA和NameNode Federation时， 集群结构会相对复杂一点
      • 生成环境中，NameNode HA几乎是必备
      • 集群规模在1000台以下时，几乎是不需要NameNode Federation
    • 搭建步骤...(待补充)
• HDFS1.0
  • 系统架构
    • 3个组件
      • Namenode
        • 功能
          • 1. 管理着文件系统命名空间
            • 维护着文件系统树及树中的所有文件和目录
          • 2. 存储元数据
            • NameNode保存元信息的种类有：
              • 文件名目录名及它们之间的层级关系
              • 文件目录的所有者及其权限
              • 每个文件块的名及文件有哪些块组成
            • 元数据保存在内存中
              • 有两种映射关系
                • 1.文件名到block
                • 2.block 到datanode
              • 注：NameNode元信息并不包含每个块的位置信息，只标识在哪些dataNode
        • 元信息持久化
          • 存放元信息的文件是 fsimage （镜像）
          • 对元信息的操作持久化到edits
          • nedits文件和fsimage文件会被SecondaryNameNode周期性的合并
        • Hadoop更倾向存储大文件原因
          • 文件越小，存储同等大小文件所需要的元信息就越多
          • 元信息太多占用 Namenode 内存，增加负担
          • 注：文件的物理存储是按照 64M /每个物理块， 多个小文件也是存储在一起，只是逻辑层面是多个块
        • 其他点
          • 运行会占用大量内存和I/O资源，一般NameNode不会有其他任务
          • hdfs1.0 中 Namenode 有单点问题
            • 不完全解决方案
              • 将hadoop元数据写入到本地文件系统的同时 再实时同步到一个远程挂载的网络文件系统（NFS） 【异地容灾】
              • 运行一个secondary NameNode
      • SecondNamenode
        • 并不是NameNode的备份
        • 它是为了考虑持久化到磁盘
        • 两个文件
          • fsimage
            • 它是在NameNode启动时对整个文件系统的快照
          • edit logs
            • 它是在NameNode启动后，对文件系统的改动序列
        • 解决的问题
          • NameNode启动时，edit logs才会合并到fsimage文件中， 当NN运行了很长时间后，edit logs文件会变得很大，重启很耗时； secondary NameNode作用就是定期从edits logs读取并合并到 fsimage； 减少NN重启时间
      • DataNode
        • 功能
          • 1. 负责存储数据块，负责为系统客户端提供数据块的读写服务
          • 2. 根据NameNode的指示进行创建、删除和复制等操作
          • 3. 心跳机制，定期报告文件块列表信息
          • 4. DataNode之间进行通信，块的副本处理
        • 数据块--磁盘读写的基本单位
          • HDFS默认数据块大小64MB
          • 磁盘块一般为512B（4096B） --物理的磁盘块
            • 块增大可以减少寻址时间
            • 过大会导致整体任务数量过小，降低作业处理速度 即：任务层面不利于并行计算
      • 注：Namenode、SecondNamenode 在一台物理机
    • 其他概念
      • Rack 机架
      • client 客户端
  • 机架感知策略
    • 就是Block副本放置策略
      • 第一个副本，在客户端相同的节点
        • 如果客户端是集群外的一台机器，就随机算节点， 但是系统会避免挑选太满或者太忙的节点
      • 第二个副本，放在不同机架（随机选择）的节点
      • 第三个副本，放在与第二个副本同机架但是不同节点上
        • 同机架传输比跨机架快
    • block 距离
      • 机房 > 机架> 物理机结点
  • 数据完整性校验
    • 计算校验和
      • HDFS会在写入、读取时验证校验和
        • 收到客户端的数据
        • 其他副本传过来的数据
        • 客户端从datanode读数据的时候
      • hdfs 默认检查单位是512字节
        • 即数据的每512字节会生产一个校验码（crc32算法）
        • 因为CRC32是32位即4个字节，这样校验和占用的空间就会少于原数据的1%
    • 后台有一个扫描进程：DataBlockScanner
      • 一旦检测出问题的block，通过心跳，通知NN， 于是NN让DN进行修复（拷贝一个无问题的备份）
      • 这个是防止物理介质出现损减情况而造成的数据损坏。
  • 容错--可靠性保证
    • 1. 心跳机制
    • 2. 多副本机制
    • 3. crc32数据校验
    • 4. SNN：保证元数据避免丢失
    • 5. 回收站(.Trash目录)
    • 6. 报告
      • ]# hdfs fsck /passwd -files -blocks -locations
    • 7. 快照：备份，有助于快速还原
  • HDFS 特点
    • 能做什么
      • 存储并管理PB级数据
      • 处理非结构化数据
      • 注重数据处理的吞吐量（延迟不敏感）T+1
      • 应用模式：write-once-read-many存取模式（无数据一致性问题）
    • 不适合做
      • 存储小文件（不建议）
      • 大量随机读（不建议）
      • 需要对文件修改（不支持）
      • 多用户写入（不支持，会造成覆盖）
  • HDFS 写的流程
    • 1. 客户端 rpc 调用NN，创建路径
    • 2. 客户端写入DN，DN自己根据机架感知策略创建多个副本。
      • 注：客户端不会等待DN所有副本创建完成（异步）
    • 3. 客户端向NN确认写入成功
  • HDFS 读的流程
    • 1、从NN获取元信息
    • 2、可从多个DN读取数据
  • 数据本地化
    • DateNode 和 tasktracker 部署在同一台机器
    • Namenode 和 Jobtracker是可以部署不同机器
  • HDFS 操作命令
    • 显示命令的帮助信息
      • hdfs dfs -help ls
    • 显示当前目录下的所有文件
      • hdfs dfs -ls /log/map hdfs dfs -lsr /log/ (递归的) hdfs dfs -ls -R /log/ (递归的)(新版本)
    • 。。。