HBase面试题

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 欢迎采纳

1.HBase 的特点是什么?

1)大:一个表可以有数十亿行,上百万列;
2)无模式:每行都有一个可排序的主键和任意多的列,列可以根据需要动态的增加,同一张表中不同的行可以有截然不同的列; 3)面向列:面向列(族)的存储和权限控制,列(族)独立检索;
4)稀疏:空(null)列并不占用存储空间,表可以设计的非常稀疏;
5)数据多版本:每个单元中的数据可以有多个版本,默认情况下版本号自动分配,是单元格插入时的时间戳;
6)数据类型单一:Hbase 中的数据都是字符串,没有类型。

2.HBase 适用于怎样的情景?

① 半结构化或非结构化数据 对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用 HBase。以上面的例子为例,当业务发展需要存储 author 的 email,phone, address 信息时 RDBMS 需要停机维护, 而 HBase 支持动态增加。
② 记录非常稀疏

RDBMS 的行有多少列是固定的,为 null 的列浪费了存储空间。而如上文提到的,HBase 为 null 的 Column 不会被存储,这样既节省了空间又提高了读性能。
③ 多版本数据
如上文提到的根据 Row key 和 Column key 定位到的 Value 可以有任意数量的版本值,因此对于需要存储变动历史记录的数据,用 HBase 就非常方便了。比如上例中的 author 的 Address 是会变动的,业务上一般只需要最新的值, 但有时可能需要查询到历史值。
④ 超大数据量
当数据量越来越大,RDBMS 数据库撑不住了,就出现了读写分离策略,通过一个 Master 专门负责写操作,多个 Slave 负责读操作,服务器成本倍增。 随
着压力增加,Master 撑不住了,这时就要分库了,把关联不大的数据分开部署, 一些 join 查询不能用了,需要借助中间层。随着数据量的进一步增加, 一个表的记录越来越大,查询就变得很慢,于是又得搞分表,比如按 ID 取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。 采用HBase 就简单了,只需要加机器即可,HBase 会自动水平切分扩展,跟Hadoop 的无缝集成保障了其数据可靠性(HDFS)和海量数据分析的高性能
(MapReduce)。

3.描述 HBase 的 rowKey 的设计原则?

(1)Rowkey 长度原则
Rowkey 是一个二进制码流,Rowkey 的长度被很多开发者建议说设计在10~100 个字节,不过建议是越短越好,不要超过 16 个字节。
原因如下:
① 数据的持久化文件 HFile 中是按照 KeyValue 存储的,如果 Rowkey 过长比如 100 个字节,1000 万列数据光 Rowkey 就要占用 100*1000 万=10 亿个字节, 将近 1G 数据,这会极大影响 HFile 的存储效率;
② MemStore 将缓存部分数据到内存,如果 Rowkey 字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率。 因此 Rowkey 的字节长度越短越好。
③ 目前操作系统是都是 64 位系统,内存 8 字节对齐。控制在 16 个字节,8 字节的整数倍利用操作系统的最佳特性。
(2)Rowkey 散列原则
如果 Rowkey 是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将 Rowkey 的高位作为散列字段,由程序循环生成,低位放时间字段, 这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段,首字段直接是时间信息将产生所有新数据都在一个 RegionServer 上堆积的 热点现象,这样在做数据检索的时候负载将会集中在个别RegionServer,降低查询效率。
(3)Rowkey 唯一原则
必须在设计上保证其唯一性。

4.描述 HBase 中 scan 和 get 的功能以及实现的异同?

HBase 的查询实现只提供两种方式:
1)按指定 RowKey 获取唯一一条记录,get 方法
(org.apache.hadoop.hbase.client.Get) Get 的方法处理分两种 : 设置了ClosestRowBefore 和 没有设置 ClosestRowBefore 的 rowlock。主要是用来保证行的事务性,即每个 get 是以一个 row 来标记的。一个 row 中可以有很多 family 和 column。
2)按指定的条件获取一批记录,scan 方法(org.apache.Hadoop.hbase.client.Scan)实现条件查询功能使用的就是 scan 方式。
(1)scan 可以通过 setCaching 与 setBatch 方法提高速度(以空间换时间);
(2)scan 可以通过 setStartRow 与 setEndRow 来限定范围([start, end)start 是闭区间,end 是开区间)。范围越小,性能越高。
(3)scan 可以通过 setFilter 方法添加过滤器,这也是分页、多条件查询的基础。
5.请详细描述 HBase 中一个 cell 的结构?

HBase 中通过 row 和 columns 确定的为一个存贮单元称为 cell。Cell:由{row key, column(= + ), version}唯一确定的单元。cell 中的数据是没有类型的,全部是字节码形式存贮。

6.简述 HBase 中 compact 用途是什么,什么时候触发,分为哪两种, 有什么区别,有哪些相关配置参数?
在 hbase 中每当有 memstore 数据 flush 到磁盘之后,就形成一个 storefile, 当 storeFile 的数量达到一定程度后,就需要将 storefile 文件来 进行compaction 操作。
Compact 的作用:
① 合并文件
② 清除过期,多余版本的数据
③ 提高读写数据的效率
HBase 中实现了两种 compaction 的方式:minor and major. 这两种compaction 方式的区别是:
1)Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理,不做任何删除数据、多版本数据的清理工作。
2)Major 操作是对 Region 下的 HStore 下的所有 StoreFile 执行合并操作, 最终的结果是整理合并出一个文件。

7.每天百亿数据存入 HBase,如何保证数据的存储正确和在规定的时间里全部录入完毕,不残留数据?

需 求 分 析 : 1)百亿数据:证明数据量非常大;
2)存入 HBase:证明是跟 HBase 的写入数据有关;
3)保证数据的正确:要设计正确的数据结构保证正确性;
4)在规定时间内完成:对存入速度是有要求的。解决思路:
1)数据量百亿条,什么概念呢?假设一整天 60x60x24 = 86400 秒都在写入数据,那么每秒的写入条数高达 100 万条,HBase 当然是支持不了每秒百万条数据的, 所以这百亿条数据可能不是通过实时地写入,而是批量地导入。批量导入推荐使用 BulkLoad 方式(推荐阅读:Spark 之读写 HBase),性能是普通写入方式几倍以上;
2)存入 HBase:普通写入是用 JavaAPI put 来实现,批量导入推荐使用BulkLoad;
3)保证数据的正确:这里需要考虑 RowKey 的设计、预建分区和列族设计等问题;
4)在规定时间内完成也就是存入速度不能过慢,并且当然是越快越好,使用BulkLoad。

8.请列举几个 HBase 优化方法?

1)减少调整

减少调整这个如何理解呢?HBase 中有几个内容会动态调整,如 region(分区)、HFile,所以通过一些方法来减少这些会带来 I/O 开销的调整。
① Region
如果没有预建分区的话,那么随着 region 中条数的增加,region 会进行分裂,这将增加 I/O 开销,所以解决方法就是根据你的 RowKey 设计来进行预建分区, 减少 region 的动态分裂。
② HFile
HFile 是数据底层存储文件,在每个 memstore 进行刷新时会生成一个HFile,当 HFile 增加到一定程度时,会将属于一个 region 的 HFile 进行合并, 这个步骤会带来开销但不可避免,但是合并后 HFile 大小如果大于设定的值,
那么 HFile 会重新分裂。为了减少这样的无谓的 I/O 开销,建议估计项目数据量大小, 给 HFile 设定一个合适的值。
2)减少启停
数据库事务机制就是为了更好地实现批量写入,较少数据库的开启关闭带来的开销,那么 HBase 中也存在频繁开启关闭带来的问题。
① 关闭 Compaction,在闲时进行手动 Compaction。
因为 HBase 中存在 Minor Compaction 和 Major Compaction,也就是对HFile 进行合并,所谓合并就是 I/O 读写,大量的 HFile 进行肯定会带来 I/O 开销, 甚至是 I/O 风暴,所以为了避免这种不受控制的意外发生,建议关闭自动 Compaction,在闲时进行 compaction。
② 批量数据写入时采用 BulkLoad。

如果通过 HBase-Shell 或者 JavaAPI 的 put 来实现大量数据的写入,那么性能差是肯定并且还可能带来一些意想不到的问题,所以当需要写入大量离线数据时 建议使用 BulkLoad。
3)减少数据量
虽然我们是在进行大数据开发,但是如果可以通过某些方式在保证数据准确性同时减少数据量,何乐而不为呢?
① 开启过滤,提高查询速度
开启 BloomFilter,BloomFilter 是列族级别的过滤,在生成一个 StoreFile 同时会生成一个 MetaBlock,用于查询时过滤数据
② 使用压缩
一般推荐使用 Snappy 和 LZO 压缩4)合理设计
在一张 HBase 表格中 RowKey 和 ColumnFamily 的设计是非常重要,好的设计能够提高性能和保证数据的准确性
① RowKey 设计:应该具备以下几个属性
散列性:散列性能够保证相同相似的 rowkey 聚合,相异的 rowkey 分散, 有利于查询。
简短性:rowkey 作为 key 的一部分存储在 HFile 中,如果为了可读性将rowKey 设计得过长,那么将会增加存储压力。
唯一性:rowKey 必须具备明显的区别性。业务性:举例来说:

假如我的查询条件比较多,而且不是针对列的条件,那么 rowKey 的设计就应该支持多条件查询。
如果我的查询要求是最近插入的数据优先,那么 rowKey 则可以采用叫上Long.Max-时间戳的方式,这样 rowKey 就是递减排列。
② 列族的设计:列族的设计需要看应用场景
优势:HBase 中数据时按列进行存储的,那么查询某一列族的某一列时就不需要全盘扫描,只需要扫描某一列族,减少了读 I/O; 其实多列族设计对减少的作用不是很明显,适用于读多写少的场景
劣势:降低了写的 I/O 性能。原因如下:数据写到 store 以后是先缓存在memstore 中,同一个 region 中存在多个列族则存在多个 store, 每个 store 都一个 memstore,当其实 memstore 进行 flush 时,属于同一个 region 的store 中的 memstore 都会进行 flush,增加 I/O 开销。

9.Region 如何预建分区?
预分区的目的主要是在创建表的时候指定分区数,提前规划表有多个分区, 以及每个分区的区间范围,这样在存储的时候 rowkey 按照分区的区间存储, 可以避免 region 热点问题。
通常有两种方案: 方案 1:shell 方法

create 'tb_splits', {NAME => 'cf',VERSIONS=> 3},{SPLITS => ['10','20','30']}
方案 2:JAVA 程序控制
① 取样,先随机生成一定数量的 rowkey,将取样数据按升序排序放到一个集合里;
② 根据预分区的 region 个数,对整个集合平均分割,即是相关的 splitKeys;
③ HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][]splitkeys)可以指定预分区的 splitKey, 即是指定region 间的 rowkey 临界值。
10.HRegionServer 宕机如何处理?
1)ZooKeeper 会监控 HRegionServer 的上下线情况,当 ZK 发现某个HRegionServer 宕机之后会通知 HMaster 进行失效备援;
2)该 HRegionServer 会停止对外提供服务,就是它所负责的 region 暂时停止对外提供服务;
3)HMaster 会将该 HRegionServer 所负责的 region 转移到其他HRegionServer 上,并且会对 HRegionServer 上存在 memstore 中还未持久化到磁盘中的数据进行恢复;
4)这个恢复的工作是由 WAL 重播来完成,这个过程如下:
① wal 实际上就是一个文件,存在/hbase/WAL/对应 RegionServer 路径下。

② 宕机发生时,读取该 RegionServer 所对应的路径下的 wal 文件,然后根据不同的 region 切分成不同的临时文件 recover.edits。
③ 当 region 被分配到新的 RegionServer 中,RegionServer 读取 region 时会进行是否存在 recover.edits,如果有则进行恢复。

11.HBase 读写流程?
读:
① HRegionServer 保存着 meta 表以及表数据,要访问表数据,首先 Client 先去访问 zookeeper,从 zookeeper 里面获取 meta 表所在的位置信息, 即找到这个 meta 表在哪个 HRegionServer 上保存着。
② 接着 Client 通过刚才获取到的 HRegionServer 的 IP 来访问 Meta 表所在
的 HRegionServer,从而读取到 Meta,进而获取到 Meta 表中存放的元数据。
③ Client 通过元数据中存储的信息,访问对应的 HRegionServer,然后扫描所在 HRegionServer 的 Memstore 和 Storefile 来查询数据。
④ 最后 HRegionServer 把查询到的数据响应给 Client。
写:
① Client 先访问 zookeeper,找到 Meta 表,并获取 Meta 表元数据。
② 确定当前将要写入的数据所对应的 HRegion 和 HRegionServer 服务器。
③ Client 向该 HRegionServer 服务器发起写入数据请求,然后HRegionServer 收到请求并响应。

④ Client 先把数据写入到 HLog,以防止数据丢失。
⑤ 然后将数据写入到 Memstore。
⑥ 如果 HLog 和 Memstore 均写入成功,则这条数据写入成功。
⑦ 如果 Memstore 达到阈值,会把 Memstore 中的数据 flush 到 Storefile 中。
⑧ 当 Storefile 越来越多,会触发 Compact 合并操作,把过多的 Storefile 合并成一个大的 Storefile。
⑨ 当 Storefile 越来越大,Region 也会越来越大,达到阈值后,会触发 Split 操作,将 Region 一分为二。

12.HBase 内部机制是什么?
Hbase 是一个能适应联机业务的数据库系统
物理存储:hbase 的持久化数据是将数据存储在 HDFS 上。
存储管理:一个表是划分为很多 region 的,这些 region 分布式地存放在很多 regionserver 上 Region 内部还可以划分为 store, store 内部有memstore 和 storefile。
版本管理:hbase 中的数据更新本质上是不断追加新的版本,通过 compact 操作来做版本间的文件合并 Region 的 split。
集群管理:ZooKeeper + HMaster + HRegionServer。

13.Hbase 中的 memstore 是用来做什么的?
hbase 为了保证随机读取的性能,所以 hfile 里面的 rowkey 是有序的。当客户端的请求在到达 regionserver 之后,为了保证写入 rowkey 的有序性, 所以不能将数据立刻写入到 hfile 中,而是将每个变更操作保存在内存中,也就是memstore 中。memstore 能够很方便的支持操作的随机插入, 并保证所有的操作在内存中是有序的。当 memstore 达到一定的量之后,会将 memstore 里面的数据 flush 到 hfile 中,这样能充分利用 hadoop 写入大文件的性能优势, 提高写入性能。
由于 memstore 是存放在内存中,如果 regionserver 因为某种原因死了,会导致内存中数据丢失。所有为了保证数据不丢失, hbase 将更新操作在写入memstore 之前会写入到一个 write ahead log(WAL)中。WAL 文件是追加、顺序写入的,WAL 每个 regionserver 只有一个, 同一个 regionserver 上所有 region 写入同一个的 WAL 文件。这样当某个 regionserver 失败时,可以通过 WAL 文件,将所有的操作顺序重新加载到 memstore 中。
15.HBase 在进行模型设计时重点在什么地方?一张表中定义多少个Column Family 最合适?为什么?

Column Family 的个数具体看表的数据,一般来说划分标准是根据数据访问频度,如一张表里有些列访问相对频繁,而另一些列访问很少, 这时可以把这张表划分成两个列族,分开存储,提高访问效率。
16.如何提高 HBase 客户端的读写性能?请举例说明
① 开启 bloomfilter 过滤器,开启 bloomfilter 比没开启要快 3、4 倍
② Hbase 对于内存有特别的需求,在硬件允许的情况下配足够多的内存给它
③ 通过修改 hbase-env.sh 中的 export HBASE_HEAPSIZE=3000 #这里默认为 1000m
④ 增大 RPC 数量
通过修改 hbase-site.xml 中的 hbase.regionserver.handler.count 属性, 可以适当的放大 RPC 数量,默认值为 10 有点小。
17.HBase 集群安装注意事项?
① HBase 需要 HDFS 的支持,因此安装 HBase 前确保 Hadoop 集群安装完成;
② HBase 需要 ZooKeeper 集群的支持,因此安装 HBase 前确保ZooKeeper 集群安装完成;

