阿里云HBase增強(qiáng)版(Lindorm)簡介
阿里云數(shù)據(jù)庫HBase增強(qiáng)版，是基于阿里集團(tuán)內(nèi)部使用的Lindorm產(chǎn)品研發(fā)的、完全兼容HBase的云上托管數(shù)據(jù)庫，從2011年開始正式承載阿里內(nèi)部業(yè)務(wù)的海量數(shù)據(jù)實(shí)時(shí)存儲(chǔ)需求，支撐服務(wù)了淘寶、支付寶、菜鳥、優(yōu)酷、高德等業(yè)務(wù)中的大量核心應(yīng)用，歷經(jīng)雙十一、春晚、十一出行節(jié)等場(chǎng)景的大規(guī)模考驗(yàn)，在成本、性能、穩(wěn)定性、功能、安全、易用性等方面相比社區(qū)版擁有諸多優(yōu)勢(shì)和企業(yè)級(jí)能力，更多介紹可以參考Lindorm幫助文檔（https://help.aliyun.com/document_detail/119548.html）
當(dāng)大數(shù)據(jù)存儲(chǔ)遇上復(fù)雜查詢
HBase是目前廣泛使用的NoSQL數(shù)據(jù)庫，其具有Schemeless特性，高吞吐，海量存儲(chǔ)和無限水平擴(kuò)展的特性，因此被很好地應(yīng)用在了推薦、風(fēng)控、物聯(lián)網(wǎng)、畫像、表單等所有大數(shù)據(jù)場(chǎng)景。但是原生的HBase只支持Rowkey索引，即按rowkey的二進(jìn)制排序的索引。HBase的Scan請(qǐng)求可基于此rowkey索引高效的執(zhí)行整行匹配、前綴匹配、范圍查詢等操作。但若需要使用rowkey之外的列進(jìn)行查詢，則只能使用filter在指定的rowkey范圍內(nèi)進(jìn)行逐行過濾。若無法指定rowkey范圍，則需進(jìn)行全表掃描，不僅浪費(fèi)大量資源，查詢RT也無法保證。
為了解決用戶基于非主鍵列的查詢問題，阿里云HBase增強(qiáng)版(Lindorm)內(nèi)置原生的全局二級(jí)索引功能，對(duì)于列較少且有固定查詢模式的場(chǎng)景來說，阿里云的高性能二級(jí)索引方案能夠完美解決此類問題，同時(shí)仍保持強(qiáng)大的吞吐與性能。這個(gè)索引方案在阿里內(nèi)部使用多年，經(jīng)歷了多次雙11考驗(yàn)，尤其適合解決海量數(shù)據(jù)的全局索引場(chǎng)景。關(guān)于高性能二級(jí)索引，用戶可以參考《數(shù)據(jù)查詢的玄鐵劍：Lindorm二級(jí)索引功能解析》一文（https://developer.aliyun.com/article/740009 ), 同時(shí)，社區(qū)也有Phoenix，在HBase之上提供了插件式的二級(jí)索引以及SQL能力，使用SQL可以比較簡單地表達(dá)一些復(fù)雜查詢。
但是，當(dāng)面對(duì)更加復(fù)雜的查詢，比如表單、日志查詢里面的模糊查找，用戶畫像里面的隨機(jī)條件組合查詢等等，二級(jí)索引方案會(huì)顯得力不從心。而這些查詢，正是搜索引擎的優(yōu)勢(shì)。
Solr是分布式全文檢索的最佳實(shí)踐之一。Solr支持各種復(fù)雜的條件查詢和全文索引。通過智能集成Solr，Lindorm可以充分發(fā)揮海量數(shù)據(jù)的實(shí)時(shí)存儲(chǔ)和檢索能力，使得其可以高效支撐于：需要保存大數(shù)據(jù)量數(shù)據(jù)，而查詢條件的字段數(shù)據(jù)僅占原數(shù)據(jù)的一小部分，并且需要各種條件組合查詢的業(yè)務(wù)。例如：
- • 常見物流業(yè)務(wù)場(chǎng)景，需要存儲(chǔ)大量軌跡物流信息，并需根據(jù)多個(gè)字段任意組合查詢條件
- • 交通監(jiān)控業(yè)務(wù)場(chǎng)景，保存大量過車記錄，同時(shí)會(huì)根據(jù)車輛信息任意條件組合檢索出感興趣的記錄
- • 各種網(wǎng)站會(huì)員、商品信息檢索場(chǎng)景，一般保存大量的商品/會(huì)員信息，并需要根據(jù)少量條件進(jìn)行復(fù)雜且任意的查詢，以滿足網(wǎng)站用戶任意搜索需求等。
數(shù)據(jù)同步的難題
要想在Lindorm中集成Solr，必須想辦法將業(yè)務(wù)寫入Lindorm的主表數(shù)據(jù)實(shí)時(shí)索引到Solr中，然而存儲(chǔ)主表數(shù)據(jù)的寬表引擎和存儲(chǔ)索引數(shù)據(jù)的Solr檢索引擎有很大的差異性，比如數(shù)據(jù)模型上，兩者差別較大，寫入能力上，也有巨大的差異。針對(duì)寬表與檢索兩種異構(gòu)引擎間的數(shù)據(jù)同步，目前市面上主要有兩種類似的方案：
應(yīng)用雙寫
雙寫是最容易想到，也是最容易實(shí)現(xiàn)的方案。以用戶自己維護(hù)的雙寫HBase+Solr為例：業(yè)務(wù)將數(shù)據(jù)寫入HBase的同時(shí)，也將同樣的數(shù)據(jù)寫入Solr即可。有些用戶使用了HBase的Coprocessor功能，hook了HBase的寫入邏輯，在HBase完成寫入時(shí)，在Coprocessor中寫入solr，本質(zhì)上也是雙寫HBase和Solr
但雙寫HBase和Solr存在非常多的問題，需要用戶自己去解決：一致性難以保證
- 當(dāng)HBase寫入成功，Solr寫入失敗，或者HBase寫入失敗，Solr寫入成功都會(huì)造成數(shù)據(jù)不一致，用戶需要自己處理此類情況。
- HBase支持更新部分列，而Solr只能整行更新，因此當(dāng)更新HBase后，還需要在HBase中讀取整行數(shù)據(jù)，才能寫入Solr，當(dāng)有多個(gè)線程同時(shí)修改一行時(shí)，會(huì)導(dǎo)致HBase和Solr中的數(shù)據(jù)不一致。
- 就算用戶寫入HBase時(shí)是整行全量更新，無需回讀，寫入HBase和寫入Solr并不是原子更新，很難保證HBase的寫入順序跟Solr中的修改順序一致從而導(dǎo)致數(shù)據(jù)不一致問題
穩(wěn)定性降低雙寫HBase和Solr等于把HBase和Solr的可用性捆綁在了一起。Solr的可用性會(huì)反過來影響HBase的可用性。一旦Solr出現(xiàn)問題，用戶要么選擇放棄寫Solr，放棄數(shù)據(jù)一致性來確保可用性，要么只能無限重試等待Solr恢復(fù)來確保數(shù)據(jù)一致性，但降低了可用性。在HBase的Coprocessor中寫Solr的用戶的穩(wěn)定性問題尤為突出，如果用戶沒有處理好Solr的拋錯(cuò)和重試時(shí)的內(nèi)存管理，很容易直接造成HBase RegionServer的宕機(jī)。讀寫能力下降很多用戶選擇HBase的主要原因是HBase具有海量吞吐能力，而現(xiàn)在雙寫Solr等于將HBase的寫入能力拉低到了Solr的水平，大部分業(yè)務(wù)都無法接受。同時(shí)雙寫時(shí)需要回讀HBase獲取整行數(shù)據(jù)，回讀會(huì)造成HBase額外的壓力，從而進(jìn)一步降低了HBase的讀寫能力
開源Lily HBase Indexer
Lily HBase Indexer（下文簡稱Indexer）是Cloudera推出的HBase和Solr之間的數(shù)據(jù)同步組件。他利用了HBase的Replication功能，將自己"偽裝"成一個(gè)HBase的Replication sink集群，當(dāng)HBase有數(shù)據(jù)寫入時(shí)，Replication會(huì)通過讀取WAL文件獲取最新更新傳輸?shù)絀ndexer里，然后再由Indexer寫入Solr。
同樣，這套方案也存在大量問題：同步效率低
- Indexer使用的是Replication框架。在Replication框架下，一行數(shù)據(jù)的更新需要先要序列化寫入WAL，然后通過Replication從WAL中讀出反序列化，然后序列化成二進(jìn)制數(shù)據(jù)發(fā)送到Indexer，Indexer再反序列化成數(shù)據(jù)才能寫入Solr。整個(gè)過程非常低效，同步的速率受限于HBase的Replication能力，往往Solr的寫入瓶頸還沒達(dá)到，就已經(jīng)達(dá)到了HBase的Replication瓶頸。
- Indexer的同步模型是每一個(gè)HBase表，都開啟一條Replication通道（一個(gè)Replication Peer）。有10張HBase表需要同步到Solr，就必須有10個(gè)Replication Peer，這意味著同一個(gè)WAL，會(huì)被讀取10次（每個(gè)peer都讀取一次）隨著同步表的增多，對(duì)HDFS的壓力也就越大。
- 由于HBase是SchemaLess的，Indexer收到Replication發(fā)過來的WAL后，無法知道是否在WAL中有整行數(shù)據(jù)，因此它必須在寫Solr之前回讀HBase獲取整行數(shù)據(jù)。因此實(shí)際上，WAL中的entry發(fā)送過來后，有用的只有rowkey，其他的數(shù)據(jù)還是要依靠回讀，這些WAL entry經(jīng)歷了這么長的發(fā)送鏈路，但大部分信息卻是無用的。同時(shí)，回讀會(huì)占用HBase資源，影響HBase穩(wěn)定性。
數(shù)據(jù)一致性無法保證使用Indexer同步HBase到Solr會(huì)經(jīng)常遇到兩者之間數(shù)據(jù)不一致的問題，這也是Indexer的用戶吐槽最多的地方。
這些不一致往往發(fā)生的非常隨機(jī)，一般用戶也很難查到原因，讓人摸不到頭腦。我們深入研究Indexer后發(fā)現(xiàn)了他的問題所在。由于Indexer依賴了HBase的Replication做同步，而HBase Replication有一個(gè)重要的特點(diǎn)就是亂序發(fā)送，這對(duì)于HBase集群之間的Replication無影響，因?yàn)镠Base可以用KV的時(shí)間戳來保證最終一致。但是Solr是不支持列時(shí)間戳的，HBase的寫入亂序到達(dá)Indexer會(huì)導(dǎo)致寫入Solr中的數(shù)據(jù)與HBase不一致。
比如用戶有兩次更新同一行,。但是在replication過程中， ts2的更新先到Indexer，而ts1的更新后到，這會(huì)導(dǎo)致Indexer將Solr中的這行的數(shù)據(jù)更新成value1，導(dǎo)致HBase和Solr的數(shù)據(jù)不一致。另外，由于HBase是先寫WAL再內(nèi)存可見，在回讀HBase過程中，Indexer也可能沒有獲取到最新數(shù)據(jù)導(dǎo)致Solr數(shù)據(jù)不一致。
同時(shí)HBase支持多family，多版本，自定義時(shí)間戳，各種類型的刪除，Solr模型的支持比較有限，Indexer沒有處理好這些問題，我們發(fā)現(xiàn)有多個(gè)case都會(huì)導(dǎo)致HBase和Solr的數(shù)據(jù)不一致，這里就不一一列舉了。Indexer官方已經(jīng)不再維護(hù)Indexer社區(qū)代碼已經(jīng)4年沒有更新，所有的這些問題都不會(huì)再修復(fù)，這也是使用Indexer的最大風(fēng)險(xiǎn)，面對(duì)這些問題和bug，用戶只能自行解決。
云HBase增強(qiáng)版(Lindorm)全文索引
通過分析應(yīng)用雙寫和開源的Lily HBase Indexer存在的種種問題，Lindorm在研發(fā)全文索引功能時(shí)，從中吸取相關(guān)經(jīng)驗(yàn)，進(jìn)行創(chuàng)新的設(shè)計(jì)，使得寬表和檢索兩類引擎正確而自然的結(jié)合在一起，方便用戶即開即用。
在此方案中，我們選用了自研的BDS組件做Lindorm的寬表引擎到Solr檢索引擎間的數(shù)據(jù)同步。BDS是一個(gè)cloud native的HBase生態(tài)數(shù)據(jù)同步服務(wù)，可以提供高效的數(shù)據(jù)實(shí)時(shí)同步和全量遷移能力，關(guān)于BDS的介紹，用戶可以參照《BDS - HBase數(shù)據(jù)遷移同步方案的設(shè)計(jì)與實(shí)踐》一文(https://yq.aliyun.com/articles/704977 )。
在此方案中，我們使用BDS完美解決了Lindorm的寬表引擎和檢索引擎Solr因?yàn)槟Ｐ筒灰恢拢琖AL亂序等等問題帶來的數(shù)據(jù)不一致問題。不管用戶是部分更新，多版本，自定義時(shí)間戳，多family寫入，還是刪除行、列，兩個(gè)引擎之間的數(shù)據(jù)都不會(huì)產(chǎn)生不一致問題（具體的做法在申請(qǐng)專利中，專利申請(qǐng)完成后再專文對(duì)外分享）。同時(shí)整個(gè)系統(tǒng)采用分布式分層架構(gòu)，各個(gè)組件之間可以獨(dú)立自由伸縮，BDS服務(wù)、Lindorm的寬表引擎服務(wù)和檢索引擎服務(wù)都具備無限的橫向擴(kuò)展能力，從而提供海量數(shù)據(jù)的無限存儲(chǔ)和實(shí)時(shí)檢索。在使用上， Lindorm全文索引功能非常簡單易用，用戶可以通過HBase Shell(Lindorm原生API暫未開放)就可以管理同步映射的Schema，BDS對(duì)于用戶來說是完全透明的。不像在Lily HBase Indexer方案中，用戶還需要和Indexer交互，管理schema。具體的操作大家可以參考全文索引使用快速入門的幫助(https://help.aliyun.com/document_detail/161121.html ),簡單來說，用戶只需要在HBase Shell中執(zhí)行一條命令，就可以為數(shù)據(jù)列創(chuàng)建Solr索引
hbase shell> add_external_index_field 'testTable', {FAMILY => 'f', QUALIFIER => 'money', TARGETFIELD => 'money_f', TYPE => 'FLOAT' }
同時(shí)BDS還具有豐富的WebUI界面和監(jiān)控和報(bào)警信息，用戶可以非常方便地獲取同步狀態(tài)和報(bào)錯(cuò)信息。比如在云監(jiān)控中，我們可以清晰地看到同步的延遲，同時(shí)可以通過訂閱報(bào)警，隨時(shí)發(fā)現(xiàn)異常。
最后是 阿里云HBase增強(qiáng)版(Lindorm)全文索引與其他方案的一個(gè)對(duì)比
方案雙寫Lily HBase IndexerLindorm全文索引同步效率受限于Solr受限于HBase Replication，擴(kuò)展性差受限于Solr穩(wěn)定性會(huì)影響HBase穩(wěn)定性會(huì)影響HBase穩(wěn)定性無影響數(shù)據(jù)一致性無法保證無法保證可以保證一致性Cloud NativeN/AN/A云原生，支持?jǐn)U容，升級(jí)配置，同步通道可獨(dú)立擴(kuò)展，報(bào)警監(jiān)控一應(yīng)俱全
案例介紹
目前已經(jīng)有非常多的公司和業(yè)務(wù)已經(jīng)在線上使用Lindorm的全文索引。這里給大家介紹幾個(gè)使用案例。
某快遞公司包裹平臺(tái)
該快遞公司的包裹系統(tǒng)原來使用了Oracle，由于業(yè)務(wù)的增長Oracle的單表數(shù)據(jù)過大已經(jīng)造成瓶頸，并且只能存儲(chǔ)1個(gè)月的數(shù)據(jù)。在這么大規(guī)模的數(shù)據(jù)下，上萬網(wǎng)點(diǎn)的分析查詢已經(jīng)慢到無法接受的程度。該公司采用了Lindorm全文索引的方案改造之后，不僅可以將可查數(shù)據(jù)擴(kuò)展到6個(gè)月，在引入Solr做多維查詢后，查詢能力也比之前好了五倍。
某O2O公司訂單系統(tǒng)
該公司原來的訂單查詢系統(tǒng)使用了DRDS分庫分表，由于訂單量巨大，DRDS分32個(gè)庫都已經(jīng)只能放下6個(gè)月的訂單數(shù)據(jù)。而該公司希望查詢系統(tǒng)能夠查詢所有訂單數(shù)據(jù)。同時(shí)由于查詢時(shí)有多達(dá)15個(gè)維度條件的隨機(jī)組合查詢，傳統(tǒng)的二級(jí)索引方案已經(jīng)無法滿足要求。在選用了Lindorm全文索引方案后，得益于Lindorm的海量存儲(chǔ)能力，一個(gè)表就能放下所有歷史數(shù)據(jù)。由于單個(gè)Solr的表索引數(shù)據(jù)不宜過大，因此該業(yè)務(wù)使用了我們推薦的Solr分庫分表功能（Alias功能），Lindorm寬表存儲(chǔ)中的數(shù)據(jù)自動(dòng)增量同步到不同的Solr Collection中（按時(shí)間分割），在查詢時(shí)，無需查詢?nèi)縎olr數(shù)據(jù)，只需要根據(jù)時(shí)間維度查詢少量Solr Collection。在新方案下，該公司不僅實(shí)現(xiàn)了能夠在線查詢所有歷史數(shù)據(jù)，還能秒級(jí)返回查詢結(jié)果。
某在線教育公司營銷平臺(tái)
該公司原來的營銷平臺(tái)直接基于MySQL，由于MySQL列不能太多，只能把各個(gè)系統(tǒng)的數(shù)據(jù)分布在多張表內(nèi)，然后再采用DTS同步的方式，訂閱Binlog，再寫入到自建HBase的大寬表中。然后把寫入事件記在Kafka上，再消費(fèi)Kafka的消息，回讀HBase數(shù)據(jù)同步到Solr中，最后提供給營銷系統(tǒng)使用。整個(gè)鏈路非常長，組件非常多，難以維護(hù)，容易出穩(wěn)定性問題。在使用了Lindorm的全文索引方案后，僅僅使用了一個(gè)Lindorm就解決了所有的問題，簡單易運(yùn)維，同時(shí)獲得了 Cloud native的能力，各個(gè)組件都可以無限水平擴(kuò)展和擴(kuò)容。
總結(jié)阿里云Lindorm全文索引方案給廣大用戶提供了存儲(chǔ)與檢索的一站式解決能力，相比之前的方案，不僅簡單易用，容易維護(hù)，同時(shí)能夠利用Cloud Native的特性解決一系列運(yùn)維上的難題。在技術(shù)上，阿里云Lindorm使用了一種高性能，低延遲的異構(gòu)存儲(chǔ)同步方案，避免了之前一些方案的性能問題，并完美地解決了寬表引擎和檢索引擎的模型差異所帶來的數(shù)據(jù)不一致的問題，在后續(xù)的計(jì)劃中，Lindorm還將提供統(tǒng)一的多維查詢能力，系統(tǒng)會(huì)自動(dòng)利用Solr索引對(duì)多條件查詢加速，而無需應(yīng)用顯示地訪問Solr，進(jìn)一步優(yōu)化使用體驗(yàn)。目前，有大量的公司和用戶已經(jīng)基于此功能打造了他們的在線查詢和離線分析系統(tǒng)，歡迎更多的用戶前來試用。
