1. 表的設(shè)計

1.1 Pre-Creating Regions

默認(rèn)情況下，在創(chuàng)建HBase表的時候會自動創(chuàng)建一個region分區(qū)，當(dāng)導(dǎo)入數(shù)據(jù)的時候，所有的HBase客戶端都向這一個region寫數(shù)據(jù)，直到這個region足夠大了才進(jìn)行切分。一種可以加快批量寫入速度的方法是通過預(yù)先創(chuàng)建一些空的regions，這樣當(dāng)數(shù)據(jù)寫入HBase時，會按照region分區(qū)情況，在集群內(nèi)做數(shù)據(jù)的負(fù)載均衡。
有關(guān)預(yù)分區(qū)，詳情參見：Table Creation: Pre-Creating Regions，下面是一個例子：

public static boolean createTable(HBaseAdmin admin, HTableDescriptor table, byte[][] splits)
throws IOException {try {admin.createTable(table, splits);return true;} catch (TableExistsException e) {logger.info("table " + table.getNameAsString() + " already exists");// the table already exists...return false;  }
}

public static byte[][] getHexSplits(String startKey, String endKey, int numRegions) { //start:001,endkey:100,10region [001,010]
[011,020]byte[][] splits = new byte[numRegions-1][];BigInteger lowestKey = new BigInteger(startKey, 16);BigInteger highestKey = new BigInteger(endKey, 16);BigInteger range = highestKey.subtract(lowestKey);BigInteger regionIncrement = range.divide(BigInteger.valueOf(numRegions));lowestKey = lowestKey.add(regionIncrement);for(int i=0; i < numRegions-1;i++) {BigInteger key = lowestKey.add(regionIncrement.multiply(BigInteger.valueOf(i)));byte[] b = String.format("%016x", key).getBytes();splits[i] = b;}return splits;
}

1.2 Row Key

HBase中row key用來檢索表中的記錄，支持以下三種方式：

• 通過單個row key訪問：即按照某個row key鍵值進(jìn)行g(shù)et操作；
• 通過row key的range進(jìn)行scan：即通過設(shè)置startRowKey和endRowKey，在這個范圍內(nèi)進(jìn)行掃描；
• 全表掃描：即直接掃描整張表中所有行記錄。

在HBase中，row key可以是任意字符串，最大長度64KB，實際應(yīng)用中一般為10~100bytes，存為byte[]字節(jié)數(shù)組，一般設(shè)計成定長的。
row key是按照字典序存儲，因此，設(shè)計row key時，要充分利用這個排序特點，將經(jīng)常一起讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問的數(shù)據(jù)放在一塊。
舉個例子：如果最近寫入HBase表中的數(shù)據(jù)是最可能被訪問的，可以考慮將時間戳作為row key的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE - timestamp作為row key，這樣能保證新寫入的數(shù)據(jù)在讀取時可以被快速命中。
Rowkey規(guī)則：
1、越小越好
2、Rowkey的設(shè)計是要根據(jù)實際業(yè)務(wù)來
3、散列性
a)取反 001 002 100 200
b)Hash

1.3 Column Family

不要在一張表里定義太多的column family。目前Hbase并不能很好的處理超過2~3個column family的表。因為某個column family在flush的時候，它鄰近的column family也會因關(guān)聯(lián)效應(yīng)被觸發(fā)flush，最終導(dǎo)致系統(tǒng)產(chǎn)生更多的I/O。感興趣的同學(xué)可以對自己的HBase集群進(jìn)行實際測試，從得到的測試結(jié)果數(shù)據(jù)驗證一下。

1.4 In Memory

創(chuàng)建表的時候，可以通過HColumnDescriptor.setInMemory(true)將表放到RegionServer的緩存中，保證在讀取的時候被cache命中。

1.5 Max Version

創(chuàng)建表的時候，可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設(shè)置表中數(shù)據(jù)的最大版本，如果只需要保存最新版本的數(shù)據(jù)，那么可以設(shè)置setMaxVersions(1)。

1.6 Time To Live

創(chuàng)建表的時候，可以通過HColumnDescriptor.setTimeToLive(int timeToLive)設(shè)置表中數(shù)據(jù)的存儲生命期，過期數(shù)據(jù)將自動被刪除，例如如果只需要存儲最近兩天的數(shù)據(jù)，那么可以設(shè)置setTimeToLive(2 * 24 * 60 * 60)。

