数分-理论-大数据4-HBase（分布式数据库）

(数据分析系列)

1知识点

• Hadoop局限
• 简介
• HBase数据模型
• 实现原理
• 运行机制
• 安装应用

2具体内容

2.1Hadoop局限

1.Hadoop

• 优势：通过HDFS存储结构化、半结构甚至非结构化数据，对传统数据库补充，对大文件存储、批量访问、流式访问做优化，通过多副本解决容灾
• 劣势：只能
  
  批处理
  
  ，以
  
  顺序方式
  
  访问数据。无法实现对数据的随机访问，需要遍历！
• 因此，需要新的解决方案，既保证
  
  海量数据存储
  
  ，又可
  
  随机访问
  

2.数据结构分类（补充知识）

• 结构化数据：以
  
  关系型数据库表
  
  形式管理的数据
• 半结构化数据：具有非关系模型，
  
  基本固定结构
  
  模式的数据，日志文件、XML文档、Json文档、Email
• 非结构化数据：
  
  无固定
  
  模式的数据，word、pdf、ppt、图片、视频等

3.数据库类型

• 关系型数据库（
  
  MySQL
  
  ）：关系型数据库模型，是把复杂的数据结构归结为简单的二元关系（即二维表格形式）
• 键值存储数据库（
  
  Redis
  
  ）：键值数据库是一种非关系数据库，它使用简单的键值方法来存储数据。键值数据库将数据存储为键值对集合，其中键作为唯一标识符。
• 列存储数据库（
  
  HBase
  
  ）：列式存储（column-based）是相对于传统关系型数据库的行式存储（Row-basedstorage）来说的。简单来说，两者的区别就是对表中数据的存储形式的差异。
• 面向文档数据库（
  
  MongoDB
  
  ）：此类数据库可存放并获取文档，可以是XML、JSON、BSON等格式，这些文档具备可描述性（self-describing），呈现分层的树状结构（hierarchical tree data structure），可以包含映射表、集合和纯量值。数据库中的文档彼此相似，但不必完全相同。文档数据库所存放的文档，就相当于键值数据库所存放的“值”。文档数据库可视为其值可查的键值数据库。
• 图形数据库：图形数据库顾名思义，就是一种存储图形关系的数据库。图形数据库是NoSQL数据库的一种类型，可以用于存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。（
  
  Neo4J、ArangoDB、OrientDB、FlockDB、GraphDB、InfiniteGraph、Titan和Cayley等
  
  ）
• 搜索引擎数据库（
  
  Solr、Elasticsearch等
  
  ）：搜索引擎数据库是一类专门用于数据内容搜索的非关系数据库。搜索引擎数据库使用索引对数据中的相似特征进行归类，并提高搜索能力。搜索引擎数据库经过优化，以处理可能内容很长的半结构化或非结构化数据，它们通常提供专业的方法，例如全文搜索、复杂搜索表达式和搜索结果排名等

4.HBase与传统的关系型数据库区别：

• 数据类型
  • 关系型：数据类型有int、date、long等
  • HBase：每个数据都被存储为未经解释的字符串，用户需要自己编写程序把字符串解析成不同的数据类型。
• 数据操作
  • 关系型：增删改查、联表操作
  • HBase：不进行充分的规范化，存在一张表里，避免低效连接操作
• 存储模式
  • 关系型：行模式存储
  • HBase：基于列存储
• 数据索引
  • 关系型：对不同的列构建复杂的索引结构
  • HBase：对行键的索引
• 数据维护（更新数据）
  • 关系型：会把数据替换掉
  • HBase：保留旧的版本数据一段时间，到了一定期限才会在后台清理数据
• 可伸缩性
  • 关系型：很难实现水平扩展
  • HBase：分布式集群存储，水平扩展性较好

2.2简介

1.概念

• 构建在Hadoop文件系统之上的一个
  
  高可靠、高性能、面向列、可伸缩
  
  的
  
  分布式数据库
  
• 存储
  
  非结构化
  
  和
  
  半结构化
  
  的松散数据
• 用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表
• 提供对大量结构化数据的快速随机访问
• 利用Hadoop MapReduce来处理HBase中的海量数据，实现高性能计算
• 利用ZooKeeper作为协同服务，实现稳定服务和失败恢复
• 使用HDFS作为高可靠的底层存储，利用廉价集群提供海量数据存储能力
• HBase也可以直接使用本地文件系统而不用HDFS作为底层数据存储方式
• Sqoop为HBase提供了高效、便捷的RDBMS数据导入功能，Pig和Hive为HBase提供了高层语言支持。
  
  
  2.接口

2.3HBase数据模型

