hadoop之HDFS

一、背景

1、企业存储系统

a. 存储设备

硬盘

· 硬盘是计算机的主要存储硬件，可用来存储数据
· 市面上流行的硬盘多少是TB级
· 硬盘分类：机械硬盘HDD 、固态硬盘SSD、混合硬盘SSHD

机械硬盘的特点：体积大、价格便宜、读写速度慢、内部有马达和风扇、寿命长
固态硬盘的特点：体积小、价格贵、读写速度快、寿命短

RAID 磁盘队列

磁盘队列由很多独立磁盘组合成容量巨大的磁盘组，存储和容错性能提升

b. 存储架构类型

DAS 直连式存储

存储设备通过电缆直接挂在服务器总线上，DAS比较依赖操作系统进行IO操作

FAS 网络化存储

· FAS网络化存储 分为 NSA 网络接入存储 和 SAN 存储区域网络存储

· NSA 也称网络接入存储，存储设备通过网络连接，常用来存储非结构化数据，采用nsa较多的功能是用来共享文档、图片等。随着云计算的发展，一些nsa厂家也推出了云存储功能

· SAN 存储区域网络 是一种高速的、专用于存储操作的网络，通常独立于计算机局域网(LAN)。SAN将主机和存储设备连接在一起，能够为其上的任意一台主机和任意一台存储设备提供专用的通信通道。SAN将存储设备从服务器中独立出来，实现了服务层次上的存储资源共享。

· DAS、NAS、SAN对比

2、文件系统

a. 介绍

· 文件系统用于存储数据、组织数据，并提供了访问和获取数据的方法
· 文件系统使用文件和树形目录的抽象逻辑概念替代了物理设备使用数据块的概念，方便用户使用和查找数据。
· 文件系统中的文件名用于定位存储位置、区分不同文件，元数据用于记录文件的特征

b. 分类

· 基于磁盘的文件系统
linux中使用df -Th 可查看磁盘内容
· 虚拟文件系统
proc文件系统是在内核中生成的文件系统，通过它 可以使用一种新的方法 在linux内核空间和用户之间 进行通信
· 网络文件系统 NFS
将远程主机上的分区（目录）经过网络挂载到本地系统的一种机制

c. 文件存储格式

3、海量数据存储遇到的问题

· 成本高：传统存储硬件后期维护、升级扩容成本高
· 性能低：单节点I/O性能瓶颈无法逾越，难以支持海量数据高并发高吞吐场景
· 可扩展性差：无法实现快速部署和弹性扩展，动态扩容、缩容成本高，技术实现难度大
· 无法支持高效率的计算分析

二、简介

· HDFS 全称Hadoop Distributed File System ，意为Hadoop分布式文件系统
· HDFS是hadoop的核心组件之一，作为大数据生态圈最底层的分布式存储服务而存在
· 能够在普通硬件上运行，支持故障检测和自动快速恢复，可以存储TB、PB级别的大数据
· 使用多台计算机存储文件，并提供统一的访问接口，可以像访问普通文件系统一样访问分布式文件系统中的文件。
· HDFS适用于大文件存储、数据流式访问、一次写入多次读取的场景，不适用于小文件、数据交互式访问、频繁任意修改、低延迟处理的场景

· hdfs首次启动时要进行formate操作。 formate之前, hdfs在物理上还不存在。首次formate会执行一些清除和准备工作，就是创建元数据本地存储目录和元数据相关文件。

三、架构剖析

1、HDFS架构

MS架构，主从各司其职，互相配合，共同对外提供分布式的文件存储服务
缺点：存在单点故障的问题

a. namenode

· hdfs的核心，集群的主角色，简称nn
· namenode负责存储管理HDFS的元数据，文件系统namespace操作维护目录树、文件和块的位置信息。
· namenode知道hdfs中任何给定文件的块列表及其位置。使用此信息nn知道如何从块中构建文件
· namenode是客户访问hdfs的唯一入口，namenode关闭时，hdfs集群无法访问

· Namenode下文件所在位置由hdfs-site.xml中的配置项dfs.namenode.name.dir配置
· namenode启动后，datanode启动前，nn启动了安全模式，使用命令行可ls文件但是不可cat文件
· 没有数据块向namenode汇报数据，namenode自动启动安全模式。安全模式下，可读不可写
· namenode所在机器通常有大量内存（RAM）

b. datanode

· datanode是架构中的从角色，简称dn，负责具体数据块存储
· dn的数量决定了hdfs集群的整体数据存储能力
· dn启动时，会将自己发布到namenode并汇报自己负责持有的块列表
· dn定期向nn进行自己持有的数据块信息汇报，默认ds.blockreport.intervalMsec=6h
· dn定期向nn发送心跳，如果nn长时间没有接受到dn发送的心跳，nn就会认为该dn失效，默认dfs.heartbeat.interval=3s
· dn根据nn的指令执行块的创建、复制和删除操作
· Damenode下文件所在位置由hdfs-site.xml中的配置项dfs.datanode.name.dir配置
· 在datanode上，文件分块存储，且每个块按副本数存储在不同的datanode 上
· dn所在机器通常有大量硬盘空间

c. secondaryNameNode

· secondaryNameNode是namenode的辅助角色
· 负责帮助namenode是进行元数据的合并，还原当前文件系统namespace

2、HDFS HA （高可用）架构

· HA，即高可用（7*24小时不中断服务）,消除单点故障
· 缺点：
（1）系统扩展性方面，元数据存储在NN内存中，受内存上限的制约
（2） 整体性能方面，吞吐量受单个NN的影响。
（3）隔离性方面，一个程序可能会影响其他运行的程序，如一个程序消耗过多资源导致其他程序无法顺利运行。
HDFS HA本质上还是单名称节点。

a. NameNode

