关于hbase:HBase知识点总结

HBase 是一种建设在 Hadoop 文件系统之上的分布式、可扩大、反对海量数据存储的 NoSQL 数据库。HBase 是 BigTable 的开源 Java 版本。是建设在 HDFS 之上，提供高可靠性、高性能、列存储、可伸缩、实时读写 NoSql 的数据库系统。

它介于 NoSql 和 RDBMS 之间，仅能通过主键 (rowKey) 和主键的 range 来检索数据，仅反对单行事务(可通过 Hive 反对来实现多表 join 等简单操作)。次要用来存储结构化和半结构化的涣散数据。HBase 查问数据性能很简略，不反对 join 等简单操作，不反对简单的事务（行级的事务）。

HBase 不限度存储的数据的品种，容许动静的、灵便的数据模型，不必 SQL 语言，也不强调数据之间的关系。HBase 被设计成在一个服务器集群上运行，能够相应地横向扩大。利用 HBase 技术可在便宜 PC Server 上搭建起大规模结构化存储集群。

HBase 自身是一个数据模型，相似于谷歌的大表设计（BIgtable），能够提供疾速随机拜访海量结构化数据。它利用了 Hadoop 的文件系统（HDFS）提供的容错能力，提供对数据的随机实时读 / 写访问，是 Hadoop 文件系统的一部分。人们能够间接或通过 HBase 存储 HDFS 数据，也能够应用 HBase 在 HDFS 读取生产 / 随机拜访数据。HBase 利用 Hadoop 的 MapReduce 来解决海量数据。协同服务方面 Google Bigtable 利用 Chubby 来反对，HBase 的 Zookeeper 与之对应。

HBase 中的表个别有这样的特点：

大：一个表能够有上十亿行，上百万列。
面向列: 面向列 (族) 的存储和权限管制，列 (族) 独立检索。
稠密：对于为空 (null) 的列，并不占用存储空间，因而，表能够设计的十分稠密。

1、HDFS 与 HBase 比照

HDFS

为分布式存储提供文件系统
针对存储大尺寸的文件进行优化，不须要对 HDFS 上的文件进行随机读写
间接应用文件
数据模型不灵便
应用文件系统和解决框架
优化一次写入，屡次读取的形式

HBase

提供表状的面向列的数据存储
针对表状数据的随机读写进行优化
应用 key-value 操作数据
提供灵便的数据模型
应用表状存储，反对 MapReduce，依赖 HDFS
优化了屡次读，以及屡次写

2、Hive 与 HBase 比照

Hive

(1) 数据仓库

Hive 的实质其实就相当于将 HDFS 中曾经存储的文件在 Mysql 中做了一个双射关系，以方便使用 HQL 去治理查问。

(2) 用于数据分析、荡涤

Hive 实用于离线的数据分析和荡涤，提早较高。

(3) 基于 HDFS、MapReduce

Hive 存储的数据仍旧在 DataN ode 上，编写的 HQL 语句终将是转换为 MapReduce 代码执行。

HBase

(1) 数据库

是一种面向列族存储的非关系型数据库。

(2) 用于存储结构化和非结构化的数据

实用于单表非关系型数据的存储，不适宜做关联查问，相似 JOIN 等操作。

(3) 基于 HDFS

数据长久化存储的体现模式是 HFile，寄存于 DataNode 中，被 ResionServer 以 region 的模式进行治理。

(4) 提早较低，接入在线业务应用

面对大量的企业数据，HBase 能够直线单表大量数据的存储，同时提供了高效的数据访问速度。

每天：
（1) 音讯量：发送和接管的音讯数超过 60 亿
（2) 将近 1000 亿条数据的读写
（3) 高峰期每秒 150 万左右操作
（4) 整体读取数据占有约 55%，写入占有 45%
（5) 超过 2PB 的数据，波及冗余共 6PB 数据
（6) 数据每月大略增长 300 千兆字节。

架构角色：

（1）Region Server

Region Server 为 Region 的管理者，其实现类为 HRegionServer，次要作用如下:

监控 RegionServer
解决 RegionServer 故障转移
解决元数据的变更
解决 region 的调配或移除
在闲暇工夫进行数据的负载平衡
通过 Zookeeper 公布本人的地位给客户

（2）Master

Master 是所有 Region Server 的管理者，其实现类为 HMaster，次要作用如下：

负责存储 HBase 的理论数据
解决调配给它的 Region
刷新缓存到 HDFS
保护 HLog
执行压缩
负责解决 Region 分片

（3）Zookeeper

HBase 通过 Zookeeper 来做 Master 的高可用、RegionServer 的监控、元数据的入口以及集群配置的保护等工作。

（4）HDFS

HDFS 为 HBase 提供最终的底层数据存储服务，同时为 HBase 提供高可用的反对。

（5）Client

蕴含拜访 HBase 的接口，并保护 cache 来放慢对 HBase 的拜访。