③ 注意 HBase 与 Hadoop 的版本兼容性;
④ 注意 hbase-env.sh 配置文件和 hbase-site.xml 配置文件的正确配置;
⑤ 注意 regionservers 配置文件的修改;
⑥ 注意集群中的各个节点的时间必须同步,否则启动 HBase 集群将会报错。
18.直接将时间戳作为行健,在写入单个 region 时候会发生热点问题, 为什么呢?
region 中的 rowkey 是有序存储,若时间比较集中。就会存储到一个 region 中,这样一个 region 的数据变多,其它的 region 数据很少,加载数据就会很慢, 直到 region 分裂,此问题才会得到缓解。
19.请描述如何解决 HBase 中 region 太小和 region 太大带来的冲突?
Region 过大会发生多次 compaction,将数据读一遍并重写一遍到 hdfs 上, 占用 io,region 过小会造成多次 split,region 会下线,影响访问服务, 最佳的解决方法是调整 hbase.hregion. max.filesize 为 256m。
20.简述hbase工作机制?
工作机制:
Hbase的数据都是存储在hdsf上的,是可以无限存储的,只要添加集群容量就可以,由于是分布式数据库,Hbase服务器肯定也是很多台,那么就需要分任务给不同的服务器,按照数据库行键的范围(region)来分,比如一号服务器负责0000-9999的一个region,然后不同的服务器负责不同的查找范围,因此在hdfs中的目录存放结构也不是在一个目录下,而是一个一张表在一个目录下,但是里面又分为不同的region目录,这样可以避免datanode频繁的io操作
由于是分布式就存在机器节点挂掉的情况,如果某一台region server挂掉了,那么就需要一个master的角色,来监控着region server,如果有region server挂掉了,那么master就会将他的任务分配到别的机器节点上,Hbase是用zookeeper来做协作服务的, region server实时的向zookeeper注册信息,为了防止master挂掉,也可以配置多个master

21.简述hive与hbase之间的区别?
Hive的定位是数据仓库,虽然也有增删改查,但其删改查对应的是整张表而不是单行数据,查询的延迟较高。
其本质是更加方便的使用mr的威力来进行离线分析的一个数据分析工具。
HBase的定位是hadoop的数据库,是一个典型的Nosql,所以HBase是用来在大量数据中进行低延迟的随机查询的。
22.Hbase合并怎么操作?合并的大小是多少?
compact的作用
flush操作会将memstore的数据落地为一个个StoreFile(HFile),那么随着时间的增长在HDFS上面就会有很多的HFile文件,这样对读操作会产生比较大的影响(读操作会对HFile进行归并查询),并且对DataNode的压力也会比较大。为了降低对读操作的影响,可以对这些HFile进行compact操作,但是compact操作会产生大量的IO,所以可以看出compact的本质就是用IO操作换取后续读性能的提升。
minor compaction (小合并)
选取部分小的、相邻的HFile文件,形成一个较大的HFile文件。
小合并并不会进行过期数据的清除工作。
major compaction(大合并)
合并所有的HFile文件为一个大的HFile文件
大合并会清理TTL过期数据、超出设定版本号的数据以及delete标记的数据
一般是手动进行,将参数hbase.hregion.majorcompaction的值设为0,表示禁用major compaction。其默认值为7天,允许上下浮动hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter的值,后者默认是0.5。即[7 - 70.5, 7 + 70.5]
触发条件
一、memstore flush之后
memstore flush之后,都需要对当前Store的文件数量进行判断,一旦大于hbase.hstore.compactionThreshold(现在的版本中这个参数的名字为hbase.hstore.compaction.min)的值(默认3),触发合并操作。该参数一般需要调大。一次minor cmpaction最多合并hbase.hstore.compaction.max个文件(默认值10)。
二、定期compaction
后台线程CompactionChecker定期触发检查是否需要执行compaction,检查周期为:hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier,默认值为10s和1000
当文件大小小于参数hbase.hstore.compaction.min.size指定的值的时候(默认128M,单位字节),该文件会被加入到合并队列中,当合并队列中的StoreFile数量超过参数hbase.hstore.compaction.min(更早的版本中这个的参数的名字为hbase.hstore.compactionThreshold)的值(默认3)时会触发compaction操作。一次minor cmpaction最多合并hbase.hstore.compaction.max个文件(默认值10)。
如果一个文件的大小超过hbase.hstore.compaction.max.size的值(默认值LONG.MAX_VALUE),则会被compaction操作排除。
通过hbase.hstore.compaction.ratio参数(默认值1.2)确定大小超过hbase.hstore.compaction.min.size的文件是否需要进行compaction。如果一个文件的大小小于它后面(按文件产生的先后顺序,总是从新产生的文件开始选择即“老文件”)的hbase.hstore.compaction.max个StoreFile的大小之和乘以hbase.hstore.compaction.ratio,则该StoreFile文件也会加入到合并队列中。
三、手动触发major compaction
使用命令major_compact
23.简述hbase的过滤器?
单个列过滤器
列过滤器
列族过滤器
前缀过滤器
键值过滤器
24.简述hbase两种compaction的方式?
· Minor Compaction
只合并小文件,对TTL过期数据设置过期清理,不会对文件内容进行清除操作
· · Major Compaction
对 Region 下同一个 Column family 的 StoreFile 合并为一个大文件,并且清除删除、过期、多余版本的数据。
25.每日日志数据有多大?业务数据有多大?
每天日志数据有几百万(具体的话700多万)
每天业务数据有几十万(具体的话30多万)
26.Hbase的查询效率如何进行提升?
1、使用bloomfilter和mapfile_index_interval

2、 hbase对于内存有特别的嗜好,在硬件允许的情况下配足够多的内存给它。

通过修改hbase-env.sh中的
export HBASE_HEAPSIZE=3000 #这里默认为1000m

3、修改java虚拟机属性

(1)、在环境允许的情况下换64位的
(2)、替换掉默认的垃圾回收器,因为默认的垃圾回收器在多线程环境下会有更多的wait            等待
export HBASE_OPTS="-server -XX:NewSize=6m -XX:MaxNewSize=6m             -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode"

4、增大RPC数量

通过修改hbase-site.xml中的    
hbase.region.handler.count属性,可以适当的放大。默认值为10有点小

5、做程序开发是注意的地方

(1)、需要判断所求的数据行是否存在时,尽量不要用HTable.exists(final byte [] row) 而用            HTable.exists(final byte [] row, final byte[] column)等带列族的方法替代。
(2)、不要使用HTable.get(final byte [] row, final byte [] column) == null来判断所求的数据        存在,而是用HTable.exists(final byte [] row, final byte[] column)替代
(3)、HTable.close()方法少用.因为我遇到过一些很令人费解的错误

6、记住HBase是基于列模式的存储,如果一个列族能搞定就不要把它分开成两个,的那套 在这里很不实用.分成多个列来存储会浪费更多的空间,除非你认为现在的硬盘和白菜一个 价。
7、如果数据量没有达到TB级别或者没有上亿条记录,很难发挥HBase的优势,建议换关系 数据库或别的存储技术。
27.简述HMaster的作用
HBase中的每张表都通过键按照一定的范围被分割成多个子表(HRegion),默认一个 HRegion超过256M就要被分割成两个,这个过程由HRegionServer管理,而HRegion的分 配由HMaster管理 ​

  1.为HRegionServer分配HRegion
  2.负责HRegionServer的负载均衡
  3.发现失效的HRegionServer并重新分配
  4.HDFS上的垃圾文件回收
  5.处理Schema更新请求

28.简述HRegionServer的作用
1.维护HMaster分配给它的HRegion,处理对这些HRegion的IO请求
2.负责切分正在运行过程中变得过大的HRegion可以看到,Client访问HBase上的数据并不 需要HMaster参与,寻址访问ZooKeeper和HRegionServer,数据读写访问HRegionServer, HMaster仅仅维护Table和Region的元数据信息,Table的元数据信息保存在ZooKeeper 上,负载很低。HRegionServer存取一个子表时,会创建一个HRegion对象,然后对表的 每个列簇创建一个Store对象,每个Store都会有一个MemStore和0或多个StoreFile与 之对应,每个StoreFile都会对应一个HFile,HFile就是实际的存储文件。因此,一个HRegion 有多少列簇就有多少个Store。
3 一个HRegionServer会有多个HRegion和一个HLog。
29.简述HRegion的作用

  Table在行的方向上分割为多个HRegion,HRegion是HBase中分布式存储和负载均衡          的最小单元,即不同的HRegion可以分别在不同的HRegionServer上,但同一个HRegion          是不会拆分到多个HRegionServer上的。HRegion按大小分割,每个表一般只有一个          HRegion,随着数据不断插入表,HRegion不断增大,当HRegion的某个列簇达到一个          阀值(默认256M)时就会分成两个新的HRegion。

1、<表名,StartRowKey, 创建时间>

    2、由目录表(-ROOT-和.META.)记录该Region的EndRowKey
     HRegion定位:HRegion被分配给哪个HRegionServer是完全动态的,所以需要机制            来定位HRegion具体在哪个HRegionServer,HBase使用三层结构来定位HRegion:

    1、通过zk里的文件/hbase/rs得到-ROOT-表的位置。-ROOT-表只有一个region。
  2、通过-ROOT-表查找.META.表的第一个表中相应的HRegion位置。其实-ROOT-表             是.META.表的第一个region;
     .META.表中的每一个Region在-ROOT-表中都是一行记录。
  3、通过.META.表找到所要的用户表HRegion的位置。用户表的每个HRegion在.META.            表中都是一行记录。
  -ROOT-表永远不会被分隔为多个HRegion,保证了最多需要三次跳转,就能定位到任意         的region。Client会将查询的位置信息保存缓存起来,缓存不会主动失效,因此如果Client         上的缓存全部失效,则需要进行6次网络来回,才能定位到正确的HRegion,其中三次         用来发现缓存失效,另外三次用来获取位置信息。

30.简述你知道的Hbase优化?
hbase的优化
一、写入数据方面
1.Auto Flash

  通过调用HTable.setAutoFlushTo(false)方法可以将HTable写客户端自动flush关        闭,这样可以批量写入数据到HBase,而不是有一条put就执行一次更新,只        有当put填满客户端写缓存的时候,才会向HBase服务端发起写请求。默认情        况下auto flush是开启的。

2.Write Buffer

  通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端        的写buffer大小,如果新设置的buffer小于当前写buffer中的数据时,buffer        将会被flush到服务端。其中,writeBufferSize的单位是byte字节数,可以根基        实际写入数据量的多少来设置该值。

3.WAL Flag

  在HBase中,客户端向集群中的RegionServer提交数据时(Put/Delete操作),        首先会写到WAL(Write Ahead Log)日志,即HLog,一个RegionServer上的所        有Region共享一个HLog,只有当WAL日志写成功后,再接着写MemStore,        然后客户端被通知提交数据成功,如果写WAL日志失败,客户端被告知提交失        败,这样做的好处是可以做到RegionServer宕机后的数据恢复。
  对于不太重要的数据,可以在Put/Delete操作时,通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数,放弃写WAL日志,以提高数据写入的性能。

注:如果关闭WAL日志,一旦RegionServer宕机,Put/Delete的数据将会无法根 据WAL日志进行恢复。
4.Compression 压缩

  数据量大,边压边写也会提升性能的,毕竟IO是大数据的最严重的瓶颈,哪        怕使用了SSD也是一样。众多的压缩方式中,推荐使用SNAPPY。从压缩率和        压缩速度来看,性价比最高。
      HColumnDescriptor hcd = new HColumnDescriptor(familyName);   
      hcd.setCompressionType(Algorithm.SNAPPY);  

5.批量写

  通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase,同样        HBase提供了另一个方法:通过调用HTable.put(List<Put>)方法可以将指定的row         key列表,批量写入多行记录,这样做的好处是批量执行,只需要一次网络I/O        开销,这对于对数据实时性要求高,网络传输RTT高的情景下可能带来明显的        性能提升。

6.多线程并发写

  在客户端开启多个 HTable 写线程,每个写线程负责一个 HTable 对象的 flush         操作,这样结合定时 flush 和写 buffer(writeBufferSize),可以既保证在数据        量小的时候,数据可以在较短时间内被 flush(如1秒内),同时又保证在数        据量大的时候,写 buffer 一满就及时进行 flush。

二、读数据方面
1.批量读

  通过调用 HTable.get(Get) 方法可以根据一个指定的 row key 获取一行记录,        同样 HBase 提供了另一个方法:通过调用 HTable.get(List) 方法可以根据一个        指定的 row key 列表,批量获取多行记录,这样做的好处是批量执行,只需要        一次网络 I/O 开销,这对于对数据实时性要求高而且网络传输 RTT 高的情景        下可能带来明显的性能提升。

2.缓存查询结果

  对于频繁查询 HBase 的应用场景,可以考虑在应用程序中做缓存,当有新的        查询请求时,首先在缓存中查找,如果存在则直接返回,不再查询 HBase;否        则对 HBase 发起读请求查询,然后在应用程序中将查询结果缓存起来。至于        缓存的替换策略,可以考虑 LRU 等常用的策略。 ​

三、数据及集群管理
1.预分区

  默认情况下,在创建HBase表的时候会自动创建一个Region分区,当导入数据        的时候,所有的HBase客户端都向Region写数据,知道这个Region足够大才        进行切分,一种可以加快批量写入速度的方法是通过预先创建一些空的            Regions,这样当数据写入HBase的时候,会按照Region分区情况,在进群内        做数据的负载均衡。

2.Rowkey优化

  rowkey是按照字典存储,因此设置rowkey时,要充分利用排序特点,将经常        一起读取的数据存储到一块,将最近可能会被访问的数据放到一块。
  rowkey若是递增生成的,建议不要使用正序直接写入,可以使用字符串反转        方式写入,使得rowkey大致均衡分布,这样设计的好处是能将RegionServer        的负载均衡,否则容易产生所有新数据都在集中在一个RegionServer上堆积的        现象,这一点还可以结合table的与分区设计。

减少Column Family数量

  不要在一张表中定义太多的column family。目前HBase并不能很好的处理超过        2-3个column family的表,因为某个column family在flush的时候,它临近的c        olumn family也会因关联效应被触发flush,最终导致系统产生更过的I/O;

3.设置最大版本数

  创建表的时候,可以通过 HColumnDescriptor.setMaxVersions(int maxVersions)         设置表中数据的最大版本,如果只需要保存最新版本的数据,那么可以设置         setMaxVersions(1)。

4.缓存策略(setCaching)

  创建表的时候,可以通过HColumnDEscriptor.setInMemory(true)将表放到            RegionServer的缓存中,保证在读取的时候被cache命中。

5.设置存储生命期

  创建表的时候,可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置        表中数据的存储生命周期,过期数据将自动被删除

6.磁盘配置

  每台RegionServer管理10-1000个Regions。每个Region在1-2G,则每台server        最少要10G,最大要1000*2G=2TB,考虑3备份,需要6TB。方案1是3块2TB        磁盘,2是12块500G磁盘,带宽足够时,后者能提供更大的吞吐率,更细力        度的冗余备份,更快速的单盘故障恢复。

分配何时的内存给RegionServer

  在不影响其他服务的情况下,越大越好。在HBase的conf目录下的hbase-env.sh        的最后添加export HBASE_REGIONSERVER_OPTS="- Xmx16000m                        $HBASE_REGIONSERVER_OPTS"

其中16000m为分配给REgionServer的内存大小。
7.写数据的备份数

  备份数与读性能是成正比,与写性能成反比,且备份数影响高可用性。有两         种配置方式,一种是将hdfs-site.xml拷贝到hbase的conf目录下,然后在其         中添加或修改配置项dfs.replication的值为要设置的备份数,这种修改所有的        HBase用户都生效。另一种方式是改写HBase代码,让HBase支持针对列族设        置备份数,在创建表时,设置列族备份数,默认为3,此种备份数支队设置的        列族生效。

客户端一次从服务器拉取的数量

  通过配置一次拉取较大的数据量可以减少客户端获取数据的时间,但是他会占        用客户端的内存,有三个地方可以进行配置
  在HBase的conf配置文件中进行配置hbase.client.scanner.caching;
  通过调用HTble.setScannerCaching(int scannerCaching)进行配置;
  通过调用Sacn.setCaching(int caching)进行配置,三者的优先级越来越高。

8.客户端拉取的时候指定列族

  scan是指定需要column family,可以减少网络传输数据量,否则默认scan操作        会返回整行所有column family的数据

拉取完数据之后关闭ResultScanner

  通过 scan 取完数据后,记得要关闭 ResultScanner,否则 RegionServer 可能        会出现问题(对应的 Server 资源无法释放)。

