大数据学习07之Hadoop-HDFS-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_64407249/article/details/143415836

1.大数据思维

1.1 分而治之

所谓“分而治之”，就是把一个复杂的算法问题按一定的“分解”方法分为等价的规模较小的若干部分，然后逐个分别找出各部分的解，再把各部分的解组成整个问题的解。这种朴素的思想来源于人们生活与工作的实践经验，如下图。

1.2 查重

如何在内存1G的情况下，在1TB的文本文件中找到重复的两行？

1.遍历（效率低，内存够，但时间复杂度较高O（n²））

2.HashSet（key去重，内存不够）

3.对文本的每一行取哈希值然后用1024取余，相同余数的行数据放到一个文本里，如此划分成1024个1GB大小的文本文件，然后再对每个文件用HashSet来判断是否重复

1.3 排序

内存1GB，对1TB的数据进行排序；

外排序。分块，将数据分块，每个块1GB，对块进行排序，然后对排序后的块进行归并。

2.分布式文件系统架构

2.1文件切分思想

文件存放在一个磁盘上效率肯定是低的
        读取效率低
        如果文件特别大会超出单机的存储范围
字节数组
        文件在磁盘真实存储文件的抽象概念
        数组可以进行拆分和组装，源文件不会受到影响
切分数据
        对字节数组进行切分
拼接数据
        按照数组的偏移量将数据连接到一起,将字节数组链接到一起
偏移量
        当前数据在数组中的相对位置，你可以理解为下标
        数组都有对应的索引(下标),可以快速的定位数据
数据存储的原理：
        不管文件的的大小，所有的文件都是由字节数组构成
        如果我们要切分文件,就是将一个字节数组分成多份
        我们将切分后的数据拼接到一起，数据可以继续使用
        我们需要根据数据的偏移量将他们重新拼接到一起

2.2 Block拆分标准

拆分的数据块需要等大
        数据计算的时候简化问题的复杂度
                进行分布式算法设计的时候，数据不统一，算法很难设计
        数据拉取的时候时间相对一致
        通过偏移量就知道这个块的位置
        相同文件，分成的数据块大小应该相等
数据块 Block
        数据被切分后的一个整体称之为块
        在H1默认大小为64M,在H2及其以后默认大小为128M
        同一个文件中，每个数据块大小要一致除了最后一个节点外
        不同文件中，块的大小可以不一致
        文件大小不同可以设置不同的块的数量
        真实情况下，会根据文件大小和集群节点的数量综合考虑块的大小
        数据块的个数 =Ceil（文件大小 / 每个块的大小）
注意事项
        HDFS中一旦文件被存储，数据不允许被修改
                修改会影响偏移量

                修改会导致数据倾斜
                修改数据会导致蝴蝶效益
但是可以被追加，但是不推荐
        追加设置需要手动打开
一般HDFS存储的都是历史数据。所以将来Hadoop的mr都用来进行离线数据的处理
块的大小一旦文件上传之后就不允许被修改
        128m -512M
如果数据文件的切割点128M整好是一个单词的中间部分，切分数据如何保证数据的完整性？

2.3 Block数据安全

数据备份；

备份存放到多个节点上；

就近节点获取数据；

备份数量要小于等于节点数量；

每个数据库默认有三个副本，相同副本不会存放在同一节点上；

副本数量可以变更；

2.4 Block的管理效率

需要专门给节点进行分工：
存储：DataNode

记录：NameNode

日志：QJM

2.5 HDFS的特点

优点：

高容错性：保存多个副本，提供容错机制；副本丢失自动回复，默认三份副本

运行在廉价机群上：通过副本提高可靠性；提供容错和恢复机制

适合批处理：移动计算而非数据；数据位置暴露给计算框架，NameNode上有位置

适合大数据处理：TB，甚至PB级数据；百万以上的文件数量，一万以上的节点规模

流式数据访问：一次写入，多次读取，高吞吐量，并行处理大量数据

缺点：

不擅长低延迟数据访问，如毫秒级别；

不擅长小文件分区：占用大量的NameNode内存，元数据内存大于文件本身；

不擅长并发写入，文件随机修改：一个文件只能有一个写入者，仅支持追加

3. HDFS基础架构

元数据：数据的数据，用来描述数据的文件名称，存放位置，内存大小等数据；

3.1NN （NameNode）

3.1.1

接受客户端的读写服务：

存放文件与Block的映射关系；

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

保存文件元数据：

文件的归属；

文件的权限；

文件的大小、时间；

Block信息，但是Block的位置信息不会持久化，需要每次开启集群的时候DN（DataNode）通过心跳上报；

收集Block信息：

系统启动时，DN通过心跳上报自己的Block信息；

集群运行时，DN每三秒钟发送一次心跳，超过三秒判定DN出现异常；

3.1.2性能

NN所有操作在内存中完成，提高效率；

问题：数据的持久化，数据保存在内存中，容易丢失

3.2DN（DataNode）

3.2.1 功能

存放文件的数据信息和验证文件完整性的校验信息：

数据会存放在硬盘上；

1m=1条元数据 1G=1条元数据

NameNode非常排斥存储小文件，一般小文件在存储之前需要进行压缩

汇报：

启动时：

汇报之前先验证Block文件是否被损坏；

向NN汇报当前DN上block的信息；

运行时：

向NN保持心跳机制；
客户可以向DN读写数据；

当客户端读写数据的时候，首先去NN查询file与block与dn的映射：

然后客户端直接与dn建立连接，然后读写数据；

4.Hadoop-HA架构

4.1设计思想

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

4.2 ANN

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

4.3 SNN

Standby NameNode：NN的备用节点
他和主节点做同样的工作，但是它不会发出任何指令
存储：数据的元数据信息
数据文件：Block：DN的映射关系
它的内存数据和主节点内存数据几乎是一致的
工作：
启动时：
接受DN的block汇报
运行时：
和DN保持心跳(3s,10m30s)
存储介质
完全基于内存
优点：数据处理效率高
缺点：数据的持久化
合并日志文件和镜像
当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会会默认创建
fsimage_000000000000000
当我们操作HDFS的时候ANN会产生日志信息
edits_inprogress_0000000000001
主节点会将日志文件中新增的数据同步到JournalNode集群上
edits 文件默认 2 分钟生成一个，默认上限 100W 个；
只有 Active NameNode 才可以将 edits 元数据写入到 QJM；
每个 NameNode 上的 edits 元数据是不完整的（主备切换导致），但是 QJM 中一定是完整的；
10
No. 10 / 35
Hadoop 2.x 以及以后 fsimage 文件的合并机制：
时间纬度：1 小时合并一次；
操作纬度：edits 操作次数超过 100W 次；
纬度检查周期：默认 1 分钟检查一次。
QJM 只保存 edits 文件，不保存 fsimage 文件，fsimage 文件只保存在 NameNode 中。SNN 将合并后的 fsimage 发
送给ANN，ANN 验证无误后，存放到自己的目录中；
ANN 使用 fsimage 加 edits_inprogress_ 文件还有大于 fsimage 的 edits 文件即可完全恢复元数据。