HRegionServer 组件

1. Write-Ahead logs

HBase 的批改记录。因为数据要经 MemStore 排序后能力刷写到 HFile，但把数据保留在内存中会有很高的概率导致数据失落，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile 的文件中，而后再写入内存中。所以在零碎呈现故障的时候，数据能够通过这个日志文件重建。

2. HFile

这是在磁盘上保留原始数据的理论的物理文件，是理论的存储文件。

3. StoreFile

HFile 存储在 Store 中，一个 Store 对应 HBase 表中的一个列族。保留理论数据的物理文件，StoreFile 以 HFile 的模式存储在 HDFS 上。每个 Store 会有一个或多个 StoreFile（HFile），数据在每个 StoreFile 中都是有序的。

4. MemStore

写缓存，因为 HFile 中的数据要求是有序的，所以数据是先存储在 MemStore 中，排好序后，等达到刷写机会才会刷写到 HFile，每次刷写都会造成一个新的 HFile。

5. Region

Hbase 表的分片，HBase 表会依据 rowKey 值被切分成不同的 region 存储在 RegionServer 中，在一个 RegionServer 中能够有多个不同的 Region。

1、基本操作

1．进入 HBase 客户端命令行
bin/hbase shell
2．查看帮忙命令
hbase(main):001:0> help
3．查看以后数据库中有哪些表
hbase(main):002:0> list

2、表的操作

1．创立表
hbase(main):002:0> create ‘student’,’info’
2．插入数据到表
hbase(main):003:0> put ‘student’,’1001′,’info:sex’,’male’
hbase(main):004:0> put ‘student’,’1001′,’info:age’,’18’
hbase(main):005:0> put ‘student’,’1002′,’info:name’,’Janna’
hbase(main):006:0> put ‘student’,’1002′,’info:sex’,’female’
hbase(main):007:0> put ‘student’,’1002′,’info:age’,’20’
3．扫描查看表数据
hbase(main):008:0> scan ‘student’
hbase(main):009:0> scan ‘student’,{STARTROW => ‘1001’, STOPROW =>
‘1001’}
hbase(main):010:0> scan ‘student’,{STARTROW => ‘1001’}
4．查看表构造
hbase(main):011:0> describe‘student’
5．更新指定字段的数据
hbase(main):012:0> put ‘student’,’1001′,’info:name’,’Nick’
hbase(main):013:0> put ‘student’,’1001′,’info:age’,’100′
6．查看“指定行”或“指定列族: 列”的数据
hbase(main):014:0> get ‘student’,’1001′
hbase(main):015:0> get ‘student’,’1001′,’info:name’
7．统计表数据行数
hbase(main):021:0> count ‘student’
8．删除数据
删除某 rowkey 的全副数据：
hbase(main):016:0> deleteall ‘student’,’1001′
删除某 rowkey 的某一列数据：
hbase(main):017:0> delete ‘student’,’1002′,’info:sex’
9．清空表数据
hbase(main):018:0> truncate ‘student’
提醒：清空表的操作程序为先 disable，而后再 truncate。
10．删除表
首先须要先让该表为 disable 状态：
hbase(main):019:0> disable ‘student’
而后能力 drop 这个表：
hbase(main):020:0> drop ‘student’
提醒：如果间接 drop 表，会报错：ERROR: Table student is enabled. Disable it first.
11．变更表信息
将 info 列族中的数据寄存 3 个版本：
hbase(main):022:0> alter ‘student’,{NAME=>’info’,VERSIONS=>3}
hbase(main):022:0> get
‘student’,’1001′,{COLUMN=>’info:name’,VERSIONS=>3}

首先，HBase 是基于 HDFS 来存储的。

HDFS

一次性写入，屡次读取。
保证数据的一致性。
次要是能够部署在许多便宜机器中，通过多正本进步可靠性，提供了容错和复原机制。

HBase

霎时写入量很大，数据库不好撑持或须要很高老本撑持的场景。
数据须要短暂保留，且量会长久增长到比拟大的场景。
HBase 不实用与有 join，多级索引，表关系简单的数据模型。
大数据量且有疾速随机拜访的需要。如：淘宝的交易历史记录。数据量微小无容置疑，面向普通用户的申请必然要即时响应。
业务场景简略，不须要关系数据库中很多个性（例如穿插列、穿插表，事务，连贯等等）。

HBase 逻辑表构造

HBase 物理存储构造

（1）Name Space
命名空间，相似于关系型数据库的 DatabBase 概念，每个命名空间下有多个表。HBase 有两个自带的命名空间，别离是 hbase 和 default，hbase 中寄存的是 HBase 内置的表，default 表是用户默认应用的命名空间。

（2）Region
相似于关系型数据库的表概念。不同的是，HBase 定义表时只须要申明列族即可，不须要申明具体的列。这意味着，往 HBase 写入数据时，字段能够动静、按需指定。因而，和关系型数据库相比，HBase 可能轻松应答字段变更的场景。

