最近的猛，Intel在HBase社區(qū)提交了一個(gè)標(biāo)題為"WALLess HBase on Persistent Memory"的問(wèn)題單寨典，將3D XPoint技術(shù)引入到HBase中氛雪，并且移除了WAL。雖然方案還沒(méi)有公布詳細(xì)的設(shè)計(jì)細(xì)節(jié)凝赛，本文借機(jī)討論HBase現(xiàn)有架構(gòu)的一些痛點(diǎn)注暗，以及利用3D XPoint技術(shù)可能為HBase帶來(lái)的一些變革。

回顧LSM-Tree

LSM-Tree設(shè)計(jì)源自Patrick O‘Neil的論文"The Log-Structured Merge-Tree"墓猎，自從Bigtable論文發(fā)布以后捆昏，該設(shè)計(jì)又被廣泛應(yīng)用于更多的NoSQL系統(tǒng)中。LSM-Tree利用了傳統(tǒng)機(jī)械硬盤的“順序讀寫(xiě)速度遠(yuǎn)高于隨機(jī)讀寫(xiě)速度”的特點(diǎn)毙沾，思路如下：

• 硬盤上存儲(chǔ)的數(shù)據(jù)根據(jù)業(yè)務(wù)需求按順序組織骗卜，實(shí)時(shí)寫(xiě)入的數(shù)據(jù)如果要即時(shí)修改存放于硬盤上的文件，會(huì)導(dǎo)致性能低下左胞，因?yàn)闀?huì)帶來(lái)大量的隨機(jī)IO寇仓。因此，實(shí)時(shí)寫(xiě)入的數(shù)據(jù)暫時(shí)緩存在內(nèi)存中的一個(gè)排序集合中烤宙，而不是直接去修改底層存儲(chǔ)的文件遍烦。

• 數(shù)據(jù)緩存在內(nèi)存中是不可靠的，因此躺枕，新寫(xiě)入的數(shù)據(jù)也會(huì)被寫(xiě)入到一個(gè)稱之為WAL(Write-Ahead-Log)的日志文件中服猪，WAL的日志按時(shí)間順序組織。顧名思義拐云，數(shù)據(jù)應(yīng)該先寫(xiě)WAL再寫(xiě)內(nèi)存罢猪，早期版本的HBase的確也是這么設(shè)計(jì)的，但后來(lái)出于性能的考慮叉瘩，HBase將這兩者的寫(xiě)入順序給顛倒了膳帕。

• 緩存在內(nèi)存中的數(shù)據(jù)達(dá)到一定的閾值之后，被Flush到硬盤中成為一個(gè)新的文件薇缅。

• 隨著Flush次數(shù)的不斷增多危彩，文件數(shù)量越來(lái)越多，而讀取時(shí)捅暴，每一個(gè)文件都可能需要被查找（例如恬砂，基于Key查詢時(shí)，每一個(gè)文件中都可能包含該Key蓬痒，因此泻骤，每一個(gè)文件都需要查看一下）漆羔，這導(dǎo)致讀取性能底下。為了改進(jìn)讀取的性能狱掂，當(dāng)文件數(shù)量達(dá)到一定大小以后演痒，多個(gè)文件會(huì)被合并成一個(gè)大文件，這里的合并帶來(lái)了一些IO資源的浪費(fèi)趋惨。當(dāng)然鸟顺，每一次合并時(shí)并不需要合并所有的文件，這里講究一定的策略器虾，主要是篩選文件的策略讯嫂，而一個(gè)NoSQL系統(tǒng)通常支持多種可配置的策略。

WAL源自LSM-Tree兆沙，但因?yàn)閃AL的數(shù)據(jù)基于“時(shí)間順序”組織欧芽，它還可以被用于其它用途：

• 用于跨集群的容災(zāi)備份

• 增量備份

• 跨系統(tǒng)數(shù)據(jù)同步

但LSM Tree存儲(chǔ)模型存在如下一些缺點(diǎn)：

1. 基于傳統(tǒng)機(jī)械硬盤的IO模型設(shè)計(jì)，對(duì)于新型的存儲(chǔ)介質(zhì)葛圃，性能優(yōu)勢(shì)無(wú)法很好的發(fā)揮出來(lái)

2. Compaction階段的層層合并帶來(lái)大量的IO資源浪費(fèi)

3. 對(duì)讀取并不太友好千扔，尤其是存在大量的待合并文件時(shí)

4. 故障恢復(fù)時(shí)，Replay-WAL通常需要耗費(fèi)數(shù)十秒甚至數(shù)分鐘的時(shí)間

5. LSM Tree的架構(gòu)僅適合存儲(chǔ)單行記錄較小的數(shù)據(jù)（最好小于KB級(jí)別）库正，對(duì)于偏大的數(shù)據(jù)曲楚，IO冗余太大

