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. 待續

原文：