（3）rowKey
HBase 表中的每行数据都由一个 RowKey 和多个 Column（列）组成，数据是依照 RowKey 的字典顺序存储的，并且查问数据时只能依据 RowKey 进行检索，所以 RowKey 的设计非常重要。与 nosql 数据库一样,rowKey 是用来检索记录的主键。拜访 hbase table 中的行，只有三种形式：

通过单个 rowKey 拜访
通过 rowKey 的 range
全表扫描

rowKey 行键能够是任意字符串 (最大长度是 64KB，理论利用中长度个别为 10-100bytes)，在 hbase 外部，rowKey 保留为字节数组。Hbase 会对表中的数据依照 rowkey 排序(字典程序) 存储时，数据依照 Row key 的字典序 (byte order) 排序存储。设计 key 时，要充沛排序存储这个个性，将常常一起读取的行存储放到一起。(地位相关性)。

（4) Column Family
HBase 表中的每个列，都归属于某个列族。列族是表的 schema 的一部分(而列不是)，必须在应用表之前定义。列名都以列族作为前缀。例如 courses:history，courses:math 都属于 courses 这个列族。访问控制、磁盘和内存的应用统计都是在列族层面进行的。列族越多，在取一行数据时所要参加 IO、搜查的文件就越多，所以，如果没有必要，不要设置太多的列族。

（5）Column
HBase 中的每个列都由 Column Family(列族)和 Column Qualifier（列限定符）进行限定，例如 info：name，info：age。建表时，只需指明列族，而列限定符无需事后定义。

（6）Time Stamp
用于标识数据的不同版本（version），每条数据写入时，如果不指定工夫戳，零碎会主动为其加上该字段，其值为写入 HBase 的工夫。HBase 中通过 row 和 columns 确定的为一个存贮单元称为 cell。每个 cell 都保留着同一份数据的多个版本。版本通过工夫戳来索引。工夫戳的类型是 64 位整型。工夫戳能够由 hbase(在数据写入时主动)赋值，此时工夫戳是准确到毫秒的以后零碎工夫。工夫戳也能够由客户显式赋值。如果应用程序要防止数据版本抵触，就必须本人生成具备唯一性的工夫戳。每个 cell 中，不同版本的数据依照工夫倒序排序，即最新的数据排在最后面。

为了防止数据存在过多版本造成的的治理 (包含存贮和索引)累赘，hbase 提供了两种数据版本回收形式：

保留数据的最初 n 个版本
保留最近一段时间内的版本（设置数据的生命周期 TTL）。

用户能够针对每个列族进行设置。

（7）Cell
由{rowkey, column Family：column Qualifier, time Stamp} 惟一确定的单元。cell 中的数据是没有类型的，全副是字节码模式存贮。

读流程

（1）Client 先拜访 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
（2）拜访对应的 Region Server，获取 hbase:meta 表，依据读申请的 namespace:table/rowkey，查问出指标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的地位信息缓存在客户端的 meta cache，不便下次访问。
（3）与指标 Region Server 进行通信。
（4）别离在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查问指标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。
（5）将从文件中查问到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到 Block Cache。
（6）将合并后的最终后果返回给客户端。

写流程

（1）Client 先拜访 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
（2）拜访对应的 Region Server，获取 hbase:meta 表，依据读申请的 namespace:table/rowkey，查问出指标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的地位信息缓存在客户端的 meta cache，不便下次访问。
（3）与指标 Region Server 进行通信；
（4）将数据程序写入（追加）到 WAL；
（5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序；
（6）向客户端发送 ack；
（7）等达到 MemStore 的刷写机会后，将数据刷写到 HFile。

0、概述

正因为机器的配置并不是太好加上网络硬盘等各方面的起因，机器宕机的概率就会绝对比拟大。RegionServer 作为 HBase 集群中理论的执行节点，不可避免地也会呈现宕机。

宕机并不非常可怕，因为不会丢数据。HBase 集群中一台 RegionServer 宕机（实指 RegionServer 过程挂掉）并不会导致曾经写入的数据失落，和 MySQL 等数据库一样，HBase 采纳 WAL 机制保障这点：它会先写 HLog，再写缓存，缓存写满后一起落盘。即便意外宕机导致很多缓存数据没有及时落盘，也能够通过 HLog 日志复原进去。

可是没有数据失落并不意味着宕机对业务方没有任何影响。家喻户晓，RegionServer 宕机是由 Zookeeper 首先感知到的，而 Zookeeper 感知到 RegionServer 宕机事件是须要肯定工夫的。在这段时间内，所有的读写路由还会失常落到它下面，这些读写必然都会失败。

1、解决流程

（1）RegionServer 产生宕机，RegionServer 注册到 Zookeeper 的 /hbase/rs 节点下的长期节点就会离线，Zookeeper 第一工夫告诉 Master 进行生效备援。

