hadoop架构总结（二）

hadoop架构总结（二）

分布式文件系统HDFS-HA

随着互联网的进步，无论是PC还是移动，个人还是企业，每天都有PB级的数据产生，其中大部分的数据都是没有意义的，少部分数据可以用来计算分析，作决策。最典型的例子就是音乐推荐、电影推荐、移动购物推荐。平台将大量用户点击形成的日志文件存储起来，通过数据清晰、存储，再进行实时计算获得优质决策。

那么在大数据的背景下就需要有对应的大数据存储架构。以往的数据往往是存储在单台电脑上，带来的最直接的限制就是存储量与吞吐率。传统存储架构要完成大数据存储需要投入高额的硬件基础比如PB级的存储盘或者是增加硬件数量通过共享文件的方式。

增加硬件数量通过网络传输实现文件共享是分布式文件系统的雏形，但是会带来一些显而易见限制：

• 单机负载可能极高

  某些机器存储较热门的数据，很多用户会去访问这个机器，负载过大。

• 数据不安全

  机器损坏代表数据丢失

• 问价整理困难

  内存空间管理、存储路径管理等。

HDFS设计理念

当文件大小超过单台机器的存储能力时，就有必要将数据文件切割并存储在多台由计算机组成的集群中，集群内通过网络传输数据，HDFS对外抽象成一个统一的文件管理系统，实现单台计算机的使用感受。

• 支持超大文件存储

• 流式数据访问

• 简单的一致性模型，文件写入关闭后不支持修改

• 硬件故障检测和快速应对

  数据复制副本的形式分散在多个节点，一个数据损坏还有备份数据

HDFS架构

HDFS是一个主从架构，通常具有一个NameNode，SecondaryNameNode和至少一个DataNode。

1. NameNode

   namenode节点是集群主节点，对外提供服务，管理文件系统的命名空间保存了两个最核心的文件，文件镜像FsImage和编辑日志EditLog。FsImage记录了集群的目录树以及目录树中的所有子目录和文件，EditLog记录的是文件/目录的增加、删除、重命名等操作。

   集群在启动时会进入“安全状态”（对外只提供读取操作），加载FsImage文件到内存中，执行EditLog的操作。那么问题来了，随着系统的运行EditLog文件越来越大怎么办？

2. SecondaryNameNode

   一般称第二名称节点，作用有二：一是定时执行EditLog操作，合并FsImage。而是作为namenode的数据备份（非热备份，仍有数据丢失风险）。

   FsImage实际上是HDFS的永久性检查点，但并不是每次操作都直接写入FsImage文件，因为这是个庞大的文件，频繁执行写操作会造成系统运行缓慢。解决的办法是将操作信息记录在EditLog文件，但是EditLog会越来越大，如果namenode故障重启，加载EditLog回滚的时间就会越长，影响用户体验，所以需要定期合并FsImage与EditLog文件，但是namenode在外集群提供服务时就无法拥有足够的资源来处理合并操作，secondarynamenode应运而生。

   1）SecondaryNameNode与NameNode保持通信，定期请求NameNode的暂停使用EditLog文件，Namenode启动EditLog.new，记录合并期间的数据，secondaryNameNode复制FsImage和EditLog文件到本地。

   2）SecondaryNameNode加载FsImage到内存，执行EditLog操作，形成新的FsImage.ckpt文件，并将文件传回NameNode。

   3）namenode接收到.ckpt文件后，将FsImage.ckpt替换成FsImage，然后加载和启用该文件。

   4）加载完成将EditLog.new更名为EditLog。通常采用定时或文件到达固定阀值来触发一次合并

3. DataNode

   在namenode的指导下完成数据的I/O操作。文件会被切分成块的单位独立存放在数据节点中。Datanode定时向namenode汇报块信息，同时接收namenode的指令，如删除、创建、移动等。

4. 数据块

   与传统文件相同，分布式文件系统也有块的概念，不同的是分布式文件系统的块单位通常都是以MB为单位，它是HDFS处理的数据单元，之所以数据块这么大是为了最小化地址开销，这也决定了分布式文件系统处理的只能是粗粒度数据。分布式文件系统适合存储大文件，过多的小文件反而降低系统性能。另外值得注意的是，实际文件不足块大小也不会占据完整的块空间。

5. 读数据流程

   整个过程总结为客户端向namenode提出读取请求，namenode根据datanode节点返回的块信息，返回给客户端一个datanode文件存放信息，客户端根据信息直接访问datanode。不管是读数据还是写数据，客户端都是和datanode进行数据操作，减轻namenode的负担。

   1）首先调用FileSystem对象的open()方法，获得一个分布式文件系统（DistrubutedSystem)实例。

   2）DistrubutedSystem通过RPC获得文件的第一个块存放信息，同一个块的副本信息按照hadoop拓扑结构排列，距离客户端最近的排在前面（同机架甚至同一个机器）。

   3）得到文件系统数据输入流（FSDataInputStream）对象，该对象被封装为分布式文件系统输入流（DFSInputStream），方便管理Datanode和namenode的数据流。调用read方法会找出离客户最近的datanode连接

   4）read成功，数据从datanode远远不断流向客户端。如果第一个块读取完成，就会关闭第一个块的连接，建立下一个块的连接

   5）如果第一批块读取完成了，DFSInputStream就会从namenode请求下一批块，然后继续读。

   异常处理 如果在读取过程中，DFSInputStream和datanode通讯异常，就会尝试与副本数据所在的数据节点连接，并且会记录异常节点信息。DFSInputStream也会进行数据校验和，如果有数据损坏就会报告给namenode，namenode节点也会定期检查集群数据，重新生成数据副本。