· NameNode会被配置在两台独立的机器上，在任何时间点，一个NameNode处于活动状态，而另一个NameNode处于备份状态
· Active NameNode对外提供服务，比如处理来自客户端的RPC请求
· Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，对Active NameNode进行实时备份，以便能够在它失败时快速进行切换。
· 访问文件时使用命名空间，hdfs dfs -ls hdfs://RUOZEG6/，core-site.xml、hdfs-site.xml里配置了RUOZEG6命名空间下挂了NN1和NN2，当它找到NN1，它会尝试着连接第一个机器NN1，如果发现它不是active状态，它会尝试着连接第二个机器NN2，如果发现NN1是active状态，就直接用了。

b. DataNode

· 为了支持快速failover，Standby node持有集群中blocks的最新位置是非常必要的。为了达到这一目的，DataNodes上需要同时配置这两个Namenode的地址，同时和它们都建立心跳链接，并把block位置发送给它们。

c. JournalNode

· JournalNode：用于active NN节点和standby NN节点之间同步数据
· JournalNode集群就是共享hdfs读和写操作记录的。

d. zookeeper

· zookeeper：用于做选举的，举谁来做老大（active），谁做standby。
· 集群中ZK的个数是2n+1，这样能投票保证最后有一个胜出。
· 生产上zookeeper部署的个数经验：如果集群中有20台节点，那么可以在5台上部署zk。如果总共有七八台，也部署5台zk。如果总共有20~100台节点，可以部署7台/9台/11台 zk。如果大于100台，可以部署11台zk。

e. ZKFC

· zookeeper failover control，和NN在同一台机器上面，是单独的进程。
· 每一个zkfailover负责监控自己所在namenode节点的健康状态，向zk集群定期发送心跳，使得自己可以被选举。
· 当自己被zk选举为active的时候，zkfc进程通过RPC协议调用使NN节点的状态变为active
· 对外提供实时服务，是无感知的

3、HDFS Federation （联邦）架构

· 允许一个HDFS集群中存在多组Namenode同时对外提供服务，分管一部分目录（水平切分），彼此之间相互隔离，但共享底层的Datanode存储资源。
· 缺点:
(1) 由于Namespace被拆分成多个，且互相独立，一个文件路径只允许存在一个Namespace中。如果应用程序要访问多个文件路径，那么不可避免的会产生交叉访问Namespace的情况。比如MR、Spark任务，都会存在此类问题。
(2) 启用Federation后，HDFS很多管理命令都会失效，比如“hdfs dfsadmin、hdfs fsck”等，除此之外，“hdfs dfs cp/mv”命令同样失效，如果要在不同Namespace间拷贝或移动数据，需要使用distcp命令，指定绝对路径。

a. namenode

· HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展
· 每个NN分别进行各自文件命名空间和块的管理，不需要彼此协调
· 一个namenode挂掉了不会影响其他的namenode，不会影响其下Datanode为其他Namenode服务。
· 增加更多的Namenode能增大文件系统读写操作的吞吐量。
· 一个单一的Namenode不能对多用户环境进行隔离，一个实验性的应用程序会加大Namenode的负载，减慢关键的生产应用程序，在多个Namenode情况下，不同类型的程序和用户可以通过不同的Namespace来进行隔离。
· HDFS中namespace是指NameNode中负责管理文件系统中的树状目录结构以及文件与数据块的映射关系的一层逻辑结构，在Federation方案中，NameNode之间相互隔离，因此社区也用一个namespace来指代Federation中一组独立的NameNode及其元数据。

c. block pool

· 一个block pool由属于同一个namespace的数据块组成，每个datanode可能会存储集群中所有block pool 数据块
· 当DN与NN建立联系并开始会话后自动建立Block Pool。每个block都有一个唯一的标识，这个标识我们称之为扩展块ID,在HDFS集群之间都是惟一的，为以后集群归并创造了条件。
· 每个block pool内部自治，各自管理各自的block，不会与其他block pool交流
· namenode和block pool一起被称作namespace volume，它是管理的基本单位，当一个namespace被删除后，所有datanode上与其对应的block pool也会被删除。当集群升级时，每个namespace volume作为一个基本单元进行升级
· Block Pool允许一个命名空间在不通知其他命名空间的情况下为一个新的block创建Block ID。

b.datanode

· 每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。并执行来自所有Namenode的命令。
· DN中的数据结构都通过块池ID索引，即DN中的BlockMap，storage等都通过BPID索引。

四、部署

五、重要特征

1、主从架构

· namenode和datanode各司其职，共同协调完成分布式的文件存储服务。

2、分块存储机制

· hdfs中的文件在物理上是分块存储的
· 块的大小通过hdfs-default.xml配置文件中的dfs.blocksize指定，默认是128M
· 大文件拆成多个block,可以提高文件传输速度、负载均衡、存储大数据

3.副本机制

· 文件中的所有block都有副本，配置副本可降低数据丢失风险
· 全局副本数可通过hdfs-default.xml配置文件中的dfs.replication指定，默认是3副本
· 局部副本数可通过命令指定 hdfs dfs -setrep -R -w 2 hdfs://ns10/user/data/
· 默认三副本存储策略
第一块副本：优先存储在客户端本地，否则随机
第二块副本：不同于第一块副本的不同机架
第三块副本：和第二块副本相同机架的不同机器

· 若hdfs中副本数量没有达到配置的数量则会自动进行备份，此时datanode节点之间会大量复制文件，集群性能会暂时受到影响。
· 若hdfs中副本数量多于配置的数量，已存在的副本不会被删除，只会对后续新增的文件使用新的配置。
· 如果希望修改配置后，原有多出来的副本释放空间则可以执行balancer命令

HDFS 副本存放磁盘选择策略 : https://blog.csdn.net/CPP_MAYIBO/article/details/88209557

4、文件系统的命名空间 namespace

· Hdfs支持传统层次型文件组织结构，用户可以创建目录，然后上传文件到这些目录中。用户也可以创建、删除、移动或者重命名文件。
· hdfs给客户提供了一个统一的抽象目录树，客户端可通过路径来访问文件，访问形式 hdfs://namenode:port/dir-1/dir-2/t.txt
· namespace负责维护文件目录树，文件和块的位置信息，屏蔽了复杂的数据存储结构，方便用户访问和使用文件
· namespace由namenode 维护，任何对namespace的修改都会被nn记录下来。
· inode 文件目录树节点，也称索引节点，存储文件或者目录相关的元数据信息，包含名称、时间、父节点、拥有者、所在组等信息
· Namenode中代表了一个树状结构即Namespace的类是 INode类。INode类是一个抽象类，表示的是目录和文件的抽象，INodeFile和INodeDirectory是具体实现。
· 文件目录没有副本数概念