2.3.1模型

1. HBase是一个稀疏、多维度、排序的映射表，表索引是
   
   行键、列族、列限定符、时间戳
   
2. 每个值是未经解释的字符串，没有数据类型
3. 在表中存储数据，每一行有一个可排序的行键和任意多的列
4. 表在水平方向由一个或多个列族组成，一个列族中可包含任意多列，同一个列族内数据存储在一起
5. 列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储。因此对于整个映射表的每行数据而言，有些列的值是空的，所以说HBase是稀疏的
6. HBase中执行
   
   更新
   
   操作时，并不会删除数据旧的版本，而是
   
   生成一个新的版本
   
   ，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）

2.3.2相关概念

• 表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。
• 行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。
• 列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元。表中的每个列都归属于某个列族，数据可以被存放到列族的某个列下面（列族需要先创建好）。在创建完列族以后，就可以使用同一个列族当中的列。列名都以列族作为前缀。例如，courses:history和courses:math这两个列都属于courses这个列族。
• 列限定符：列族里的数据通过列限定符（或列）来定位。
• 单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]。
• 时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。
  
  

• 学号作为行键来唯一标识每个学生，表中设计了列族Info来保存学生相关信息，列族Info中包含3个列——name、major和email，分别用来保存学生的姓名、专业和电子邮件信息。
• 学号为201505003的学生存在两个版本的电子邮件地址，时间戳分别为ts1=1174184619081和ts2=1174184620720，时间戳较大的版本的数据是最新的数据。

2.3.3数据坐标

• HBase使用坐标来定位表中的数据，也就是说，每个值都通过坐标来访问。
• HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即 [行键, 列族, 列限定符, 时间戳]。
• 把所有坐标看成一个整体，视为“键”，把四维坐标对应的单元格中的数据视为“值”，那么，HBase可以看成一个键值数据库。

2.3.4概念视图

在HBase的概念视图中，一个表可以视为一个稀疏、多维的映射关系。

• 行键是一个反向URL，由于HBase是按照行键的字典序来排序存储数据的，采用这种方式可以让来自同一个网站的数据内容都存在相邻的位置，在按照行键的值进行水平分区时，就可以尽量把来自同一个网站的数据分到同一个分区（Region）中。
• 列族content用来存储网页内容。
• 列族anchor包含了任何引用这个页面的锚链接文本。
• 时间戳代表不同时间的版本

• 可以用“四维坐标”定位单元格中的数据，比如[“com.cnn.www”,“anchor”,“cnnsi.com”,“t5”]对应的单元格里存储的数据为CNN。
• 可以看出，在一个HBase表的概念视图中，每个行都包含相同的列族，尽管行不需要在每个列族里存储数据。从这个角度来说，HBase表是一个
  
  稀疏的
  
  映射关系，即里面存在很多空的单元格。

2.3.5物理视图

• 基于
  
  列
  
  的存储方式
• 上例，HBase表会按照contents和anchor这两个列族分别存放，属于同一个列族的数据保存在一起，同时，和每个列族一起存放的还包括行键和时间戳。
• 有些列是空的。但是在物理视图中， 这些空的列不会被存储。如果请求这些空白的单元格的时候，会返回null值。
  
  

2.3.6面向列存储

2.4实现原理

2.4.1HBase功能组件

1.组成

• 库函数（用于连接到每个客户端）
• 一个Master主服务器
  • 管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡。
• 许多个Region服务器
  • 负责存储和维护分配给自己的Region，处理来自客户端的读写请求
• 客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据
• 客户端并不依赖Master，而是通过Zookeeper获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小

2.4.2表和Region

1.Region由来

• 一个HBase中，存储了很多的表
• 每个HBase表而言，表中的行是根据行键的值的字典序进行维护
• 行数量庞大，无法存储在一台机器，需要分布到多台
• 根据行键的值对表中行分区
• 每个行区间构成一个分区，成为
  
  Region
  
• Region包含了位于某个值域区间内的所有数据，是负载均衡和数据分发的基本单位。
  
  
  
  2.生成Region：

1. 1个Region，达到阈值，分裂成2个新Region
2. 行量增加，分裂出越来越多的Region
3. 拆分之后的Region读取的仍然是原存储文件，直到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件。
   
   
   注意：
   • 每个Region默认大小是100MB到200M，每个Region的最佳大小取决于单台服务器的有效处理能力，目前每个Region最佳大小建议1GB-2GB
   • 同一个Region不会被分拆到多个Region服务器
   • 每个Region服务器负责管理一个Region集合，通常在每个Region服务器会存储10-1000个Region

2.4.3Region的定位

