0

CDH3u4 (HBase-0.90) を使用して 6 ノードの HBase クラスターをセットアップし、アプリケーション サーバー (-cum web-server) で HBase クライアントを使用しています。クラスターで実行される HBase/Hadoop サービスは次のとおりです。

NODENAME-- ROLE

Node1 -- NameNode
Node2 -- RegionServer, SecondaryNameNode, DataNode, Master
Node3 -- RegionServer, DataNode, Zookeeper
Node4 -- RegionServer, DataNode, Zookeeper
Node5 -- RegionServer, DataNode, Zookeeper
Node6 -- Cloudera Manager, RegionServer, DataNode

HBase クライアントに次の最適化を使用しています。

  1. 自動フラッシュ = false
  2. ClearbufferOnFail=true
  3. HTable bufferSize = 12MB
  4. setWriteToWAL = false を入力します (データが 1 つ失われても問題ありません)。

読み取りと書き込みの間で一貫性を保つために、2 秒ごとにすべてのバッファ テーブルでフラッシュ コミットを呼び出しています。

私のアプリケーションでは、HBase 書き込み呼び出しをキューに配置し (非同期方式)、20 個のコンシューマー スレッドを使用してキューを排出します。curl を使用して Web サーバーをローカルでヒットすると、curl の完了後に HBase で 2500 の TPS を確認できますが、負荷テストでは、3 つのアプリケーション サーバーで 1 秒あたり 1200 ヒットという高い速度でリクエストが送信されます。 ) HBase への書き込みを担当するスレッドは、入力速度に匹敵する速度でデータを書き込んでいません。リクエスト レートが 1200 ヒット/秒の場合、TPS は 600 以下です。

パフォーマンスを向上させるために私たちができることを誰か提案できますか? 3 つのアプリ サーバーのそれぞれでスレッドを 7 に減らしてみましたが、まだ効果はありません。専門家の意見は参考になります。これは運用サーバーであるため、誰かがパフォーマンスの大幅な向上を指摘しない限り、役割を交換することは考えていません。

[編集]: HBase の書き込みパターンを強調/明確にするために、最初のトランザクションで Table-A の行をチェックします (HTable.exists を使用)。最初は行の検索に失敗したため、3 つのテーブルに書き込みます。後続の 4 トランザクションは、テーブル A で存在チェックを行い、行が見つかると、1 つのテーブルにのみ書き込みます。

4

1 に答える 1