9.RegionServer的请求处理IO线程数

  较少的IO线程适用于处理单次请求内存消耗较高的Big Put场景(大容量单词        Put或设置了较大cache的scan,均数据Big Put)或RegionServer的内存比较        紧张的场景。
  较多的IO线程,适用于单次请求内存消耗低,TPS要求(每次事务处理量)非        常高的场景。这只该值的时候,以监控内存为主要参考
  在hbase-site.xml配置文件中配置项为hbase.regionserver.handle.count

10.Region大小设置

  配置项hbase.hregion.max.filesize,所属配置文件为hbase-site.xml,默认大小是        256m。
      在当前RegionServer上单个Region的最大存储空间,单个Region超过该        值时,这个Region会被自动split成更小的Region。小Region对split和compaction        友好,因为拆分Region或compact小Region里的StoreFile速度非常快,内存        占用低。缺点是split和compaction会很频繁,特别是数量较多的小Region不        同的split,compaction,会导致集群响应时间波动很大,Region数量太多不仅        给管理上带来麻烦,设置会引起一些HBase个bug。一般 512M 以下的都算小         Region。大 Region 则不太适合经常 split 和 compaction,因为做一次 compact         和 split 会产生较长时间的停顿,对应用的读写性能冲击非常大。
      此外,大 Region 意味着较大的 StoreFile,compaction 时对内存也是一个        挑战。如果你的应用场景中,某个时间点的访问量较低,那么在此时做 compact         和split,既能顺利完成 split 和 compaction,又能保证绝大多数时间平稳的读        写性能。compaction 是无法避免的,split 可以从自动调整为手动。只要通过        将这个参数值调大到某个很难达到的值,比如 100G,就可以间接禁用自动         split(RegionServer 不会对未到达 100G 的 Region 做 split)。再配合                 RegionSplitter 这个工具,在需要 split 时,手动 split。手动 split 在灵活性和        稳定性上比起自动 split 要高很多,而且管理成本增加不多,比较推荐 online         实时系统使用。内存方面,小 Region 在设置 memstore 的大小值上比较灵活,        大 Region 则过大过小都不行,过大会导致 flush 时 app 的 IO wait 增高,过        小则因 StoreFile 过多影响读性能。