• 每个Region都有一个RegionID来标识它的唯一性，这样，一个Region标识符就可以表示成表名＋开始主键+RegionID
• 映射表（“元数据表”，又名.META.表）：Region标识符、Region服务器标识（表示Region和Region服务器之间的对应关系）
• .META.表也会被分裂成多个Region
• “根数据表”，又名-ROOT-表，为了定位Region，再构建一个新的映射表，记录所有元数据的具体位置
  • ROOT-表是不能被分割的，永远只存在一个Region用于存放-ROOT-表。
  • 用来存放-ROOT-表的唯一个Region，它的名字是在程序中被写死的，Master主服务器永远知道它的位置。
    
    
    
• 为了加快访问速度，.META.表的全部Region都会被保存在内存中
• 客户端访问数据时采用的是三级寻址
• 为了加速寻址，客户端会缓存位置信息。同时，需要解决缓存失效问题
• 寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器。因此，主服务器的负载相对就小了很多

2.5运行机制

2.5.1HBase系统架构

• 
  客户端
  
  ：包含访问HBase的接口，同时在缓存中维护着已经访问过的
  
  Region
  
  位置信息，用来加快后续数据访问过程。

• 
  Zookeeper服务器
  
  ：Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题。同时，Zookeeper也是一个很好的集群管理工具，被大量用于分布式计算，提供配置维护、域名服务、分布式同步、组服务等。
  
  

• 
  Master服务器
  
  ：主服务器Master主要负责表和Region的管理工作：

  • 管理用户对表的增加、删除、修改、查询等操作
  • 实现不同Region服务器之间的负载均衡
  • 在Region分裂或合并后，负责重新调整Region的分布
  • 对发生故障失效的Region服务器上的Region进行迁移

• 
  Region服务器
  
  ：Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。

2.5.2Region服务器工作原理

1.读写数据

• 用户写入数据时，被分配到相应Region服务器去执行
• 用户数据首先被写入到MemStore和Hlog中
• 只有当操作写入Hlog之后，调用commit() 方法才会将其返回给客户端
• 当用户读取数据时， Region服务器会首先访问MemStore缓存，如果找不到，再到磁盘的StoreFile中寻找

2.缓存刷新

• 系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
• 每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件
• 每个Region服务器都有一个自己的HLog文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务
  
  3.StoreFile合并
• 每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
• 调用Store.compact()把多个StoreFile合并成一个
• 合并操作比较耗费资源，只有数量达到一定阈值后才会启动合并

2.5.3Store的工作原理

• Store是Region服务器的核心
• 多个StoreFile合并成一个StoreFile
  
  单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region
  
  

2.5.4HLog的工作原理

• 系统出错时，当Region服务器发生故障时，MemStore缓存中的数据（还没有写入文件）会全部丢失。
• HBase来用HLog来保证系统发生故障时能够恢复到正确的状态，HLog具有以下特点：
  • HBase系统为
    
    每个
    
    Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）。
  • 用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘后，该缓存内容才能被刷写到磁盘。
  • Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。
  • Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录。
  • 系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器。
  • Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会
    
    重新做一遍
    
    日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复。
  • 共用日志的优点是提高对表的写操作性能；其缺点是恢复时需要
    
    分拆日志
    
    。

2.5.5Hbase性能优化

• 行键（Row Key）： 行键是按照
  
  字典序
  
  存储。因此，设计行键时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。例如：如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为行键的一部分 。
• InMemory：创建表的时候，可将表放到Region服务器的缓存中，保证在读取的时候被
  
  cache
  
  命中。
• Max Version：创建表的时候，可设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置
  
  setMaxVersions(1)
  
  。
• Time To Live：创建表的时候，可设置表中数据的
  
  存储生命期
  
  ，过期数据将自动被删除。

2.6安装应用

• 完成Java运行环境部署（详见第2章Java安装）
• 完成Hadoop 3.0.0的单点部署
• HBase安装并启动shell
  • 创建表 create
  • 添加数据 put
  • 查表内容 scan
  • 查询数据 get
  • 修改内容 put
  • 添加、删除列族 alter（describe查看）
  • 删除表 disable
• 将关系型数据库中的表和数据，转换为适合于HBase存储的表并插入数据
• 使用list命令，列出HBase所有的表的相关信息，如表名、创建时间等
• 使用scan命令，打印Course表的所有记录数据（按照截图，创建Course表及列族，并添加数据）
• 使用alter命令，向已经创建好的表添加和删除指定的列族或列
• 使用truncate命令，清空指定的表的所有记录数据
• 使用count命令，统计表的行数

3参考

• https://shenhao-stu.github.io/Big-Data/#/