6.Hadoop之HDFS（二）（Hadoop架构和特性）

6.Hadoop之HDFS（二）（Hadoop主要架构）

1.NameNode（NN）

1. 功能

• 接受客户端的读写服务

  • NameNode存放文件与Block的映射关系

  • NameNode会记录Block与DataNode的映射关系，但是不会持久化

• 保存文件的元数据信息

  • 文件的归属
  • 文件的权限
  • 文件的大小时间
  • Block信息，但是block的位置信息不会持久化,需要每次开启集群的时候DN上报
  • 

• 收集Block的信息

  • 系统启动时

  • NN关机的时候是不会存储任意的Block与DN的映射信息

  • DN启动的时候，会将自己节点上存储的Block信息汇报给NN

  • NN接受请求之后重新生成映射关系

    • Block–DN3

  • 如果某个数据块的副本数小于设置数，那么NN会将这个副本拷贝到其他节点

• 集群运行中

  • NN与DN保持心跳机制,三秒钟发送一次

  • <property> 
        <description>Determines datanode heartbeat interval in seconds.</description>
        <name>dfs.heartbeat.interval</name> 
        <value>3</value> 
    </property> 
    <property> 
        <name>heartbeat.recheck.interval</name> 
        <value>300000</value> 
    </property>
    

  • 如果客户端需要读取或者上传数据的时候，NN可以知道DN的健康情况

  • 可以让客户端读取存活的DN节点

• 如果DN超过三秒没有心跳，就认为DN出现异常

- 不会让新的数据读写到DataNode 
- 客户访问的时候不提供异常结点的地址

• 如果DN超过10分钟+30秒没有心跳，那么NN会将当前DN存储的数据转存到其他节点
  • 超时时长的计算公式为： timeout = 2 * heartbeat.recheck.interval + 10 *dfs.heartbeat.interval。 而默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。

2性能

• NameNode为了效率，将所有的操作都在内存中完成
  • NameNode不会和磁盘进行任何的数据交换
  • 问题:
    • 数据的持久化
    • 数据保存在内存中，掉电易失

2.DataNode(DN)

功能

• 存放的是文件的数据信息和验证文件完整性的校验信息
  • 数据会存放在硬盘上
  • 1m=1条元数据 1G=1条元数据
  • NameNode非常排斥存储小文件，一般小文件在存储之前需要进行压缩
• 汇报
  • 启动时
    • 汇报之前先验证Block文件是否被损坏
    • 向NN汇报当前DN上block的信息
  • 运行中
    • 向NN保持心跳机制
    • 客户可以向DN读写数据
• 当客户端读写数据的时候，首先去NN查询file与block与dn的映射
  • 然后客户端直接与dn建立连接，然后读写数据

3.SecondaryNameNode

1. 传统解决方案

• 日志机制
  • 做任何操作之前先记录日志
  • 当NN下次启动的时候，只需要重新按照以前的日志“重做”一遍即可
  • 缺点
    • edits文件大小不可控，随着时间的发展，集群启动的时间会越来越长
    • 有可能日志中存在大量的无效日志
  • 优点
    • 绝对不会丢失数据
• 拍摄快照
  • 我们可以将内存中的数据写出到硬盘上
    • 序列化
  • 启动时还可以将硬盘上的数据写回到内存中
    • 反序列化
  • 缺点
    • 关机时间过长
    • 如果是异常关机，数据还在内存中，没法写入到硬盘
    • 如果写出频率过高，导致内存使用效率低（stop the world） JVM
  • 优点
    • 启动时间较短

2.SNN解决方案

• 解决思路（日志edits+快照fsimage）

  • 让日志大小可控
  • 定时快照保存

• NameNode文件目录

  • 查看目录

  • 

  • /var/yjx/hadoop/full/dfs/name/current

  • edits_0000000000000000001-0000000000000000019

  • edits_inprogress_0000000000000000020

    • 当前已经正在执行的操作的日志信息
    • 这些日志信息还没有被合并到镜像中

  • fsimage_0000000000000000000

  • fsimage_0000000000000000000.md5

  • fsimage_0000000000000000019

  • fsimage_0000000000000000019.md5

    • 完整性校验规则

  • seen_txid -->19

  • VERSION

