14

問題

Phoenix でセカンダリ インデックスを構築しようとしています。インデックスの作成には数時間かかります。次のパフォーマンスに気づいたので、HBase スキャンが遅いことが原因のようです。

  • 私はテーブルをスキャンするのに 2 時間かかるかもしれませんが、他の開発者はより大きなテーブル (1 億行) では数分かかると報告しています。
  • HBase シェルは、おおよその行数をカウントできます。これは、このテーブルのすべての行をカウントするのに 3800 秒 (>1 時間!) かかることを意味します。

HBase シェルと Java スキャナーの両方。

NB : GET (行キーによる) 操作は、良好なパフォーマンス (約 0.5 秒) で達成されます。

環境

  • 3800 万行 / 1000 列 / 単一列ファミリー / GZ 圧縮で 96Go。
  • クラスターには 6 つのノード (126Go RAM、24 コア) があり、5 つのリージョン サーバーがあります。
  • Hortonworks データ プラットフォーム 2.2.0

トラブルシューティング

HBaseの本（http://hbase.apache.org/book.html#performance）に基づいて、私がすでにチェックしたものは次のとおりです：

1) ハードウェア

  • IO(ディスク)
    • NMon は、ディスクが 80% を超えてビジー状態になることはなく、最も頻繁に 0 ～ 20% の間であると述べています
    • 一番上は、HBase JVM がスワッピングしていないことを示しています (5 RS のうち 2 をチェック)
  • IO(ネットワーク) : 各ノードのアクティブ インターフェイスは同じスイッチ上に立っています (すべての 2 番目のパッシブ インターフェイスは別のスイッチに接続されています)。

2) JVM

  • GC 一時停止 OK (毎分数ミリ秒程度の一時停止)
  • ヒープは問題ないように見えます (制限近くでピークが長くなりすぎていません)
  • CPU は驚くほど低い : 10% を超えることはありません
  • スレッド:
    • アクティブなスレッド (10 個の "RpServe.reader=N" + 他のいくつか) は競合を示しません
    • 何もしない保留スレッドが多数 (60 "DefaultRpcServer.handler=n"、約 15 その他)
    • スレッド ステータスのない IPC クライアントの膨大なリスト

3) データ

  • Hive + completebulkload を使用してバルク ロードされました。
  • 地域数 :
    • 13 のリージョンは、RS ごとに 2 ～ 3 つの大きなリージョンがあることを意味します。これは想定どおりです。
    • メジャー圧縮を強制した後も、スキャンのパフォーマンスは変わりません。
    • 領域サイズはかなり均一です: 11 領域で 4,5Go (+/-0.5)、2 領域で 2,5Go

4) HBase の構成

  • ほとんどの構成は変更されていません。

    • HBase env は JMX コンソールのポートのみを示します
    • HBase サイトには Phoenix の設定がほとんどありません

  • 私にはOKに見えたパラメータのいくつか

    • hbase.hregion.memstore.block.multiplier
    • hbase.hregion.memstore.flush.size : 134217728 バイト (134Go)
    • Xmx の Xmn 比率: .2 Xmn 最大値: 512 Mb Xms: 6144m
    • hbase.regionserver.global.memstore.lowerLimit : 0.38
    • hbase.hstore.compactionTreshold : 3
    • hfile.block.cache.size : 0.4 (ヒープのブロック キャッシュ サイズ AS %)
    • 最大 HStoreFile (hbase.hregion.max.filesize) : 10 go (10737418240)
    • クライアント スキャナー キャッシュ: 100 行 Zookeeper タイムアウト: 30 秒
    • クライアントの最大キー値サイズ: 10mo
    • hbase.regionserver.global.memstore.lowerLimit : 0.38
    • hbase.regionserver.global.memstore.upperLimit: 0.40
    • hstore ブロック ストアファイル: 10
    • hbase.hregion.memstore.mslab.enabled :
    • hbase.hregion.majorcompaction.jitter を有効にしました: 0.5

  • パフォーマンスに影響を与えることなく、次の構成変更を試みました

    • hbase-env.sh : HBASE_HEAPSIZE=6144 を増やそうとしました (デフォルトは 1000 であるため)
    • hbase-site.xml :
      • hbase.ipc.server.callqueue.read.ratio: 0.9
      • hbase.ipc.server.callqueue.scan.ratio: 0.9

5) 何も言わない有用なログ

猫 hbase-hbase-master-cox.log | grep "2015-05-11.*エラー"

cat hbase-hbase-regionserver-*.log | grep "2015-05-11.*エラー"

何も印刷しない

WARN を印刷すると、関連のないエラーが表示される

2015-05-11 17:11:10,544 WARN [B.DefaultRpcServer.handler=8,queue=2,port=60020] shortcircuit.ShortCircuitCache: ShortCircuitCache(0x2aca5fca): 1074749724_BP-2077371184-184.10.17.65-142370984 を読み込めませんでしたInvalidToken 例外に。

2015-05-11 17:09:12,848 WARN [regionserver60020-smallCompactions-1430754386533] hbase.HBaseConfiguration: 構成オプション "hbase.regionserver.lease.period" は非推奨です。代わりに、「hbase.client.scanner.timeout.period」を使用してください

4

2 に答える 2

3

わかりました。重要なのは、「ホット」コンテンツを「コールド」コンテンツから別々の列ファミリーに分離することです。列ファミリは、列を個別の HFiles に格納するために使用されるため、1 つの列ファミリをインデックス付き (または頻繁に読み取る) 列に使用し、別の 1 つの列ファミリ (つまりファイル) を他のすべての列に使用できます。

最初のステップ: 列ファミリーが小さいほどスキャンが速いことを確認します

単純にコールド コンテンツを破棄して、1 つの小さなカラム ファミリーを構築します (1655 カラム -> 7 カラム)。

中規模のテーブル スキャンでのパフォーマンス:

  • [37.876.602 行、1655 列] 1000 行をスキャン 39.4750
  • [76.611.463 行、7 列] 1000 行をスキャン 1.8620

備考 ：

  • 最初の 1000 行をスキャンするため、行の総数は無視できます。
  • Hbase シェルからスキャンするとコンソールにコンテンツが出力されるため、大きな行でオーバーヘッドが発生します。

2 番目のステップ: 複数ファミリの HTable を生成する

Hive から HFiles を生成することにより、一括読み込みを行います。ドキュメントには、マルチ ファミリー テーブルを 1 つ生成することはできないと書かれていますが、HFiles を個別に生成することはできます。

create table mytable_f1 (UUID string, source_col1, source_col2)
...
TBLPROPERTIES('hfile.family.path' = 'tmp/mytable/**f1**');

create table mytable_f1 (UUID string, source_col3, source_col4)
...
TBLPROPERTIES('hfile.family.path' = 'tmp/mytable/f2');

そして、いつものように import コマンドを呼び出すだけです:

hadoop jar [hbase-server-jar] completebulkload /tmp/mytable mytable
于 2015-06-19T14:09:49.877 に答える
2

  • スキャン時にブロックキャッシュをオフにします（ヒープメモリを大量に消費しています）

  • ur record のサイズを調べます。1 MB を超える場合は、hbase.scanner.timeout 期間を増やしてください scan.setCacheBlocks(false);

  • scan.setCaching(x) x * 1 つの short でフェッチされるレコードのサイズ。1 MB に近いことを確認してください。

  • いくつかの必要なチェック: スキャンされる Tabled のリージョンがリージョン間で均等に分散されていることを確認してください。

(一括読み込みを行った場合は、メジャー圧縮を 1 回実行します)

于 2015-05-13T12:44:13.500 に答える