（2）Master 首先会将这台 RegionServer 上所有 Region 移到其余 RegionServer 上，再将 HLog 分发给其余 RegionServer 进行回放。

（3）再批改路由，业务方的读写恢复正常。

2、实际

（1）排查 RegionServer 日志

（2）排查系统监控

0、定义

每一个 region 保护着 StartRow 与 EndRow，如果退出的数据合乎某个 Region 保护的 RowKey 范畴，则该数据交给这个 Region 保护。将新数据所要投放的分区提前布局，以进步 HBase 性能，防止产生热点问题。其中，布局的分区数与将来半年或一年的数据量和机器规模无关。

1、预分区的长处

减少数据读写效率
负载平衡，避免数据歪斜 / 热点问题
不便集群容灾调度 region
优化 Map 数量

2、预分区的几种形式

（1）手动设定预分区

create ‘staff1′,’info’,’partition1′,SPLITS => [‘1000′,’2000′,’3000′,’4000’]

（2）生成 16 进制序列预分区

create ‘staff2′,’info’,’partition2′,{NUMREGIONS => 15, SPLITALGO => ‘HexStringSplit’}

（3）依照文件中设置的规定预分区

创立 splits.txt 文件内容如下：
aaaa
bbbb
cccc
dddd

而后执行：
create ‘staff3′,’partition3’,SPLITS_FILE => ‘splits.txt’

（4）应用 JavaAPI 创立预分区

// 自定义算法，产生一系列 hash 散列值存储在二维数组中
byte[][] splitKeys = 某个散列值函数
// 创立 HbaseAdmin 实例
HBaseAdmin hAdmin = new HBaseAdmin(HbaseConfiguration.create());
// 创立 HTableDescriptor 实例
HTableDescriptor tableDesc = new HTableDescriptor(tableName);
// 通过 HTableDescriptor 实例和散列值二维数组创立带有预分区的 Hbase 表
hAdmin.createTable(tableDesc, splitKeys);

HBase 应用 RowKey 将表程度切割成多个 Hregion，每个 HRegion 都纪录了它的 StartKey 和 EndKey，Client 能够通过 HMaster 疾速的定位每个 RowKey 在哪个 HRegion 中，HRegion 由 HMaster 调配到相应在 HRegion Split 后，两个新的 HRegion 最后会和之前的父 HRegion 在雷同的 HRegionServer 上，出于负载平衡的思考，HMaster 可能会将其中的一个甚至两个重新分配的其余的 HRegionServer 中，此时会引起有些 HRegionServer 解决的数据在其余节点上，直到下一次 Major Compaction 将数据从远端的节点挪动到本地节点。这就是 Hregion 的负载平衡。

HBase 是三维有序存储的，通过 rowkey（行键），column key（column family 和 qualifier）和 TimeStamp（工夫戳）这个三个维度能够对 HBase 中的数据进行疾速定位。

HBase 中 rowkey 能够惟一标识一行记录，在 HBase 查问的时候，有以下几种形式：

通过 get 形式，指定 rowkey 获取惟一一条记录；
通过 scan 形式，设置 startRow 和 stopRow 参数进行范畴匹配；
全表扫描，即间接扫描整张表中所有行记录。

HBase rowKey 设计准则

1、长度准则

rowkey 是一个二进制码流，能够是任意字符串，最大长度 64kb，理论利用中个别为 10-100bytes，以 byte[]模式保留，个别设计成定长。倡议越短越好，不要超过 16 个字节，起因如下：

数据的长久化文件 HFile 中是依照 KeyValue 存储的，如果 rowkey 过长，比方超过 100 字节，1000w 行数据，光 rowkey 就要占用：100 * 1000w=10 亿个字节，将近 1G 数据，这样会极大影响 HFile 的存储效率。
MemStore 将缓存局部数据到内存，如果 rowkey 字段过长，内存的无效利用率就会升高，零碎不能缓存更多的数据，这样会升高检索效率。

2、散列准则

如果 rowkey 依照工夫戳的形式递增，不要将工夫放在二进制码的后面，倡议将 rowKey 的高位作为散列字段，由程序随机生成，低位放工夫字段，这样将进步数据平衡散布在每个 RegionServer，以实现负载平衡的几率。
如果没有散列字段，首字段间接是工夫信息，所有的数据都会集中在一个 RegionServer 上，这样在数据检索的时候负载会集中在个别的 RegionServer 上，造成热点问题，会升高查问效率。

3、惟一准则

必须在设计上保障其唯一性，rowkey 是依照字典程序排序存储的，因而，设计 rowkey 的时候，要充分利用这个排序的特点，将常常读取的数据存储到一块，将最近可能会被拜访的数据放到一块。

其余一些设计倡议：

