インパラのメモリの最適化

I.はじめ
のNoSQLデータのHadoopエコロジカル・分析三銃士ハイブ、HBaseの、インパラバッチは質量、データストレージの大列、自分の長所をリアルタイムでインタラクティブな分析で分析しました。特にインパラでは、その様々な利点の顕著な特徴で、Hadoopのコミュニティに参加するため、大規模なデータアナリストの過半数の賛成を獲得します。

マスタノードにより生成されたインパラは、プログラム実行計画ツリーを実行し、パラレルデータ取得動作モードで実行されるプル・ノードの各々に分配、プッシュモードデータ取得における従来のMapReduceのHadoopに代わる、中間結果は、ディスクに書き込まれていませんネットワーク、リアルタイムのインタラクティビティと通過タイムリーストリームで強く、インパラは、余分な労力管理メタデータはかかりませんが、メタストアハイブのメタデータ管理の使用は、直接でのHadoopのHDFSとHBaseの中に格納されているアクセスすることができますPB振幅データを、インパラデータ・ブロックを介してメモリ要素にロードされるのと比較してハイブ、HBaseのは、コンピューティング性能の点で大幅に改善された、計算;インパラは便利比較のHBaseを使用するユーザのためのSQLセマンティクスを提供そして、シンプルで実用的な、ない他のプログラミング言語、単に複雑なデータ分析タスクを実行するSQL文を使用し、インパラもHadoopの柔軟性、拡張性と経済性を継承し、ネットワークのボトルネックを避けるために、分散ローカリゼーションプロセスの特性を持っています。

インパラの利点は、それが本当に任意の欠点やない「完璧な」分析ツールであることを言いましたか？

絶対にありません！分析の年以上のデータのインパラ膨大な量、実際の戦闘でのWebアプリケーション開発の経験は、インパラも続けていくつかの致命的な問題を暴露します：

• 「食べるメモリー」の家族、それが直接技術的なタスクの故障につながるメモリ、メモリ・オーバーフローのためにあまりにも深刻依存しています。

• 「骨抜きバージョン」SQL--は、UDFをサポートしていない、UPDATE / DELTE操作をサポートしていない、同じことがDISTINCT SELECT複数サポートしていません。

• セキュリティ権限の役割は、追加のセキュリティコンポーネント、より複雑な構成管理を必要と達成。
  しかし、基本的には、インパラとエラーログの作業機構を介して、我々はインパラ欠陥が最適化プログラム及び代替措置のかなりの数によって解決することができました。インパラ合理的な最適化は、分析性能を得るために、立ち向かうためのオープンソースのHadoop生態利点とNewSQLデータベースの商業化を使用して、掘削のパフォーマンスを最大化するコストを節約すると同時に、NewSQLデータベースソフトウェアに劣っていません。

  限られた空間に、今日はのは、メモリのオーバーフローの問題を最適化インパラについて話しましょう。

第二に別れ「Memorylimitを超え、」 - インパラのメモリの最適化

• ディスクにスピルSQLOperations
  導入インパラメモリ最適化技術の前の努力は、我々が最初に作られたメモリ・オーバーフローの公式インパラを見てください。インパラメモリ算術オーバーフロー、一時的なディスク領域を占有する必要性が増加を計算する際際CDH4ためインパラインパラ1.4からは、機能「ディスクにスピルSQL操作」の新バージョンを起動CDH5.1、そのディスク操作に転送され、ディスクのI / O、計算時間が得られ、純粋なメモリ操作よりもはるかに高いですが、少なくとも、この「0」フォールトトレラントメモリ障害から直接致命的な問題分析タスクを解決するために。
  この機能をオンにするだけでimpalashell実行し、また、非常にシンプルであるset DISABLE_UNSAFE_SPILLS=0かset DISABLE_UNSAFE_SPILLS=FALSEのコマンド。設定時DISABLE_UNSAFE_SPILLSの時間パラメータは、ディスクのオーバーフローにメモリ操作動作寸前、0（FALSE）であるセット（TRUE）図1に示すように、ダイレクト・メモリ・オーバーフローパケットメモリオーバーフローMemory limit exceededエラー。
  オープンテストではDISABLE_UNSAFE_SPILLS、パラメータ、ディスク機能に書き込まれた無効なメモリオーバーフローは、クエリタスクが失敗しました。しかし、閉じられDISABLE_UNSAFE_SPILLSたパラメータは、ディスクに書き込まれたメモリのアウト機能を開いたときに1225秒でクエリタスクが、しかし、問い合わせタスクの完了。
  インパラクエリ制御インタフェースのClouderaのマネージャでは、我々は二回、クエリによって消費されるリソースを見ることができます：
  テストでは、私はノードのメモリ制限をクラスタ化しますインパラは3.5ギガバイトは、あなたは、クエリの累積メモリーピーク使用量が3.6ギガバイトで見ることができますエラーを「メモリの制限を超え」を生成します。そして、関数の後に「ディスクにスピルSQL操作」をオープンし、ピーク時のメモリ使用量が2.3ギガバイトに変更し、計算に必要な余分なメモリは、ディスク操作（それぞれが、一時的なデータ10G 3クラスタノードのデータノードで書かれたに変換され、 ）、「メモリの制限を超えて」エラーの問い合わせが正常に完了したことを避けるために。
  このトリックを解くだけでメモリオーバーフローの問題？それは真実ではありません！
  実際には、インパラの関係者はまた、機能に多くの制約があることを認め、また、ユーザーが可能トリガ機能「ディスクへの流出」を避けることをお勧めします。既存の制限の機能は次のとおりです。