31.如果让你管理hbase你有什么看法
运维任务
regionserver添加/删除节点 master备份
1 添加新节点
复制hbase目录并进行配置文件修改(regionserver增加新节点)并保持配置文件在 全集群一致,在新节点上启动相关进程如hbase-daemon.sh start regionserver命令
2 删除节点
停止相关进程(例如regionserver hbase-daemon.sh stop regionserver),下线节点需 注意
(2-1) 如果负载均衡进程正在执行,请先停止,因为其可能会和master转移region 产生竞争
(2-2) 如果该节点上的数据量很大,移动region的过程可能很漫长
3 master备份
(3-1) 修改配置文件conf/backup-master文件
(3-2) 启动相关进程 hbase-daemon.sh start master
数据迁移
(1) 导入导出
HBase的jar包中包含了两个以MapReduce作业形式来导入导出数据的工具,如 hadoop jar ${hbase.jar} export ${tablename} ${outputdir
该工具其余的参数可以做到增量导出、控制导出的数据版本等功能.
32.说一下Hbase行健列族的概念,物理模型,表的设计原则?
1.行健:是hbase表自带的,每个行健对应一条数据。
2.列族:是创建表时指定的,为列的集合,每个列族作为一个文件单独存储,存储的数据都是字节数组,其中的数据可以有很多,通过时间戳来区分。
3.物理模型:整个hbase表会拆分为多个region,每个region记录着行健的起始点保存在不同的节点上,查询时就是对各个节点的并行查询,当region很大时使用.META表存储各个region的起始点,-ROOT又可以存储.META的起始点。
4.rowkey的设计原则:各个列簇数据平衡,长度原则、相邻原则,创建表的时候设置表放入regionserver缓存中,避免自动增长和时间,使用字节数组代替string,最大长度64kb,最好16字节以内,按天分表,两个字节散列,四个字节存储时分毫秒。
5.列族的设计原则:尽可能少(按照列族进行存储,按照region进行读取,不必要的io操作),经常和不经常使用的两类数据放入不同列族中,列族名字尽可能短。
33.为什么用HBase存储?
HBase(Hadoop DataBase)是一个高可靠性、高性能、可伸缩、面向列的分布式数据库(分布式存储系统)。
HBase与Hadoop的关系非常紧密,Hadoop的HDFS提供了高可靠的底层存储支持,Hadoop MapReduce为HBase提供了高性能的计算能力,Zookeeper为HBase提供了稳定性及Failover机制的保障。同时其他周边产品诸如Hive可以与HBase相结合,使得对HBase中的数据进行数据统计变得简单,Sqoop为HBase提供了方便的RDBMS数据导入功能,使传统数据库的数据向HBase中迁移变得容易,Spark等高性能的分布式内存计算引擎也可以帮助我们更加快速的对HBase中的数据进行处理分析。

  1. HBase的读写流程?

.元数据存储
HBase中有一个系统表hbase:meta,存储元数据信息,可以在HBase Web UI查看到相关信息。
该表记录保存了每个表的Region地址,还有一些其他信息,例如Region的名字,对应表的名字,开始Rowkey(STARTKEY)、结束Rowkey(ENDKEY)、服务器的信息。hbase:meta表中每一行对应一个单一的Region。
hbase:meta表单个数据含义:
RowKey(行键)- TableName(表名),table produce epoch(表创建的时间戳)。
ColumnFamily(列族) - info (信息)
ColumnQualifier(列)- regioninfo;server;serverstartcode;seqnumDuringOpen
value - NAME:表名 STARTKEY:表行键开始值 ENDKEY:表行键结束值 ENCODED:Region编码后的名字;服务器地址:端口;服务开始的时间戳;Region在线时长的一个二进制串
Zookeeper中存储了hbase:meta表的位置,客户端可以通过Zookeeper查找到hbase:meta表的位置,hbase:meta是HBase当中的一张表,肯定由一个HRegionServer来管理,其实主要就是要通过Zookeeper的"/hbase/meta-region-server"获取存储"hbase:meta"表的HRegionServer的地址。
附:ZK的作用
作用一:HMaster、RegionServer容错
当HBase集群启动成功后,会在ZK注册如下znode:
./hbase/master,其中包含当前活动(Active)的HMaster信息;
./hbase/backup-masters/[host-name],每个子znode包含当前作为热备的HMaster信息;
./hbase/rs/[host-name],每个子znode包含各个RegionServer的信息。
所有znode都是临时(ephemeral)节点,HMaster和RegionServer通过心跳维护这些znode。

作用二:Log Split管理
Log Split的信息需要有一个中心组件来统一协调。HMaster会在ZK上注册 /hbase/splitlog临时节点,其中存放有存活RegionServer与其应该处理的Region HLog的映射关系。各个RegionServer从该节点得到分配的Region,重放HLog,并将结果写回该节点,以通知HMaster进行后续操作。


作用三:.META.表位置维护
ZK通过永久(persistent)节点/hbase/meta-region-server来记录.META.表保存在哪个RegionServer上。


作用四:Replication管理
HBase的Replication是比较高级的功能,用于主集群和从集群之间的数据同步,从而支持容灾和备份。开启Replication之后,主集群会将数据实时地推送给各个从集群(可以是异步、同步或串行的),且保证数据的最终一致性。整个Replication的状态信息都储存在ZK的 /hbase/replication这个znode下。

多个HBase集群是可以共用一个ZK集群的。只需要修改HBase的zookeeper.znode.parent参数,对不同集群指定不同的ZK根路径即可,例如/hbase-cluster1、/hbase-cluster2。
.读数据流程

.HBaseClient先访问Zookeeper,从meta表读取Region的位置,然后读取meta表中的数据。meta中又存储了用户表的Region信息;

.根据Rowkey在meta表中找到对应的Region信息;

.找到这个Region对应的RegionServer;

.查找对应的Region;

.先从MetaStore找数据,如果没有,再到BlockCache里面读;

.BlockCache还没有,再到StoreFile上读(为了读取的效率);

.如果是从StoreFile里面读取的数据,不是直接返回给客户端,而是先写入BlockCache,再返回给客户端。
.写数据流程

.HBaseClient访问Zookeeper,获取meta表所处位置(IP地址);

.访问meta表,然后读取meta表中的数据;

.根据namespace(类似于关系数据库中的数据库)、表名和Rowkey在meta表中找到该Rowkey应该写入到哪个Region;

.找到这个Region对应的RegionServer,并发送写数据请求;

.HRegionServer将数据先写到HLog(Write Ahead Log)。为了数据的持久化和恢复;

.HRegionServer将数据写到内存(MemStore);

.反馈给HBaseClient写入成功。
HBase将数据写入内存中后,就返回给客户端写入成功,响应非常快。这也是为什么HBase写数据速度快的原因。
.数据flush过程
HBase写数据是写入到MemStore内存就会返回客户端了,并没有直接落磁盘。磁盘IO非常小。那么什么时候数据会落到磁盘呢?其实MemStore空间是有限的,当MemStore数据达到阈值(默认是128MB),RegionServer将数据刷到HDFS上,生成HFile,然后将内存中的数据删除,同时删除HLog中的历史数据。该操作是由RegionServer自己完成

  1. Rowkey如何设计可以避免数据热点问题?

通常有3种方法来解决Region热点问题:
.Reverse反转
针对固定长度的Rowkey反转后存储,这样可以使得Rowkey中经常改变的部分放在前面,可以有效的随机Rowkey。反转Rowkey的例子通常以手机举例,可以将手机号反转后的字符串作为Rowkey,这样就避免了以手机号那样比较固定开头(139x、18x等)导致热点问题,这样做的缺点就是牺牲了Rowkey的有序性。
.Salt加盐
Salt是将每一个Rowkey加一个前缀,前缀使用一些随机字符,使得数据分散在多个不同的Region,达到Region负载均衡的目的。
比如在一个有4个Region(以[,a)、[a,b)、[b,c)、[c,)为Region起点和结束点)的HBase表中,加Salt前的Rowkey:abc001、abc002、abc003。
分布加上a、b、c前缀,加Salt知乎Rowkey为:a-abc001、b-abc002、c-abc003。可以看到,加盐前的Rowkey默认会在第2个Region中,加盐后的Rowkey数据会分布在3个Region中,理论上处理后的吞吐量是之前的3倍。由于前缀是随机的,读这些数据时需要耗费更多的时间,所以Salt增加了写操作的吞吐量,不过缺点是同时增加了读操作的开销。
.Hash散列或者Mod
用Hash散列来替代随机Salt前缀的好处是能让一个给定的行有相同的前缀,这在分散了Region负载的同时,使读操作也能够推断。确定性Hash(比如md5后取前4位做前缀)能让客户端重建完整的Rowkey,可以使用get操作直接get想要的行。
比如,对abc001、abc002、abc003采用md5散列算法取前4位做前缀,
9bf0-abc001
7006-abc002
95e6-abc003
若以 前4位 字符作为不同分区的起止,上面几个Rowkey数据会分布在3个Region中。实际应用场景是当数据量越来越大的时候,这种设计会使得分区之间更加均衡。
如果Rowkey是数字类型的,也可以考虑mod方法。
 36.HBase的最小存储单位
HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表示不同的HRegion可以分布在不同的HRegionServer上。
HRegion由一个或者多个Store组成,每个Store保存一个Column Family。每个Store又由一个MemStore和0至多个StoreFile组成,每个StoreFile以HFile格式保存在HDFS上,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile。
37.HBase是怎么做预分区的,预分区的作用是什么
HBase默认建表时只有一个Region,这个Region的Rowkey是没有边界的,即没有StartKey和EndKey,在数据写入时,所有数据都会写入这个默认的Region,随着数据量的不断增加,此Region已经不能承受不断增长的数据量,会进行split,分成两个Region。在此过程中,会产生两个问题:
.数据往一个Region上写会有写热点问题
.Region split会消耗宝贵的集群IO资源
基于此,我们可以控制在创建表的时候,创建多个空Region,并确定每个Region的起始和结束Rowkey,这样只要我们的Rowkey设计能够均匀的命中各个Region,就不会存在写热点问题。自然split的几率也会大大降低。当随着数据量的不断增长,该split的还是要进行split。像这样预先创建HBase表分区的方式,称之为预分区。
创建预分区可以通过hbase shell或者Java代码实现。
38.请写出hbase命令(不少于20个)

  1. 为什么HBase查询比较快

HBase查询快,主要原因是由其架构和底层的数据结构决定的,即LSM(Log-Structured Merge Tree)+HTable(region分区)+Cache。
客户端可以直接定位到要查数据所在的HRegion Server服务器,然后直接在服务器的一个Region上查找要匹配的数据,并且这些数据部分是经过Cache缓存的。
HBase会将数据保存到内存中,在内存中的数据是有序的,如果内存空间满了,会刷写到HFile中,而在HFile中保存的内容也是有序的。当数据写入HFile后,内存中的数据会被丢弃。HFile文件为磁盘顺序读取做了优化。
HBase的写入速度快是因为它其实并不是真的立即写入到文件中,而是先写入内存,随后异步刷入HFile。所以在客户端看来,写入速度很快。另外,写入时候将随机写入转换成顺序写,数据写入速度也很稳定。读取速度快是因为它使用了LSM树形结构,而不是B或B+树。磁盘的顺序读取速度很快,但是相比而言,寻找磁道的速度就要慢很多。HBase的存储结构导致它需要磁盘寻道时间在可预测范围内,并且读取与所要查询的Rowkey连续的任意数据的记录都不会引发额外的寻道开销。比如有5个存储文件,那么最多需要5次磁盘寻道就可以。而关系数据库,即时使用索引,也无法确定磁盘寻道次数。而且,HBase读取首先会在缓存(BlockCache)中查找,它采用了LRU(最近最少使用算法),如果缓存中没找到,会从内存中的MemStore中查找,只有这两个地方都找不到时,才会加载HFile中的内容。
40.HBase的导入导出方式
答:
1)导入:bin/hbase org.apache.hadoop.hbase.mapreduce.Driver import 表名 路径
路径:来源
本地路径 file:///path
HDFS hdfs://cluster1/path
2)导出:bin/hbase org.apache.hadoop.hbase.mapreduce.Driver export 表名 路径
路径:目的地
本地路径 file:///path
HDFS hdfs://cluster1/path
41.Region如何预建分区
预建分区的方法很简单,有以下两种
hbase shell
create 't1', 'f1',SPLITS=>['10','20','30']
create 't1','f1',SPLITS_FILE =>'splits.txt'
Java API
o创建一个byte[][] splitKeys = {{1,2,3},{4,5,6}}
oadmin.createTable(tableDesc,splitKeys)
42.HBase和Hive的对比

HBase    Hive

