你好,游客 登录 注册 搜索
背景:
阅读新闻

Hadoop学习:深度剖析HDFS原理

[日期:2016-09-06] 来源:Linux公社   作者:tgzhu [字体: ]

在配置hbase集群将 hdfs 挂接到其它镜像盘时,有不少困惑的地方,结合以前的资料再次学习;  大数据底层技术的三大基石起源于Google在2006年之前的三篇论文GFS、Map-Reduce、 Bigtable,其中GFS、Map-Reduce技术直接支持了ApacheHadoop项目的诞生,Bigtable催生了NoSQL这个崭新的数据库领域,由于map-Reduce处理框架高延时的缺陷, Google在2009年后推出的Dremel促使了实时计算系统的兴起,以此引发大数据第二波技术浪潮,一些大数据公司纷纷推出自己的大数据查询分析产品,如: Cloudera 开源了大数据查询分析引擎 Impala 、 Hortonworks 开源了 Stinger 、 Fackbook 开源了 Presto 、UC Berkeley AMPLAB实验室开发了 Spark 计算框架,所有这些技术的数据来源均基于hdsf, 对于 hdsf 最基本的不外乎就是其读写操作

目录:

  • hdfs 名词解释
  • hdsf 架构
  • NameNode(NN)
  • Secondary NN
  • hdfs 写文件
  • hdfs 读文件
  • block持续化结构

HDFS名词解释:

  • Block: 在HDFS中,每个文件都是采用的分块的方式存储,每个block放在不同的datanode上,每个block的标识是一个三元组( block id, numBytes,generationStamp ),其中block id是具有唯一性,具体分配是由namenode节点设置,然后再由datanode上建立block文件,同时建立对应block meta文件
  • Packet: 在DFSclient与DataNode之间通信的过程中,发送和接受数据过程都是以一个packet为基础 的方式进行
  • Chunk: 中文名字也可以称为块,但是为了与block区分,还是称之为chunk。在DFSClient与DataNode之间通信的过程中,由于文件采用的是基于块的方式来进行的,但是在发送数据的过程中是以packet的方式来进行的, 每个packet包含了多个chunk ,同时对于每个chunk进行checksum计算,生成checksum bytes
  • 小结:
  • Packet结构与定义: Packet分为两类,一类是实际数据包,另一类是heatbeat包。一个Packet数据包的组成结构,如图所示
  • Hadoop
  • 上图中,一个Packet是由Header和Data两部分组成,其中Header部分包含了一个Packet的概要属性信息,如下表所示:
  • Data部分是一个Packet的实际数据部分,主要包括一个4字节校验和(Checksum)与一个Chunk部分,Chunk部分最大为512字节
  • 在构建一个Packet的过程中,首先将字节流数据写入一个buffer缓冲区中,也就是从偏移量为25的位置(checksumStart)开始写Packet数据Chunk的Checksum部分,从偏移量为533的位置(dataStart)开始写Packet数据的Chunk Data部分,直到一个Packet创建完成为止。
  • 当写一个文件的最后一个Block的最后一个Packet时,如果一个Packet的大小未能达到最大长度,也就是上图对应的缓冲区中,Checksum与Chunk Data之间还保留了一段未被写过的缓冲区位置,在发送这个Packet之前,会检查Chunksum与Chunk Data之间的缓冲区是否为空白缓冲区(gap),如果有则将Chunk Data部分向前移动,使得Chunk Data 1与Chunk Checksum N相邻,然后才会被发送到DataNode节点

hdsf架构:

  • hdfs的构架图网上一堆,抓了一张表述比较清楚的图如下, 主要包含因类角色:Client、NameNode、SecondayNameNode、DataNode
  • HDFS Client: 系统使用者,调用HDFS API操作文件;与 NN交互获取文件元数据 ;与DN交互进行数据读写, 注意: 写数据时文件 切分由Client完成 
  • Namenode: Master节点(也称元数据节点),是系统唯一的管理者。负责元数据的管理( 名称空间和数据块映射信息 );配置 副本策略 ;处理客户端请求
  • Datanode: 数据存储节点(也称Slave节点), 存储实际的数据;执行 数据块的读写;汇报存储信息给NN
  • Secondary NameNode: 小弟角色,分担大哥namenode的工作量;是NameNode的冷备份; 合并fsimage和fsedits然后再发给namenode, 注意: 在hadoop 2.x 版本,当启用 hdfs ha 时,将没有这一角色。(详见第二单)
  • 解释说明:
  • hdfs构架原则:

