Hadoop - HDFS

抖音

读取

SNN

文件 —— 块 映射关系a.jpg —— Block1b.mp4 ——Block1 Block2 Block3c.tar.gz —— Block1

Hadoop-HDFS 分布式文件系统 —— 网络拓扑图优极限网盘

1.联邦机制是为了解决 NameNode 压力问题，防止 NameNode 出现 OOM（内存溢出异常）2.底层 DataNode 公用，上层 NameNode 是联邦的，解决了 NameNode 的请求压力问题3.DataNode 底层磁盘存储格式是按照 NameNode 的 BlockPoolID 构建目录分别存储的，心跳也只汇报对应的块池文件块信息

DN

1G

处理1T文件

第一份副本

QJM 小型分布式文件系统，最少三台构建为集群环境，自己内部实现了 Paxos 算法

b.mp4128MBlock1

实时写入

1T

1.Client 发起文件上传或下载的请求到 Active NameNode，Active NameNode 会根据 DataNode 的资源情况以及机架感知策略返回可用节点2.直接和 DataNode 建立连接完成文件的上传下载3.客户端设置一个文件分割阈值，当文件超过阈值时，对文件进行切分，切分为多个块分别上传

Hadoop-HDFS 分布式文件系统 —— 基本架构优极限网盘

如果整个集群宕机，重启集群后，恢复数据流程如下：1.现将本地 fsimage 文件读入内存2.再将 QJM 中大于 fsimage 编号的 edits 文件读入内存3.再将 QJM 中最大编号的 edits_inprogress 文件读入内存4.等待所有 DataNode 心跳即可对外提供服务

抖音 生成BlockPoolID

DataNode01

元数据

排序

DataNode

存在NameNode的OOM

去重

第三份副本

2G

b.mp4128MBlock2

Hadoop-HDFS 分布式文件系统 —— ZooKeeper优极限网盘

利用ZooKeeper进行选主Active 和 Standby

可用内存1G

解决NameNode的OOM

Hadoop-HDFS 分布式文件系统 —— 客户端优极限网盘

c.tar.gz10MBlock1

内存读取速度快

联邦机制

前置条件副本3份

NameNode

解决方案：1.将数据读入内存，进行排序2.将1T 分为多个1G 的数据进行排序（快排）。怎么分才能确保相同两行在同一个文件中？（使用Hash取余），这样会得到一堆内部有序外部无序的文件，再通过归并排序，最终获得结果

DataNode05

解决元数据丢失

4G

DataNode02

Hadoop1.x

NameNodeSecondaryNameNode

1.NameNode 负责存储元数据（映射关系），元数据如何存储？2.为了元数据不丢失，需要持久化落盘存储；为了快速响应客户端，元数据还需要放入内存3.将文件与块的映射关系存入内存与磁盘，但是块与 DataNode 的映射关系只存入内存，因为 DataNode 可能会宕机，这层关系持久化无意义4.Client 发起文件上传或下载的请求到 Active NameNode，Active NameNode 会根据 DataNode 的资源情况以及机架感知策略返回可用节点5.为了保证 NameNode 的高可用，Hadoop2.x 版本中引入了 ZooKeeper 解决单点故障问题，使用 ZooKeeper 完成 Hadoop 集群的选主以及主备切换，主被称为 Active，备被称为 Standby

头条

1.NameNode 和 DataNode 是主从关系，Client 直接和 DataNode 建立连接完成文件的上传和下载2.默认每 3s 发送一次心跳至所有 NameNode，心跳中包含了节点剩余资源情况以及当前节点的所有文件块信息3.当 DataNode 宕机时（NameNode 会根据未收到心跳的时间统计，默认时间是10分30秒），部分文件块已无法满足集群默认3分副本数，NameNode 会让其他资源充分节点进行拷贝，来达到默认副本数

存在元数据丢失

Active NameNode

QJM 共享文件存储系统

分而治之：将海量数据按照服务器性能进行拆分，解决问题的核心方法不变，将这个方法映射到多份数据上

海量数据排序

只有一台电脑

Hadoop2.x

DataNode03

Standby NameNode

Hadoop-HDFS 分布式文件系统 —— 总结优极限网盘

第二份副本

