一條數據的HBase之旅，簡明HBase入門教程9：RegionServer寫數據

RegionServer端處理：Region分發

RegionServer的RPC Server側，接收到來自Client端的RPC請求以后，將該請求交給Handler線程處理。

如果是single put，則該步驟比較簡單，因為在發送過來的請求參數MutateRequest中，已經攜帶了這條記錄所關聯的Region，那么直接將該請求轉發給對應的Region即可。

如果是batch puts，則接收到的請求參數為MultiRequest，在MultiRequest中，混合了這個RegionServer所持有的多個Region的寫入請求，每一個Region的寫入請求都被包裝成了一個RegionAction對象。RegionServer接收到MultiRequest請求以后，遍歷所有的RegionAction，而后寫入到每一個Region中，此過程是串行的:

Write Per Region

從這里可以看出來，并不是一個batch越大越好，大的batch size甚至可能導致吞吐量下降。

Region內部處理：寫WAL

HBase也采用了LSM-Tree的架構設計：LSM-Tree利用了傳統機械硬盤的“順序讀寫速度遠高于隨機讀寫速度”的特點。隨機寫入的數據，如果直接去改寫每一個Region上的數據文件，那么吞吐量是非常差的。因此，每一個Region中隨機寫入的數據，都暫時先緩存在內存中(HBase中存放這部分內存數據的模塊稱之為MemStore，這里僅僅引出概念，下一章節詳細介紹)，為了保障數據可靠性，將這些隨機寫入的數據順序寫入到一個稱之為WAL(Write-Ahead-Log)的日志文件中，WAL位于HDFS中，它的數據按時間順序組織：

MemStore And WAL

如果位于內存中的數據尚未持久化，而且突然遇到了機器斷電，只需要將WAL中的數據回放到Region中即可:

WAL Replay

在HBase中，默認一個RegionServer只有一個可寫的WAL文件，WAL文件位于HDFS中，因此默認也是三副本存儲的。WAL中寫入的記錄，以Entry為基本單元，而一個Entry中，包含：

WALKey?包含{Encoded Region Name，Table Name，Sequence ID，Timestamp}等關鍵信息，其中，Sequence ID在維持數據一致性方面起到了關鍵作用，可以理解為一個事務ID。

WALEdit?WALEdit中直接保存待寫入數據的所有的KeyValues，而這些KeyValues可能來自一個Region中的多行數據。

也就是說，通常，一個Region中的一個batch put請求，會被組裝成一個Entry，寫入到HDFS的WAL中：

Write into WAL

將Entry寫到文件中時是支持壓縮的，但該特性默認未開啟。

WAL進階內容

WAL Roll and Archive

當正在寫的WAL文件達到一定大小以后，會創建一個新的WAL文件，上一個WAL文件依然需要被保留，因為這個WAL文件中所關聯的Region中的數據，尚未被持久化存儲，因此，該WAL可能會被用來回放數據。

這個操作被稱之為WAL Roll。

Roll WAL

如果一個WAL中所關聯的所有的Region中的數據，都已經被持久化存儲了，那么，這個WAL文件會被暫時歸檔到HDFS的另外一個目錄中：

WAL Archive In HDFS

注意，這里不是直接將HDFS目錄中的WAL文件刪除掉，這是一種穩妥且合理的做法，原因如下：

避免因為邏輯實現上的問題導致WAL被誤刪，暫時歸檔到另外一個目錄，為錯誤發現預留了一定的時間窗口

按時間維度組織的WAL數據文件還可以被用于其它用途，如增量備份，跨集群容災等等，因此，這些位于HDFS中的WAL文件通常不允許直接被刪除，至于何時可以被清理，還需要額外的控制邏輯

另外，如果對寫入HBase中的數據的可靠性要求不高，那么，HBase允許通過配置跳過寫WAL操作。

思考：put與batch put的性能為何差別巨大？

在網絡分發上，batch put已經具備一定的優勢，因為batch put是打包分發的。

而從寫WAL這塊，看的出來，batch put寫入的一小批次Put對象，可以通過一次sync就持久化到WAL文件中了，有效減少了IOPS。

但前面也提到了，batch size并不是越大越好，因為每一個batch在RegionServer端是被串行處理的。

利用Disruptor提升寫并發性能

在高并發隨機寫入場景下，會帶來大量的WAL Sync操作，HBase中采用了Disruptor的RingBuffer來減少競爭，思路是這樣：如果將瞬間并發寫入WAL中的數據，合并執行Sync操作，可以有效降低Sync操作的次數，來提升寫吞吐量。