尽量减少行键和列族的大小。在 HBase 中，value 永远和它的 key 一起传输的。当具体的值在零碎间传输时，它的 rowkey，列名，工夫戳也会一起传输。如果你的 rowkey 和列名很大，这个时候它们将会占用大量的存储空间。
列族尽可能越短越好，最好是一个字符。
简短的属性名尽管可读性好，然而更短的属性名存储在 HBase 中会更好。

1、什么是热点

HBase 中的行是依照 rowkey 的字典程序排序的，这种设计优化了 scan 操作，能够将相干的行以及会被一起读取的行存取在邻近地位，便于 scan。然而蹩脚的 rowkey 设计是热点的源头。热点产生在大量的 client 间接拜访集群的一个或极少数个节点（拜访可能是读，写或者其余操作）。大量拜访会使热点 region 所在的单个机器超出本身承受能力，引起性能降落甚至 region 不可用，这也会影响同一个 RegionServer 上的其余 region，因为主机无奈服务其余 region 的申请。设计良好的数据拜访模式以使集群被充沛，平衡的利用。为了防止写热点，设计 rowkey 使得不同行在同一个 region，然而在更多数据状况下，数据应该被写入集群的多个 region，而不是一个。

2、常见的防止热点的办法以及它们的优缺点

(1) 加盐

这里所说的加盐不是密码学中的加盐，而是在 rowkey 的后面减少随机数，具体就是给 rowkey 调配一个随机前缀以使得它和之前的 rowkey 的结尾不同。调配的前缀品种数量应该和你想应用数据扩散到不同的 region 的数量统一。加盐之
后的 rowkey 就会依据随机生成的前缀扩散到各个 region 上，以防止热点。

(2) 哈希

哈希会使同一行永远用一个前缀加盐。哈希也能够使负载扩散到整个集群，然而读却是能够预测的。应用确定的哈希能够让客户端重构残缺的 rowkey，能够应用 get 操作精确获取某一个行数据。

(3) 反转

第三种避免热点的办法时反转固定长度或者数字格局的 rowkey。这样能够使得 rowkey 中常常扭转的局部（最没有意义的局部）放在后面。这样能够无效的随机 rowkey，然而就义了 rowkey 的有序性。反转 rowkey 的例子以手机号为 rowkey，能够将手机号反转后的字符串作为 rowkey，这样的就防止了以手机号那样比拟固定结尾导致热点问题。

(4) 工夫戳反转

一个常见的数据处理问题是疾速获取数据的最近版本，应用反转的工夫戳作为 rowkey 的一部分对这个问题非常有用，能够用 Long.Max_Value – timestamp 追加到 key 的开端，例如 key , [key] 的最新值能够通过 scan [key]取得 [key] 的第一条记录，因为 HBase 中 rowkey 是有序的，第一条记录是最初录入的数据。

0、背景

HBase 作为列族数据库最常常被人诟病的个性包含：无奈轻易建设“二级索引”，难以执行求和、计数、排序等操作。如果做一些简略的相加或者聚合计算的时候间接将计算过程搁置在 server 端，可能缩小通信开销，从而获得很好的性能晋升。于是，HBase 在 0.92 之后引入了协处理器 (coprocessors) 实现一些新个性：可能轻易建设二次索引、简单过滤器 (谓词下推) 以及访问控制等。

1、两种协处理器：observer 和 endpoint

1.1 Observer

Observer 相似于传统数据库中的触发器，当产生某些事件的时候这类协处理器会被 Server 端调用。Observer Coprocessor 就是一些分布在 HBase Server 端代码中的 hook 钩子，在固定的事件产生时被调用。比方：put 操作之前有钩子函数 prePut，该函数在 put 操作执行前会被 Region Server 调用；在 put 操作之后则有 postPut 钩子函数。

以 HBase0.92 版本为例，它提供了三种观察者接口：

RegionObserver：提供客户端的数据操纵事件钩子：Get、Put、Delete、Scan 等。
WALObserver：提供 WAL 相干操作钩子。
MasterObserver：提供 DDL- 类型的操作钩子。如创立、删除、批改数据表等。

下图是以 RegionObserver 为例子解说 Observer 这种协处理器的原理：

（1）客户端收回 put 申请

（2）该申请被分派给适合的 RegionServer 和 region

（3）coprocessorHost 拦挡该申请，而后在该表上注销的每个 RegionObserver 上调用 prePut()

（4）如果没有被 prePut()拦挡，该申请持续送到 region，而后进行解决

（5）region 产生的后果再次被 CoprocessorHost 拦挡，调用 postPut()

（6）如果没有 postPut()拦挡该响应，最终后果被返回给客户端

1.2 Endpoint

