hbase复习题、面试题_梧桐林._hbase期末考试题

网络投稿 02-07 3178

1. HBASE架构

我们知道HBase依赖HDFS也依赖Zookeeper，那么首先出来的应该是HDFS，这是他底层的存储地，随便画几个DataNode无所谓，然后HBase还依赖Zookeeper，因此我们在启动HBase之前需要先启动它们。那接下轮到HBase启动了，HBase需要启动两大进程HMaster和HRegionServer，这个Master工作太累了，它需要把某些工作交给Zookeeper，后面在说具体都交给些什么任务。Master主要管理DDL相关的操作，操作表，操作命名空间，HRegionServer则是管理DML数据层面的操作，涉及数据的增删改查，同时Master也会管理HRegionServer，因为我的Region到底是给哪个HRegionServer维护由Master说的算，万一某个HRegionServer挂掉了，也需要Master重新分配给其它人来维护。 ?? 在谈HRegionServer之前还有一个HLog，这个又叫预写入日志Write-Ahead logfile在/HBase/wal文件夹中，相当于HDFS的edits文件，由于数据一开始并没有落盘存在内存中，若内存崩掉数据就会丢失，HLog会实时记录操作。接下来就是一堆HRegion，一个表对应一个或者多个HRegion，HRegion里面就是列族，也就是Store，它们的存储是隔离的，就像上面看的info1,info2，对于HBase来说它的列就是数据，在插入数据之前是没有列这个概念的，随着插入数据而存在。 ?? 下面来看看Mem Store，主要是做刷写操作（flush），上面我们做个一个操作证明HBase是按照Row Key的字典序排列的，因此数据首先存到Mem Store中进行排序，等待刷写时机将其写入磁盘中这就是HFile，因此将来会有很多个文件，当触发全局刷写条件（即HRegionServer的刷写条件）时可能有的Mem Store只有几k，就会产生很多小文件，这时候HBase就会做合并（compact）操作，当合并的文件过大又会做拆分（split）操作。 ?? 关于Store File和HFile的关系：HFile和.txt，.csv等同等级，是一种存储格式，Store File只是我们对刷写下来的文件的一种命名，这个文件以HFile格式存储，虽然Store File是HBase的一个组件，但它真正活跃在DataNode上，作用在磁盘上，然后就是一系列的HDFS读写操作。 ?? 那么Zookeeper到底为HMaster做了什么？如果是DDL那没话说客户端需要请求HMaster，若进行DML操作，客户端会请求Zookeeper然后直接到HRegionServer不经过HMaster，即使HMaster挂了，也可以进行读写操作，因此Zookeeper作为HBase接待客户端的第一管家，分担HBase的DML操作。

Row Key：行键，系统自带，在一张表中必须是唯一的，类似MySQL的主键【字典序】列：类似MySQL的字段列族：将很多列分出来不同的列族，影响最终的存储，不同的列族存储在不同的文件夹中 Region：横向切片 store：存储，真正存储在HDFS的数据

2. 写流程

1. client访问zookeeper，从中获取hbase:meta表所在的HResgionServer 2. 访问对应的HResgionServer，获取hbase:meta写入缓存并从中去读预操作表在哪个HResgionServer哪个Region中 3. 与对应的目标节点通讯 4. 将操作追加到wal中 5. 将数据写入memstore中，并在其中进行排序（此时数据和wal全在内存里） 6. 同步wal，返回ack，client写操作到此结束 ※若同步失败有回滚操作，将删除内存中写入的数据 7. 等待memstore刷写时机，将数据刷写到HFile 8. 如果 Memstore 达到阈值，会把 Memstore 中的数据 flush 到 Storefile 中。 9. 当 Storefile 越来越多，会触发 Compact 合并操作，把过多的 Storefile 合并成一个大的 Storefile。 10. 当 Storefile 越来越大，Region 也会越来越大，达到阈值后，会触发 Split 操作，将 Region 一分为二。

3. FLUSH 3.1 HRegionServer级别的flush

