問題タブ [phoenix]

問題

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」を使用してください

Google Cloud BigTable はコプロセッサをサポートしていません。

コプロセッサーはサポートされていません。インターフェイス org.apache.hadoop.hbase.coprocessor を実装するクラスを作成することはできません。

https://cloud.google.com/bigtable/docs/hbase-differences

コプロセッサーでは、各タブレット (RS) ノードに顧客コード (jar) をデプロイする必要があることは理解できます。それでも、エンドポイント コプロセッサは、一部のシナリオでデータの局所性を確保するために、HBase アプリケーションにとって不可欠です。Apache Phoenix などの HBase 拡張機能は、セカンダリ インデックスを維持するために Observer コプロセッサに依存しているため、コプロセッサのサポートがないことが主な非互換領域のように思えます。

将来、コプロセッサーのサポートは可能ですか? BigTable タブレットでカスタム Java の「ストアド プロシージャ」を実行するための回避策はありますか?

更新 1: Apache Phoenix coprosessors のリスト:

• GroupedAggregateRegionObserver
• インデクサー
• MetaDataEndpointImpl
• MetaDataRegionObserver
• ScanRegionObserver
• SequenceRegionObserver
• ServerCachingEndpointImpl
• UngroupedAggregateRegionObserver

セカンダリ インデックスを持つ書き込み負荷の高いテーブルでの upsert のパフォーマンスについて大まかに把握したいと思います。

インデックスには、テーブルのすべてのフィールドがあります (実際には、非行キー フィールドの数は 1 つ、これは varbinary 型です)。

大まかなテストを実行しましたが、結果は次のとおりです。

• セカンダリ インデックスを持つテーブル: 4.3 分
• セカンダリ インデックスのないテーブル: 53 秒

このテストは、PhoenixInputFormat を使用した Apache Spark プログラムで行われます。

セカンダリ インデックスはグローバルに変更可能です。

結果は、私にとっては、セカンダリ インデックスのないテーブルに比べてやや遅すぎます。

約 4.7 倍遅いです。2～2.5倍くらいにしてほしいです。（実際には2つのテーブルに書き込むため）

これは典型的なパフォーマンスの低下ですか?

もしそうなら、書き込みの多いテーブルの (グローバルで変更可能な) セカンダリ インデックスをあきらめる必要があると思います。

アップデート

私のテスト クラスタは、1 つの名前ノードと 3 つのデータ ノードで構成されています。(小さいです)

データ ノード マシンの仕様は次のとおりです: (決して強力ではありません)

• CPU: Core i7-4790 (コア数: 4、スレッド数: 8)
• RAM：32GB（8GB×4）
• HDD：8TB（2TB×4）
• ネットワーク: 1Gb

ソフトウェア仕様:

• Hadoop: Hortonworks HDP 2.2 (Hadoop 2.6)
• アパッチ スパーク: 1.3.0
• アパッチ フェニックス: 4.3.1

アップサートされたレコードの数は約 600 万です。列が 1 つしかなく (データ型は varbinary)、小さいです。(1k を大きく下回る)

誰かがフェニックスの機能に関する私の質問を手伝ってくれれば幸いです。

phoenix テーブルを作成し、100,000 レコードを挿入しました (これらが異なるリージョン サーバーに分散していると仮定します)。

ここで、制限 n を指定して選択クエリを発行すると、次のようになります。

鳳凰の行動は？

• サイド サーバー側で (すべてのリージョン サーバーから) すべてのデータを読み取り、データセットに制限を適用して 1000 レコードをクライアントに送信しますか?

また

• すべてのデータ セットをクライアントに提供してから、制限を適用しますか?

1. 現在、クライアントとサーバーの両方で孵化するフェニックス 4.0.0 を使用しています。
2. 4.3.1 (最新) にアップグレード

3. コマンド ラインで (./sqlline.py を使用して) クライアントを使用して接続しようとすると、次のエラーが発生して接続が成功しませんでした。

   エラー: エラー 1013 (42M04): テーブルは既に存在します。tableName=SYSTEM.CATALOG (state=42M04,code=1013) org.apache.phoenix.schema.NewerTableAlreadyExistsException: エラー 1013 (42M04): テーブルは既に存在します。tableName=SYSTEM.CATALOG

SYSTEM.CATALOG テーブルの削除は機能しますが、それは意図した解決策ではありません。

問題の解決策/回避策は何ですか?

Apache Phoenix では、リージョン サーバー全体にデータを分散するソルトテーブルを作成できます。例えば

この機能を使用するには、多数のソルト バケットを選択する必要があります。この数の塩バケツを選択するにはどうすればよいですか? 地域サーバーの数に基づいている必要がありますか? 後で地域サーバーを追加する予定がある場合はどうすればよいですか?

Phoenixにphoenix-4.3.1をインストールし、sqlineを介してhbaseに正常に接続しました。クラスターの一部であるマシンと、クラスターの一部ではなく、hadoopコンポーネントを持たないマシンの両方で。Zookeeper sqlline アクセスにアクセスするだけで問題ありませんが、druid 経由でアプリ (npm) 経由で接続するとエラーが発生します

npm https://github.com/gaodazhu/phoenix-clientを見つけました

私は以下を取得しています