前面,我們已經打下了很多關于HBase的理論基礎,今天,我們主要聊聊在實際開發使用HBase中,需要關注的一些最佳實踐經驗。
1.Schema設計七大原則
1)每個region的大小應該控制在10G到50G之間;
2)一個表最好保持在 50到100個 region的規模;
3)每個cell最大不應該超過10MB,如果超過,應該有些考慮業務拆分,如果實在無法拆分,那就隻能使用mob;
4)跟傳統的關系型資料庫不同,一個HBase的表中列族最多不超過3個,列族中的列可以動态添加的,不要設計過多列族;
5)列族名必須盡量短,因為我們知道在存儲的時候,每個keyvalue都會包含列族名;
6)如果一個表存在一個以上的列族,那麼必須要注意,不同列族之間行數相差不要太大。例如列族A有10萬行,而列族B有1億行,那麼rowkey就有1億行,而region是按照行鍵進行切分的,是以列族A可能會被打散為很多很多小region,這會導緻在掃描列族A時會引發較多IO,效率低下。
7)列族可以設定TTL時間,HBase在超過設定時間後,會自動删除資料。
設定方法有兩種:
建表時設定,TTL機關為秒,此例中列簇'f1'的資料保留1天(86400秒)
hbase(main):002:0>create 'table', {NAME => 'f1', TTL => 86400}
通過修改表設定
hbase(main):002:0>alter 'table', {NAME => 'f1', TTL => 86400}
這裡需要注意,一旦超過設定時間後,該資料就無法讀取了,但是,真正的過期資料删除,是發生在major compaction時。
2.RowKey設計三大政策
HBase作為一個分布式存儲資料庫,雖然擴容非常容易,但是,對于“熱點”問題,還是非常頭疼的。
所謂“熱點”問題(HotSpotting),就是請求(讀或者寫)短時間内落在了集中的個别region上,導緻了該region所在機器的負載急劇上升,超過了單點執行個體的承受能力,進而引起性能下降或者不可用。
要解決這個問題,就需要設計RowKey時,使得資料盡量往多個region上去寫。
舉個例子:
假如region按照26個字母分成26個,那麼同時寫入m開頭的rowkey的記錄都會同時寫入同一個region
比如m001,m002,m003,m004,m005。
是以,RowKey的設計非常關鍵。常見的設計政策有這麼幾種。
1)salting
salting政策就是将生成随機數放在行鍵的開頭作為字首,
遊戲賬号拍賣平台使得每個行鍵有随機的字典序。
對上面的案例進行優化,我們采用了salting政策,插入前給每個rowkey生成一個随機的字母,變成了
am001,zm002,nm003,qm004,lm005
這樣就能同時往5個region裡面寫入了,成功打散。
副作用:由于字首生成是随機的,是以如果想要按照字典序查詢這些行,則需要做更多的事情。從這個角度上看,salting增加了寫操作的吞吐量,卻也增大了讀操作的開銷。
2)Hashing
Hashing政策也是一種特殊的salting,是用一個單向的 hash 來取代随機指派字首。
這樣能使一個給定rowkey的行在“salted”時有相同的字首,是以,這樣既可以分散RegionServer間的負載的,同時也允許在讀操作時能夠預測這個字首值是什麼。确定性hash( deterministic hash )可以讓用戶端重建完整的行鍵,然後就可以像正常一樣用Get方法查詢确定的行。
3)reverse key
第三種預防hotspotting的方法是反轉一段固定長度或者可數的鍵,讓變化最多的某個位置放在rowkey的第一位,
副作用:對于Get操作沒有影響,但是不利于Scan操作進行範圍查詢,因為資料在原RowKey上的順序已經被打亂。
3.預分區
在 HBase核心特性—region split 中,我們知道已經提到過關于預分區。
主要原因是當一張表被首次建立時,隻會配置設定一個region給這個表。是以,在剛剛開始時,所有讀寫請求都會落在這個region所在的region server上,而不管你整個叢集有多少個region server。不能充分地利用叢集的分布式特性。
是以,預分區主要也是解決“熱點”問題。
最為常見的建表語句為:
create ‘tb’,{NAME => ‘f1’,COMPRESSION => ‘snappy’ }, { NUMREGIONS => 50, SPLITALGO => ‘HexStringSplit’ }
NUMREGIONS 為 region的個數,一般按照每個region 8-10GB左右來計算region數量,如果叢集規模非常大,那麼region數量可以适當取大一些
SPLITALGO 為 rowkey分割的算法,Hbase自帶了三種pre-split的算法,分别是 HexStringSplit、DecimalStringSplit 和 UniformSplit。
各種Split算法适用場景:
HexStringSplit: rowkey是十六進制的字元串作為字首的
DecimalStringSplit: rowkey是10進制數字字元串作為字首的
UniformSplit: rowkey字首完全随機
4.讀性能優化
前面主要講一些設計方面的優化點。
那如果在HBase的使用過程中,發現查詢較慢,那麼就需要根據具體情況,分析查詢慢的原因,并采取相應的政策。
現象:隻有某個業務查詢慢,其他業務并不慢,HBase叢集也不慢
排查用戶端
Scan是否設定合理的緩存(setCatch)
Get請求是否設定為批量
排查列族設計
是否設定BloomFilter?
是否設定了合理的TTL?
排查HDFS
資料本地化率是否過低?
現象:HBase叢集查詢很慢
HBase服務端問題
BlocCache配置是否合理?
HFile數量是否過多?
Compaction是否過于頻繁?
現象:某個查詢上線後,其他查詢都變慢了
用戶端問題
大scan是否設定了setBlockCache=false?
服務端問題
讀請求是否均衡
region分布是否均衡
region server的traffic是否均衡