ElasticSearch的River機械
ElasticSearch本身就提供了River機械，對於同步數據。
在這里，現在能找到的官方推薦River：
http://www.elasticsearch.org/guide/en/elasticsearch/rivers/current/
可是官方沒有提供HBase的River。
事實上ES的River很easy，就是一個用戶打包好的jar包，ES負責找到一個node。並啟動這個River。假設node失效了，會自己主動找另外一個node來啟動這個River。
public interface RiverComponent {
RiverName riverName();
}
public interface River extends RiverComponent {
/**
* Called whenever the river is registered on a node, which can happen when:
* 1) the river _meta document gets indexed
* 2) an already registered river gets started on a node
*/
void start();
/**
* Called when the river is closed on a node, which can happen when:
* 1) the river is deleted by deleting its type through the delete mapping api
* 2) the node where the river is allocated is shut down or the river gets rerouted to another node
*/
void close();
}
Elasticsearch-HBase-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變化非常大，基本不可用。並且作者也說了不能用於生產環境。
HBase的Relication機制
能夠參考官方文檔和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上記錄自己同步到的位置。
HBase同步數據到Solr的方案：Lily HBase Indexer
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數據同步到ElasticSearch的終於方案
考慮了上面的東東，所以決定基於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
private static class EventLogger implements EventListener {
@Override
public void processEvents(List<SepEvent> sepEvents) {
for (SepEvent sepEvent : sepEvents) {
System.out.println("Received event:");
System.out.println(" table = " + Bytes.toString(sepEvent.getTable()));
System.out.println(" row = " + Bytes.toString(sepEvent.getRow()));
System.out.println(" payload = " + Bytes.toString(sepEvent.getPayload()));
System.out.println(" key values = ");
for (KeyValue kv : sepEvent.getKeyValues()) {
System.out.println(" " + kv.toString());
}
}
}
}
其他的一些東東：
ElasticSearch 和Solr cloud的比較
從網上找到的帖子，討論比較多的是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的完整日志收集分析工具鏈。也有非常多公司在用。
版權聲明：本文博主原創文章，博客，未經同意，不得轉載。