How did we make our Impala run faster?
Hadoop があり、1 日に何テラバイトものデータがそこに流れ、ETL は Spark、Hive、あるいは禁じ手の Pig で 24/7 行われていますね。 そして、データが思い通りの形になり（あるいはそれ以前に）、すべてが完璧になった後、アナリストはクエリを実行したいと思うようになります。
私たちは、いくつかの目的のためにImpalaを使っています：
- データエンジニアがまだETLを作っていない新しいタイプのデータをアナリストにクエリーさせてください。
- アナリストに、（ETL プロセスの後の）最終目的地が HDFS であるデータをクエリさせる。
- レポート作成（独自のツールを使用）。
- 監視 & 警告システム（毎時間入ってくる新しいデータについて）。 私たちのクラスターは、ハードウェアとノードの数から見て、巨大なものではありません。 この記事では、私たちの Impala 最適化プロジェクトから学んだ知識と結論を共有します。
Impalaと他のSQL-on-Hadoopソリューション
Impalaが何であるかを知らない場合、Cloudera Impala Guideでそれについて読み、それからここに戻ってきて、面白いものを見てください。 最近では、Hive は ETL とバッチ処理のためだけのものです。 Hiveと違ってImpalaはフォールトトレラントではありませんが、アナリストはImpalaを使ってずっと速く答えを得ることができます。 しかし、MPP（大規模並列処理）エンジンとしては問題ありません。
Impala はHiveよりも高速ですが、これはHiveがMapReduce（ディスク入出力操作が多すぎるため非常に遅い）に対してまったく別のエンジンであるためです。 SparkSQL
SparkSQL は、特にインメモリ計算のみを実行する場合は、Hive よりもはるかに高速ですが、それでも Impala は SparkSQL よりも高速です。
Impala は、HDFS 上の対話型 SQL というミッションのために特に設計されたエンジンなので高速ですし、それを実現するためのアーキテクチャ概念があります。 例えば、Impalaの「常時稼働」デーモンは、24時間365日稼働し、クエリを待ちますが、これはSparkSQLにはないものです。 また、Impalaのcodegenメカニズム、Parquetフォーマットの最適化、統計、メタデータキャッシュなどの理由もあります。
SparkSQL の JDBC/ODBC Thrift ServerはImpalaと同等の競争相手かもしれませんが、ウェブ上でそれについてあまり見つけられなかったので、私はここでそれを述べ、もしこのテーマについて何らかの知識と経験をお持ちならそれについて媒体記事を書いていただければと思います。 もし、このテーマについて何らかの知識、経験があるのであれば、ぜひ媒体で記事を書いてください。近い将来、私も記事を書くかもしれません。 Web 上のほぼすべてのベンチマークによると、Impala は Presto よりも高速ですが、Presto は Impala よりもずっとプラグイン可能です。 Hadoop上でSQLが必要な場合はImpalaの方が速いでしょうが、同じクエリーエンジンで複数のデータソースにクエリーする必要がある場合は、PrestoがImpalaより優れています。 Prestoのコネクター一覧はこちらです。 Impala は Amazon S3、Kudu、HBase にもクエリできますが、基本的にはそれだけです。
Presto についてさらに読みたい場合は、私が作成した PrestoDB フルレビューを参照してください。 Cloudera Impala が基づいている技術全体は、Google Dremel Whitepaper から来ており、そのペーパーで Parquet が基づいている概念を見つけることができます。 そのため、json、csv、またはシーケンスファイルをクエリしないことを忘れないでください。
Work With Partitions
アナリストのクエリに従ってデータをパーティション分割します。 Impala はインデックスを持たないので、各クエリで処理するデータ量を減らすには、これが唯一の方法です。 私たちはほとんどのテーブルでDT（日付時間）を主なパーティショニング方法として使用しています。 8034>
REFRESH ステートメント
REFRESH ステートメントは、特に毎時間データが追加される何千ものテーブルがある場合、高価な操作となることがあります。 私たちは、1 日あたり 10,000 回以上のリフレッシュを実行しています。
- Impala 2.7 以降では、特定のパーティションに対してリフレッシュを実行することができ、これを使用すると REFRESH 文が非常に軽くなります。
- Hot & Archived tables architecture – それぞれのテーブルにはホット バージョンとアーカイブ バージョンがあります。 ホット・バージョンは過去 24 時間を保持し、そのテーブルのリフレッシュは 1 時間ごとに発生し、より軽量になります。 毎日、ホットテーブルはアーカイブテーブルにマージされ、そのテーブルに対してより重いリフレッシュが行われます。
- Don’t have too much metadata (files and partitions) per table (See the ‘Optimal File Size’ section).
Compute Stats
Stats will make your queries much more efficient, especially ones that involve more than one table (joins).The Stats will make a queries more efficient than the two two two two two things. したがって、すべてのテーブルの統計情報を計算し、増分統計情報でそれらを最新に保つワークフローを維持する必要があります。 より技術的な詳細については、Cloudera Impala Table and Column Statistics を参照してください。
Optimal File Size – 256MB/File
TL;DR: あまり小さいファイルを持たないように注意してください – カタログサーバー、リフレッシュ、クエリのパフォーマンスに大きな影響を与えます。
We noticed our Impala catalog server keeps crashes 4 times a week and that our queries takes too much time. そして、私たちにはあまりにも多くのファイルとパーティションがあることに気づきました。
その結果、2 年後には 17GB のデータと 17,000 のパーティションからなるテーブルができ、各パーティションは約 1MB ということになります。 つまり、1 つのパーティションは約 1MB です。私たちは 50KB サイズのパーティションを持つテーブルを持っていました。
当初は、この不合理な量のファイルがメタデータを大きくしすぎて、リフレッシュが重くなり、カタログ サーバーがクラッシュする原因になっているだけだと考えました。 しかしその後、ファイルの量がクエリのパフォーマンスにも非常に悪い影響を与えることに気づきました (非常に多くの寄せ集めのファイルを読み取るためにスキャナ スレッドの数が必要になるため)。 私たちは、17,280（！）個のパーティションとファイルを持つ、私たちが持つ実際の 500MB テーブル上でテストを実行しました。 私たちは、このテーブルの新しいマージ バージョンを、1 年につき 1 つ、2 つのファイルのみで作成しました。 クエリ実行のサマリーにおけるSCAN HDFSの部分は、2,000倍も速かったのです。 そこで、パーティションの管理を開始し、約 256mb の最適なファイル サイズにマージしました。
1 時間ごとのパーティションがあるテーブルは、毎日、毎月、毎年のパーティションになりました。 各パーティションには1つのファイルしかありません（サイズが> 256mbでない限り）
Configure Coordinators & Executors Per Daemon
Impala 2.9 から、どの impala デーモンがコーディネータで、どれが実行者であるかを決めることができるようになりました。 以前は、すべてのデーモンがコーディネーターとエグゼキューターであり、コーディネーターであることのオーバーヘッドは、大規模なクラスターでは非常にリソースを消費するため、これは大きな変化です。 たとえば、20GB のメタデータと 50 のノードがある場合、すべてのノードが調整役でもあるため、1TB の RAM を浪費することになります。 ヒント: クラスターあたり 2 人のコーディネーターを使用して開始します。
Column Data Types
Aut first we used STRING for all of our columns in all of the tables. これは本当に悪い習慣で、パフォーマンスに大きな打撃を与えました。
Impala Query Limits
Impala Admission Control を使用して、異なるユーザーグループに異なるプールを設定し、あるユーザーの使用を X 同時クエリーまたは Y メモリに制限する必要があります。 しかし、それ以上に、問題のあるユーザーやクエリーを処理するための独自のシステムを構築しました。
私たちのシステムは、現在実行中のクエリーを 10 秒ごとにサンプルし、クエリーが 30 分以上実行されている場合、それは強制終了されます。 先月、同じクエリ テンプレートが 30 分以上かかったために 90% 強制終了された場合、インフラストラクチャを保護するため、システムがテンプレートを認識すると、直ちに強制終了されます。
クエリを強制終了することは新しいコンセプトではありません – Amazon Athena が先にそれを行っていました。 Cloudera Impala Guide を読んで、本当に良い Impala 管理者になり、ここで説明したベスト プラクティスを実践することを忘れないでください。