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同时汇报自己的块信息。

     

     

     

     

     

     

     

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值