目录
第三章 分布式文件系统HDFS
一、分布式文件系统
分布式文件系统：是一种通过网络实现文件在多台主机上进行分布式存储的文件系统
HDFS：针对谷歌GFS的开源实现
1.1 计算机集群基本架构
集群中的计算机节点放在机架上，每个机架可以存放8~64个节点，同一个机架上不同节点之间通过网络互连，不同机架间采取另一级网络或交换机互连。
【机架上有多台服务器，机架内通过网络互连，机架间通过交换机或局域网互连】
1.2 分布式文件系统结构
存储思想：
OS中文件系统会将磁盘空间划分为512B的磁盘块，存储时将文件分块，且每块是磁盘块的整数倍。而分布式文件系统也采用了分块，且块很大【HDFS每块为64MB】，与OS文件系统不同的是，如果一个文件小于一个数据块，其不会占用整个块的存储空间。
物理结构：
分布式文件系统将计算机集群的节点分为名称节点【主节点】和数据节点【从节点】。
| 节点 |
功能 |
说明 |
| 名称节点 |
1、负责文件和目录的创建、删除和重命名等 2、管理数据节点和文件块的映射关系 |
客户端只有访问名称节点才能找到数据块的存储位置，进而进行读取 |
| 数据节点 |
1、负责数据的存储和读取 |
存储时：由名称节点分配存储位置，然后客户端，直接将数据写入相应的数据节点 读取时：客户端从名称节点获得数据节点和文件块的映射关系，直接到相应位置访问文件块 |
预防措施
采用多副本存储，文件块被复制为多个副本，存储到不同的节点上，且同一文件块的副本分布到不同的机架上。
遇到节点故障时，可以快速调用副本，而不用重启整个计算过程。
适用范围范围
分布式文件系统是针对大规模数据存储而设计，主要用于处理大规模文件【TB级】，处理小规模文件时，不仅没有优势，而且会严重影响系统的扩展和性能
二 、 HDFS
2.1 HDFS特点
优势
兼容廉价的硬件设备：快速检测硬件故障和自动恢复机制，硬件出错也能实现数据的完整性。
实现流数据读写：顺序、大量、快速、连续到达的数据序列，不可随机读写。
支持大数据集：GB，TB支持简单的文件模型：一次写入，多次读取
强大的跨平台兼容性：支持JVM即可用。
局限
不适合低延迟数据访问：大规模数据批处理，流式数据读取，高吞吐率， 高延迟。
无法高效存储大量小文件：存储问题：名称节点内存保存文件的元数据【信息】，大量小文件会增加名称节点空间且检索效率低。处理问题：MapReduce处理小文件，产生大量Map线程，开销太大。
不支持多用户写入及任意修改文件：一个文件只能有一个写入者，且只有追加操作，不随机写操作。
2.2 HDFS的体系结构
| 结构 |
功能 |
说明 |
特点 |
| 名称节点 |
HDFS中，选择性能较好的机器作为唯一的名称节点，负责管理分布式文件系统的命名空间，保存了两个核心数据结构：FsImage和EditLog。 名称节点记录了块所在数据节点的位置信息，但并非持久化存储，而是在每次启动时，加载FsImage，并逐步执行EditLog。同时创建新FsImage和新空的EditLog。 根据客户端发送的文件名返回文件数据块对应的数据节点位置信息。 |
FsImage用于维护文件系统树和树中所有文件和目录的元数据 EditLog中记录了所有针对文件的创建删除重命名等操作 运行过程中，操作并不会直接写入fsImage，而是写入EditLog。 |
名称节点在启动时会进入安全模式，此期间只对外提供读操作，无法进行写操作。启动结束后，进入正常状态，对外提供读写操作。 在整个访问过程中，名称节点不参与数据的传输，使得每个文件的数据能在不同数据节点上实现并发访问。保证了数据不会脱了名称节点的同时，减轻了中心服务器的复返，简化管理。 |
| 第二名称节点 |
完成EditLog和FsImage的合并操作，减小EditLog大小。 作为名称节点的检查点，保存元数据信息 |
为了防止EditLog文件过大，导致名称节点启动缓慢，长期处于安全模式，采用第二名称节点。 每隔一段时间，第二名称节点和名称节点进行通信，完成合并E和F的操作，同时创建新F执行原E后替换原F，创建新E记录合并期间操作并替换原E。 名称节点发生故障时，可从第二名称节点进行系统恢复 |
在合并期间，名称节点产生故障丢失的元数据无法被恢复。所以第二名称节点只是检查点，无法做到热备份 |
| 数据节点 |
负责文件的存储和读取，根据客户端和名称节点的调度进行数据的存储和检索， 定时向名称节点发送心跳和存储数据块的列表信息，死机节点不会被分配IO请求 |
数据节点的文件保存在本地Linux系统， |
|
| 命名空间 |
HDFS使用传统的分级文件体系，支持创建删除目录和文件，支持重命名、转移文件。 HDFS不支持磁盘配额、文件访问权限、软硬连接等功能 |
HDFS命名空间包括目录、文件和块 命名空间管理是只命名空间支持对HDFS中的文件目录块做类似文件系统的创建、修改等基本操作 |
整个HDFS集群只有一个命名空间，由唯一的名称节点对其管理 |
| 通信协议 |
HDFS的所有通信协议都建立在TCP/IP基础上。 |
HDFS体系结构的局限性
1、命名空间的限制：名称节点保存在内存中，其容纳文件数量收到内存大小的限制
2、性能瓶颈：整个文件系统的吞吐量受限于单个名称节点的吞吐量
3、可用性：一旦名称节点故障，整个集群将不可用
4、隔离问题：唯一的名称节点无法对不同应用程序进行隔离
2.3 HDFS的存储原理
| 方法 |
说明 |
特点 |
| 冗余存储 |
HDFS使用多副本方式进行冗余存储，一个数据块的多个副本会被分布到不同数据节点上。 |
1、加快数据传输速度，多客户端从不同副本并发读取文件 2、容易检查出数据错误，多副本检错 3、可靠性强，不容易造成数据丢失 |
| 数据存取 |
数据存放：默认三个副本，两个在同一机架的不同节点，一个在另一个机架 数据读取：HDFS提供API返回数据节点所在机架，客户端读取数据时，优先读取同一机架上的副本，或随机选择其它机架副本。 数据复制：流水线复制。 |
流水线复制： 客户端向HDFS中写入文件时，首先将文件写入本地，然后按HDFS给文件分块。每一块都向名称节点发起写请求，名称节点返回一个数据节点列表。然后客户端向列表内节点1写入4KB【假设】数据，并将列表传给节点1，节点1向节点2发送连接请求，将4KB数据和列表发送给节点2，以此类推。当文件写完时，数据复制也同时完成 |
| 数据错误与恢复 |
名称节点出错：法一：将名称节点的元数据信息同步到远程挂载的网络文件系统。法二：第二名称节点。 数据节点出错：法一：定期发送心跳。法二：节点导致副本数量少于冗余银子，生成新副本 数据出错：MD5和SHA-1校验。创建文件时，会摘录信息写入同级下隐藏文件中，用作校验。名称节点会定期检查并重新复制出错数据块。 |
硬件出错是常态 名称节点出错：结合法一二，当名称节点发生死机时，首先到网络文件系统获取备份元数据，放到第二名称节点进行恢复，然后使用第二名称节点作为名称节点。。 数据节点出错：HDFS与其它分布式FS最大区别是可以调整备份数据位置。 |
第四章、 分布式数据库HBase
HBase：针对谷歌BigTable的开源实现，是一个高可靠，高性能，面向列，可伸缩的分布式数据库，主要用来存储非结构化和半结构化的松散数据。
BugTable：一个支持大规模海量数据、分布式并发数据处理效率极高、易于扩展且支持动态伸缩，适用于廉价设备，适合读操作不适合写操作的分布式存储系统
一、HBase和Hadoop
1.1 HBase与Hadoop生态的关系
| Hadoop生态 |
与HBase的功能 |
| Zookeeper |
作为协同服务，为HBase提供了稳定服务和failover【失败恢复机制】 |
| Pig和Hive |
为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单 |
| Sqoop |
为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。 |
| HDFS |
为HBase提供了高可靠性的底层存储支持，提供海量数据存储能力 |
| Hadoop MapReduce |
为HBase提供了高性能的计算能力 |
1.2 Hbase和HDFS
HBase本质是一个高并发的分布式数据库，其底层文件系统可以是任何分布式文件系统，在HDFS基础上提供了随机写入功能。。
HDFS的视角看，HBase就是它的客户端。
HBase本身并不存储文件，它只规定文件格式以及文件内容，管理的是数据本身，实际文件存储由HDFS实现，管理的是记载着这些数据的文件。
HBase不提供机制保证存储数据的高可靠，数据的高可靠性由HDFS的多副本机制保证。
HBase-HDFS体系是典型的计算存储分离架构。
Hadoop 已有 HDFS 和 MapReduce，为什么需要 HBase?
HDFS面向批量访问模式，不是随机访问模式
Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不能很好解决)
传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间
二、 Hbase特点
2.1 HBase与传统关系数据库
| 方面 |
传统关系数据库 |
HBase |
| 数据类型 |
采用关系模型，具有丰富的数据类型和存储方式 |
采用更简单的数据模型，将所有数据【结构化/非结构化】存储为未解释的字符串，由用户编写程序解析字符串成为不同类型。 |
| 数据操作 |
提供设计多表连接的增删查改操作 |
只提供单表增删查清空等操作，无法改，只能追加 |
| 存储模式 |
基于行模式存储，元组被连续存储在磁盘页中，读取数据时顺序查扫描，然后筛选所需属性。【无论查找几个属性都会查找整行后筛选，容易浪费磁盘空间和内存带宽】 |
基于列存储，每个列族由几个文件保存，不同列族的文件是分离的。可以降低I/O开销，支持大量用户并发查询【不需要处理无关列/属性】；同一个列族的数据会被一起压缩，相似度高的数据会得到更高的压缩比。 |
| 数据索引 |
可针对不同列构建复杂的多个索引，提高访问性能 |
只有一个索引--行键，因设计巧妙 ，查询时系统不会慢下来，且在Hadoop框架下，MapReduce可以快速高效生成索引表 |
| 可伸缩性 |
横向扩展困难，纵向扩展优先 |
分布式数据库横向扩展灵活，轻易增加减少硬件实现性能伸缩 |
| 数据维护 |
更新时会替换旧值，旧值不复存在 |
更新操作生成新版本，仍保留旧版本 |
2.2 HBase数据模型
HBase实际上是一个稀疏【有些列/列族的内容为空】、多维、持久化存储的映射表。采用行键，列族，列限定符和时间戳进行索引，每个值都是未解释的字节数组byte[]。
表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。用户在表中存储数据，每一行都有一个可排序的行键和任意多的列。
行：每个表都由若干行组成，每个行由行键来标识。
列族：一个表被分组成许多“列族” 的集合，它是基本的访问控制单元。一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。
列限定符：列族里的数据通过列限定符（或列）来定位。列支持动态扩展，可以很轻松地添加一个列，无需预先定义列的数量以及类型。
单元格：通过行、列族和列限定符确定一个“单元格”，单元格中存储的数据没有数据类型，总被视为字节数组。
时间戳：每个单元格都保存着同一份数据的多个版本，采用时间戳进行索引。
数据坐标：【行键、列族、列限定符和时间戳】
2.3 Hbase视图
概念视图来看，HBase中每个表是有许多行组成的，可通过四维坐标查找单元格的数据。
物理视图来看，在物理存储层面，采用基于列的存储方式，属于同一个列族的数据保存在一起，不同列族分别存放，与列族一起存放的还有时间戳和行键。空列不会被存储，被请求时返回null。
三、 HBase实现原理
3.1 HBase功能组件
| 功能组件 |
功能 |
特点 |
| 库函数 |
连接到每个客户端 |
|
| Master主服务器 |
Master服务器负责管理和维护HBase分区信息【一个表被分为哪些Region，每个Region被存放到哪个Region服务器上】，同时也负责维护Region服务器列表。 Master还处理模式变化，如表和列族的创建。 |
客户端并不是直接从Master获取数据，而是获取Region存储位置信息后，直接从Region读取数据。 HBase客户端并不依赖于Master而是使用ZooKeeper来获取Region位置信息，所以Master负担很小 |
| 许多的Region服务器 |
Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求 |
当表中的行增加到一定阈值时会被等分成两个Region，Master将Region分配到不同的服务器上，一个Region服务器可维护约1~1000个Region |
3.2 Region的定位
三级寻址结构：
| 层次 |
名称 |
作用 |
| 第一层 |
Zookeeper文件 |
记录了-ROOT-表的位置信息 |
| 第二层 |
-ROOT-表 |
记录了.META.表的Region位置信息 -ROOT-表只能有一个Region。通过-ROOT-表，就可以访问.META.表中的数据 |
| 第三层 |
.META.表 |
记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息 |
3.3 HBase运行机制
| 结构 |
功能 |
| 客户端 |
包含访问HBase的接口，并在缓存中维护着已访问过的Region位置信息，用来加快后续数据访问过程。 |
| Zookeeper服务器 |
可帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，就避免了Master的“单点失效”问题。 |
| Master服务器 |
主服务器Master主要负责表和Region的管理工作： 管理用户对表的增加、删除、修改、查询等操作 实现不同Region服务器之间的负载均衡 在Region分裂或合并后，负责重新调整Region的分布 对发生故障失效的Region服务器上的Region进行迁移 |
| Region服务器 |
HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。 用户读写数据过程 ：用户写入数据时，被分配到相应Region服务器去执行用户数据首先被写入到MemStore和HLog中只有当操作写入HLog之后，commit()调用才会将其返回给客户端当用户读取数据时，Region服务器会首先访问MemStore缓存，如找不到，再去磁盘上面的StoreFile中寻找 缓存的刷新：系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在HLog里面写入一个标记。每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件。每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的HLog文件，开始为用户提供服务。 StoreFile的合并：每次刷写都生成一个新的StoreFile，数量太多，影响查找速度调用Store.compact()把多个合并成一个合并操作比较耗费资源，只有数量达到一个阈值才启动合并 |
| Store |
多个StoreFile合并成一个单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region |
| HLog |
分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复。 HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写（Write Ahead Log）。用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。 Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录。 |