类型 列式数据库 数据仓库
内部机制 数据库引擎 MapReduce
增删改查 都支持 只支持导入和查询
Schema 只需要预先定义列族,不需要具体到列列可以动态修改 需要预先定义表格
应用场景 实时 离线处理
特点 以K-V形式存储 类SQL
43.简述Hbase的六大特点?
(1)、表大:一个表可以有数亿行,上百万列。
(2)、无模式:每行都有一个可排序的主键和任意多的列,列可以根据需要动态增加,同一个表中的不同行的可以有截然不同的列。
(3)、面向列:HBase是面向列的的存储和权限控制,列族独立索引。
(4)、稀疏:空(null)列并不占用空间,表可以设计的非常稀疏。
(5)、数据类型单一:HBase中的数据都是字符串,没有类型。
(6)、数据多版本:每个单元中的数据可以有多个版本,默认情况下版本号自动分配,是单元格插入时的时间戳。
44.Hbase的使用场景是什么?
(1)、半结构化数据和非结构化数据,可以进行动态扩展。
(2)、记录非常的稀疏。
(3)、多版本数据。
(4)、超大数据容量:HBase会自动水平切分扩展,跟Hadoop的无缝集成保证了其数据的可靠性和海量数据分析的高性能。
45.Hbase的查询方式有哪些?
1、全表查询:scan tableName
2、基于rowkey的单行查询:get tableName,'1'
3、基于rowkey的范围扫描:scan tableName, {STARTROW=>'1',STOPROW=>'2'}
4、get和scan方法:
(1)、按指定的rowkey获取唯一一条数据,get方法:分为两种,分别是设置了closestRowBefore和没有设置的rowlock,只要保证行的事务性,即每一个get是以一个row来标记的,一个row中可以有多个family和column。
(2)、按指定的条件获取一批记录,条件查询。1、scan可以通过setCaching和setBatch方法来提高速度;2、scan也可以通过setStartRow和setEndRow来限定范围(左闭右开),3、scan还可以通过setFileter方法来添加过滤器。
ps:setCache和setBatch方法:
setCache方法:这个方法设置即一次RPC请求放回的行数,对于缓存操作来说,如果返回行数太多了,就可能内存溢出,那么这个时候就需要setBatch方法,。
setBatch:设置这个之后客户端可以选择取回的列数,如果一行包括的列数超过了设置的值,那么就可以将这个列分片。例如:如果一行17列,如果batch设置为5的话,就会返回四组,分别是5,5,5,2。、
※:Cache设置了服务器一次返回的行数,而Batch设置了服务器一次返回的列数。
ps:Batch参数决定了一行数据分为几个result,它只针对一行数据,Cache决定了一次RPC返回的result个数。
RPC请求次数 = (行数 * 每行列数) / Min(每行的列数,批量大小) / 扫描器缓存
46.Hbase的结构有哪些?
1、HMaster:
(1)、为所有的RegionServer分配Region。
(2)、负责RegionServer的负载均衡。
(3)、发现失效的RegionServer并重新分配其上的Region。
(4)、HDFS上的垃圾文件。
(5)、处理Schema更新请求(表的创建,删除,修改,列族的增加等)。
2、HRegionServer:
(1)HRegion:
(1)、简介:Table在行的方向上分隔为多个Region,Region是HBase中分布式存储和负载均衡的最小单元,即不同的Region可以分在不同的RegionServer上面,但同一个Region是不会拆分到多个Server上面的。随着数据的增多,某个列族的达到一个阈值就会分成两个新的Region。结构:<表名,startRowkey,创建时间>,由目录表(-ROOT-,.META.)记录该Region的endRowkey
(2)、Store:
(1)简介:每一个Region由一个或则多个Store组成,至少是一个Store,HBase会把访问的数据存放在Store中,即每一个列族建一个Store,如果有多个ColumnFamily,就多多个Store,一个Store由一个MemStore和0或则多个StoreFile组成。HBase通过Store的大小判断是否需要切分Region。
(2)MemStore:它是放在内存中的,保存修改的数据,即key/values。当MemStore的大小达到一定的阈值的时候(默认128M),MemStore会被Flush到文件,即生成一个快照StoreFile,Flush过程由一个线程完成。
(3)StoreFile:StoreFile底层是HFile,HFile是Hadoop的二进制格式文件,
(2)HLog:WAL文件,用来灾难恢复使用,HLog记录数据的所有变更,一旦RegionServer宕机,就从HLog中进行恢复,HLog文件就是一个普通的Hadoop Sequence File,Sequence File记录了写入数据的归属信息,除了Table和Region名字外,还同时包括了Sequence Number和TimeStamp,Sequence File的value是HBase的key/value对象,即对应的HFile中的key/value。
3、Zookeeper:
(1)、保证任何时候集群中只有一个活跃的Master。
(2)、存储所有的Region的寻址入口,知道哪个Region在哪台机器上。
(3)、实时监控RegionServer的状态,将RegionServer的上下线的信息汇报给HMaster,RegionServer不直接向HMaster汇报信息,减轻HMaster的压力,而是通过向ZK发送信息。
(4)、存储HBase的元数据结构(schema),知道集群中有哪些Table,每个Table有哪些Column Family。
47.Hbase中的Compact机制你了解过吗?
1、当HBase中的memstore数据flush到磁盘的时候,就会形成一个storefile,当storefile的数量达到一定程度的时候,就需要将storefile文件进行compaction操作,Compact作用:合并文件、清楚过期,多余版本数据、提高读写效率。
2、compact操作的实现:①minor:Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理,不做任何删除数据、多版本数据的清理工作。②major:Major 操作是对 Region 下的HStore下的所有StoreFile执行合并操作,最终的结果是整理合并出一个文件。
48.描述Hbase中scan和get的功能以及实现的异同.
 
HBase的查询实现只提供两种方式:
1、按指定RowKey 获取唯一一条记录,get方法(org.apache.hadoop.hbase.client.Get)
Get 的方法处理分两种 : 设置了ClosestRowBefore 和没有设置的rowlock .主要是用来保证行的事务性,即每个get 是以一个row 来标记的.一个row中可以有很多family 和column.
2、按指定的条件获取一批记录,scan方法(org.apache.Hadoop.hbase.client.Scan)实现条件查询功能使用的就是scan 方式.
1)scan 可以通过setCaching 与setBatch 方法提高速度(以空间换时间);
2)scan 可以通过setStartRow 与setEndRow 来限定范围([start,end)start 是闭区间,
end 是开区间)。范围越小,性能越高。
3)、scan 可以通过setFilter 方法添加过滤器,这也是分页、多条件查询的基础

49.以 start-hbase.sh 为起点,Hbase 启动的流程是什么?
 
start-hbase.sh 的流程如下:
1.运行 hbase-config.sh
hbase-config.sh的作用:
1>.装载相关配置,如HBASE_HOME目录,conf目录,regionserver机器列表,JAVA_HOME 目录等,它会调用$HBASE_HOME/conf/hbase-env.sh .
2>.解析参数(0.96 版本及以后才可以带唯一参数 autorestart,作用就是重启)
3>.调用 hbase-daemon.sh 来启动 master.
4>.调用 hbase-daemons.sh 来启动 regionserver zookeeper master-backup.
2.hbase-env.sh 的作用:
主要是配置 JVM 及其 GC 参数,还可以配置 log 目录及参数,配置是否需要 hbase 管
理 ZK,配置进程 id 目录等.
3.hbase-daemons.sh 的作用:根据需要启动的进程,
如 zookeeper,则调用 zookeepers.sh
如 regionserver,则调用 regionservers.sh
如 master-backup,则调用 master-backup.sh
4.zookeepers.sh 的作用:
如果 hbase-env.sh 中的 HBASE_MANAGES_ZK"="true",那么通过ZKServerTool这个类解析xml配置文件,获取 ZK 节点列表,然后通过 SSH 向这些节点发送远程命令执行。
5.regionservers.sh 的作用:
与 zookeepers.sh 类似,通过配置文件,获取 regionserver 机器列表,然后 SSH 向这些机器发送远程命令:
6.master-backup.sh 的作用:
通过 backup-masters 这个配置文件,获取 backup-masters 机器列表,然后 SSH 向这些机器发送远程命令。
50.hbase 的存储结构?
Hbase 中的每张表都通过行键 (rowkey) 按照一定的范围被分割成多个子表(HRegion),默认一个 HRegion 超过 256M 就要被分割成两个,由 HRegionServer 管理,管理哪些 HRegion 由 HMaster 分配。 HRegion 存取一个子表时,会创建一个 HRegion 对象,然后对表的每个列族 (Column Family) 创建一个 store 实例, 每个 store 都会有 0个或多个 StoreFile 与之对应,每个 StoreFile 都会对应一个 HFile,HFile 就是实际的存储文件,因此,一个 HRegion 还拥有一个 MemStore 实例。
51.解释下 hbase 实时查询的原理
实时查询,可以认为是从内存中查询,一般响应时间在 1 秒内。HBase 的机制是数据先写入到内存中,当数据量达到一定的量(如 128M),再写入磁盘中。 在内存中,是不进行数据的更新或合并操作的,只增加数据,这使得用户的写操作只要进入内存中就可以立即返回,保证了 HBase I/O 的高性能。(实时查询,即反应根据当前时间的数据,可以认为这些数据始终是在内存的,保证了数据的实时响应。)
52.简述 Hbase filter 的实现原理是什么?结合实际项目经验,写出几个使用filter 的场景?
HBase 为筛选数据提供了一组过滤器,通过这个过滤器可以在 HBase 中的数据的多个维度(行,列,数据版本)上进行对数据的筛选操作,也就是说过滤器最终能够筛选的数据能够细化到具体的一个存储单元格上(由行键, 列名,时间戳定位)。
比较过滤器:1.行过滤器(RowFilter)
      2.列族过滤器(FamilyFilter)
      3.列名过滤器(QualifierFilter)
      4.值过滤器(ValueFilter)
      5.参考列过滤器(DependentColumnFilter)
