这篇文章浅显的从几个方面谈谈HBase的一些优化技巧，只能作为我学习笔记的一部分，因为学多了怕忘，留给自己以后看看。
1 修改 linux 系统参数
Linux系统最大可打开文件数一般默认的参数值是1024,如果你不进行修改并发量上来的时候会出现“Too Many Open Files”的错误，导致整个HBase不可运行，你可以用ulimit -n 命令进行修改，或者修改/etc/security/limits.conf 和/proc/sys/fs/file-max 的参数，具体如何修改可以去Google 关键字 “linux limits.conf ”
2 JVM 配置
修改 hbase-env.sh 文件中的配置参数，根据你的机器硬件和当前操作系统的JVM(32/64位)配置适当的参数
HBASE_HEAPSIZE 4000 HBase使用的 JVM 堆的大小
HBASE_OPTS "‐server ‐XX:+UseConcMarkSweepGC"JVM GC 选项
HBASE_MANAGES_ZKfalse 是否使用Zookeeper进行分布式管理
3 HBase持久化
重启操作系统后HBase中数据全无，你可以不做任何修改的情况下，创建一张表，写一条数据进行，然后将机器重启，重启后你再进入HBase的shell中使用 list 命令查看当前所存在的表，一个都没有了。是不是很杯具？没有关系你可以在hbase/conf/hbase-default.xml中设置hbase.rootdir的值，来设置文件的保存位置指定一个文件夹 ，例如：<value>file:///you/hbase-data/path</value>，你建立的HBase中的表和数据就直接写到了你的磁盘上，如图所示：
同样你也可以指定你的分布式文件系统HDFS的路径例如: hdfs://NAMENODE_SERVER:PORT/HBASE_ROOTDIR，这样就写到了你的分布式文件系统上了。
4 配置HBase运行参数
其次就需要对hbase/conf/hbase-default.xml 文件进行配置，以下是我认为比较重要的配置参数
hbase.client.write.buffer
描述：这个参数可以设置写入数据缓冲区的大小，当客户端和服务器端传输数据，服务器为了提高系统运行性能开辟一个写的缓冲区来处理它， 这个参数设置如果设置的大了，将会对系统的内存有一定的要求，直接影响系统的性能。
hbase.master.meta.thread.rescanfrequency
描述：多长时间 HMaster对系统表 root 和 meta 扫描一次，这个参数可以设置的长一些，降低系统的能耗。
hbase.regionserver.handler.count
描述：由于HBase/Hadoop的Server是采用Multiplexed, non-blocking I/O方式而设计的，所以它可以透过一个Thread来完成处理，但是由于处理Client端所呼叫的方法是Blocking I/O，所以它的设计会将Client所传递过来的物件先放置在Queue，并在启动Server时就先产生一堆Handler(Thread)，该Handler会透过Polling的方式来取得该物件并执行对应的方法，默认为25，根据实际场景可以设置大一些。
hbase.regionserver.thread.splitcompactcheckfrequency
描述：这个参数是表示多久去RegionServer服务器运行一次split/compaction的时间间隔，当然split之前会先进行一个compact操作.这个compact操作可能是minor compact也可能是major compact.compact后,会从所有的Store下的所有StoreFile文件最大的那个取midkey.这个midkey可能并不处于全部数据的mid中.一个row-key的下面的数据可能会跨不同的HRegion。
hbase.hregion.max.filesize
描述：HRegion中的HStoreFile最大值，任何表中的列族一旦超过这个大小将会被切分，而HStroeFile的默认大小是256M。
hfile.block.cache.size
描述：指定 HFile/StoreFile 缓存在JVM堆中分配的百分比，默认值是0.2，意思就是20%，而如果你设置成0，就表示对该选项屏蔽。
hbase.zookeeper.property.maxClientCnxns
描述： 这项配置的选项就是从zookeeper中来的，表示ZooKeeper客户端同时访问的并发连接数，ZooKeeper对于HBase来说就是一个入口这个参数的值可以适当放大些。
hbase.regionserver.global.memstore.upperLimit
描述：在Region Server中所有memstores占用堆的大小参数配置，默认值是0.4，表示40%，如果设置为0，就是对选项进行屏蔽。
hbase.hregion.memstore.flush.size
描述：Memstore中缓存的内容超过配置的范围后将会写到磁盘上，例如：删除操作是先写入MemStore里做个标记，指示那个value, column 或 family等下是要删除的，HBase会定期对存储文件做一个major compaction，在那时HBase会把MemStore刷入一个新的HFile存储文件中。如果在一定时间范围内没有做major compaction，而Memstore中超出的范围就写入磁盘上了。
5 HBase中log4j的日志
HBase中日志输出等级默认状态下是把debug、 info 级别的日志打开的，可以根据自己的需要调整log级别，HBase的log4j日志配置文件在 hbase\conf\log4j.properties 目录下。
4–存储
在HBase中创建的一张表可以分布在多个Hregion，也就说一张表可以被拆分成多块，每一块称我们呼为一个Hregion。每个Hregion会保 存一个表里面某段连续的数据，用户创建的那个大表中的每个Hregion块是由Hregion服务器提供维护，访问Hregion块是要通过 Hregion服务器，而一个Hregion块对应一个Hregion服务器，一张完整的表可以保存在多个Hregion 上。HRegion Server 与Region的对应关系是一对多的关系。每一个HRegion在物理上会被分为三个部分：Hmemcache(缓存)、Hlog(日志)、HStore(持久层)。
上述这些关系在我脑海中的样子，如图所示：
1.HRegionServer、HRegion、Hmemcache、Hlog、HStore之间的关系，如图所示：
2.HBase表中的数据与HRegionServer的分布关系，如图所示：
HBase读数据
HBase读取数据优先读取HMemcache中的内容，如果未取到再去读取Hstore中的数据，提高数据读取的性能。
HBase写数据
HBase写入数据会写到HMemcache和Hlog中，HMemcache建立缓存，Hlog同步Hmemcache和Hstore的事务日志，发起Flush Cache时，数据持久化到Hstore中，并清空HMemecache。
客户端访问这些数据的时候通过Hmaster ，每个 Hregion 服务器都会和Hmaster 服务器保持一个长连接，Hmaster 是HBase分布式系统中的管理者，他的主要任务就是要告诉每个Hregion 服务器它要维护哪些Hregion。用户的这些都数据可以保存在Hadoop 分布式文件系统上。 如果主服务器Hmaster死机，那么整个系统都会无效。下面我会考虑如何解决Hmaster的SPFO的问题，这个问题有点类似Hadoop的SPFO 问题一样只有一个NameNode维护全局的DataNode，HDFS一旦死机全部挂了，也有人说采用Heartbeat来解决这个问题，但我总想找出
其他的解决方案，多点时间，总有办法的。
昨天在hadoop-0.21.0、hbase-0.20.6的环境中折腾了很久，一直报错，错误信息如下：
Exception in thread "main" java.io.IOException: Call to localhost/serv6:9000 failed on local exception:
java.io.EOFException
10/11/10 15:34:34 ERROR master.HMaster: Can not start master
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.hadoop.hbase.master.HMaster.doMain(HMaster.java:1233)
at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:1274)
|
死活连接不上HDFS，也无法连接HMaster，郁闷啊。
我想想啊，慢慢想，我眼前一亮 java.io.EOFException 这个异常，是不是有可能是RPC 协定格式不一致导致的？也就是说服务器端和客户端的版本不一致的问题？换了一个HDFS的服务器端以后，一切都好了，果然是版本的问题，最后采用 hadoop-0.20.2 搭配hbase-0.20.6 比较稳当。
最后的效果如图所示：
上图的一些文字说明：
- hadoop版本是0.20.2 ,
- hbase版本是0.20.6,
- 在hbase中创建了一张表 tab1，退出hbase shell环境,
- 用hadoop命令查看，文件系统中的文件果然多了一个刚刚创建的tab1目录,以上这张图片说明HBase在分布式文件系统Apache HDFS中运行了。
5(集群) -压力分载与失效转发
在上一篇关于HBase的文章中曾经讲述过HBase在分布式中的架构，这篇文章将会讲述HBase在分布式环境中是如何排除单点故障的(SPFO)，做一个小实验讲述HBase在分布式环境中的高可用性，亲眼看到一些现象，延伸一些思考的话题。
先来回顾一下HBase主要部件：
- HBaseMaster
- HRegionServer
- HBase Client
- HBase Thrift Server
- HBase REST Server
HBaseMaster
HMaster 负责给HRegionServer分配区域,并且负责对集群环境中的HReginServer进行负载均衡，HMaster还负责监控集群环境中的HReginServer的运行状况，如果某一台HReginServer down机，HBaseMaster将会把不可用的HReginServer来提供服务的HLog和表进行重新分配转交给其他HReginServer来提供，HBaseMaster还负责对数据和表进行管理，处理表结构和表中数据的变更，因为在 META 系统表中存储了所有的相关表信息。并且HMaster实现了ZooKeeper的Watcher接口可以和zookeeper集群交互。
HRegionServer
HReginServer负责处理用户的读和写的操作。HReginServer通过与HBaseMaster通信获取自己需要服务的数据表，并向HMaster反馈自己的运行状况。当一个写的请求到来的时候，它首先会写到一个叫做HLog的write-ahead log中。HLog被缓存在内存中，称为Memcache，每一个HStore只能有一个Memcache。当Memcache到达配置的大小以后，将会创建一个MapFile，将其写到磁盘中去。这将减少HReginServer的内存压力。当一起读取的请求到来的时候，HReginServer会先在Memcache中寻找该数据，当找不到的时候，才会去在MapFiles
中寻找。
HBase Client
HBase Client负责寻找提供需求数据的HReginServer。在这个过程中，HBase Client将首先与HMaster通信，找到ROOT区域。这个操作是Client和Master之间仅有的通信操作。一旦ROOT区域被找到以后，Client就可以通过扫描ROOT区域找到相应的META区域去定位实际提供数据的HReginServer。当定位到提供数据的HReginServer以后，Client就可以通过这个HReginServer找到需要的数据了。这些信息将会被Client缓存起来，当下次请求的时候，就不需要走上面的这个流程了。
HBase服务接口
HBase Thrift Server和HBase REST Server是通过非Java程序对HBase进行访问的一种途径。
进入正题
先来看一个HBase集群的模拟环境，此环境中一共有4台机器，分别包含 zookeeper、HBaseMaster、HReginServer、HDSF 4个服务，为了展示失效转发的效果HBaseMaster、HReginServer各有2台，只是在一台机器上即运行了HBaseMaster，也运行了HReginServer。
注意，HBase的集群环境中HBaseMaster只有失效转发没有压力分载的功能，而HReginServer即提供失效转发也提供压力分载。
服务器清单如下：
- zookeeper 192.168.20.214
- HBaseMaster 192.168.20.213/192.168.20.215
- HReginServer 192.168.20.213/192.168.20.215
- HDSF 192.168.20.212
整个模拟环境的架构如图所示：
注意，这里只是做了一个模拟环境，因为这个环境的重点是HBase，所以zookeeper和HDFS服务都是单台。
虽然说在整个HBase的集群环境中只能有一个HMaster，可是在集群环境中HMaster可以启动多个，但真正使用到的HMaster Server只有一个，他不down掉的时候，其他启动的HMaster Server并不会工作，直到与ZooKeeper服务器判断与当前运行的HMaster通讯超时，认为这个正在运行的HMaster服务器down掉了，Zookeeper才会去连接下一台HMaster Server。
简单来说,如果运行中HMaster服务器down掉了，那么zookeeper会从列表中选择下一个HMaster 服务器进行访问，让他接管down掉的HMaster任务，换而言之，用Java客户端对HBase进行操作是通过ZooKeeper的，也就是说如果zookeeper集群中的节点全挂了 那么HBase的集群也挂了。本身HBase并不存储中的任何数据 真正的数据是保存在HDFS上，所以HBase的数据是一致的，但是HDFS文件系统挂了，HBase的集群也挂。
在一台HMaster失败后，客户端对HBase集群环境访问时，客户端先会通过zookeeper识别到HMaster运行异常，直到确认多次后，才连接到下一个HMaster，此时，备份的HMaster服务才生效，在IDE环境中的效果，如图所示：
上图中能看见抛出的一些异常和name:javahttp://www.javabloger.com和name:javahttp://www.javabloger.com1的结果集，因为我在serv215机器上用killall java命令把 HMaster和HReginServer都关掉，并且立刻用Java客户端对HBase的集群环境进行访问有异常抛出，但是retry到一定次数后查询出结果，前面已经说了访问HBase是通过zookeeper再和真正的数据打交道，也就是说zookeeper接管了一个standby
的 HMaster，让原先Standby的HMaster接替了失效的HMaster任务，而被接管的HBaseMaster再对HReginServer的任务进行分配，当 HReginServer失败后zookeeper会通知 HMaster对HReginServer的任务进行分配。这样充分的说明了HBase做到了实效转发的功能。
如图所示：
口水：
1、HBase的失效转发的效率比较慢了，不指望能在1-2秒切换和恢复完毕，也许是我暂时没有发现有什么参数可以提高失效转发和恢复过程的速度，将来会继续关注这个问题。
2、在官方网站上看见HBase0.89.20100924的版本有篇讲述关于数据同步的文章，我尝试了一下在一台机器上可以运行所谓的HBase虚拟集群环境，但是切换到多台机器的分布式环境中，单点失效转发的速度很慢比HBase0.20.6还要慢，我又检查了是否存在网络的问题，目前尚未找到正确的答案，对与HBase0.89.20100924 新版中的数据同步的原理，如图所示：(更多信息)
转载出处：http://blog.csdn.net/frankiewang008/article/details/41965543