apache phoenixクエリパフォーマンスに参加する

Question

私は数ヶ月後にフェニックスのカップルを使い始めました。以下は、環境とバージョンの詳細です。

Hadoop - Cloudera CDH 5.4.7-1。 Phoenix - 4.3 - PhoenixはCDH5.4.7-1で小包として提供されます。 HBaseバージョン - HBase 1.0.0 JDK - 1.7.0_67 1つのマスターサーバーと3つのリージョンサーバー。

Apache Phoenixを評価するためにPOCを開始しました。 Oracle DB上の12の異なる表にデータがあります。 Oracle Golden Gateを使用してHadoopシステムにデータを取得します。

フェニックステーブルには、それぞれ40〜100個の列と数百行のフェニックステーブルがあります。変換処理を行い、最終的なテーブルにロードします。これは私たちがやっている基本的なETLです。変換プロセスは、中間テーブルを作成する2つの中間段階を経ます。したがって、テーブル間には「結合」があります。

すべてがうまくいっており、ETLプロセス全体を実装することができました。私は使いやすさと実装が非常にうれしく思いました。

何百万行ものパフォーマンステストを開始したときに問題が発生しました。以下はその問題です。

1. 中間変換プロセスでリージョンサーバーがクラッシュします。それぞれ2つのテーブルを結合し、それぞれ20,000,000行あります。私が加わっている列に作成された二次索引。 2つのテーブルは9つのバケツで塩漬けされています。これは、ジョインに起因する行数が〜200k未満の場合にうまく実行されました。 200kの行は10分以上実行されます。結果の行数が多い場合、リージョンサーバーはクラッシュし始めます。 テストコード は、内側がba.c_item_id = mi.c_item_idにMI として（s_info_id = 12345 salted.m_item2 miからc_item_id選択）を に参加salted.b_acct2 BAから選択数（available_bal）を説明します。

   + ------------------------------------------ + |プラン| + ------------------------------------------ + | CLIENT 9-CHUNK PARALLEL 9-WAY SALTEDを超える完全なスキャン.2_BA_CI_IDX | |サーバーは1行に集約| |パラレル・インナー・ジョイン・テーブル0（スキップ・マージ）| |クライアント9-CHUNKパラレル9-wayレンジスキャンSALTED.S_MI_SI_IDX [0,19,266] | |クライアント・マージ・ソート| |ダイナミック・サーバー・フィルターBY TO_BIGINT（ "C_ITEM_ID"）IN（MI.C_ITEM_ID）| + ------------------------------------------ +

2. 最終的な変換のために6つのテーブルを結合すると、インデックス付きカラムに6つのテーブルを結合すると、1M行未満のデータが返されます。これには10〜12分かかります。しかし、結合結果が約1M以上であれば、結果は戻ってこない。最初はInsufficientMemoryExceptionを取得しました。これは構成を変更して使用可能なメモリを増やすことで解決しました。私はInsufficientMemoryExceptionを再度取得しませんが、クエリは20分以上実行されません。我々は数秒以内に実行する予定です。

   jvm.bootoptions= -Xms512m –Xmx9999M. 
   hbase.regionserver.wal.codec : org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec 
   hbase.rpc.timeout 600000 
   phoenix.query.timeoutMs 360000000 
   phoenix.query.maxServerCacheBytes 10737418240 
   phoenix.coprocessor.maxServerCacheTimeToLiveMs 900000 
   hbase.client.scanner.timeout.period 600000 
   phoenix.query.maxGlobalMemoryWaitMs 100000 
   phoenix.query.maxGlobalMemoryPercentage 50 
   hbase.regionserver.handler.count 50 
   

   概要：

は、以下のパラメータであるコアの問題は、参加したクエリの実行が遅いことと、データは行の100万を超えたとき、最終的には地域サーバのクラッシュ。実行には制限がありますか？私たちが評価プロセスを進めているので、私はこれらの問題を解決するのを手助けしてください。私はフェニックスを放棄したくありません！上記のクエリをすばやく実行できる場合は、Phoenixを使用することを躊躇しません。

よろしく、 Shivamohan

Answer 1

デフォルトでは、フェニックスは、メモリ内に収まるようにデータを必要とする、-ハッシュ結合を使用しています。 （大きなテーブルで）問題が発生した場合は、Phoenixに割り当てられているメモリ量を増やす（設定を変更する）か、クエリ「ヒント」（SELECT /*+ USE_SORT_MERGE_JOIN*/ FROM ...）を使用して同じ要件。彼らは将来、理想的な結合アルゴリズムを自動検出する予定です。さらに、フェニックスは現在、結合操作のサブセットのみをサポートしています。

Answer 2

性能最適化機能（http://phoenix.apache.org/joins.html）としてphoenixドキュメントに記載されているRHSの概念を試しましたか？結合のLHSがサーバーキャッシュのハッシュテーブルとして構築される小さいテーブルが内部結合のLHSを形成していることを確認してください。 クエリで列uがセカンダリインデックスの一部を作成していましたか？ あなたが上記を試しても、数分で待ち時間が残っているなら、Hbaseリージョンサーバーのメモリをチェックし、クエリを処理するのに十分であるかどうかを確認する必要があります。