hadoop原理学习——结构解释

Posted simon麦田

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了hadoop原理学习——结构解释相关的知识,希望对你有一定的参考价值。

转自:https://www.cnblogs.com/tgzhu/p/5788634.html

1.hadoop2的结构划分

在Hadoop部署中,有以下角色:
  • HDFS Client: 系统使用者,调用HDFS API操作文件;与 NN交互获取文件元数据;与 DN交互进行数据读写, 注意: 写数据时文件 切分由Client完成  
  • Namenode:Master节点(也称元数据节点),是系统唯一的管理者。负责元数据的管理( 名称空间和数据块映射信息);配置 副本策略;处理客户端请求
  • Datanode:数据存储节点(也称Slave节点), 存储实际的数据;执行 数据块的读写;汇报存储信息给NN。每个 Slave 运行一个 Data Node 和一个 Task Tracker 守护进程。这两个守护进程负责与 Master 节点通信。Task Tracker 守护进程与 Job Tracker 相互作用,而 Data Node 守护进程则与 Name Node 相互作用
  • Secondary NameNode: 小弟角色,分担大哥namenode的工作量;是NameNode的冷备份; 合并fsimage和fsedits然后再发给namenode, 注意: 在hadoop 2.x 版本,当启用 hdfs ha 时,将没有这一角色。
  • 解释说明:
    1. 热备份: b是a的热备份,如果a坏掉。那么b马上运行代替a的工作
    2. 冷备份: b是a的冷备份,如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息,减少a坏掉之后的损失
  • hdfs构架原则:
    1. 元数据与数据分离: 文件本身的属性(即元数据)与文件所持有的数据分离
    2. 主/从架构: 一个HDFS集群是由一个NameNode和一定数目的DataNode组成
    3. 一次写入多次读取: HDFS中的文件在任何时间只能有一个Writer。当文件被创建,接着写入数据,最后,一旦文件被关闭,就不能再修改。
    4. 移动计算比移动数据更划算: 数据运算,越靠近数据,执行运算的性能就越好,由于hdfs数据分布在不同机器上,要让网络的消耗最低,并提高系统的吞吐量,最佳方式是将运算的执行移到离它要处理的数据更近的地方,而不是移动数据

       所有的集群配置都会存在于客户端服务器,但是客户端服务器不属于 Master 以及 Salve,客户端服务器仅仅负责提交计算任务给 Hadoop 集群,并当 Hadoop 集群完成任务后,客户端服务器来拿走计算结果。在一个较小的集群中(40个节点左右),可能一台服务器会扮演多个角色,例如通常我们会将 Name Node 与 Job Tracker安置在同一台服务器上。(由于 Name Node对内存开销非常大,因此不赞成将 Name Node 与 Secondary Name Node 安置在同一台机器上)。而在一个大型的集群中,请无论如何要保证这三者分属于不同的机器。
NameNode
  • NameNode是整个文件系统的管理节点,也是HDFS中最复杂的一个实体,它维护着HDFS文件系统中最重要的两个关系:
  1. HDFS文件系统中的文件目录树,以及文件的数据块索引,即 每个文件对应的数据块列表
  2. 数据块和数据节点的对应关系,即某一块 数据块保存在哪些(哪些是因为有备份)数据节点 的信息

  • 第一个关系即目录树、元数据和数据块的索引信息会 持久化到物理存储 中,实现是保存在命名空间的镜像 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文件,该命令需要以下参数:
    1. -i  (必填参数)  –inputFile <arg>  输入FSImage文件
    2. -o (必填参数)  –outputFile <arg> 输出转换后的文件,如果存在,则会覆盖
    3. -p (可选参数) –processor <arg>   将FSImage文件转换成哪种格式: (Ls|XML|FileDistribution).默认为Ls
    4. 示例: hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt
    • 命令: hdfs oev  (offline edits viewer 离线edits查看器)的缩写, 该工具只操作文件因而并不需要hadoop集群处于运行状态。
    1. 示例:  hdfs oev -i edits_0000000000000042778-0000000000000042779 -o edits.xml
    2. 支持的输出格式有 binary (hadoop使用的二进制格式)、 xml (在不使用参数p时的默认输出格式)和 stats (输出edits文件的统计信息)
  • 小结:
  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 文件中记下检查 点发生的时

以上是关于hadoop原理学习——结构解释的主要内容,如果未能解决你的问题,请参考以下文章

十Hadoop学习笔记————Hive的基本原理

Hadoop基础(三十七):Zookeeper 内部原理

Hadoop架构设计执行原理具体解释

Hadoop==zookeeper

大数据学习---Hadoop的深入学习

Hadoop机架感知原理