5、元数据管理

· 元数据信息即文件本身属性，由namenode管理维护。
· 记录文件元数据信息，是为了方便查找文件
· namenode管理的元数据包括文件自身属性信息和文件块位置映射信息。
· 文件自身属性信息包括文件名、文件大小、文件块大小、副本个数、权限、修改时间等

· 文件块位置映射信息：记录文件块和dn之间的映射信息，即哪个块在哪个节点上

· namenode内部通过内存和磁盘文件两种方式管理元数据，分为内存元数据和元数据文件

a. 内存元数据

· 元数据存在内存中的优点：高效操作，低延迟，缺点：数据不会持久化
· namenode把所有的元数据都存储在内存中，内存中的元数据是最完整的，包括文件自身属性信息、文件块位置映射信息
· namenode不会持久化存储每个文件中各个块所在的DataNode的位置信息，文件块的位置信息只存储在内存中，由dn启动自动加入集群时向nn进行数据块的汇报。并且后续间隔指定时间进行数据块报告
· snn负责恢复内存元数据

b. 元数据文件

· 元数据存在磁盘，可持久化数据
· 在磁盘上的元数据文件包括FileSystemImage(Fsimage)内存元数据镜像文件和edits log(Journal)编辑日志
· fsimage、editlog两个文件有专门的进程去管理，这个进程是JN（journalnode）日志结点。
· 当一个目录在网络文件系统NFS上时，即使机器损坏了，元数据也可以保存

· 存储地址 由dfs.namenode.name.dir指定，可以配置多个目录，各个目录存储的文件结构和内容完全一样，相当于备份

${dfs.namenode.name.dir}/current目录包括文件

1、fsimage内存镜像文件
· fsimage中只包含文件系统中文件自身属性相关的数据元信息，不包含文件块位置的信息。
· 负责将内存元数据中的文件自身属性持久化到fsimage内存镜像文件中
· 持久化是数据从内存到磁盘的IO过程，会对nn正常服务造成影响，所以不能频繁进行持久化
· 每个fsimage都会对应一个.md5文件，其中包含MD5校验和，hdfs使用该文件来防止磁盘损坏文件异常

· fsimage内存镜像文件 包含hadoop文件系统中的所有目录和文件idnode的序列化信息。目录包含修改时间、访问控制权限等信息；文件包含修改时间、访问时间、块大小和组成一个文件块信息等。
· fsimage内存镜像文件内容不能直接查看
oiv可以将hdfs fsimage文件内容转为人类可读的格式
oiv 是offline image viewer的缩写
命令: hdfs oiv -i fsimage_0000 -p XML -o fsimage.xml

2、Edits log（Journal）编辑日志
· 为避免两次持久化之间数据丢失，edits log文件中记录了hdfs所有更改操作的日志
· 日志内容不可修改
· Edits log不可直接查看
oev可将 edits文件转为人类可查看的格式，hadoop集群不在运行状态也可使用
oev是offline edits viewer的缩写
命令：hdfs oev -i edits_000 -o edits.xml

3、VERSION 文件

· 包含集群标识，防止dn意外注册到其它集群的nn上
· 这些标识在联邦部署中特别重要。联邦模式下会有多个nn独立工作
· namespace ID：每个集群的唯一命名空间
· blockpoolID：当前集群下的唯一文件块池
· clusterID：将多个集群组合成一个逻辑集群。clusterID相同表示在一个集群中，就是一个业务线。当一个Namenode被格式化的时候，这个标识被指定或自动生成，这个ID会用于格式化集群中的其它Namenode。
· storageType：说明存储的是什么进程的数据结构信息
nn节点storageType =data_node
· cTime：nn系统创建时间
· LayoutVersion：元数据格式的版本

· HDFS联邦拥有多个独立的命名空间。其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。
· 每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。

4、seen_txid文件
· 保存上次checkpoint时 EditLog最新的一个结束事务id
· seen_txid内存不会在每次事务操作时更新，只会在checkpoint时更新
· nn启动时会检查seen_txid文件,已验证至少可加载该数目的事务，否则nn将终止执行
· 当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件，进行元数据恢复。如果该文件丢失或记录的事务ID有问题，会造成数据块信息的丢失。

c. nn元数据恢复

1、nn启动时会先加载fsimage文件中的内容到内存中，之后再执行edits文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读写操作，也是最完整的元数据。
2、当客户端对hdfs中的文件进行新增或者修改操作时，操作记录会被记入edits日志文件中。当客户端操作成功，相应的元数据会更新到内存元数据中。（fsimage文件一般GB级别，为不影响系统运行，对文件进行更新操作时不会更新fsimages）
3、secondaryNameNode会定期合并fsimage文件和edits log ，
snn checkpoint–触发机制
core-site.xml中dfs.namenode.checkpoint.period=3600 //两次checkpoint之间的时间间隔，默认1小时
core-site.xml中dfs.namenode.checkpoint.txns=10000 //最大没有执行checkpoint事务的数量

4、元数据合并流程
· checkpoint进行元数据合并，核心是把fsimage和edits log合并成新的fsimage
· 保证fsimage版本不断更新不会太旧，保证edits日志文件不会太大
snn checkpoint–流程
· 当触发checkpoint操作条件时，snn发送请求给nn滚动edits log。 然后nn会生产一个新的编辑日志文件edits new，便于记录后续操作记录
· snn将旧的edits log文件和上次fsimage下载到本地（使用http get方式）
· snn首先将fsimage加载入内存，然后一条一条执行edits文件中的操作，使得内存中的fsimage不断更新。合并结束,snn将内存中的数据dump生成一个新的fsimage文件（checkpoint之后fsimage文件不会被删除）
· snn将新生成的fsimage new文件复制到nn节点。