除了LSM-Tree，bitcask也是一種常見(jiàn)的存儲(chǔ)模型褥符，兩者最明顯的區(qū)別為：LSM-Tree是一種有序的數(shù)據(jù)組織龙誊，而bitcask卻是無(wú)序的，對(duì)于兩種模型更詳細(xì)的對(duì)比喷楣，本文暫不展開(kāi)载迄。

HBase現(xiàn)有架構(gòu)的痛點(diǎn)

HBase的現(xiàn)有運(yùn)行架構(gòu)，從上到下可以理解為三層：

• 數(shù)據(jù)庫(kù)邏輯實(shí)現(xiàn)層： HBase的核心數(shù)據(jù)存儲(chǔ)邏輯實(shí)現(xiàn)

• 數(shù)據(jù)復(fù)制層：通過(guò)HDFS實(shí)現(xiàn)數(shù)據(jù)的多副本復(fù)制

• 本地存儲(chǔ)層：硬盤抡蛙，本地文件系統(tǒng)以及DataNode所在層

分層的架構(gòu)，有利于一個(gè)系統(tǒng)的快速構(gòu)建魂迄，但往往帶來(lái)了一些性能上的劣勢(shì)粗截。HBase的現(xiàn)有架構(gòu)，存在如下幾個(gè)痛點(diǎn)問(wèn)題：

• 無(wú)法發(fā)揮新型存儲(chǔ)介質(zhì)的IO優(yōu)勢(shì)

基于Sata/Sas盤存儲(chǔ)時(shí)捣炬，容易發(fā)現(xiàn)部分磁盤的 IOPS會(huì)是瓶頸熊昌，一個(gè)簡(jiǎn)單的思路是將Sata/Sas盤直接替換為SSD/PCIe SSD的啡邑，但實(shí)際對(duì)比測(cè)試后會(huì)發(fā)現(xiàn)性能提升并不是特別明顯胖翰，尤其是PCIe-SSD的IO優(yōu)勢(shì)很難被發(fā)揮出來(lái)，這里有Java GC的原因（因此從HBase 2.0開(kāi)始爽彤，盡可能多的使用Offheap區(qū)的內(nèi)存來(lái)降低Heap區(qū)的GC壓力）推溃，也有架構(gòu)設(shè)計(jì)上的原因（如現(xiàn)有的RPC/WAL/MVCC等模塊以及Lock機(jī)制均存在改進(jìn)空間）昂利。值得借鑒的是，與新型硬件的結(jié)合上，ScyllaDB提供了更先進(jìn)的思路：分區(qū)與CPU Core綁定蜂奸，用戶空間的IO調(diào)度使得底層的IO能夠得到更充分的利用犁苏，對(duì)NUMA架構(gòu)友好，利用DPDK提升包處理效率等扩所，正是基于這些優(yōu)秀的設(shè)計(jì)围详，使得ScyllaDB的性能能夠達(dá)到Cassandra的10倍以上。但可惜祖屏，這些思路對(duì)于HBase而言助赞，都是要?jiǎng)訐u架構(gòu)根基的。

Facebook在Fast14上提交的論文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》中袁勺，針對(duì)Facebook Messages(縮寫(xiě)為FM)系統(tǒng)的業(yè)務(wù)模型雹食，通過(guò)模擬的方法做了系統(tǒng)的測(cè)試，最終給出了一些有價(jià)值的結(jié)論：

• FM的業(yè)務(wù)讀寫(xiě)比為99:1魁兼，而最終反映到磁盤中婉徘，讀寫(xiě)比卻變?yōu)榱?strong>36:64。WAL咐汞，HDFS Replication盖呼，Compaction以及Caching，共同導(dǎo)致了磁盤寫(xiě)IO的顯著放大化撕。

• 建議使用Flash作為Caching几晤，對(duì)于讀多寫(xiě)少的應(yīng)用而言通常能帶來(lái)明顯的性能改善。

• Local Compaction可以降低至少一半的網(wǎng)絡(luò)IO：將Compaction下移到本地存儲(chǔ)層植阴，這樣蟹瘾，Compaction執(zhí)行時(shí)讀取數(shù)據(jù)不再通過(guò)網(wǎng)絡(luò)IO而是直接從本地磁盤讀取。

• Combined Logging能使得寫(xiě)WAL的時(shí)延有6倍的提升： 現(xiàn)在的方案中掠手，一個(gè)RegionServer一個(gè)實(shí)時(shí)寫(xiě)入的WAL(暫不考慮Multi-WAL特性的前提下)憾朴，多個(gè)RegionServer則有多個(gè)WAL，對(duì)應(yīng)于HDFS中的多個(gè)不同的文件喷鸽，這會(huì)導(dǎo)致一些多余的磁盤seeks操作众雷，因此，Combined Logging考慮將多個(gè)RegionServer的WAL合并成一個(gè)WAL做祝，測(cè)試表明砾省，寫(xiě)WAL的時(shí)延能有6倍的提升，但該能力對(duì)于讀取時(shí)延的提升卻幾乎無(wú)幫助混槐。當(dāng)然编兄，這會(huì)帶來(lái)額外的系統(tǒng)復(fù)雜度。