• 解决方案

  • 当我们启动一个集群的时候，会产生四个文件

    • edits_0000000000000000001
    • fsimage_00000000000000000
    • seen_txid
    • VERSION

  • 我们每次操作都会记录日志 -->edits_inprogress-000000001

  • 随和时间的推移，日志文件会越来越大，当达到阈值的时候（64M 或 3600秒）

    • dfs.namenode.checkpoint.period 每隔多久做一次checkpoint ，默认3600s 
      
      dfs.namenode.checkpoint.txns 每隔多少操作次数做一次checkpoint，默认1000000次 
      
      dfs.namenode.checkpoint.check.period 每个多久检查一次操作次数，默认60s
      

  • 会生成新的日志文件

    • edits_inprogress-000000001 -->edits_0000001
    • 创建新的日志文件edits_inprogress-0000000016

3.SNN数据恢复

1.强行杀死NameNode节点

​ kill -9 7388

2.清空namenode下name中的fsimage和edtis文件

rm -rf /var/yjx/hadoop/full/dfs/name/current/*

3.secondary namenode下的name中的fsimage和edits复制到namenode对应文件夹中

scp -r 
/var/yjx/hadoop/full/dfs/namesecondary/current/*
/var/yjx/hadoop/full/dfs/name/current

4.启动namenode

​ hadoop-daemon.sh start namenode

5.访问namenode节点页面，成功

4.安全模式

• 集群启动时的一个状态

  • 安全模式是HDFS的一种工作状态，处于安全模式的状态下，只向客户端提供文件的只读视图，不接受对命名空间的修改；同时NameNode节点也不会进行数据块的复制或者删除，

• NameNode启动时，

  • 首先将镜像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作。
  • 一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。
  • NameNode开始监听RPC和Http请求。
  • 此时NameNode处于安全模式，只接受客户端的读请求。

• 系统中的数据块的位置并不是由NameNode维护的，而是以块列表的形式存储在DataNode中。

• 安全模式下

  • 安全模式下，各个DataNode会向NameNode发送自身的数据块列表
  • 当NameNode有足够的数据块信息后，便在30秒后退出安全模式
  • NameNode发现数据节点过少会启动数据块复制过程

• 如果NN收集的Block信息没有达到最少副本数，就会将缺失的副本,从有的DN上拷贝到其他DN

  • dfs.replication.min=2
  • 但是默认最低副本数为1
  • 在拷贝的过程中系统还是处于安全模式

• 安全模式相关命令

  • hadoop dfsadmin -safemode leave 强制NameNode退出安全模式 
    hadoop dfsadmin -safemode enter 进入安全模式 
    hadoop dfsadmin -safemode get 查看安全模式状态 
    hadoop dfsadmin -safemode wait 等待一直到安全模式结束
    

4.HDFS的权限

• HDFS对权限的控制
  • 只能防止好人做错事
  • 不能防止坏人做坏事
• 你告诉他你是谁，他就认为你是谁！

5.机架感知策略

1. 节点距离

• distance(/D1/R1/H1,/D1/R1/H1)=0 相同的datanode
• distance(/D1/R1/H1,/D1/R1/H3)=2 同一rack下的不同datanode
• distance(/D1/R1/H1,/D1/R2/H4)=4 同一IDC下的不同datanode
• distance(/D1/R1/H1,/D2/R3/H7)=6 不同IDC下的datanode

2. 机架感知

• 机架感知(rack awareness)是为了保证副本在集群的安全性
• 我们需要将副本放在不同的DN节点上，节点也需要一定的考量
  • 可靠性、可用性、带宽消耗
• 第一个节点
  • 集群内部（优先考虑和客户端相同节点作为第一个节点）
  • 集群外部（选择资源丰富且不繁忙的节点为第一个节点）
• 第二个节点
  • 选择和第一个节点不同机架的其他节点
• 第三个节点
  • 与第二个节点相同机架的其他节点
• 第N个节点

  • 与前面节点不重复的其他节点
    -

  • 

6.HDFS写数据流程

写数据就是将客户端的数据上传到HDFS

1. 宏观流程

1. 客户端向HDFS发送写数据请求

   1. hdfs dfs -put tomcat.tar.gz /yjx/

2. filesystem通过rpc调用namenode的create方法

   1. nn首先检查是否有足够的空间权限等条件创建这个文件,或者这个路径是否已经存在，权限

      1. 有：NN会针对这个文件创建一个空的Entry对象,并返回成功状态给DFS

      2. 没有：直接抛出对应的异常，给予客户端错误提示信息

3. DFS如果接收到成功状态，会创建一个对象 FSDataOutputStream的对象给客户端使用

4. 客户端需要向NN询问第一个Block存放的位置

   1. NN通过机架感知策略 (node1 node 2 node8)

5. 需要将客户端和DN节点创建连接

   1. pipeline(管道)
      1. 客户端和node1创建连接 socket
      2. node1和node2创建连接 socket
      3. node2 和Node8创建连接 socket

6. 客户端将文件按照块block切分数据,但是按照packet发送数据

   1. 默认一个packet大小为64K,Block128M为2048个packet

7. 客户端通过pipeline管道开始使用FSDataOutputStream对象将数据输出

   1. 客户端首先将一个packet发送给node1,同时给予node1一个ack状态

   2. node1接受数据后会将数据继续传递给node2,同时给予node2一个ack状态

   3. node2接受数据后会将数据继续传递给node8,同时给予node8一个ack状态

   4. node8将这个packet接受完成后，会响应这个ack给node2为true

   5. node2会响应给node1 ,同理node1响应给客户端

8. 客户端接收到成功的状态,就认为某个packet发送成功了，直到当前块所有的packet都发送完成

9. 如果客户端接收到最后一个pakcet的成功状态,说明当前block传输完成，管道就会被撤销

10. 客户端会将这个消息传递给NN，NN确认传输完成

    1. NN会将block的信息记录到Entry,客户端会继续向NN询问第二个块的存储位置,依次类推

    2. block1 (node1 node2 node8)

    3. block2 (node1 node8 node9)

    4. …

    5. blockn(node1 node7 node9)

11. 当所有的block传输完成后，NN在Entry中存储所有的File与Block与DN的映射关系关闭FsDataOutPutStream

2. 微观流程

2. 首先客户端从自己的硬盘以流的方式读取数据文件到自己的缓存中

3. 然后将缓存中的数据以chunk（512B）和checksum(4B)的方式放入到packet（64K）

   1. chunk:checksum=128:1

   2. checksum:在数据处理和数据通信领域中，用于校验目的的一组数据项的和

   3. Packet中的数据分为两类，一类是实际数据包，另一类是header包。

   4. 一个Packet数据包的组成结构

4. 当packet满的时候加入到 添加到 dataqueue

5. datastreamer开始从dataqueue队列上取出一个packet，通过FSDataOPS发送到Pipleline

   1. 在取出的时候，也会将packet加入到ackQueue,典型的生产者消费者模式

6. 客户端发送一个Packet数据包以后开始接收ack，会有一个用来接收ack的ResponseProcessor进程，如果收到成功的ack

   1. 如果某一个packet的ack为true,那么就从ackqueue删除掉这个packet

   2. 如果某一个packet的ack为false,将ackqueue中所有的packet重新挂载到 发送队列,重新发送

7. 最终DFS保存的数据格式为

7.HDFS读数据流程

• 首先客户端发送请求到DFS，申请读取某一个文件
  • /yjx/tomcat.tar.gz
• DFS去NN查找这个文件的信息(权限,文件是否存在)
  • 如果文件不存在，抛出指定的错误
  • 如果文件存在，返回成功状态
• DFS创建FSDataInputStream对象，客户端通过这个对象读取数据
• 客户端获取文件第一个Block信息,返回DN1 DN2 DN8
• 客户端直接就近原则选择DN1对应的数据即可
• 依次类推读取其他块的信息，直到最后一个块,将Block合并成一个文件
• 关闭FSDataInputStream

8.Hadoop1的问题

• 单点故障

  • 每个群集只有一个NameNode，NameNode存在单点故障（SPOF）。

  • 如果该计算机或进程不可用，则整个群集在整个NameNode重新启动或在另一台计算机上启动之前将不可用

  • 如果发生意外事件（例如机器崩溃），则在操作员重新启动NameNode之前，群集将不可用。

  • 计划内的维护事件，例如NameNode计算机上的软件或硬件升级，将导致群集停机时间的延长。

• 水平扩展

  • 将来服务器启动的时候，启动速度慢

• namenode随着业务的增多，内存占用也会越来越多

  • 如果namenode内存占满，将无法继续提供服务

• 业务隔离性差

• 存储：有可能我们需要存储不同部门的数据

• 计算：有可能存在不同业务的计算流程

• 项目后期namenode的吞吐量将会是集群的瓶颈

• 客户端所有的请求都会先访问NameNode

• Hadoop2.x

  • NameNode节点的高可用
    • HA–high availability
  • NameNode业余的水平扩展
    • Federation

8.Hadoop-HA

1. 设计思想

• hadoop2.x启用了主备节点切换模式（1主1备）
• 当主节点出现异常的时候，集群直接将备用节点切换成主节点
  • 要求备用节点马上就要工作
  • 主备节点内存几乎同步
• 有独立的线程对主备节点进行监控健康状态
• 需要有一定的选举机制，帮助我们确定主从关系
• 我们需要实时存储日志的中间件

2. ANN

• Active NameNode 的功能和原理的NN的功能是一样的
• 接受客户端请求，查询数据块DN信息
• 存储数据的元数据信息
  • 数据文件：Block：DN的映射关系
• 工作
  • 启动时：接受DN的block汇报
  • 运行时：和DN保持心跳(3s,10m30s)
• 存储介质
  • 完全基于内存
  • 优点：数据处理效率高
  • 缺点：数据的持久化(日志edits+快照fsimage)

3.SNN

• Standby NameNode：NN的备用节点
• 他和主节点做同样的工作，但是它不会发出任何指令
• 存储：数据的元数据信息
  • 数据文件：Block：DN的映射关系
  • 它的内存数据和主节点内存数据几乎是一致的
• 工作：
  • 启动时：
    • 接受DN的block汇报
  • 运行时：
    • 和DN保持心跳(3s,10m30s)
• 存储介质
  • 完全基于内存
  • 优点：数据处理效率高
  • 缺点：数据的持久化
• 合并日志文件和镜像
  • 当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会会默认创建
    • fsimage_000000000000000
  • 当我们操作HDFS的时候ANN会产生日志信息
    • edits_inprogress_0000000000001
  • 主节点会将日志文件中新增的数据同步到JournalNode集群上
• 所以只需要snn有操作的日志信息，就可以合并fsImage与edits信息,理论上是一直在合并数据
  • fsimage -->初始化创建
  • edits–>从JournalNode集群上定时同步
  • 只要同步到edits文件，就开始于fsimage合并
  • 当达到阈值的时候，直接拍摄快照即可
• SNN将合并好的Fsimage发送给ANN,ANN验证无误后，存放到自己的目录中

4.DataNode(DN)

• 存储
  • 文件的Block数据
• 介质
  • 硬盘
• 启动时：
  • 同时向两个NN汇报Block信息
• 运行中
  • 同时和两个NN节点保持心跳机制

5.QJM

• Quorum JournalNode Manager 共享存储系统，NameNode通过共享存储系统实现日志数据同步。
• JournalNode是一个独立的小集群，它的实现原理和Zookeeper的一致( Paxos)
• ANN产生日志文件的时候，就会同时发送到 JournalNode的集群中每个节点上
• JournalNode不要求所有的jn节点都接收到日志，只要有半数以上的（n/2+1）节点接受收到日志，那么本条日志就生效
• SNN每间隔一段时间就去QJM上面取回最新的日志
  • SNN上的日志有可能不是最新的
• HA集群的状态正确至关重要，一次只能有一个NameNode处于活动状态。
• JournalNode只允许单个NameNode成为作者。在故障转移期间，将变为活动状态的NameNode将承担写入JournalNodes的角色，这将有效地防止另一个NameNode继续处于活动状态，从而使新的Active节点可以安全地进行故障转移。

6.ZKFC

• Failover Controller(故障转移控制器)

• 对 NameNode 的主备切换进行总体控制，能及时检测到 NameNode 的健康状况

  • 在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换

  • 为了防止因为NN的GC失败导致心跳受影响，ZKFC作为一个deamon进程从NN分离出来

  • 

  • 启动时：

    • 当集群启动时，主备节点的概念是很模糊的

    • 当ZKFC只检查到一个节点是健康状态，直接将其设置为主节点

    • 当zkfc检查到两个NN节点是的健康状态，发起投票机制

    • 选出一个主节点，一个备用节点，并修改主备节点的状态

  • 运行时：

    • 由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现主备切换

    • ZKFailoverController启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两个主要的内部组件

    • HealthMonitor 主要负责检测 NameNode 的健康状态

    • ActiveStandbyElector 主要负责完成自动的主备选举，内部封装了 Zookeeper 的处理逻辑

    • 

    • 主备节点正常切换

      NameNode 在选举成功后，ActiveStandbyElector会在 zk 上创建一个ActiveStandbyElectorLock 临时节点，而没有选举成功的备 NameNode 中的ActiveStandbyElector会监控这个节点

      如果 ActiveNameNode 对应的 HealthMonitor 检测到 NameNode 的状态异常时，ZKFailoverController 会主动删除当前在 Zookeeper 上建立的临时节点ActiveStandbyElectorLock

      如果是 Active NameNode 的机器整个宕掉的话，那么跟zookeeper连接的客户端线程也挂了,会话结束,那么根据 Zookeepe的临时节点特性，ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换

      处于 Standby 状态的 NameNode 的 ActiveStandbyElector 注册的监听器就会收到这个节点的 NodeDeleted 事件，并创建 ActiveStandbyElectorLock 临时节点，本来处于 Standby 状态的 NameNode 就选举为Active NameNode 并随后开始切换为 Active 状态。

7.Zookeeper

• 为主备切换控制器提供主备选举支持。
• 辅助投票
• 和ZKFC保持心跳机制，确定ZKFC的存活

8.脑裂brain-split

• 定义

  • 脑裂是Hadoop2.X版本后出现的全新问题，实际运行过程中很有可能出现两个namenode同时服务于整个集群的情况，这种情况称之为脑裂。

• 原因

  • 脑裂通常发生在主从namenode切换时，由于ActiveNameNode的网络延迟、设备故障等问题，另一个NameNode会认为活跃的NameNode成为失效状态，此时StandbyNameNode会转换成活跃状态，此时集群中将会出现两个活跃的namenode。因此，可能出现的因素有网络延迟、心跳故障、设备故障等。

• 脑裂场景

  • NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应
  • zkfc客户端也就无法向 zk 写入心跳信息，这样的话可能会导致临时节点掉线，备 NameNode会切换到 Active 状态
  • 这种情况可能会导致整个集群会有同时有两个Active NameNode

• 脑裂问题的解决方案是隔离（Fencing）

  • 1.第三方共享存储：任一时刻，只有一个 NN 可以写入；
  • 2.DataNode：需要保证只有一个 NN 发出与管理数据副本有关的命令；
  • 3.Client需要保证同一时刻只有一个 NN 能够对 Client 的请求发出正确的响应。

• (a) 每个NN改变状态的时候，向DN发送自己的状态和一个本次选举对应的序列号。

• (b) DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回是认为该NN为新的active。

• © 如果这时原来的active（比如GC）恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。

• 解决方案

  • ActiveStandbyElector为了实现 fencing，当NN成为ANN之后创建Zookeeper临时节点ctiveStandbyElectorLock，创建ActiveBreadCrumb 的持久节点，这个节点里面保存了这个Active NameNode的地址信息(node-01)

  • Active NameNode的 ActiveStandbyElector在正常的状态下关闭 Zookeeper Session 的时候，会一起删除这个持久节点

  • 但如果 ActiveStandbyElector在异常的状态下关闭，那么由于 /hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来，后面当另一个NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而会回调 ZKFailoverController的方法对旧的 Active NameNode 进行 fencing。

    • 首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的transitionToStandby 方法，看能不能把它转换为 Standby 状态；

    • 如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施。

      ​ sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死

      ​ shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离

• 在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始对外提供服务。

• 新的主创建临时节点ActiveStandbyElectorLock，创建持久化节点ActiveBreadCrumb ，并将自己的主机地址Node02赋值给初始化节点

Hadoop-Federation

HDFS Federation就是使得HDFS支持多个命名空间，并且允许在HDFS中同时存在多个NameNode。

1.单NN局限性

• Namespace（命名空间）的限制
  • NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。
  • 50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，12PB的存储
  • DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。
• 性能的瓶颈
  • 整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量
• 隔离问题
  • HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序
• 集群的可用性
  • Namenode的宕机无疑会导致整个集群不可用。
• Namespace和Block Management的紧密耦合
• 纵向扩展目前的Namenode不可行
  • 将Namenode的Heap空间扩大到512GB启动花费的时间太长
  • Namenode在Full GC时，如果发生错误将会导致整个集群宕机

2.Federation

• 块池Block Pool
  • Block pool(块池)就是属于单个命名空间的一组block(块)管理区域
  • 每一个datanode为所有的block pool存储
  • Datanode是一个物理概念，而block pool是一个重新将block划分的逻辑概念
  • 一个Namenode失效不会影响其下的datanode为其他Namenode的服务
  • datanode与Namenode建立联系并开始会话后自动建立Block pool
• Namespace Volume（命名空间卷）
  • 一个Namespace和它的Block Pool合在一起称作Namespace Volume
  • Namespace Volume是一个独立完整的管理单元。当一个Namenode/Namespace被删除，与之相对应的Block Pool也也被删除。
• 通过多个namenode/namespace把元数据的存储和管理分散到多个节点中
  • 降低单个NN节点数据压力,计算压力
• namenode/namespace可以通过增加机器来进行水平扩展
  • 可以让更多的节点参与到运算
  • namespace命名空间，通过这种方式确定要处理数据的路径
• 我们可以通过namenode和namespace组合使用
  • 所有的nn共享dn
  • 但是每一个namespace会单独管理自己的块
  • 会创建一个管理块的机制：blocks pool

9.Hadoop3新特性

1. Erasure Encoding

• 简介
  • HDFS默认情况下，Block的备份系数是3，一个原始数据块和其他2个副本。
  • 其中2个副本所需要的存储开销各站100%，这样使得200%的存储开销
  • 正常操作中很少访问具有低IO活动的冷数据集的副本，但是仍然消耗与原始数据集相同的资源量。
• EC技术
  • EC(擦除编码)和HDFS的整合可以保持与提供存储效率相同的容错。
    • HDFS:一个副本系数为3，要复制文件的6个块，需要消耗6*3=18个块的磁盘空间
    • EC:6个数据块，3个奇偶校验块
  • 擦除编码需要在执行远程读取时，对数据重建带来额外的开销，因此他通常用于存储不太频繁访问的数据

2.服务器端口

• 早些时候，多个Hadoop服务的默认端口位于Linux端口范围以内。
• 因此，具有临时范围冲突端口已经被移除该范围。
• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZgLVEMIJ-1661249759239)(C:\Users\dell\AppData\Roaming\Typora\typora-user-images\image-20220823181430774.png)]

3.JDK

JHadoop3中，最低版本要求是JDK8，所以低于JDK8的版本需要对JDK进行升级，方可安装使用Hadoop3

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ltxapDmT-1661249759240)(C:\Users\dell\AppData\Roaming\Typora\typora-user-images\image-20220823181509507.png)]

4.Yarn

提供YARN的时间轴服务V.2，以便用户和开发人员可以对其进行测试，并提供反馈意见

5.其他

• 优化Hadoop Shell脚本
• 重构Hadoop Client Jar包
• 支持随机Container
• MapReduce任务级本地优化
  本。
  • 其中2个副本所需要的存储开销各站100%，这样使得200%的存储开销
  • 正常操作中很少访问具有低IO活动的冷数据集的副本，但是仍然消耗与原始数据集相同的资源量。
• EC技术
  • EC(擦除编码)和HDFS的整合可以保持与提供存储效率相同的容错。
    • HDFS:一个副本系数为3，要复制文件的6个块，需要消耗6*3=18个块的磁盘空间
    • EC:6个数据块，3个奇偶校验块
  • 擦除编码需要在执行远程读取时，对数据重建带来额外的开销，因此他通常用于存储不太频繁访问的数据

2.服务器端口

• 早些时候，多个Hadoop服务的默认端口位于Linux端口范围以内。
• 因此，具有临时范围冲突端口已经被移除该范围。
• 

3.JDK

JHadoop3中，最低版本要求是JDK8，所以低于JDK8的版本需要对JDK进行升级，方可安装使用Hadoop3

4.Yarn

提供YARN的时间轴服务V.2，以便用户和开发人员可以对其进行测试，并提供反馈意见

5.其他

• 优化Hadoop Shell脚本
• 重构Hadoop Client Jar包
• 支持随机Container
• MapReduce任务级本地优化
• 支持文件系统连接器