文章标题

HBase的衍生

HBase的产生：
HBase的使用场景：当使用随机的读写数据，实时分析数据的时候，收集大量的表，数据的行和列是非常多的
Mysql，Oracle数据库满足不了数据存储的要求时候，数据量大的时候，一个sql语句根本就是查询不出来的额，直接夯住的，数据量大的时候，检索非常长的时间的额
HBase的存储模式跟关系型的数据库的存储模式是不一样的额，属于列式存储的
Mysql,Oracle关系型数据库是行式存储的，一行数据存储所有的字段的额，一行一个主键，为null的数值也会存储的，
当一个表存储了大量的数据量的时候，想要对表进行更改的时候，是非常困难的， 加减列的情况是非常困难的，
HBase中是通过rowKey和列族来定义表的数据信息的，表中的rowKey是唯一的，HBase中是不存储NULL的数据的
HBase的数据模型的：
RowKey+TimeStamp+CF
其中的RowKey是唯一的，作为主键，一条数据通过RowKey识别的，唯一识别的，尽管数据里面会有多个TimeStamp时间戳的额
存储非结构化的数据，任何的数据转化成Byte类型的都可以存储进来的，可以存储string,numbers,complex objects,even images
as long as they can rendered as bytes.
HBase支持bytes-in和bytes-out
大屏的实时的显示效果都是从HBase中去拿的，不是去从Mysql，Redis等数据库中拿的
HBase的存储和实时处理的情况下是非常有地位的额，

Redis和HBase是一种弥补性质的关系的，Redis是基于内存的额,HBase的底层是基于HDFS的，
Redis是基于内存的，查询速度是非常快的但是不能作为大数据的存储的额，Redis适用于简单的批量的数据的处理，快速的读写的一种方式，临时性的缓存的方式 memcache简单，类型单一的，内存空间是非常小的，Redis存储的类型也多了，支持主从复制的，

HBase与关系型的数据库的区别在于就是数据类型有区别的，数据操作上有区别的，HBase对于新增的数据基本上都是录入的没有update的操作的，update只修改表的命名空间，每增加一个数据操作的时候都是新增一个新的版本的，用版本控制的额，

Mysql cpu不够增加配置的，主从复制的时候，若主机要增加配置则从机也会要增加相同的配置的，否则跟不上主机的处理速度的，当数据量大的时候，添加硬件的配置的成本是好几倍的额，

HBase是分布式的，伸缩性扩展性是非常方便的额，HBase也是CDH的 ，维护性和操作性方便的，版本的兼容性的不用考虑的额，

archive.cloudera.com/cdh5

对于Apache提供的hbase的src包的源码包可以根据指定文档指定的环境进行重新编译的额

Client请求Zookeeper，Zookeeper请求HMaster，HMaster找HRegionServer，再去找DataNode的，
HBase的元数据是在Zookeeper之上的，由Zookeeper进行管理元数据信息的

进入hbase shell客户端：
list
help
hbase shell中创建一张表是非常麻烦的
create ‘ns1:t1’,’f1’,SPLITS =>[‘10’,’20’,’30’,’40’ ]
表的命名空间，列族，Splits指的是表的预分区，
create ‘test1’,’cf’ 创建一个表的时候，必须指定表名和列族的，
list
describe ‘test1’
list_namespace_tables ‘default’
list_namespacce_tables ‘ns1’
list_namespace
create_namespace ‘ns1’
create ‘ns1:test1’ ,’cf’
drop_namespace ‘ns1’
alter_namespace ‘ns1’ ,{METHOD=>’set’,’PROPERTY_NAME’=>’PROPERTY_VALUE’}
scan ‘test’ 全表的扫描 区间的扫描
scan ‘表名’ ‘rowkey’ ‘cf’
get ‘表名’ ‘rowkey’ ‘cf’
list_namespace

HBase的最小的单元是cell，通过RowKey+CF+列名来确定唯一的一个单元的，
TimeStamp是每个cell保存同一份数据的多个版本的，通过时间戳来确定版本的，64位整形的数字，系统默认生成的时间戳，

HBase是部署在HDFS上的，Zookeeper为了选举操作设置了奇数台机器的，hbase-site.xml核心的配置文件的，regionservers文件
HBase启动之后的UI界面的，60010默认的端口的
HBase中的数据是通过RowKey来进行的唯一的确定的，
HBase
RowKey CF:COL TIMESTAMP VERSION
HBase Shell检索数据方式：
get RowKey
get RowKey range
scan RowKey
RowKey的优化的额，
TimeStamp的确定的
version多个的

