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