· 合并后的FsImage在SNN中也保存一份，当NN失效时，可以利用SNN中的FsImage进行恢复

d. HA 元数据的同步

· 当Active Node上更新了namespace，它自己保存一份记录，并将修改记录发送给JNS。
· Edits日志只能有一份，只有Active状态的namenode节点可以做写操作
· Standby noes将会从JNS中读取这些edits，并持续关注它们对日志的变更，Standby Node将日志变更应用在自己的namespace中
· 在failover发生之前，Standy持有的namespace与Active保持完全同步。

6、数据块存储

· 文件的各个block的具体存在管理由DataNode节点承担，每个block都可以在多个datanode上存储

六、访问

1、HDFS Shell CLI 客户端

· 命令行界面
· HDFS Shell CLI 支持多种文件系统，包括本地文件系统（file:///）、分布式文件系统（hdfs://nn:8020）等

· 通过设置fs.defaultFS=hdfs://n1:8080/可指定默认的文件系统
· 跟文件系统读写相关的命令是hdfs dfs [generic options]
· hadoop dfs、 hdfs dfs、 hadoop fs三者的区别：
hadoop dfs ：只能操作hdfs文件系统，已经过时
hdfs dfs ：只能操作hdfs文件系统相关，包括于Local FS间的操作，常用
hadoop fs 可操作任意文件系统，官方推荐

2、HDFS Java 客户端API

· HDFS在生产应用中主要是java客户端的开发，其核心是从hdfs提供的api中构造一个访问客户端的hdfs对象，然后使用该客户端对象操作hdfs上的文件
· 客户端核心类之一：Configuration配置对象类，用于加载或设置参数属性
· 客户端核心类之一：FileSystem 文件系统对象基类。针对不同文件系统有具体的实现。该类分装了文件系统的相关操作方法
本地文件系统对应的类LocalhostFileSystem ，分布式文件系统对应的类DistributedFileSystem

a. 实现

· 添加hadoop-common、hadoop-hdfs、hadoop-client依赖包


· 创建junit单元测试

· 创建文件夹

· 设置客户端权限

· 上传文件

3、LibHDFS客户端

· LibHDFS是基于JNI的C API

4、HDFS Rest HTTP API

· webhdfs提供了访问hdfs的Restful接口，内置组件，默认开启。
· 集群外的客户不安装hadoop和java环境就可以对hdfs进行访问，且客户端不受语言的影响
· 客户端请求某文件时，webHDFS会将请求重定向到资源所在的datanode

· 访问格式：http://host:port/webhdfs/v1/path?op=

a. HttpFS

· HttpFS是一个独立于HDFS的服务，提供RESTful接口的网关的服务器，对hdfs中文件的CURD操作全部可以交给httpfs服务进行中转，然后由HttpFS和HDFS集群交互。

· HttpFS需手动安装，HttpFS 配置
{
· 停止器群
· 配置允许root用户通过代理访问的主机节点 hadoop.proxyuser.root.hosts=*
· 配置允许root用户通过代理访问的用户所属组 hadoop.proxyuser.root.groups=*
· 重启hdfs集群
}
· HttpFS默认服务


· httpfs访问需访问指定访问用户身份，格式：http://host:port/webhdfs/v1/path?user.name=root&op=

· WebHDFS和HTTPFS之间的区别

5、HDFS WEB Interfaces

· 通过web界面操作文件系统，并获取和hdfs相关的状态属性信息
· 地址: http://nn:port/

· Namenode启动后就可以访问web页面，但是功能不全

七、HDFS文件存储细节

1、目录规划

2、HDFS文件压缩

10、文件压缩
· 压缩算法优劣指标：压缩比越高越好、压缩 / 解压缩吞吐量越高越好、算法简单、无损压缩、恢复效果好、压缩后的文件支持切分
· hadoop对文件压缩均实现org.apache.hadoop.io.compress.CompressCodec接口，所有的实现类都在org.apache.hadoop.io.compress包下

· hadoop支持的压缩方法对比



· 合理使用压缩可提高HDFS的存储效率
· 压缩意味着CPU 内存需要参与编码、解码
· 主要在mapper reduce阶段. 会指定压缩格式
· hadoop常采用LZO压缩格式

3、HDFS文件存储格式

· HDFS文件存储格式分为行式存储、列式存储和行列混合存储
· 行式存储即同一行数据存储在一起，适合插入，不适合查询
· 列式存储即同一列数据存储在一起，适合查询，不适合插入
· 大数据中ORC、parquet、Avro使用较多

行式存储文件

1、 Text File ,比如.csv .json .xml .txt

· 特点：回车符区分不同行数据，易读性好
· 缺点：不支持块级别压缩

2、sequence file 序列化文件

· 每条数据记录（record）都是以key、value键值对进行序列化存储（二进制文件存储格式）
· 通常作为中间数据存储格式，比如将大量小文件合并放到一个序列化文件中
· 支持 多个record级、block级压缩、支持文件切分。
· record就是kv键值对，值保存在value中，record级别的压缩就是针对value进行压缩
· 序列化文件由一个header、一个或者多个record、多个sync组成
· header结构

SEQ4：SEQ表示该文件是序列文件，4表示实际版本号
Sync Marker：同步标记，用于可以读取任意位置的数据
· 未压缩格式的序列化文件：record部分包括record length、key length、key、value，每隔几个record就有一个同步标记，一般隔100字节左右
· 基于record压缩的sequence file,record部分包括record length、key length、key、compressed value(被压缩的值)，每隔几个record就有一个同步标记，一般100字节左右

· 基于block压缩格式的序列化文件，block包括：record条数、压缩的key长度、压缩的keys、压缩的value长度、压缩的values。每隔一个block就有一个同步标记
· 多个record记录组成一个块，这个block和hdfs中分块存储的block不是同一概念
· block压缩比record压缩提供更好的压缩率，首选block压缩

