HBase讀寫優化N條實用技巧

最近spark跑的很慢，主要時間在scan hbase上。來來回回調試了挺長時間，最後肯定瓶頸在AWS EBS的磁盤I/O(跑spark時IOPS爆到1500)，因此實際上也沒有太多調優能夠作。卻是調試過程當中看了許多文章和資料，我以爲值得記錄一下。

中間廢話略多，不愛看直接跳文章最後一句。

網上HBASE/Hadoop調優的文章很是多，這裏列一些我以爲值得留做reference的：

• 應用層：hbase性能調優
• Infra層：HBase 管理，性能調優
• HBase操做最佳實踐

籠統的說，不管什麼樣的數據庫，數據庫查詢調優大體也就有這麼幾件能夠作的事情：

• 緩存
• 索引
• 減小I/O
• 提升I/O效率

緩存

Hbase操做中scanner.setCaching能夠設置每次RPC請求返回的記錄條數，默認是1，應該考慮設置。

全表掃描關掉cacheBlock，由於在全表scan的過程當中不會使用剛剛讀取的東西。

索引

HBASE裏最接近傳統數據庫索引的概念應該是Bloom Filter。Bloom Filter能夠經過告訴系統哪些StoreFile根本不用查來用來優化Get，對帶條件或指定列的Scanner也有幫助。

Bloom filter有ROW和ROWCOL兩種，ROWCOL的方式能夠對scan生效，可是存儲消耗更大。

• 任何類型的get（基於rowkey或row+col）Bloom Filter的優化都能生效，關鍵是get的類型要匹配Bloom Filter的類型

• row+col+qualify的scan能夠去掉不存在此qualify的storefile，也算是不錯的優化了，並且指明qualify也能減小流量，所以scan儘可能指明qualify。

減小I/O

少讀有時是最簡單有效的優化：

• 批量讀寫
• 減小scan的family和qualifier

• 使用filter
• 用盡可能小的Family名字

個人理解是每一個scan的result是會帶有family和qualifier名字的。舉個例子，若是family名字是"family",5個列，5000萬行數據，scan表的時候你大概load的"family"這個詞大概有1個G。

不少文章提到了壓縮對讀取性能的提高，即減小了磁盤讀寫，又減小了網絡傳輸。

開啓lzo或者snappy壓縮，壓縮會消耗必定的CPU，可是，磁盤IO和網絡IO將得到極大的改善，大體能夠壓縮4~5倍；

還有文章提到了使用Avro序列對象再作存儲，雖然這樣不能在序列化的對象上使用Filter，可是一樣是大幅下降了磁盤讀寫和存儲空間。

除了正常的應用程序對HBASE的使用，一個潛在的I/O是Hadoop的replication。

考慮調低或關閉replication ./bin/hadoop dfs -setrep -R -w 2 /

另外一個潛在的I/O是Hbase的region split和compaction。默認策略當region的大小超過10G時就會split。當一個region中的StoreFile太多時Hadoop就會作Compaction。個人感受compaction對I/O影響很是大，常常會致使spark在scan時timeout。

Major Compaction能夠手動或自動觸發，然而因爲它會引發不少的IO操做而引發性能問題，於是它通常會被安排在週末、凌晨等集羣比較閒的時間。

提升I/O瓶頸

AWS EBS很方便，可是不強大，畢竟是網絡虛擬硬盤。提升IOPS方法卻是不少，用IOPS優化的卷或者多掛磁盤作RAID(準確的說是作JBOD就好)。

• 不要用網絡虛擬硬盤（然而臣妾作不到啊）
• Master作1+0Raid，Slave作JBOD
• 不要用SSD！SSD同效率成本大概是HDD的2.5倍
• 控制在1個instance 8核不超過8個磁盤，每磁盤IOPS=100左右

更宏觀的思考

回過頭來想，既然全表scan hbase，那確定是個離線任務，既然是離線任務，又爲什麼要糾結性能。

固然此次的問題出發點來自於Spark報Timeout的錯：

Tue Jul 12 09:46:46 UTC 2016, null, java.net.SocketTimeoutException:

最後其實把Hadoop的Timeout時間從2分鐘設置成10分鐘就行了。

固然即便是離線任務也不能夠恣意的慢，當數據庫足夠大時，離線任務的執行時間也可能超過一個特定的可忍受的線。應用程序應該考慮如何讓全表這樣的操做分解成周期更短的操做，以便於磁盤的I/O能更均勻的時間分佈。

確實有意思的一個話題是如何scale out磁盤：若是把磁盤I/O當作和CPU同樣的資源，就會有在特定須要的時候scale out的需求。固然，閒置的磁盤相對便宜，因此如今沒有人會像管理CPU或instance同樣去管理它。並且磁盤不一樣於CPU和內存這些資源，對它的使用老是伴隨着對其上數據的使用，因而資源的初始化難度大不少。

固然，AWS EBS雖不強大，可是價格實惠童叟無欺，1TB的Amazon EBS Throughput Optimized HDD (st1) 磁盤一個月大概350塊，因此若是HBASE讀寫有性能問題：

花千吧塊錢多加幾塊硬盤吧！