Hadoop概述二 -- HDFS

Hadoop概述二 -- HDFS

一、设计思想

        1. 分块存储

                文件在hdfs中采用分块方式存储，hadoop2中数据块默认大小为128M。每个文件在hdfs中存储时被切分成多个大小相同的块，若数据大小不足128M也按照128M进行存储。

        2. 备份存储

                hdfs底层采用空间换取数据安全，每个数据块会复制多个副本存储在不同的节点上。多个副本之间互为备份，没有主次之分。

        3. 元数据

                记录数据的数据。数据在hdfs中分块存储，元数据记录着所有真实数据的路径等信息，相当于真实数据的索引，当需要查询某个数据时，首先查询元数据找到数据对应的数据块以及数据块对应的存储节点才能访问数据。

                1）元数据中存储的内容：

                        1. 抽象目录树。hdfs的目录结构与linux类似，以 / 为根目录。不同的是，hdfs存储是多台机器共同存储，根目录是多台机器共同的抽象根目录。

                        2. 数据和块的映射关系。即抽象目录树中的每个文件与其在hdfs中存储块的对应关系。

                        3. 块的存储位置。即每个数据块在集群中存储的节点。

                元数据中存储的这3部分内容，可以将数据文件与某一存储该数据的节点对应起来。

                2）元数据的存储位置

                        内存 + 磁盘

                        磁盘上存储内容：抽象目录树、数据和块的映射关系

                        内存上存储内容：抽象目录树、数据和块的映射关系、块的存储位置。（完整的原数据信息）

                        由于内存中的数据容易丢失，故需要在磁盘中存储一份。但由于磁盘读写速度慢，所有不会存储块的位置信息。块的位置信息在datanode向namenode发送心跳报告时才会补全，该内容会在后面内容中讲到。

二、HDFS架构

        HDFS采用主从架构。主节点namenode，从节点datanode，备份节点secondarynamenode。

        namenode作用：

                1. 管理元数据

                2. 接收客户端的读写请求

                3. 分配副本存放位置

                4. 负载均衡

        datanode作用：

                1. 存储数据

                2. 处理客户端的读写请求

                3. 发送心跳报告

        secondarynamenode作用：

                1. 备份元数据

                2. checkpoint

三、HDFS四大核心

        1. 心跳机制

                datanode每隔3秒向namenode发送心跳包，报告自己的存活状态和存储的块信息。10次心跳时间datanode没有收到心跳包，则会主动向datanode发送检查报告，若两次检查报告没有回应，则认为datanode宕机。

                心跳报告中会包含本节点存储的块信息，namenode收到这部分信息会补充进内存的元数据中。

        2. 安全模式

                安全模式是集群的一种自我保护状态，在该模式下会进行数据块的检查和复制工作，不对外提供服务。

                集群启动，namenode会先将元数据加载到内存中并接收datanode的心跳包，补全块的存储信息。同时会检查数据块的完整度，对缺失块进行复制，当块的完整度达到99.99%时自动退出安全模式。

        3. 机架策略

                副本的存放策略。相同的副本不可能存储在同一个节点中，机制策略解决的是数据存放在哪个节点的问题。以3个副本为例，第一份副本会存放在请求客户端所在的机器上（这样做只是在磁盘下对数据复制一份，不会因为网络产生数据丢失问题）。若请求客户端不在集群中，则在集群中选择任意一个节点存储。第二个副本存储在与第一台机器不同机架的任意节点上，目的防止机架断点。第三个副本存放在与第二个副本相同机架的不同节点上。

                目的是用空间换数据安全，数据存储尽量分隔开，存放在不同节点、不同机架、不同数据中心。

        4. 负载均衡

                负载均衡与硬件配置相关，HDFS在集群空闲时会自动进行负载均衡，自动负载均衡的带宽默认是1M，集群规模较小（20个节点）时可以依赖集群的自动负载均衡。

四、HDFS两大机制

        1. 文件上传

                写数据流程：

                1）客户端向namenode发送文件上传请求

                2）namenode会进行一系列检查，父目录是否存在、文件是否已经上传、权限等。若检查没有问题，则会发送允许上传请求。

                3）客户端发送真正的上传请求，包含文件大小等信息

                4）namenode向客户端返回上传文件的节点

                5）客户端准备上传并对文件进行逻辑切分

                6）客户端构建第一个数据块的pipline（文件上传通道），pipline是由一组存储节点构成的一个文件传输通道。客户端将文件发送给pipline中的第一个节点，第一个节点将文件发送个pipline中的第二个节点，在上传过程中，若一个节点宕机，客户端会立即重试一次，若还是失败，则将该节点剔除出pipline，由剩余节点继续构成新的pipline。客户端只要保证最终有一个副本 上传成功即可，剩余的副本可等到集群空闲时自动进行数据块的异步复制。

                7）客户端真正开始文件上传。文件上传以package为单位，每个package512byte。数据上传中先传入节点的内存，节点每接收到一个package就将其写入磁盘并同时传给pipline中下一个节点。

                8）数据上传成功后pipline会从后向前依次相应，客户端收到成功响应后关闭pipline

                9）开始进行第二个块的上传，重复5-8

                10）所有的块上传成功后，客户端向namenode发送上传成功相应

        2. 文件下载

                1）客户端向namenode发送文件下载请求

                2）namenode会进行一系列检查。若检查没有问题，则开始查询元数据库，返回数据对应的块以及块的存储位置

                3）客户端收到块的存储信息，采用就近原则进行数据下载。若下载失败，客户端会立即重试，若依旧失败，则将失败节点返回给namenode，同时会继续从其它节点进行下载。

                4）第一个块下载完成之后进行crc检验，校验通过代表下载成功

                5）进行第二个块的下载，重复4

                6）当所有的数据块下载成功之后，客户端向namenode发出成功相应

五、checkpoint

        元数据合并过程。

        元数据信息存储的文件类型：

                1. edits文件。历史日志文件，记录元数据的 *** 作日志

                2. edits_inprogress。正在编辑的日志文件

                3. fsimage。磁盘镜像文件，存储的是真实的元数据信息序列化之后的文件

                4. seen_txid。合并点，记录下次需要合并的edits文件的编号

        元数据修改为什么需要记录edits文件？

                直接修改fsimage文件会消耗大量namenode的时间和io，所以不会直接将元数据的修改写在fsimage中，而是先写在edits中，合并的工作由secondarynamenode完成，根据edits文件中记录的日志 *** 作修改fsimage文件。

                fsimage = 旧的fsimage + edits文件

        checkpoint过程：

                1. secondarynamenode定时向namenode发送请求，询问namenode是否需要元数据合并

                2. namenode相应元数据合并询问请求

                3. secondarynamenode向namenode发送元数据合并请求

                4. namenode将正在编辑的edits文件回滚，同时会生成一个全新的edits_inprogress文件用于处理当前的客户端请求。

                5. secondarynamenode将回滚完成的edits文件（从seen_txid到最新回滚位置的edits文件）和fsimage文件拉取到本地

                6. secondarynamenode在内存中对edits文件和fsimage文件进行合并，合并完成后写入磁盘并重命名为fsimage.checkpoint文件

                7. secondarynamenode将新的fsimage.checkpoint文件发送给namenode，并重命名为fsimage将原来的文件覆盖

        元数据更新过程：

                1. 在edits_inprocess中追加修改 *** 作

                2. 修改内存中的元数据

                内存中的元数据永远是最新的完整的元数据