• 低CPU使用率

該問(wèn)題對(duì)于HBase而言声登，可以說(shuō)是詬病已久狠鸳，現(xiàn)有的架構(gòu)是導(dǎo)致該問(wèn)題的關(guān)鍵原因揣苏。基于虛擬機(jī)或容器的公有云HBase服務(wù)倒是一個(gè)不錯(cuò)的解決方案碰煌，可以根據(jù)用戶實(shí)際需求分配合理的計(jì)算資源舒岸，避免計(jì)算資源浪費(fèi)。

• 讀寫(xiě)可用性偏弱

HBase依賴于HDFS的多副本機(jī)制來(lái)保障數(shù)據(jù)的可靠性芦圾，Region層其實(shí)是單副本的蛾派，而每當(dāng)RegionServer故障時(shí)，平均故障恢復(fù)時(shí)間(MTTR)通常在幾十秒甚至幾分鐘之間个少，社區(qū)花費(fèi)了大量的精力來(lái)優(yōu)化MTTR過(guò)程的每一步驟洪乍，但難有質(zhì)的提升，這與HBase的LSM-Tree架構(gòu)有關(guān)夜焦，也與HBase的“強(qiáng)一致性”語(yǔ)義承諾有關(guān)壳澳。

Region Replica特性使得Region層能夠支持多副本機(jī)制，但主副本與從副本之間的數(shù)據(jù)卻不是實(shí)時(shí)同步的茫经，在允許弱一致性讀取時(shí)巷波，對(duì)于讀的可用性是可以提升的，但應(yīng)用場(chǎng)景受限卸伞。HBase現(xiàn)有的跨集群容災(zāi)能力是異步的（同步容災(zāi)特性目前正在開(kāi)發(fā)中抹镊，由小米主導(dǎo)），但集群切換對(duì)應(yīng)用端是感知的荤傲，在實(shí)際應(yīng)用中常被用來(lái)提升數(shù)據(jù)的可靠性而不是提升服務(wù)的可用性垮耳。Facebook曾經(jīng)提過(guò)HydraBase的方案，在HBase層實(shí)現(xiàn)Raft協(xié)議遂黍，從而可以支持多HBase集群間的數(shù)據(jù)同步终佛，在讀寫(xiě)可用性上均可帶來(lái)提升，但因該方案在運(yùn)維上的巨大復(fù)雜度雾家，導(dǎo)致方案最終被放棄铃彰。

• 讀取性能與數(shù)據(jù)本地化率強(qiáng)相關(guān)

既然數(shù)據(jù)本地化率是影響讀取性能的關(guān)鍵要素，這就要求HBase與HDFS采用計(jì)算與存儲(chǔ)"邏輯分離芯咧，物理融合”的部署豌研，而這的確也是常見(jiàn)的思路，但在公有云服務(wù)中唬党，計(jì)算與存儲(chǔ)常常物理分離來(lái)降低成本，這使得數(shù)據(jù)本地化率不再有任何意義鬼佣。在物理融合的部署思路中驶拱，RegionServer與DataNode被部署在同一個(gè)物理機(jī)/虛擬機(jī)中，但偶爾的服務(wù)故障晶衷，或者是Region遷移蓝纲，都可能導(dǎo)致本地化率下降阴孟。

什么是3D XPoint

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

3D XPoint作為一種SCM(存儲(chǔ)級(jí)內(nèi)存)，相比做內(nèi)存DRAM税迷，具備數(shù)據(jù)掉電也不丟失特性永丝；相比傳統(tǒng)SSD的NAND Flash，不但讀寫(xiě)速度更快箭养，而且還支持字節(jié)級(jí)訪問(wèn)(因?yàn)?strong>NAND Flash要求必須按照Page讀寫(xiě)慕嚷，按照幾百個(gè)Page的Block擦除)。

Intel稱Optane Memory(Optane為Intel 3D XPoint技術(shù)對(duì)應(yīng)的產(chǎn)品名稱)為Apache Pass(AEP)毕泌，為高性能和靈活性而設(shè)計(jì)的革命性的SCM喝检，稱Optane NVMe SSD為Coldstream，為世界上最快撼泛、可用性和可服務(wù)性最好的SSD挠说。