1. すべてのSQL文をトリガすることができない、例えば、労働組合またはキーワードは、メモリオーバーフローエラーがトリガされます。

2. 各オペレータノードに割り当てられた最小必要メモリ以下が低すぎない各ノードピーク限界のメモリ;

3. 各ノードの動作は、出力メモリ上に各ノードにおける実際の物理メモリよりも高く推定することができない説明します。

4. 機能トリガ「ディスクへの流出は、」メモリオーバーフローエラーをトリガーする他の同時クエリがあります。

5. ディスクスペースの特定の要件は、ディスク操作のデータがディスクにI / Oを増やす、各ノードの一時ディレクトリインパラに書き込まれ、ディスク使用率が制御不能な原因となります、があります。

   それは公式が提案、または実務経験の面であるかどうか、「Spilltoディスクは、」長期的な解決策ではありません。SQLクエリを最適化することによって、変更システムパラメータは、ハードウェア構成はリークが発生メモリを解決する方法を改善する必要があり、または。

SQLクエリの最適化

SQLの最適化だけでなく、成熟した分析で、開発チームは、データ分析における乗数効果を達成するために、パフォーマンスインパラマイニングクラスタを最大化するために、より良い、基本的な品質を持っている必要があります。ここでは4つの魔法のいくつかのインパラSQLの最適化は、次のとおりです。

• 魔法：計算統計
  COMPUTE STATS（DDL）は、テーブルを完了するために、パーティション、データ列とデータ配信情報収集の量は、収集された情報は、メタデータデータベースに格納されています。インパラはちょうど一見単純な文の統計表に入るが、それはタスクスケジューリングプロセスの分析において重要な役割を果たしています。統計情報の文が唯一のインパラでは、クエリのJOIN、GROUP BY、ORDER BYを使用することを得ることはありません、 UNIONは、DISTINCT 資源のおよびその他の高い消費が最適化されており、およびHBaseのテーブルも役割を果たしています。
  インパラの分析タスクでは、元のデータベーステーブルに、大規模なデータテーブルまたはキー・テーブルで使用される中間のテーブル、テーブルまたはクエリの結果は、パフォーマンスに影響を与えるかどうか、世代のテーブルの後にテーブルに情報をコマンドtable_nameのCOMPUTEのSTATSを実行することをお勧めします統計は、クラスターは自動的に統計に基づいて、最適なクエリプランを選択します。（上記GB、TBと）より大規模なテーブル統計はより明白終了後の長い実行時間、クエリオプティマイザ統計の効果を命じます。
  実行統計コマンドの完了、コマンドSHOW TABLE STATS table_nameの使用後は、詳細な情報を確認するためにテストする出力テーブルに使用可能な統計です。
  計算統計どれだけ重要？知っている次の例を見てみましょう。
  プロセスのユーザ肖像主題分析を行う際に、私は3つの大きなテーブルに関連付けられているユーザ情報テーブル（3億）、ユーザ音声情報テーブル（1.6億）、ユーザデータトラフィック情報テーブル（9千万）をベースに必要以下に示すように要約は、計算統計コマンドを使用して、レコードを複製する複数のリソースがあり、ノードのメモリ使用量ピーク140ギガバイトのそれぞれは、最終的な結果は、バグを見える、タスクの前に消費されたタスクを50分を要する
  大型3のうちテーブルが行わComputeStatsのコマンドであり、この分析を再び行った後、タスクは、専用メモリ17ギガバイト、通常の分析結果、以下に示すように、タスクによって消費されるリソースの各ノードのピークを32分かかりました。
  インパラは、「メモリの制限を超え、」生産エラーのリスクを低減し、かつメモリ消費を避けるだけでなく、より合理的な実施計画を作成し、タスクスケジューリングタスクを完了することができ、統計情報テーブルを取得した後、各ノードを見ることができる大きすぎますBUG異常な解析作業。
  実際のアプリケーション・プロセスでは、多くの場合、状況のCOMPUTE STATSコマンドの実装では、統計的な作業を完了することができ、いくつかの大きなテーブル（TBに記録千億レベル）仮死、があることを言及する価値があります。このような状況に鑑み、解決する2つの方法がある：第一に、後添加COMPUTE INCREMENTAL STATS（DDL）は、各パーティションに対して、このコマンド増分を使用することができ、CDH5.3バージョン、大きなテーブルのパーティションの記憶のためにインパラ2.1からのコマンドゾーニング変更部品への変更のみをスキャンして、統計を更新するときの統計は、と、2番目はそうではありませんインパラクラスタまたは物理的な所有の中国冶金の上位バージョンへのアップグレードのために彼らの統計的な作業を完了するためにも、増分統計はできない制限しました統計は、我々は手動でテーブルの統計を更新することができ、解決する他の方法のパーティションを設定します。以下の例では、第1テーブルCOUNT（ ）、その後、テーブルtable_nameのsettblproperties（「numRowsの数」変える =「N」）を順（N（COUNTを表す）のレコードの特定の数を取得した）レコードの数を手動で再度設定テーブル統計情報のルックアップテーブル、インパラが正常に統計情報テーブルを取得したクラスタを発見しました。

