5. HBase必知必会之理论进阶篇

1.1 集群搭建以及规模预测

1.1.1 HBase集群搭建

HBase结构图：

进程及作用说明

• QuorumPeerMain ：zookeeper启动进程
• DFSZKFailoverController：故障转移控制器，ha通信进程，active，standby切换
• JournalNode：namenode间共享数据
• NameNode：管理整个文件系统的命名空间，维护整个文件系统树及其内部的文件和目录，这些信 息以命名空间镜像和编辑日志方式持久化到磁盘上
• DataNode：存储和检索数据块，定期向NameNode发送本节点上所存储的块列表
• ResourceManager：集群中所有资源的统一管理和分配以及调度
• NodeManager：ResourceManager在每台机器上的代理，负责容器管理，并监控它们的资源使用情 况，以及向ResourceManager/Scheduler提供资源使用报告
• HMaster：负责Table表和HRegion的管理工作
• HRegionServer：负责table数据的实际读写,管理Region

1.1.2 HBase集群规划

业务类型考虑：

• 硬盘容量敏感型业务：这类业务对读写延迟以及吞吐量都没有很大的要求，唯一的需要就是硬盘容量。
  • 比 如大多数离线读写分析业务，上层应用一般每隔一段时间批量写入大量数据，然后读取也是定期批量读取 大量数据。
  • 特点：离线写、离线读，需求硬盘容量
• 带宽敏感型业务：这类业务大多数写入吞吐量很大，但对读取吞吐量没有什么要求。
  • 比如日志实时存储业 务，上层应用通过kafka将海量日志实时传输过来，要求能够实时写入，而读取场景一般是离线分析或者
    在上次业务遇到异常的时候对日志进行检索。
  • 特点：在线写、离线读，需求带宽
• IO敏感型业务：相比前面两类业务来说，IO敏感型业务一般都是较为核心的业务。
  • 这类业务对读写延迟 要求较高，尤其对于读取延迟通常在100ms以内，部分业务可能要求更高。
  • 比如在线消息存储系统、历史订单系统、实时推荐系统等。
  • 特点：在（离）线写、在线读，需求内存、高IOPS介质
  • （而对于CPU资源，HBase本身就是CPU敏感型系统，主要用于数据块的压缩/解压缩，所有业务都对CPU有 共同的需求）

一个集群想要资源利用率最大化，一个思路就是各个业务之间‘扬长避短’，合理搭配，各取所需。

实际上就是上述几种类型的业务能够混合分布，建议不要将同一种类型的业务太多分布在同一个集群。

因此一个集 群理论上资源利用率比较高效的配置为：硬盘敏感型业务 ＋ 带宽敏感型业务 ＋ IO敏感型业务 （目前线上 基本是io敏感性）

集群容量规划：

• 硬盘容量纬度下Region个数：Disk Size / (RegionSize ＊ReplicationFactor)
• Java Heap纬度下Region个数：Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 ) Disk Size / Java Heap = RegionSize / MemstoreSize* ReplicationFactor * HeapFractionForMemstore * 2

对应解释说明：

• RegionSize：对应参数为hbase.hregion.max.filesize
• MemstoreSize：对应参数hbase.hregion.memstore.flush.size
• ReplicationFactor：副本个数dfs.replication
• HeapFractionForMemstore：对应参数hbase.regionserver.global.memstore.lowerLimit（默认0.4）
  • 参数2：为一般memstore内存一般使用量不到一半，这个值是估算
  • 官方文档给出的一个推荐范围在20～200之间，而单个Region大小控制在10G~30G，比较符合实际情况
    (sub-region概念，但是没有被采用，所以最好还是保持官网说法）

• HBase最佳实践－集群规划

1.2 HBase重要的概念

1.2.1 snapshot

snapshot的不同用法可以实现很多功能:

1. 全量/增量备份：任何数据库都需要有备份的功能来实现数据的高可靠性，snapshot可以非常方便的实现表 的在线备份功能，并且对在线业务请求影响非常小。使用备份数据，用户可以在异常发生的情况下快速回滚到指定快照点。增量备份会在全量备份的基础上使用binlog进行周期性的增量备份。 •
   • 使用场景一：通常情况下，对重要的业务数据，建议至少每天执行一次snapshot来保存数据的快照记录，并且定期清理过期快照，这样如果业务发生重要错误需要回滚的话是可以回滚到之前的一个快照点的。
   • 使用场景二：如果要对集群做重大的升级的话，建议升级前对重要的表执行一次snapshot，一旦升级有任 何异常可以快速回滚到升级前。
2. 数据迁移：可以使用ExportSnapshot功能将快照导出到另一个集群，实现数据的迁移
   • 使用场景一：机房在线迁移，通常情况是数据在A机房，因为A机房机位不够或者机架不够需要将整个集群.迁移到另一个容量更大的B集群，而且在迁移过程中不能停服。
     • 基本迁移思路是先使用snapshot在B集群恢复出一个全量数据，再使用replication技术增量复制A集群的更新数据，等待两个集群数据一致之后将客户端请 求重定向到B机房。

• 使用场景二：使用snapshot将表数据导出到HDFS，再使用Hive\Spark等进行离线OLAP分析，比如审计报表、 月度报表等

snapshot是很多存储系统和数据库系统都支持的功能。

一个snapshot是一个全部文件系统、或者某个目录在某一时刻的镜像

结构层面的分布式原子操作：

1. prepare阶段：HMaster在zookeeper创建一个’/acquired-snapshotname’节点，并在此节点上写入snapshot相
   关信息（snapshot表信息）。所有regionserver监测到这个节点之后，根据/acquired-snapshotname节点携带的
   snapshot表信息查看当前regionserver上是否存在目标表，如果不存在，就忽略该命令。如果存在，遍历目标
   表中的所有region，分别针对每个region执行snapshot操作，注意此处snapshot操作的结果并没有写入最终文
   件夹，而是写入临时文件夹/hbase/.hbase-snapshot/.tmp。regionserver执行完成之后会在/acquired-
   snapshotname节点下新建一个子节点/acquired-snapshotname/nodex，表示nodex节点完成了该regionserver上
   所有相关region的snapshot准备工作。
2. commit阶段：一旦所有regionserver都完成了snapshot的prepared工作，即都在/acquired-snapshotname节点
   下新建了对应子节点，hmaster就认为snapshot的准备工作完全完成。master会新建一个新的节点/reached-
   snapshotname，表示发送一个commit命令给参与的regionserver。所有regionserver监测到/reached-
   snapshotname节点之后，执行snapshot commit操作，commit操作非常简单，只需要将prepare阶段生成的结
   果从临时文件夹移动到最终文件夹即可。执行完成之后在/reached-snapshotname节点下新建子节点/reached-
   snapshotname/nodex，表示节点nodex完成snapshot工作。
3. abort阶段：如果在一定时间内/acquired-snapshotname节点个数没有满足条件（还有regionserver的准备工 作没有完成），hmaster认为snapshot的准备工作超时。hmaster会新建另一种新的节点/abort-snapshotname，
   所有regionserver监听到这个命令之后会清理snapshot在临时文件夹中生成的结果。
   • 博客地址：HBase原理 – 分布式系统中snapshot是怎么玩的？

1.2.2 region 切分

常用region切分策略

• ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略，即一个region中最大store的大小大于设置阈值之后才会触
  发切分。但是在生产线上这种切分策略却有相当大的弊端：切分策略对于大表和小表没有明显的区分。阈值
  （hbase.hregion.max.filesize）设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，这
  对业务来说并不是什么好事。如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的
  管理、资源使用、failover来说都不是一件好事。
• IncreasingToUpperBoundRegionSplitPolicy： 0.94版本~2.0版本默认切分策略（线上用的就是这种）。不像 ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前
  regionserver上的region个数有关系 ：(#regions) * (#regions) * (#regions) *
  memstore flush size * 2，当然阈值并不
  会无限增大，最大值为用户设置的MaxRegionFileSize。这种切分策略很好的弥补了ConstantSizeRegionSplitPolicy的短
  板，能够自适应大表和小表。而且在大集群条件下对于很多大表来说表现很优秀，但并不完美，这种策略下很多小表会在
  大集群中产生大量小region，分散在整个集群中。而且在发生region迁移时也可能会触发region分裂。
• SteppingSplitPolicy: 2.0版本默认切分策略。这种切分策略的切分阈值又发生了变化，相比 IncreasingToUpperBoundRegionSplitPolicy简单了一些，依然和待分裂region所属表在当前regionserver上的region个
  数有关系，如果region个数等于1，切分阈值为flush size *
  2，否则为MaxRegionFileSize。这种切分策略对于大集群中
  的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不会再产生大量的小region，而是适可而
  止。
  • 还有一些其他分裂策略，比如使用DisableSplitPolicy:可以禁止region发生分裂；
  • 而 KeyPrefixRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy对于切分策略依然依据默认切分策略，
  • 但对于切分点有自己的看法，比如KeyPrefixRegionSplitPolicy要求必须让相同的PrefixKey待在一个region
    中。在用法上，一般情况下使用默认切分策略即可，也可以在cf级别设置region切分策略，命令为： create ’table’, {NAME
    => ‘cf’, SPLIT_POLICY => ‘org.apache.hadoop.hbase.regionserver. ConstantSizeRegionSplitPolicy’}
• 切分点：整个region中最大store中的最大文件中最中心的一个block的首个rowkey，另外，HBase还规定， 如果定位到的rowkey是整个文件的首个rowkey或者最后一个rowkey的话，就认为没有切分点（例如：最常
  见的就是一个文件只有一个block，这种情况就没有切分点）。
• 切分核心流程：HBase将整个切分过程包装成了一个事务，意图能够保证切分事务的原子性。整个分裂事务 过程分为三个阶段：prepare – execute – (rollback)

• 英文官网:Apache HBase Region Splitting and Merging
• 中文对应:HBase原理 – 所有Region切分的细节都在这里了

1.2.3 RIT

RIT:Region-In-Transition，region状态变迁

unassign操作region变迁过程：

大部分RIT状态是短暂的，但是特别极端的场景下会有一些异常导致部分region处于永久的RIT状态，从而引起表
读写阻塞甚至整个集群阻塞。

永久RIT总结：

1. 永久性掉入RIT状态其实出现的概率并不高，都是在一些极端情况下才会出现。绝大部分RIT状态都是暂时的。
2. 一旦掉入永久性RIT状态，说明一定有根本性的问题原因，只有定位出这些问题才能彻底解决问题
3. 如果Region长时间处于PENDING_CLOSE或者CLOSING状态，一般是因为RegionServer在关闭Region的时候遇到了
   长时间Compaction任务或Flush任务，所以如果Region在做类似于Major_Compact的操作时尽量不要执行unassign
   操作，比如move操作、disable操作等；而如果Region长时间处于FAILED_OPEN状态，一般是因为HDFS文件出现异
   常所致，可以通过RegionServer日志以及hbck定位出来

• HBase运维实践－聊聊RIT的那点事

1.2.4 HBase读优化

1.2.4.1 客户端优化

大scan场景下（针对几万到几十万数据，例如mapreduce）将scan缓存从100增大到500或者1000，用以减少RPC次数

• 批量get接口，减少客户端到RegionServer之间的RPC连接数，提高读取性能
• 指定列簇以及列进行查找，如果一个表有多个列族（不同存储目录），只是根据Rowkey而不指 定列族进行检索的话不同列族的数据需要独立进行检索，性能必然会比指定列族的查询差很多， 很多情况下甚至会有2倍～3倍的性能损失。
• 离线批量读取请求设置禁用缓存，scan.setBlockCache(false)，避免将业务热点数据挤出，从而 产生读延迟毛刺（mapreduce）

1.2.4.2 服务端优化

• 读请求是否均衡：避免读请求大量落入一台或几台regionserver，对rowkey进行哈希，建表时进 行预分区，如果hash后仍然后热点数据，短期将热点region拆分，长期重新设计rowkey
• 读多写少可以将读缓存bloackCache设置占比调大，hbase2.0针对BucketCache策略的offheap改造， 读性能提升2-4倍，同时gc更好
• hfile文件是否太多，文件越多io次数越多，读延迟越高，控制minor compaction线程数，以及做 合并的hfile文件个数限制等，在业务低峰期手动做major compaction等
• 建表设置bloomfilter，对只用rowkey做随机读取设置值为row，对rowkey+cf随机查询设置为 rowcol
• 针对scan查询业务，将BLOCKSIZE调大
• 操作系统级别：
  • 关闭THP大页：echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag
  • 较少内存交换的使用：vm.swappiness=0
  • vm.min_free_kbytes 最少1GB (在超过8GB的内存服务器)
  • vm.zone_reclaim_mode=0 (可以取值0/1/3/4，其中0表示在local内存不够用的情况下可以去其他的内存区域分配内存；
  • 1表示在local内存不够用的情况下本地先回收再分配； 3表示本地回收尽可能先回收文件缓存对象；
  • 4表示本地回收优先使用swap回收匿名内存cpu架构层面减少swap交换）

HBase最佳实践-用好你的操作系统

1.2.4.3 hdfs 优化

• 数据本地率太低，读取数据产生大量跨网络io请求，从而导致延迟， 优化建议：

  • 避免region迁移（手动做region迁移），
  • 关闭自动balance，regionserver宕机及时启动并迁回迁移的region，
  • 业务低峰期执行major compact提升本地率

• Short-Circuit Local Read功能开启：

  • 前HDFS读取数据都需要经过DataNode，客户端会向DataNode发送读取数据的请求，
  • DataNode接受到请求之后从硬盘中将文件读出来，再通过TPC发送给客户端。
  • Short Circuit策略允许客户端绕过DataNode直接读取本地数据，
  • 详情见：HBase查询优化之Short-Circuit Local Reads

• Hedged Read功能是否开启：针对磁盘问题或者网络问题引起的短时间本地读取失败。

  • 社区开发 者提出了补偿重试机制 – Hedged Read。
  • 该机制基本工作原理为：
  • 客户端发起一个本地读，一旦一段时间之后还没有返回
  • 客户端将会向其他DataNode发送相同数据的请求。
  • 哪一个请求先返回， 另一个就会被丢弃

1.2.5 HBase写优化

1.2.5.1 客户端优化

• 是否写wal：通常情况下写缓存延迟很低，因此提升写性能就只能从WAL入手。
  • WAL机制一方面是 为了确保数据即使写入缓存丢失也可以恢复，另一方面是为了集群之间异步复制。
  • 部分业务可能并不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，
  • 比如某些推荐业务，这种场景下可以考虑关闭WAL写入，写入吞吐量可以提升2x~3x（对于使用Increment操作的业务，WAL 可以设置关闭，也可以设置异步写入，方法同Put类似。
  • 相信大多数Increment操作业务对WAL可能都不是那么敏感）
• 批量put操作：
  • 批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能
• 异步批量提交：setAutoFlush(false)，当客户端缓存达到阈值（默认2M）之后批量提交给 RegionServer。
  • 需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失

1.2.5.2 服务端优化

• region个数
• region写入是否均衡：体现在rowkey设计以及预分区策略
• keyvalue是否太大：KeyValue太大对写入性能的影响还是比较大的，会导致延迟时间增长，tps降低，
  • 可以考虑hbase2.0版本的MOB特性，该版本对此进行了优化

1.2.6 compaction

• compaction概念：用户数据写入先写WAL，再写缓存，满足一定条件后缓存数据会执行flush操作 真正落盘，形成一个数据文件HFile。

  • 随着数据写入不断增多，flush次数也会不断增多，进而HFile数据文件就会越来越多。
  • 然而，太多数据文件会导致数据查询IO次数增多，因此HBase尝试着不断
    对这些文件进行合并，这个合并过程称为Compaction

• MinorCompaction ：指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个 过程中不会处理已经Deleted或Expired的Cell。

  • 一次Minor Compaction的结果是更少并且更大的 StoreFile。

• MajorCompaction：指将所有的StoreFile合并成一个StoreFile，

  • 这个过程还会清理三类无意义数据： 被删除的数据、TTL过期数据、版本号超过设定版本号的数据。
  • 另外，一般情况下，MajorCompaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。
  • 因 此线上业务都会将关闭自动触发MajorCompaction功能，改为手动在业务低峰期触发。

1.2.6.1 compaction 过程

触发时机：

1. Memstore Flush、
2. 后台线程周期性检查、
3. 手动触发

1. Memstore Flush:
   • 应该说compaction操作的源头就来自flush操作，memstore flush会产生HFile文件， 文件越来越多就需要compact。
   • 因此在每次执行完Flush操作之后，都会对当前Store中的文件数进行判断，一旦文件数大于合并限制，就会触发compaction。
   • 需要说明的是，compaction都是以Store为单位进行的，
   • 而在Flush触发条件下，整个Region的所有Store都会执行compact，所以会在短时间内执行多次compaction
2. 后台线程周期性检查：
   • 后台线程CompactionChecker定期触发检查是否需要执行compaction，
   • 检 查周期为：hbase.server.thread.wakefrequency（10000）*hbase.server.compactchecker.interval.multiplier（1000）。
   • 和flush不同的是，该线程优先检查文件数是否大于限制，一旦大于就会触发compaction。
   • 如果不满足，它会接着检查是否满足majorcompaction条件，
   • 简单来说，如果当前store中hfile的最早更新时间早于某个值mcTime，就会触发 majorcompaction，
   • HBase预想通过这种机制定期删除过期数据。上文mcTime是一个浮动值，浮动 区间默认为［7-70.2，7+70.2］，
   • 其中7为hbase.hregion.majorcompaction，0.2为hbase.hregion.majorcompaction.jitter，
   • 可见默认在7天左右就会执行一次majorcompaction。
   • 用户如 果想禁用majorcompaction，只需要将参数hbase.hregion.majorcompaction设为0
3. 手动触发：
   • 一般来讲，手动触发compaction通常是为了执行major compaction，原因有三，
     • 其一 是因为很多业务担心自动major compaction影响读写性能，因此会选择低峰期手动触发；
     • 其二也有可能是用户在执行完alter操作之后希望立刻生效，执行手动触发major compaction；
     • 其三是HBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数据；
   • 无论哪种触发动机，一旦手动触发，HBase会不做很多自动化检查，直接执行合并

1.2.7 gc优化

优化目的：减少fullgc次数，缩短fullgc时间

-Xmx24g 
-Xms24g 
-Xmn1g 
-Xss256k 
-XX:MaxPermSize=128m 
-XX:SurvivorRatio=2 
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+CMSParallelRemarkEnabled 
-XX:MaxTenuringThreshold=15 
-XX:+UseCMSCompactAtFullCollection 
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75 
-XX:-DisableExplicitGC
1
2
3
4
5
6
7
8
9
10
11
12
13
14

1.2.8 hbck

新版本的 hbck 可以修复各种错误，修复选项是：

（1）-fix，向下兼容用，被-fixAssignments替代
（2）-fixAssignments，用于修复region assignments错误
（3）-fixMeta，用于修复meta表的问题，前提是HDFS上面的region info信息有并且正确。
（4）-fixHdfsHoles，修复region holes（空洞，某个区间没有region）问题
（5）-fixHdfsOrphans，修复Orphan region（hdfs上面没有.regioninfo的region）
（6）-fixHdfsOverlaps，修复region overlaps（区间重叠）问题
（7）-fixVersionFile，修复缺失hbase.version文件的问题 （8）-maxMerge
（n默认是5），当region有重叠是，需要合并region，一次合并的region数最大不超过这个值。
（9）-sidelineBigOverlaps ，当修复region
overlaps问题时，允许跟其他region重叠次数最多的一些region不参与（修复后，可以 把没有参与的数据通过bulk
load加载到相应的region）
（10）-maxOverlapsToSideline （n默认是2），当修复region
overlaps问题时，一组里最多允许多少个region不参与 由于选项较多，所以有两个简写的选项
（11） -repair，相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile -sidelineBigOverlaps
（12）-repairHoles，相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans

hbase 的几个修复方法

1.2.9 RegionServer宕机数据恢复

正常情况下的hlog生命周期：

• hlog构建：
  • 生成Hlog格式文件，包括HLogKey，WALEdit，
  • 其中HLogKey由sequenceid、writetime、clusterid、regionname以及tablename组成。
  • 其中sequenceid是日志写入时分配给数据的一个自增数字，
  • 先写入的日志数据sequenceid小，后写入的sequenceid大
• HLog滚动：HBase后台启动了一个线程会每隔一段时间进行日志滚动（默认1小时）
• HLog失效：一旦数据从Memstore中落盘，对应的日志就可以被删除，
  • 因此一个文件所有数据失效，只 需要看该文件中最大sequenceid对应的数据是否已经落盘就可以，
  • HBase会在每次执行flush的时候纪录
  • 对应的最大的sequenceid，如果前者小于后者，则可以认为该日志文件失效。
  • 一旦判断失效就会将该文件从WALs文件夹移动到OldWALs文件夹
• HHlog删除：
  • HMaster后台会启动一个线程每隔一段时间会检查一次文件夹OldWALs下的所有失效日志 文件，
  • 确认是否可以被删除，确认之后执行删除操作

regionserver异常，Distributed Log Splitting过程：

1. Master会将待切分日志路径发布到Zookeeper节点上（/hbase/splitWAL），每个日志作为一个任务，每个任务都 会有对应状态，起始状态为TASK_UNASSIGNED
2. 所有RegionServer启动之后都注册在这个节点上等待新任务，一旦Master发布任务之后，RegionServer就会抢占该 任务
3. 抢占任务实际上首先去查看任务状态，如果是TASK_UNASSIGNED状态，说明当前没有人占有，此时就去修改该 节点状态为TASK_OWNED。如果修改失败，说明其他RegionServer也在抢占，修改成功表明任务抢占成功。
4. RegionServer抢占任务成功之后会分发给相应线程处理，如果处理成功，会将该任务对应zk节点状态修改为 TASK_DONE，一旦失败会修改为TASK_ERR
5. Master会一直监听在该ZK节点上，一旦发生状态修改就会得到通知。任务状态变更为TASK_ERR的话，Master会 重新发布该任务，而变更为TASK_DONE的话，Master会将对应的节点删除

• HBase原理－RegionServer宕机数据恢复

1.3 实际过程遇到问题

1. 永久RIT：是具体情况而定，产生原因：机器搬迁时，停止节点正好碰到写未关闭，region做split，从而导 致 解决办法：重启节点并对master节点进行重启
2. hdfs坏块，meta表信息，hbase regionInfo信息丢失：如果单纯的是hdfs有坏块，基本上只能清除，所幸只 有hbase运行在hadoop集群，所以可以通过hbase hbck命令进行具体修复
3. 硬盘损坏，read卡损坏，服务宕机：下掉节点并将服务器替换，重新安装软件并添加集群，通过hdfs balance操作平衡数据，保证数据副本数量以及数据不丢失
4. hostname配置不了，不能配置host：通过namenode节点配置dfs.namenode.datanode.registration.ip-
   hostname-check 参数设置false进行控制，同时将服务器的hostname更改成物理ip，这样服务器客户端以及集
   群之间可以保证能够正常通信
5. 集群服务器搬迁，避免datanode在搬迁过程中复制：控制增加dfs.namenode.heartbeat.recheck-interval时间
   值,从而让namenode认为datanode还存在，从而避免复制
6. 同步服务器时间，服务器时间差别启动不了节点：30s时间间隔，超过30s启动不了节点
7. 表查询变化：变化不明显，一般体现在storefile变多以及表做major compaction(自己维护的表通知添加定 时合并)