protocol Buffer:是一种轻便高效的结构化数据存储格式,可用于结构化数据串行化,或者说序列化。它很适合做数据存储或RPC数据交换格式。可用于通讯协议,数据存储等领域的语言无关,平台无关,可扩展的序列化结构数据格式,目前提供了java,c++,Python等三种语言的API。
-
表的设计:
- 预分区:
默认情况下,创建HBase表时会自动创建一个region分区,当导入数据时,所有的HBase客户端都向这个region写入数据,直到这个region足够大了才进行切分,一种可以加快批量写入速度的方法是通过预先创建的一些空的regions。这样当数据写入HBase时,会按照region分区情况,在集群内做数据的负载均衡。 - RowKey
HBase中rowKey用来检索表中的记录,支持一下三种方式:
1-通过单个rowkey访问:即按照某个rowKey键值进行get操作;
2-通过rowKey的range进行scan:即通过设置startRowKey和endRowKey,在这个范围内进行扫描
3-全表扫描:即直接扫描整张表中所有行记录
在HBase中,rowKey可以是任意字符,最大长度为64K,实际应用中一般为10-100byte,存为byte[]字节数组,一般设计为定长的。
rowKey按照字典顺序存储,设计rowKey时,要充分利用这个排序特点,将经常一起读的数据存储到一块,将最近可能会被访问的数据放在一块。
eg:如果最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为rowKey的一部分,由于是字典排序,所以可以使用Long.MaxValue - timestamp作为rowKey,这样可保证新写入的数据在读取时被快速命中。
rowKey规则:
1.越小越好
2.RowKey的设计是根据实际业务来的
3.散列性 1-取反(反序)如 001-100 ;2- 散列 hash - columnFamily
不要在表中定义太多的columnFamily。目前HBase不能很好地处理超过2-3个columnFamily的表。因为某个column family在flush时,它临近的columnFamily也会因关联效应触发flush,最终导致系统产生更多的IO。 - In Memory
创建表时,可通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中,保证在读取数据的时候被cache中。 - MaxVersion
在创建表时,通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本,如果只需要保存最新版本,可设置setMaxVersions(1) - Time To Live
创建表时,通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的生命周期,过期数据将会被自动删除,例如如果只需存储最近两天的数据,那么可以设置setTimeToLive(22460*60) - Compact & Split
在HBase中,数据在更新时,首先写入WAL日志(HLog)和内存(MemStore)中,MemStore中的数据是有序的,当MemStore累积到一定的阈值时,就会创建一个新的MemStore,并将老的MemStore添加到flush队列,由单独的线程flush到磁盘,成为一个StoreFile,同时,系统会在zookeeper中记录一个redo point,表示这个时刻之前的变更已经持久化(minor compact)。
storeFIle是只读的,一旦创建后就不可以再修改,因此HBase的更新其实是不断追加的操作。当一个store中的storeFile达到一定的阈值后,就会进行一次合并(major compact),将对同一个key的修改合并到一起。形成一个大的storeFile,当storeFile的大小达到一定的阈值后,又会对Store File进行分割(split),等分为两个StoreFile
由于对表的更新是不断追加的,处理读请求时,需要访问Store中的全部StoreFile和MemStore,将它们按照rowKey进行合并,由于StoreFile和MemStore都是经过排序的,并且storeFile带有内存中索引,通常合并较快。
实际应用中,可以考虑必要时手动进行major compact,将同一个rowKey的修改进行合并形成一个大的storeFile。同时,可以将StoreFile设置大一点,减少split的发生。
- 预分区:
-
写表操作
- 多HTable并发写
创建多个HTable客户端用于写操作,提高数据的吞吐量(用的少) - HTable参数设置
- Auto Flush
调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭,这样可以批量写入到HBase,而不是有一条put就执行一次更新,只有当put填满客户端写操作时,才实际向HBase服务发起写请求。默认情况下autoflush是开启的。 - Write Buffer
调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小,如果新设置的buffer小于当前写buffer中的数据时,buffer将会被flush到服务端。其中,writeBufferSize的单位是byte字节数,可以根据实际写入数据量的多少来设置该值。 - WAL Flag
在HBase中,客户端向集群中的RegionServer提交数据时(Put/Delete操作),首先会先写WAL(Write Ahead Log)日志(即HLog,一个RegionServer上的所有Region共享一个HLog),只有当WAL日志写成功后,再接着写MemStore,然后客户端被通知提交数据成功;如果写WAL日志失败,客户端则被通知提交失败。这样做的好处是可以做到RegionServer宕机后的数据恢复。
因此对于不太重要的数据,可以在Put/Delete操作时,通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数,放弃写WAL日志,从而提高数据写入性能。
谨慎选择关闭WAL日志,因为这样的话,一旦RegionServer宕机,Put/Delete的数据将无法根据WAL日志进行恢复。 - 批量写
通过调用HTable.put方法可以将一个指定的rowKey写入HBase,同样HBase提供了另一个方法:通过调用HTable.put(List)方法可以将指定的rowKey列表,批量写入多行记录,这样做的好处是批量执行,只需要一次网络IO开销,这对于数据实时性要求高,网络传输RTT高的情境下可能带来明显的性能提升。 - 多线程并发写
再客户端开启多个HTable写线程,每个写线程负责一个HTable的flush操作,这样结合定时flush和buffer(WriteBufferSize),可以既保证在数据量小的时候,数据可以在较短时间内被flush,同时又保证在数据量大的时候,写buffer一满就及时进行flush,
- Auto Flush
- 多HTable并发写
-
读表操作
-
HTable并发读
创建多个HTable客户端用于读操作,提高读数据的吞吐量。 -
HTable参数设置
- Scanner Caching
hbase.client.scanner.caching配置项可以设置HBaseScanner一次从服务端抓取的数据条数,默认情况下一次一条。通过将其设置成一个合理的值,可以减少scan过程中next()的时间开销,代价是scanner需要通过客户端的内存来维持这些被cache的行记录。
有三个地方可以进行配置:
1>在HBase的conf配置文件中进行配置;
2>通过调用HTable.setScannerCaching(int scannerCaching)进行配置;(使用最多)
3>通过调用Scan.setCaching(int caching)进行配置。
三者优先级别越来越高 - Scan Attribute Selection
scan时需指定需要的ColumnFamily,可以减少网络传输数据量,否则默认scan操作会返回整行所有的Column Family的数据 - Close ResultScanner
通过scanner取完数据后,记得要关闭ResultScanner,否则RegionServer可能会出现问题(对应的Server资源无法释放)
- Scanner Caching
-
批量读
通过调用HTable.get(Get)方法可以根据一个指定的row key获取一行记录,同样HBase提供了另一个方法:通过调用HTable.get(List<\Get>)方法可以根据一个指定的rowKey列表,批量获取多行记录,这样做的好处是批量执行,只需要一次网络IO开销,这对于数据实时性要求高而且网络传输RTT高的情境下可能带来明显的性能提升。 -
多线程并发读
-
缓存查询结果
对于频繁查询HBase的应用场景,可以考虑在应用程序中做缓存,当有新的查询请求时,首先在缓存中查找,如果存在直接返回,不再查询HBase,否则对HBase发起请求查询,然后在应用程序中将查询结果缓存。 -
BlockCache
HBase上RegionServer的内存分为两个部分,一部分作为MemStore,主要用来做写缓存;另外一部分作为BlockCache,主要用于读。
写请求会先写入MemStore,RegionServer会给每个region提供一个Memstore,当MenStore满64MB之后,会启动flush刷写到磁盘。当MemStore的总大小超过限制(heapsizeshbase.regionserver.global.memstore.upperLimit0.9),会强行启动flush进程,从最大的MemStore开始flush直到低于限制。
读请求首先到MemStore中查数据,查不到就到BlockCache中查,再查不到就到磁盘上读,并将读的结果放入BlockCache。由于BlockCache采用的是LRU策略,因此BlockCache达到上限(heapsizehfile.block.cache.size0.85)后,会启动淘汰机制,淘汰掉最老的一批数据。
一个RegionServer上有一个BlockCache和N个Memstore,它们的和不能大于等于heapszie*0.8,否则HBase不能启动。默认BlockCache为0.2而MemStore为0.4。对于注重读响应时间的系统,可以将BlokCache调大,比如设置BlockCache=0.4,Memstore=0.39,以加大缓存的命中率。
-
-
HTable和HTablePool使用注意事项
HTable和HTablePool都是HBase客户端API,使用其进行CRUD- 规避HTable对象的创建开销
因为客户端创建HTable对象后,需要进行一系列的操作;检查.meta表确认指定名称的HBase表是否存在,表是否有效等等。整个时间开销比较重,可能会耗时几秒。因此最好在程序启动时一次性创建完成需要的HTable对象,如果使用javaAPI,一般是在函数中进行创建,程序启动后直接重用。 - HTable对象不是线程安全的
HTable对象对于客户端来说不是线程安全的。因此在多线程环境下,要为每个线程单独创建复用一个HTable对象,不同对象间不要共享HTable对象使用,特别是在客户端auto flush被置为false时,由于存在本地write buffer,可能导致数据不一致。 - HTable对象间共享Configuration,好处在于:
- 共享zookeeper的连接:每个客户端需要与zookeeper建立连接,查询用户的table regions位置,这些信息可以在连接建立后缓存起来共享使用。
- 共享公共的资源:客户端需要通过zookeeper查找-ROOT-和.META.表,这个需要网络传输开销,客户端缓存这些客户端资源后能够减少后续的网络传输开销,加快查找过程速度。
- 规避HTable对象的创建开销