コプロセッサを使用してHBAseデータをElasticsearchクラスタにインデックス
2256 ワード
HBaseCon 2013: Using Coprocessors to Index Columns in an Elasticsearch Cluster
コプロセッサを使用してカラムデータをElasticsearchクラスタにインデックスする
要約すると、一般的にRegionObserverクラスを拡張し、pre-とpost-メソッドを上書きし、jarパケットパスをテーブルに構成し、hbaseに上書きをコールバックさせる方法です.
このコプロセッサは、構成されたtable範囲にのみ有効です.
上書き方法では、ElasticSearch Clientをインスタンス化し、JavaクライアントAPIを使用することが一般的である.クライアントはまた2種類に分けられ、1つはTransportタイプであり、1つはNodeタイプである:Transportは「接続を確立-データ転送-接続リソースを解放する」モードであり、Nodeタイプのクライアントは、クライアントマシンをESの通常nodeとして宣言し、ESクラスタのマルチキャストを受け入れる.
1つ目のTransportタイプのクライアントは、接続が使い捨てで、一般的に速度を向上させるために2つの最適化が採用されています: 1.複数のhbase oprtationを蓄積し、elasticsearchのbulk transport apiを呼び出します.これは、複数のオペレーションをパッケージングしてESクラスタに要求することです.
2.Java thread executorマルチスレッド処理、スレッドプール管理を使用して、接続を保存し、マルチスレッドに割り当てることもできます.
この方式では,10台のhbaseマシンを持ち,1台につき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ソースコードを参照してください.の第2のノードタイプのクライアントは、ESクラスタ内のnodeと区別されず、下位層でマルチキャストによってノードの変化を発見し、通知することができ、一定のネットワークリソースを持つ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に渡され、高いメモリの消費(検証対象)になる可能性があります.
問題と方案:現在、私たちのプログラムのボトルネックはhbase region serverの側にあり、ESの側にはありません.coprocessorはJVMメモリを食べすぎて、コプロセッサプログラム全体を「寄生」したregion serverとともにGCで回収されました.
Transport clientのマルチスレッド処理は操作速度を向上させるためですが、接続の保存は、メモリ最適化のスペースがある可能性がありますが、現在、region serverごとにtransport clientが1つしか確立されておらず、staticで回収されず、問題はここには現れないはずです.
Node clientスキームは,ESクラスタネットワークへのアクセスのルーティングコストの最適化がより多く,メモリ占有について実験的に証明する必要があるか少ないかである.
ステップ1.続きを待つ
原文:
コプロセッサを使用してカラムデータをElasticsearchクラスタにインデックスする
要約すると、一般的にRegionObserverクラスを拡張し、pre-とpost-メソッドを上書きし、jarパケットパスをテーブルに構成し、hbaseに上書きをコールバックさせる方法です.
このコプロセッサは、構成されたtable範囲にのみ有効です.
上書き方法では、ElasticSearch Clientをインスタンス化し、JavaクライアントAPIを使用することが一般的である.クライアントはまた2種類に分けられ、1つはTransportタイプであり、1つはNodeタイプである:Transportは「接続を確立-データ転送-接続リソースを解放する」モードであり、Nodeタイプのクライアントは、クライアントマシンをESの通常nodeとして宣言し、ESクラスタのマルチキャストを受け入れる.
1つ目のTransportタイプのクライアントは、接続が使い捨てで、一般的に速度を向上させるために2つの最適化が採用されています: 1.複数のhbase oprtationを蓄積し、elasticsearchのbulk transport apiを呼び出します.これは、複数のオペレーションをパッケージングしてESクラスタに要求することです.
2.Java thread executorマルチスレッド処理、スレッドプール管理を使用して、接続を保存し、マルチスレッドに割り当てることもできます.
この方式では,10台のhbaseマシンを持ち,1台につき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ソースコードを参照してください.
参照先: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に渡され、高いメモリの消費(検証対象)になる可能性があります.
問題と方案:現在、私たちのプログラムのボトルネックはhbase region serverの側にあり、ESの側にはありません.coprocessorはJVMメモリを食べすぎて、コプロセッサプログラム全体を「寄生」したregion serverとともにGCで回収されました.
Transport clientのマルチスレッド処理は操作速度を向上させるためですが、接続の保存は、メモリ最適化のスペースがある可能性がありますが、現在、region serverごとにtransport clientが1つしか確立されておらず、staticで回収されず、問題はここには現れないはずです.
Node clientスキームは,ESクラスタネットワークへのアクセスのルーティングコストの最適化がより多く,メモリ占有について実験的に証明する必要があるか少ないかである.
ステップ1.続きを待つ
原文: