一，基本命令：
建表：create 'testtable','coulmn1','coulmn2'
也可以建表时加coulmn的属性如：create 'testtable',{NAME => 'coulmn1', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0',
VERSIONS => '10', COMPRESSION => 'LZO', TTL => '30000', IN_MEMORY => 'false', BLOCKCACHE => 'false'}, {NAME => 'coulmn', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '30', COMPRESSION => 'LZO', TTL => '30000', IN_MEMORY => 'true'} (其中的属性有versions：设置历史版本数，TTL：过期时间，COMPRESSION：压缩方式，当配置lzo的情况)
删除表：drop 'testtable' （删除表之前先要禁用表，命令disable 'testtable'）
启用和禁用表： enable 'testtable' 和disable 'testtable'
其它的基本命令：describe 'testtable'（查看表结构），alert 修改表结构，list 列出所有表。
二，日常维护的命令
1，major_compact 'testtable'，通常生产环境会关闭自动major_compact(配置文件中hbase.hregion.majorcompaction设为0)，选择一个晚上用户少的时间窗口手工major_compact，如果hbase更新不是太频繁，可以一个星期对所有表做一次major_compact，这个可以在做完一次major_compact后，观看所有的storefile数量，如果storefile数量增加到major_compact后的storefile的近二倍时，可以对所有表做一次major_compact，时间比较长，操作尽量避免高锋期。
2，flush 'testtable'，将所有memstore刷新到hdfs，通常如果发现regionserver的内存使用过大，造成该机的regionserver很多线程block，可以执行一下flush操作，这个操作会造成hbase的storefile数量剧增，应尽量避免这个操作，还有一种情况，在hbase进行迁移的时候，如果选择拷贝文件方式，可以先停写入，然后flush所有表，拷贝文件。
3，balance_switch true或者balance_switch flase，配置master是否执行平衡各个regionserver的region数量，当我们需要维护或者重启一个regionserver时，会关闭balancer，这样就使得region在regionserver上的分布不均，这个时候需要手工的开启balance。
三，重启一个regionserver
bin/graceful_stop.sh --restart --reload --debug nodename
这个操作是平滑的重启regionserver进程，对服务不会有影响，他会先将需要重启的regionserver上面的所有region迁移到其它的服务器，然后重启，最后又会将之前的region迁移回来，但我们修改一个配置时，可以用这种方式重启每一台机子，这个命令会关闭balancer，所以最后我们要在hbase
shell里面执行一下balance_switch true，对于hbase regionserver重启，不要直接kill进程，这样会造成在zookeeper.session.timeout这个时间长的中断，也不要通过bin/hbase-daemon.sh stop regionserver去重启，如果运气不太好，-ROOT-或者.META.表在上面的话，所有的请求会全部失败。
四，关闭下线一台regionserver
bin/graceful_stop.sh --stop nodename
和上面一样，系统会在关闭之前迁移所有region，然后stop进程，同样最后我们要手工balance_switch true，开启master的region均衡。
五，检查region是否正常以及修复
bin/hbase hbck (检查)
bin/hbase hbck -fix （修复）
会返回所有的region是否正常挂载，如没有正常挂载可以使用下一条命令修复，如果还是不能修复，那需要看日志为什么失败，手工处理。
六，hbase的迁移
1，copytable方式
bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=zookeeper1,zookeeper2,zookeeper3:/hbase
'testtable'
目前0.92之前的版本的不支持多版本的复制，0.94已经支持多个版本的复制。当然这个操作需要添加hbase目录里的conf/mapred-site.xml，可以复制hadoop的过来。
2，Export/Import
bin/hbase org.apache.hadoop.hbase.mapreduce.Export testtable /user/testtable [versions] [starttime] [stoptime]
bin/hbase org.apache.hadoop.hbase.mapreduce.Import testtable /user/testtable
跨版本的迁移，我觉得是一个不错的选择，而且copytable不支持多版本，而export支持多版本，比copytable更实用一些。
3，直接拷贝hdfs对应的文件
首先拷贝hdfs文件，如bin/hadoop distcp hdfs://srcnamenode:9000/hbase/testtable/ hdfs://distnamenode:9000/hbase/testtable/
然后在目的hbase上执行bin/hbase org.jruby.Main bin/add_table.rb /hbase/testtable
生成meta信息后，重启hbase
这个操作是简单的方式，操作之前可以关闭hbase的写入，执行flush所有表（上面有介绍）,再distcp拷贝，如果hadoop版本不一致，可以用hftp接口的方式，我推荐使用这种方式，成本低。
先总结这么多，有空我再详细写一下region坏时怎么修复。
hbase参数配置及优化
via: http://my.oschina.net/beiyou/blog/76259
接触hbase已有半年的时间，查了很多资料，也参考了很多别人心得，也希望把自己的心得以及理解写出来，我把配置hbase必调的几个参数写一下，以及它们的意义。
zookeeper.session.timeout
这个参数的意义是regionserver在zookeeper的会话过期时间，默认是3分钟，如果regionserver 在zookeeper.session.timeout这个配置的时间没有去连zookeeper的话，zookeeper会将该regionserver在zookeeper摘除，不让该regionserver向提供服务，很多人都该值配置很大，原因是生产环境中regionserver的内存都配置很大，以扩大memstore和cache的大小，提高性能，但是内存配置大了以后，regionserver在jvm做一次内存大回收时，时间也会变长，很有可能这个时间超过zookeeper.session.timeout时间，导致regionserver在jvm回收内存的时候，zookeeper误以为regionserver挂掉而将regionserver摘除。但我认为该值还是不要配的过大，首先地java已支持cms方式回收内存，每次内存回收的时间不是太长，并且生产环境中，我们也不允许过长时间的服务中断，配置大了，容易造成一个regionserver的服务真出现异常时，zookeeper不会切除该regionserver，使得很多请求失败。
hbase.regionserver.handler.count
regionserver的工作线程数量，默认是10，没有疑问，官方默认值太小，通常都调到100~200之间，提高regionserver性能。
hbase.regionserver.lease.period
regionserer租约时间，默认值是60s，也有点小，如果你的生产环境中，在执行一些任务时，如mapred时出现lease超时的报错，那这个时候就需要去调大这个值了。
hfile.block.cache.size
regionserver cache的大小，默认是0.2，是整个堆内存的多少比例作为regionserver的cache，调大该值会提升查询性能，当然也不能过大，如果你的hbase都大量的查询，写入不是很多的话，调到0.5也就够了，说到这个值，有一个地方需要说明一下，如果生产环境有mapred任务去scan
hbase的时候，一些要在mapred scan类中加一个scan.setCacheBlocks(false)，避免由于mapred使用regionserver的cache都被替换，造成hbase的查询性能明显下降。
hbase.hregion.memstore.flush.size
一个regionserver的单个region memstore的大小，默认是64M，在hbase结构中,一个regionserver管理多个region，一个region对应一个hlog和多个store，一个store对应多个storefile和一个memstore，这里的hbase.hregion.memstore.flush.size意思一个region下面的所有store里面的memstore的达到多少时，开始将这些memstore
flush到hdfs中去，配置这个值，需要参考一下，平均每个regionserver管理的region数量，如果每台regionsever管理的region不多的话，可以适当的调大该值，如512M时再flush。
hbase.regionserver.global.memstore.upperLimit/hbase.regionserver.global.memstore.lowerLimit
配置一台regionserver所有memstore占整个堆的最大比例，默认是0.4/0.35，二个值的差异在于是做局部的flush，还是全部flush，如果你的regionserver日志中，频发出现因为超过hbase.regionserver.global.memstore.lowerLimit而做flush的信息，我觉得有必要调小hbase.hregion.memstore.flush.size，或者适当调大这二个值，当然hbase.regionserver.global.memstore.upperLimit和hfile.block.cache.size的和不能大于1，到0.8我觉得已经够大了。如果你的jvm内存回收是使用cms的话，有一个值CMSInitiatingOccupancyFraction（内存使用到时多少时，一始cms回收内存）的大小和觉得和这个有关系，略小于hbase.regionserver.global.memstore.upperLimit和hfile.block.cache.size的和是一个不错的选择。
hbase.hstore.compactionThreshold/hbase.hregion.majorcompaction
hbase.hstore.compactionThreshold执行compaction的store数量，默认值是3，如果需要提高查询性能，当然是storefile的数量越小，性能越好，但是执行compaction本身有性能资源的开消，如果regionserver频繁在compacion对性能影响也很大。hbase.hregion.majorcompaction表示majorcompaction的周期，默认是1天，majorcompaction与普通的compaction的区别是majorcompaction会清除过期的历史版本数据，同时合并storefile，而普通的compaction只做合并，通常都是majorcompaction，调为0，然后手工定期的去执行一下majorcompaction，适当调小点compacionThreshold。
hbase.hregion.max.filesize
一个regionsever的最大值，默认是256M，如果数据量特别大的话，调大该值可以减少region的数量，调到2G我觉得都不为过。
hbase配置调优太多，jvm，mslab内存管理以及hdfs append方式等等，需要太多的知识面，很多东西，我也在学习之中，先写这么多。