专用过滤器:1.单列值过滤器(SingleColumnValueFilter)
      2.单列排除过滤器(SingleColumnValueExcludeFilter)
      3.前缀过滤器(PrefixFilter)
      4.分页过滤器(PageFilter)
      5.行健过滤器(KeyOnlyFilter)
      6.首次行健过滤器(FirstKeyOnlyFilter)
      7.包含结束的过滤器(InclusiveStopFilter)
      8.时间戳过滤器(TimestampsFilter)
      9.列计数过滤器(ColumnCountGetFilter)
      10.列分页过滤器(ColumnPaginationFilter)
      11.列前缀过滤器(ColumnPrefixFilter)
      12.随机行过滤器(RadomRowFilter)
附加过滤器:1.跳转过滤器(SkipFilter)
      2.全匹配过滤器(WhileMatchFilter)
  hbase的filter是通过 scan 设置的,所以是基于 scan 的查询结果进行过滤。过滤器的类型很多,但是可以分为两大类——比较过滤器,专用过滤器。过滤器的作用是在服务端判断数据是否满足条件,然后只将满足条件的数据返回给客户端。如在进行订单开发的时候,我们使用 rowkeyfilter 过滤出某个用户的所有订单。
53.导致Hbase挂掉的场景有哪些?
导致Hbase挂掉的场景
HMaster
HMaster会出现异常(执行abort())停止的场景如下:
1.zk异常导致的master停止服务是最常见的场景,涉及操作包含但不限于以下:
a)Zk链接超时,超时时间通过zookeeper.session.timeout配置,默认为3分钟, 如果fail.fast.expired.active.master配置的值为false(默认为false),则不会立即abort,而是会尝试恢复zk的过期session;
b)在打开region后,需要从zk中删除opened节点,如果zk有该节点,但是删除失败;
c)在split region过程中,从zk删除split节点时;
d)Master节点改变时;
e)从zk中创建unassigned节点时;
f)在下线disabled的regoin时,从zk中删除disabled的region如果发生zk异常;
g)还有很多操作zk的节点时如果出现异常。
2.在assign时,如果设置region为offlined状态,但是region之前的状态不是closed或者offlined;
3.在assign时,如果无法从.META.表中读取region信息;
4.把新的hbase集群加入到正在运行的hbase集群时,如果zk的/hbase/unassigned节点没有数据;
5.使用线程池批量分配region时,如果出现未被捕获的异常,实现方式如下:
6.在启动master的服务线程时,出现了异常;
7.在hdfs中检查hbase日志路径时,发现了dead的server时,需从hdfs中读出log,如果出现io异常需要检查hdfs文件系统,如果fsOk状态为true,但是通过FSUtils工具类进行检查时出现io异常;
8.在校验并且分配-ROOT-的region时,如果zk异常,或者其它异常(其它异常会重试10次),比如:“-ROOT- is onlined on the dead server”。

HRegionServer
HRegionServer会出现异常停止(执行abort())服务的场景如下:
1.在读写hdfs时如果出现IOException异常,此时会发起hdfs的文件系统检查(checkFileSystem)1.
2.Regionserver的服务线程出现了未捕获异常;
3.在启动HRegionServer时出现异常;
4.在进行HLog回滚时,出现异常;
5.在flush memstore时,如果持久化失败,会重启RS,在重启中把hlog的内容重新加载到memstore;
6.出现zk异常,包括但不限于以下场景:
a)Zk链接超时,超时时间通过zookeeper.session.timeout配置,默认为3分钟,与master不同,如果zk操作不会重试;
b)启动HRegionServer时出现KeeperException异常;
c)在进行split操作时,如果出现异常会进行回滚操作,在回滚过程中需要从zk中删除region的spliting状态,如果删除时出现KeeperException或者回滚的其它操作出现异常;
d)在打开region时,出现了KeeperException异常;
e)在进行hbase集群复制时,很多与zk交互的操作出现KeeperException异常时均会导致abort;
7.在close region时,如果出现异常,比如:不能成功的flush memstore;
8.Flush memstore时,如果HLog发现该region已经在flush则会强制终止JVM,采用的是Runtime.getRuntime().halt(1)方法,该方法不会执行正常退出的关闭钩子,从而不会flush RS的所有region,也不会迁移region,只有等待ZK的session超时后master才会发现该RS不可用,做迁移工作。

总结
Hbase挂掉的可能性有很多,主要由zk或者hdfs的问题导致,因此zk、hdfs的可用对于hbase极其重要,关于zk:
1.zk如果停止了服务则在很多时候会导致master、rs挂掉,hbase集群基本上就失去了服务的能力,因此zk一定要是稳定可靠的,当client已经于rs建立了链接,这时zk挂掉,如果不进行split等小数与zk交互失败会导致触发rs的abort()的操作时rs还是可以提供服务的;
2.如果rs/master进行了长时间的gc或者改动了服务器时间,导致出现zk的session超时会导致rs/master停止服务,目前已经出现了2次因为服务器时间变化导致hbase停止服务的事故;
3.别轻易人为改变zk的hbase节点数据,master/rs在进行很多操作时会比较依赖zk的数据,如果发现不符合预期可能会导致master/rs停止服务,尤其是master。
Master通过ZK知道RS是否可用,一般情况下RS在停止服务时均会正常退出,在正常退出时会从ZK中删除/hbase/rs/$regionserver的节点,Master会监听该节点的被删除,从而较快的(速度取决于所有region关闭时间)对该RS负责的region进行重新分配,如果是强制退出,比如 kill -9或者出现HRegionServer挂掉的第8条时则只有等待ZK的session超时时才会删除RS在ZK的节点(RS在ZK中添加节点时采用的是CreateMode.EPHEMERAL模式,该模式创建的节点会在session关闭时自动删除),那时Master才会进行重新assign。
Kill RS的进程也是正常退出(不能使用kill -9强制退出),RS使用Runtime的addShutdownHook方法注册了jvm关闭钩子,在关闭钩子中会执行RS的退出逻辑,实际上hbase-daemon.sh的停止RS就是采用kill。

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
&nbsp; 相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情:&nbsp;https://cn.aliyun.com/product/hbase &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
7月前
|
存储 分布式计算 大数据
HBase分布式数据库关键技术与实战:面试经验与必备知识点解析
【4月更文挑战第9天】本文深入剖析了HBase的核心技术,包括数据模型、分布式架构、访问模式和一致性保证,并探讨了其实战应用,如大规模数据存储、实时数据分析及与Hadoop、Spark集成。同时,分享了面试经验,对比了HBase与其他数据库的差异,提出了应对挑战的解决方案,展望了HBase的未来趋势。通过Java API代码示例,帮助读者巩固理解。全面了解和掌握HBase,能为面试和实际工作中的大数据处理提供坚实基础。
418 3
|
7月前
|
存储 SQL 分布式计算
HBase 相关面试题
HBase 是一种基于 Hadoop 的分布式 NoSQL 数据库,它是 Google 的Bigtable 的开源实现。
84 7
|
存储 负载均衡 容灾
大数据知识面试题-Hbase
如果 Rowkey 是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将 Rowkey 的高位作为散列字段,由程序循环生成,低位放时间字段,这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段,首字段直接是时间信息将产生所有 新数据都在一个 RegionServer 上堆积的热点现象,这样在做数据检索的时候负载将会集中 在个别 RegionServer,降低查询效率。
大数据知识面试题-Hbase
|
7月前
|
缓存 大数据 分布式数据库
大数据开发岗面试复习30天冲刺 - 日积月累,每日五题【Day11】——Hbase5
大数据开发岗面试复习30天冲刺 - 日积月累,每日五题【Day11】——Hbase5
53 0
|
存储 NoSQL 分布式数据库
HBase面试连环炮
HBase面试连环炮
56 0
|
存储 监控 负载均衡
JAVA面试——Hbase(二)
JAVA面试——Hbase
118 0
JAVA面试——Hbase(二)
|
存储 分布式计算 关系型数据库
JAVA面试——Hbase(一)
JAVA面试——Hbase
173 0
JAVA面试——Hbase(一)
|
存储 缓存 算法
【大数据面试题】(四)HBase 相关面试题总结2
【大数据面试题】(四)HBase 相关面试题总结2
168 0
【大数据面试题】(四)HBase 相关面试题总结2
|
SQL 存储 分布式计算
【大数据面试题】(四)HBase 相关面试题总结1
【大数据面试题】(四)HBase 相关面试题总结1
191 0
【大数据面试题】(四)HBase 相关面试题总结1
|
存储 缓存 分布式计算
大数据面试--HBASE
大数据面试,HBASE,大数据
184 0