栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 前沿技术 > 大数据 > 大数据系统

Jbd4:Hbase

Jbd4:Hbase

Jbd4:Hbase

0. 背景

0.1 Hadoop的局限性0.2 Hbase VS 传统数据库

0.2.1 数据类型0.2.2 数据库类型0.2.3 数据库区别 1. 概述

1.1 Hbase 简介1.2 Hbase 访问接口 2. Hbase 数据模型

2.1 数据模型概述2.2 模型相关概念2.3 数据坐标2.4 概念视图2.5 物理视图2.6 面向列的存储 3. Hbase的实现原理

3.1 Hbase功能组件3.2 表和Region

3.2.1 相应概念3.2.2 分裂region3.2.3 region详情 3.3 Region定位

3.3.1 定位Region3.3.2 定位.meta.表3.3.3 结构图示 4. Hbase运行机制

4.1 Hbase系统架构4.2 Region服务器的工作原理

4.2.1 用户读写数据过程4.2.2 缓存的刷新4.2.3 StoreFile的合并 4.3 Store工作原理4.4 HLog工作原理4.5 Hbase性能优化 5. Hbase 编程实战

5.1 实验一:Hbase的安装部署和使用

5.1.1 实验准备5.1.2 实验内容5.1.3 实验步骤

5.1.3.1 解压安装包5.1.3.2 更改文件夹名和所属用户5.1.3.3 设置Hbase_HOME环境变量5.1.3.4 修改hbase-site.xml配置文件5.1.3.5 修改hbase-env.sh配置文件5.1.3.6 启动hadoop5.1.3.7 启动Hbase5.1.3.8 启动Hbase Shell5.1.3.9 创建表(create命令)5.1.3.10 添加数据(put命令)5.1.3.11 查看表内容(scan命令)5.1.3.12 查询数据(get命令)5.1.3.13 修改内容(put命令)5.1.3.14 添加列族(alter命令)5.1.3.15 删除列族(alter命令)5.1.3.16 删除表(disable命令) 5.2 实验二:常用的Hbase操作

5.2.1 实验准备5.2.2 实验内容5.2.3 实验步骤

5.2.3.1 构造数据5.2.3.2 list命令5.2.3.3 scan命令5.2.3.4 alter命令5.2.3.5 truncate命令5.2.3.6 count命令

0. 背景 0.1 Hadoop的局限性

    优点

    Hadoop可以通过HDFS来存储结构化、半结构甚至非结构化的数据

    对大文件的存储、批量访问和流式访问都做了优化,也有多副本设计

    局限

    但是Hadoop的缺陷在于它只能执行批处理,并且只能以顺序的方式访问数据

    即使是最简单的工作,也必须搜索整个数据库,无法实现对数据的随机访问

    反观传统的关系型数据库,其主要特点就在于随机访问,但不适用海量数据

Cassandra、ouchDB、Dynamo和MongoDB也能存储海量数据并支持随机访问。

0.2 Hbase VS 传统数据库 0.2.1 数据类型

先来看一下数据的分类,按照结构可以分为:

    结构化数据:

    即以关系型数据库表形式管理的数据

    例如各种符合范式的表格类型的文件

    半结构化数据:

    具有非关系模型、基本固定结构模式的数据

    例如日志文件、XML文档、JSON文档、Email等

    非结构化数据:

    没有固定模式的数据

    如Word、PDF、PPT、Excel

    或者各种格式的图片、视频等

0.2.2 数据库类型