在HBase中删除表，必须要先disable的，disable ‘ns1test1’
在进行drop ‘ns1test1’
scan ‘test’,{LIMIT => 2}只拿俩条数据的，LIMIT必须是大写的
exists ‘test’
put ‘test’ ,’row1’,’cf’,’zhangsan’
scan ‘test’
truncate ‘test’ 删除数据的
describe_namespace ‘ns1’

DBeaver进行连接HBase的操作的额，通过Phoenix的方式来进行操作HBase的
drop table JYDW.DIM_GOODS
selecet count(1) from JYDW.DIM_GOODS;
create table if not exists JYDW.DIM_GOODS(goods_id varchar(32) not null primary key ,goods_name varchar(256),cat_name_1 varchar(128),cat_name_2 varchar(128),netweight decimal(16,4),grossweight decimal(16,4),length decimal(16,4),width decimal(16,4),volume decimal(16,,4),price decimal(16,4),is_hot tinyint (1),is_gift tinyint (1)) salt_buckets=6,compression=’snappy’;
salt_buckets是的rowKey的开闭合区间的额，分桶的，rowkey有12条的话，则1-2在一个区间内的，3-4在一个区间内的，通过rowkey所在的区间进行查找的，startKey endKey来进行表示的

REST API的方式进行迁移数据的，REST API的方式进行处理HBase中的数据

HBase体系架构：
Client
Zookeeper
Master
RegionServer
memStore
StoreFile
HFile====HDFS上的block的关系是
HLog

HBase自带的监控JMX，有CDH监控的话就需要JMX的管理的啊，
HBase中的字母区分大小写的，

get_counter ‘test’,’row1’,’cf:a’

HBase的数据结构：
RowKey cf col timestamp version
cell

CDH HBase1.2.0的版本

