20200407 NoSQL笔记（五）

第五章 Hadoop生态系统
一、 HDFS的架构设计

1. 计算机集群的基本架构

1. 分布式文件系统把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群
2. 目前的分布式文件系统所采用的计算机集群，都是由普通硬件构成的，大大降低了硬件上的开销
   

2. HDFS设计的前提和目标

1. 硬件失效
2. 流式数据读取访问
3. 海量数据集
4. 追加写入及文件同步
5. 移动计算比移动数据的代价小
6. 跨异构硬件和软件平台的可移植性

3. HDFS的基本架构——主从（Master/Slave）体系架构

1. 分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类， “名称节点”(NameNode)和“数据节点”(DataNode)
   
2. 名称节点
   a) 只含有一个NameNode主服务节点管理文件系统中的命名空间和调度客户端对文件的访问
   b) NameNode负责管理分布式文件系统的命名空间，保存了两个核心的数据结构，即FsImage和EditLog，执行文件系统中命名空间的操作(打开、关闭、重命名文件和目录)
    FsImage文件
    用于维护文件系统树以及文件树中所有文件和文件夹元数据
    包含文件系统中所有目录和文件inode的序列化形式
    FsImage文件没有记录数据块与数据节点之间的映射关系，而是由名称节点把这些映射保留在内存中
    EditLog文件
   记录了所有针对文件的创建、删除、重命名等操作
   c) NameNode执行数据块到DataNode映射的决策
   d) 名称节点的启动
    在名称节点启动的时候，将FsImage文件中的内容加载到内存中，再执行EditLog文件中的各项操作，存在内存中的元数据支持客户端的读操作
    在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件
    名称节点启动之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（通常是GB级别），如果所有的更新操作都添加到FsImage文件中，这样会导致系统运行十分缓慢，但是，如果更新操作写入EditLog文件里就不一样，因为EditLog小很多。每次执行写操作之后，在向客户端发送成功代码之前，EditLog文件都需要同步更新
   
3. 数据节点
   a) 数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的数据块的列表
   b) 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中
   c) 通常一台计算机就是一个DataNode数据节点，DataNode管理本节点上数据的存储
   d) DataNode负责响应来自客户端的文件读写要求并执行来自NameNode的关于数据块创建、删除和冗余存储的指令
   
4. 数据块
   a) HDFS默认一个块64MB，一个文件被分成多个块，以块作为存储单位，存储在一批DataNode中
   b) 块的大小远远小于普通文件系统，可以最小化寻址开销
   c) HDFS采用抽象的块概念可以带来以下几个好处：
    支持大规模文件存储
   文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量
    简化系统设计
   首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据
    适合数据备份
   文件块可以冗余存储到多个节点上，提高了系统容错性和可用性

4. HDFS数据存储原理

1. 数据存放——机架感知策略（rack-aware）
   通过一个机架感知的过程，名称节点可以确定每个数据节点所属的机架ID
   a) 第一个副本：随机挑选一台磁盘不太满、CPU不太忙的节点
   b) 第二个副本：放置在与第一个副本不同的机架的节点上
   c) 第三个副本：与第一个副本相同机架的其他节点上
   d) 更多副本：随机节点
2. 数据读取
   a) HDFS通过API调用机架ID
   b) 当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，优先选择该副本读取数据，如果不相同，则随机选择一个副本读取数据
3. 硬件失效的几种情形
   a) 名称节点出错——备份服务器SecondaryNameNode
   b) 数据节点出错——“心跳”信息+数据冗余备份
   HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置
   c) 数据包出错——客户端信息摘录+数据冗余备份

5. 可访问性

1. DFS Shell命令行
2. Java API调用
3. C语言的封装API调用
4. 浏览器访问

二、 MapReduce执行流程

1. 主从结构

1. 主节点（只有一个）—— 作业管理器 JobTracker
   a) 接收客户提交的计算任务
   b) 把计算任务分给TaskTrackers执行，即任务调度
   c) 监控TaskTracker的执行情况
2. 从节点（有很多个）—— 任务管理器TaskTracker
   执行JobTracker分配的计算任务

2. MapReduce执行流程
   

三、 ZooKeeper

1. 定义：一种为分布式应用所设计的高可用、高性能且一致的开源协调服务
2. ZooKeeper典型的应用场景

1. 统一命名服务
2. 共享锁
3. 队列管理

四、 HBase简介

1. HBase是建立在HDFS之上，提供高可靠性、高性能、列存储和可伸缩、实时读写的数据库系统