NameNode:

  • NameNode是整个文件系统的管理节点,也是HDFS中最复杂的一个实体,它维护着HDFS文件系统中最重要的两个关系:
  • 第一个关系即目录树、元数据和数据块的索引信息会 持久化到物理存储 中,实现是保存在命名空间的镜像 fsimage 和编辑 日志edits 中, 注意: 在fsimage中, 并没有记录每一个block对应到哪几个Datanodes的对应表信息
  • 第二个关系是在NameNode启动后,每个Datanode对本地磁盘进行扫描,将 本Datanode上保存的block信息汇报给Namenode ,Namenode在接收到每个Datanode的块信息汇报后,将接收到的块信息,以及其所在的Datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来 完成 block -> Datanodes list的对应表构建
  • fsimage 记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的序列化信息;
  • edits 是元数据操作日志(记录每次保存fsimage之后到下次保存之间的所有hdfs操作)
  • 在NameNode启动时候,会先将fsimage中的文件系统元数据信息 加载到内存 ,然后根据eidts中的记录将内存中的元数据 同步至最新状态, 将这个新版本的 FsImage 从内存中保存到本地磁盘上,然后删除 旧的 Editlog,这个过程称为一个 检查 点 (checkpoint),  多长时间做一次 checkpoint?( 见第四章 参数配置 )   checkpoint 能手工触发吗? 验证重启hdfs服务后editlog没删除呢?
  • 类似于���据库中的检查点,为了避免edits日志过大,在Hadoop1.X中,SecondaryNameNode会按照时间阈值(比如24小时)或者edits大小阈值(比如1G),周期性的将fsimage和edits的合并,然后将最新的fsimage推送给NameNode。而在Hadoop2.X中,这个动作是由Standby NameNode来完成 .
  • 由此可看出,这两个文件一旦损坏或丢失,将导致整个HDFS文件系统不可用,在HDP2.4安装(五):集群及组件安装   集 群安装过程中,hdfs 默认的只能选择一个NN,是否意味着 NN存在单点呢?( 见第二单 hdfs HA)
  • 在hadoop1.X为了保证这两种元数据文件的高可用性,一般的做法,将 dfs.namenode.name.dir设置成以逗号分隔的多个目录 ,这多个目录至少不要在一块磁盘上,最好放在不同的机器上,比如:挂载一个共享文件系统
  • fsimage\edits 是序列化后的文件,想要查看或编辑里面的内容,可通过 hdfs 提供的 oiv\oev 命令,如下:
    • 命令: hdfs oiv (offline image viewer)  用于将fsimage文件的内容转储到指定文件中以便于阅读, ,如文本文件、XML文件,该命令需要以下参数:
    • 命令: hdfs oev  (offline edits viewer 离线edits查看器)的缩写, 该工具只操作文件因而并不需要hadoop集群处于运行状态。
  • 小结:
  1. NameNode管理着DataNode,接收DataNode的注册、心跳、数据块提交等信息的上报,并且在心跳中发送数据块复制、删除、恢复等指令;同时,NameNode还为客户端对文件系统目录树的操作和对文件数据读写、对HDFS系统进行管理提供支持
  2. Namenode 启动后会进入一个称为 安全模式 的特殊状态。处于安全模式 的 Namenode 是不会进行数据块的复制的。 Namenode 从所有的 Datanode 接收心跳信号和块状态报告 。块状态报告包括了某个 Datanode 所有的数据 块列表。每个数据块都有一个指定的最小副本数。当 Namenode 检测确认某 个数据块的副本数目达到这个最小值,那么该数据块就会被认为是副本安全 (safely replicated) 的;在一定百分比(这个参数可配置)的数据块被 Namenode 检测确认是安全之后(加上一个额外的 30 秒等待时间), Namenode 将退出安全模式状态。接下来它会确定还有哪些数据块的副本没 有达到指定数目,并将这些数据块复制到其他 Datanode 上。

