HDFS

Hadoop 1.0:

• 3个组件：
  • Namenode
  • SecondNamenode
  • Datanode

namenode（主节点，master，只有一个，单点故障的风险）中间存储信息（元数据）
2种映射关系：

1. path -> blockid list 列表
2. blockid 数据块 -> datanode 节点地址
   元数据存在内存中
   元数据进行持久化 — 磁盘fsimage — 目的：避免数据丢失
   fsimage ： 元数据镜像文件
   只有机器重启的时候加载fsimage

   元数据持久化的过程 — SNN — secondnamenode
   内存 -> edit log（磁盘）-> fsimage

   SNN 存在意义 ： 备份 / 数据恢复

   namenode和 edit log关系：
   namenode需要把每一次改动都存在 edit log ，整个过程谁来推动？（Datanode和namenode之间心跳机制）

   namenode除了单点问题之外，还有不适合存储太多小文件的问题，因为内存有限

datanode （slave，从节点，多个机器）

1. block 数据块 -> 真实输据
   多副本机制 — 默认3副本 （作用：数据冗余，高可用）
   本地化原则 （就近原则）：mapreduce：主（jobtracker - namenode），从（tasktracker - datanode）

可靠性保证 :

1. 数据校验
   目的 ： 保证数据完整性 （通过crc32校验算法）
   整个数据传输过程，输据需要校验几次？
   1. client给datanode写数据：要针对写的数据，每个检查单元（512字节）
      • 每一个单元创建一个单独的校验码（crc32） ， 数据和校验码统一发送给Datanode
   2. Datanode 接受输据的时候 ： 用同样的加密算法，生成校验码，并校验
      • 在后台还会运行一个扫描进程：DataBlockScanner（定期校验）
      • 一旦检测出现问题，通过心跳，通知NN，让NN发起DN修复 （拷贝没有问题的备份）

2.可靠性保证 ：

• 心跳
• 多副本机制
• crc32
• SNN （secondnamenode）
• 回收站 （ .Trash 目录）

Hadoop 2.0:

1. HA 高可用 ： 解决了单点故障问题
   1.0里有一个SNN，但是不可靠
   如何便可靠：需要两个NN，一个active，一个standby（备用）
   为了保证两个NN的数据一致性，Datanode要对两个NN同时发送心跳

2. 虽然Datanode同时发送心跳，但是为什么还需要JN？
   2种映射关系：
   path -> blockid list 列表 ：JN
   blockid 数据块 -> datanode 节点地址 ： Datanode心跳
   分工不同：：：

3. HDFS２.０ 需要引入zookeeper ， （zookeeper目的：协调分布式集群中各个节点工作有序进行，完成故障转移）

4. 在2.0，引入zkfc（ZookeeperFailoverController）进程，和NN部署到同一个机器上，目的：负责自己管辖之内的NN进行健康检查
   zkfc 进程会在zookeeper上注册一个临时节点
   目的：监控NN，一旦NN挂掉，相对应的临时节点消失，接下来开始选主（申请锁）流程

5. JN目的：让activeNN和standbyNN保持输据同步（文件 -> block)
   同步问题：需要以来JN（JournalNodes）守护进程，完成元数据的一致性

6. JN 角色有两种选择：
   1） NFS — 网络系统 （network file system）
   需要额外的磁盘空间
   2）QJM — 最低法人管理机制 （投票）
   不需要额外的磁盘空间
   需要用2n+1台机器存储edit log (奇数是为了投票）
   QJM本质是小集群
   好处：
   * 不需要空间
   * 无但点问题
   * 不会因为个别机器延迟，影响整体性能
   * 只需要通过简单的系统配置可以实现

7. 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