1&2 大数据发展趋势 & HDFS和ZooKeeper【HCIA-BigData】
文章目录
- 1、大数据发展趋势与鲲鹏大数据
-
-
- **大数据应用的主要计算模式**
- **Hadoop大数据生态圈**
- **华为云大数据服务**
-
- 2、HDFS分布式文件管理系统和ZooKeeper
-
- 2.1 导读
- 2.2 HDFS 分布式文件管理系统（Hadoop Distributed File System）
-
- 1. 特性
- 2. 基本系统架构
- 3. HDFS体系结构与局限性
- 4. HDFS通信协议
- 5. HDFS高可用性（High availability，HA）
- 6. 元数据的持久化（备份-合并-覆盖）
- 7. HDFS联邦（Federation）
- 8. 数据副本机制与完整性保障
- 9. HDFS常用shell命令
- 10. HDFS 3.0新特性
- 11. HDFS数据写入与读取流程
- 2.3 ZooKeeper
-
- 1. ZooKeeper体系架构
- 2. ZooKeeper关键特性
- 3. ZooKeeper读特性
- 4. ZooKeeper写特性
- 5. ZooKeeper客户端常用命令
- 2.4 本章总结
- 2.5 课后习题
1、大数据发展趋势与鲲鹏大数据
大数据应用的主要计算模式
Hadoop大数据生态圈
Hadoop成为大数据批量处理的基础，但无法提供实时分析。
华为云大数据服务
2、HDFS分布式文件管理系统和ZooKeeper
2.1 导读
大数据平台提供的最基本的两个功能是什么？
存储和计算能力
HDFS主要包括哪些角色？
NameNode，DataNode，Client
大数据生态圈组件为什么需要Zookeeper去提供分布式协调？
2.2 HDFS 分布式文件管理系统（Hadoop Distributed File System）
1. 特性
- 高容错性：认为硬件总是不可靠的；
- 高吞吐量：对大量数据访问的应用提供吞吐量支持；
- 大文件存储：支持存储TB-PB级别的数据。
擅长：大文件存储与访问、流式数据访问
不擅长：大量小文件存储、随机写入、多用户写入、低延迟读取
2. 基本系统架构
HDFS架构包含三个部分：NameNode，DataNode，Client。
- NameNode：用于存储、生成文件系统的元数据，运行一个实例。
- DataNode：用于存储实际的数据，将自己管理的数据块上报给NameNode ，运行多个实例。
- Client：支持业务访问HDFS，从NameNode ,DataNode获取数据返回给业务。多个实例，和业务一起运行。
Block 块
HDFS默认一个块128MB，一个文件被分成多个块，以块做存储单位。块的大小远远大于普通文件系统,可以最小化寻址开销。
抽象的块概念可以带来一下几个明显的好处：
- 支持大规模文件存储：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。
- 简化系统设计：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据
- 适合数据备份：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性
NameNode 和 DataNodes
| NameNode | DataNodes |
|---|---|
| 存储元数据 | 存储文件内容 |
| 元数据保存在内存中 | 文件内容保存在磁盘中 |
| 保存文件 block,datanode之间的映射关系 | 维护了block id 到datanode本地文件的映射关系 |
-
名称节点（NameNode）记录了每个文件中各个块所在的数据节点的位置信息。NameNode维护文件系统名称空间。对文件系统名称空间或其属性的任何更改均由 NameNode记录。应用程序可以指定应由HDFS维护的文件副本的数量。文件的副本数称为该文件的复制因子，此信息由NameNode存储。
保存了两个核心的数据结构，即FsImage和EditLog。
- FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。
- 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作。
-
数据节点（DataNode）是分布式文件管理系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并向名称节点上报自己所存储的块的列表。
每个数据节点的数据会被保存在各自节点的本地Linux文件系统中。
客户端Client
- 客户端是用户操作HDFS最常用的方式，HDFS在部署时都提供了客户端。严格来说，客户端并不算是HDFS的一部分。
- HDFS客户端是一个库，包含HDFS文件系统接口，这些接口隐藏了HDFS实现中的大部分复杂性。
- 客户端可以支持打开、读取、写入等常见的操作，并且提供了类似Shell的命令行方式来访问HDFS中的数据。
- HDFS也提供了Java API，作为应用程序访问文件系统的客户端编程接口。（HDFS本身就是由Java开发）
3. HDFS体系结构与局限性
HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点（NameNode）和若干个数据节点（DataNode）。
- 名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。
- 集群中的数据节点一般是一个节点运行一个数据节点进程，负责处理文件系统客户端的读/写请求，在名称节点的统一调度下进行数据块的创建、删除和复制等操作。
- 每个数据节点的数据实际上是保存在本地Linux文件系统中的。
HDFS单名称节点体系结构的局限性
HDFS只设置唯一个名称节点，这样做虽然大大简化了系统设计，但也带来了一些明显的局限性：
- 命名空间的限制：名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制。
- 性能的瓶颈：整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。
- 隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此无法对不同应用程序进行隔离。
- 集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。
利用zookeeper实现主备NameNode可以解决单点NameNode故障问题。
4. HDFS通信协议
- 所有的HDFS通信协议都是构建在TCP/IP协议基础之上的。
- 客户端通过一个可配置的端口向名称节点主动发起TCP连接，并使用客户端协议与名称节点进行交互。
- 名称节点和数据节点之间则使用数据节点协议进行交互。
- 客户端与数据节点的交互是通过RPC（Remote Procedure Call，远程过程调用）来实现的。在设计上，名称节点不会主动发起RPC，而是响应来自客户端和数据节点的RPC请求。
一台计算机上的程序调用另一台计算机的程序时，就称之为 一次远程过程调用
5. HDFS高可用性（High availability，HA）
HDFS的高可靠性（HA）主要体现在利用zookeeper实现主备NameNode，以解决单点NameNode故障问题。
- ZooKeeper主要用来存储HA下的状态文件、主备信息。ZK个数建议3个及以上且为奇数个。
- NameNode主备模式，Active NameNode提供服务，Standby NameNode同步主元数据并作为主的热备。
- ZKFC（ZooKeeper Failover Controller）用于监控NameNode节点的主备状态。
- JN（JournalNode）用于存储Active NameNode生成的Editlog。 Standby NameNode加载JN上Editlog，同步元数据。
心跳机制是定时发送一个自定义的结构体(心跳包),让对方知道自己还活着,以确保连接的有效性的机制。
ZKFC控制NameNode主备仲裁
ZKFC作为一个精简的仲裁代理，其利用zookeeper的分布式锁功能，实现主备仲裁，再通过命令通道，控制NameNode的主备状态。ZKFC与NN部署在一起，两者个数相同。
元数据同步
- 主NameNode对外提供服务。生成的Editlog同时写入本地和JN，同时更新主 NameNode内存中的元数据。
- 备NameNode监控到JN上Editlog变化时，加载Editlog进内存，生成新的与主NameNode一样的元数据。元数据同步完成。
- 主备的FSlmage仍保存在各自的磁盘中，不发生交互。FSlmage是内存中元数据定时写到本地磁盘的副本，也叫元数据镜像。
6. 元数据的持久化（备份-合并-覆盖）
fsimage第一次读进备份，后面每次只读editlog，此时创建editlog.new继续工作，备份NN合并为fsimage.ckpt，传回主节点，覆盖fsimage落盘，再把editlog.new覆盖editlog。
- EditLog：记录用户的操作日志，用以在FSImage的基础上生成新的文件系统镜像。
- FSImage：用以阶段性保存文件镜像。
- FSImage.ckpt：在内存中对FSImage文件和EditLog文件合并(merge)后产生新的FSImage，写到磁盘上，这个过程叫checkpoint.。备用NameNode加载完fsimage和EditLog文件后， 会将merge后的结果同时写到本地磁盘和NFS。此时磁盘上有一份原始的fsimage文件和一份新生成的checkpoint件fsimage.ckpt。 而后将fsimage.ckpt改名为fsimage（覆盖原有的fsimage）。
- EditLog.new：NameNode每隔1小时或Editlog满64MB就触发合并，合并时将数据传到 Standby NameNode时，因数据读写不能同步进行，此时NameNode产生一个新的日志文件 Editlog.new用来存放这段时间的操作日志。Standby NameNode合并成fsimage后回传给主NameNode替换掉原有fsimage，并将Editlog.new 命名为Editlog。
7. HDFS联邦（Federation）
超大规模文件存储时，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，NN成为了性能的瓶颈。
各NameNode负责自己所属的目录。与Linux挂载磁盘到目录类似，此时每个NameNode只负责整个hdfs集群中部分目录。如NameNode1负责/database目录，那么在/database目录下的文件元数据都由NameNode1负责。各NameNode间元数据不共享，每个NameNode都有对应的standby，两两之间并不互相通信，一个失效也不会影响其他NameNode。
8. 数据副本机制与完整性保障
副本距离计算公式：
- Distance(Rack1/D1, Rack1/D1)=0：同一台服务器的距离为0。
- Distance(Rack1/D1, Rack1/D3)=2：同一机架不同的服务器距离为2。
- Distance(Rack1/D1, Rack2/D1)=4：不同机架的服务器距离为4。
- 不同数据中心的节点距离为6。
副本放置策略：
- 第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点。
- 第二个副本：放置在与第一个副本不同的机架的节点上。
- 第三个副本：与第一个副本相同机架的其他节点上。
- 更多副本：随机节点。
- 如果写请求方所在机器是其中一个DataNode，则直接存放在本地，否则随机在集群中选择一 个DataNode。
HDFS数据完整性保障
HDFS主要目的是保证存储数据完整性，对于各组件的失效做了可靠性处理。
- 重建失效数据盘的副本数据
- DataNode与NameNode之间通过心跳周期汇报数据状态，DataNode向NameNode周期上报失败时，如DataNode因硬盘损坏未上报数据块，NameNode将发起副本重建动作以恢复丢失的副本。
- 集群数据均衡
- HDFS架构设计了数据均衡机制，此机制保证数据在各个DataNode上分布是平均的。
- 元数据可靠性保证
- 采用日志机制操作元数据,同时元数据存放在主备NameNode上。
- 快照机制实现了文件系统常见的快照机制,保证数据误操作时,能及时恢复。
- 安全模式
- HDFS提供独有安全模式机制，当节点硬盘故障时，进入安全模式，HDFS只支持访问元数据。此时HDFS上的 数据是只读的，其他的操作如创建、删除文件等操作都会导致失败。待硬盘问题解决、数据恢复后，再退出安全模式。
9. HDFS常用shell命令
10. HDFS 3.0新特性
- 支持HDFS中的纠删码Erasure Encoding，EC技术可以防止数据丢失，又可以解决HDFS存储空间翻倍的问题，一般用于存储冷数据。
- 基于HDFS路由器的联合，简化了对现有HDFS客户端的联合集群的访问。
- 支持多个NameNode。
- DataNode内部添加了负载均衡Disk Balancer。
11. HDFS数据写入与读取流程
写入：
读取：
**
2.3 ZooKeeper
Zookeeper分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力。
1. ZooKeeper体系架构
- Zookeeper集群由一组Server节点组成,这一组Server节点中只存在一个Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的 Follower节点。
- 启动时选举出leader。ZooKeeper选举时，当某一个实例获得了半数以上的票数时变为leader。
- Leader节点在接收到数据变更请求后，先将变更写入本地磁盘，以作恢复之用。当所有写请求持久化到磁盘以后，才会将变更应用到内存中。（先写磁盘再写内存）
- ZooKeeper使用自定义的原子消息协议（ZooKeeper Atomic Broadcast Zab协议），保证了整个系统中的节点数据和状态的一致性。Follower 基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。
- 当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择一个 Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步(广播)到其他的Follower节点。
容灾能力
n为奇数时，成为leader的节点需获得x+1票，容灾能力为x。n为偶数时，成为leader的节点需要获得x+2票(大于一半)，容灾能力为x。
所以2x+1个节点与2x+2个节点的容灾能力相同，考虑到选举以及完成写操作的速度与节点数的相关性，ZooKeeper应部署奇数个节点。
2. ZooKeeper关键特性
- 最终一致性：无论哪个server，对外展示的均是同一个视图。
- 实时性：保证客户端将在一个时间间隔范围内获得服务器更新或失效的信息。
- 可靠性：一条消息被一个server接收，它将被所有server接受。
- 等待无关性：慢的或者失效的client不会干预快速的client的请求，使得每个client都能有效的等待。
- 原子性：更新只能成功或者失败，没有中间状态。
- 顺序一致性：客户端所发送的更新会按照它们被发送的顺序进行应用。
3. ZooKeeper读特性
由ZooKeeper的一致性可知，客户端无论连接哪个server，获取的均是同一个视图。所以，读操作可以在客户端与任意节点间完成。
4. ZooKeeper写特性
- 同读请求一样，客户端可以向任一server提出写请求，server将这一请求发送给leader。
- leader获取写请求后，会向所有节点发送这条写请求信息，询问是否能够执行这次写操作。
- follower节点根据自身情况给出反馈信息ACK应答消息，leader根据反馈信息，若获取到的可以执行写操作的数量大于实例总数的一半，则认为本次写操作可执行。
- leader将结果反馈给各follower，并完成写操作，各follower节点同步leader的数据，本次写操作完成。
5. ZooKeeper客户端常用命令
2.4 本章总结
- 分布式文件系统是大数据时代解决大规模数据存储问题的有效解决方案，HDFS开源实现了GFS，可以利用由廉价硬件构成的计算机集群实现海量数据的分布式存储。
- HDFS具有兼容廉价的硬件设备、流数据读写、大数据集、简单的文件模型、强大的跨平台兼容性等特点。但是也要注意到，HDFS也有自身的局限性，比如不适合低延迟数据访问、无法高效存储大量小文件和不支持多用户写入及任意修改文件等。
- 块是HDFS核心的概念，一个大的文件会被拆分成很多个块。HDFS采用抽象的块概念，具有支持大规模文件存储、简化系统设计、适合数据备份等优点。
- ZooKeeper分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力。
2.5 课后习题
思考题:
-
ZooKeeper为什么建议奇数部署?
容灾能力相同，但部署成本低
-
HDFS数据块为什么一般比磁盘块大?
块比磁盘大，目的是为了最小化寻址开销。块足够大，那么从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。但也不能太大，因为map通常只处理一个块中的数据。如果Map数太少，则作业运行速度会比较慢。
-
HDFS在数据写入时,能读取到吗?
当数据在写入的时候，写入数据不能立即可见，在命令空间是立即可见的。当写入超过一个块或者结束的时候，对一个新的reader就是可见的。当前正在写入的块，对其他reader是不可见的。
测试题：
- Leader：通过选举算法确定，Zookeeper集群工作的核心，也是事务性请求(写操作)的唯一调度和处理者，它保证集群事务处理的顺序性，同时负责进行投票的发起和决议，以及更新系统状态。
- Follower：负责处理客户端的非事务(读操作)请求，如果接收到客户端发来的事务性请求，则会转发给Leader，让Leader进行处理，同时还负责在Leader选举过程中参与投票。
- Observer：负责观察Zookeeper集群的最新状态的变化，并且将这些状态进行同步。对于非事务性请求可以进行独立处理，对于事务性请求，则会转发给Leader处理。通常用于在不影响集群事务处理能力的前提下，提升集群的非事务处理能力（提高集群读的能力，也降低了集群选主的复杂程度）。