Endpoint 协处理器相似传统数据库中的存储过程，客户端能够调用这些 Endpoint 协处理器执行一段 Server 端代码，并将 Server 端代码的后果返回给客户端进一步解决，最常见的用法就是进行汇集操作。如果没有协处理器，当用户须要找出一张表中的最大数据，即 max 聚合操作，就必须进行全表扫描，在客户端代码内遍历扫描后果，并执行求最大值的操作。这样的办法无奈利用底层集群的并发能力，而将所有计算都集中到 Client 端对立执行，势必效率低下。利用 Coprocessor，用户能够将求最大值的代码部署到 HBase Server 端，HBase 将利用底层 cluster 的多个节点并发执行求最大值的操作。即在每个 Region 范畴内执行求最大值的代码，将每个 Region 的最大值在 Region Server 端计算出，仅仅将该 max 值返回给客户端。在客户端进一步将多个 Region 的最大值进一步解决而找到其中的最大值。这样整体的执行效率就会进步很多。

EndPoint 的工作原理如图：

1.3 比照

Observer 相似于 RDBMS 中的触发器，次要在服务端工作
Endpoint 相似于 RDBMS 中的存储过程，次要在服务端工作

Observer 容许集群在失常的客户端操作过程中能够有不同的行为表现
Endpoint 容许扩大集群的能力，对客户端利用凋谢新的运算命令

Observer 能够实现权限治理、优先级设置、监控、ddl 管制、二级索引等性能
Endpoint 能够实现 min、max、avg、sum、distinct、group by 等性能

2、协处理器加载形式

协处理器的加载形式有两种：动态加载形式（Static Load）和动静加载形式（Dynamic Load）

动态加载的协处理器称之为 System Coprocessor
动静加载的协处理器称之为 Table Coprocessor

为什么须要 HBse 二级索引

因为 HBase 的查问比拟弱，如果须要实现相似于

select name,salary,count(1),max(salary) from user group by name,salary order by salary

等这样的复杂性的统计需要，基本上不可能，或者说比拟艰难，所以咱们在应用 HBase 的时候，个别都会借助二级索引的计划来进行实现。HBase 的一级索引就是 rowKey，咱们只能通过 rowkey 进行检索。如果要对库里的非 rowkey 字段进行数据检索和查问，往往要通过 MapReduce/Spark 等分布式计算框架进行，硬件资源耗费和时间延迟都会比拟高。

为了 HBase 的数据查问更高效、适应更多的场景，诸如应用非 rowkey 字段检索也能做到秒级响应，或者反对各个字段进行含糊查问和多字段组合查问等，因而须要在 HBase 下面构建二级索引，以满足事实中更简单多样的业务需要。

HBase 的二级索引计划：

1、基于 Coprocessor 计划

基于 Coprocessor 实现二级索引的大抵思路：构建一份“索引”的映射关系，存储在另一张 hbase 表或者其余 DB 外面。业界比拟出名的基于 Coprocessor 的开源计划：

华为的 hindex：基于 0.94 版本，当年刚进去的时候比拟火，然而版本较旧，GitHub 我的项目地址最近这几年就没更新过。
Apache Phoenix：性能围绕着 SQL on HBase，反对和兼容多个 HBase 版本，二级索引只是其中一块性能。二级索引的创立和治理间接有 SQL 语法反对，应用起来很简便，该我的项目目前社区活跃度和版本更新迭代状况都比拟好。

Apache Phoenix 在目前开源的计划中，是一个比拟优的抉择。主打 SQL on HBase，基于 SQL 能实现 HBase 的 CRUD 操作，反对 JDBC 协定。Apache Phoenix 在 Hadoop 生态外面地位：

Phoenix 二级索引特点：

Covered Indexes(笼罩索引)：把关注的数据字段也附在索引表上，只须要通过索引表就能返回所要查问的数据（列），所以索引的列必须蕴含所需查问的列(SELECT 的列和 WHRER 的列)。
Functional indexes(函数索引)：索引不局限于列，反对任意的表达式来创立索引。
Global indexes(全局索引)：实用于读多写少场景。通过保护全局索引表，所有的更新和写操作都会引起索引的更新，写入性能受到影响。在读数据时，Phoenix SQL 会基于索引字段，执行疾速查问。
Local indexes(本地索引)：实用于写多读少场景。在数据写入时，索引数据和表数据都会存储在本地。在数据读取时，因为无奈预先确定 region 的地位，所以在读取数据时须要查看每个 region（以找到索引数据），会带来肯定性能（网络）开销。

基于 Coprocessor 的计划优缺点：

长处：基于 Coprocessor 的计划，从开发设计的角度看，把很多对二级索引治理的细节都封装在的 Coprocessor 具体实现类外面，这些细节对里面读写的人是无感知的，简化了数据访问者的应用。

毛病：然而 Coprocessor 的计划入侵性比拟强，减少了在 Regionserver 外部须要运行和保护二级索引关系表的代码逻辑等，对 Regionserver 的性能会有肯定影响。

2、非 Coprocessor 计划

抉择不基于 Coprocessor 开发，自行在内部构建和保护索引关系也是另外一种形式。