import  org.apache.hadoop.conf.Configuration;import  org.apache.hadoop.hbase.*;import  org.apache.hadoop.hbase.client.*;import  org.apache.hadoop.hbase.util.Bytes;import  java.io.IOException;public   class  HBaseApiTest{    static  Configuration  conf;    static  Connection  conn;    static  Admin  admin;    //初始化连接    public  static   void  init(){       conf=HBaseConfiguration.create();       conf.set("hbase.zookeeper.quorum","haoop000");       conf.set("hbase.zookeeper.property.clientPort","2181");       conf.set("hbase.rootdir","hdfs://hadoop000:8020/hbase");try{conn=ConnectionFactory.createConnection(conf);admin=conn.getAdmin();    // 管理员去管理连接的}catch(IOException  e){     e.printStackTrace();}   }//关闭连接public  static  void  close(){try{ if(null!=admin){   admin.close();  } if(null != conn){    conn.close();}}catch(IOException  e){ e.printStackTrace();}}public  static void   main(String[] args){ createTab("t2",new String[]{"cf","cf1"}); putData("t2","row1","cf","name","zhangsan");  putData("t2","row1","cf","age","18"); putData("t2","row1","cf","address","shanghai");      putData("t2","row2","cf","name","lis"); putData("t2","row2","cf1","address","Beijing"); putData("t2","row3","cf","name","wangwu"); getData("t2","row1","cf","name"); scanData("t2","cf","name","row1","row3"); //stopRow  row  to  end  of  exclusive  [)的区间的updateColumn("t2","row1"，"cf","name","zhaoliu");//更新cell，put  list<put>//               bulkload批量加载的，底层是HFile的东西的//delRow("t2","row2","cf1","address");getData("t2","row1","cf","name");delTable(String tableName);//删除表的时候，一定要先disable的，然后再删除表的}public  static  void  delTable(String  tableName){init();TableName  table=TableName.valueOf(tableName);try{if(admin.tableExists(table)){admin.disableTable(table);admin.deleteTable(table);}else  {System.out.println("table  is  not exists !!!!");}}catch(IOException  e){e.printStackTrace();}}public  static  void  delRow(String tableName,String rowkey,String family,String  col){init();try{Table  table=conn.getTable(TableName.valueOf(tableName));Delete  delete=new  Delete(rowkey.getBytes());//删除指定列族delete.addFamily(family.getBytes());delete.addColumn(family.getBytes(),col.getBytes());table.delete(delete);List<Delete> deleteList=new  ArrayList<Delete>();deleteList.add(delete);table.delete(deleteList);table.close();close();}catch(IOException  e){e.printStackTrace();}}public  static  void  updateColumn(String tableName,String rowKey,String  family,String  col,String  val){init();try{Table  table=conn.getTable(TableName.valueOf(tabelname));Put  put=new Put(rowkey.getBytes());put.addColumn(family.getBytes(),col.getBytes(),val.getBytes());table.put(put);table.close();}catch(IOException  e){ e.printStackTrace();}}public static   void  scanData(String  tableName,String family,String  col, String startRow,String  endRow){  init();  try{  Table  table=conn.getTable(TableName.valueOf(tableName));Scan scan=new Scan();scan.setStartRow(startRow.getBytes());scan.setStopRow(endRow.getBytes());ResultScanner  resultScanner=table.getScanner(scan);for(Result  result:resultScanner){printCell(result);}table.close(); }  catch(IOException e){  e.printStackTrace();}}public  static  void  printCell(Result  result){Cell[]   cells=result.rawCells();for(Cell  cell:cells){System.out.println("RowKey====="+new String(CellUtil.cloneRow(cell)));System.out.println("Column  Name"+new String(CellUtil.cloneQualifier(cell)));System.out.println("Column  Family"+new String(CellUtil.cloneFamily(cell)));System.out.println("value==="+new String(CellUtil.cloneValue(cell)));System.out.println("TimeStamp===="+cell.getTimeStamp());System.out.println("===========华丽的分割线==========");}}public  static  void  getData(String  tableName,String rowKey,String family,String col){init();try{Table  table=conn.getTable(TableName.valueOf(tableName));Get  get=new Get(rowKey.getBytes());//get.addFamily(family.getBytes());get.addColumn(family.getBytes(),col.getBytes());Result  result=table.get(get);printCell(result);table.close();close();}catch(IOException   e){ e.printStackTrace();}}public  static  void  creatTab(String  tableName,String[]  families){init();//HTableDescriptor   hTableDescriptor=new //HTableDescriptor(tableName);//admin.createTable();TableName  table=TableName.valueOf(tableName);try{if(admin.tableExists(table)){ System.out.println("table is  exists  !!!!!");}else  {HTableDescriptor  hTableDescriptor=new  HTableDescriptor(table);for(String  family:families){HColumnDescriptor  hColumnDescriptor=new HColumnDescriptor(family);hTableDescriptor.addFamily(hColumnDescriptor);}  admin.createTable(hTableDescriptor);}}catch(IOException   e){  e.printStackTrace();}  close();}public  static  void  putData(String  tableName,String  rowKey,String  family,String col,String  value){init();try{Table  table=conn.getTable(TableName.valueOf(tableName));Put  put=new Put(Bytes.toBytes(rowKey));put.addColumn(Bytes.toBytes(family),Bytes.toBytes(col),Bytes.toBytes(val));table.put(put);table.close();close();}catch(IOException  e){  e.printStackTrace();}}}

ulimit -a
limits on number of files and processes
open files=1024
dfs.datanode.max.transfer.threads
RowKey的个数确定数据的条数的
Time to Live TTL 存活时间的
二级索引：Phoenix或者是ElasticSearch
注意的点是：
若Mysql中的char的长度是4的话，若在Phoenix中的char的长度也是4的话，则通过Phoenix插入数据到HBase中是不成功的，Phoenix的长度不够的，

Speculative Execution推测执行的机制

Table
Region
Store
MemStore
StoreFile
Block=HFile

HBase的RESTAPI的使用：参照官网的例子，官网中的Configuration的信息的
HBase的Thrift的API的使用：
HBase的Snapshot的快照方式迁移的

通过Zookeeper管理HBase之后，可以避免了HMaster的单节点故障的问题
HBase可以启动多个HMaster的，保证一个HMaster正在运行的，
HMaster负责对表的一些增删改查的操作，而不是对表中的数据进行操作的额，
HMaster对HRegion的管理和一些负载均衡的操作，
HRegionServer=HRegion
HRegion=Store
Store=MemStore+StoreFile
StoreFile=HFile
相同请求频繁的列放在同一个列族下效果更好的， MemStore是内存的额，
StoreFile是落地磁盘的文件的存储，数据来临的时候都是先写到MemStore中的到达一定量的时候就会flush到磁盘中的生成StoreFile的，生成底层的HFile文件去做存储的额，查询检索的时候都是要先进行MemStore的，满了之后进行Flush操作，之后才会走真正的数据文件的，
小的StoreFile会合并成大的StoreFile的，在合并的时候，会进行数据的删除，版本的合并，数据的操作是在StoreFile进行Combine的时候进行的，StoreFile超过界定的大小的时候，会进行一次裂变的，进行Split的操作的，把一个Region分成俩个Region的，将其中的一个Region下线的，分配到其他的HRegionServer上的，减轻HRegionServer的压力的，

数据的增删操作都是在StoreFile合并操作的时候进行的额，
HLog是HBase的日志文件的，写数据之前都是要先到HLog中去的，避免机器宕机了数据不可恢复的，一个是去HLog中记录的，一个是去真正的数据操作的额，

HLog的存储的格式，WAL预写日志的一种存储格式，一个HRegionServer对应一个HLog的日志文件的，用于数据的恢复操作的，一个HRegionServer下可以有1000个Region的，但是只有一个HLog的日志文件的，可以恢复数据但是恢复的速度慢的，

HRegionServer=HLog(WAL) +HRegion+BlockCache
BlockCache是一个读缓存的

HFile是不定长的文件的额，一种Sequence的格式，，固定的是Trailer和FileInfo的，但是整个HFile的整个文件是不定长的额，Trailer是指向其他数据块的起始点的，是指针的入口点的，FileInfo是存储真正数据的元数据信息的，
HFile是一种二进制的文件的，StoreFile是对HFile的包装，HBase的最底层的数据文件是HFile文件的，

Zookeeper是存放整个元数据信息的和整个集群的状态信息的，包括实现HMaster的主从节点的FailOver的，保证HMaster只有一个存活状态的，RegionServer上都是对应一个DataNode的，所以说最好RegionServer是跟DataNode一一对应的，每台机器上只要有DataNode就要有RegionServer的，数据本地化的，不需要进行数据的拉取的，一个RegionServer大约存储1000个Region的，
HMaster和NameNode都是支持热备份的，都可以通过ZooKeeper进行调节的，多台Zookeeper保证选举的，
RegionServer中的Region中存储的是一段连续的数据的，有StartKey和EndKey的，连续的横向的切分的，RowKey是按照字典序排列的额，HMaster可以快速的定位到RowKey是在哪个Region中的，盐桶的分区将Key进行横向的切分的，

一个列只有一个所属的列族的
但是不同的列族下有相同的列的，
Zookeeper通过Meta的信息找到表的信息的

hbase zkcli的客户端的命令请求：hbase zkcli直接启动的时候报错的额，jline的包
vim hbase
find zkcli
CLASSPATH=’echo $CLASSPATH| sed ‘s/jruby-cloudera-1.0.0.jar//g”

ls /
ls /hbase/table/t2
HBase写数据的时候，先是写到MemStore中的额，写到缓存中的，每一个列族一个MemStore的，自己写自己的MemStore的，Key-value的形式的，

HBase的读流程：
首先扫描从BlockCache中去查找RowKey的value值的，
有就拿到，没有则会去MemStore中拿到的，
有就拿到，没有则会去HFile中拿到的，
拿到之后，会更新MemStore中的数据信息的，

当Region比较大的时候，会进行分裂的操作，聚合的操作的，手动进行聚合或者分裂的，

当数据量小的时候,Region会进行一些合并的，当一个Region比较大的时候，当数据量大的时候，会进行一些分裂的操作的，分成多个Region的，减轻Region的压力的额，

RowKey增大的时候，数据量大的时候，进行split的操作，一个Region的时候，可以分裂俩个Region的，
hbase.hstore.compactionThreshold
hbase.hstore.compaction.min.size=128MB
hbase.hstore.compaction.max.size=
Memstore进行Flush操作的时候，卡住了不动了，操作不下去的，列族过多的，影响关联其他的列族的额，

StoreFile或者HFile过多的情况下，产生过多的小文件的，会进行合并的额，hbase.hstore.compactionThreshold

什么时候进行裂变和合并操作的：
hbase.hstore.compaction.max.size
使用不频繁的时候，不足的时候，可以进行合并的操作的，
不可以乱改参数的，要重启的生效的额，集群是不可以进行随意的重启操作的，当有数据写入的时候，

Flush是针对整个Region的操作的额，而聚合或者是分裂是针对Region中的StoreFile，HFile文件进行的操作的额，
Flush的操作粒度是非常大的，

RegionServer的DataNode挂掉的，通信机制知道，记录在HLog的操作日志信息的，HMaster知道的，从HLog中查找恢复的操作点
宕机之前的数据记录的，HLog的缺陷的，且宕机前的有些记录是记录不了的，

多台的机器分布式部署，可以进行容灾性和容错性的额，

client zk hmaster hregionServer region
storeFile HFile
HBase中的HFile与DataNode中的block的关系是？？
负载均衡，表的设计，俩种合并的操作

HLog的日志记录信息的额，然后才会真正的写到Region中去的额，
BlockCache是为了方便读取数据的

HBase的Combine的和HBase负载均衡：
即是对Region进行操作的，

HBase的负载均衡的粒度： hbase.balancer.period五分钟一个批次的去执行的，负载均衡的配置会影响读写性能的，默认的负载均衡是关闭的，
负载均衡的算法：

Compaction合并的：一个是针对小文件进行合并的，一个是针对所有的文件进行合并的额。
MemStore进行flush操作的时候，也可能会生成很多的小文件的，所以要进行合并的操作的，三种情况可能会触发合并Compaction的操作的：
1.MemStore进行Flush的时候，溢写磁盘的时候，生成的是HFile文件的，合并文件就是对HFile文件的处理
2.周期性的检查是否达到规定好的阈值，
3.手动的触发，业务不繁忙的时候进行触发的，

HBase的检索的方式：通过Key的范围进行检索的，通过Phoenix结合hive一起去完成的，
表的设计优化，迁移的

Hive跟HBase结合的操作：
Phoenix对接HBase的：
首先要进行Phoenix的编译，官网上编译的步骤，

Phoenix生产环境下的timeout的加倍处理的，Phoenix架在HBase之上的，现在是SparkSQL处理流程，DataFormat在Phoenix是不支持的，要转成toData或toChar的方式的才可以进行的，必须要换成对应的Pheniox中的函数的，特别是在处理时间函数这一块的，Mysql中的时间函数，SparkSQL中的时间函数，Phoenix中的时间函数的对应的转换方式的处理的，
特别是在生产环境中的转化操作不通用处理的。

Phoenix中的时区的问题的
Cast的转化操作，针对数据类型的不统一的，String转化成int的数据的处理

建表的规范性的统一处理，
Phoenix数据类型对应关系型数据库的数据类型的对比的参照处理：
Mysql中Char数据类型长度4，但是在Phoenix中的Char长度为4的时候，则数据存放在Phoenix中会有丢失的部分的，

HBase的检索，总共字段80多个的，常用的字段10几个的，二级索引的检索速度是非常快的，Secondary Indexes二级索引的处理，Phoenix，ElasticSearch的二级索引的处理，分区分桶的建立，
二级索引：索引表实际上是复制一张表的结构进行处理的，只是处理的字段的个数是少的，是常用的字段的，故在索引之内的字段都是检索非常快的，根据你的sql语句解析下推，根据你的字段匹配是否走索引的额，
localIndex本地索引：
GlobalIndex全局性索引：
ES中的切分索引
explain执行计划来进行查看的额

强制的指定某个索引表的：index()
_* index()强制指定某个索引的额
时间的问题：时区的问题+工具框架的时间函数不同的

SALT_BUCKETS盐桶分区的，1到256的，只能在建表的时候才可以指定的。SALT_BUCKETS的数量跟HRegionServer的数量是一致的，方便数据的落地的额，用于数据的检索的额，跟RowKey一起使用的额，跟真正的分区是没有关系的额，是为了检索的，

Phoenix中的命令空间是Schema的
create schema xxx
create table if not exists xxx.LOGICAL_PO(
o_po_id varchar(32) not null primary key,
po.o_order_type varchar(32),
po.o_seller_id varchar(32),
po.o_source_pid varchar(32),
po.o_send_to_wms_time TIMESTAMP,
po.o_mod_time TIMESTAMP,
po.o_total_qty BIGINT(16),
po.o_total_weight DOUBLE(16,4),
po.w_receive_status varchar(10),
detail.o_goods_real_qty decimal(16,4)
)salt_buckets=12,compression=’snappy’;
一个字段作为主键的 ,俩个列族的po和detail的
create table if not exists xx.logical_po(
o_po_id varchar(32) not null,
o_wh_id varchar(32) not null,
o_goods_id varchar(32) not null,
o_id bigint(20) not null
constraint pk primary key (o_po_id,o_wh_id,o_goods_id,o_id)
)salt_buckets=12,compression=’snappy’,split on (10,20,30);
split on 是按照前后缀进行分组的
salt_buckets是均分的，
drop table

这个是在HBase的shell中的查询scan ‘JYD.DIM_ADDRESS’,{LIMIT=>100}
Phoenix:select * from JYD.DIM_ADDRESS limit 100;

建立了二级索引的，就会有二级索引表的额，
create index logical_order_idx on JYDW.LOGICAL_ORDER(w_user_id,o_creatime,w_b2b_flag,o_orderno,o_goods_id,w_picked_qty)

HBase全文索引后端采用ElasticSearch实现的

HBase集群的迁移方式：
DistCp迁移：停掉原集群，disable all table;
Replication动态备份，俩个的集群hadoop版本必须一致的
CopyTable目前集群必须建好要迁移的表
Export/Import迁移，前提在目标集群中比较建立
HBaseRestAPI方式迁移 Java /Scala RestAPI方式(REST服务启停)
快照方式迁移 0.95+才会支持快照，
将HDFS中HBase表文件落地再迁移，适用于集群不通信的情况下

HBase的备份：
CopyTable热备，表事先要先建立好的
快照方式热备/冷备
export/import热备

表的设计以及优化的点：存储byte-in/byte-out的数据类型
RowKey：长度，放置什么字段(常用的查询字段放在RowKey中)，二级索引ES，Phoenix localIndex globalIndex 全文索引
新进来的一批数据查询粒度比较大的，加上时间戳TimeStamps排序处理的，相当于RowKey加上Timestamp的，取一个数值类型的数long.max_size-数，处理的，
本身是字典排序的
三个字段拼在一起的，1_2_2查询第三个字段的时候，进行reverse
Phoenix中split预分区，salt_buckets盐桶

JVM gc 新生代往老年代中跑，则OOM风险大的
要适当 的调节新生代的gc长度
HBase配置
客户端Java堆大小的：
只要用到JDK的时候，必然会用到JVM的问题的

HBaseJVM
HDFSJVM
ZKJVM

TTL
多长时间过期的，设定过期时间
合并操作的时候，major compact主的合并才会去处理这种数据的

索引
ES做索引
Phoenix做二级索引
索引查询快了，但是占用空间大了，复制了一些常用的字段，复制一部分的列的数据的，有时候是需要索引的，有时候是不需要的

压缩
snappy压缩，减少数据的存储空间
HBase是支持一部分的压缩方式的，不是支持全部的，hive的支持不一定可以支持的

Region策略
Region的划分，compact的合并(major合并，minor合并)，split的分区，参数设定的时候，多大的数据量的数据量进行合并操作的。

Zk调优
ZK的JVM调整
timeout的调整
hbase的rpc timeout的调整
cache timeout 读取数据的请求时间，querytime的时间

HFile文件块大小
HFile存在HDFS上的，HFile的大小与HDFS上的block大小关系的

热点
Master的问题的，引入ZK之后基本上就不需要担心热点问题的

负载均衡
什么时候做的，怎么去做的

MemStore Flush
设定参数去进行Flush操作的，频繁的Flush操作会影响读写的性能

ColumnFamily：做Flush操作的时候，临近的列族也会进行Flush操作的，前期的时候ColumnFamily不会超过3个的，合理的设定CF的，合理设置，少的话，数据全在一个文件中的额，太多的CF的话，进行Flush操作的时候，会影响临近的CF的Flush

HLog(WAL)：用于恢复数据的，入数据操作的时候，数据不重要的，可以进行重跑的，HLog是不需要的额，
写的流程：
HLog–》MemStore–》StoreFile，若不需要HLog的时候，则写的流程会更快的，
HBase的参数调整的：
cache timeout
表数据是由什么组成：
RowKey cf:a ttl version timestamp
setMaxVersion(1/5/3)
Replication_scope的放置规则

批量的读写操作，
table.put(put)