最近，Intel在HBase社區提交了一個標題為"WALLess HBase on Persistent Memory"的問題單，將3D XPoint技術引入到HBase中，并且移除了WAL。雖然方案還沒有公布詳細的設計細節，本文借機討論HBase現有架構的一些痛點，以及利用3D XPoint技術可能為HBase帶來的一些變革。

回顧LSM-Tree

LSM-Tree設計源自Patrick O‘Neil的論文"The Log-Structured Merge-Tree"，自從Bigtable論文發布以后，該設計又被廣泛應用于更多的NoSQL系統中。LSM-Tree利用了傳統機械硬盤的“順序讀寫速度遠高于隨機讀寫速度”的特點，思路如下：

• 硬盤上存儲的數據根據業務需求按順序組織，實時寫入的數據如果要即時修改存放于硬盤上的文件，會導致性能低下，因為會帶來大量的隨機IO。因此，實時寫入的數據暫時緩存在內存中的一個排序集合中，而不是直接去修改底層存儲的文件。

• 數據緩存在內存中是不可靠的，因此，新寫入的數據也會被寫入到一個稱之為WAL(Write-Ahead-Log)的日志文件中，WAL的日志按時間順序組織。顧名思義，數據應該先寫WAL再寫內存，早期版本的HBase的確也是這么設計的，但后來出于性能的考慮，HBase將這兩者的寫入順序給顛倒了。

• 緩存在內存中的數據達到一定的閾值之后，被Flush到硬盤中成為一個新的文件。

• 隨著Flush次數的不斷增多，文件數量越來越多，而讀取時，每一個文件都可能需要被查找（例如，基于Key查詢時，每一個文件中都可能包含該Key，因此，每一個文件都需要查看一下），這導致讀取性能底下。為了改進讀取的性能，當文件數量達到一定大小以后，多個文件會被合并成一個大文件，這里的合并帶來了一些IO資源的浪費。當然，每一次合并時并不需要合并所有的文件，這里講究一定的策略，主要是篩選文件的策略，而一個NoSQL系統通常支持多種可配置的策略。

WAL源自LSM-Tree，但因為WAL的數據基于“時間順序”組織，它還可以被用于其它用途：

• 用于跨集群的容災備份

• 增量備份

• 跨系統數據同步

但LSM-Tree存儲模型存在如下一些缺點：

基于傳統機械硬盤的IO模型設計，對于新型的存儲介質，性能優勢無法很好的發揮出來

Compaction階段的層層合并帶來大量的IO資源浪費

對讀取并不太友好，尤其是存在大量的待合并文件時

故障恢復時，Replay-WAL通常需要耗費數十秒甚至數分鐘的時間

LSM Tree的架構僅適合存儲單行記錄較小的數據（最好小于KB級別），對于偏大的數據，IO冗余太大

除了LSM-Tree，bitcask也是一種常見的存儲模型，兩者最明顯的區別為：LSM-Tree是一種有序的數據組織，而bitcask卻是無序的，對于兩種模型更詳細的對比，本文暫不展開。

HBase現有架構的痛點

HBase的現有運行架構，從上到下可以理解為三層：

• 數據庫邏輯實現層： HBase的核心數據存儲邏輯實現

• 數據復制層：通過HDFS實現數據的多副本復制

• 本地存儲層：硬盤，本地文件系統以及DataNode所在層

分層的架構，有利于一個系統的快速構建，但往往帶來了一些性能上的劣勢。HBase的現有架構，存在如下幾個痛點問題：

• 無法發揮新型存儲介質的IO優勢

