雲hbase2.0也就是我們即將要上線的apsaradb for hbase2.0。它不僅相容開源hbase2.0，也承載著阿里多年大規模hbase使用的技術積澱，還有廣大公有雲使用者喜歡的商業化功能。在大資料量場景中已經具有如此優勢的雲hbase2.0，如果還能search呢？
雲hbase2.0上的search是基於最新版本的solr7.3.x研發。資料通過replication準實時的同步到solrcloud中，利用solr實現資料的檢索。具體過程如下：
通過配置檔案或者sql中指定要同步的索引列以及分詞器等資訊，建立hbase與solr表之間的對映關係。
當有hbase中發生資料操作（插入／更新／刪除）時，對應的運算元據將會**獲，轉化為doc寫入solrcloud中。
索引列作為全文索引進行檢索。先檢索solr中對應的索引資料，拿到所有符合條件索引資料的value, 也就是對應hbase表中rowkey時，再對hbase主表中的資料做過濾，最後獲取到查詢結果。
以上過程可參考下圖：
當hbase有了search能力，不僅能解決非rowkey的索引問題，也補齊了hbase字尾模糊匹配，分詞檢索的能力。
索引資料的同步方案目前有兩種, 分別是使用hbase coprocessor的同步方案和利用replication的非同步方案。目前我們使用非同步方案的原因是，對hbase集群影響最小，而且此方案經過多次優化，資料同步速度也能接近準實時。
除了相容目前最高版本的hbase和solr的優勢以外，相對現在社群已有的同類方案，還有以下優點：
某交通資料中心，每天會從各個路口攝像頭實時採集大量的車牌號資料，並儲存到hbase中。上層業務有以車牌號為條件，模糊查詢出相關車主資訊的需求。而由於每天實時寫入的資料多達幾億條之多，同時涉及大量包含和字尾查詢。此時，hbase現有的功能特性，已經不能滿足此類查詢需求了，大資料量的全表掃瞄不僅非常慢，也很容易造成rs因為大scan頻繁掛掉的問題。對於有search功能的hbase來說，通過二級索引借助luence的能力很容易就能解決這個問題。
大資料儲存框架之HBase 2 解壓縮
以下資料是google在2005年發布的乙個測試資料。algorithm remaining encoding decoding gzip 13.4 21 mb s 118 mb s lzo20.5 135 mb s 410 mb s 22.2 172 mb s 409 mb s 資料 hbase ...
雲HBase建設之開篇
阿里云云hbase團隊在2月份推出了雲hbase產品，此款產品的核心在集團內部已經使用了6年之久，那麼跟社群版本的hbase有怎樣的區別，我們又做了怎樣的產品化，本系列將會為使用者詳細介紹這些點。雲hbase位址 雲hbase的核心是基於開源社群1.1版本系列，在此之上深度改造，之前阿里在較早版本有...
HBase 2 hbase物理模型結構
1 儲存單元cell rowkey 列簇 timestamp version，確定乙個單元格的值 2 資料無型別，以位元組碼的形式進行儲存 1 列分割 table中所有的行都是按照字典序進行排列，可以在行的方向分割為多個region 2 region是hbase中分布式儲存和負載均衡的最小單元，儲存...