对于不同类型的数据,我们一般存入不同类型的数据库:

    关系型数据库:

    使用二维表格形式存储复杂的数据结构

    代表软件:MySQL

    键值存储数据库:

    键值数据库是一种非关系数据库,将数据存储为键值对集合

    代表软件:Redis

    列存储数据库:

    列式存储是相对于传统的行式存储来说的

    两者的主要区别是对数据存储形式的差异

    代表软件:Hbase

    面向文档数据库:

    存放XML、JSON、BSON等格式的文档数据

    具备自描述性,呈现分层的树状结构

    可以包含映射表、集合和纯量值

    代表软件:MongoDB

    图形数据库:

    NoSQL数据库的一种类型,可以用于存储实体之间的关系信息。

    最常见例子就是社会网络中人与人之间的关系

    代表软件:Neo4J、ArangoDB、OrientDB、FlockDB、

    GraphDB、InfiniteGraph、Titan和Cayley等

    搜索引擎数据库:

    搜索引擎数据库是一类专门用于数据内容搜索的非关系数据库。

    搜索引擎数据库使用索引对数据中的相似特征进行归类,并提高搜索能力。

    搜索引擎数据库经过优化,以处理可能内容很长的半结构化或非结构化数据

    它们通常提供专业的方法,例如全文搜索、复杂搜索表达式和搜索结果排名等。

    代表软件:Solr、Elasticsearch等

0.2.3 数据库区别

新的形势下,传统数据库无法很好地处理数据高并发、高可拓展性及高可用性

因此造成了Hbase的崭露头角,其与传统数据库的主要区别如下:

    数据类型:

    关系型数据库数据类型较为丰富,数据类型有int、date、long等。

    Hbase数据类型简单,每个数据都被存储为未经解释的字符串

    用户需要自己编写程序把字符串解析成不同的数据类型。

    数据操作:

    关系型数据库存在增删改查,还有我们比较熟悉的联表操作,效率较低。

    Hbase不会把数据进行充分的规范化,而是存在一张表里,避免了低效率的连接操作。

    存储模式:

    关系型数据库采用行模式存储,Hbase是基于列存储。

    数据索引:

    关系型数据库可以对不同的列构建复杂的索引结构

    Hbase支持对行键的索引。

    数据维护:

    更新操作时,关系型数据库会把数据替换掉,

    Hbase会保留旧的版本数据一段时间,到了一定期限才会在后台清理数据。

    可伸缩性:

    关系型数据库很难实现水平扩展

    Hbase采用分布式集群存储,水平扩展性较好

1. 概述 1.1 Hbase 简介

Hbase是高可靠、高性能、面向列、可伸缩的分布式数据库

主要用来存储非结构化和半结构化的松散数据

旨在提供对大量结构化数据的快速随机访问

其与Hadoop生态系统组件的配合如下:

    使用HDFS提供的容错功能,提供数据的随机实时读写访问

    使用Hadoop MapReduce来处理Hbase中的海量数据,实现高性能计算

    使用ZooKeeper作为协同服务,实现稳定服务和失败恢复

    使用HDFS作为高可靠的底层存储,利用廉价集群提供海量数据存储能力。

    当然,Hbase也可以直接使用本地文件系统而不用HDFS作为底层数据存储方式

    使用Sqoop实现高效、便捷的RDBMS数据导入Hbase的功能

    使用Pig和Hive为Hbase提供了高层语言支持。

1.2 Hbase 访问接口
类型特点场合
Native Java API最常规和高效的访问方式适合Hadoop MapReduce作业并行批处理Hbase表数据
Hbase ShellHbase的命令行工具,最简单的接口适合Hbase管理使用
Thrift Gateway利用Thrift序列化技术,支持C++、PHP、Python等多种语言适合其他异构系统在线访问Hbase表数据
REST Gateway解除了语言限制支持REST风格的Http API访问Hbase
Pig使用Pig Latin流式编程语言来处理Hbase中的数据适合做数据统计
Hive简单当需要以类似SQL语言方式来访问Hbase的时候
2. Hbase 数据模型 2.1 数据模型概述

    索引

    Hbase是一个稀疏、多维度、排序的映射表

    这张表的索引是行键、列族、列限定符和时间戳

    字段类型

    每个值是一个未经解释的字符串,没有数据类型。

    行构成

    用户在表中存储数据,每一行都有一个可排序的行键和任意多的列。

    列构成

    表在水平方向由一个或者多个列族组成

    一个列族中可以包含任意多个列

    同一个列族里面的数据存储在一起

    扩展列族

    列族支持动态扩展,可以很轻松地添加一个列族或列

    无需预先定义列的数量以及类型,所有列均以字符串形式存储

    因此对于一行数据而言,有些列的值是空的,所以说Hbase是稀疏的。

    更新操作

    Hbase中执行更新操作时,并不会删除数据旧的版本

    而是生成一个新的版本,旧有的版本仍然保留

    这是和HDFS只允许追加不允许修改的特性相关的

