使用协处理器将HBase数据索引到Elasticsearch集群

HBaseCon 2013: Using Coprocessors to Index Columns in an Elasticsearch Cluster

使用协处理器将列数据索引到Elasticsearch集群

    总结来说，一般就是扩展RegionObserver类，覆写pre-和post-方法，将jar包路径配置到表中，让hbase去回调覆写的方法。

    这种协处理器只是对配置的table范围有效。

    在覆写的方法中，实例化ElasticSearch Client，一般可用Java客户端API；客户端又分为两种，一种是Transport类型，一种是Node类型：Transport是一种“建立连接－数据传输－释放连接资源”的模式，而Node类型客户端，将客户端机器声明为一个ES的常规node，接受ES集群的多播。

• 第一种 Transport类型的客户端，连接是一次性的，一般为了提高速度，采用两处优化：

    1.将多个hbase oprtation累积起来，调用elasticsearch的bulk transport api，就是多个操作打包再向ES集群发出请求。

    2.使用java thread executor多线程处理，线程池管理，也可以将连接保存起来，分配给多线程。

    这种方式，如果我们有10台hbase机器，每台建立10个连接，则会对ES集群产生100个client的访问压力，对于单个ES机器，是不合理的。如果使用

. put( "client.transport.snif", true)

//参考ttps://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport

-client.html

客户端能够直接探测到多个ES集群的节点，将traffic导向多台机器，对于transport如何建立、管理和多个ES节点的连接，有兴趣请阅读transport client源码。

• 第二种 Node类型的客户端，会建立一个node，这个node和ES集群中的node没有区别，在底层能够被多播发现和通知节点变化，从而持有了一定网络资源。

    参考：https://www.elastic.co/guide/en/elasticsearch/client/java-api/0.90/node-client.html#node-client，node client能够在任意机器上实例化，实例化之后加入ES集群，但是可以不存储Index和Shard，只做路由功能。带来的好处就是，不需要通过你在transport client实例化时指定address，同时也不需要再根据探测到的address list做再一次路由，而是直接访问ES集群节点(operations are automatically routed to the node(s) the operations need to be executed on, without performing a "double hop".)。对于我们来说，就是完整的把网络路由和连接建立的任务交给了elasticsearch提供的client，付出的代价可能是高内存的消耗(待验证)。

 

    问题和方案：目前我们的program的瓶颈在于hbase region server这边，不在ES这边，coprocessor吃掉了太多的JVM内存，导致整个协处理器program，连同它“寄生”的region server全被GC回收掉了。

    transport client的多线程处理是为了提高操作速度，但是连接的保存持有，可能有内存优化的空间，但是目前我们每个region server只建立一个transport client，而且是static的，不会被回收，应该问题不出现在这里。

    node client方案更多的是对访问ES集群网络路由代价的优化，对于内存占用需要实验证明多了还是少了。

    步骤1. 待续

原文：