HDFS概述
- HDFS(Hadoop Distributed File System,Hadoop分布式文件系统)是一种旨在在商品硬件上运行的分布式文件系统。
- HDFS最初是作为ApacheNutchWeb搜索引|擎项目的基础结构而构建的。
- HDFS是Apache Hadoop Core项目的一部分。
- HDFS具有高度的容错能力,旨在部署在低成本硬件上。
- HDFS提供对应用程序数据的高吞吐量访问,并且适用于具有大数据集的应用程序。
- HDFS放宽了一些POSIX要求,以实现对文件系统数据的流式访问。
HDFS相关概念
HDFS基本系统架构
客户端(Client)
- 客户端是用户操作HDFS最常用的方式,HDFS在部署时都提供了客户端。
- HDFS客户端是一个库,包含HDFS文件系统接口,这些接口隐藏了HDFS实现中的大部分
- 复杂性。
- 严格来说,客户端并不算是HDFS的一部分。
- 客户端可以支持打开、读取、写入等常见的操作,并且提供了类似shell的命令行方式来
- 访问HDFS中的数据。
- HDFS也提供了JavaAPI,作为应用程序访问文件系统的客户端编程接口。
名称节点(NameNode)
在HDFS中,名称节点(NameNode)负责管理分布式文件系统的命名空间(Namespace),保存了两个核 心的数据结构,即FsImage和EditLog。
- FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。
- 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作。
数据节点(DataNode)
- 数据节点是分布式文件系统HDFS的工作节点,负责数据的存储和读取,会根据客户端或者是名称节点的调度来进行数据的存储和检索,并且向名称节点定期发送自己所存储的块的列表。
- 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。
块(Block)
- HDFS默认一个块128MB,一个文件被分成多个块,以块作为存储单位。
- 块的大小远远大于普通文件系统,可以最小化寻址开销。
- 抽象的块概念可以带来以下几个明显的好处:
-
- 支持大规模文件存储
-
- 简化系统设计
-
- 适合数据备份
HDFS体系结构
HDFS体系结构
HDFS命名空间管理
- HDFS的命名空间(NameSpace)包含目录、文件和块。
- HDFS使用的是传统的分级文件体系,因此,用户可以像使用普通文件系统一样,创建、删除目录和文件,在目录间转移文件,重命名文件等。
- NameNode维护文件系统命名空间。对文件系统命名空间或其属性的任何更改均由NameNode记录。
通信协议
HDFS是一个部署在集群上的分布式文件系统,因此,很多数据需要通过网络进行传输。
- 所有的HDFS通信协议都是构建在TCP/IP协议基础之上的。
- 客户端通过一个可配置的端口向名称节点主动发起TCP连接,并使用客户端协议与名称节点进行交互。
- 名称节点和数据节点之间则使用数据节点协议进行交互。
- 客户端与数据节点的交互是通过RPC(RemoteProcedureCall)来实现的。在设计上,名称节点不会主动发起RPC,而是响应来自客户端和数据节点的RPC请求。
HDFS单名称节点体系结构的局限性
HDFS只设置唯一一个名称节点,这样做虽然大大简化了系统设计,但也带来了一些明显的局限性,具体如下:
- 命名空间的限制:名称节点是保存在内存中的,因此,名称节点能够容纳的对象(文件、块)的个数会受到内存空间大小的限制。
- 性能的瓶颈:整个分布式文件系统的吞吐量,受限于单个名称节点的吞吐量。
- 隔离问题:由于集群中只有一个名称节点,只有一个命名空间,因此,无法对不同应用程序进
- 行隔离。
- 集群的可用性:一旦这个唯一的名称节点发生故障,会导致整个集群变得不可用。
HDFS关键特性
HDFS高可用性(HA)
元数据持久化
HDFS联邦(Federation)
数据副本机制
HDFS数据完整性保障
HDFS主要目的是保证存储数据完整性,对于各组件的失效,做了可靠性处理。
-
重建失效数据盘的副本数据
DataNode向NameNode周期上报失败时,NameNode发起副本重建动作以恢复丢失副本。
-
集群数据均衡
HDFS架构设计了数据均衡机制,此机制保证数据在各个DataNode上分布是平均的。
-
元数据可靠性保证
采用日志机制操作元数据,同时元数据存放在主备NameNode上。
快照机制实现了文件系统常见的快照机制,保证数据误操作时,能及时恢复。
-
安全模式
HDFS提供独有安全模式机制,在数据节点故障,硬盘故障时,能防止故障扩散。
HDFS架构其他关键设计要点说明
- 空间回收机制: 支持回收站机制,以及副本数的动态设置机制。
- 数据组织: 数据存储以数据块为单位,存储在操作系统的HDFS文件系统上。
- 访问方式: 提供JAVA API,HTTP方式,SHELL方式访问HDFS数据。
常用shell命令
HDFS数据读写流程
HDFS数据写入流程
HDFS数据读取流程
Zookeeper概述
- ZooKeeper分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题,提供分布式、高可用性的协调服务能力。
- ZooKeeper作为底层组件广泛被上层组件使用并依赖,如Kafka、HDFS、HBase、Storm等,提供配置管理、名字服务、分布式锁、集群管理等功能。
- ZooKeeper封装了复杂、易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
- 安全模式下ZooKeeper依赖于Kerberos和LdapServer进行安全认证,非安全模式则不依赖于Kerberos与LdapServer。
ZooKeeper体系架构
- ZooKeeper集群由一组Server节点组成,这一组Server节点中只存在一个Leader的节点,其他节点都为Follower。
- 启动时选举出Leader。
- ZooKeeper使用自定义的原子消息协议,保证了整个系统中的节点数据的一致性。
- Leader节点在接收到数据变更请求后,先写磁盘再写内存。
ZooKeeper容灾能力
- ZooKeeper能够完成选举即能够正常对外提供服务。
- ZooKeeper选举时,当某一个实例获得了半数以上的票数时,则变为leader。
- 对于n个实例的服务,n可能为奇数或偶数。
- n为奇数时,假定n=2x+1,则成为leader的节点需获得x+1票,容灾能力为x。
- n为偶数时,假定n=2x+2,则成为leader的节点需要获得x+2票(大于一半),容灾能力为x。
ZooKeeper关键特性
- 最终一致性:无论哪个Server,对外展示的均是同一个视图。
- 实时性:保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。
- 可靠性:一条消息被一个Server接收,它将被所有Server接受。
- 等待无关性:慢的或者失效的Client不会干预快速的Client的请求,使得每个Client都能有效的等待。
- 原子性:更新只能成功或者失败,没有中间状态。
- 顺序一致性:客户端所发送的更新会按照它们被发送的顺序进行应用。
ZooKeeper读特性
- 由ZooKeeper的一致性可知,客户端无论连接哪个Server,获取的均是同一个视图。所以,读操作可以在客户端与任意节点间完成。
ZooKeeper写特性
ZooKeeper客户端常用命令使用
- 调用ZooKeeper客户端,执行命令:zkCli.sh -server 172.16.0.1:24002
- 创建节点:create/node
- 列出节点子节点:Is/node
- 创建节点数据:set /node data
- 获取节点数据:get/node
- 删除节点:delete/node
- 删除节点及所有子节点:deleteall/node
思考
ZooKeeper为什么建议奇数部署?
HDFS的数据块大小为什么一般比磁盘块大?
HDFS的数据在写入时,能够读取到吗?
总结
- 分布式文件系统是大数据时代解决大规模数据存储问题的有效解决方案,HDFS开源实现了GFS,可以利用由廉价硬件构成的计算机集群实现海量数据的分布式存储。
- HDFS具有兼容廉价的硬件设备、流数据读写、大数据集、简单的文件模型、强大的跨平台兼容性等特点。但是,也要注意到,HDFS也有自身的局限性,比如不适合低延迟数据访问、无法高效存储大量小文件和不支持多用户写入及任意修改文件等。
- 块是HDFS核心的概念,一个大的文件会被拆分成很多个块。HDFS采用抽象的块概念,具有支持大规模文件存储、简化系统设计、适合数据备份等优点。
- ZooKeeper分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题,提供分布式、高可用性的协调服务能力。