HBase資料同步到ElasticSearch的方案

ElasticSearch自身提供了一個River機制，用于同步資料。

這裡能夠找到官方眼下推薦的River：

​​http://www.elasticsearch.org/guide/en/elasticsearch/rivers/current/​​

可是官方沒有提供HBase的River。

事實上ES的River很easy，就是一個使用者打包好的jar包，ES負責找到一個node，并啟動這個River。假設node失效了。會自己主動找另外一個node來啟動這個River。

github上有兩個相關的項目：

​​https://github.com/mallocator/Elasticsearch-HBase-River​​

這個項目事實上非常easy。在River裡用定時器啟動一個HBase的Scanner，去掃描資料，并把資料插到ES裡。

和自己手動寫代碼去掃描差點兒相同。

​​https://github.com/posix4e/Elasticsearch-HBase-River​​

這個項目利用了HBase的Replication機制。模拟了一個Hbase Replication的結點，然後同步資料到ES裡。

可是這個項目是基于Hbase0.94的，實作的功能有限。

Hbase0.94和HBase0.98 的API變化非常大，基本不可用，并且作者也說了不能用于生産環境。

能夠參考官方文檔和cloudera的一些部落格文章：

​​http://hbase.apache.org/book.html#cluster_replication ​​

​​http://blog.cloudera.com/blog/2012/07/hbase-replication-overview-2/​​

HBase的Relication機制，事實上和Mysql的同步機制非常像，HBase的每一個Region Server都會有WAL Log，當Put/Delete時。都會先寫入到WAL Log裡。然後背景有線程會把WAL Log随機發給Slave的Region Server。而Slave的Region Server會在zookeeper上記錄自己同步到的位置。

Cloudera内置的Cloudera Search實際上就是這個Lily Hbase Indexer：

​​https://github.com/NGDATA/hbase-indexer ​​

這個項目就是利用了HBase的Replication功能，把HBase資料改動（Put。Delete）都抽像成為一系列Event，然後就能夠同步到Solr裡了。

這個項目抽象出了一個子項目：HBase Side-Effect Processor。

​​https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/README.md​​

讓使用者能夠自己寫Listener來處理Event。

考慮了上面的東東。是以決定基于HBase Side-Effect Processor。來自己寫簡單的程式同步資料到ES裡。

事實上代碼是很easy的。參考下Demo裡的LoggingConsumer就好了。

https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-demo/src/main/java/com/ngdata/sep/demo/LoggingConsumer.java

從網上找到的文章，讨論比較多的是12年，貌似後面就比較少了。

https://github.com/superkelvint/solr-vs-elasticsearch 

http://stackoverflow.com/questions/2271600/elasticsearch-sphinx-lucene-solr-xapian-which-fits-for-which-usage 

http://www.quora.com/Why-Cloudera-search-is-built-on-Solr-and-not-Elasticsearch   Cloudera-Search為什麼選擇Solr而不是ElasticSearch

個人傾向于ElasticSearch，由于從流行度來看。ES正在超越solr cloud：

Logstash + ElasticSearch + Kibana的完整日志收集分析工具鍊，也有非常多公司在用。