• マジック2：実施計画

  SQL文の前にキーワードを「EXPLAIN」追加することで、あなたは文の実行計画を返すことができます。作業を調整する方法、表示データを読み出し、ノード間の組み合わせは、中間結果を送信し、最終的な結果セットがプロセス全体で得られる方法底インパラから実行計画。

  実施計画によると、あなたは、私たちは効率が低すぎる見つけた場合、あなたは文自体を調整し、またはテーブルの構造を調整することができ、この文の効率を決定することができます。例えば、ヒントを使用して、ジョイン・クエリにWHEREクエリを変更することにより、サブクエリの導入は、テーブルの接続順を変更テーブルおよび列統計または文のパフォーマンスを最適化するための他の方法を収集し、パーティションテーブルを変更します。
  図は、クエリコールでEXPLAINボトムアップシーケンシャルリードからの出力のための実行計画を表示する：
  （1）最後の部分は、データの読み出しの総量の基礎となる内容の詳細を示しています。データ読み出しの量は、我々は効果的に、これらのおよび他のデータの実際のニーズを読み取るために、クラスタの推定サイズと組み合わせる戦略を、分割か否かを判断することができます。
  （2）重合が実行中に見ることができ、ソート順序および特定の実装の詳細、統計関数、相互作用、中間結果は、より高いレベルとは異なるノード間のフローに見ることができます。
  動作は並列インパラ異なるノードで実行され、各ノードは、必要なメモリを推定した場合（3）我々が見ることができます。

  （4）EXPLAIN_LEVELパラメータを設定すると、より詳細な出力を学ぶことができます。0から3までの値、及び対応する実施計画詳細。

  • マジック3：PROFILEクエリ情報

  PROFILE文は、より詳細な使用して、最近実行されたSQLクエリ情報の基礎となる出力することができます。クエリの実行が完了すると、クエリが成功したかどうか、コマンドPROFILEを入力し、詳細な情報の問い合わせを出力することができます。これは、情報を使用して、メモリの最大量リードごとの物理バイトのクエリノード番号の実装を含みます。この情報を使用して、我々は、クエリのタイプはIP消費である、またはCPU消費量の種類に影響を与え、ノードのパフォーマンスの低下が消費するネットワークの種類が、あなたには、いくつかの推奨構成を確認することができするように有効であると判断することができます。

  プロフィール情報コンテンツクエリ出力が含まれています：

  クエリ、クエリの開始時刻、クエリ、タスクインパラノードおよびその他の基本的な情報から提出されたクエリを実行するために（1）の状態を確認します。

  （2）計画とチェックする手順の実装：

  （3）ステップの実施に関する統計情報は、各ノードは、データ量が読み出され、ピーク情報メモリ平均時間、最大時間を実行することを含みます。

  詳細（4）と実行の詳細に割り当てられた各ノードの各ステップの実現の様々なステップ（による情報の過剰部分に、スクリーンショットが示されています）。

  クエリを実行した後、SQL文で対象とされていない最適解ならば、地面、メモリ消費量、ネットワーク帯域幅、CPU使用率やその他の情報からクエリIO PROFILEコマンドの確認は、私たちの所望の範囲内にありますチューニング、調整、等ノードの構成を最適化します。

