[[321376]]

在各行各業(yè)紛紛結(jié)合自身需求，加快自主改造和研發(fā)腳步的當下，涌現(xiàn)出許多值得學習借鑒的優(yōu)秀項目。本期將詳述光大銀行首個獨立研發(fā)的基礎(chǔ)軟件Pharos，如何從HBase二級索引出發(fā)，提升多條件復(fù)雜查詢的性能，拓展HBase的數(shù)據(jù)使用模式，應(yīng)對海量數(shù)據(jù)低延時復(fù)雜查詢。

自研背景

可插拔的HBase索引組件

NoSQL興起無疑是大數(shù)據(jù)時代的標志性事件，創(chuàng)新者們不斷打破關(guān)系型數(shù)據(jù)庫“一種存儲模式解決所有問題”的思路，發(fā)明了很多不同的產(chǎn)品應(yīng)對細分的數(shù)據(jù)訪問模式，它們提供了更好的服務(wù)特性，比如低延時、高并發(fā)等等。HBase是其中極具代表性的產(chǎn)品，作為Hadoop生態(tài)體系的明星產(chǎn)品，時至今日已在很多企業(yè)得到廣泛應(yīng)用。

NoSQL這種為特定的數(shù)據(jù)使用模式設(shè)計存儲系統(tǒng)的思路，收獲了性能的大幅提升，但隨著存儲數(shù)據(jù)量的激增，對解決方案整體性價比的滿意度卻在不斷走低。畢竟，相較幾個TB和數(shù)百TB，存儲成本對用戶的沖擊力是不同的，人們總是不滿于線性增長的成本，希望能花更少的錢做更多的事。

通過適度拓展數(shù)據(jù)訪問模式提升性價比，成為業(yè)內(nèi)很多技術(shù)方案追求的目標。

光大銀行是金融行業(yè)中較早引入HBase的，經(jīng)過若干年建設(shè)已經(jīng)積累了大量數(shù)據(jù)。如果僅是為了滿足不同條件的查詢，就copy一個同等規(guī)模的集群，是各方都難以接受的。

HBase作為一種KV數(shù)據(jù)庫，數(shù)據(jù)訪問模式以主鍵為核心，當面對非主鍵查詢時，其原生解決方案Filter無法滿足大多數(shù)聯(lián)機應(yīng)用的性能需求。所以，很多基于HBase的二級索引方案都在嘗試應(yīng)對復(fù)雜查詢場景的需求。

Pharos是基于HBase的技術(shù)中間件，研究起點同樣是二級索引，致力于提升多條件復(fù)雜查詢的性能，應(yīng)用在海量數(shù)據(jù)低延時復(fù)雜查詢場景。

構(gòu)建思路

三種二級索引方案的選型與分析

在啟動研發(fā)工作前，我們對現(xiàn)存的二級索引方案進行了分析，除原生Filter外大致可以分為三種。

Elastic Search + HBase

這個方案流行度最高，在ES中存儲索引信息，HBase存儲數(shù)據(jù)本身，兩者協(xié)同完成索引查詢。方案的優(yōu)點是組合成熟產(chǎn)品，實施難度低;但缺點也有很多，首先是整體架構(gòu)復(fù)雜、設(shè)備投入增加、運維成本高;其次是性能相對較低，每一次索引查詢，都要先訪問ES獲得匹配的索引后，再訪問HBase讀取數(shù)據(jù)內(nèi)容，查詢鏈路延長，帶來更多的網(wǎng)絡(luò)開銷;最后是開發(fā)技能要求較高，程序員必須熟悉ES和HBase兩種產(chǎn)品接口。

Phoenix

Phoenix無疑是一款優(yōu)秀的開源產(chǎn)品，產(chǎn)品的理念是Put the SQL back in NoSQL。產(chǎn)品成熟，Apache社區(qū)背書，都是該方案的優(yōu)勢。

但因為目標高遠，Phoenix的體量也偏重，這樣在沒有商業(yè)廠商支持下，運維難度很高(2019年Cloudera宣布支持Phoenix后，可能會有所改善)。第二點，對SQL的支持成為它的核心目標，但在很多查詢場景中，SQL并非不可替代，高性能才是首要目標，性能卻是Phoenix尚待改進的地方。Phoenix在整體機制上，并沒有實現(xiàn)完善的索引下推，很多情況下索引查詢需要從客戶端發(fā)起兩次與服務(wù)端的交互，第一次獲得匹配的索引信息，第二次才是匹配的數(shù)據(jù)，這無疑帶來了性能損耗。

云廠商方案

在云計算時代，HBase已經(jīng)成為云服務(wù)的標配，部分公有云也提供了二級索引功能。這個方案的優(yōu)點當然是廠商的一站式服務(wù)，運維成本極低。缺點首先是部分企業(yè)因為安全因素無法使用公有云，例如金融行業(yè);其次在于技術(shù)方案本身，例如阿里的HBase二級索引，其內(nèi)核依然是Elastic與HBase的組合，雖然接口上進行封裝降低了開發(fā)難度，但架構(gòu)帶來的性能損耗依舊存在。