常见的是采纳底层基于 Apache Lucene 的 Elasticsearch(上面简称 ES)或 Apache Solr，来构建弱小的索引能力、搜寻能力，例如反对含糊查问、全文检索、组合查问、排序等。

1、通用优化

（1）NameNode 的元数据备份应用 SSD。

（2）定时备份 NameNode 上的元数据，每小时或者每天备份，如果数据极其重要，能够 5~10 分钟备份一次。备份能够通过定时工作复制元数据目录即可。

（3）为 NameNode 指定多个元数据目录，应用 dfs.name.dir 或者 dfs.namenode.name.dir 指定。一个指定本地磁盘，一个指定网络磁盘。这样能够提供元数据的冗余和健壮性，免得产生故障。

（4）设置 dfs.namenode.name.dir.restore 为 true，容许尝试复原之前失败的 dfs.namenode.name.dir 目录，在创立 checkpoint 时做此尝试，如果设置了多个磁盘，倡议容许。

（5）NameNode 节点必须配置为 RAID1（镜像盘）构造。

（6）放弃 NameNode 日志目录有足够的空间，这些日志有助于帮忙你发现问题。

（7）因为 Hadoop 是 IO 密集型框架，所以尽量晋升存储的速度和吞吐量（相似位宽）。

2、Linux 优化

（1）开启文件系统的预读缓存能够进步读取速度
$ sudo blockdev –setra 32768 /dev/sda
提醒：ra 是 readahead 的缩写

（2）敞开过程睡眠池
$ sudo sysctl -w vm.swappiness=0

3、HDFS 优化（hdfs-site.xml）

（1）保障 RPC 调用会有较多的线程数

属性：dfs.namenode.handler.count
解释：该属性是 NameNode 服务默认线程数，的默认值是 10，依据机器的可用内存能够调整为 50~100。

属性：dfs.datanode.handler.count
解释：该属性默认值为 10，是 DataNode 的解决线程数，如果 HDFS 客户端程序读写申请比拟多，能够调高到 15~20，设置的值越大，内存耗费越多，不要调整过高，个别业务中，5~10 即可。

（2）正本数的调整

属性：dfs.replication
解释：如果数据量微小，且不是十分之重要，能够调整为 2~3，如果数据十分之重要，能够调整为 3~5。

（3）文件块大小的调整

属性：dfs.blocksize
解释：块大小定义，该属性应该依据存储的大量的单个文件大小来设置，如果大量的单个文件都小于 100M，倡议设置成 64M 块大小，对于大于 100M 或者达到 GB 的这种状况，倡议设置成 256M，个别设置范畴稳定在 64M~256M 之间。

4、MapReduce 优化（mapred-site.xml）

（1）Job 工作服务线程数调整
mapreduce.jobtracker.handler.count
该属性是 Job 工作线程数，默认值是 10，依据机器的可用内存能够调整为 50~100。

（2）HTTP
属性：mapreduce.tasktracker.http.threads
解释：定义 HTTP 服务器工作线程数，默认值为 40，对于大集群能够调整到 80~100。

（3）文件排序合并优化
属性：mapreduce.task.io.sort.factor
解释：文件排序时同时合并的数据流的数量，这也定义了同时关上文件的个数，默认值为 10，如果调高该参数，能够显著缩小磁盘 IO，即缩小文件读取的次数。

（4）设置工作并发
属性：mapreduce.map.speculative
解释：该属性能够设置工作是否能够并发执行，如果工作多而小，该属性设置为 true 能够显著放慢工作执行效率，然而对于提早十分高的工作，倡议改为 false，这就相似于迅雷下载。

（5）MR 输入数据的压缩
属性：mapreduce.map.output.compress、mapreduce.output.fileoutputformat.compress
解释：对于大集群而言，倡议设置 Map-Reduce 的输入为压缩的数据，而对于小集群，则不须要。

（6）优化 Mapper 和 Reducer 的个数
属性：mapreduce.tasktracker.map.tasks.maximum、mapreduce.tasktracker.reduce.tasks.maximum
解释：以上两个属性别离为一个独自的 Job 工作能够同时运行的 Map 和 Reduce 的数量。设置下面两个参数时，须要思考 CPU 核数、磁盘和内存容量。假如一个 8 核的 CPU，业务内容十分耗费 CPU，那么能够设置 map 数量为 4，如果该业务不是特地耗费 CPU 类型的，那么能够设置 map 数量为 40，reduce 数量为 20。这些参数的值批改实现之后，肯定要察看是否有较长期待的工作，如果有的话，能够缩小数量以放慢工作执行，如果设置一个很大的值，会引起大量的上下文切换，以及内存与磁盘之间的数据交换，这里没有规范的配置数值，须要依据业务和硬件配置以及教训来做出抉择。在同一时刻，不要同时运行太多的 MapReduce，这样会耗费过多的内存，工作会执行的十分迟缓，咱们须要依据 CPU 核数，内存容量设置一个 MR 工作并发的最大值，使固定数据量的工作齐全加载到内存中，防止频繁的内存和磁盘数据交换，从而升高磁盘 IO，进步性能。

