大数据分布式文件存储系统--HDFS

Posted 2021-04-02 Whitecookies

HDFS基础

HDFS系统架构

Hadoop的框架最核心的设计就是HDFS、MapReduce。hdfs本身是主从架构，即master和slave。

hdfs进行海量数据的分布式存储。namenode是主节点，datanode是从节点。SecondaryNameNode可以理解为一个备份，但实际上并不是。

NameNode

我们先来看看hdfs架构中的namenode。namenode是一个进程在某一个节点(机器)上，本身维护一块内存区域。内存中存储两份最重要的数据(元数据通过datanode通过心跳机制保证，datanode有新增数据，通过心跳机制告诉namenode)：

•1.文件名->block数据块的映射关系(mapping关系)•2.block数据块到datanode节点之间的映射关系

整个1、2、3数据块合起来就是文件的内容。

在存储数据时，首先要找nn分配dn来写入数据。hdfs默认会存储三分数据副本。

NameNode(NN)作用

•管理着文件系统命名空间•存储元数据•保存文件，block, datanode之间的映射关系•元信息持久化•运行 Namenode会占用大量内存和I/O资源•Hadoop更倾向存储大文件原因

1.为什么hadoop更倾向于存储大文件？

namenode内存有限，如果内存存放大量小文件，会占用大量内存和I/O资源，使得集群反应速度慢。所以，hadoop不适合存储大量的小文件。hdfs1.0的块大小是64M，hdfs2.0是128M。

总结：

1.对于集群硬盘资源造成严重浪费；

2.nn本身内存有限，造成namenode内存溢出；

注意：数据块过大，会导致启动mapreduce并发能力不够，影响任务执行速度。

比如Block块大小为128m，如果数据大小是1G，则可以启动8个maptask线程去跑该数据，但如果Block块大小设置为640m，则只能启动2个maptask线程去跑该数据，8线程和2线程，哪个效率更高，一眼即可看出。

假设有一个块，大小64m，但是存储的文件大小是10m，就浪费了54m的空间，对集群的硬盘资源造成了严重浪费。

在hdfs1.0中只有一个namenode(nn)，这是因为当时基础设施的不完整，数据量也不是很多没有想太多。到现在，由于数据量过多，因此产生了zookeeperk(分布式锁服务...)来协调

NN单节点故障

Hadoop集群生态只有一个 Namenode，容易导致单节点故障。

解决方案

•

1.将 hdfs元数据写入到本地文件系统的同时再实时同步到一个远程挂载的网络文件系统（NFS)

•fsimage它是在 Namenode启动时对整个文件系统的快照

•edit logs它是在 Namenode启动后，对文件系统的改动序列，产生log

•2.运行一个 Secondary Name Node，它的作用是与Namenode进行交互定期通过编辑日志文件合并命名空间镜像。当 NameNode发生故障时它会通过自己合并的命名空间镜像副本来恢复。需要注意的是 Secondary Namenode保存的状态总是滞后于NameNode，所以这种方式难免会导致丢失部分数据。

snn的意义是对editlog进行汇总，并产生一个新的fsimage，但也是不能保证完全不会产生信息丢失，下面只是hdfs1.0的一个临时解决方案，具体解决方案会在hdfs2.0讲解。

DataNode(NN)作用

•负责存储数据块，负责为系统客户端提供数据块的读写服务•根据 Namenodel的指示进行创建、删除和复制等操作•心跳机制，定期报告文件块列表信息

机架感知策略--Block副本放置策略

•什么情况下涉及到机架感知？

hadoop集群规模很大的时候，还有为了避免跨机架，导致的带宽消耗

目的：

1.不同节点之间的通讯，尽量发生在一个机架之内，节省网络传输带宽

2.提高容错能力

数据完整性--检测数据是否受到损坏

•不希望在存储和处理数据时丢失或损坏任何数据•HDFS会对写入的数据计算校验和，并在读取数据时验证校验和•两种检验方法逻辑

•校检和

•检测损坏数据的常用方法是在第一次进行系统时计算数据的校验和，在通道传输过程中，如果新生成的校验和不完全匹配原始的校验和，那么数据就会被认为是被损坏的。•

•数据块检测程序 DataBlockScanner

•在 Datanode节点上开启一个后台线程，来定期验证存储在它上所有块，这个是防止物理介质出现损减情况而造成的数据损坏。

容错--数据可靠性

•

一个NN和多个DN

•

故障检测

•数据节点

•心跳包(检测是否宕机)：dn和nn随时保持心跳，3s一次，保证集群可靠性；•快报告（安全模式下检测）•数据完整性检测（校验和比较--crc32）

•

空间回收机制

•Trash目录：-skipTrash（删除的文件跳过回收站直接删除）

•

数据复制(冗余机制)

•副本-数据冗余存放(机架感知策略)

•

snn，保证镜像文件数据可以恢复；

HDFS特点

优点

•存储并管理PB级数据•处理非结构化数据•注重数据处理的吞吐量（延迟不敏感）•应用模式：write-once-read-many存取模式（无数据一致性问题）

缺点

•存储小文件（不建议）•大量随机读（不建议）•需要对文件修改（不建议）

•对文件修改会影响块进行重新分配，块分配又会影响到和多个dn节点间进行网络通讯；

•多用户写入（不支持）

hdfs不适合场景

存储海量小文件

文件被修改

大量随机读取，对于大数据的文件读取，更倾向于顺序读，因为随机读取需要寻址，浪费时间影响效率，而且顺序读取的效率会比内存读取要高

hdfs写流程