6. 写入数据

   写数据总结为客户端向namenode提出写入请求，文件按照规定的块大小切割成独立的存储单元，每个块向namenode请求写入，namenode根据集群的使用情况，返回一个datanode列表。客户端找到第一个datanode传输第一个块，当第一个块数据传输4kb数据时，立即写入datanode磁盘，并尝试与列表中的下一个datanode建立连接，将4kb数据与datanode列表信息传入，形成流水线写入，直到数据按照datanode列表全部写入，此时副本的复制也完成。

   1）客户端通过调用DistrubutedSystem的create方法创建文件。

   2）DistrubutedSystem通过RPC调用namenode去创建一个没有块关联的新文件，创建前校验文件是否存在，当前是否有操作权限等。

   3）前两步返回文件系统数据输出流（FSDataOutputStream）的对象，被封装为分布式文件输出流（DFSOutputStream）。客户端开始写数据到DFSOutputStream，DFSOutputStream会把数据切分成一个个数据包（4kb），然后排成数据队列。

   4）接下来数据会传输到由多个节点构成的数据管道，按数据包的单位写入一个个datanode。

   5）DFSOutputStream还维护一个响应队列，这个队列也是由数据包组成，用于等待Datanode收到数据后的响应数据包，当数据管道中的所有daanode都表示已经收到响应信息时，ack quene才会吧对应数据包移除。

   6）所有数据写完后Close关闭数据流。

   异常处理 datanode有一个算一个，数据传输不会停止，传输结束后副本数少于规定副本数，namenode在执行集群检查的时候会安排新的datanode进行复制。

7. 数据块存放策略

   HDFS面对的由廉价计算机组成的集群系统，充分考虑了由硬件故障可能带来的数据丢失，采用副本的方式备份数据。默认副本数为3.

   对分布式集群来说，数据副本不会造成额外的数据存储负担，相反还有好处：

   • 提高可靠性。当前数据丢失可以从别的机器获取
   • 负载均衡。多个副本意味着可以同时响应多个客户端的请求
   • 提高访问效率。就近原则获取datanode数据

1）如果客户端在集群外请求数据存储，namenode根据集群的使用情况安排datanode；如果客户端在集群集群内发起请求，第一副本数据块会优先写入本地。

2）第二副本写入与第一副本相同机架的不同机器

3）第三副本写入与第一副本不同机架的任一机器

4）如果还有其他副本，则随机写入

• HDFS的优缺点

  优点

  1）高容错性，副本恢复机制。

  2）适合大数据存储。

  3）流式数据访问，一次写入多次读取，支持追加不支持修改。

  4）集群成本低。

  缺点

  1）不适合低延迟数据访问，在毫秒级比较难实现大数据量的吞吐。

  2）不适合大量小文件存储，大量小文件占据寻址地址，造成FsImage臃肿，从而限制系统的响应性能。

  3）不适合并发写入、文件随机修改。

   

  HDFS的新特性HA

  HA（high available）产生背景

  影响集群正常使用通常有两种情况，一是namenode宕机挂了；而是namenode升级暂停服务。

  前面提过在2.0中引入了SecondaryNamenode除了合并FsImage和EditLog，还有备份的作用，但是这个备份只发生在合并前，合并过程中如果发生了错误，还是会造成数据丢失或响应错误。另外在系统运行时间久后，数据量越大重启集群花费的时间越长。

  HA机制

  在集群中设置两个namenode，同一时刻只用一个namenode处于active活跃状态处理客户端的请求，另一个处于standby待机状态。EditLog文件通过一个文件同步系统实现两个namenode的同步。

  HA架构

• 

   

  HA架构分为下面几个部分：

  1）Active NN和Standby NN，在同一时刻只有一个处于Active对外提供服务。

  2）主备切换控制器（ZKFailoverControl,zkfc），作为独立进程运行，与namenode保持通讯，可以及时检测namenode健康状态，在主namenode出现故障时，提交zookeeper实现自动主备选取切换，也可以通过命令手动切换。

  3）zookeeper，采用过半机制为主备选举支持。过半机制既数量大于2且为奇数，只要满足过半机制就有效。

  4）共享存储系统，一般有Quorum Journal Manager和NFS，官方使用Quorum Journal Manager。主namenode更新数据后写入共享文件系统，StandbyNN检测有数据写入后立即拉取数据写入本地实现元数据同步。这个地方有个需要注意的，journalnode也是采用过半机制，属于最终一致性，也就是说当前三个journalnode只要active将数据成功写入两个，就当作是成功的。当主NN故障时，namenode检查数据一致后才开始对外提供服务。

  5）datanode，namenode被动接收datanode的块信息，所有datanode需要向active和standby同时汇报自己的块信息。