• マジック4：構造最適化
  インパラメモリオーバーフローの問題が解決しない場合、上記の3つの魔法の武器を使用した後の構造を最適化するための措置を検討する必要があります。
  保存された（1）寄せ木テーブル
  インパラソースデータ、中間テーブルとして、適切な結果テーブル記憶構造を選択します。デフォルトでは、インパラテキスト形式テーブル格納部、及び大容量データ記憶装置、好ましくは寄せ木の記憶フォーマットについて確立することです。表形式の寄せ木ビルド表に示す構成で指定され、かつ使用INSERを避けるために...テーブルにステートメント寄せ木挿入データ値。それぞれがHDFS上の単一の小さなデータファイルが生成されます、このように行を挿入するので、それは、このように検索速度に影響を与えるデータクエリの並列処理を削減します。
  （2）分割
  大幅インパラクエリ速度を向上させることができる分割技術によって、テーブルは、いくつかの特定の列によれば、非常に大きなテーブルまたはクエリが常にデータ量。パーティション列の別個の値は、パーティション内のデータを含めることは確かである分化のある程度を有します。パーティションの粒子サイズの実際の選択は、各パーティションは、データが1GB以上1ギガバイトの倍数よりも大きいことを確認してみてください。分散クエリとインパラのIO性能のHDFSバッチを最大限に活用するために、適切なサイズのデータファイルの唯一のパーティションサイズ、。
  （3）SQL文の
  SQL文のパフォーマンスは、最終的なタスクの効率に直接影響を持っています。いくつかのSQLの最適化「経験則」は、次のとおりです。

• 関連する条件は、できるだけ多くのデジタル仲間を使用して、関連した長い文字列を回避するために使用します。

• 巨大なタスク分割「分割統治」の後、テーブルネストされたタスクの代替真ん中の漸進的実現の確立を介して。

• あなたが参加した場合関連する表統計が入手できない、または自動的に参加するのインパラ低い効率を選択し、手動でSELECTキーワードの後に​​テーブルを指定し、原則として、接続「右から左、小さなテーブルに大きなテーブル」に基づいて、キーワードSTRAIGHT_JOINを使用することができますオーダー。

• [] SQL文で特定のヒントを同封使用して、基本的な作業から利用のヒントをSQLクエリを使用して手動で調整するヒント。

• [ブロードキャスト]指定されたヒントを使用して、小さなテーブルに関連付けられている場合、大きなテーブルは、接続モードで、テーブルとの間に大きな相関を扱う場合、接続のために指定ヒント[SHUFFLE]を使用します。

クラスタリソースを最適化
するようにSQLクエリ用語を最適化することに加えて、また、リソースの割り当てにインパラクラスタシステムのために最適化することができる「二のアプローチ」。インパラアドミッション制御機能は、クエリで使用されるメモリ・セグメントのサイズを制限軽量、分散リソース制御機構であり、これに並行して実行されたクエリの数。含みを最適化するアイデア、クラスタの特定の環境に応じたシステムの構成を最適化するために、この機能を使用します。

• クエリのために予約されたメモリのサイズを制限するimpaladプロセスのための合理的なオプションを開発-MEM_LIMIT。

• 動的割り当てのために構成された糸は、メモリの割り当ては、Hadoopのインパラ他の成分との関係を開発することは合理的です。

• 異なるユーザグループ、リソースのcgroupの使用を隔離するように構成されたリソースプール機構のためのアプリケーションを要求します。

• メモリのオーバーフローが発生した場合にあまりにも多くの同時クエリではなく、インパラアドミッション制御機能による小さなメモリフットプリント高い大クエリ少数の同時クエリを制限します。

• システムリソースがピークに達した場合、新しい要求がクエリに来るとき、クエリキューを設定し、それがクエリの実行がクエリが実行される前にキューで待機し、関連するリソースを完了し、リリース後まで、待ちキューに入れました。

• インパラは、Hadoopの糸制御リソース消費の他のコンポーネントを使用して、同時実行とクラスタのメモリ消費の動作を制御するためにアドミッション制御を使用します。

III。背中に書かれました

インパラは、オープンソースのビッグデータ分析エンジンとして、自身の存在の欠陥のいくつかは許容されます。いくつかの合理的な最適化プログラムを使用して、そしてその潜在的な、本当の「楽しさ」をタップすることで、インパラはあなたの予想外の驚きをもたらすでしょう。

ます。https：//www.jianshu.com/p/936339ac1a25で再現