写的文件经过namenode同意，即文件是否已存在？用户是否有写的权限？如果都ok，则nn分配dn节点去写数据。当client写入数据到第一个dn后就直接返回成功，其他节点对第一个dn进行拷贝，减轻了client的负担，数据同步是异步的过程。dn通过心跳告知nn数据的增加。

hdfs读流程

HDFS&MapReduce的本地模式

mapreduce(mr)集群在1.0中，主(jobtracker--nn)，从(tasktracker--dn)

hdfs是一个存储集群，mr是一个计算集群；

主：分配任务，根据集群空闲情况分配任务；

从：具体干活

就近原则：本地化，数据不移动，任务移动；哪些节点有数据，就把代码逻辑放到哪些节点上，提高了集群整体性能。因为大量数据移动会产生高带宽，可如果只是代码逻辑移动，代码文件不大，能有效减少带宽，提高集群效率。

HDFS2.0

新特性

•Namenode HA•Namenode Federation•HDFS快照•HDFS缓存•HDFS ACL

NameNode的HA(高可用)

Hadoop2.0中的HA 主要解决Hadoop1.0中的单点故障问题（使用两个NN，一个activeNN, 一个是standbyNN），并不是两个nn都对外提供服务，activenn挂了，standby则顶替上。

单点故障问题解决方案

•HDFS的高可用性将通过在同一个集群中运行两个 Name Nodeactive Name Node& standby Name Node）来解决•在任何时间，只有一台机器处于 Active>状态；另一台机器是处于Standby状态•Active NN负责集群中所有客户端的操作，Standby NN主要用于备用，它主要维持足够的状态，如果必要，可以提供快速的故障恢复。

数据一致性如何保证？

•1.共享的网络文件系统(文件名 -> block映射关系)•2.dn向两个nn都发送心跳信息，维护block和dn节点的映射关系

•*之所以向两个同时发，是因为要保证standbyNN顶替时，能够与原来的activeNN拥有一样的元数据信息？**

故障转移：利用zookeeper来保证(本身维护了一个有序的临时节点)

NameNode2.0

实现了active挂掉无感知。active挂掉后，fc进程会将信息传给zk，进行一个故障转移。

JN(网络共享文件系统)

可以理解为一个集群。但因为有多个机器，怎么判断哪些机器的数据是新的哪些是旧的呢？

•

采用投票机制，谁的票数越多，就以谁的为准。

•

•前提是节点个数必须是奇数，避免一半赞成一半反对情况的出现导致无法确定结果,方便进行投票选举出含有最新数据所在机器并以此为根据，达到数据的统一存储；

•

共享文件系统的作用是保证数据统一存储

JN：QJM（是JN组成的集群，只有投票，没有存储），JN部署一般和DN在一起，处于同一个节点上，不部署在NN上是因为如果NN挂掉会影响JN进行投票。

•

但是每一个datanode上都部署一个JN合理吗？

•

•只需要选择一部分部署即可(选择奇数个节点部署)，便于利用少数服从多数的机制。•但会导致多个机器数据不一致？？

JN优点：

•不需要额外的配置共享存储，节约成本•没有单节点问题•不需要人为搭建（介入），自动支持

当activeNN挂掉了，standbyNN如何顶替？

•

故障转移（利用zookeeper保证）

•

•主要通过有序的临时节点来保证•

集群配置：

nn和jn可以配置在一个节点上好，还是不同机器好？

•通常nn和jn放置在不同机器上，如果放在同一机器，nn挂掉了，会影响jn；•nn和fc部署在同一节点上，以便于随时监控nn的情况；•hadoop2.0 RM（相当于jobtracker）和nm在同一个节点上；•NM(相当于tasktracker)和DN在同一个节点上，因为就近原则，减少带宽损耗•zk独立维护一套集群

NameNode Federation

联邦nn用于解决单nn的内存限制问题，集群中提供多个nn，每个nn负责管理一部分dn，集群共享整个dn。

nn联邦机制：本质是突破nn本身内存资源的瓶颈，不再受某一个nn内存限制

解决的问题：

•高可用•nn内存资源不足

减轻了单个nn的压力，有利于集群的横向拓展，提升了性能。

关键点：每个nn共享所有dn的数据，让我们的元数据和存储得到了隔离

前面解决了高可用的问题，但是NN本身的内存资源也是不够

联邦：（解决了高可用，内存资源增加）

•通过将数据进行切分，产品部门，技术部门，其他业务部门，各自维护各自的namenode, 但是背后的数据都是共享同一套DN

好处：

•减轻单一的NN的压力，将数据可以通过其他的NN来管理•有利于集群的横向扩展，性能带来很大的提升，资源得到隔离

本质：

•元数据管理和存储得到解耦，但是真实的数据是共享的

HDFS快照

数据备份，灾备，快速恢复

快照本质：只记录block列表和大小，不涉及到数据的复制

•HDFS快照是一个只读的基于时间点文件系统拷贝•快照可以是整个文件系统的也可以是一部分。•常用来作为数据备份，防止用户错误操作和容灾恢复。•Snapshot并不会影响HDFS的正常操作：修改会按照时间的反序记录，这样可以直接读取到最新的数据。•快照数据是当前数据减去修改的部分计算出来的。•快照会存储在 snapshottable的目录下

HDFS缓存

本地client，第一次记录查询的文件路径以及dn(涉及和nn的交互)，第二次直接拿着查询的文件路径进行查询即可

chmod o+w 文件：给other用户组添加一个写权限

ACL

dr(读权限)w(写权限)x(执行权限)(代表owner的权限) r-x(用户同组的权限) r-x(其他不是和owner同组的用户). 2 6 01:01 hadoop d表示目录 若是文件使用 "-"