hbase读数据流程,hbase数据存储原理
HBase读写操作-ROOT-表和.META.表
上图是RegionServer数据存储关系图。上文提到,HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的,当MemStore累计到一定阈值时,就会创建一个新的MemStore,并且将老的MemStore添加到Flush队列,由单独的线程Flush到磁盘上,成为一个StoreFile。与此同时,系统会在Zookeeper中记录一个CheckPoint,表示这个时刻之前的数据变更已经持久化了。当系统出现意外时,可能导致MemStore中的数据丢失,此时使用HLog来恢复CheckPoint之后的数据。
StoreFile是只读的,一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后,就会进行一次合并操作,将对同一个key的修改合并到一起,形成一个大的StoreFile。当StoreFile的大小达到一定阈值后,又会对 StoreFile进行切分操作,等分为两个StoreFile。
1.1 写操作流程
(1) Client通过Zookeeper的调度,向RegionServer发出写数据请求,在Region中写数据。
(2) 数据被写入Region的MemStore,直到MemStore达到预设阈值。
(3) MemStore中的数据被Flush成一个StoreFile。
(4) 随着StoreFile文件的不断增多,当其数量增长到一定阈值后,触发Compact合并操作,将多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除。
(5) StoreFiles通过不断的Compact合并操作,逐步形成越来越大的StoreFile。
(6) 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个新的Region。父Region会下线,新Split出的2个子Region会被HMaster分配到相应的RegionServer上,使得原先1个Region的压力得以分流到2个Region上。
可以看出HBase只有增添数据,所有的更新和删除操作都是在后续的Compact历程中举行的,使得用户的写操作只要进入内存就可以立刻返回,实现了HBase I/O的高性能。
1.2 读操作流程
(1) Client访问Zookeeper,查找-ROOT-表,获取.META.表信息。
(2) 从.META.表查找,获取存放目标数据的Region信息,从而找到对应的RegionServer。
(3) 通过RegionServer获取需要查找的数据。
(4) Regionserver的内存分为MemStore和BlockCache两部分,MemStore主要用于写数据,BlockCache主要用于读数据。读请求先到MemStore中查数据,查不到就到BlockCache中查,再查不到就会到StoreFile上读,并把读的结果放入BlockCache。
寻址过程:client–Zookeeper–-ROOT-表–META表–RegionServer–Region–client
2.1 -ROOT-表结构
HBase的用-ROOT-表来记录.META.的Region信息,就和.META.记录用户表的Region信息一模一样。-ROOT-只会有一个Region。
这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是:
/hbase/root-region-server
2.2 .META.表结构
2.3 两个表的关系
HBase的所有Region元数据被存储在.META.表中2.1,随着Region的增多,.META.表中的数据也会增大,并分裂成多个新的Region。为了定位.META.表中各个Region的位置,把.META.表中所有Region的元数据保存在-ROOT-表中,最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前,需要首先访问Zookeeper获得-ROOT-的位置,然后访问-ROOT-表获得.META.表的位置,最后根据.META.表中的信息确定用户数据存放的位置,如下图所示。
-ROOT-表永远不会被分割,它只有一个Region,这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度,.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来,且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据,则询问相关.META.表的Region服务器,试图获取数据的位置,如果还是失败,则询问-ROOT-表相关的.META.表在哪里。最后,如果前面的信息全部失效,则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效,则需要进行6次网络来回,才能定位到正确的Region。
Hbase读写原理
不同列族分别存在不同的文件夹里。
与MySQL比较
首先Hbase是依赖于HDFS和zookeeper的。
Zookeeper分担了Hmaster的一部分功能,客户端进行DML语句的时候,都是先跟ZK交互。
RegionServer管理了很多的Region(表),RegionServer里面的WAL(HLog)是预写入日志,功能是防止内存中的数据没有来的及落盘时丢失。在Region里面管理的Store管理的是列族,Store里面有Mem Store(内存),Flush之后,删除内存中的数据,同时写入文件StoreFile Hfile,Hfile 其实是在DataNode里面的。
Hbase的读比写慢。
Hbase命名空间下有一张元数据表meta表和namespace表。meta表里面保存了要操作的表所在的位置等元数据。
(1)首先客户端向zk请求元数据表所在的RegionServer,zk返回给客户端meta表所在的regionServer。
(2)然后客户端再去对应的RegionServer查找meta表,找到真正要操作的表所在的regionServer,同时把meta表的信息缓存下来,加快后续的查询。
(3)然后客户端再向目标表所在的RegionServer发送put请求。先把数据写到Hlog里面,再写到内存MemStore,数据会在内存排序,然后向客户端发送ack,到这里对于客户端来说写数据已经结束了。再等到MemStore的刷写时机后,将数据刷写到Hfile.
注:meta表所在的位置信息保存在zk的meta-region-server节点上,客户端首先就是在这个节点上差询meta表所在的RegionServer。meta表里面的信息就是表与其对应的RegionServer的信息
这个stu表可能不止一条,因为stu表可能数据量大了之后根据RowKey进行了切分,并且可能会在不同的机器上。
不同的列族是在不同的文件夹。
MemStore刷写时机:
全局的MemStore的容量,默认是堆内存的40%。这个容量值会触发flush操作,所有的MemStore都要刷写,flush操作会阻塞读写操作。
会刷写并阻塞到到MemStore大小降到它的最大容量的95%
WAL日志的刷写时机:
可以设置日志的大小和数量,当达到一定数量,刷写到HDFS
(1)从zk找meta表所在的RegionServer
(2)从上述RegionServer里的meta表里找目标表所在的RegionServer,同时把meta表缓存,加速后面的查询。
(3)向目标表所在的RegionServer发送get请求。可以从block Cache,MemStore还有StoreFile里面查,具体从哪查根据时间戳,查时间戳大的,具体就都查然后merge取最新。
RegionServer里面有block Cache可以缓存磁盘的数据,加速查询。如果block Cache里面有,就将缓存和MemStore的数据merge然后取最新时间戳,没有就是把磁盘读的和MemStore里面的合并。所以hbase大多数读要走磁盘,所以读很慢。
每次刷写会生成新的Hfile,Hfile很小并且数量多的时候会影响查询的速度。所以要进行合并。合并分为minor Compaction和major Compaction
minor Compaction将临近的若干较小的Hfile合并成一个较大的Hfile,不会清理过期和删除的数据,major Compaction会将一个Store里面的所有Hfile合并成一个大的Hfile,并且会清理掉过期和删除的数据。
数据的读写可以不依赖Hmaster,只需要指定zookeeper,但是Hmaster负责region调度的元数据
但是DDL语言是要有Hmaster的
Flush和major Compact
(1)flush在同一个内存中清除过期或删除(删除标记也是一行数据)的数据,但是如果数据不同的版本分布在不同的memStroe,就不能清除。删除的标记在flush之后不会被删,但在后面的major compaction会把删除标记删除掉。
(2)major compaction 会清除过期或删除的数据。
默认情况下,每个Table起初只有一个Region,随着数据的不断写入,Region会自动拆分,两个子Region开始都会在一个Regionserver里面,但是出于负载均衡的考虑,Hmaster有可能会将某个Region传给其他的RegionServer。
Split的时机:
(1)当一个Region中的某个Store下的StoreFile的总大小查过某个值,由参数hbase.hregion.max.filesize设定(默认10g),该Region就会按照RowKey进行拆分。
(2)在新版本中这个值是Min(R^2*"hbase.hregion.memStore.flush.size(128M)","hbase.hregion.max.filesize"),R是当前RegionServer中属于该Table的Region个数。分region是按照RowKey切分的。这会导致数据倾斜,就是因为切分的阈值在变化,导致切分之后的region数据量不均匀,导致热点的问题。所以在建表的时候要做预分区,就是用RowKey规划好多少个region,不让hbase自己的切分逻辑切分。
官方建议只用一个列族,防止不同的列族之间数据不均匀,单一列族数据量增多,导致全局的flush,数据量小的列族也要flush,这样会形成很多小的storeFile。
delete操作:
(1)设置RowKey:打的删除标记是deleteFamily,删除多个版本
(2)设置RowKey+Family:打的标记是deleteFamily,删除多个版本
(3)设置RowKey+family+column:有addColumn()和addColumns().addColumn是删除最新的版本或者删除指定时间戳的版本,删除标记是delete标记。addColumns是删除所有的版本或者删除指定时间戳或之前的版本,删除标记是deleteColumn
Delete的操作其实也是put操作,put的是删除的标记。
在Hbase中HMaster负责监控HRegionServer的生命周期,均衡RegionServer的负载,如果HMaster挂掉了,那个整个Hbase集群将处于不健康的状态,并且此时的工作状态不会维持太久。所以Hbase支持对HMaster的高可用配置。
在Hbase的conf目录下新建backup-masters文件,vim加入备份Master,比如slave01,slave02.在把文件分发到各个slave里,然后再启动hbase 就能实现HMaster的高可用了。
每一个region维护着StartRow和EndRow,如果加入的数据符合某个region维护的RowKey范围,则该数据交给这个region维护。那么依照这个原则,我们可以将数据所要投放的分区提前大致的规划好,以提高Hbase性能。
(1)手动设定预分区
手动设置RowKey分了5个region
(2)生成16进制序列预分区
(3)按照文件中设置的规则预分区
创建split.txt
然后执行
这里如果文件里面给的分区键不是按照顺序的,hbase会先帮我们把键排序,然后按照键来分区。
(4)使用JavaAPI预分区
admin的创建表的方法有多个重载,可以只传表的描述,也可以加入分区的信息。admin.createTable
规划分区要考虑未来数据量和机器的规模。虽然提前做了分区,但是最后如果分区大于了10G,还是会触发split。假设一台机器有100G磁盘,那么预分区尽量大于10个,这样就能避免预分区之后又触发了大于10G的split。
(1)希望数据能够尽量均匀的分配在多个分区里面(散列性)。
(2)唯一性
(3)长度原则(生产环境70到100位)
常见的设计方案:
(1)生产随机数、hash、散列值
(2)字符串反转
(3)字符串拼接
电信项目:
一次通话的记录:13112341233-18998768771 2018-12-12 12:12:21 568
假设分300个区
分区键怎么设计:
(299个键)
000|
001|
...
298|
RowKey的前面一般会拼上000_,001_,...,298_
这样做的好处是,根据前三位就能知道哪个分区。
(1)我们希望手机号尽量分布在不同的分区,但是相同的手机号数据集中在同一个分区,这样方便查询某个用户的通话信息。000_13112341233
(2)因为每个人通话的需求不同,也希望把同一个人的通话记录也分布在不同的分区里面。000_13112341233_2019-12-12
哈希取余:[(13112341234^201912).hash]%299
假设要查询某用户2019年2月的通话记录,可以用13112341234 201902做startRowkey,13112341234 201903做endRowKey
微博。
1、需求
(1)微博内容的浏览
(2)用户社交:关注用户,取关用户
(3)拉取关注人的微博用户
2、设计表
(1)微博内容表Content
行键:用户id+时间戳
(2)用户关系表
因为正常情况一个用户的粉丝和关注都不多,可以用一行存储关注和粉丝的情况。
行键:用户id
(3)初始化页面的表(显示关注的人的最近三条微博)
HBASE 1.0
前身:BigTable
网页搜索:
google分布式存储系统BigTable依赖GFS
Hbase(bigtable的开源实现): 高可靠、高性能、面向列、可伸缩
存储结构化和半结构化的数据
优点:
水平可扩展性特别好:
依赖:
文件存储系统:HDFS
海量数据处理:MapReduce
协同管理服务:Zookeeper
满足了:大数据量的实时计算
数据类型:
? ? RDBMS:关系数据模型、多种数据类型
? ? Hbase:
数据操作:
存储模式:
索引:
数据维护:
可伸缩性:
? ? ? ? 纵向扩展:
? ? ? ? 水平扩展:
Hbase的访问接口:
? ? ? ? ? ? JAVA API
? ? ? ? ? ? shell
? ? ? ? ? ? thrift Gateway
? ? ? ? ? ? restful Gateway
? ? ? ? ? ? SQL接口:pig编写类sql? hive用hivesql访问Hbase
Hbase的数据类型:
? ? ? ? 列限定符
? ? ? ? 每个值都是未解释的bytes
? ? ? ? 一个行可以有一个行键和多列
? ? ? ? 表由列族组成
Hbase数据模型:
? ? 列族支持动态扩展、保留旧版本(HDFS只能追加数据)
基础元素:
? ? 行键 : rowkey
? ? 列族
? ? 列限定符
? ? 单元格 (时间戳概念、对应数据版本)
坐标概念:
? ? 四维定位:行键、列族、列限定符、时间戳
稀疏表
HBASE:面向列的存储:高数据压缩率、分析便捷
RDBMS :面向行存储,事务性操作(记录完整)、不便于分析(需要全表扫描)
4.3 HBASE 的实现原理
4.3.1 库函数 、master服务器、region服务器
Master服务器:
分区信息进行维护和管理
维护region服务器列表
确认当前工作的region服务器
负责对region进行分配和负载平衡
对表的增删改查
region服务器:
客户端不依赖于Master获取位置信息
用户数据的存储和管理
Region服务器--10-1000个region -----Store是一个列族----每个列族就是一个Hfile----所有region公用1个Hlog
写数据流程:Region服务器---写缓存Memstore---写日志(Hlog)
读数据流程:Region服务器-读缓存Memstore(最新数据)----StoreFile
缓存刷新:周期性将缓存内容刷写到Storefile 清空缓存---Hlog写入标记
每次刷写会生成新的StoreFile 每个Store包含多个StoreFile
每个Region服务器都有一个自己的Hlog,将启动检查确认缓存刷新是否有新的内容需要刷写,发现则刷写新的storefile,完成后删除Hlog,开始对外提供服务
Storefile的合并,storefile 的数量达到阈值后,会进行合并。当Storefile超过大小阈值则会触发Region的分裂
4.4 Hlog的工作原理
Zookeeper负责监听region服务器,由master处理故障,通过故障服务器的Hlog恢复,按region切分Hlog,将region和对应的Hlog分配到新的region服务器上
一个HBASE表会被划分成多个Region(1G-2G 取决于服务器性能)
同一个region不会被拆分到不同服务器上
Region的寻找:
Meta表:regionID 服务器ID 存储元数据
Root表:只有一个region
三级寻址:
zookeeper文件---root表-多个meta表--多个用户数据表
客户端会有Hbase三层寻址的缓存,调用访问Hbase的接口,缓存失效后,再次寻址
zookeeper决定master服务器,确保只有一个master
4.5 Hbase的应用方案
性能优化:
1)时间靠近存放----将时间戳引入行键,使用Long.max-时间戳进行排序
2)提升读写性能,创建表时设置HcloumnDescriptor.setMemory=true,会将表放入内存的缓存中
3)节省存储·空间----设置最大版本数、保存最新版的数据,将最大版本参数设置为1
4)timetolive参数,会将过期数据自动清空
检测Hbase性能:
Maste-status(web浏览器查询)
ganglia
OpenTSDB
Armbari
sql 查询HBASE
1)hive整合hbase
2)Phoenix
Hbase 二级索引 (辅助索引)
默认只支持对rowkey进行索引
Hbase行访问:
1)单行键访问
2)确定起点和终点访问区间数据
3)全表扫描
二级索引样例:
? ? Hindex? ? Hbase+redis? Solr+ Hbase
二级索引的机制:
? ? ? ? Hbase Coprocessor?
? ? ? ? endpoint? ---存储过程
? ? ? ? observer----触发器
? ? ? ? 通过Observer监测数据插入动作,同步写入索引表,完成对表和列的索引
? ? ? Hbase 主表 索引表
4.6 HBASE的shell命令
三种部署模式:单机 伪分布式? 分布式
HDFS
创建表
create table, F1, F2, F3
list table
每次只能为1行的1列添加数据
put? table R1,R1:C1 ,“1,2,3”
scan? table? R1,{column='R1:C1'}
get? table
删除表:
disable table +drop table
4.7 JAVA API +HBASE
六、HBase写入流程
1、HBase写入流程
HBase服务端没有提供update,delete接口,HBase中对数据的更新、删除操作都认为是写入操作,更新操作会写入一个最小版本数据,删除操作写写入一条标记为deleted的KV数据
1.1、写入流程三个阶段概况
1)客户端处理阶段:客户端将用户请求进行预处理,并根据集群元数据定位写入数据所在的RegionServer,将请求发送给RS
2)Region写入阶段:RS收到请求之后解析数据,首先把数据写入WAL,再写入对应Region对应的MemStore
3)MemStore Flush阶段:当Region中MemStore容量达到一定阈值之后,系统异步执行flush操作,将内存写入文件,形成HFile
1.2、用户写入请求在完成写入MemStore之后就会返回成功。MemStore Flush是一个异步执行的过程。
1.3、客户端处理阶段步骤详解:
1)客户端可以设置批量提交,如果设置了批量提交(autoflush=false)客户端会先将数据写入本地缓冲区等达到一定阈值之后才会提交。否则put请求直接会提交给服务端进行处理。
2)RS寻址,在提交之前HBase会在元数据表hbase:meta中根据rowkey找到她们归属的RS
2.1)客户端根据写入的表和rowkey在元数据中查找,如果能够查找出该rowkey所在的RS及Region,就直接发送写入请求
2.2)如果客户端没有找到rowkey信息,需要首先到zk上找到hbase:meta表所在的RS,向那RS发送查询请求获取元数据,然后在元数据中查找rowkey所在的RS,并将元数据缓存在本地,以备下次使用。
3)客户端发送远程RPC请求给RS,将数据写入目标Region的MemStore中
1.4、Region写入阶段步骤详解:
1)获取行锁,HBase中使用行锁保证对同一行数据的更新是互斥操作,用以保证更新的原子性,要么成功要么失败
2)更新所有待写入keyValue的时间戳为当前系统时间
3)对一次写入同一个Region的一个或多个KeyValue构建一条WALEdit记录,这样做的目的是保证Region级别事务的写入原子性
4)把WALEdit写入HLog,HLog是存储在HDFS上需要sync操作把HLog真正落地到HDFS,在这一部暂时不用执行sync,HBase使用了disruptor实现了高效的生产者消费者队列,来异步实现WAL的追加写入操纵
5)写入WAL之后再将数据写入MemStore
6)释放行锁
7)sync WAL:将HLog真正sync到HDFS,如果sync失败,执行回滚操作将MemStore数据移除
8)结束写事务。更新对外可见,更新生效
1.5、MemStore Flush阶段详解:
1.5.1、触发flush条件
1.5.1.1、MemStore级别限制,当Rgion中任意一个MemStore大小达到阈值(hbase.hrgion.memstore.flush.size)默认128M
1.5.1.2、Region级别限制:当Region所有MemStore的大小达到了上限(hbase.hregion.memstore.block.multiplier * hbase.hrgion.memstore.flush.size)超过memstore大小的倍数达到该值则阻塞所有写入请求进行flush,自我保护默认是2.
1.5.1.3、RegionServer级别限制:当RS中MemStore的总大小超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit * hbase.reagionserver.global.memstore.size RS则开始强制执行flush,按Region中MemStore大小从大到小进行flush,直到总MemStore大小下降到低水位。
1.5.1.4、当一个RegionServer中HLog数量达到一定上限(hbase.regionserver.maxlogs),系统选择最早的HLog对应的Rgion进行Flush
1.5.1.5、HBase定期Flush,默认是1小时确保MemStore不会长时间没有持久化。为了避免同一时间所有都进行flush,定期的flush操作有一定时间的随机延迟
1.5.1.6、手动flush,用户可以通过flush 'tablename'或者 flush 'regionname'对一个表或者Region进行flush
1.5.2、flush执行步骤
1.5.2.1、prepare阶段
遍历当前region下的MemStore做一个快照,然后新一个ConcurrentSkipListMap接受新的数据请求。此阶段需要通过锁来阻塞写请求,结束后释放锁,此过程持锁时间很短
1.5.2.2、flush阶段
对快照数据按照特定格式生成HFile持久化为临时文件放在.tmp目录下。这个过程涉及到磁盘IO操作,相对比较耗时
1.5.2.3、commit阶段
把临时文件移动到指定的CF目录下。再清空快照数据。
1.5.3、MemStore Flush对业务的影响
1.5.3.1、大部分MemStore Flush操作都不会对业务读写产生太大影响,
1.5.3.2、Region Server级别呆滞的flush,会对用户请求产生较大影响,会阻塞落在该RS上的写入操作。
1.6、HLog写入模型
1.6.1、HLog持久化级别
SKIP_WAL:只写缓存,不写HLog,不可取
ASYNC_WAL:异步写入HLog
SYNC_WAL:同步写入日志文件,数据只是被写入文件系统缓存中并没有真正落盘。默认是此级别
FSYNC_WAL:同步将数据写入日志文件并强制落盘,这是最严格的写入级别,保证数据不丢失,性能相对较差
USER_DEFAULT:如果用户没有指定持久化级别,默认HBase使用SYN_WAL等级持久化数据put.setDurability(Durability.SYNC_WAL);
1.6.2、HLog写入模型
1、HLog写入需要经过3个阶段:手写将数据写入本地缓存,然后将本地缓存写入文件系统,最后执行syn操作同步到磁盘
2、HBase使用LMAX Disruptor框架实现了无锁有界队列操作,写入模型如下图
2、BulkLoad 流程
2.1、BulkLoad使用场景:用户数据位于HDFS中,业务需要定期将这部分海量数据导入HBase系统.
2.2、核心流程分两步
2.2.1、HFile生成阶段:运行一个MapReduce任务,map需要自己实现,将HDFS文件中的数据读取出来组装一个复合KV,其中Key是rowkey,Value可以是KeyValue对象、Put对象甚至Delete对象;reduce由HBase负责,他会根据表信息配置一个全局有序的partitioner,将partitioner文件上传到HDFS集群,设置reduce task个数为目标表的Region个数。为每个Region生成一个对应的HFile文件
2.2.2、HFile导入阶段:HFile主备就绪后,将HFile加载到在线集群。
2.3、Bulkload遇到的一些常见问题
2.3.1、设置正确的权限
2.3.1、BulkLoad操作过程涉及到的用户:
第一步,通过MapReduce任务生成HFile。假设这个过程使用的HDFS账号为:u_mapreduce.
第二步,将HFile加载到HBase集群,假设这个步骤使用的账号为:u_load。
一般地:HBase集群由一个专门的账号用来管理HBase数据,该账号拥有HBase集群的所有表的最高权限,
同时可以读写HBase root目录下的所有文件,假设这个账号为:hbase_srv
2.3.2、权限设置
2.3.2.1、通过MapReduce任务生成HFile,HFile文件的owner为u_mapreduce。
2.3.2.2、u_load需要HFile文件以及目录的读、写权限。写的权限是因为在HFile跨越多个Region时,需要对HFile进行split操作。
另外u_load账号需要HBase表的Create权限
2.3.2.3、hbase_srv账号把HFile文件从用户的数据目录rename到HBase的数据目录,所以hbase_sHrv需要有用户数据目录及HFile的读取
权限,但事实上仅读取权限还不够,应为加载到HBase数据目录的HFile目录的owner仍为u_mapreduce。一旦执行完compaction操作
之后,这些文件无法挪动到archive目录,导致文件越来越多。这个问题在HBase 2.x 上修复。
2.3.2、影响Locality
如果生成HFile都在的HDFS集群和HBase所在HDFS集群时同一个,则MapReduce生成HFile,能够保证HFile与目标Region落在同一个机器上。这样就保证了Locality。由hbase.bulkload.locality.sensitive.enabled的参数控制整个逻辑,默认是true.所以默认保证locality的。
如果用户MapReduce在A集群上生成HFile,通过distcp拷贝到集群B.这样BulkLoad到HBase集群数据是没法保证Locality的。需要跑完BulkLoad之后再手动执行major compact,来提升loaclity。
2.3.3、BulkLoad数据复制
在1.3之前版本中,BulkLoad到HBase集群的数据并不会复制到备集群,这样可能无意识的导致备集群比主集群少了很多数据。在HBase1.3版本之后开始支持BulkLoad数据复制。需要开启开关:hbase.replicatition.bulkload.enabled=true。