· 优点：二进制格式存储，比文本文件更紧凑、支持基于Record和Block压缩、文件可拆分和并行处理，适用于MapReduce程序
· 缺点：二进制文件不方便查看，只有java api可于之进行交互，尚且不支持其它语言
· 序列化文件读写
开发环境

写文件

读文件

3、Avro File
· 每个Avro File都包含JSON格式的schema定义
· 支持block压缩、支持切分
· Avro直接将一行数据序列化在一个block中
· 适用于大量频繁写入宽表数据（字段多列多）的场景，其序列化和反序列化很快

行列混合存储文件

1、RCFile
· Hive Record Columnar File(记录列文件)，这种类型的文件首先将数据按行划分为行组，然后在行组内部将数据存储在列中。很适合在数仓中执行分享。且支持压缩和切分。
· 不支持schema扩展，如果需要添加新的列，必须重写文件，这会降低操作效率

2、ORC File
· 内部将数据划分为默认大小为250M的Stripe。每个条带均包含索引、数据和页脚。
· 索引存储每列的最大值和最小值，以及列中每一行的位置
· ORC File首先根据Stripe分割整个表，在每个Stripe内进行按列存储
· ORC File以二进制方式存储，不可以直接读取
· ORC File有多种文件压缩方法，文件可切分

3、Parquet File
· Parquet的存储模式主要由行组（Row Group）、列块（Column Chuck）、页（page）组成。
· 在水平方向将数据划分为行组，默认行组大小与hdfs block块大小对齐，Parquet保证一个行组会被一个Mapper处理
· 行组中的每一列保存在列块中，一个列块具有相同的数据类型，不同的列块可使用不同的压缩方式。
· Parquet是页存储方式，没一个列块包含多个页，一个页是最小的编码单位，同一列块的不同页可使用不同的编码方式
· 文件的首部都是该文件的magic code，用于校验它是否是一个Parquet文件

大数据新一代存储格式Apache Arrow

BigData File Viewer工具

· 桌面应用程序，用于查看常见的大数据二进制格式，如Parquet,ORC,AVRO等。
· 支持本地文件系统、HDFS、AWS、S3等
· 可以将二进制格式的数据转换为文本格式的数据，如CSV格式
· 支持数组、映射、结构等复杂的数据类型
· 支持win、mac、linux等多种平台

4、HDFS异构存储类型

· 要存储的数据按热度分类：冻、冷、温、热

· hdfs中定义了4中异构存储类型：RAM_DISK(内存)、SSD（固态硬盘）、DISK（机械硬盘，默认使用）、ARCHIVE(高密度存储介质，存储历史数据)

· 通过修改hdfs-site.xml文件中的dfs.datanode.data.dir=[SSD]file:///grid/dn,[DISK]file:///grid/dn2 可以指定集群中的数据存储目录的存储介质

5、HDFS存储策略

· hdfs的BlockStoragePolicySuite类定义了6种数据存储策略

· 按冷热数据区分
（1）HOT(默认策略) , 数据块都存储在DISK中,处理中的数据使用此策略 (4)
（2）WARM， 既有热数据，又有冷数据。热数据存储在disk中，冷数据存储在archive中（5）
（3）CODE，数据块都存储在ARCHIVE中，不再使用的数据使用该策略 （ 6）
· 按磁盘性质区分
（1）ALL_SSD ， 数据块都存储在SSD中 （2）
（2）ONE_SSD ，副本之一存储在SSD中，其余都存储在DISK中（3）
（3）LAZY_PERSIST ，用于在内存中写入具有单个副本的块，副本首先写入RSM_DISK,再写入DISK中（1）
· LAZY_PERSIST使用：

（1）安装tmpfs 临时文件系统，tmpfs是基于RAM的文件系统
（2）将tmpfs挂载到指定目录下
mount -t tmpfs -o -size=1g tmpfs /mnt/dn/
（3）设置存储介质
修改hdfs-site.xml文件，配置参数dfs.datanode.data.dir=[RAM_DISK]file:///grid/dn
需要在dn上配置，否则nn不知道dn都有哪些磁盘的类型
（4）开启异构存储
dfs.storage.policy.enabled=true
（5）配置内存缓存量大小
dfs.datanode.max.locked.memory
（6）设置存储策略
hdfs storagepolicies -setStoragePolicy -path /s -policy HOT

6、小文件解决方案

· hdfs不擅长存储小文件，因为每个文件最少一个block，每个block的元数据都会占用nn内存，如果存在大量小文件，会占用nn的大量内存

使用Archive合并小文件

· Archive可以把多个文件归档成一个文件，归档后还可以透明的访问每一个小文件

创建archive
· hadoop archive -archiveName test.har -p /smallfile /srcdir /targetdir
-archiveName 指定要创建的存档的名称，扩展名称是*.har
-p 指定src文件的相对路径
· 在/targetdir目录下创建一个名为test.har的存档文件
· Archive归档是通过MapReduce程序完成的，需要启动YARN集群
· 创建archive文件需要消耗和原文件一样多的硬盘空间
· 创建archive时，源文件不会被更改或者删除
· archive文件不支持压缩，尽管archive文件看起来像已经被压缩过
· archive文件一旦创建就不可以改变，如果要修改，需要创建新的archive文件

查看归档后的文件
hdfs dfs -ls /targetdir/test.har
har://nnhost:port/targetdir/test.har

· test.har目录下包含两个索引文件_index和_masterindex， _index 通过index文件可以去找原文件
· _masterindex
· 多个part文件，part文件是多个原文件的集合

· _success 标记成功与否的文件 ，对应的_fail

查看归档前的文件
har://nnhost:port/targetdir/test.har

解压归档文件
并行解压存档文件，提高效率：hadoop distcp har://nnhost:port/dest/test.har/* /smailfile1
串行解压存档文件：hdfs dfs -cp har://nnhost:port/dest/test.har/* /smailfile1

使用序列化方式合并小文件

· 写小程序把所有小文件写入序列化文件中，文件名作为key，文件内容系列化后作为value序列化到sqquence file中
· 实现
添加小文件路径

