開頭
需要hbase具有實時讀取數據的時效，但如果利用不好，哪些hbase也不能為我們好好利用，為了更好讓hbase寫入性能的提升，哪些我們應該要注意以下相當事項。
是否需要寫WAL（Write-Ahead-Log）？WAL是否需要同步寫入？
優化原理：數據寫入流程可以理解為一次順序寫WAL+一次寫緩存，通常情況下寫緩存延遲很低，因此提升寫性能就只能從WAL入手。WAL機制一方面是為了確保數據即使寫入緩存丟失也可以恢復，另一方面是為了集群之間異步復制。默認WAL機制開啟且使用同步機制寫入WAL。首先考慮業務是否需要寫WAL，通常情況下大多數業務都會開啟WAL機制（默認），但是對于部分業務可能并不特別關心異常情況下部分數據的丟失，而更關心數據寫入吞吐量，比如某些推薦業務，這類業務即使丟失一部分用戶行為數據可能對推薦結果并不構成很大影響，但是對于寫入吞吐量要求很高，不能造成數據隊列阻塞。這種場景下可以考慮關閉WAL寫入，寫入吞吐量可以提升2x~3x。退而求其次，有些業務不能接受不寫WAL，但可以接受WAL異步寫入，也是可以考慮優化的，通常也會帶來1x～2x的性能提升。
優化推薦：根據業務關注點在WAL機制與寫入吞吐量之間做出選擇
其他注意點：對于使用Increment操作的業務，WAL可以設置關閉，也可以設置異步寫入，方法同Put類似。相信大多數Increment操作業務對WAL可能都不是那么敏感～
?
Put是否可以同步批量提交？
優化原理：HBase分別提供了單條put以及批量put的API接口，使用批量put接口可以減少客戶端到RegionServer之間的RPC連接數，提高寫入性能。另外需要注意的是，批量put請求要么全部成功返回，要么拋出異常。
優化建議：使用批量put進行寫入請求
Put是否可以異步批量提交？
優化原理：業務如果可以接受異常情況下少量數據丟失的話，還可以使用異步批量提交的方式提交請求。提交分為兩階段執行：用戶提交寫請求之后，數據會寫入客戶端緩存，并返回用戶寫入成功；當客戶端緩存達到閾值（默認2M）之后批量提交給RegionServer。需要注意的是，在某些情況下客戶端異常的情況下緩存數據有可能丟失。
優化建議：在業務可以接受的情況下開啟異步批量提交
使用方式：setAutoFlush(false)
結語
所以hbase是提供對于技術的支持，但如果利用不用，hbase不為我們所用。在實際操作中我們應用要注意組件的特性以及利用特性，才能很好的為我們所有。
