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回收掉了。
问题不出现在这里。
要实验证明多了还是少了。
步骤1. 待续
