使用協處理器將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客戶端能夠直接探測到多個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
問題和方案:目前我們的program的瓶頸在於hbase region server這邊,不在ES這邊,coprocessor吃掉了太多的JVM記憶體,導致整個協處理器program,連同它“寄生”的region server全被GC回收掉了。
transport client的多執行緒處理是為了提高操作速度,但是連線的儲存持有,可能有記憶體優化的空間,但是目前我們每個region server只建立一個transport client,而且是static的,不會被回收,應該問題不出現在這裡。
node client方案更多的是對訪問ES叢集網路路由代價的優化,對於記憶體佔用需要實驗證明多了還是少了。
步驟1. 待續
原文: