1. HDFS 系统介绍
Hadoop 分布式文件系统HDFS(Hadoop Distributed File System)是一个能够兼容普通硬件环境的分布式文件系统,和现有的分布式文件系统不同的地方是,Hadoop 更注重容错性和兼容廉价的硬件设备,这样做是为了用很小的预算甚至直接利用现有机器就实现大流量和大数据量的读取。Hadoop 使用了POSIX 的设计来实现对文件系统文件流的读取。HDFS 原来是Apache Nutch 搜索引擎(从Lucene 发展而来)开发的一个部分,后来独立出来作为一个Apache 子项目。
HDFS 是基于流数据模式访问和处理超大文件的需求而开发的,它可以运行于廉价的商用服务器上。HDFS 在设计时的假设和目标包括以下几个方面:
硬件出错:Hadoop 假设硬件出错是一种正常的情况,而不是异常,为的就是在硬件出错的情况下尽量保证数据完整性,HDFS 设计的目标是在成百上千台服务器中存储数据,并且可以快速检测出硬件错误和快速进行数据的自动恢复。
流数据读写:不同于普通的文件系统,Hadoop 是为了程序批量处理数据而设计的,而不是与用户的交互或者随机读写,所以POSIX 对程序增加了许多硬性限制,程序必须使用流读取来提高数据吞吐率。
大数据集:HDFS 上面一个典型的文件一般是用GB 或者TB 计算的,而且一个数百台机器组成的集群里面可以支持过千万这样的文件。简单的文件模型:HDFS 上面的文件模型十分简单,就是一次写入多次读取的模型,文件一旦创建,写入并关闭了,之后就再也不会被改变了,只能被读取,这种模型。 刚好符合搜索引擎的需求,以后可能会实现追加写入数据这样的功能。
强大的跨平台兼容性:由于是基于Java 的实现,无论是硬件平台或者是软件平台要求都不高,只要是JDK 支持的平台都可以兼容。正是由于以上的种种考虑,我们会发现,现在的HDFS 在处理一些特定问题时,不但没有优势,而且有一定的局限性,主要表现在以下几个方面:不适合低延迟数据访问:如果要处理一些用户要求时间比较短的低延迟应用请求,则HDFS 不适合。HDFS 是为了处理大型数据集分析任务,主要是为了达到较高的数据吞吐量而设计的,这就可能以高延迟作为代价。目前的一些补充的方案,比如使用HBase,通过上层数据管理项目来尽可能地弥补这个不足。无法高效存储大量小文件:在Hadoop 中需要使用NameNode(目录节点)来管理文件系统的元数据,以响应客户端请求返回文件位置等,因此,文件数量大小的限制要由NameNode 来决定。例如,每个文件、索引目录及块大约占100 字节,如果有100 万个文件,每个文件占一个块,那么,至少要消耗200MB 内存,这似乎还可以接受。但是,如果有更多文件,那么,NameNode 的工作压力更大,检索处理元数据的时间就不可接受了。不支持多用户写入及任意修改文件:在HDFS 的一个文件中只有一个写入者,而且写操作只能在文件末尾完成,即只能执行追加操作。目前HDFS 还不支持多个用户对同一文件的写操作,以及在文件任意位置进行修改。
2、什么是ACL
2.1. linux acl
ACL 就是Access Control List 的缩写,中文意思就是访问控制列表,其主要作用可以用来提供除传统的ower、group、others 的read、write、execute 权限之外的具体权限的设置。ACl 可以针对单一用户、单一文件或目录进行读写执行等权限的设置,可以实现更加灵活的权限设置,这样的权限设置对于有特殊权限需求的使用情况是非常有帮助的。

2.2 hdfs acl
Hadoop 中的ACL 与Linux 中的ACL 机制基本相同,都是用于为文件系统提供更精细化的权限控制。
hdfs dfs -setfacl -m user:hbase:rwx /user/tao/xt-data
hadoop dfs -getfacl /user/tao/xt-data
3、HDFS
3.1 系统架构