Multi-WAL

默認情形下，一個RegionServer只有一個被寫入的HDFS WAL Writer，盡管WAL Writer依靠順序寫提升寫吞吐量，在基于普通機械硬盤的配置下，此時只能有單塊盤發揮作用（注意：WAL位于HDFS中，因此，一個WAL Writer關聯HDFS中的三個DataNodes，這三個DataNodes中，都只能有一塊盤發揮作用），其它盤的IOPS能力并沒有被充分利用起來，這是Multi-WAL設計的初衷。Multi-WAL可以在一個RegionServer中同時啟動幾個WAL Writer，可按照一定的策略，將一個Region與其中某一個WAL Writer綁定，這樣可以充分發揮多塊盤的性能優勢。

關于WAL的未來

WAL是基于機械硬盤的IO模型設計的，而對于新興的非易失性介質，如3D XPoint，WAL未來可能會失去存在的意義，關于這部分內容，請參考文章《從HBase中移除WAL？3D XPoint技術帶來的變革》。

Region內部處理：寫MemStore

每一個Column Family，在Region內部被抽象為了一個HStore對象，而每一個HStore擁有自身的MemStore，用來緩存一批最近被隨機寫入的數據，這是LSM-Tree核心設計的一部分。

MemStore中用來存放所有的KeyValue的數據結構，稱之為CellSet，而CellSet的核心是一個ConcurrentSkipListMap，我們知道，ConcurrentSkipListMap是Java的跳表實現，數據按照Key值有序存放，而且在高并發寫入時，性能遠高于ConcurrentHashMap。

因此，寫MemStore的過程，事實上是將batch put提交過來的所有的KeyValue列表，寫入到MemStore的以ConcurrentSkipListMap為組成核心的CellSet中：

Write Into MemStore

MemStore因為涉及到大量的隨機寫入操作，會帶來大量Java小對象的創建與消亡，會導致大量的內存碎片，給GC帶來比較重的壓力，HBase為了優化這里的機制，借鑒了操作系統的內存分頁的技術，增加了一個名為MSLab的特性，通過分配一些固定大小的Chunk，來存儲MemStore中的數據，這樣可以有效減少內存碎片問題，降低GC的壓力。當然，ConcurrentSkipListMap本身也會創建大量的對象，這里也有很大的優化空間，去年阿里的一篇文章透露了阿里如何通過優化ConcurrentSkipListMap的結構來有效減少GC時間。

進階內容2：先寫WAL還是先寫MemStore?

在0.94版本之前，Region中的寫入順序是先寫WAL再寫MemStore，這與WAL的定義也相符。

但在0.94版本中，將這兩者的順序顛倒了，當時顛倒的初衷，是為了使得行鎖能夠在WAL sync之前先釋放，從而可以提升針對單行數據的更新性能。詳細問題單，請參考HBASE-4528。

在2.0版本中，這一行為又被改回去了，原因在于修改了行鎖機制以后(下面章節將講到)，發現了一些性能下降，而HBASE-4528中的優化卻無法再發揮作用，詳情請參考HBASE-15158。改動之后的邏輯也更簡潔了。

進階內容3：關于行級別的ACID

在之前的版本中，行級別的任何并發寫入/更新都是互斥的，由一個行鎖控制。但在2.0版本中，這一點行為發生了變化，多個線程可以同時更新一行數據，這里的考慮點為：

如果多個線程寫入同一行的不同列族，是不需要互斥的

多個線程寫同一行的相同列族，也不需要互斥，即使是寫相同的列，也完全可以通過HBase的MVCC機制來控制數據的一致性

當然，CAS操作(如checkAndPut)或increment操作，依然需要獨占的行鎖

更多詳細信息，可以參考HBASE-12751。

至此，這條數據已經被同時成功寫到了位于HDFS的WAL以及MemStore中：

Data Written In HBase

安全訪問控制

如何保障UserA只能寫數據到UserA的表中，以及禁止UserA改寫其它User的表的數據，HBase提供了ACL機制。ACL通常需要與Kerberos認證配合一起使用，Kerberos能夠確保一個用戶的合法性，而ACL確保該用戶僅能執行權限范圍內的操作。

HBase將權限分為如下幾類：

READ(‘R’)

WRITE(‘W’)

EXEC(‘X’)

CREATE(‘C’)

ADMIN(‘A’)

可以為一個用戶/用戶組定義整庫級別的權限集合，也可以定義Namespace、表、列族甚至是列級別的權限集合。

hbase

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。