扫一扫体验手机阅读
hbase手动compact与split
<span type="1" blog_id="1717714" userid='
344篇文章，92W+人气，0粉丝
高并发架构之路
￥51.00121人订阅
<span type="1" blog_id="1717714" userid='hbase 中HRegion 手动分裂无效_百度知道
hbase 中HRegion 手动分裂无效
问题函数splitRegion(HRegionInfo regionInfo, byte[] splitPoint)
方法，我指定了splitpoint,这个分割点确定存在域region中，可是分割完后，还是只有一个region,并没有新生成一个region.
我的测试数据是100多万条记录。请问，这个方法是否并不是一定能够分...
我有更好的答案
对于一个曾经运维过几百个节点的HBase集群的运维人员，并且Request每秒在5w以上，一定遇到过如下类似的问题。ZooKeeper服务在不停地报警指示在zookeeper的unassigned路径由一些节点在会一直存在，而且它的版本在不断增加。此时，HRegionServer和HMaster都会打印大量log，而且会持续给ZooKeeper带来压力，另外整个HBase集群没有报告出现任何Region offline的现象。如果你也是遇到同样的问题，那么请继续看本文的内容。背景：注册到zookeeper的unassgined路径下的节点，是处于Transition状态的Region，这主要有如下几种： public enum State {
// region is in an offline state
PENDING_OPEN,
// sent rpc to server to open but has not begun
// server has begun to open but not yet done
// server opened region and updated meta
PENDING_CLOSE,
// sent rpc to server to close but has not begun
// server has begun to close but not yet done
// server closed region and updated meta
SPLITTING,
// server started split of a region
// server completed split of a region
}几个常见场景：1）在一个RegionServer下线，在进行了log split之后，它上面的Region需要迁移到其它RegionServer的时候，会首先将其放入PENDING_OPEN的Region放入unassigned路径下。2）在Region进行split时，会有Region经历SPLITTING -〉SPLIT的过程，对于SPLIT的操作，下面将努力还原这个过程。HRegionServer有两种方式触发split操作：1）用户直接通过API指定splitkey，然后进行Region Split2）HRegionServer上CompactionSplitThread被触发。无论哪种方式，最后的核心处理逻辑都是类似的，都是由SplitTransction来进行。核心操作的步骤为：1）创建两个子女Region。此时，Parent Region的信息被创建在unassgined路径下，状态为SPLITTING，此时该Region处于Off-line。2）让两个子女Region上线。在first region 和 second Region上线的选择中， 给出了一个小小的trick，让second Region先上线。orignal Region：[starkey， endkey）
{a, b ,c}first Region : [startkey，midkey)
example {a}second Region: [midkey， endkey）
example {b, c}如果让first Region 先于 second Region上线，那么根据Get(key)查找离key最匹配的Region的区间时，会根据startkey进行匹配，由于second Region还没上线，则get(c)最后直接会在first Region中查找，找不到该值，直接返回null，而如果second Region先于first Region上线，则get(a)仍然会找到original Region，从而触发客户端的retry。3）结束整个split操作工作。这一步相当于打扫卫生的工作，然而就是这步操作，出现了一个问题。SplitTransaction将parent region的状态由SPLITTING 转换成SPLIT，这是在提醒HMaster端的AssignmentManager，你可以回收这个parent region了。AssignmentManager由nodeChanged发现了SPLIT的event之后，立刻就开始清理工作，它通过ExecutorThreadPool提交了SplitRegionHandler，接下来它的顺序就特别重要了：1）它会清空在AssignmentManager内存中该Parent Region记录的状态；2）然后删除unassigned节点的内容。注意这个步骤是time-consuming过程。同时，在SplitTransaction内，如果在sleep 100 ms之后，会醒来，如果发现AssignmentManager没有处理该路径，会重新创建一个新的version，状态仍然是SPLIT。可怕的事情是，如果ZooKeeper是顺序执行这个操作，如果某个时序上，AssignmentManager删除了该路径，而此时，HRegionServer上SplitTransaction又正好更新该ZNode，就悲剧了。此时，AssignmentManager由于内存已经清空了该数据，不再认定该Region是正常的Region，所以，就会报出Warning，而SplitTransaction只是100ms反复更新znode。分布式交互的死循环即将开始。对于该bug，深层次原因在于，对于zookeeper上一个node的创建与修改都是加锁的，而且是time-consuming的过程。如果在HMaster节点和HRegionServer节点高并发，多线程调度情况下，很容易出现上述的状态。基于此，我的解决方案是：增加HRegionServer上SplitTransaction的sleep的时间，可以由100ms改成4000ms，让等待时间足够长，同时保留之前循环检查来比避免ZK的event丢失问题。hbase-0.92.1 SplitTransaction.java412 Thread.sleep(100);
=& Thread.sleep(4000);注意，由于分裂的Region已经上线，修改该时间，不会带来性能上的影响。只是确保HMaster的AssignmentManager 可以更好进行相应的操作。
采纳率：91%
来自团队：
为您推荐：
其他类似问题
您可能关注的内容
hbase的相关知识
&#xe675;换一换
回答问题，赢新手礼包&#xe6b9;
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。51CTO旗下网站
HBase原理C所有Region切分的细节都在这里了
HBase系统中Region自动切分是如何实现的?这里面涉及很多知识点，比如Region切分的触发条件是什么?Region切分的切分点在哪里?如何切分才能最大的保证Region的可用性?如何做好切分过程中的异常处理?切分过程中要不要将数据移动?
作者：佚名来源：| 16:40
Region自动切分是HBase能够拥有良好扩张性的最重要因素之一，也必然是所有分布式系统追求无限扩展性的一副良药。HBase系统中Region自动切分是如何实现的?这里面涉及很多知识点，比如Region切分的触发条件是什么?Region切分的切分点在哪里?如何切分才能最大的保证Region的可用性?如何做好切分过程中的异常处理?切分过程中要不要将数据移动?等等，这篇文章将会对这些细节进行基本的说明，一方面可以让大家对HBase中Region自动切分有更加深入的理解，另一方面如果想实现类似的功能也可以参考HBase的实现方案。
Region切分触发策略
在最新稳定版(1.2.6)中，HBase已经有多达6种切分触发策略。当然，每种触发策略都有各自的适用场景，用户可以根据业务在表级别选择不同的切分触发策略。常见的切分策略如下图：
ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略。这是最容易理解但也最容易产生误解的切分策略，从字面意思来看，当region大小大于某个阈值(hbase.hregion.max.filesize)之后就会触发切分，实际上并不是这样，真正实现中这个阈值是对于某个store来说的，即一个region中最大store的大小大于设置阈值之后才会触发切分。另外一个大家比较关心的问题是这里所说的store大小是压缩后的文件总大小还是未压缩文件总大小，实际实现中store大小为压缩后的文件大小(采用压缩的场景)。ConstantSizeRegionSplitPolicy相对来来说最容易想到，但是在生产线上这种切分策略却有相当大的弊端：切分策略对于大表和小表没有明显的区分。阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，这对业务来说并不是什么好事。如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。
I ncreasingToUpperBoundRegionSplitPolicy :
0.94版本~2.0版本默认切分策略。这种切分策略微微有些复杂，总体来看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大store大小大于设置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系
：(#regions) * (#regions) * (#regions) * 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切分准备工作-寻找SplitPoint
region切分策略会触发region切分，切分开始之后的第一件事是寻找切分点-splitpoint。所有默认切分策略，无论是ConstantSizeRegionSplitPolicy、
IncreasingToUpperBoundRegionSplitPolicy
抑或是SteppingSplitPolicy，对于切分点的定义都是一致的。当然，用户手动执行切分时是可以指定切分点进行切分的，这里并不讨论这种情况。
那切分点是如何定位的呢? 整个region中最大store中的最大文件中最中心的一个block的首个rowkey
。这是一句比较消耗脑力的语句，需要细细品味。另外，HBase还规定，如果定位到的rowkey是整个文件的首个rowkey或者最后一个rowkey的话，就认为没有切分点。
什么情况下会出现没有切分点的场景呢?最常见的就是一个文件只有一个block，执行split的时候就会发现无法切分。很多新同学在测试split的时候往往都是新建一张新表，然后往新表中插入几条数据并执行一下flush，再执行split，奇迹般地发现数据表并没有真正执行切分。原因就在这里，这个时候仔细的话你翻看debug日志是可以看到这样的日志滴:
Region核心切分流程
HBase将整个切分过程包装成了一个事务，意图能够保证切分事务的原子性。整个分裂事务过程分为三个阶段：prepare & execute &
(rollback) ，操作模版如下：
prepare阶段：在内存中初始化两个子region，具体是生成两个HRegionInfo对象，包含tableName、regionName、startkey、endkey等。同时会生成一个transaction
journal，这个对象用来记录切分的进展，具体见rollback阶段。
execute阶段：切分的核心操作。见下图(来自 Hortonworks )：
regionserver 更改ZK节点 /region-in-transition 中该region的状态为SPLITING。
master通过watch节点/region-in-transition检测到region状态改变，并修改内存中region的状态，在master页面RIT模块就可以看到region执行split的状态信息。
在父存储目录下新建临时文件夹.split保存split后的daughter region信息。
关闭parent region：parent
region关闭数据写入并触发flush操作，将写入region的数据全部持久化到磁盘。此后短时间内客户端落在父region上的请求都会抛出异常NotServingRegionException。
核心分裂步骤：在.split文件夹下新建两个子文件夹，称之为daughter A、daughter
B，并在文件夹中生成reference文件，分别指向父region中对应文件。这个步骤是所有步骤中最核心的一个环节，生成reference文件日志如下所示：
&11:53:38,158&DEBUG&[StoreOpener-c3c919d3f05d-1]&regionserver.StoreFileInfo:&reference&'hdfs://hdfscluster/hbase-rsgroup/data/default/music/c3c919d3f05d/cf/d427b8fc4d9dc.00bbe4d0ecb6ddfdbacf66'&to&region=00bbe4d0ecb6ddfdbacf66&hfile=d427b8fc4d9dc。&
其中reference文件名为d427b8fc4d9dc.00bbe4d0ecb6ddfdbacf66，格式看起来比较特殊，那这种文件名具体什么含义呢?那来看看该reference文件指向的父region文件，根据日志可以看到，切分的父region是00bbe4d0ecb6ddfdbacf66，对应的切分文件是d427b8fc4d9dc，可见reference文件名是个信息量很大的命名方式，如下所示：
除此之外，还需要关注reference文件的文件内容，reference文件是一个引用文件(并非linux链接文件)，文件内容很显然不是用户数据。文件内容其实非常简单，主要有两部分构成：其一是切分点
splitkey，其二是一个boolean类型的变量(true或者false)，true表示该reference文件引用的是父文件的上半部分(top)，而false表示引用的是下半部分
(bottom)。为什么存储的是这两部分内容?且听下文分解。
看官可以使用hadoop命令 亲自来查看reference文件的具体内容：
hadoop&dfs&-cat&/hbase-rsgroup/data/default/music/c3c919d3f05d/cf/d427b8fc4d9dc.00bbe4d0ecb6ddfdbacf66&
6. 父region分裂为两个子region后， 将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region。
7. parent region通知修改 hbase.meta 表后下线，不再提供服务。下线后parent
region在meta表中的信息并不会马上删除，而是标注split列、offline列为true，并记录两个子region。为什么不立马删除?且听下文分解。
8. 开启daughter A、daughter B两个子region。通知修改 hbase.meta 表，正式对外提供服务。
rollback阶段：如果execute阶段出现异常，则执行rollback操作。为了实现回滚，整个切分过程被分为很多子阶段，回滚程序会根据当前进展到哪个子阶段清理对应的垃圾数据。代码中使用
JournalEntryType 来表征各个子阶段，具体见下图：
Region切分事务性保证
整个region切分是一个比较复杂的过程，涉及到父region中HFile文件的切分、两个子region的生成、系统meta元数据的更改等很多子步骤，因此必须保证整个切分过程的事务性，即要么切分完全成功，要么切分完全未开始，在任何情况下也不能出现切分只完成一半的情况。
为了实现事务性，hbase设计了使用状态机(见SplitTransaction类)的方式保存切分过程中的每个子步骤状态，这样一旦出现异常，系统可以根据当前所处的状态决定是否回滚，以及如何回滚。遗憾的是，目前实现中这些中间状态都只存储在内存中，因此一旦在切分过程中出现regionserver宕机的情况，有可能会出现切分处于中间状态的情况，也就是RIT状态。这种情况下需要使用hbck工具进行具体查看并分析解决方案。在2.0版本之后，HBase实现了新的分布式事务框架Procedure
V2(HBASE-12439)，新框架将会使用HLog存储这种单机事务(DDL操作、Split操作、Move操作等)的中间状态，因此可以保证即使在事务执行过程中参与者发生了宕机，依然可以使用HLog作为协调者对事务进行回滚操作或者重试提交，大大减少甚至杜绝RIT现象。这也是是2.0在可用性方面最值得期待的一个亮点!!!
Region切分对其他模块的影响
通过region切分流程的了解，我们知道整个region切分过程并没有涉及数据的移动，所以切分成本本身并不是很高，可以很快完成。切分后子region的文件实际没有任何用户数据，文件中存储的仅是一些元数据信息-切分点rowkey等，那通过引用文件如何查找数据呢?子region的数据实际在什么时候完成真正迁移?数据迁移完成之后父region什么时候会被删掉?
1. 通过reference文件如何查找数据?
这里就会看到reference文件名、文件内容的实际意义啦。整个流程如下图所示：
(1)根据reference文件名(region名+真实文件名)定位到真实数据所在文件路径
(2)定位到真实数据文件就可以在整个文件中扫描待查KV了么?非也。因为reference文件通常都只引用了数据文件的一半数据，以切分点为界，要么上半部分文件数据，要么下半部分数据。那到底哪部分数据?切分点又是哪个点?还记得上文又提到reference文件的文件内容吧，没错，就记录在文件中。
2. 父region的数据什么时候会迁移到子region目录?
答案是子region发生major_compaction时。我们知道compaction的执行实际上是将store中所有小文件一个KV一个KV从小到大读出来之后再顺序写入一个大文件，完成之后再将小文件删掉，因此compaction本身就需要读取并写入大量数据。子region执行major_compaction后会将父目录中属于该子region的所有数据读出来并写入子region目录数据文件中。可见将数据迁移放到compaction这个阶段来做，是一件顺便的事。
3. 父region什么时候会被删除?
实际上HMaster会启动一个线程定期遍历检查所有处于splitting状态的父region，确定检查父region是否可以被清理。检测线程首先会在meta表中揪出所有split列为true的region，并加载出其分裂后生成的两个子region(meta表中splitA列和splitB列)，
只需要检查此两个子region是否还存在引用文件，如果都不存在引用文件就可以认为该父region对应的文件可以被删除。现在再来看看上文中父目录在meta表中的信息，就大概可以理解为什么会存储这些信息了：
4. split模块在生产线的一些坑?
有些时候会有同学反馈说集群中部分region处于长时间RIT，region状态为spliting。通常情况下都会建议使用hbck看下什么报错，然后再根据hbck提供的一些工具进行修复，hbck提供了部分命令对处于split状态的rit
region进行修复，主要的命令如下：
-fixSplitParents&&Try&to&force&offline&split&parents&to&be&online.&&&-removeParents&&&&Try&to&offline&and&sideline&lingering&parents&and&keep&daughter&regions.&&&-fixReferenceFiles&&Try&to&offline&lingering&reference&store&files&
其中最常见的问题是 ：
ERROR:&Found&lingering&reference&file&hdfs://mycluster/hbase/news_user_actions/3b3ae24c65fc5094bc2acfebaa7a56de/meta/0f47cda55fa44cf9aaaed6.b7b3faabf2a248a54d3dc&&
简单解释一下，这个错误是说reference文件所引用的父region文件不存在了，如果查看日志的话有可能看到如下异常：
java.io.IOException:&java.io.IOException:&java.io.FileNotFoundException:&File&does&not&exist:/hbase/news_user_actions/b7b3faabf2a248a54d3dc/meta/0f47cda55fa44cf9aaaed&
父region文件为什么会莫名其妙不存在?经过和朋友的讨论，确认有可能是因为官方bug导致，详见HBASE-13331。这个jira是说HMaster在确认父目录是否可以被删除时，如果检查引用文件(检查是否存在、检查是否可以正常打开)抛出IOException异常，函数就会返回没有引用文件，导致父region被删掉。正常情况下应该保险起见返回存在引用文件，保留父region，并打印日志手工介入查看。如果大家也遇到类似的问题，可以看看这个问题，也可以将修复patch打到线上版本或者升级版本。【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
热点头条关注头条热点
24H热文一周话题本月最赞
讲师：222327人学习过
讲师：37552人学习过
讲师：353114人学习过
CTO专属活动
精选博文论坛热帖下载排行
一个网站，无论视觉上多美观或者内容多丰富，如果它不能适应各种浏览情况并能面向尽可能广泛的用户群，那它就不算是真正成功的网站。本书提...
订阅51CTO邮刊Hbase0.98版本的安装部署配置管理（Hadoop2.3、Hbase0.98、Hive0.13整合）_服务器应用_Linux公社-Linux系统门户网站
你好，游客
Hbase0.98版本的安装部署配置管理（Hadoop2.3、Hbase0.98、Hive0.13整合）
来源：Linux社区&
作者：黄杉
HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。
当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。
1，HBase的架构：
LSM - 解决磁盘随机写问题(顺序写才是王道)；
HFile - 解决数据索引问题(只有索引才能高效读)；
WAL - 解决数据持久化(面对故障的持久化解决方案)；
zooKeeper - 解决核心数据的一致性和集群恢复；
Replication - 引入类似MySQL的数据复制方案，解决可用性；
此外还有：自动分拆Split、自动压缩(compaction,LSM的伴生技术)、自动负载均衡、自动region迁移。
HBase集群需要依赖于一个Zookeeper ensemble。HBase集群中的所有节点以及要访问HBase
的客户端都需要能够访问到该Zookeeper ensemble。HBase自带了Zookeeper，但为了方便
其他应用程序使用Zookeeper，最好使用单独安装的Zookeeper ensemble。此外，Zookeeper ensemble一般配置为奇数个节点，并且集群、Zookeeper ensemble、HBase集群是三个互相独立的集群，并不需要部署在相同的物理节点上，他们之间是通过网络通信的。
Hbase和hadoop的关系可以如下图所示：
HBase 系统架构&
Hadoop+HBase搭建云存储总结 PDF
HBase 结点之间时间不一致造成regionserver启动失败
Hadoop+ZooKeeper+HBase集群配置
Hadoop集群安装&HBase实验环境搭建
基于Hadoop集群的HBase集群的配置 &
Hadoop安装部署笔记之-HBase完全分布模式安装
单机版搭建HBase环境图文教程详解
2，Hadoop和Hbase的版本匹配
下面在给列出官网信息：下面面符号的含义：S =支持并且测试,X = 不支持,NT =应该可以，但是没有测试。如下图所示：
3，下载地址
从Step2的图中看出，由于我安装的hadoop是2.3.0，所以可以选择0.96以上的hbase版本，这里选择比较稳健的0.98版本的hbase下载。
进hbase官网
进去，找到下载，进去
再进去，选择HTTP，第一个mirrors，找到下载地址如下：
4 ，开始安装
tar zxvf hbase-0.98.9-hadoop2-bin.tar.gz -C /home/hadoop/src/
5.1)，配置hbase-site.xml
开始修改配置文件：/home/hadoop/src/hbase-0.98.9-hadoop2/conf
完全分布式安装：
&configuration&&property&&name&hbase.rootdir&/name&&value&hdfs://192.168.52.128:9000/hbase&/value&&description&HBase数据存储目录&/description&&/property&&property&&name&hbase.cluster.distributed&/name&&value&true&/value&&description&指定HBase运行的模式：false：单机/伪分布；true：完全分布&/description&&/property&&property&&name&hbase.master&/name&&value&hdfs://192.168.52.128:60000&/value&&description&指定Master位置&/description&&/property&
&property&&name&hbase.zookeeper.property.dataDir&/name&&value&/home/hadoop/zookeeper&/value&&/property&&property&&name&hbase.zookeeper.quorum&/name&&value&192.168.52.128, 192.168.52.129, 192.168.52.130&/value&&description&指定ZooKeeper集群&/description&&/property&
&property&&name&hbase.master.info.bindAddress&/name&&value&192.168.52.128&/value&&description&The bind address for the HBase Master web UI&/description&&/property&&/configuration&
& & 5.1)，& 配置
[root@name01 conf]# more hbase-site.xml
&?xml version="1.0"?&
&?xml-stylesheet type="text/xsl" href="configuration.xsl"?&
&* Licensed to the Apache Software Foundation (ASF) under one
&* or more contributor license agreements.& See the NOTICE file
&* distributed with this work for additional information
&* regarding copyright ownership.& The ASF licenses this file
&* to you under the Apache License, Version 2.0 (the
&* "License"); you may not use this file except in compliance
&* with the License.& You may obtain a copy of the License at
&* Unless required by applicable law or agreed to in writing, software
&* distributed under the License is distributed on an "AS IS" BASIS,
&* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
&* See the License for the specific language governing permissions and
&* limitations under the License.
&configuration&
&property&
&name&hbase.rootdir&/name&
&value&hdfs://192.168.52.128:9000/hbase&/value&
&description&HBase data directory&/description&
&/property&
&property&
&name&hbase.cluster.distributed&/name&
&value&true&/value&
&description&指定HBase运行的模式：false：单机/伪分布；true：完全分布&/description&
&/property&
&property&
&name&hbase.master&/name&
&value&hdfs://192.168.52.128:60000&/value&
&description&指定Master位置&/description&
&/property&
&property&
&name&hbase.zookeeper.property.dataDir&/name&
&value&/home/hadoop/zookeeper&/value&
&/property&&property&
&name&hbase.zookeeper.quorum&/name&
&value&192.168.52.128, 192.168.52.129, 192.168.52.130&/value&
&description&指定ZooKeeper集群&/description&
&/property&
&property&
&name&hbase.master.info.bindAddress&/name&
&value&192.168.52.128&/value&
&description&The bind address for the HBase Master web UI
&/description&
&/property&
&/configuration&
[root@name01 conf]#
5.2)，配置文件regionservers:
[root@name01 conf]# more regionservers
192.168.52.128
192.168.52.129
192.168.52.130
[root@name01 conf]#
5.3)，设置环境变量hbase-env.sh:
vim hbase-env.sh
export JAVA_HOME=/usr/lib/jvm/jdk1.7.0_60
export HBASE_CLASSPATH=/home/hadoop/src/hbase-0.98.9-hadoop2/conf
export HBASE_HEAPSIZE=2048
export HBASE_MANAGES_ZK=false&
其中，JAVA_HOME表示java安装目录，HBASE_CLASSPATH指向存放有Hadoop配置文件的目录，这样HBase可以找到HDFS的配置信息，由于本文Hadoop和HBase部署在相同的物理节点，所以就指向了Hadoop安装路径下的conf目录。HBASE_HEAPSIZE单位为MB，可以根据需要和实际剩余内存设置，默认为1000。HBASE_MANAGES_ZK=false指示HBase使用已有的Zookeeper而不是自带的。
更多详情见请继续阅读下一页的精彩内容：
相关资讯 & & &
& (10/10/:16)
& (09/14/:44)
& (11/18/:51)
& (02/25/:19)
& (07/04/:06)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款