通過上述的分析，我們發(fā)現(xiàn)這些方案都不能滿足光大銀行的應(yīng)用場景，因此我們決定自研產(chǎn)品。

我們將產(chǎn)品命名為Pharos，源自英文單詞 [Pharos]，其含義是燈塔。這個名稱有兩層含義：

• 第一層是詞義本身，燈塔對夜行的船只進行指引保證其安全地出入港口。而索引指向符合條件的數(shù)據(jù)地址，用于提升每次查數(shù)據(jù)訪問操作的效率，兩者有神似之處;
• 第二層含義，Pharos最初是指代亞歷山大燈塔，這也是世界上第一座燈塔。而Pharos是光大銀行首次嘗試自研基礎(chǔ)產(chǎn)品，我們希望這個命名能夠激勵團隊，做出有開創(chuàng)意義的產(chǎn)品。

設(shè)計目標

低延時，架構(gòu)簡單，非侵入性

在Pharos設(shè)計目標中最重要的有三點：

1. 低延時：我們希望未來Pharos的應(yīng)用場景不僅限于數(shù)據(jù)查詢分析，也能夠嵌入到業(yè)務(wù)交易系統(tǒng)中，這樣低延時就是一個剛性需求;
2. 架構(gòu)簡單：這樣開發(fā)人員可以很容易上手使用，而運維的成本也很低;
3. 非侵入性：是指對HBase的侵入，事實上除了前述分析的二級索引方案外，還有一些小眾的二級索引方案是直接對HBase進行改造，但這種侵入式改造帶來了后續(xù)的版本維護問題，考慮到多數(shù)企業(yè)不可能維護獨立的HBase版本分支，我們的方案直接排除了這種技術(shù)路線，必須是對HBase非侵入的。

 

 

 

 

Pharos的研發(fā)是從2018年開始的，相對于目前的產(chǎn)品成熟度來說研發(fā)過程顯得有點長，主要原因是開發(fā)人力投入相對較小。我們希望隨著產(chǎn)品的應(yīng)用推廣，能擴充人員，加快產(chǎn)品的演進速度。

研發(fā)過程，我們受到了很多同類產(chǎn)品的啟發(fā)，包括Phoenix、華為與360等公司的二級索引方案，也借鑒了很多好的設(shè)計方法，這里要特別致敬一下。

設(shè)計要點

四大關(guān)鍵設(shè)計的權(quán)衡

前面講了Pharos的外部特性，接下來我會著重講一些關(guān)鍵設(shè)計時的tradeoff，希望對大家的研發(fā)工作有所幫助。

存儲策略

HBase是沒有索引概念的，我們首先要解決的是如何存儲索引。

Pharos采用的方式是在數(shù)據(jù)表增加一個“獨立列族”用于存儲索引信息，利用列族對應(yīng)獨立文件的特點，形成獨立的索引文件，不會直接受到原始數(shù)據(jù)量的影響，降低磁盤I/O開銷。這個設(shè)計另一個好處在于，索引與數(shù)據(jù)同分布，不必干預(yù)HBase的Region分布策略。后續(xù)的所有設(shè)計都是在同Region基礎(chǔ)上，這大大簡化了實現(xiàn)的復(fù)雜度。

 

 

 

 

這種索引與數(shù)據(jù)同分布的模式，可以簡稱為“分區(qū)索引”;而索引與數(shù)據(jù)各自存儲的方式，則成為“全局索引”。“全局索引”的缺點在于無法完成索引查詢的下推，優(yōu)點是可以進行全局控制，例如唯一索引。選擇“分區(qū)索引”是因為我們期望實現(xiàn)低延時目標，當然同時也就放棄了對“唯一索引”的支持，至少目前是不支持的。

存儲模型

索引記錄的Key部分，最開始是Region頭信息，保證與數(shù)據(jù)的同分布，而后是被索引字段的信息，接下來是存儲索引名稱等信息，數(shù)據(jù)記錄的Key則被拼接為尾部信息;value部分則存儲反序列化的元數(shù)據(jù)。

 

 

 

 

可以看到，這樣設(shè)計的優(yōu)點是索引檢索速度快，存儲成本也比較小。所以，當查詢條件較復(fù)雜需要建立多個索引時，整體存儲成本依然是可接受的。

分頁機制

傳統(tǒng)的后臺分頁方法是由應(yīng)用服務(wù)記錄每頁的末尾記錄主鍵，這個主鍵通常是由數(shù)據(jù)庫提供的row number，數(shù)據(jù)庫本身并不感知分頁動作。對于分布式存儲的HBase，每個Region都可能存在分頁斷點，如果延續(xù)該思路，應(yīng)用端要記錄大量斷點信息，不僅增加傳輸數(shù)據(jù)量，也增大了開發(fā)的難度。在Pharos的設(shè)計中，我們通過Client作為匯聚點，緩存每個Region的斷點信息，在Pharos的Client中增加Session概念，應(yīng)用端僅需持有Session ID即可順利完成翻頁操作。

 

 

 

 

索引與數(shù)據(jù)的事務(wù)一致性(實驗版本)

根據(jù)Pharos的存儲設(shè)計，我們可以知道索引實質(zhì)上是與數(shù)據(jù)行前綴相同的另一行記錄，保證索引與數(shù)據(jù)的一致性要使用跨行事務(wù)，但HBase本身不支持跨表、跨行事務(wù)，這就成為一個死結(jié)，也是幾乎所有二級索引方案都不支持索引事務(wù)一致性的原因。

這個問題的解決比較復(fù)雜，所以我們先簡單介紹下HBase內(nèi)部機制。HBase采用LSM-Tree模型，在聯(lián)機寫入時，數(shù)據(jù)在日志和內(nèi)存中各保留一份，兩者通過MVCC與日志的協(xié)調(diào)機制可以保證事務(wù)一致性。我畫了一張圖來表示HBase 1.2.6的事務(wù)控制邏輯，具體如下：

 

 

 

 

HBase內(nèi)部會監(jiān)控WAL的異常，但在Coprocessor事件體系中并未開“回滾標志位”，第三方開發(fā)者也就無法回滾相關(guān)數(shù)據(jù)行。

按說，到這里問題已經(jīng)無解了，不過某天恰好受到了Percolator事務(wù)模型的啟發(fā)，找到了另一種解決問題的思路。既然無法在寫入過程通過回滾控制異常情況，那我們可以延后在讀取過程中來補充對異常的操作，也就是說在下一次查詢操作中再次確認并維護索引的一致性。

具體處理過程是，在首次寫入索引信息時，置事務(wù)標志位為“不確定”，數(shù)據(jù)行更新完成后，將該標志改為“成功”;如果出現(xiàn)回滾，則標志位保留“不確定”狀態(tài)。查詢操作中一旦發(fā)現(xiàn)“不確定”標志，則根據(jù)索引查找相應(yīng)的數(shù)據(jù)行是否存在，如存在，則將該標志更新為“成功”。

我們用流程圖來體現(xiàn)處理過程，如下圖：

 

 

 

 

該方式付出的代價是寫入時需要兩次更新事務(wù)標志，相對于僅寫入數(shù)據(jù)行(無索引)肯定增加了一些開銷，在測試環(huán)境下我們發(fā)現(xiàn)損耗在15%左右，主要是指延時;在查詢環(huán)節(jié)雖然存在確認索引事務(wù)的可能性，但因為其發(fā)生的概率極低，不會對查詢產(chǎn)生實質(zhì)性影響。

未來展望

徹底解決Region分裂問題

目前Pharos主要還是在內(nèi)部使用場景中測試，收集需求和問題，近期我們會發(fā)布V0.3版本。新版本會推出一些讓人激動的特性，主要仍是圍繞查詢性能的提升，推出Pharos自有的數(shù)據(jù)組織形式，提供更加豐富的查詢加速手段，完成從二級索引組件到一個完整的技術(shù)中間件的演進。

其中，特別重要的一點是徹底解決了Region分裂問題，我要迫不及待地做個劇透。

Region分裂是HBase數(shù)據(jù)再平衡的手段，保證每個數(shù)據(jù)節(jié)點上的數(shù)據(jù)量分布大致平均，也會有一些打散熱點的效果。但是，分裂機制卻破壞了索引與數(shù)據(jù)的同分布，在同類方案中通常采用很重的更新操作來調(diào)整索引的位置，追隨數(shù)據(jù)的分布情況。

這種方式顯得過于笨拙，并且更新過程會影響整體方案的可用性。因此，Pharos在V0.22版本中是建議索引延后加載，這樣在數(shù)據(jù)更新導致的重分布完成后再更新索引。

實際操作中，這種方式要重復(fù)讀取數(shù)據(jù)文件，延長了整體數(shù)據(jù)加載周期，對運維操作來說不夠友好。在V0.3中，我們加入了Pharos自有的數(shù)據(jù)組織方式，實現(xiàn)在Region分裂時維持索引的同分布效果。

作者介紹

王磊(Ivan)，光大銀行科技部數(shù)據(jù)領(lǐng)域架構(gòu)師，曾任職于IBM全球咨詢服務(wù)部從事技術(shù)咨詢工作，具有十余年數(shù)據(jù)領(lǐng)域研發(fā)及咨詢經(jīng)驗。目前負責全行數(shù)據(jù)領(lǐng)域系統(tǒng)的日常架構(gòu)管理、重點系統(tǒng)架構(gòu)設(shè)計及內(nèi)部研發(fā)等工作，對分布式數(shù)據(jù)庫、Hadoop等基礎(chǔ)架構(gòu)研究有濃厚興趣。

本文轉(zhuǎn)載自微信公眾號「DBAplus社群」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系DBAplus社群公眾號。