a.jpg10KBlock1

火山

存在单点故障

客户端自己电脑IP 上海

今日头条 生成BlockPoolID

新增额外功能

与第二个副本相同机架的任意资源充足的服务器

Hadoop3.x

DataNode06

Hadoop-HDFS 分布式文件系统 —— Federation 联邦优极限网盘

海量数据去重

ZKFC

与第一份副本相同机房不同机架的任意资源充足的服务器

b.mp444MBlock3

块 —— DataNode 映射关系a.jpg - Block1 —— DN01 03 06b.mp4 - Block1 —— DN01 02 04b.mp4 - Block2 —— DN01 04 05b.mp4 - Block3 —— DN03 05 06c.tar.gz - Block1 —— DN03 05 06

火山小视频 生成BlockPoolID

磁盘数据不丢失

1.为了保证 NameNode 的高可用，Hadoop2.x 版本中引入了 ZooKeeper 解决单点故障问题，使用 ZooKeeper 完成 Hadoop 集群的选主以及主备切换，主被称为 Active，备被称为 Standby2.Standby NameNode 的内存元数据与 Active NameNode 的内存元数据一摸一样，当 Active 宕机时可以随时顶替成为新的 Active3.Standby NameNode 的磁盘元数据与 Active NameNode 的磁盘元数据不一样，因为谁是 Active 谁才会在磁盘写入元数据，并实时写入 QJM4.DataNode 需要同时向所有 NameNode 汇报自己的心跳，主要包含资源情况和文件块与 DataNode 的映射5.Standby NameNode 需要元数据进行压缩合并，为了方便快速地恢复元数据    a. 时间维度：默认1小时合并一次    b. 操作维度：默认100W次操作执行一次    c. 维度检查：默认1分钟执行一次6.合并后的文件叫做 fsimage，例如：fsimage_00000000034，合并后 Standby 会通知 Active 拷贝走合并文件，该文件最多只存在最近两个版本的

通过网络得出离客户端最近的一个机房中的机架中的一台服务器

解决单点故障

Hadoop-HDFS 分布式文件系统 —— DataNode优极限网盘

当前登录的节点存储第一份副本

ANN

客户端登陆至集群

根据客户端与 DataNode 的网络连接情况进行排序，按优劣顺序返回给客户端

解决方案：1.将数据读入内存，从第一行开始依次比较，找到重复两行，去重2.将1T 分为多个1G 的数据进行处理。怎么分才能确保相同两行在同一个文件中？（使用Hash取余），再利用HashSet 去重

客户端

李四PC

磁盘

机房IDC

Hadoop-HDFS 分布式文件系统 —— Active NameNode优极限网盘

DataNode04

1.元数据命名为 edits ，分为正在进行中的和已生成的，具体如下：   a.正在进行的文件叫做 —— edits_inprogress_000000000000071   b.已完成的文件叫做 —— edits_0000000000_0000000019  edits_00000000000020_0000000000342.元数据默认2分钟生成一次，当客户端上传文件时，元数据实时写入内存与 inprogress 文件，2分钟时 inprogress 文件会被分割为已完成的文件，新的 inprogress 文件继续写入

SN不会在NameNode 宕机时顶替，因为他只会进行压缩合并元数据

服务器

DataNode 群

机架

Hadoop-HDFS 分布式文件系统 —— QJM优极限网盘

1.解决 Hadoop 集群单点故障的问题，帮助选主，以及主备切换（Active 和 Standby 为主备关系）2.NameNode 向 ZooKeeper 注册临时 Znode，谁先注册成功谁是主，Standby 监听 Active3.当 Active 宕机时，Standby 通过监听机制得知，重新注册为 Active，Active 重启后降级为 Standby4.当集群发生脑裂现象时（Active是假宕机，比如网络波动），ZooKeeper 先通过 ZKFC 调用转换为 Standby 的方法，调用失败（转换失败）时，ZooKeeper 会根据配置文件中配置的结局方案，例如 ssh 登录至当前机器将其进程杀死 

Hadoop-HDFS 分布式文件系统 —— 机架感知优极限网盘

张三浏览器

王五APP

Hadoop-HDFS 分布式文件系统 —— Standby NameNode优极限网盘