正しいデータウェアハウスの SQL エンジンを選ぶ:Apache Hive LLAP とApache Impala の比較

正しいデータウェアハウスの SQL エンジンを選ぶ:Apache Hive LLAP とApache Impala の比較

by David Dichmann

この記事は、2020/09/24に公開された「Choosing the right Data Warehouse SQL Engine: Apache Hive LLAP vs Apache Impala」の翻訳です。

スーパーヒーローは1人より2人の方がいい

お互いを補完し合う2つのことを組み合わせることで強力な結果を得られることが良くあります。Cloudera Data Warehouse に搭載されている Apache Hive LLAP と Apache Impala の「強力なペア」もそんな一例です。Impala も Hive も、何ペタバイトものデータを扱う、かつてない大規模なスケールでの運用が可能です。どちらも100%オープンソースなので、お好きなBIツールを使い、ベンダーロックインを回避し、またコミュニティ主導のイノベーションを活用できます。

Impala と Hive LLAP のどちらも、データウェアハウスのユースケースに最適なように思えるとき、なぜ2つの間でどちらかに決める必要があるのでしょうか?答えは簡単で、それぞれに得意分野があり、お望みの分析の種類によっては、どちらかがより適している場合があります。より適切な判断のためには、ぜひブログの最後までお読みください!

SQL エンジンの違いを説明する前に、Impala と Hive LLAP の両方が(Hive Metastore を介して)同じデータとメタデータを共有していることに注目することが重要です。そのため、気が変わったら切り替えることができるだけでなく、同じデータに対して異なるエンジンを使用して、異なるワークロードを同時に実行することもできます。つまり、両方の「いいとこ取り」 ができるのです。

では、なぜ選ぶのか、を説明したいと思います。一般的には、Impala はデータマートを扱う場合に最適です。データマートは、一般的に範囲が限定されたスキーマを持つ大規模なデータセットのことです。一方、Hive LLAP は、企業のデータウェアハウスのような広い範囲のユースケースを扱う場合に適しています。このようなユースケースには、複数の部門やさまざまなダウンストリームアプリケーションが含まれることが多く、どちらもクエリパターンの幅が広くなります。また、Impala はインタラクティブでアドホックなクエリに適しており、特に数百人、数千人のユーザーがそれぞれの作業を行う場合に適していることがわかります。 

また、一部のクエリとテーブルにはImpalaを使用し、他のクエリやテーブルにはHive LLAP を使用するなど、組み合わせて使用することもできます。

Impala はスピード重視の設計

Impala は、CPU 効率の高い C++ で書かれており、非常に高速なクエリプランナーとメタデータキャッシングを備え、低レイテンシーのクエリに最適化されています。このため、Impala はデータマートでの使用に理想的なエンジンです。データマートで作業する人は、大規模な書き込みではなく、読み取り専用のクエリを実行することがほとんどだからです。  

また、Impala は、コード生成、プロセス間通信、大規模な並列処理、メタデータのキャッシングなどを用いた、非常に効率的なランタイム実行フレームワークを備えています。このため、Impala は、データを反復的に掘り下げて探索するときのような、アドホックなクエリを扱うときにも適しています。クエリを何度も短時間で変更したい場合、Impala は非常に速いレスポンスタイムなため、反復のたびに長時間待たされることがありません。 

Hive LLAPは洗練された設計を取っています

Hive LLAP には、多くの高度な機能があるため、開発者が開始してすぐに効果的に使用するのは少し難しい場合があります。Hive LLAP では、クエリが計画を経て実行に向けて立ち上がるまでに時間がかかることがあります。しかし、Hive は非常にフォールトトレラントな設計になっています。長時間実行されるクエリの断片が失敗した場合、Hive はそれを再割り当てして再試行します。Hive はクエリの結果だけでなく、データファイルも高度なアルゴリズムでキャッシュするため、要求頻度の高いデータは LLAP でキャッシュされたままになります。Hive LLAP は、複数のコンポーネントやデータベースにまたがってクエリを実行できるようにすることで、クエリのフェデレーションをサポートしています。したがって、Hive LLAP は、EDW のユースケースにおける「スタートの遅れ」を補い、長期的にはより堅牢で、より高いパフォーマンスを発揮します。

Hive LLAP は、このような高度な機能と柔軟性を備えているため、エンタープライズ・データ・ウェアハウス(EDW)のユースケースに適しています。EDW では、ビジネスインテリジェンスのレポートやダッシュボード、依存するデータマート、他のエンタープライズアプリケーション、外部システムなどをサポートしています。これらのワークロードは、複数の次元を考慮に入れていることが多く、その結果、EDW はデータマートよりも複雑な SQL 要件を処理する必要があり、複雑なデータタイプ、より多くのスケジュールされたクエリ、データマートへの入力や通常のデータ抽出を行うためのクエリオーケストレーションなどの必要性が高くなります。

Hive は、大規模なデータセット上で、より長時間の複雑なクエリをより堅牢に処理することができるため、このようなタイプのアプリケーションでは、Hive LLAP の方が優れた選択肢となります。高速で実行されるアドホックなクエリでは、Hive LLAP の起動時間が Impala に比べて遅くなることがありますが、長時間実行されるクエリでは、この起動コストは全体の実行時間の中で比較的重要ではありません。Hive LLAP が EDW に適しているのは、フォールトトレランス(結果を長時間待っているときにクエリが失敗しては困りますよね?)と、より複雑なクエリでのパフォーマンスが優れているからです。

ImpalaとHiveのLLAPの使用

Impala Hive LLAP
データマート エンタープライズ・データ・ウェアハウス
  • インタラクティブでアドホックな分析に適しており、特に同時実行性の高いセルフサービスの形に適しています。
  • 重い変換や複数の結合を必要とする長時間のクエリに適しています。
  • Impala では利用できない機能を使った、インタラクティブでアドホックな分析に適しています。
  • ユーザーが迅速にクエリを変更できるビジネス・インテリジェンス・ツールに適しています。
  • あらかじめ定義されていて、閲覧者がカスタマイズできないダッシュボードに適しています。
  • 推奨ファイル形式として Parquet を採用。
  • 推奨ファイル形式として ORC を採用。
  • Impala よりも JSON の扱いに向いています。

 

膨大なデータセットとユースケースの増加に伴い、タイムリーな結果を得るために適切なデータウェアハウス SQL エンジンを選択することは、大きな違いをもたらします。 

2020年10月20日に行われた「Data Warehouse – Impala vs. Hive LLAP」のウェビナーでは、専門家による議論、お客様のユースケース、質疑応答が行われました。オンデマンドで視聴されたい方はこちらでご覧いただけます。(言語は英語になります。)

Cloudera Japan Marketing
この著者の他の記事

コメントする

あなたのメールアドレスは公開されません。また、コメントにリンクを貼ることはできません。