1、HDFS 系统介绍
Hadoop 分布式文件系统HDFS(Hadoop Distributed File System)是一个能够兼容普通硬件环境的分布式文件系统,和现有的分布式文件系统不同的地方是,Hadoop 更注重容错性和兼容廉价的硬件设备,这样做是为了用很小的预算甚至直接利用现有机器就实现大流量和大数据量的读取。Hadoop 使用了POSIX 的设计来实现对文件系统文件流的读取。HDFS 原来是Apache Nutch 搜索引擎(从Lucene 发展而来)开发的一个部分,后来独立出来作为一个Apache 子项目。
HDFS 是基于流数据模式访问和处理超大文件的需求而开发的,它可以运行于廉价的商用服务器上。HDFS 在设计时的假设和目标包括以下几个方面:
(1) 硬件出错:Hadoop 假设硬件出错是一种正常的情况,而不是异常,为的就是在硬件出错的情况下尽量保证数据完整性,HDFS 设计的目标是在成百上千台服务器中存储数据,并且可以快速检测出硬件错误和快速进行数据的自动恢复。(用软件的方式来屏蔽底层中硬件的差异,也可以以软件的方式无限的增加硬件)
(2)流数据读写:不同于普通的文件系统,Hadoop 是为了程序批量处理数据而设计的,而不是与用户的交互或者随机读写,所以POSIX 对程序增加了许多硬性限制,程序必须使用流读取来提高数据吞吐率。
(3)大数据集:HDFS 上面一个典型的文件一般是用GB 或者TB 计算的,而且一个数百台机器组成的集群里面可以支持过千万这样的文件。简单的文件模型:HDFS 上面的文件模型十分简单,就是一次写入多次读取的模型,文件一旦创建,写入并关闭了,之后就再也不会被改变了,只能被读取,这种模型。 刚好符合搜索引擎的需求,以后可能会实现追加写入数据这样的功能。(写入并且关闭后只支持追加的写)
(4)强大的跨平台兼容性:由于是基于Java 的实现,无论是硬件平台或者是软件平台要求都不高,只要是JDK 支持的平台都可以兼容。
正是由于以上的种种考虑,我们会发现,现在的HDFS 在处理一些特定问题时,不但没有优势,而且有一定的局限性,主要表现在以下几个方面:
(1)不适合低延迟数据访问:如果要处理一些用户要求时间比较短的低延迟应用请求,则HDFS 不适合。HDFS 是为了处理大型数据集分析任务,主要是为了达到较高的数据吞吐量而设计的,这就可能以高延迟作为代价。目前的一些补充的方案,比如使用HBase,通过上层数据管理项目来尽可能地弥补这个不足。
(2)无法高效存储大量小文件:在Hadoop 中需要使用NameNode(目录节点)来管理文件系统的元数据,以响应客户端请求返回文件位置等,因此,文件数量大小的限制要由NameNode 来决定。例如,每个文件、索引目录及块大约占100 字节,如果有100 万个文件,每个文件占一个块,那么,至少要消耗200MB 内存,这似乎还可以接受。但是,如果有更多文件,那么,NameNode 的工作压力更大,检索处理元数据的时间就不可接受了。
(3)不支持多用户写入及任意修改文件:在HDFS 的一个文件中只有一个写入者,而且写操作只能在文件末尾完成,即只能执行追加操作。目前HDFS 还不支持多个用户对同一文件的写操作,以及在文件任意位置进行修改。
2、什么是ACL
2.1. linux acl(在文件分布式系统中是非常重要的,是访问控制级别或则访问控制层)
ACL 就是Access Control List 的缩写,中文意思就是访问控制列表,其主要作用可以用来提供除传统的ower、group、others 的read、write、execute 权限之外的具体权限的设置。ACl 可以针对单一用户、单一文件或目录进行读写执行等权限的设置,可以实现更加灵活的权限设置,这样的权限设置对于有特殊权限需求的使用情况是非常有帮助的。
注意:sla是对可靠性描述的指标,比如对云计算、分布式存储系统等的衡量,当sla指标比较高的时候,说明其可靠性较高(一般为几个9来构成的),荡机的可能性将会变少。
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 系统架构
总结上述图:
上图的hdfs系统架构说明namenode是整个架构的核心,存储了元数据(Metadata);Rack是机柜(Rack1就是一个集群,包含3个机柜)。此图说明我们只要拿到namenode中数据的存储位置,然后告诉client,client读取数据流的时候只会从副本集(Replication,在datanodes中)中去读取,以达到不会对namenode节点造成压力,达到了负载均衡的效果,此时真正在进行工作的是机柜,机柜来进行相应的输出操作,从而不是namenode进行输出了。-----是webhdfs的基本原理。
3.1.1 Block
HDFS 中的文件在物理上是分块存储(block),块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在hadoop2.x 版本中是128M,老版本中是64M。
3.1.2 Namenode(是花名册,根据花名册上的每个datanode分配并且调度任务)
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
(1) 是一个镜像,分担namenode 的工作量;是NameNode 的快照备份;合并fsimage和fsedits然后再发给namenode 。
(2)Fsimage:元数据镜像文件(文件系统的目录树)。
(3)edits:元数据的操作日志(针对文件系统做的修改操作记录)。
(4) namenode内存中存储的是=fsimage+edits。
(5)SecondaryNameNode 负责定时默认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 会自动从其他数据节点迁移数据过来。-----hdfs已经自动实现了(比如数据拷贝3份等)。
3.2.4 维护多个FsImage 和Editlog 的拷贝。目录节点上的fsimage 和edits 日志文件是HDFS 的核心数据结构,如果这些文件损坏了,HDFS 将失效。因而,目录节点可以配置成。
笔记:对于hdfs的高可用性来说,是对hdfs中的namenode来进行相应的高可用操作的,因为datanode已经是高可用的了(默认有3份副本);所谓namenode的高可用就是一个主备模式,举例当有一个A和B两个计算机的时候,当A计算机挂了,B计算机就会运行起来,并且A计算机中的数据会和B进行一个共享(共享的方式就是通过Quorum Journal Manager来进行实现导入数据的,把数据导入到B计算机中),当A计算机又好了的时候,B计算机会处于一个离线备份的一个状态。--------------具体实现高可用是通过两种方式来进行的:zookeeper(进行主从选举的一种方式)和keepalive(心跳包)方式来实现。
3.3 配置文件
3.3.1 core-site.xml
(1)fs.defaultFS :这个属性用来指定namenode 的hdfs 协议的文件系统通信地址,可以指定一个主机+端口,也可以指定为一个namenode 服务(这个服务内部可以有多台namenode 实现hadoop的namenode 服务)。
(2)hadoop.tmp.dir : hadoop集群在工作的时候存储的一些临时文件的目录。
3.3.2 hdfs-site.xml
(1)dfs.namenode.name.dir:namenode 数据的存放地点。也就是namenode 元数据存放的地方,记录了hdfs 系统中文件的元数据。
(2)dfs.datanode.data.dir:datanode 数据的存放地点。也就是block 块存放的目录了。
(3)dfs.replication:hdfs 的副本数设置。也就是上传一个文件,其分割为block 块后,每个block 的冗余副本个数,默认配置是3。
(4)dfs.secondary.http.address:secondarynamenode 运行节点的信息,和namenode不同节点。
笔记:在hadoop的安装目录下的etc中看配置文件
(1)capacity-scheduler.xml:主要是配置集群中物理存储上的一些存储容量。
(2)kms-acls.xml:主要是对数据进行一个透明加密。就是存储在hdfs中的数据都是通过加密了的,只能是自己的用户才能看;当其他用户把数据下载下来,如果没有相应的密钥,也是打不开数据的,打开了也是一些乱码。
3.4 权限控制
原生的hadoop(hdfs)对权限控制非常薄弱(以上是基于对用户名权限进行相应的控制的,只要在hdfs文件存储系统中注册了的用户,就可以进行访问,不要校验用户等操作),强化方案可以是以下几种:
(1) k8s---支持单点登录,是一个无服务器架构。
(2) spring security
(3) cloudera(https://www.cloudera.com/)
注意:对于cloudera版本的hadoop对权限控制有进一步的加强。
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。
(1) Curl 介绍
Curl是一个命令行参数,可以用来发送http请求,在linux系统中可以进行。
https://www.cnblogs.com/duhuo/p/5695256.html
(2) Postman
(3) 配置
在hdfs-site.xml 中配置:
命令:curl -i -L "http://localhost:50070/webhdfs/v1/user/Ginger/input/6_1.txt?op=OPEN"
注意:WebHDFS的效率要比HttpFS高,WebHDFS不需要配置任何东西,而HttpFS需要配置(手动配置),WebHDFS通过发送http请求来进行访问hdfs。
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
3.8.2 httpfs-site.xml
4、性能评测
jmeter配置:( 在java中jmeter主要是用来做压力测试的)