大略估算公式：
map = 2 + 2/3cpu_core
reduce = 2 + 1/3cpu_core

5、HBase 优化

（1）优化 DataNode 容许的最大文件关上数
属性：dfs.datanode.max.transfer.threads
文件：hdfs-site.xml
解释：HBase 个别都会同一时间操作大量的文件，依据集群的数量和规模以及数据动作，设置为 4096 或者更高。默认值：4096

（2）优化提早高的数据操作的等待时间
属性：dfs.image.transfer.timeout
文件：hdfs-site.xml
解释：如果对于某一次数据操作来讲，提早十分高，socket 须要期待更长的工夫，倡议把该值设置为更大的值（默认 60000 毫秒），以确保 socket 不会被 timeout 掉。

（3）优化数据的写入效率
属性：mapreduce.map.output.compress、mapreduce.map.output.compress.codec
文件：mapred-site.xml
解释：开启这两个数据能够大大提高文件的写入效率，缩小写入工夫。第一个属性值批改为 true，第二个属性值批改为：
org.apache.hadoop.io.compress.GzipCodec

（4）优化 DataNode 存储
属性：dfs.datanode.failed.volumes.tolerated
文件：hdfs-site.xml
解释：默认为 0，意思是当 DataNode 中有一个磁盘呈现故障，则会认为该 DataNode shutdown 了。如果批改为 1，则一个磁盘呈现故障时，数据会被复制到其余失常的 DataNode 上，以后的 DataNode 持续工作。

（5）设置 RPC 监听数量
属性：hbase.regionserver.handler.count
文件：hbase-site.xml
解释：默认值为 30，用于指定 RPC 监听的数量，能够依据客户端的申请数进行调整，读写申请较多时，减少此值。

（6）优化 HStore 文件大小
属性：hbase.hregion.max.filesize
文件：hbase-site.xml
解释：默认值 10737418240（10GB），如果须要运行 HBase 的 MR 工作，能够减小此值，因为一个 region 对应一个 map 工作，如果单个 region 过大，会导致 map 工作执行工夫过长。该值的意思就是，如果 HFile 的大小达到这个数值，则这个 region 会被切分为两个 Hfile。

（7）优化 hbase 客户端缓存
属性：hbase.client.write.buffer
文件：hbase-site.xml
解释：用于指定 HBase 客户端缓存，增大该值能够缩小 RPC 调用次数，然而会耗费更多内存，反之则反之。个别咱们须要设定肯定的缓存大小，以达到缩小 RPC 次数的目标。

（8）指定 scan.next 扫描 HBase 所获取的行数
属性：hbase.client.scanner.caching
文件：hbase-site.xml
解释：用于指定 scan.next 办法获取的默认行数，值越大，耗费内存越大。

6、内存优化

HBase 操作过程中须要大量的内存开销，毕竟 Table 是能够缓存在内存中的，个别会调配整个可用内存的 70% 给 HBase 的 Java 堆。然而不倡议调配十分大的堆内存，因为 GC 过程继续太久会导致 RegionServer 处于长期不可用状态，个别
16~48G 内存就能够了，如果因为框架占用内存过高导致系统内存不足，框架一样会被零碎服务拖死。

7、JVM 优化（hbase-env.sh）

（1）并行 GC
参数：·-XX:+UseParallelGC·
解释：开启并行 GC。

（2）同时解决垃圾回收的线程数
参数：-XX:ParallelGCThreads=cpu_core – 1
解释：该属性设置了同时解决垃圾回收的线程数。

（3）禁用手动 GC
参数：-XX:DisableExplicitGC
解释：避免开发人员手动调用 GC。

8、Zookeeper 优化

优化 Zookeeper 会话超时工夫

参数：zookeeper.session.timeout
文件：hbase-site.xml
解释：该值会间接关系到 master 发现服务器宕机的最大周期，默认值为 30 秒，如果该值过小，会在 HBase 在写入大量数据产生而 GC 时，导致 RegionServer 短暂的不可用，从而没有向 ZK 发送心跳包，最终导致认为从节点 shutdown。个别 20 台左右的集群须要配置 5 台 Zookeeper。

一、HBase 根底

二、HDFS、Hive、HBase 三者比照

三、HBase 在商业我的项目中的能力

四、HBase 零碎架构

五、HBase shell 操作

六、HBase 应用场景

七、HBase 的表数据模型

八、HBase 读写过程

九、HRegionServer 宕机解决

十、预分区

十一、HRegion 的负载平衡

十二、rowKey 设计

十三、HBase 中热点 / 数据歪斜的产生起因及解决办法

十四、HBase 的协处理器

十五、二级索引

十六、调优

站内搜索