1、compression
默認值是 NONE 即不使用壓縮， 這個參數意思是該列族是否采用壓縮，采用什么壓縮算 法
方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'}
建議采用 SNAPPY 壓縮算法 ， HBase 中，在 Snappy 發布之前（ Google 2011 年對外發布 Snappy），采用的 LZO 算法，目標是達到盡可能快的壓縮和解壓速度，同時減少對 CPU 的消耗；
HBase修改壓縮格式，需要一個列族一個列族的修改
alter 'test', NAME => 'f', COMPRESSION => 'snappy'。
而且這個地方要小心，別將列族名字寫錯，或者大小寫錯誤。因為這個地方任何錯誤，都會創建一個新的列族，且壓縮格式為snappy（
修改之前需要先disable，修改完之后需要enable，然后 major_compact 'test'）
2、TTL (time to live)
設置方法和versions類似
3、disable_all enable_all drop_all：支持正則表達式，並列出當前匹配的表，之后給出確認提示。
4、Hbase 預分區
HBase表在剛剛被創建時，只有1個分區（region），當一個region過大（達到hbase.hregion.max.filesize屬性中定義的閾值，默認10GB）時，表將會進行split，分裂為2個分區。表在進行split的時候，會耗費大量的資源，頻繁的分區對HBase的性能有巨大的影響。HBase提供了預分區功能，即用戶可以在創建表的時候對表按照一定的規則分區。分區是針對表級，不是列族級，因為region是根據rowkey來划分的。
目的：減少由於region split帶來的資源消耗。從而提高HBase的性能。
方案1：Hbase shell 創建，16010端口可以查看具體region
方案2：Hbase shell ，通過文件來創建
5、表的設計
列簇設計：
原則：在合理范圍內能盡量少的減少列簇就盡量減少列簇，因為列簇是共享region的，每個列簇數據相差太大導致查詢效率低下
最優：將所有相關性很強的 key-value 都放在同一個列簇下，這樣既能做到查詢效率 最高，也能保持盡可能少的訪問不同的磁盤文件。以用戶信息為例，可以將必須的基本信息存放在一個列族，而一些附加的額外信息可以放在 另一列族
rowkey設計：
長度原則：100字節以內，8的倍數最好，可能的情況下越短越好。因為HFile是按照keyvalue存儲的，過長的rowkey會影響存儲效率；其次，過長的rowkey在memstore中較大，影響緩沖效果，降低檢索效率。最后，操作系統大多為64位，8的倍數，充分利用操作系統的最佳性能。
散列原則：高位散列，低位時間字段。避免熱點問題
唯一原則：分利用這個排序的特點，將經常讀取的數據存儲到一塊，將最近可能會被訪問 的數據放到一塊。
6、數據熱點問題
措施一：加鹽
隨機前綴，高位散列，講數據隨機分散到region上
措施二：哈希
哈希前綴，負債均衡，並且可以利用哈希重構rowkey，使用get獲取准確數據
措施三：反轉
反轉固定長度或者數字格式的rowkey，犧牲了有序性，避免類似手機號固定開頭的熱點問題
措施四：時間戳反轉