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的完整日志收集分析工具链。也有非常多公司在用。
版权声明:本文博主原创文章,博客,未经同意,不得转载。