2.2 模型相关概念

    表:

    Hbase采用表来组织数据,表由行和列组成,列划分为若干个列族。

    行:

    每个Hbase表都由若干行组成,每个行由行键(row key)来标识。

    列族:

    一个Hbase表被分组成许多“列族”(Column Family)的集合,它是基本的访问控制单元。

    表中的每个列都归属于某个列族,数据可以被存放到已存在的列族的某个列下面

    列名都以列族作为前缀来进行访问操作,例如,courses:history属于courses这个列族。

    列限定符:

    列族里的数据通过列限定符(或列)来定位

    单元格:

    在Hbase表中,通过行、列族和列限定符确定一个“单元格”(cell)

    单元格中存储的数据没有数据类型,总被视为字节数组byte[]

    时间戳:

    每个单元格都保存着同一份数据的多个版本,这些版本采用时间戳进行索引。

下面引用一张图来作示例:

学号作为行键来唯一标识每个学生,应该也就是数据行的关键字

表中设计了列族Info来保存学生相关信息,也就是这里列族是个人信息

列族Info中包含3个列——name、major和email,分别用来保存对应的信息

学号为201505003的学生存在两个版本的电子邮件地址,拥有不同的时间戳

时间戳较大的版本的数据是最新的数据,但是旧版的数据依旧存在没有覆盖

2.3 数据坐标

依照上文所说,这个数据库单元格的索引是一个四维的坐标

即:[行键, 列族, 列限定符, 时间戳],也可以视作key,值为value

2.4 概念视图

引用示例如下:

行键是一个反向URL,由于Hbase是按照行键的字典序来排序存储数据的

采用这种方式可以让来自同一个网站的数据内容都存在相邻的位置

在按照行键的值进行水平分区时,就可以尽量将他们分到同一个分区(Region)

在概念视图中可以看到,每个行都包含相同的列族,但并不是在每个列族里都有数据存储

从这个角度来说,Hbase表是一个稀疏的映射关系,即里面存在很多空的单元格。

2.5 物理视图

继续引用上图的举例:

之前的概念视图层是按照行进行组织的,但是这个物理图是按列的,区别明显

注意:在概念视图中,我们可以发现,有些列是空的。但是在物理视图中, 这些空的列不会被存储。如果请求这些空白的单元格的时候,会返回null值。

2.6 面向列的存储

引用示例如下:

    传统行式数据库

      数据是按行存储的,对比之前的概念图与物理图

      没有索引的查询使用大量I/O,需要扫描完整内容再进行筛选

      建立索引和物理视图需要花费大量时间和资源

      面对查询的需求,数据库必须被大量膨胀才能满足性能要求

    列式数据库

      数据按列存储,对比之前的概念图与物理图

      数据即是索引,根据关键字进行查询

      只访问查询涉及的列,大量降低系统IO

      每一列由一个线索来处理,查询采用并发处理方式

      数据类型一致,数据特征相似,采用高效压缩方式

      点陷在执行连接操作时,需要昂贵的元组重构代价

3. Hbase的实现原理 3.1 Hbase功能组件

主要的功能组件有三个,分别是 :

    库函数(用于连接到每个客户端)

    一个Master主服务器

    许多个Region服务器。

