1 是否需要寫WAL，WAL是否需要同步寫入
優化原理：數據寫入流程可以理解爲一次順序寫WAL(HLog)加上一次寫緩存（MemStore），通常情況下寫緩存延遲很低，因此提升寫性能就只能從WAL入手。WAL機制一方面是爲了確保數據即使寫入緩存丟失也可以恢復，另一方面是爲了集羣之間異步複製。默認WAL機制開啓且使用同步機制寫入WAL。首先考慮業務是否需要寫WAL，通常情況下大多數業務都會開啓WAL機制（默認），但是對於部分業務可能並不特別關心異常情況下部分數據的丟失，而更關心數據寫入吞吐量，比如某些推薦業務，這類業務即使丟失一部分用戶行爲數據可能對推薦結果並不構成很大影響，但是對於寫入吞吐量要求很高，不能造成數據隊列阻塞。這種場景下可以考慮關閉WAL寫入，寫入吞吐量可以提升2x~3x。退而求其次，有些業務不能接受不寫WAL，但可以接受WAL異步寫入，也是可以考慮優化的，通常也會帶來1x～2x的性能提升。
優化推薦：根據業務關注點在WAL機制與寫入吞吐量之間做出選擇
2 批量Put提交
優化原理：HBase分別提供了單條put以及批量put的API接口，使用批量put接口可以減少客戶端到RegionServer之間的RPC連接數，提高寫入性能。另外需要注意的是，批量put請求要麼全部成功返回，要麼拋出異常。
優化建議：使用批量put進行寫入請求
3. 異步批量Put提交
優化原理：業務如果可以接受異常情況下少量數據丟失的話，還可以使用異步批量提交的方式提交請求。提交分爲兩階段執行，用戶提交寫請求之後，數據會寫入客戶端緩存，並返回用戶寫入成功；當客戶端緩存達到閾值（默認2M）之後批量提交給RegionServer。需要注意的是，在某些情況下客戶端異常的情況下緩存數據有可能丟失。
優化建議：在業務可以接受的情況下開啓異步批量提交
使用方式：setAutoFlush(false)
4. Region個數調整
優化原理：當前集羣中表的Region個數如果小於RegionServer個數，即Num(Region of Table) < Num(RegionServer)，可以考慮切分Region並儘可能分佈到不同RegionServer來提高系統請求併發度，如果Num(Region of Table) > Num(RegionServer)，再增加Region個數效果並不明顯。
優化建議：在Num(Region of Table) < Num(RegionServer)的場景下切分部分請求負載高的Region並遷移到其他RegionServer；
5. 寫請求均衡
優化原理：另一個需要考慮的問題是寫入請求是否均衡，如果不均衡，一方面會導致系統併發度較低，另一方面也有可能造成部分節點負載很高，進而影響其他業務。分佈式系統中特別害怕一個節點負載很高的情況，一個節點負載很高可能會拖慢整個集羣，這是因爲很多業務會使用Mutli批量提交讀寫請求，一旦其中一部分請求落到該節點無法得到及時響應，就會導致整個批量請求超時。因此不怕節點宕掉，就怕節點奄奄一息！
優化建議：檢查rowkey設計以及預分區策略，保證寫入請求均衡。
6. 寫入KeyValue數據是否太大
KeyValue大小對寫入性能的影響巨大，一旦遇到寫入性能比較差的情況，需要考慮是否由於寫入KeyValue數據太大導致。隨着單行數據大小不斷變大，寫入吞吐量急劇下降，寫入延遲在100K之後會急劇增大。
7. Utilize Flash storage for WAL(HBASE-12848)
這個特性意味着可以將WAL單獨置於SSD上，這樣即使在默認情況下（WALSync），寫性能也會有很大的提升。需要注意的是，該特性建立在HDFS 2.6.0+的基礎上，HDFS以前版本不支持該特性。具體可以參考官方HBASE-12848。
8. Multiple WALs(HBASE-14457)
該特性也是對WAL進行改造，當前WAL設計爲一個RegionServer上所有Region共享一個WAL，可以想象在寫入吞吐量較高的時候必然存在資源競爭，降低整體性能。針對這個問題，社區小夥伴提出Multiple WALs機制，管理員可以爲每個Namespace下的所有表設置一個共享WAL，通過這種方式，寫性能大約可以提升20%～40%左右。具體可以參考官方HBASE-14457。