基于Sata/Sas盤存儲時，容易發現部分磁盤的 IOPS會是瓶頸，一個簡單的思路是將Sata/Sas盤直接替換為SSD/PCIe SSD的，但實際對比測試后會發現性能提升并不是特別明顯，尤其是PCIe-SSD的IO優勢很難被發揮出來，這里有Java GC的原因（因此從HBase 2.0開始，盡可能多的使用Offheap區的內存來降低Heap區的GC壓力），也有架構設計上的原因（如現有的RPC/WAL/MVCC等模塊以及Lock機制均存在改進空間）。值得借鑒的是，與新型硬件的結合上，ScyllaDB提供了更先進的思路：分區與CPU Core綁定，用戶空間的IO調度使得底層的IO能夠得到更充分的利用，對NUMA架構友好，利用DPDK提升包處理效率等，正是基于這些優秀的設計，使得ScyllaDB的性能能夠達到Cassandra的10倍以上。但可惜，這些思路對于HBase而言，都是要動搖架構根基的。

Facebook在Fast14上提交的論文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》中，針對Facebook Messages(縮寫為FM)系統的業務模型，通過模擬的方法做了系統的測試，最終給出了一些有價值的結論：

• FM的業務讀寫比為99:1，而最終反映到磁盤中，讀寫比卻變為了36:64。WAL，HDFS Replication，Compaction以及Caching，共同導致了磁盤寫IO的顯著放大。

• 建議使用Flash作為Caching，對于讀多寫少的應用而言通常能帶來明顯的性能改善。

• Local Compaction可以降低至少一半的網絡IO：將Compaction下移到本地存儲層，這樣，Compaction執行時讀取數據不再通過網絡IO而是直接從本地磁盤讀取。

• Combined Logging能使得寫WAL的時延有6倍的提升： 現在的方案中，一個RegionServer一個實時寫入的WAL(暫不考慮Multi-WAL特性的前提下)，多個RegionServer則有多個WAL，對應于HDFS中的多個不同的文件，這會導致一些多余的磁盤seeks操作，因此，Combined Logging考慮將多個RegionServer的WAL合并成一個WAL，測試表明，寫WAL的時延能有6倍的提升，但該能力對于讀取時延的提升卻幾乎無幫助。當然，這會帶來額外的系統復雜度。

• 低CPU使用率

該問題對于HBase而言，可以說是詬病已久，現有的架構是導致該問題的關鍵原因?；谔摂M機或容器的公有云HBase服務倒是一個不錯的解決方案，可以根據用戶實際需求分配合理的計算資源，避免計算資源浪費。

• 讀寫可用性偏弱

HBase依賴于HDFS的多副本機制來保障數據的可靠性，Region層其實是單副本的，而每當RegionServer故障時，平均故障恢復時間(MTTR)通常在幾十秒甚至幾分鐘之間，社區花費了大量的精力來優化MTTR過程的每一步驟，但難有質的提升，這與HBase的LSM-Tree架構有關，也與HBase的“強一致性”語義承諾有關。

Region Replica特性使得Region層能夠支持多副本機制，但主副本與從副本之間的數據卻不是實時同步的，在允許弱一致性讀取時，對于讀的可用性是可以提升的，但應用場景受限。HBase現有的跨集群容災能力是異步的（同步容災特性目前正在開發中，由小米主導），但集群切換對應用端是感知的，在實際應用中常被用來提升數據的可靠性而不是提升服務的可用性。Facebook曾經提過HydraBase的方案，在HBase層實現Raft協議，從而可以支持多HBase集群間的數據同步，在讀寫可用性上均可帶來提升，但因該方案在運維上的巨大復雜度，導致方案最終被放棄。

• 讀取性能與數據本地化率強相關

既然數據本地化率是影響讀取性能的關鍵要素，這就要求HBase與HDFS采用計算與存儲"邏輯分離，物理融合”的部署，而這的確也是常見的思路，但在公有云服務中，計算與存儲常常物理分離來降低成本，這使得數據本地化率不再有任何意義。在物理融合的部署思路中，RegionServer與DataNode被部署在同一個物理機/虛擬機中，但偶爾的服務故障，或者是Region遷移，都可能導致本地化率下降。

什么是3D XPoint?

