大数据3架马车之HDFS

·  阅读 122

Hadoop1.0架构

image.png

HDFS-1.0-角色介绍

NameNode:

  • 维护整个文件系统的文件目录树,文件目录的元信息和文件数据块索引
  • 以FsImage和EditLog形式存储在本地
  • 整个系统的单点,存在SPOF(Simple Point of Failure)

目录树

image.png

  • 没有master节点
  • 信息存放在client中
    • 如果有1亿个文件 怎么办?不可能存在一台机器上面
      • hash计算的方法(取模) 去对应的机器找文件

FsImage和EditLog

内存会越来越大 目录树是一个动态变化的 namenode down/pid crash的话 内存中的数据没有了 文件索引信息丢失了 为了维护这些索引数据 类似于做快照 按照一定的时间周期 存放到FsImage文件中 - 例如7点做了快照 8点要做快照 - 7:45挂掉了 怎么办? 45分钟的增量数据怎么办

EditLog 记录变化的数据

SecondaryNameNode:

  • 又名CheckPoint Node,定期合并FsImage和EditLog
  • 不接收客户端的请求,作为NameNode的冷备

DataNode:

  • 实际存储数据的单元

  • 以Block为单位

  • 数据以普通文件形式保存在本地文件系统

  • 实际以进程的方式进行存储

Block是什么?

6G的文件怎么存放 默认切割64MB 切割成101个Block

企业微信截图_ae93383d-ab66-440f-a43d-e9a81bb43e74.png

数据怎么分布

image.png

默认布局规则: (假设复制因子=3) • 第一份拷贝写入创建文件的节点 (快速写入) • 第二份拷贝写入同一个rack内的节点(减少跨rack的网络流量) • 第三份拷贝写入位于不同rack的节点 (应对交换机故障)

假设1 3 5 是一个rack机柜 数据会就近写入 3个副本不能全部放到一个rack中

hadoop中的rack是逻辑的 - 切割的逻辑 会按照上联交换机进行区分 不同的交换机 是不同的rack

Client:

  • 与HDFS交互,进行读写、创建目录、创建文件、复制、删除等操作
  • HDFS提供了多种客户端:命令行Shell、Java API、Thrift接口、C library、WebHDFS等

HDFS个角色交互

image.png

HDFS读流程

image.png

HDFS读流程

  • 读取大文件的流程
  • client请求namenode获取 101个文件block在哪些机器上 获取一个文件分布列表
  • client主动和 对应的datanode建立链接 streaming 读取文件
  • 文件校验 防止文件丢包 丢数据

拓扑距离排序

image.png

两个节点 到达一个公共节点的总和

image.png

image.png

1.0的时候是单节点 为了防止丢失 fsimage editlog

FsImage和EditLog的目的 • NameNode的内存中有整个文件系统的元数据,例如目录树,块信息,权限信息等等。 • 当NameNode异常宕机时,内存中的元数据将全部丢失。 • 为了让重启的NameNode获得最新的宕机前的元数据,才有了FsImage和Editlog。 • FsImage是整个NameNode内存中元数据在某一时刻的快照(Snapshot)。 • FsImage不能频繁的构建,生成FsImage需要花费大量的内存。 • 目前FsImage只在NameNode重启时才构建。 • 而Editlog记录的是从这个快照开始到当前所有的元数据的改动。 • 如果Editlog太多,重放Editlog会消耗大量时间。 • 这会导致启动NameNode花费数小时之久。

NameNode HA概述

image.png

设计目的:解决单点故障问题 • 两个名称节点: Active NameNode

  • Standby NameNode

• 共享存储系统:实现名称节点的状态同步 • Zookeeper:确保一个名称节点在对外服务 • 名称节点:维护映射信息 • 数据节点:同时向两个名称节点汇报信息 • 优点:热备份,提供高可用性 • 不足:无法解决可扩展性、系统性能和隔离性

复习

image.png

secondary namenode节点 帮助namenode减轻压力

image.png

image.png

image.png

拓展

CAP理论

一致性 可用性 分区容错性

分类:
代码人生
标签: