前言
因爲之前在項目上，需要用到ES+Hbase方案，最後經過各種測試和驗證，最終項目完成上線。因爲在實際的過程遇到不少的問題，和理論還是有一定的差距。
紙上得來終覺淺，絕知此事要躬行。----古人誠不欺我
基本原理
很簡單，將Elasticsearch的DOC ID和Hbase的rowkey相關聯：
將源數據根據業務特點劃分爲索引數據和原始數據：
索引數據：指需要被檢索的字段，存儲在Elasticsearch集羣中；
原始數據：指不需要被ES檢索的字段，包括某些超長的文本數據等，存儲在Hbase集羣中。
將HBase的rowkey設定爲ES的文檔ID，搜索時根據業務條件先從ES裏面全文檢索出相對應的文檔，從而獲取出文檔ID，即拿到了rowkey，再從HBase裏面抽取數據。
優點
- 發揮了Elasticsearch的全文檢索的優勢，能夠快速根據關鍵字檢索出相關度最高的結果；
- 同時減少了Elasticsearch的存儲壓力，這種場景下不需要存儲檢索無關的內容，甚至可以禁用_source，節約一半的存儲空間，同時提升最少30%的寫入速度；
- 避免了Elasticsearch大數據量下查詢返回慢的問題，大數據量下Hbase的抽取速度明顯優於Elasticsearch；
- 各取所長，發揮兩個組件各自的優勢。
缺點
說完了優點，其實也有不少坑，一把辛酸淚…
1、兩個組件之間存在時效不一致的問題
相對而言，Elasticsearch的入庫速度肯定是要快於Hbase的，這是需要業務容忍一定的時效性，對業務的要求會比較高。
2、同時管理兩個組件增加了管理成本
顯而易見，同時維護兩套組件的成本肯定是更大的。
小結
總的來說，如果要使用ES+HBase，要充分考慮業務數據是否適合這種模式。