zoukankan      html  css  js  c++  java
  • Hadoop学习笔记

    Hadoop

    存储模型

    • 文件线性按字节切割成块,具有offset,id
    • 文件和文件的块的大小可以不一样
    • 一个文件除了最后一个块,其他块的大小都一样
    • 块的大小应该一句硬件的 I/O 特性调整
    • 块被分散存放在集群的节点中,具有location
    • 块具有副本,没有主从概念,副本不可能出现在同一个节点
    • 副本是满足可靠性和性能的关键
    • 文件上传可以指定lock大小和副本数量,上传之后只能修改副本数量
    • 一次写入多次读取,不支持修改
    • 支持追加数据

    架构设计

    • HDFS是一个主从 (Master/Slaves) 架构
    • 由一个NameNode和一些DataNode组成
    • 面向文件包括 : 文件数据 (data) 和一些文件元数据 (metadate)
    • NameNode负责存储和管理文件元数据,并维护了一个层次型的文件目录树
    • DataNode负责存储文件数据 (block块),并提供 block 的读写
    • DataNodeNameNode 维持心跳,并汇报自己持有的block信息
    • ClientNameNode交互文件元数据 , 与DataNode交换文件block数据

    角色功能

    • NameNode
      • 完全基于内存存储文件元数据、目录结构、文件Block的映射
      • 需要持久化方案保证数据可靠性
      • 提供副本放置策略
    • DataNode
      • 基于本地磁盘存储 block (文件的形式)
      • 并保存 block 的校验和数据保证 block 的可靠性
      • NameNode 保持心跳,汇报 block 列表状态

    元数据持久化

    • 任何对文件系统元数据产生修改的操作,NameNode都会用一种叫做EditLog的事物日志记录下来
    • 使用FsImage存储内存中所有的元数据状态
    • 使用本地磁盘保存EditLogFsImage
    • EditLog就有完整性,数据丢失很少,但是数据恢复速度很慢,有体积膨胀的风险
    • FsImage具有恢复速度快,体积与内存数据相当,但不能实时保存,数据丢失多
    • NameNode使用了FsImage+EditLog整合的方案:
    • 滚动将增量的EditLog更新到FsImage,确保更近时间段的FsImage和更小体积的EditLog

    安全模式

    • HDFS搭建时会格式化,格式化操作会产生一个 FsImage

    • NameNode启动时,它从硬盘中读取 EditLogFsImage

    • 将所有 EditLog 中的事务作用在内存中的 FsImage

    • 并将这个新版本的 FsImage 从内存中保存到本地磁盘上

    • 然后删除旧的 EditLog ,因为这个旧的 EditLog 的事务都已经作用在 FsImage 上了


    • NameNode启动后会进入一个称为安全模式的特殊状态

    • 处于安全模式的NameNode是不会进行数据块的复制的

    • NameNode从所有的DataNode接受心跳信号和块状态报告

    • 每当NameNode检测确认某个数据块的副本数目达到了这个最小值,那么该数据块就会被认为是副本安全的 (safely replicated)

    • 在一定百分比 (参数可以配置) 的数据块被 NameNode 检测确认是安全之后 (加上一个额外的30秒等待时间) ,NameNode 将退出安全模式状态

    • 接下来它会确定还有哪些数据块的副本没有达到指定数目,并将这些数据块复制到其他DataNode上

    HDFS中的SNN

    • SecondaryNameNode (SNN)
      • 在非Ha (High avaliable) 模式下,SNN一般是独立的节点,周期完成对 NameNodeEditLogFsImage 合并,减少 EditLog 的大小,减少 NameNode 启动时间
      • 根据配置文件设置的时间间隔 fs.checkpoint.period 默认3600秒
      • 根据配置文件设置EditLog大小 fs.checkpoint.size 规定edits文件的最大值 默认64MB

    Block的副本放置策略

    • 第一个副本:放置在上传文件的DN;如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点
    • 第二个副本:放置在与第一个副本不同的机架的节点上
    • 第三个副本:与第二个副本相同机架的节点
    • 更多副本:随机节点

    HDFS写流程

    • ClientNameNode连接创建文件元数据
    • NameNode 判断元数据是否有效
    • NameNode 触发副本放置策略,返回一个有序的 DateNode 列表
    • ClientDataNode 建立 Pipeline 连接
    • Client 将块切分成 packet(64KB) ,并使用 chunk(512B) + chucksum(4B) 填充
    • Clientpacket 放入发送队列 dataqueue 中,并向第一个 DataNode 发送
    • 第一个DataNode收到packet后本地保存并发送给第二个DataNode
    • 第二个DataNode收到packet后本地保存并发送给第三个DataNode
    • 这一个过程中,上游节点同时发送下一个packet
    • (流式也是变种的并行计算)
    • HDFS使用这种传输方式,副本数对于Client式透明的
    • Block传输完成,DataNode各自向NameNode汇报,同时Client继续传输下一个Block
    • 所以Client的传输和Block的汇报也是并行的、

    HDFS读流程

    • 尽量让读取程序读离他近的副本
    • 如果在读取程序的同一个机架上有一个副本,那么就读取该副本
    • 如果一个HFDS集群跨越多个数据中心,那么客户端也将首先读取本地数据中心的副本
    • 语义:下载一个文件:
      • ClientNameNode交互文件元数据获取FileBlockLocation
      • NameNode按照距离策略返回
      • Client尝试下载block并校验数据完整性
    • 语义:下载一个文件其实是获取文件的所有的 block 元文件数据,那么子集获取block应该成立
      • HDFS支持client给出文件的offset自定义哪些blockDataNode,自定义获取数据
      • 这个是支持计算层的分治,并行计算的核心
  • 相关阅读:
    postgres 错误duplicate key value violates unique constraint 解决方案
    Golang包管理工具之govendor的使用
    《算法竞赛进阶指南》0x26广搜变形 HDOJ3085 双向BFS
    《算法竞赛进阶指南》0x26广搜变形 POJ3635
    《算法竞赛进阶指南》0x26广搜变形 电路维修 01最短路问题
    《算法竞赛进阶指南》0x25广度优先搜索 推箱子游戏 双重BFS
    《算法竞赛进阶指南》0x25广度优先搜索 多源floodfill
    《算法竞赛进阶指南》0x25广度优先搜索 POJ3322 Bloxorz I
    NETCORE
    VUE- 异步等待方法嵌套
  • 原文地址:https://www.cnblogs.com/xun-/p/13869708.html
Copyright © 2011-2022 走看看