7、HDFS写数据流程

Pipeline管道

· Pipeline管道是hdfs在上传文件写数据过程中采用的一种数据传输方式。
· 数据以管道的方式，顺序的沿着一个方向传输，能充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接。最小化推送所有数据的延时。
· 在线性推送模式下，每台机器所有的出口宽带都以最快的速度传输数据，而不是在多个接受者之前分配宽带

ack应答

· 确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符，表示发来的数据已确认接收无误。

流程

1、客户端创建FileSystem对象实例DistributeFileSystem,FileSystem封装了与文件系统操作的相关方法
2、调用DistributeFileSystem对象的create()方法，通过RPC请求namenode创建文件。
namenode执行各种检查判断目录文件是否存在、父目录是否存在、客户端是否具有创建文件的权限。检查通过后namenode就会为本次请求记一条记录，返回FSDataoutputStream输出流对象给客户端用于写数据
3、客户端通过FSDataoutputStream开始写入数据。FSDataOutputStream是DFSOutputStream包装类。
4、客户端写入数据时，DFSOutputStream将数据分成一个个数据包(packet)，并写入一个内部数据队列(data quequ).
DFSOutputStream 有一个内部类DataStreamer，用于请求NameNode挑选出适合存储数据副本的一组DataNode,默认是3副本存储。DataStreamer将数据包流式传输到pipeline的第一个DataNode，该DataNode存储数据包并将它pipeline的第二个DataNode，第二个DataNode存储数据包并将它发送到pipeline的第三个DataNode
5、DFSOutputStream也维护着一个内部数据包队列来等待DataNode 的收到确认回执，称之为ack queue，收到pipeline中所有DataNode确认信息后，该数据包才会从确认队列删除。
6、客户端完成数据写入后，在FSDataOutputStream输出流上调用close()方法关闭。
7、DistributeFileSystem联系NameNode告知其写入完成，等待NameNode确认。
因为NameNode已经知道文件由哪些块组成，因此仅需等待最小复制块可成功返回。最小复制块由dfs.namenode.replication.min指定，默认是1

7、EC策略 纠删码技术

· 对数据进行分块，然后计算出一些冗余的校验块。当一部分数据块丢失时，可以通过剩余的数据块和校验块计算出丢失的数据块。
· 提高存储利用率
· EC模式：包括EC组(例如6 + 3)中的数据和奇偶校验块的数量，以及编解码器算法(例如Reed-Solomon，XOR)
· 条带化单元的大小： 决定了条带读取和写入的粒度、缓冲区大小和编码工作。
· 策略被命名为编解码器-数据块-奇偶校验-块单元大小。当前，支持五种内置策略：RS-3-2-1024k，RS-6-3-1024k，RS-10-4-1024k，RS-LEGACY-6-3-1024k，XOR-2-11024k。
https://blog.csdn.net/Androidlushangderen/article/details/51923582
XOR策略
XOR是”异或”的意思,XOR码的原理如下:
数据编码时按照位进行异或运算,数据恢复的时候也就是解码时则通过结果与其他数据位进行异或操作的逆运算.
异或操作与我们常见的”与”操作和”或”操作略有不同,遵循”相同为0,不同则为1”的运算原则.比如下面的例子(⊕就是异或操作的意思):

1 ⊕ 1 = 0;
0 ⊕ 0 = 0;
1 ⊕ 0 = 1;
0 ⊕ 1 = 1;
0 ⊕ 1 ⊕ 1 = 0;
现在假设最后一个式子中的第二位,就是数字第一个数字1丢失了,变成了下面这个式子:
0 ⊕ ? ⊕ 1 = 0;
我们可以通过异或操作的逆运算恢复数据,因为最后结果为0,所以0 ⊕ ?的结果应该为1,也就是0 ⊕ ? = 1,因为异或运算,不同才为1,所以这里丢失的数据就是1,数据成功恢复.但是这里暴露出了一个问题,如果丢失或损坏的数据位超过1位的时候,数据好像就不是那么好恢复了,比如丢失了头2位:
? ⊕ ? ⊕ 1 = 0;
这个时候头2位是0,1还是1,0呢?只能说都有可能.OK,从这里我们可以看出XOR编码算法存在可容忍错误过少的问题,那么有什么别的EC算法能帮我们解决这个问题呢?在很多场合下,是会存在多个数据丢失的情况的,并不能确保每次只有1个数据出错的情况.下面介绍的新的编码算法能解决这个棘手的问题.

Reed-Solomon Codes
Reed-Solomon Codes也是EC编码中的一种.Reed-Solomon Codes缩写为RS码,中文名称里德所罗门码.下面说说RS码在HDFS中的使用原理.RS码在使用的时候需要指定2个参数的,RS(k, m),k代表的是data cell数据块的数量,m代表的是parity cell块的数量,parity cell可理解为加密块,因为它是由数据块编码产生的.RS码的恢复原理如下:

数据块如果发生损坏,则可以通过parity cell和其他data cell的解码计算重新恢复.
如果加密块发生损坏,则可以通过data cell重新进行编码生成.
以上数据块与加密块的编解码原理与矩阵运算有点关联,感兴趣的同学可以查阅相关资料继续学习.注意了,以上数据块出错的最大容忍数为m.不过这个数字我们可以进行调整,比如RS(6, 3)或RS(10, 4)等.这里的数据块与加密块的存储方式与传统的数据存放方式略有不同,它是横向式的条带式存储,而不是传统的连续存储方式


上图对应的EC编码类型是RS(6, 3).前面从DataNode0_{5总共6个节点存数据块,后面的DataNode6}8存的则是加密块.其实我们可以看到,HDFS EC的独有的条带式的存储方式与原有的存储方式存在着非常大的不同.这势必会带来数据读写方式的改变.而HDFS EC是如何做到其中的适配呢?还有一个问题,HDFS EC下的数据能支持原来的许多的HDFS的一些特性吗,Snapshot?EncryptionZone?HDFS Cache?

八、数据安全和隐私保护