Secondary NameNode: 在HA cluster中又称为standby node

  • 定期合并 fsimage 和 edits 日志,将 edits 日志文件大小控制在一个限度下
  • namenode 响应 Secondary namenode 请求,将 edit log 推送给 Secondary namenode , 开始重新写一个新的 edit log
  • Secondary namenode 收到来自 namenode 的 fsimage 文件和 edit log
  • Secondary namenode 将 fsimage 加载到内存,应用 edit log , 并生成一 个新的 fsimage 文件
  • Secondary namenode 将新的 fsimage 推送给 Namenode
  • Namenode 用新的 fsimage 取代旧的 fsimage , 在 fstime 文件中记下检查 点发生的时

HDFS写文件:

  • 写文件部分参考blog 地址 ( http://www.linuxidc.com/Linux/2016-09/134882.htm ),2.X版本默认block的大小是 128M (见第四章参数配置)
  1. Client将FileA按64M分块。分成两块,block1和Block2;
  2. Client向nameNode发送写数据请求,如图蓝色虚线①------>
  3. NameNode节点,记录block信息。并返回可用的DataNode ( NameNode按什么规则返回DataNode? 参见第三单 hadoop机架感知 ),如粉色虚线②--------->
    • Block1: host2,host1,host3
    • Block2: host7,host8,host4
  4. client向DataNode发送block1;发送过程是以流式写入,流式写入过程如下:
    1. 将64M的block1按64k的packet划分
    2. 然后将第一个packet发送给host2
    3. host2接收完后,将第一个packet发送给host1,同时client想host2发送第二个packet
    4. host1接收完第一个packet后,发送给host3,同时接收host2发来的第二个packet
    5. 以此类推,如图红线实线所示,直到将block1发送完毕
    6. host2,host1,host3向NameNode,host2向Client发送通知,说“消息发送完了”。如图粉红颜色实线所示
    7. client收到host2发来的消息后,向namenode发送消息,说我写完了。这样就真完成了。如图黄色粗实线
    8. 发送完block1后,再向host7,host8,host4发送block2,如图蓝色实线所示
  •  说明:

  •   小结:
  1. 写入的过程,按hdsf默认设置, 1T文件,我们需要3T的存储 , 3T的网络流量
  2. 在执行读或写的过程中,NameNode和DataNode通过HeartBeat进行保存通信,确定DataNode活着。如果发现DataNode死掉了,就将死掉的DataNode上的数据,放到其他节点去。读取时,要读其他节点去
  3. 挂掉一个节点,没关系,还有其他节点可以备份;甚至,挂掉某一个机架,也没关系;其他机架上,也有备份

hdfs读文件:

  •  读到文件示意图如下:
  • 客户端通过调用FileSystem对象的open()方法来打开希望读取的文件,对于HDFS来说,这个对象时分布文件系统的一个实例;
  • DistributedFileSystem通过使用RPC来调用NameNode以确定文件起始块的位置,同一Block按照重复数会返回多个位置,这些位置按照 Hadoop集群拓扑结构排序,距离客户端近的排在前 面 ( 详见第三章 
  • 前两步会返回一个FSDataInputStream对象,该对象会被封装成DFSInputStream对象,DFSInputStream可以方便的管理datanode和namenode数据流,客户端对这个输入流调用read()方法
  • 存储着文件起始块的DataNode地址的DFSInputStream随即连接距离最近的DataNode,通过对数据流反复调用read()方法,将数据从DataNode传输到客户端
  • 到达块的末端时,DFSInputStream会关闭与该DataNode的连接,然后寻找下一个块的最佳DataNode,这些操作对客户端来说是透明的,客户端的角度看来只是读一个持续不断的流
  • 一旦客户端完成读取,就对FSDataInputStream调用close()方法关闭文件读取

block持续化结构:

  •  DataNode节点上一个Block持久化到磁盘上的物理存储结构,如下图所示:
  • 每个Block文件(如上图中blk_1084013198文件)都对应一个meta文件(如上图中blk_1084013198_10273532.meta文件), Block文件是一个一个Chunk的二进制数据 (每个Chunk的大小是512字节),而meta文件是与 每一个Chunk对应的Checksum数据 ,是序列化形式存储




收藏 推荐 打印 | 录入:elainebo | 阅读: