① hbase 源码 什么语言开发的
是用java开发的，hbase包含两个核心服务，一个是HMaster，一个是HRegionServer，在hbase部署的服务器上调用jps命令能查看到这两个进程。
② hbase 中HRegion 手动分裂无效
对于一个曾经运维过几百个节点的HBase集群的运维人员，并且Request每秒在5w以上，一定遇到过如下类似的问题。
ZooKeeper服务在不停地报警指示在zookeeper的unassigned路径由一些节点在会一直存在，而且它的版本在不断增加。此时，HRegionServer和HMaster都会打印大量log，而且会持续给ZooKeeper带来压力，另外整个HBase集群没有报告出现任何Region offline的现象。如果你也是遇到同样的问题，那么请继续看本文的内容。
背景：
注册到zookeeper的unassgined路径下的节点，是处于Transition状态的Region，这主要有如下几种：
public enum State {
OFFLINE, // region is in an offline state
PENDING_OPEN, // sent rpc to server to open but has not begun
OPENING, // server has begun to open but not yet done
OPEN, // server opened region and updated meta
PENDING_CLOSE, // sent rpc to server to close but has not begun
CLOSING, // server has begun to close but not yet done
CLOSED, // server closed region and updated meta
SPLITTING, // server started split of a region
SPLIT // 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 Split
2）HRegionServer上CompactionSplitThread被触发。
无论哪种方式，最后的核心处理逻辑都是类似的，都是由SplitTransction来进行。
核心操作的步骤为：
1）创建两个子女Region。此时，Parent Region的信息被创建在unassgined路径下，状态为SPLITTING，此时该Region处于Off-line。
2）让两个子女Region上线。在first region 和 second Region上线的选择中，https://issues.apache.org/jira/browse/HBASE-4335 给出了一个小小的trick，让second Region先上线。
orignal Region：[starkey， endkey） example {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.java
412 Thread.sleep(100); => Thread.sleep(4000);
注意，由于分裂的Region已经上线，修改该时间，不会带来性能上的影响。只是确保HMaster的AssignmentManager 可以更好进行相应的操作。
③ hbase splits 如何定位到哪个分区
1.取样，先随机生成一定数量的rowkey,将取样数据按升序排序放到一个集合里
2.根据预分区的region个数，对整个集合平均分割，即是相关的splitKeys.
3.HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys)可以指定预分区的splitKey，即是指定region间的rowkey临界值.
④ hbase预分区与region切割的关系
一张表预分区N个，那就是一开始就设定了N个region；
hbase.hregion.max.filesize 设定的region大小，超过了就会split，就会增加一个region，对预分区没什么影响。
一张表假如不预分区，那么数据超过region最大值才会拆分，比如你1天10G数据，设定5G才split，两天内写数据都写在一个region里，没有分布式效果，改region就是热点。
预设分区一般配合rowkey设计解决热点，例如预分区5个，rowkey可设置前最A、B、C、D、E，程序里面随机的加其中的一个前缀，那么就会随机插入到各个region中，但是一般又会和业务系统需求有些矛盾。例如rowkey按时间戳字符串加盐，那么就只有一各个region scan再合起来统计会比较快，直接scan “A20181111”到“D20181128”很慢很麻，还有按用户ID、手机号等等做rowkey加盐或者hash散列可能都会在设计上有热点和业务需求的矛盾点。
⑤ hbase源代码 纯java开发的吗
是的，纯java开发的nosql
⑥ 关于hbase的问题，开启hbase后一会hmaster和hregionserver就没了
一、通常向HBase批量导入数据有三种常用方式
1、使用HBase提供的TableOutputFormat，原理是通过一个Maprece作业将数据导入HBase
2、还有一种方式就是使用HBase原生Client API（put）
3、前两种方式因为须要频繁的与数据所存储的RegionServer通信。一次性入库大量数据时，特别占用资源，所以都不是很有效。因为HBase在HDFS中是以HFile文件结构存储的，所以高效便捷的方法就是直接生成HFile文件然后使用Bulk Load方法，即HBase提供的HFileOutputFormat类。
二、Bulk Load基本原理
Bulk Load处理由两个主要步骤组成：
1、生成HFile文件
Bulk Load的第一步会执行一个Maprece作业，其中使用到了HFileOutputFormat输出HBase数据文件：StoreFile。
HFileOutputFormat的作用在于使得输出的HFile文件能够适应单个region。使用TotalOrderPartitioner类将map输出结果分区到各个不同的key区间中，每一个key区间都相应着HBase表的region。
2、导入HBase表
第二步使用completebulkload工具将第一步的结果文件依次交给负责文件相应region的RegionServer，并将文件move到region在HDFS上的存储文件夹中。一旦完毕。将数据开放给clients。
假设在bulk load准备导入或在准备导入与完毕导入的临界点上发现region的边界已经改变，completebulkload工具会自己主动split数据文件到新的边界上。可是这个过程并非最佳实践，所以用户在使用时须要最小化准备导入与导入集群间的延时，特别是当其它client在同一时候使用其它工具向同一张表导入数据。
Bulk Load常遇到的一个ERROR:”java.io.IOException: Retry attempted 10 times without completing, ling out”
错误解析：
我们使用的Hbase1.0.2版本下，如果Hfile文件 跨越多个region，bulkload会自动地将Hfile文件split，但是对于每次retry只会将指定的Hfile文件split一次。但是在hbase-site.xml配置文件里有个参数hbase.bulkload.retries.number控制了hbase对一个hfile最多plit多少次。这个参数默认是10，如果某个hfile跨越的region数超过10个就会报上述Exception。
解决方案：
将hbase.bulkload.retries.number这个参数设置为更大的值，比如目标表的region数量或者将这个参数设置成0，0表示不断重试直到成功。设置之后问题解决。
⑦ 如何使用Java API操作Hbase
1. HBaseConfiguration是每一个hbase client都会使用到的对象，它代表的是HBase配置信息。它有两种构造方式：
public HBaseConfiguration()
public HBaseConfiguration(final Configuration c)
2. HBaseAdmin来创建表。HBaseAdmin负责表的META信息处理。HBaseAdmin提供了createTable这个方法：
public void createTable(HTableDescriptor desc)
3. addFamily方法增加family
public void addFamily(final HColumnDescriptor family)
4. 删除表
删除表也是通过HBaseAdmin来操作，删除表之前首先要disable表。
disableTable和deleteTable分别用来disable和delete表。
5. 查询数据
单条查询是通过rowkey在table中查询某一行的数据。HTable提供了get方法来完成单条查询。
批量查询是通过制定一段rowkey的范围来查询。HTable提供了个getScanner方法来完成批量查询。
public Result get(final Get get)
public ResultScanner getScanner(final Scan scan)
6. 插入数据 HTable通过put方法来插入数据。
public void put(final Put put) throws IOException
public void put(final List puts) throws IOException
7. 切分表
HBaseAdmin提供split方法来将table 进行split.
public void split(final String tableNameOrRegionName)
⑧ 淘宝为什么使用HBase及如何优化的
1 前言
hbase是从hadoop中 分离出来的apache顶级开源项目。由于它很好地用java实现了google的bigtable系统大部分特性，因此在数据量猛增的今天非常受到欢 迎。对于淘宝而言，随着市场规模的扩大，产品与技术的发展，业务数据量越来越大，对海量数据的高效插入和读取变得越来越重要。由于淘宝拥有也许是国内最大 的单一hadoop集群(云梯)，因此对hadoop系列的产品有比较深入的了解，也就自然希望使用hbase来做这样一种海量数据读写服务。本篇文章将 对淘宝最近一年来在online应用上使用和优化hbase的情况做一次小结。
2 原因
为什么要使用hbase？
淘宝在2011年之前所有的后端持久化存储基本上都是在mysql上进行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由于开源，并且生态系统良好，本身拥有分库分表等多种解决方案，因此很长一段时间内都满足淘宝大量业务的需求。
但是由于业务的多样化发展，有越来越多的业务系统的需求开始发生了变化。一般来说有以下几类变化：
a) 数据量变得越来越多，事实上现在淘宝几乎任何一个与用户相关的在线业务的数据量都在亿级别，每日系统调用次数从亿到百亿都有，且历史数据不能轻易删除。这需要有一个海量分布式文件系统，能对TB级甚至PB级别的数据提供在线服务
b) 数据量的增长很快且不一定能准确预计，大多数应用系统从上线起在一段时间内数据量都呈很快的上升趋势，因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求，且不希望存在单点制约
c) 只需要简单的kv读取，没有复杂的join等需求。但对系统的并发能力以及吞吐量、响应延时有非常高的需求，并且希望系统能够保持强一致性
d) 通常系统的写入非常频繁，尤其是大量系统依赖于实时的日志分析
e) 希望能够快速读取批量数据
f ) schema灵活多变，可能经常更新列属性或新增列
g) 希望能够方便使用，有良好且语义清晰的java接口
以上需求综合在一起，我们认为hbase是一种比较适合的选择。首先它的数据由hdfs天然地做了数据冗余，云梯三年的稳定运行，数据100%可靠 己经证明了hdfs集群的安全性，以及服务于海量数据的能力。其次hbase本身的数据读写服务没有单点的限制，服务能力可以随服务器的增长而线性增长， 达到几十上百台的规模。LSM-Tree模式的设计让hbase的写入性能非常良好，单次写入通常在1-3ms内即可响应完成，且性能不随数据量的增长而 下降。
region（相当于数据库的分表）可以ms级动态的切分和移动，保证了负载均衡性。由于hbase上的数据模型是按rowkey排序存储的，而读 取时会一次读取连续的整块数据做为cache，因此良好的rowkey设计可以让批量读取变得十分容易，甚至只需要1次io就能获取几十上百条用户想要的 数据。最后，淘宝大部分工程师是java背景的同学，因此hbase的api对于他们来说非常容易上手，培训成本相对较低。
当然也必须指出，在大数据量的背景下银弹是不存在的，hbase本身也有不适合的场景。比如，索引只支持主索引（或看成主组合索引），又比如服务是 单点的，单台机器宕机后在master恢复它期间它所负责的部分数据将无法服务等。这就要求在选型上需要对自己的应用系统有足够了解。
3 应用情况
我们从2011年3月开始研究hbase如何用于在线服务。尽管之前在一淘搜索中己经有了几十节点的离线服务。这是因为hbase早期版本的目标就 是一个海量数据中的离线服务。2009年9月发布的0.20.0版本是一个里程碑，online应用正式成为了hbase的目标，为此hbase引入了 zookeeper来做为backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一个里程碑，基本上我们今天 看到的各大网站，如facebook/ebay/yahoo内所使用于生产的hbase都是基于这一个版本(fb所采用的0.89版本结构与0.90.x 相近)。bloomfilter等诸多属性加入了进来，性能也有极大提升。基于此，淘宝也选用了0.90.x分支作为线上版本的基础。
第一个上线的应用是数据魔方中的prom。prom原先是基于redis构建的，因为数据量持续增大以及需求的变化，因此我们用hbase重构了它 的存储层。准确的说prom更适合0.92版本的hbase，因为它不仅需要高速的在线读写，更需要count/group by等复杂应用。但由于当时0.92版本尚未成熟，因此我们自己单独实现了coprocessor。prom的数据导入是来源于云梯，因此我们每天晚上花 半个小时将数据从云梯上写入hbase所在的hdfs，然后在web层做了一个client转发。经过一个月的数据比对，确认了速度比之redis并未有 明显下降，以及数据的准确性，因此得以顺利上线。
第二个上线的应用是TimeTunnel，TimeTunnel是一个高效的、可靠的、可扩展的实时数据传输平台，广泛应用于实时日志收集、数据实 时监控、广告效果实时反馈、数据库实时同步等领域。它与prom相比的特点是增加了在线写。动态的数据增加使hbase上compact/balance /split/recovery等诸多特性受到了极大的挑战。TT的写入量大约一天20TB，读的量约为此的1.5倍，我们为此准备了20台 regionserver的集群，当然底层的hdfs是公用的，数量更为庞大（下文会提到）。每天TT会为不同的业务在hbase上建不同的表，然后往该 表上写入数据，即使我们将region的大小上限设为1GB，最大的几个业务也会达到数千个region这样的规模，可以说每一分钟都会有数次 split。在TT的上线过程中，我们修复了hbase很多关于split方面的bug，有好几个commit到了hbase社区，同时也将社区一些最新 的patch打在了我们的版本上。split相关的bug应该说是hbase中会导致数据丢失最大的风险之一，这一点对于每个想使用hbase的开发者来 说必须牢记。hbase由于采用了LSM-Tree模型，从架构原理上来说数据几乎没有丢失的可能，但是在实际使用中不小心谨慎就有丢失风险。原因后面会 单独强调。TT在预发过程中我们分别因为Meta表损坏以及split方面的bug曾经丢失过数据，因此也单独写了meta表恢复工具，确保今后不发生类 似问题(hbase-0.90.5以后的版本都增加了类似工具)。另外，由于我们存放TT的机房并不稳定，发生过很多次宕机事故，甚至发生过假死现象。因 此我们也着手修改了一些patch，以提高宕机恢复时间，以及增强了监控的强度。
CTU以及会员中心项目是两个对在线要求比较高的项目，在这两个项目中我们特别对hbase的慢响应问题进行了研究。hbase的慢响应现在一般归 纳为四类原因：网络原因、gc问题、命中率以及client的反序列化问题。我们现在对它们做了一些解决方案(后面会有介绍)，以更好地对慢响应有控制 力。
和Facebook类似，我们也使用了hbase做为实时计算类项目的存储层。目前对内部己经上线了部分实时项目，比如实时页面点击系 统，galaxy实时交易推荐以及直播间等内部项目，用户则是散布到公司内各部门的运营小二们。与facebook的puma不同的是淘宝使用了多种方式 做实时计算层，比如galaxy是使用类似affa的actor模式处理交易数据，同时关联商品表等维度表计算排行(TopN)，而实时页面点击系统则是 基于twitter开源的storm进行开发，后台通过TT获取实时的日志数据，计算流将中间结果以及动态维表持久化到hbase上，比如我们将 rowkey设计为url+userid，并读出实时的数据，从而实现实时计算各个维度上的uv。
最后要特别提一下历史交易订单项目。这个项目实际上也是一个重构项目，目的是从以前的solr+bdb的方案上迁移到hbase上来。由于它关系到 己买到页面，用户使用频率非常高，重要程度接近核心应用，对数据丢失以及服务中断是零容忍。它对compact做了优化，避免大数据量的compact在 服务时间内发生。新增了定制的filter来实现分页查询，rowkey上对应用进行了巧妙的设计以避免了冗余数据的传输以及90%以上的读转化成了顺序 读。目前该集群存储了超过百亿的订单数据以及数千亿的索引数据，线上故障率为0。
随着业务的发展，目前我们定制的hbase集群己经应用到了线上超过二十个应用，数百台服务器上。包括淘宝首页的商品实时推荐、广泛用于卖家的实时量子统计等应用，并且还有继续增多以及向核心应用靠近的趋势。
4 部署、运维和监控
Facebook之前曾经透露过Facebook的hbase架构，可以说是非常不错的。如他们将message服务的hbase集群按用户分为数 个集群，每个集群100台服务器，拥有一台namenode以及分为5个机架，每个机架上一台zookeeper。可以说对于大数据量的服务这是一种优良 的架构。对于淘宝来说，由于数据量远没有那么大，应用也没有那么核心，因此我们采用公用hdfs以及zookeeper集群的架构。每个hdfs集群尽量 不超过100台规模（这是为了尽量限制namenode单点问题）。在其上架设数个hbase集群，每个集群一个master以及一个 backupmaster。公用hdfs的好处是可以尽量减少compact的影响，以及均摊掉硬盘的成本，因为总有集群对磁盘空间要求高，也总有集群对 磁盘空间要求低，混合在一起用从成本上是比较合算的。zookeeper集群公用，每个hbase集群在zk上分属不同的根节点。通过zk的权限机制来保 证hbase集群的相互独立。zk的公用原因则仅仅是为了运维方便。
由于是在线应用，运维和监控就变得更加重要，由于之前的经验接近0，因此很难招到专门的hbase运维人员。我们的开发团队和运维团队从一开始就很重视该问题，很早就开始自行培养。以下讲一些我们的运维和监控经验。
我们定制的hbase很重要的一部分功能就是增加监控。hbase本身可以发送ganglia监控数据，只是监控项远远不够，并且ganglia的 展示方式并不直观和突出。因此一方面我们在代码中侵入式地增加了很多监控点，比如compact/split/balance/flush队列以及各个阶 段的耗时、读写各个阶段的响应时间、读写次数、region的open/close，以及具体到表和region级别的读写次数等等。仍然将它们通过 socket的方式发送到ganglia中，ganglia会把它们记录到rrd文件中，rrd文件的特点是历史数据的精度会越来越低，因此我们自己编写 程序从rrd中读出相应的数据并持久化到其它地方，然后自己用js实现了一套监控界面，将我们关心的数据以趋势图、饼图等各种方式重点汇总和显示出来，并 且可以无精度损失地查看任意历史数据。在显示的同时会把部分非常重要的数据，如读写次数、响应时间等写入数据库，实现波动报警等自定义的报警。经过以上措 施，保证了我们总是能先于用户发现集群的问题并及时修复。我们利用redis高效的排序算法实时地将每个region的读写次数进行排序，能够在高负载的 情况下找到具体请求次数排名较高的那些region，并把它们移到空闲的regionserver上去。在高峰期我们能对上百台机器的数十万个 region进行实时排序。
为了隔离应用的影响，我们在代码层面实现了可以检查不同client过来的连接，并且切断某些client的连接，以在发生故障时，将故障隔离在某个应用内部而不扩大化。maprece的应用也会控制在低峰期运行，比如在白天我们会关闭jobtracker等。
此外，为了保障服务从结果上的可用，我们也会定期跑读写测试、建表测试、hbck等命令。hbck是一个非常有用的工具，不过要注意它也是一个很重 的工操作，因此尽量减少hbck的调用次数，尽量不要并行运行hbck服务。在0.90.4以前的hbck会有一些机率使hbase宕机。另外为了确保 hdfs的安全性，需要定期运行fsck等以检查hdfs的状态，如block的replica数量等。
我们会每天根踪所有线上服务器的日志，将错误日志全部找出来并且邮件给开发人员，以查明每一次error以上的问题原因和fix。直至错误降低为0。另外 每一次的hbck结果如果有问题也会邮件给开发人员以处理掉。尽管并不是每一次error都会引发问题，甚至大部分error都只是分布式系统中的正常现 象，但明白它们问题的原因是非常重要的。
5 测试与发布
因为是未知的系统，我们从一开始就非常注重测试。测试从一开始就分为性能测试和功能测试。性能测试主要是注意基准测试，分很多场景，比如不同混合读 写比例，不同k/v大小，不同列族数，不同命中率，是否做presharding等等。每次运行都会持续数小时以得到准确的结果。因此我们写了一套自动化 系统，从web上选择不同的场景，后台会自动将测试参数传到各台服务器上去执行。由于是测试分布式系统，因此client也必须是分布式的。
我们判断测试是否准确的依据是同一个场景跑多次，是否数据，以及运行曲线达到99%以上的重合度，这个工作非常烦琐，以至于消耗了很多时间，但后来 的事实证明它非常有意义。因为我们对它建立了100%的信任，这非常重要，比如后期我们的改进哪怕只提高2%的性能也能被准确捕捉到，又比如某次代码修改 使compact队列曲线有了一些起伏而被我们看到，从而找出了程序的bug，等等。
功能测试上则主要是接口测试和异常测试。接口测试一般作用不是很明显，因为hbase本身的单元测试己经使这部分被覆盖到了。但异常测试非常重要， 我们绝大部分bug修改都是在异常测试中发现的，这帮助我们去掉了很多生产环境中可能存在的不稳定因素，我们也提交了十几个相应的patch到社区，并受 到了重视和commit。分布式系统设计的难点和复杂度都在异常处理上，我们必须认为系统在通讯的任何时候都是不可靠的。某些难以复现的问题我们会通过查 看代码大体定位到问题以后，在代码层面强行抛出异常来复现它。事实证明这非常有用。
为了方便和快速定位问题，我们设计了一套日志收集和处理的程序，以方便地从每台服务器上抓取相应的日志并按一定规律汇总。这非常重要，避免浪费大量的时间到登录不同的服务器以寻找一个bug的线索。
由于hbase社区在不停发展，以及线上或测试环境发现的新的bug，我们需要制定一套有规律的发布模式。它既要避免频繁的发布引起的不稳定，又要 避免长期不发布导致生产版本离开发版本越来越远或是隐藏的bug爆发。我们强行规定每两周从内部trunk上release一个版本，该版本必须通过所有 的测试包括回归测试，并且在release后在一个小型的集群上24小时不受甘扰不停地运行。每个月会有一次发布，发布时采用最新release的版本， 并且将现有的集群按重要性分级发布，以确保重要应用不受新版本的潜在bug影响。事实证明自从我们引入这套发布机制后，由发布带来的不稳定因素大大下降 了，并且线上版本也能保持不落后太多。
6 改进和优化
Facebook是一家非常值得尊敬的公司，他们毫无保留地对外公布了对hbase的所有改造，并且将他们内部实际使用的版本开源到了社区。 facebook线上应用的一个重要特点是他们关闭了split，以降低split带来的风险。与facebook不同，淘宝的业务数据量相对没有如此庞 大，并且由于应用类型非常丰富，我们并们并没有要求用户强行选择关闭split，而是尽量去修改split中可能存在的bug。到目前为止，虽然我们并不 能说完全解决了这个问题，但是从0.90.2中暴露出来的诸多跟split以及宕机相关的可能引发的bug我们的测试环境上己经被修复到接近了0，也为社 区提交了10数个稳定性相关的patch，比较重要的有以下几个：
https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899
还有其它一些，我们主要将patch提交到0.92版本，社区会有commitor帮助我们backport回0.90版本。所以社区从 0.90.2一直到0.90.6一共发布了5个bugfix版本后，0.90.6版本其实己经比较稳定了。建议生产环境可以考虑这个版本。
split这是一个很重的事务，它有一个严重的问题就是会修改meta表（当然宕机恢复时也有这个问题）。如果在此期间发生异常，很有可能meta 表、rs内存、master内存以及hdfs上的文件会发生不一致，导致之后region重新分配时发生错误。其中一个错误就是有可能同一个region 被两个以上的regionserver所服务，那么就可能出现这一个region所服务的数据会随机分别写到多台rs上，读取的时候也会分别读取，导致数 据丢失。想要恢复原状，必须删除掉其中一个rs上的region，这就导致了不得不主动删掉数据，从而引发数据丢失。
前面说到慢响应的问题归纳为网络原因、gc问题、命中率以及client的反序列化问题。网络原因一般是网络不稳定引起的，不过也有可能是tcp参 数设置问题，必须保证尽量减少包的延迟，如nodelay需要设置为true等，这些问题我们通过tcpmp等一系列工具专门定位过，证明tcp参数 对包的组装确实会造成慢连接。gc要根据应用的类型来，一般在读比较多的应用中新生代不能设置得太小。命中率极大影响了响应的时间，我们会尽量将 version数设为1以增加缓存的容量，良好的balance也能帮助充分应用好每台机器的命中率。我们为此设计了表级别的balance。
由于hbase服务是单点的，即宕机一台，则该台机器所服务的数据在恢复前是无法读写的。宕机恢复速度决定了我们服务的可用率。为此主要做了几点优 化。首先是将zk的宕机发现时间尽量缩短到1分钟，其次改进了master恢复日志为并行恢复，大大提高了master恢复日志的速度，然后我们修改了 openhandler中可能出现的一些超时异常，以及死锁，去掉了日志中可能发生的open…too long等异常。原生的hbase在宕机恢复时有可能发生10几分钟甚至半小时无法重启的问题己经被修复掉了。另外，hdfs层面我们将 socket.timeout时间以及重试时间也缩短了，以降低datanode宕机引起的长时间block现象。
hbase本身读写层面的优化我们目前并没有做太多的工作，唯一打的patch是region增加时写性能严重下降的问题。因为由于hbase本身 良好的性能，我们通过大量测试找到了各种应用场景中比较优良的参数并应用于生产环境后，都基本满足需求。不过这是我们接下来的重要工作。
7 将来计划
我们目前维护着淘宝内基于社区0.90.x而定制的hbase版本。接下来除继续fix它的bug外，会维护基于0.92.x修改的版本。之所以这 样，是因为0.92.x和0.90.x的兼容性并不是非常好，而且0.92.x修改掉的代码非常多，粗略统计会超过30%。0.92中有我们非常看重的一 些特性。
0.92版本改进了hfile为hfileV2，v2版本的特点是将索引以及bloomfilter进行了大幅改造，以支持单个大hfile文 件。现有的HFile在文件大到一定程度时，index会占用大量的内存，并且加载文件的速度会因此下降非常多。而如果HFile不增大的 话，region就无法扩大，从而导致region数量非常多。这是我们想尽量避免的事。
0.92版本改进了通讯层协议，在通讯层中增加了length，这非常重要，它让我们可以写出nio的客户端，使反序列化不再成为影响client性能的地方。
0.92版本增加了coprocessor特性，这支持了少量想要在rs上进行count等的应用。
还有其它很多优化，比如改进了balance算法、改进了compact算法、改进了scan算法、compact变为CF级别、动态做ddl等等特性。
除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不错的特性，0.94是一个性能优化版本。它做了很多革命性工作，比如去掉root表，比如HLog进行压缩，replication上支持多个slave集群，等等。
我们自己也有一些优化，比如自行实现的二级索引、backup策略等都会在内部版本上实现。
另外值得一提的是hdfs层面的优化也非常重要，hadoop-1.0.0以及cloudera-3u3的改进对hbase非常有帮助，比如本地化 读、checksum的改进、datanode的keepalive设置、namenode的HA策略等。我们有一支优秀的hdfs团队来支持我们的 hdfs层面工作，比如定位以及fix一些hdfs层面的bug,帮助提供一些hdfs上参数的建议，以及帮助实现namenode的HA等。最新的测试 表明，3u3的checksum+本地化读可以将随机读性能提升至少一倍。
我们正在做的一件有意义的事是实时监控和调整regionserver的负载，能够动态地将负载不足的集群上的服务器挪到负载较高的集群中，而整个过程对用户完全透明。
总的来说，我们的策略是尽量和社区合作，以推动hbase在整个apache生态链以及业界的发展，使其能更稳定地部署到更多的应用中去，以降低使用门槛以及使用成本。
⑨ hbase启动为什么要做log split
HBase为了提高写的性能，将数据的修改先放到memstore内存中，这样做的缺陷是当某个region server崩溃时，其memstore中的所有修改将会丢失，因为它们还没有被刷写到磁盘上。为了防止这情况造成的数据丢失，HBase的做法是在修改写入memstore之前，先将其写入一个称为"预写日志"（write-ahead-log，WAL）文件中。这样在遇到一个region server崩溃后，可以通过回放（replay）WAL文件重新生成memstore中丢失的修改。
由于一个region server上会有多个region，并且这些region共享一个WAL文件。WAL文件中的每个修改（也叫做edit）都包含其属于哪一个region的信息。当打开一个region时，将会replay这个region在WAL中的所有edits记录，来重新生成数据。所以，在WAL文件中的所有edit都必须按region分组形成特定的集合，通过replay这些集合来对特定的region重新生成数据。像这样在WAL文件中对edit 按region分组的过程就称为Log Split。
日志拆分（Log Split）发生在集群启动时（由HMaster负责完成）或是在region server崩溃时（由ServerShutdownHandler负责完成），因为HBase需要保持一致性。在日志拆分时，受影响的region将不可用，直到拆分完成，数据完全重置。
⑩ hbase0.96meta表还需要split吗
理论上没有上限，因为个人觉得有两个因素会影响Hbase的表个数：内存，硬盘，这个很显然-ROOT-表访问限制，因为当表很多时，META.表就会很大，会发生切分，相应的-ROOT-就会变大，但是由于.META.的缓冲，对-ROOT-的影响不会很明显综上，理论上来说HBase的表个数没有限制，但是表增多必然会导致响应效率降低