1、Trash垃圾桶

· 类似于win的垃圾回收站，主要用于存放用户临时删除的文档资料，存放在回收站的文件可以恢复
· 默认情况下Trash垃圾桶没有被开启，删除操作会直接删除数据，不可恢复
· HDFS会为每个用户创建一个专属的回收站目录
· 启动trash功能
1.关闭集群，stop-dfs.sh
2.修改core-site.xml文件
fs.trash.interval=1440(分钟)：回收站中的文件多长时间后会被系统永久删除，如果等于0，Trash功能被禁用
fs.trash.checkpoint.interval=14(分钟)：前后两次检查点的创建时间间隔。新的检查点创建后，旧的检查点会被系统永久删除。等于0，则该值默认等于fs.trash.interval的值
3、同步集群配置文件
scp -r / $PWD4、启动hdfs集群start-dfs.sh\cdot 查看回收站目录/user/${username}/.Trash/
· trash目录下文件 一种是current目录，一种是数字结尾的目录（checkpoint）

· 最近删除的文件被移动到回收站Current目录。

· 跳过trash直接删除文件
hdfs dfs -rm -skipTrash /a.txt

· 恢复文件或者目录
cp、mv

· 手动清空trash
hdfs dfs -expunge
第一次执行hadoop fs -expunge时，HDFS会新建一个checkpoint并把最近删除存放在Trash/current中的文件移至checkpoint下；
下一次hadoop fs -expunge执行时，该checkpoint下的所有文件会被永久删除；

Trash Checkpoint

· 是.Trash下的数字结尾的目录，用于存储在创建检查点之前删除的所有文件或者目录
· 在可配置的时间间隔内，hdfs会为在current回收站目录下的文件创建检查点/user/${username}/.Trash/<日期>，并在过期时删除旧的检查点
· Trash在于包容误删除，checkpoint在于恢复误删除
· 数字结尾的目录其实是checkpoint的时间，201109110929。 这个表示20年11月09日11点09分29秒
· 原理：NameNode启动时会在后台启动一个emptier守护线程，用于定时（NameNode重启周期清零）清理HDFS集群上每个用户下的回收站数据，定时周期为fs.trash.checkpoint.interval。

2、snapshot快照

· 数据存储时某一时刻的状态记录
· 默认快照不开启
· 区别于备份：数据存储的某一时刻的副本
· 不是简单的拷贝，只做差异的记录，只拷贝有变更的inode数据
· 在目录节点下创建snapshot节点，任何子节点的变化都同步记录到snapshot上。删除文件时将文件元信息和数据移动到snapshot下
· /a目录允许创建快照，可以给/a目录创建快照，不可以给/a/s创建快照
· 快照只可读
· 创建快照的目录不可修改也不可删除
· 对目录创建Snapshot，创建之后不管后续目录发生什么变化，都可以通过snapshot找回原来的文件和目录结构。

作用

· 数据恢复：数据被误删后，通过snapshot恢复数据
· 数据备份：管理员以某时刻的快照作为备份的起始节点，通过比较不同备份之间的差异，增量备份
· 数据测试：使用快照的数据测试，避免原数据损坏

启用快照

	hdfs dfsadmin -allowSnapshot

原理

当前有/a/a.txt
· 给目录/a创建快照s ， a目录下会新增一个/a/.snapshot/s目录。

· hdfs dfs -ls /a/.snapshot/s查看快照目录下有a.txt文件。Datanode中的block不会被复制，snapshot节点中是记录了文件块的列表和大小信息
· 在a目录下新增、修改、删除文件或者目录，inode节点的变化信息会同步记录snapshot节点上，snapshot会按照时间顺序逆序的记录下来inode节点的变更,同时将变更的数据额外拷贝下来
· 删除a目录下的a.txt文件，a.txt将被移动到snapshot节点下，不会直接删除元信息和数据。
· 恢复a.txt时可以从a/.snapshot/s下拷贝一份文件到a目录下，达到恢复文件的目的
· 给a目录再创建快照m，对比快照s 和m的区别

3、权限管理

认证、授权和审计是计算机安全领域的架构模式，简称AAA

· 用户需要先证明自己的身份，然后根据规则被授予权限，同时用户的操作被记录下来留待审计
· 认证：登录linux系统，ssh a@node1 并输入密码，和/etc/passwd密码文件中验证
· 授权：给a账户授予管理员可执行的命令，记录在/etc/sudoers文件中
sudo service sshd status
· 审计：查看操作记录
tail /var/log/secure

HDFS身份认证

· hdfs不负责身份认证，它通过调用其它接口返回的信息来确定身份
· 目前社区支持简单认证（Simple）和Kerberos认证
· HDFS默认 hadoop.security.authentication=simple

simple认证

· 基于hdfs客户端所在linux系统的登录用户名进行认证
· 缺点：使用不同的账号登录同一个客户端，会产生不同的用户名，在多租户场景下会导致权限混淆
账号容易伪造，不安全。生产环境不会使用

Kerberos

· 网络身份认证协议，通过使用密钥加密技术为客户端、服务端应用程序提供强身份认证

· 密钥分发中心KDC包含
Authentication Server :AS
验证client的身份，验证成功返回TGT凭证
Ticket Granting Service :TGS
通过AS发送给Client的票TGT换取访问Service端的凭证ST

域

· 域的产生是为了解决企业内部的资源管理问题
· 域控服务器：在计算机网络域内响应安全身份认证请求的网络服务器，负责允许发出请求的主机访问域内资源，以及对用户进行身份验证，存储用户账户信息，并执行域的安全策略。
· 一个域可以有多个域控制器，提高高可用性和容错能力
· 密钥分发中心KDC服务默认会安装在一个域的域控中，client和service为域内的用户或者服务
· client是否有权限访问service端的服务由KDC发放的票据ST来决定

hdfs权限管理

· 作为分布式文件系统,hdfs也集成了一套权限管理系统

UGO权限管理