1.7 Compact & Split

在HBase中，數(shù)據(jù)在更新時首先寫入WAL 日志(HLog)和內(nèi)存(MemStore)中，MemStore中的數(shù)據(jù)是排序的，當(dāng)MemStore累計到一定閾值時，就會創(chuàng)建一個新的MemStore，并且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。于此同時， 系統(tǒng)會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經(jīng)持久化了(minor compact)。
StoreFile是只讀的，一旦創(chuàng)建后就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當(dāng)一個Store中的StoreFile達(dá)到一定的閾值后，就會進(jìn)行一次合并(major compact)，將對同一個key的修改合并到一起，形成一個大的StoreFile，當(dāng)StoreFile的大小達(dá)到一定閾值后，又會對 StoreFile進(jìn)行分割(split)，等分為兩個StoreFile。
由于對表的更新是不斷追加的，處理讀請求時，需要訪問Store中全部的StoreFile和MemStore，將它們按照row key進(jìn)行合并，由于StoreFile和MemStore都是經(jīng)過排序的，并且StoreFile帶有內(nèi)存中索引，通常合并過程還是比較快的。
實際應(yīng)用中，可以考慮必要時手動進(jìn)行major compact，將同一個row key的修改進(jìn)行合并形成一個大的StoreFile。同時，可以將StoreFile設(shè)置大些，減少split的發(fā)生。

hbase為了防止小文件（被刷到磁盤的menstore）過多，以保證保證查詢效率，hbase需要在必要的時候?qū)⑦@些小的store file合并成相對較大的store file，這個過程就稱之為compaction。在hbase中，主要存在兩種類型的compaction：minor compaction和major compaction。
minor compaction:的是較小、很少文件的合并。
major compaction 的功能是將所有的store file合并成一個，觸發(fā)major compaction的可能條件有：major_compact 命令、majorCompact() API、region server自動運(yùn)行（相關(guān)參數(shù)：hbase.hregion.majoucompaction 默認(rèn)為24 小時、hbase.hregion.majorcompaction.jetter 默認(rèn)值為0.2 防止region server 在同一時間進(jìn)行major compaction）。
hbase.hregion.majorcompaction.jetter參數(shù)的作用是：對參數(shù)hbase.hregion.majoucompaction 規(guī)定的值起到浮動的作用，假如兩個參數(shù)都為默認(rèn)值24和0,2，那么major compact最終使用的數(shù)值為：19.2~28.8 這個范圍。

1、關(guān)閉自動major compaction
2、手動編程major compaction

Timer類，contab
minor compaction的運(yùn)行機(jī)制要復(fù)雜一些，它由一下幾個參數(shù)共同決定：
hbase.hstore.compaction.min :默認(rèn)值為 3，表示至少需要三個滿足條件的store file時，minor compaction才會啟動
hbase.hstore.compaction.max 默認(rèn)值為10，表示一次minor compaction中最多選取10個store file
hbase.hstore.compaction.min.size 表示文件大小小于該值的store file 一定會加入到minor compaction的store file中
hbase.hstore.compaction.max.size 表示文件大小大于該值的store file 一定會被minor compaction排除
hbase.hstore.compaction.ratio 將store file 按照文件年齡排序（older to younger），minor compaction總是從older store file開始選擇

2. 寫表操作

2.1 多HTable并發(fā)寫

創(chuàng)建多個HTable客戶端用于寫操作，提高寫數(shù)據(jù)的吞吐量，一個例子：

static final Configuration conf = HBaseConfiguration.create();
static final String table_log_name = “user_log”;
wTableLog = new HTable[tableN];
for (int i = 0; i < tableN; i++) {wTableLog[i] = new HTable(conf, table_log_name);wTableLog[i].setWriteBufferSize(5 * 1024 * 1024); //5MBwTableLog[i].setAutoFlush(false);
}

2.2 HTable參數(shù)設(shè)置

2.2.1 Auto Flush