如下信息摘自《從Intel Optane系列Coldstream和AEP談全閃存性能優化》一文：

3D XPoint作為一種SCM(存儲級內存)，相比做內存DRAM，具備數據掉電也不丟失特性；相比傳統SSD的NAND Flash，不但讀寫速度更快，而且還支持字節級訪問(因為NAND Flash要求必須按照Page讀寫，按照幾百個Page的Block擦除)。

Intel稱Optane Memory(Optane為Intel 3D XPoint技術對應的產品名稱)為Apache Pass(AEP)，為高性能和靈活性而設計的革命性的SCM，稱Optane NVMe SSD為Coldstream，為世界上最快、可用性和可服務性最好的SSD。

3D XPoint(包括Apache Pass DIMM和Coldstream SSD)位于DRAM和NAND之間，填補DRAM和NAND之間的性能和時延GAP。理論上，3D XPoint可以比NAND快100-1000倍，Apache Pass DIMM比DRAM高出8-10倍，其成本優勢明顯；與DRAM相比，其具有非易失性的另一大優勢。與Flash相比，由于寫入方式不同，Apache Pass DIMM也比Flash NAND更耐用。

從HBase中移除WAL?

既然3D XPoint的隨機IOPS性能足夠彪悍，那么，設計干脆來的“任性”一些，直接將WAL移除好了，這就是由Intel Anoop提交的HBASE-20003中的思路。雖然該方案的設計細節還沒有被公布出來，但從現有的信息可以推斷：

• 數據寫入到Memstore，而Memstore中的數據也被同步持久化到本地AEP中，寫入過程中不再有WAL。也就是說，寫入過程中降低了對HDFS的依賴。

• Memstore是否直接被Flush成HDFS中的HFile？還是先在AEP中緩存一定數量的HFile經Compaction過程寫入到HDFS中？如果是后者，則完全可以借用In-memory Flush/Compaction特性，來降低HDFS層的IOPS。

• 數據既然被持久化到本地AEP中，那么，如何保障數據的可靠性？這里可以在現有Region Replica(HBASE-10070)特性基礎上，實現不同的Region Replica的MemStore之間的同步復制。假設有3個副本，這3個副本構成一個Pipeline，這Pipeline中有嚴格預定義的順序，第一個副本稱之為Leader，隨后的兩個副本暫且稱之為Follower 1, Follower 2。當Commit的時候，按照從后往前的順序Commit，即，Commit的順序為Follower 2, Follower 1, Leader。關于這里的數據共識機制，以及Leader Replica所在的RegionServer異常之后如何讓原來的Follower Replica升為Leader，是整個方案中的難點之一。

• 既然數據可以在Region的多個副本中進行同步復制，讀寫可用性均會帶來至少1個9的提升。

• Java如何直接訪問AEP? Github中有一個關于Java訪問pmem/AEP的項目"pcj"，該項目似乎還在開發中。

如上是關于該方案的一些推斷信息。前文提到了WAL的一些其它用途，如Replication，增量備份，跨系統數據同步，如果沒有了WAL，這些能力如何實現？另外，寫入盡可能的降低對HDFS的依賴以后，CPU是否成為了新的瓶頸？從問題單的描述信息來看，該方案原型開發以及測試正在進行中，期待能在即將公布的設計文檔中獲取更多有價值的信息。雖然該特性難以在短期內落地，但的確稱得上是一個足以動搖HBase現有架構的大特性。

參考信息

WALLess HBase on Persistent Memory

Analysis of HDFS Under HBase: A Facebook Messages Case Study

Patrick O‘Neil: The Log-Structured Merge-Tree

HBase read high-availability using timeline-consistent region replicas

從Intel Optane系列Coldstream和AEP談全閃存性能優化

Intel Optane Memory產品規范說明文檔

總結

以上是生活随笔為你收集整理的从HBase中移除WAL？3D XPoint技术带来的变革的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。