内存在一定条件下进行刷写操作，那么我们想到的条件有哪些？无非就是时间和大小。注意不同的store对应着不同的列族，即最终存储再不同的文件夹下面（隔离存储，可以提高效率），而之后的合并操作也只是对一个文件夹下的Store File进行合并。 ?当一个HRegionServer的全部memstore总量达到了 jvm默认堆大小的40% 时，触发HRegionServer级别的flush刷写，阻塞客户端的读写，HBase认为达到了这个级别很容易引起内存崩溃，因此它会暂停客户端的所有操作直到刷写全部完成。 ?默认值为hbase.regionserver.global.memstore.size的95%，当一个HRegionServer中memstore总量达到95% HBase就开始读写，但是不会阻塞客户端读写操作，和hbase.regionserver.global.memstore.size搭配使用的意思就是，当达到hbase.regionserver.global.memstore.size.lower.limit时开始刷写，但若客户端的写操作速度大于刷写操作导致memstore总量持续增加达到了hbase.regionserver.global.memstore.size规定的大小，这就意味着客户端写数据太快，必须暂停一下等待flush完成；若客户端写操作速度小于刷写操作时，memstore总量下降直到低于hbase.regionserver.global.memstore.size.lower.limit刷写操作结束。 ?一个小时自动刷写，若设置为0则关闭此功能，是一种“优先级略低的刷写”，这是什么意思呢？比如当客户端持续的进行写操作，但是写的数据特别小一个小时都没有达到默认堆的40%的95%，是不会触发刷写操作。这一个小时是指当前HRegionServer即这个节点内存最后一次编辑时间，对应的场景是长时间不操作，即这一个小时都没有新的数据进来那就进行刷写操作

3.2 HRegion级别的flush

当单个memstore达到128M时HRegion进行刷写操作，将其写入Store File中还有一个老版本的配置hbase.regionserver.max.logs，即控制wal的大小，防止内存特别大，那么达到40%才进行刷写，那得刷多少数据呀。可以说wal和memstore是对等的。但目前版本这个配置不对用户开放，可以在HBase官网文档中找到。

4. 读流程

?和写流程类似，首先client向Zookeeper拿到meta表所在的HRegionServer，去对应的节点读取meta表并返回将要操作的表所在的HRegionServer并且写入缓存以便下次使用，从对应的节点去读取文件，在读流程中会有一个Block Cache将最新读取的内容写入缓存中，使用的是是LRU算法，因此读取数据就面临着三个选择Block Cache（内存）、MenStore（内存）、StoreFile（磁盘），一般来说能从内存读绝不从磁盘读，例如先在内存找没有则去磁盘找，并且写入缓存中，但对于HBase来说不是这样的，这样做将会导致非常严重的后果。 ?真正的操作是，同时读内存和磁盘并在Block Cache中进行比较，返回时间戳大的数据，同时存到缓存中方便下次读取。那么Block Cache的作用是什么？当Block Cache有的那个文件将不再扫磁盘的那个文件，注意是不扫缓存的那个文件，磁盘该扫还得扫，因此无论如何都要扫磁盘，当数据量大的时候甚至做全盘扫描，这就对应着前面说的那句话 HBase的写比读快 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. 将合并后的最终结果返回给客户端。

5. Compaction

总结HBase的刷写逻辑发现，这种机制的刷写会产生很多小文件，因为最小的刷写都是HRegion级别的，一个HRegion会存在很多个Store对应着很多memstore存在刷写时部分memstore数据量少的情况，而HDFS是不擅长管理小文件的，因此HBase必须得有处理小文件的机制，即compact。HBase合表的机制分为两种分别是Minor Compaction和Major Compaction,它们的区别在于Minor Compaction属于小合并，将相邻的几个小文件合并成稍微大一点的文件（相邻的的意思就是在一个store中，因为不同的store是分文件夹存储，即仅合并一个文件夹下的），而Major Compaction属于大合并，不管文件大小全部合成一个文件。它们最大的区别是Minor Compaction合并不会删除数据，即一些被打了Delete标记或旧VERSIONS文件是不会删除的，而Major Compaction合并文件时会对其进行删除操作，且官网用的词是rewrite重写，意思就是读到内存修改再写回磁盘，因此Major Compaction非常消耗资源。

flush也能删除数据，但和合表操作删除不太一样。可以做这样的实验，连续put两次数据让后一条数据覆盖前一条，然后手动flush表，此时再scan ‘stu’,{RAW=>true,VERSIONS=>10}，会发现原先的数据被删除了，但若你put一次flush一次就不会被删除，因此flush会根据设定的VERSIONS值删除内存中的数据，已经刷写到磁盘的就不归flush管。

6. split

当持续进行合表操作时，表会越来越大，大到一定程度就要进行切分，那么切分也有它的时机。任何列族超过这个大小（10G）对于老版本来说会将其一分为二，但是新版本（0.94版本之后）会有一个公式，当某个列族下所有文件超过min(hbase.hregion.max.filesize,hbase.hregion.memstore.flush.sizeR^2) 即min(10G,128MR^2)其中R为Region数，切分是按照Row Key。