通過調(diào)用HTable.setAutoFlush(false)方法可以將HTable寫客戶端的自動flush關(guān)閉，這樣可以批量寫入數(shù)據(jù)到HBase，而不是有一條put就執(zhí)行一次更新，只有當(dāng)put填滿客戶端寫緩存時，才實際向HBase服務(wù)端發(fā)起寫請求。默認(rèn)情況下auto flush是開啟的。
2.2.2 Write Buffer
通過調(diào)用HTable.setWriteBufferSize(writeBufferSize)方法可以設(shè)置HTable客戶端的寫buffer大小，如果新設(shè)置的buffer小于當(dāng)前寫buffer中的數(shù)據(jù)時，buffer將會被flush到服務(wù)端。其中，writeBufferSize的單位是byte字節(jié)數(shù)，可以根據(jù)實際寫入數(shù)據(jù)量的多少來設(shè)置該值。

2.2.3 WAL Flag

在HBae中，客戶端向集群中的RegionServer提交數(shù)據(jù)時（Put/Delete操作），首先會先寫WAL（Write Ahead Log）日志（即HLog，一個RegionServer上的所有Region共享一個HLog），只有當(dāng)WAL日志寫成功后，再接著寫MemStore，然后客戶端被通知提交數(shù)據(jù)成功；如果寫WAL日志失敗，客戶端則被通知提交失敗。這樣做的好處是可以做到RegionServer宕機(jī)后的數(shù)據(jù)恢復(fù)。
因此，對于相對不太重要的數(shù)據(jù)，可以在Put/Delete操作時，通過調(diào)用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函數(shù)，放棄寫WAL日志，從而提高數(shù)據(jù)寫入的性能。
值得注意的是：謹(jǐn)慎選擇關(guān)閉WAL日志，因為這樣的話，一旦RegionServer宕機(jī)，Put/Delete的數(shù)據(jù)將會無法根據(jù)WAL日志進(jìn)行恢復(fù)。

2.3 批量寫

通過調(diào)用HTable.put(Put)方法可以將一個指定的row key記錄寫入HBase，同樣HBase提供了另一個方法：通過調(diào)用HTable.put(List)方法可以將指定的row key列表，批量寫入多行記錄，這樣做的好處是批量執(zhí)行，只需要一次網(wǎng)絡(luò)I/O開銷，這對于對數(shù)據(jù)實時性要求高，網(wǎng)絡(luò)傳輸RTT高的情景下可能帶來明顯的性能提升。
2.4 多線程并發(fā)寫
在客戶端開啟多個HTable寫線程，每個寫線程負(fù)責(zé)一個HTable對象的flush操作，這樣結(jié)合定時flush和寫buffer（writeBufferSize），可以既保證在數(shù)據(jù)量小的時候，數(shù)據(jù)可以在較短時間內(nèi)被flush（如1秒內(nèi)），同時又保證在數(shù)據(jù)量大的時候，寫buffer一滿就及時進(jìn)行flush。下面給個具體的例子：