其中,需要注意的是:

    主服务器Master:

    维护分区信息,维护Region服务器列表,分配Region,均衡负载

    Region服务器:

    维护分配给自己的Region,处理来自客户端的读写请求

    读取数据

    客户端是在查找节点后,直接从Region服务器上读取数据

    查找节点

    客户端并不依赖Master,查找节点也是通过Zookeeper获得位置信息

    大多数客户端甚至从来不和Master通信,这种设计方式使得Master负载很小

3.2 表和Region 3.2.1 相应概念

    Hbase表根据行键的值的字典序对数据行维护

    分布式存储的实现,是根据字典序划分行的区间

    每个行区间构成一个分区,被称为Region。

    每个分区存储了该区间内所有行的数据

    分区是负载均衡和数据分发的基本单位

3.2.2 分裂region

但是这是初始化的时候,随着集群运行,分区肯定会变大

所以为了应对不断新增是数据,势必要新增region:

    开始只有一个Region,随着新数据的不断加入,Region会越来越大。

    当达到一定的阈值时,原始的一个region会分裂成两个新的Region

    再之后,随着表中行的数量继续增加,就会分裂出更多的Region

需要注意的是:

    Region拆分操作非常快,但是拆分之后的Region读取的仍然是原存储文件

    直到“合并”过程把存储文件异步地写到独立的文件之后,才会读取新文件

    这个特性应该是源于HDFS只能追加的特点,所以设置新区的时候旧区还存在

3.2.3 region详情

    每个Region默认大小是100MB到200MB(2006年以前的硬件配置)

    每个Region的最佳大小取决于单台服务器的有效处理能力

    目前每个Region最佳大小建议1GB-2GB(2013年以后的硬件配置)

    同一个Region不会被分拆到多个Region服务器

    通常每个Region服务器负责管理10-1000个分区

3.3 Region定位 3.3.1 定位Region

为了准确定位每个Region,我们赋予其唯一的RegionID来标识

一个Region标识符就可以表示成:表名+开始主键+RegionID

为了汇集每个Region所在的位置,可以构建一张映射表

每行包含两项内容:Region标识符、Region服务器标识

借此,我们可以定位某个Region所在的Region服务器

这个映射表包含了关于Region的元数据,又名.meta.表。

3.3.2 定位.meta.表

当表中的数据超多,Region数量就会非常庞大,.meta.表也会很大

这个时候也需要进行分布式存储,.meta.表也会被分裂成多个Region

那么当我们需要定位Region,我们需要先定位存储其位置的.meta.表

那么.meta.表理应也有元数据表,即存储所有的.meta.表的位置

这个元数据表的元数据表就是-ROOT-表,其存在以下的特点:

-ROOT-表是不能被分割的,永远只存在一个Region用于存放-ROOT-表。

程序中写死了这唯一Region的名字,Master主服务器永远知道它的位置。

3.3.3 结构图示

需要注意:

为了加快访问速度,.meta.表的全部Region都会被保存在内存中

客户端访问数据时采用的是三级寻址,如图所示的root-meta-region结构

为了加速寻址,客户端会缓存位置信息。同时,需要解决缓存失效问题

寻址过程客户端只需要询问Zookeeper服务器,不需要连接Master服务器

因此,主服务器Master的负载相对就小了很多,几乎不与客户端通信

4. Hbase运行机制 4.1 Hbase系统架构

主要的结构如下:1

    客户端:

    客户端包含访问Hbase的接口

    同时在缓存中维护着已经访问过的Region位置信息

    用来加快后续数据访问过程。

    Zookeeper服务器:

    用于选出集群的Master服务器

    并保证在任何时刻总有唯一一个Master在运行

    这就避免了Master的“单点失效”问题

    同时,Zookeeper也被用于配置维护、域名服务等集群管理

    Master服务器:

    管理用户对表的增加、删除、修改、查询等操作

    在Region分裂或合并后,重新调整Region的分布

    对失效的Region服务器上的Region进行迁移

    从而实现不同Region服务器之间的负载均衡

    Region服务器:

    负责维护分配给自己的Region分区

    并与客户端进行通信,响应读写请求

    一个region服务器包含多个region

    多个region共用一个HLog日志

4.2 Region服务器的工作原理 4.2.1 用户读写数据过程

    用户写入数据时,被zookeeper分配到相应Region服务器

    需要写入的数据首先被写入到Region的MemStore和Hlog

    当操作写入Hlog之后,调用commit() 方法才会将其返回给客户端

    当用户读取数据时, Region服务器会首先访问MemStore缓存

    如果找不到,再到磁盘的StoreFile中寻找

4.2.2 缓存的刷新

系统会周期性地把MemStore缓存刷写到磁盘的StoreFile文件

也就是清空MemStore缓存,并在Hlog里面写入一个标记

每次刷写都生成一个新的StoreFile文件,每个Store有多个StoreFile

每个Region服务器都有一个自己的HLog文件,每次启动都检查该文件

确认最近一次执行缓存刷新操作之后是否发生新的写入操作

如果发现更新,则先写入MemStore,再刷写到StoreFile

最后删除旧的Hlog文件,再开始为用户提供服务

4.2.3 StoreFile的合并

每次刷写都生成一个新的StoreFile

随着StoreFile数量增多多,查找速度会受到影响

于是节点调用Store.compact()把多个StoreFile合并成一个

合并操作比较耗费资源,只有数量达到一定阈值后才会启动合并

4.3 Store工作原理

Store是Region服务器的核心,是主要存储文件的地方

例如上文提到,发现更新后要在写入StoreFile后提供服务

小的StoreFile会合并,大的StoreFile又会触发分裂

一个region中每个列族会单独构成一个store

所以说一个region有多个store,store内是storefile

StoreFile又会根据大小来分裂或者合并,维持平衡

4.4 HLog工作原理

分布式环境下要考虑到系统出错的情形,以及故障后的处理,

比如当Region服务器发生故障时,MemStore缓存中的数据会全部丢失

此时这些丢失的文件当中,可能有一部分还没有来得及写入文件

因此,Hbase用HLog来保证故障后恢复到正确的状态,特点如下:

    Hbase系统为每个Region服务器配置了一个HLog文件

    它是一种预写式日志(Write Ahead Log)。

    用户更新数据必须首先写入HLog日志后,才能写入MemStore缓存

    并且需要在对应的日志已经写入磁盘后,该缓存内容才能被刷写到磁盘。

    Zookeeper会实时监测每个Region服务器的状态

    当某个Region服务器发生故障时,Zookeeper会通知Master来处理

    Master首先会处理该故障Region服务器上面遗留的HLog文件

    这个遗留的HLog文件中包含了来自多个Region对象的日志记录

    系统会根据每条日志记录所属的Region对象对HLog数据进行拆分

    分别将不同的HLog日志数据放到相应Region对象的目录下

    然后,再将失效服务器的Region重新分配到可用的Region服务器

    并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器

    Region服务器领取到自己的Region及相关HLog以后

    会重新做一遍HLog日志记录中的各种操作

    把日志记录中的数据写入到MemStore缓存中

    然后,刷新到磁盘的StoreFile文件中,完成数据恢复。

    共用日志的优点是提高对表的写操作性能

    其缺点是恢复时需要分拆日志。

4.5 Hbase性能优化

    行键(Row Key):

    行键是按照字典序排序存储,在设计行键时要充分利用这个特点

    我们可以将经常一起读取的数据利用行键存储到一块

    也可以将最近可能会被访问的数据利用行键放在一块

    例如:如果最近写入Hbase表中的数据是最可能被访问的

    那就可以考虑将时间戳作为行键的一部分来进行设计

    InMemory:

    创建表的时候,可将表放到Region服务器的缓存中

    保证在读取的时候被cache命中。

    Max Version:

    创建表的时候,可设置表中数据的最大版本,这样可以弃掉过旧的版本

    如果只需要保存最新版本的数据,那么可以设置setMaxVersions(1)

    Time To Live:

    创建表的时候,可设置表中数据的存储生命期,过期数据将自动被删除。