3.1.1 Block
HDFS 中的文件在物理上是分块存储(block),块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在hadoop2.x 版本中是128M,老版本中是64M.
3.1.2 Namenode
namenode 是HDFS 集群主节点,负责维护整个hdfs 文件系统的目录树,以及每一个路径(文件)所对应的block 块信息(block 的id,及所在的datanode 服务器)
hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o/home/hadoop/fsimage.xml -p XML
3.1.3 Secondarynode
是一个镜像,分担namenode 的工作量;是NameNode 的冷备份;合并fsimage和fsedits然后再发给namenode 。Fsimage:元数据镜像文件(文件系统的目录树)edits:元数据的操作日志(针对文件系统做的修改操作记录) namenode 内存中存储的是=fsimage+editsSecondaryNameNode 负责定时默认1 小时,从namenode 上,获取fsimage 和edits 来进行合并,然后再发送给namenode。减少namenode 的工作量。
3.1.4 Datanode
文件的各个block 的存储管理由datanode 节点承担,datanode 是HDFS 集群从节点,每一个block 都可以在多个datanode 上存储多个副本 (副本数量也可以通过参数设置dfs.replication)。HDFS 是设计成适应一次写入,多次读的场景,且不支持文件的修改。

3.2 容灾设计
3.2.1 在目录节点和数据节点之间维持心跳检测。当由于网络故障之类的原因,导致数据节点(DataNode)发出的心跳包没有被目录节点(NameNode)正常收到的时候,目录节点就不会将任何新的IO 操作派发给那个数据节点,该数据节点上的数据被认为是无效的,因此,目录节点会检测是否有文件块的副本数目小于设置值,如果小于就自动开始复制新的副本,并分发到其他数据节点上。
3.2.2 检测文件块的完整性。HDFS 会记录每个新创建的文件的所有块的校验和。当以后检索这些文件的时候,从某个节点获取块,会首先确认校验和是否一致,如果不一致,会从其他数据节点上获取该块的副本。
3.2.3 集群的负载均衡。由于节点的失效或者增加,可能导致数据分布的不均匀,当某个数据节点的空闲空间大于一个临界值的时候,HDFS 会自动从其他数据节点迁移数据过来。
3.2.4 维护多个FsImage 和Editlog 的拷贝。目录节点上的fsimage 和edits 日志文件是HDFS 的核心数据结构,如果这些文件损坏了,HDFS 将失效。因而,目录节点可以配置成。
3.3 配置文件
3.3.1 core-site.xml
fs.defaultFS :这个属性用来指定namenode 的hdfs 协议的文件系统通信地址,可以指定一个主机+端口,也可以指定为一个namenode 服务(这个服务内部可以有多台namenode 实现ha 的namenode 服务
hadoop.tmp.dir : hadoop 集群在工作的时候存储的一些临时文件的目录
3.3.2 hdfs-site.xml
dfs.namenode.name.dir:namenode 数据的存放地点。也就是namenode 元数据存放的地方,记录了hdfs 系统中文件的元数据。dfs.datanode.data.dir:datanode 数据的存放地点。也就是block 块存放的目录了。
dfs.replication:hdfs 的副本数设置。也就是上传一个文件,其分割为block 块后,每个block 的冗余副本个数,默认配置是3。
dfs.secondary.http.address:secondarynamenode 运行节点的信息,和namenode不同节点。
3.4 权限控制
原生的hadoop(hdfs)对权限控制非常薄弱,强化方案可以是以下几种:
3.4.1 k8s
3.4.2 spring security
3.4.3 cloudera(https://www.cloudera.com/)
3.5 WebUI

3.6 常用API
https://hadoop.apache.org/docs/r2.6.5/api/org/apache/hadoop/fs/FileSystem.html
3.7 WebHDFS
WebHDFS 是HortonWorks 开发的,然后捐给了Apache,目前是Hdfs 内置的务,默认处于开启状态。当client 请求某文件时,WebHDFS 会将其重定向到该资源所在的datanode。
3.7.1 Curl 介绍
https://www.cnblogs.com/duhuo/p/5695256.html

3.7.2 Postman

3.7.3 配置
在hdfs-site.xml 中配置:
<property>
<name>dfs.webhdfs.enabled</name>
<value>true</value>
</property>
curl -i -L "http://localhost:50070/webhdfs/v1/user/Ginger/input/6_1.txt?op=OPEN"
3.8 HttpFS
HttpFS 是HDFS 一个独立的服务,HttpFS 是Cloudera 开发的,也捐给了Apache。两者都是HDFS 的REST API,但稍有差异:当client 请求某文件时,WebHDFS 会将其重定向到该资源所在的datanode,而HttpFs 相等于一个“网关”,所有的数据先传输到该httpfs server,再由该httpfs server 传输到client。

配置项:
3.8.1 core-site.xml
<property>
<name>hadoop.proxyuser.Ginger.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.Ginger.groups</name>
<value>*</value>
</property>
3.8.2 httpfs-site.xml
<property>
<name>httpfs.proxyuser.Ginger.hosts</name>
<value>*</value>
</property>
<property>
<name>httpfs.proxyuser.Ginger.groups</name>
<value>*</value>
</property>
4、性能评测
配置


网友评论