Hadoop1.0架构

HDFS-1.0-角色介绍

NameNode:

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

目录树

• 没有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

数据怎么分布

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

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

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

Client:

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

HDFS个角色交互

HDFS读流程

HDFS读流程

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

拓扑距离排序

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

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

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

NameNode HA概述

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

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

复习

secondary namenode节点 帮助namenode减轻压力

拓展

CAP理论

一致性 可用性 分区容错性