5. Hbase 编程实战 5.1 实验一:Hbase的安装部署和使用 5.1.1 实验准备

Linux Ubuntu 20.04,完成Java部署,完成Hadoop部署

5.1.2 实验内容

在上述的实验环境中,安装Hbase并学习Hbase Shell的使用。

5.1.3 实验步骤 5.1.3.1 解压安装包
master@VM-0-12-ubuntu:/opt/JuciyBigData$ ls
apache-hive-2.3.9-bin.tar.gz  hbase-2.4.8-bin.tar.gz      mysql-connector-java_8.0.27-1ubuntu20.04_all.deb
hadoop-3.3.1.tar.gz           jdk-8u311-linux-x64.tar.gz  spark-3.2.0-bin-without-hadoop.tgz
master@VM-0-12-ubuntu:/opt/JuciyBigData$ sudo tar -zxvf hbase-2.4.8-bin.tar.gz -C /opt
···
hbase-2.4.8/lib/jdk11/jakarta.xml.soap-api-1.4.1.jar
hbase-2.4.8/lib/jdk11/jakarta.jws-api-1.1.1.jar
master@VM-0-12-ubuntu:/opt/JuciyBigData$ cd /opt
master@VM-0-12-ubuntu:/opt$ ls
hadoop  hbase-2.4.8  java  JuciyBigData  JuciyBigData.zip  master
master@VM-0-12-ubuntu:/opt$ 
5.1.3.2 更改文件夹名和所属用户
master@VM-0-12-ubuntu:/opt$ ll | grep h
drwxr-xr-x 13 master master       4096 Mar 15 23:20 hadoop/
drwxr-xr-x  7 root   root         4096 Mar 18 19:59 hbase-2.4.8/
master@VM-0-12-ubuntu:/opt$ sudo mv hbase-2.4.8/ hbase
master@VM-0-12-ubuntu:/opt$ sudo chown -R master:master hbase/
master@VM-0-12-ubuntu:/opt$ ll | grep h
drwxr-xr-x 13 master master       4096 Mar 15 23:20 hadoop/
drwxr-xr-x  7 master master       4096 Mar 18 19:59 hbase/
master@VM-0-12-ubuntu:/opt$ 

5.1.3.3 设置Hbase_HOME环境变量

在/etc/profile当中添加以下内容:

# hbase
export Hbase_HOME=/opt/hbase
export PATH=$PATH:$Hbase_HOME/bin

实践如下:

master@VM-0-12-ubuntu:/opt$ sudo vim /etc/profile
master@VM-0-12-ubuntu:/opt$ source /etc/profile
master@VM-0-12-ubuntu:/opt$ tail /etc/profile
export PATH=$JAVA_HOME/bin:$PATH

#hadoop
export HADOOP_HOME=/opt/hadoop
export PATH=$HADOOP_HOME/bin:$PATH

# hbase
export Hbase_HOME=/opt/hbase
export PATH=$PATH:$Hbase_HOME/bin

master@VM-0-12-ubuntu:/opt$ 

说起来好像可以用重定向>>追加到文件末尾啊

5.1.3.4 修改hbase-site.xml配置文件

添加下面配置到/opt/hbase/conf/hbase-site.xml中的标签之间:


    
        hbase.cluster.distributed
        true
    
    
        hbase.rootdir
        hdfs://localhost:9000/hbase
    
    
        hbase.unsafe.stream.capability.enforce
        false
    


实践如下:

master@VM-0-12-ubuntu:/opt$ cat /opt/hbase/conf/hbase-site.xml






我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号