3D XPoint(包括Apache Pass DIMM和Coldstream SSD)位于DRAM和NAND之間，填補(bǔ)DRAM和NAND之間的性能和時(shí)延GAP愿题。理論上损俭，3D XPoint可以比NAND快100-1000倍，Apache Pass DIMM比DRAM高出8-10倍潘酗，其成本優(yōu)勢(shì)明顯杆兵；與DRAM相比，其具有非易失性的另一大優(yōu)勢(shì)崎脉。與Flash相比拧咳，由于寫(xiě)入方式不同，Apache Pass DIMM也比Flash NAND更耐用囚灼。

從HBase中移除WAL骆膝？

既然3D XPoint的隨機(jī)IOPS性能足夠彪悍，那么灶体，設(shè)計(jì)干脆來(lái)的“任性”一些阅签，直接將WAL移除好了，這就是由Intel Anoop提交的HBASE-20003中的思路蝎抽。雖然該方案的設(shè)計(jì)細(xì)節(jié)還沒(méi)有被公布出來(lái)政钟，但從現(xiàn)有的信息可以推斷：

• 數(shù)據(jù)寫(xiě)入到Memstore，而Memstore中的數(shù)據(jù)也被同步持久化到本地AEP中樟结，寫(xiě)入過(guò)程中不再有WAL养交。也就是說(shuō)，寫(xiě)入過(guò)程中降低了對(duì)HDFS的依賴瓢宦。

• Memstore是否直接被Flush成HDFS中的HFile碎连？還是先在AEP中緩存一定數(shù)量的HFile經(jīng)Compaction過(guò)程寫(xiě)入到HDFS中？

  如果是后者驮履，則完全可以借用In-memory Flush/Compaction特性鱼辙，來(lái)降低HDFS層的IOPS廉嚼。

• 數(shù)據(jù)既然被持久化到本地AEP中，那么倒戏，如何保障數(shù)據(jù)的可靠性怠噪？

  這里可以在現(xiàn)有Region Replica(HBASE-10070)特性基礎(chǔ)上，實(shí)現(xiàn)不同的Region Replica的MemStore之間的同步復(fù)制杜跷。假設(shè)有3個(gè)副本傍念，這3個(gè)副本構(gòu)成一個(gè)Pipeline，這Pipeline中有嚴(yán)格預(yù)定義的順序葱椭，第一個(gè)副本稱之為L(zhǎng)eader捂寿，隨后的兩個(gè)副本暫且稱之為Follower 1, Follower 2。當(dāng)Commit的時(shí)候孵运，按照從后往前的順序Commit秦陋，即，Commit的順序?yàn)镕ollower 2, Follower 1, Leader治笨。關(guān)于這里的數(shù)據(jù)共識(shí)機(jī)制驳概，以及Leader Replica所在的RegionServer異常之后如何讓原來(lái)的Follower Replica升為L(zhǎng)eader，是整個(gè)方案中的難點(diǎn)之一旷赖。

• 既然數(shù)據(jù)可以在Region的多個(gè)副本中進(jìn)行同步復(fù)制顺又，讀寫(xiě)可用性均會(huì)帶來(lái)至少1個(gè)9的提升。

• Java如何直接訪問(wèn)AEP? Github中有一個(gè)關(guān)于Java訪問(wèn)pmem/AEP的項(xiàng)目"pcj"等孵，該項(xiàng)目似乎還在開(kāi)發(fā)中稚照。

如上是關(guān)于該方案的一些推斷信息。前文提到了WAL的一些其它用途俯萌，如Replication果录，增量備份，跨系統(tǒng)數(shù)據(jù)同步咐熙，如果沒(méi)有了WAL弱恒，這些能力如何實(shí)現(xiàn)？另外棋恼，寫(xiě)入盡可能的降低對(duì)HDFS的依賴以后返弹，CPU是否成為了新的瓶頸？從問(wèn)題單的信息來(lái)看爪飘，該方案原型開(kāi)發(fā)以及測(cè)試正在進(jìn)行中义起，期待能在即將公布的設(shè)計(jì)文檔中獲取更多有價(jià)值的信息。雖然該特性難以在短期內(nèi)落地师崎，但的確稱得上是一個(gè)足以動(dòng)搖HBase現(xiàn)有架構(gòu)的大特性并扇。

Reference

1. WALLess HBase on Persistent Memory
2. Analysis of HDFS Under HBase: A Facebook Messages Case Study
3. Patrick O‘Neil: The Log-Structured Merge-Tree
4. HBase read high-availability using timeline-consistent region replicas
5. 從Intel Optane系列Coldstream和AEP談全閃存性能優(yōu)化
6. Intel Optane Memory產(chǎn)品規(guī)范說(shuō)明文檔

本文首發(fā)于“NoSQL漫談(nosqlnotes.com)”
永久連接：從HBase中移除WAL？3D XPoint帶來(lái)的變革