for (int i = 0; i < threadN; i++) {Thread th = new Thread() {public void run() {while (true) {try {sleep(1000); //1 second} catch (InterruptedException e) {e.printStackTrace();}
synchronized (wTableLog[i]) {try {wTableLog[i].flushCommits();} catch (IOException e) {e.printStackTrace();}}}
}};th.setDaemon(true);th.start();
}

3. 讀表操作

3.1 多HTable并發(fā)讀

創(chuàng)建多個HTable客戶端用于讀操作，提高讀數(shù)據(jù)的吞吐量，一個例子：

static final Configuration conf = HBaseConfiguration.create();
static final String table_log_name = “user_log”;
rTableLog = new HTable[tableN];
for (int i = 0; i < tableN; i++) {
rTableLog[i] = new HTable(conf, table_log_name);
rTableLog[i].setScannerCaching(50);
}

3.2 HTable參數(shù)設(shè)置

3.2.1 Scanner Caching

hbase.client.scanner.caching配置項可以設(shè)置HBase scanner一次從服務(wù)端抓取的數(shù)據(jù)條數(shù)，默認(rèn)情況下一次一條。通過將其設(shè)置成一個合理的值，可以減少scan過程中next()的時間開銷，代價是scanner需要通過客戶端的內(nèi)存來維持這些被cache的行記錄。
有三個地方可以進(jìn)行配置：1）在HBase的conf配置文件中進(jìn)行配置；2）通過調(diào)用HTable.setScannerCaching(int scannerCaching)進(jìn)行配置；3）通過調(diào)用Scan.setCaching(int caching)進(jìn)行配置。三者的優(yōu)先級越來越高。

3.2.2 Scan Attribute Selection

scan時指定需要的Column Family，可以減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量，否則默認(rèn)scan操作會返回整行所有Column Family的數(shù)據(jù)。

3.2.3 Close ResultScanner

通過scan取完數(shù)據(jù)后，記得要關(guān)閉ResultScanner，否則RegionServer可能會出現(xiàn)問題（對應(yīng)的Server資源無法釋放）。

3.3 批量讀

通過調(diào)用HTable.get(Get)方法可以根據(jù)一個指定的row key獲取一行記錄，同樣HBase提供了另一個方法：通過調(diào)用HTable.get(List)方法可以根據(jù)一個指定的row key列表，批量獲取多行記錄，這樣做的好處是批量執(zhí)行，只需要一次網(wǎng)絡(luò)I/O開銷，這對于對數(shù)據(jù)實時性要求高而且網(wǎng)絡(luò)傳輸RTT高的情景下可能帶來明顯的性能提升。

3.4 多線程并發(fā)讀

在客戶端開啟多個HTable讀線程，每個讀線程負(fù)責(zé)通過HTable對象進(jìn)行g(shù)et操作。下面是一個多線程并發(fā)讀取HBase，獲取店鋪一天內(nèi)各分鐘PV值的例子：

public class DataReaderServer {//獲取店鋪一天內(nèi)各分鐘PV值的入口函數(shù)public static ConcurrentHashMap<String, String> getUnitMinutePV(long uid, long startStamp, long endStamp){long min = startStamp;int count = (int)((endStamp - startStamp) / (60*1000));List<String> lst = new ArrayList<String>();for (int i = 0; i <= count; i++) {min = startStamp + i * 60 * 1000;lst.add(uid + "_" + min);}return parallelBatchMinutePV(lst);}//多線程并發(fā)查詢，獲取分鐘PV值
private static ConcurrentHashMap<String, String> parallelBatchMinutePV(List<String> lstKeys){ConcurrentHashMap<String, String> hashRet = new ConcurrentHashMap<String, String>();int parallel = 3;List<List<String>> lstBatchKeys  = null;if (lstKeys.size() < parallel ){lstBatchKeys  = new ArrayList<List<String>>(1);lstBatchKeys.add(lstKeys);}else{lstBatchKeys  = new ArrayList<List<String>>(parallel);for(int i = 0; i < parallel; i++  ){List<String> lst = new ArrayList<String>();lstBatchKeys.add(lst);}for(int i = 0 ; i < lstKeys.size() ; i ++ ){lstBatchKeys.get(i%parallel).add(lstKeys.get(i));}}List<Future< ConcurrentHashMap<String, String> >> futures = new ArrayList<Future< ConcurrentHashMap<String, String> >>(5);ThreadFactoryBuilder builder = new ThreadFactoryBuilder();builder.setNameFormat("ParallelBatchQuery");ThreadFactory factory = builder.build();ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(lstBatchKeys.size(), factory);for(List<String> keys : lstBatchKeys){Callable< ConcurrentHashMap<String, String> > callable = new BatchMinutePVCallable(keys);FutureTask< ConcurrentHashMap<String, String> > future = (FutureTask< ConcurrentHashMap<String, String> >) executor.submit(callable);futures.add(future);}executor.shutdown();// Wait for all the tasks to finishtry {boolean stillRunning = !executor.awaitTermination(5000000, TimeUnit.MILLISECONDS);if (stillRunning) {try {executor.shutdownNow();} catch (Exception e) {// TODO Auto-generated catch blocke.printStackTrace();}}} catch (InterruptedException e) {try {Thread.currentThread().interrupt();} catch (Exception e1) {// TODO Auto-generated catch blocke1.printStackTrace();}}// Look for any exceptionfor (Future f : futures) {try {if(f.get() != null){hashRet.putAll((ConcurrentHashMap<String, String>)f.get());}} catch (InterruptedException e) {try {Thread.currentThread().interrupt();} catch (Exception e1) {// TODO Auto-generated catch blocke1.printStackTrace();}} catch (ExecutionException e) {e.printStackTrace();}}return hashRet;}//一個線程批量查詢，獲取分鐘PV值protected static ConcurrentHashMap<String, String> getBatchMinutePV(List<String> lstKeys){ConcurrentHashMap<String, String> hashRet = null;List<Get> lstGet = new ArrayList<Get>();String[] splitValue = null;for (String s : lstKeys) {splitValue = s.split("_");long uid = Long.parseLong(splitValue[0]);long min = Long.parseLong(splitValue[1]);byte[] key = new byte[16];Bytes.putLong(key, 0, uid);Bytes.putLong(key, 8, min);Get g = new Get(key);g.addFamily(fp);lstGet.add(g);}Result[] res = null;try {res = tableMinutePV[rand.nextInt(tableN)].get(lstGet);} catch (IOException e1) {logger.error("tableMinutePV exception, e=" + e1.getStackTrace());}if (res != null && res.length > 0) {hashRet = new ConcurrentHashMap<String, String>(res.length);for (Result re : res) {if (re != null && !re.isEmpty()) {try {byte[] key = re.getRow();byte[] value = re.getValue(fp, cp);if (key != null && value != null) {hashRet.put(String.valueOf(Bytes.toLong(key,Bytes.SIZEOF_LONG)), String.valueOf(Bytes.toLong(value)));}} catch (Exception e2) {logger.error(e2.getStackTrace());}}}}return hashRet;}
}
//調(diào)用接口類，實現(xiàn)Callable接口
class BatchMinutePVCallable implements Callable<ConcurrentHashMap<String, String>>{private List<String> keys;public BatchMinutePVCallable(List<String> lstKeys ) {this.keys = lstKeys;}public ConcurrentHashMap<String, String> call() throws Exception {return DataReadServer.getBatchMinutePV(keys);}
}

3.5 緩存查詢結(jié)果

對于頻繁查詢HBase的應(yīng)用場景，可以考慮在應(yīng)用程序中做緩存，當(dāng)有新的查詢請求時，首先在緩存中查找，如果存在則直接返回，不再查詢HBase；否則對HBase發(fā)起讀請求查詢，然后在應(yīng)用程序中將查詢結(jié)果緩存起來。至于緩存的替換策略，可以考慮LRU等常用的策略。

3.6 Blockcache

HBase上Regionserver的內(nèi)存分為兩個部分，一部分作為Memstore，主要用來寫；另外一部分作為BlockCache，主要用于讀。
寫請求會先寫入Memstore，Regionserver會給每個region提供一個Memstore，當(dāng)Memstore滿64MB以后，會啟動 flush刷新到磁盤。當(dāng)Memstore的總大小超過限制時（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），會強(qiáng)行啟動flush進(jìn)程，從最大的Memstore開始flush直到低于限制。
讀請求先到Memstore中查數(shù)據(jù)，查不到就到BlockCache中查，再查不到就會到磁盤上讀，并把讀的結(jié)果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache達(dá)到上限(heapsize * hfile.block.cache.size * 0.85)后，會啟動淘汰機(jī)制，淘汰掉最老的一批數(shù)據(jù)。
一個Regionserver上有一個BlockCache和N個Memstore，它們的大小之和不能大于等于heapsize * 0.8，否則HBase不能啟動。默認(rèn)BlockCache為0.2，而Memstore為0.4。對于注重讀響應(yīng)時間的系統(tǒng)，可以將 BlockCache設(shè)大些，比如設(shè)置BlockCache=0.4，Memstore=0.39，以加大緩存的命中率。
有關(guān)BlockCache機(jī)制，請參考這里：HBase的Block cache，HBase的blockcache機(jī)制，hbase中的緩存的計算與使用。

HTable和HTablePool使用注意事項
HTable和HTablePool都是HBase客戶端API的一部分，可以使用它們對HBase表進(jìn)行CRUD操作。下面結(jié)合在項目中的應(yīng)用情況，對二者使用過程中的注意事項做一下概括總結(jié)。

Configuration conf = HBaseConfiguration.create();
try (Connection connection = ConnectionFactory.createConnection(conf)) {try (Table table = connection.getTable(TableName.valueOf(tablename)) {// use table as needed, the table returned is lightweight}
}

HTable

HTable是HBase客戶端與HBase服務(wù)端通訊的Java API對象，客戶端可以通過HTable對象與服務(wù)端進(jìn)行CRUD操作（增刪改查）。它的創(chuàng)建很簡單：

Configuration conf = HBaseConfiguration.create();
HTable table = new HTable(conf, "tablename");
//TODO CRUD Operation……

HTable使用時的一些注意事項：

1. 規(guī)避HTable對象的創(chuàng)建開銷

因為客戶端創(chuàng)建HTable對象后，需要進(jìn)行一系列的操作：檢查.META.表確認(rèn)指定名稱的HBase表是否存在，表是否有效等等，整個時間開銷比較重，可能會耗時幾秒鐘之長，因此最好在程序啟動時一次性創(chuàng)建完成需要的HTable對象，如果使用Java API，一般來說是在構(gòu)造函數(shù)中進(jìn)行創(chuàng)建，程序啟動后直接重用。

2. HTable對象不是線程安全的

HTable對象對于客戶端讀寫數(shù)據(jù)來說不是線程安全的，因此多線程時，要為每個線程單獨創(chuàng)建復(fù)用一個HTable對象，不同對象間不要共享HTable對象使用，特別是在客戶端auto flash被置為false時，由于存在本地write buffer，可能導(dǎo)致數(shù)據(jù)不一致。

3. HTable對象之間共享Configuration

HTable對象共享Configuration對象，這樣的好處在于：

• 共享ZooKeeper的連接：每個客戶端需要與ZooKeeper建立連接，查詢用戶的table regions位置，這些信息可以在連接建立后緩存起來共享使用；
• 共享公共的資源：客戶端需要通過ZooKeeper查找-ROOT-和.META.表，這個需要網(wǎng)絡(luò)傳輸開銷，客戶端緩存這些公共資源后能夠減少后續(xù)的網(wǎng)絡(luò)傳輸開銷，加快查找過程速度。
  因此，與以下這種方式相比：

HTable table1 = new HTable("table1");
HTable table2 = new HTable("table2");

下面的方式更有效些：

Configuration conf = HBaseConfiguration.create();
HTable table1 = new HTable(conf, "table1");
HTable table2 = new HTable(conf, "table2");

備注：即使是高負(fù)載的多線程程序，也并沒有發(fā)現(xiàn)因為共享Configuration而導(dǎo)致的性能問題；如果你的實際情況中不是如此，那么可以嘗試不共享Configuration。

HTablePool

HTablePool可以解決HTable存在的線程不安全問題，同時通過維護(hù)固定數(shù)量的HTable對象，能夠在程序運(yùn)行期間復(fù)用這些HTable資源對象。
Configuration conf = HBaseConfiguration.create();
HTablePool pool = new HTablePool(conf, 10);

1. HTablePool可以自動創(chuàng)建HTable對象，而且對客戶端來說使用上是完全透明的，可以避免多線程間數(shù)據(jù)并發(fā)修改問題。

2. HTablePool中的HTable對象之間是公用Configuration連接的，能夠可以減少網(wǎng)絡(luò)開銷。

HTablePool的使用很簡單：每次進(jìn)行操作前，通過HTablePool的getTable方法取得一個HTable對象，然后進(jìn)行put/get/scan/delete等操作，最后通過HTablePool的putTable方法將HTable對象放回到HTablePool中。
下面是個使用HTablePool的簡單例子：

public void createUser(String username, String firstName, String lastName, String email, String password, String roles) throws IOException {HTable table = rm.getTable(UserTable.NAME);Put put = new Put(Bytes.toBytes(username));put.add(UserTable.DATA_FAMILY, UserTable.FIRSTNAME,Bytes.toBytes(firstName));put.add(UserTable.DATA_FAMILY, UserTable.LASTNAME,Bytes.toBytes(lastName));put.add(UserTable.DATA_FAMILY, UserTable.EMAIL, Bytes.toBytes(email));put.add(UserTable.DATA_FAMILY, UserTable.CREDENTIALS,Bytes.toBytes(password));put.add(UserTable.DATA_FAMILY, UserTable.ROLES, Bytes.toBytes(roles));table.put(put);table.flushCommits();rm.putTable(table);
}

Hbase和DBMS比較：

查詢數(shù)據(jù)不靈活：
1、不能使用column之間過濾查詢
2、不支持全文索引。使用ES和hbase整合完成全文搜索。
a)使用MR批量讀取hbase中的數(shù)據(jù)，在ES里面建立索引（no store）之保存rowkey的值。
b)根據(jù)關(guān)鍵詞從索引中搜索到rowkey（分頁）
c)根據(jù)rowkey從hbase查詢所有數(shù)據(jù)