· hdfs默认的权限管理
· hdfs文件权限和linux系统的UGO模式类似，每个文件和目录都与一个拥有者和一个组相关联
drwxr-xr-x

				d代表目录
				USER 创建文件的用户 拥有rwx权限
				GROUP 和该用户在同一组的用户拥有r-x权限
				OTHER：其它组的用户拥有r-x权限

· 对hdfs目录权限，读：ls；写:mkdir rm ；执行
对hdfs文件权限，读： cat head tail ；写：appendToFile；hdfs 中文件没有可执行概念

umask权限掩码
· 和linux类似，用于设置新建文件和目录的默认权限
fs.permissions.umask-mode=022
默认目录权限drwxr-xr-x
默认文件权限-rw-r-r-
用户组映射Group Mapping服务
· 可调命令获取获取用户所对应的用户组列表
· 可以使用linux系统自带的，也可以使用第三方插件LDAP、Ranger
· Hdfs默认使用linux系统的组映射服务
· 用户信息存储在/etc/passwd中

用户名：口令：用户标识号：组标识号：注释性描述：主目录：登录shell
· 用户组信息存储在/etc/group中

组名：密码：GID:该用户组中的用户列表
该用户组是该用户的初始组，该用户不会写入该字段
该用户组中的用户 显示的是这个用户组的附加用户

UGO权限管理缺点
用户组映射Group Mapping 维护成本高
当有个别用户不是目录的组用户时，无法灵活授权

ACL权限管理

· Access Control List
· 优点：可以为特点的用户或者组设置特定的权限
· 通过配置dfs.namenode.acls.enabled=true开启acl，重启集群
· 命令
设置acl权限
hdfs dfs -setfacl -m user:username:rwx /path
设置默认acl权限
hdfs dfs -setfacl -m default:user:username:rwx /path

				删除指定的acl条目
					hdfs dfs -setfacl -x user:username:rwx /path
				删除基本acl条目以外的所有条目
					hdfs dfs -setfacl -b /path
				删除默认acl权限
					hdfs dfs -setfacl -k /path
			显示文件或者目录的访问控制列表

hdfs dfs -getfacl -R

				全部替换
					hdfs dfs -setfacl --set user::rw-,user:hadoop:rw-,group::r--,other::r-- /path
				查看
					drwxr-xr-x+
					（带acl权限的文件或者目录后面会多一个+）

4、代理用户

· 访问namenode需要allen身份，但是allen身份没有kerberos凭证，连不上namenode。admin有kerberos凭证，可以连接上namenode
· 超级用户admin代表普通用户提交作业或者访问hdfs
· core-site.xml设置代理用户
root用户从host1,host2连接模拟group1和group2的用户，用户代理哪些主机的哪些组
hadoop.proxyuser.root.hosts=host1,host2
hadoop.proxyuser.root.groups=group1,group2

		root用户从任意主机模拟任意用户
			hadoop.proxyuser.root.hosts=*
			hadoop.proxyuser.root.groups=*

5、透明加密

· hdfs中的文件块内容默认是明文存储
直接访问/export/atat/hadoop-3.1.4/dfs/data/current/subdir0

加密技术

· 利用密码技术对信息进行加密，保护信息安全
· 数据加密：通过加密算法和加密密钥将明文变为密文
· 数据解密：通过解密算法和解密密钥把密文变成明文
· 常见的加密层级
应用层加密
安全灵活
实现困难
数据库层加密
有性能问题
索引不能加密
文件系统层加密
容易实施
无法满足细化的要求
磁盘层加密
易于部署、性能高
只能防止用户从物理层面盗窃数据

hdfs透明加密

· 支持端到端的透明加密，端到端是指加密和解密只能通过客户端
· hdfs保存的是加密后的文件，文件加密的密钥也是加密的
· 特点
a. hdfs集群管理和密钥管理是互相独立的职责，分别由hdfs管理员和密钥管理员承担
b. 秘钥 由第三方软件管理，hdfs无法访问未加密的数据或者加密密钥
c. 从操作系统考取的文件是密文
d. 客户端上传的文件加密，查看的时候自动解密。 对客户端是明文的，其他途径看数据都是加密的
e. 采用AES-CTR加密算法
AES-CTR默认支持128位加密密钥
· 密钥库keystore：第三方软件,存储密钥的库 keystore
· 密钥管理服务KMS， Key Management Server 简称KMS，KMS是hdfs开发的秘钥管理服务，用作HDFS客户端和密钥库之间的代理
· KMS职责：获取keystore中的密钥EZ 、使用EZ KEY将DEK加密生成EDEK、使用EZ KEY 将EDEK解密生成DEK
· 创建加密区域：给加密区域生成两个密钥，EZ密钥和，DEK密钥
· EZ密钥 叫 加密区域密钥，保存在keystore中
· DEK密钥 叫 数据加密密钥，DEK是加 | 解密一个文件的密钥，保存在KMS上
· KMS 使用 EZ 密钥对 DEK进行加密 生成加密数据加密密钥EDEK， EDEK存储在namenode上，后台不断从KMS中拉取新的EDEK到nn缓存中。DEK的加解密过程只在KMS内存中进行

· 文件加密存储

1、client向nn请求在hdfs加密区域新建文件
2、nn从缓存中取出一个新的edek，并保存在文件的元数据中
3、nn把edek发送给client
4、client将edek发送给kms
5、kms用对应的ez key将edek解密生成dek
6、kms将 dek发送给client
7、client用dek加密文件内容后发送给dn存储

· 文件解密
1、client向nn请求读取加密区域文件
2、nn直接从加密文件的元数据里获取到edek 发送给client
4、client将edek发送给kms
5、kms用对应的ez key将edek解密生成dek
6、kms将 dek发送给client
7、client从dn读取文件，并用dek解密
· 使用
1、关闭集群
2、创建keystore

3、配置kms-sit.xml

4、配置kms-env.sh

5、配置

6、启动hdfs

7、创建key
hadoop key create ezk
hadoop key list -metadata

8、创建加密区
hdfs crypto -createZone -keyName ezk -path /zone
9、上传文件到加密区并读取

10、获取加密文件信息