案例
reliable and scalable data ingestion at airbnb在airbnb的rowkey設計案例中，使用了hash法避免了寫入熱點問題，其中apache hbase at airbnb
airbnb軟體工程師丁辰 - airbnb的streaming etl
event_key標識了一條日誌的唯一性，用於將來自kafka的日誌資料進行去重；
shard_id是將event_key進行hash（可以參考es的路由雜湊演算法hashing.murmur3_128）之後，對shard_num進行取餘後的結果，shard_num感覺應該是當前hbase表region server的總數，由於airbnb在hbase中儲存的是實時日誌資料，並開啟了hbase的ttl，所以當前hbase表中的資料總量應該是可**的，即region server數量不會無限增加
shard_key應該就是當前業務的region_start_keys+shard_id，比如當前業務分配的字首為00000，同時規劃了100個table regions給這個業務，即00-99，那麼shard_key的範圍就是0000000-0000099
rowkey就是shard_key.event_key，比如0000000.air_events.canaryevent.016230-a3db-434e
rowkey設計原則
1.rowkey長度原則：rowkey是乙個二進位製碼流，可以是任意字串，最大長度 64kb ，實際應用中一般為10-100bytes，以byte形式儲存，一般設計成定長。
建議越短越好，不要超過16個位元組，原因如下：
資料的持久化檔案hfile中是按照keyvalue儲存的，如果rowkey過長，比如超過100位元組，1000w行資料，光rowkey就要占用100*1000w=10億個位元組，將近1g資料，這樣會極大影響hfile的儲存效率；
memstore將快取部分資料到記憶體，如果rowkey欄位過長，記憶體的有效利用率就會降低，系統不能快取更多的資料，這樣會降低檢索效率。
目前作業系統都是64位系統，記憶體8位元組對齊，控制在16個位元組，8位元組的整數倍利用了作業系統的最佳特性。
2.rowkey雜湊原則：如果rowkey按照時間戳的方式遞增，不要將時間放在二進位製碼的前面，建議將rowkey的高位作為雜湊字段，由程式隨機生成，低位放時間字段，這樣將提高資料均衡分布在每個regionserver，以實現負載均衡的機率。
如果沒有雜湊字段，首字段直接是時間資訊，所有的資料都會集中在乙個regionserver上，這樣在資料檢索的時候負載會集中在個別的regionserver上，造成熱點問題，會降低查詢效率。
3.rowkey唯一原則：必須在設計上保證其唯一性，rowkey是按照字典順序排序儲存的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料儲存到一塊，將最近可能會被訪問的資料放到一塊。
熱點問題
hbase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行訪問在臨近位置，便於scan。然而糟糕的rowkey設計是熱點的源頭。
熱點發生在大量的client直接訪問集群的乙個或極少數個節點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起效能下降甚至region不可用，這也會影響同乙個regionserver上的其他region，由於主機無法服務其他region的請求。
設計良好的資料訪問模式以使集群被充分，均衡的利用。為了避免寫熱點，設計rowkey使得不同行在同乙個region，但是在更多資料情況下，資料應該被寫入集群的多個region，而不是乙個。下面是一些常見的避免熱點的方法以及它們的優缺點：
1.加鹽
這裡所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數，具體就是給rowkey分配乙個隨機字首以使得它和之前的rowkey的開頭不同。分配的字首種類數量應該和你想使用資料分散到不同的region的數量一致。加鹽之後的rowkey就會根據隨機生成的字首分散到各個region上，以避免熱點。
2.雜湊
雜湊會使同一行永遠用乙個字首加鹽。雜湊也可以使負載分散到整個集群，但是讀卻是可以**的。使用確定的雜湊可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某乙個行資料。
3.反轉
第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。
反轉rowkey的例子以手機號為rowkey，可以將手機號反轉後的字串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題
4.時間戳反轉
乙個常見的資料處理問題是快速獲取資料的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用 long.max_value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為hbase中rowkey是有序的，第一條記錄是最後錄入的資料。
其他一些建議：
儘量減少行鍵和列族的大小在hbase中，value永遠和它的key一起傳輸的。當具體的值在系統間傳輸時，它的rowkey，列名，時間戳也會一起傳輸。如果你的rowkey和列名很大，這個時候它們將會占用大量的儲存空間。
列族盡可能越短越好，最好是乙個字元。
冗長的屬性名雖然可讀性好，但是更短的屬性名儲存在hbase中會更好。
**：hbase的rowkey設計技巧
HBase學習之HBase的RowKey設計原則
hbase是三維有序儲存的，通過rowkey 行鍵 column key column family和qualifier 和timestamp 時間戳 這個三個維度可以對hbase中的資料進行快速定位。hbase中rowkey可以唯一標識一行記錄，在hbase查詢的時候，有以下幾種方式 通過get方...
Hbase 學習（七） rowkey設計
一直以來對rowkey的設計都比較迷茫，hbase權威指南 倒是給出了個還算靠譜的例子。下面這個例子有點兒像帖子表結構，它的rowkey設計是這樣的，可以簡單的理解為，什麼人在什麼時間發了什麼資訊，資訊包括什麼附件，它是使用者為主線的乙個設計。如果我們想查某個使用者發的資訊，我們可以設定scan的s...
Hbase學習（七） Rowkey的設計
rowkey長度原則 rowkey是乙個二進位製碼流，可以是任意字串，最大長度 64kb 實際應用中一般為10 100bytes，以 byte 形式儲存，一般設計成定長。建議越短越好，不要超過16個位元組，原因如下 資料的持久化檔案hfile中是按照keyvalue儲存的，如果rowkey過長，比如...