1. 利用Hadoop MapReduce处理HBase中的海量数据
2. 利用Zookeeper作为协同服务
3. 主要用来存储非结构化和半结构化的松散数据（列族NoSQL数据库）

2. HBase逻辑视图与物理视图

1. 逻辑视图
   HBase以表的形式存储数据，表由行和列组成，列划分为若干个列族
   
2. 物理视图
   HBase每个列族存储为一个Store
   

3. HBase存储结构

1. HBase是基于列族存储的数据库，可简单认为每个Column Family对应一张存储表，表格的Row Key、Timestamp和Column确定了每条记录的唯一索引
2. 在物理层面上，表格的数据是通过Store File来存储的，每个Store File相当于一个可序列化的Map
3. Map的key和value都是可解释型字符数组，多个Map整合到一起，形成一张松散的、可分布式的、多维的、可序列化的BigTable

4. HBase数据表

1. 键（Row Key）
   a) 表中行的键是字节数组（最大长度是 64KB ）
   b) 任何字符串都可以作为键
   c) 数据按照Row key的字典序(byte order)排序存储
2. 列族（Column Family）
   a) HBase表中的每个列都归属于某个列族，列族必须作为表模式(schema)定义的一部分预先定义
   b) 列名以列族作为前缀，每个“列族”都可以有多个列成员(column)
   c) 新的列族成员可以随后按需、动态加入
   d) 权限控制、存储以及调优都是在列族层面进行的
   e) 同一列族成员最好有相同的访问模式和大小特征
   f) HBase将同一列族的数据存储在同一目录下，由几个文件保存
3. 单元格修饰符 Cell qualifier
   a) 通过列族：单元格修饰符，可以具体到某个列
   b) 可以把单元格修饰符认为是实际的列名
   c) 列族存在时，客户端随时可以把列添加到列族
4. 时间戳Timestamp
   a) 在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面
   b) 时间戳的类型是64位整型
   c) 时间戳可以由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间
   d) 时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突，必须自己生成具有唯一性的时间戳。
5. 单元格Cell
   a) 由行和列的坐标交叉决定
   b) 单元格是有版本的
   c) 单元格的内容是未解析的字节数组
   d) 由{主键， 列( =<列族> + <列名>)， 时间戳} 唯一确定的单元
   e) Cell中的数据是没有类型的，全部是字节码形式存贮
6. 区域 Region
   a) HBase自动把表水平划分成多个区域，每个region会保存一个表里面某段连续的数据
   b) Region定位
   

5. HBase物理存储方式

1. 表中的所有行都按照row key的字典序排列

2. 表在行的方向上分割为多个HRegion

3. region是按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region，当表中的行不断增多，会有越来越多的region

4. Region是HBase中分布式存储和负载均衡的最小单元，最小单元表示不同的Region可以分布在不同的Region Server上，但一个Region不会拆分到多个Region Server上

5. Region虽然是分布式存储的最小单元，但并不是存储的最小单元。事实上，Region由一个或者多个Store组成，每个Store保存一个column family。每个Store又由一个memStore和0至多个Store File组成，Store File以HFile格式保存在HDFS上
   

6. HLog(WAL log)
   a) HLog 文件就是一个普通的Hadoop Sequence File
   b) Sequence File 的Key是HLog Key对象，HLog Key中记录了写入数据的归属信息，包括table，region名字，sequence number和timestamp
   c) timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number
   d) HLog Sequence File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue

6. HBase体系结构

1. Client
   访问HBase的接口并维护高速缓冲加快对HBase的访问
2. Zookeeper
   a) 保证任何时候，集群中只有一个master
   b) 存贮所有Region的寻址入口
   c) 实时监控Region server的上线和下线信息，并实时通知给Master
   d) 存储HBase的schema和table元数据
3. Master
   a) 为Region server分配region
   b) 负责Region server的负载均衡
   c) 发现失效的Region server并重新分配其上的region
   d) 管理用户对table的增删改查操作
4. Region Server
   a) Region server维护region，处理对这些region的IO请求
   b) Region server负责切分在运行过程中变得过大的region
   

7. HBase写请求的处理过程

1. Client向Region Server提交写请求
2. Region Server找到目标Region
3. Region检查数据是否与schema一致
4. 如果客户端没有指定版本，则获取当前系统时间作为数据版本
5. 将更新写入Wal Log
6. 将更新写入Memstore;
7. 判断Memstore是否需要flush为Store File