Apache Impala（Incubating）とAmazon Redshiftを比較評価： AWSにおけるS3との統合、弾力性、アジリティ、そしてコストパフォーマンスの優位性について

複数の基準から比較評価を行った結果（以下の分析結果参照）、多くの一般的なユースケースで、ImpalaはRedshiftと比べてより優れたクラウドネイティブなエクスペリエンスを提供することが判明しました。

Impala 2.6から、Amazon S3に対するREAD/WRITE機能がサポートされ、S3上のデータに直接クエリを発行できるようになりました。またコンピュートを弾力的に拡張し、シームレスなデータのポータビリティや柔軟性も提供し、クラウドベースの分析データベースの中で比類なき存在となりました。パブリッククラウドを導入するユーザーが増加する中、Impalaは、従来のオンプレミス型のデータベースが持つメリットをクラウドにももたらし、最新のハイパフォーマンス分析SQLエンジンとして、データの保存場所に関係なくより優れたビジネスアジリティを提供します。

最近のブログ（こちらとこちら）では、AWS上でImpalaが独自に持つ非常に興味深い新たなクラウドに対する能力とユースケースについてご紹介しました。これらの優位性に加え、Amazonの従来からの分析データベースであるRedshiftと比較した、AWSクラウド上のImpalaの機能やパフォーマンスの分析結果も共有できることを嬉しく思います。

サポート機能の詳細については後ほど解説しますが、概要は以下の通りです：

・Impalaは、以下の機能によって、クラウドベースのデータベースでは対応できなかったクラウドネイティブなユースケースにも幅広く対応します：

・S3のデータへの直接のクエリ発行
・コンピュートの弾力的なスケール
・データのポータビリティと柔軟性
・様々なファイルシステムにまたがるシームレスなデータ
・クラスターの短期的な立ち上げと停止

・Impalaは、これらの比類のない主要機能を提供するだけではなく、汎用的なチューニングを行ったRedshiftに比べ、より優れたコスト効率とパフォーマンスを実現します。S3またはEBSのいずれの場合でも、Redshiftに比べ200％の優れたコスト効率と4～10倍ものスループットを提供します。

・Redshiftに特定のレポーティングベンチマークに向けたチューニングを行った場合でも、Impalaは以下を実現します：

・EBSにおける28％ のコスト効率向上と42％ のスループット向上
・大規模なS3クラスターにおける10％ のコスト効率向上と90％のスループット向上
・小規模なS3 クラスターにおける8％ のコスト効率向上（17％ のスループット低下のみ）

RedshiftとImpalaの比較方法について

Impalaは、Apache HadoopのHDFSファイルシステム、Apache Kuduのカラムナストレージといった、オープンな共有データプラットフォーム、またS3のようなオブジェクトストアに保存されたデータを処理するために開発された最新のMPP(超並列)分析データベースです。Impalaは様々なソースの異なるオープンフォーマット（Apache ParquetやApache Avro、テキスト）からデータをクエリできます。そのため、データとコンピュートを分離しデータをImpalaクラスターに移動したりロードしたりする必要なく、クエリすることができます。これらの機能は特にクラウド環境で有効となります。レポートや分析を実施する場合だけ一時的にクラスターを立ち上げ、終了したらシャットダウンできるからです。また処理のピーク時にだけサーバーの能力を増強したりといった対応が可能になります。これはクラスターをホストするためのコスト節約にもつながります。Impalaは、大規模なデータセット、数百のノードやユーザーにも効率的に対応できるよう設計されています。このブログでS3上のImpalaがもたらす比類ないユースケースをご理解頂くことができます。

これとは対照的に、RedshiftはAmazonがParAccel社から買収したテクノロジーをベースにしたモノリシックなアーキテクチャー（密結合な分離されたストレージ、メタデータ、コンピュート）を持つ伝統的データベースです。Redshiftは、専用のAWSインスタンスで稼動し、データの起動・ロード・クエリ発行を行うためのインターフェースを提供しています。従ってRedshiftは、AWS上で動作する予め構成されたオンプレミスのデータベースシステムだと考えるのが妥当かもしれません。

Redshiftには、密結合されたストレージ管理機能やメタデータストアがあり、クエリエンジンは、独自のフォーマットを使ってクラスターに格納されたデータストアにクエリを発行します。このためRedshiftでは、まず固定したスキーマを作成し、データをクエリできるようにETL処理を施して内部のデータストアにデータをコピーするという「伝統的」なアプローチを採用しています。さらにRedshiftでは、データセットを一度に数名のユーザー（同時クエリは15未満を推奨）だけで扱えるような設計になっており、クラスターのサイズも静的です（Redshiftはノードをインクリメンタルに追加・削除せずに新しいクラスターを一度にすべてのデータのコピーを用いて立ち上げます）。これらの制約があるため、Redshiftのユーザーは、固定的なデータサイズでRedshiftクラスターを常時立ち上げておき、新規またはサイズを変更したRedshiftクラスターに再度データをコピーする必要がないようにしておくという対応が一般的になっています。

以下の表は、RedshiftとImpalaの間の相違点を示したものです：

次にベンチマーク結果について見てみましょう。

ベンチマークの設定

今回の分析は、TPC-DSを用いて3TBのデータセットを対象に実施されました。99あるクエリの中から70を使用し、クエリには一切の修正を加えないか、RedshiftとImpalaともに少し修正したものを使用しています。（以前のベンチマークで使用したような）もっと大規模なデータセットを使用したかったのですが、Redshiftのデータロード時間の制約から、データサイズを減らさざるを得ませんでした（注意：このベンチマークは、TPC-DSを「拝借」したものであり、一般に公開されているTPC-DSの結果と直接比較することはできません）。

スキーマ

Impala：日付カラムでパーティションされたファクトテーブルを持つTPC-DSの定義する汎用スキーマ

Redshiftについては、2つのスキーマを使ってベンチマークを実施しました：

• 汎用スキーマ (General Purpose Schema) － 上記のImpala汎用スキーマと完全に同じスキーマ。ファクトテーブルはTPC-DSの定義通り、*_dates_skカラムでソートされています。汎用スキーマを持つRedshiftのワークロードは、探索的、セルフサービス、アドホックなワークロードに近いものです。これは、以下に示す固定レポーティングスキーマ (Fixed Reporting Schema) のように、何度も利用されて馴染みのある、事前に用意されたレポートのスキーマデザインとは対照的です。
• 固定レポーティングスキーマ (Fixed Reporting Schema) － Redshift向けに追加で最適化したスキーマを含み、予め知られたTPC-DSワークロード用に特別なチューニングを施してあります。Redshiftでは、システム管理者がプライマリーキー、外部キーの従属性、ソートキー、スキーマの分散キーを設定することができます。これによりデータのロード時にRedshiftはデータを最適な方法で分散させることがやりやすくなります。しかし、分散方法を変更したり、将来ソートキーを変更する必要がある場合にRedshiftはすべてのテーブルの再構築が必要になります。それはつまりダウンタイムとなります。最適なパフォーマンスを得るため、Amazonはこれらのキーを事前に設定しておくことを推奨しています。

ハードウェア構成

• Redshiftは、より少数の大型で高価なノードを使用して全体を構成することを好みます。Impalaのスケールアウトなデザインでは、安価で標準的なクラウドインスタンスタイプを多数組合せることで、より高速で高いコスト効果を発揮できるようになっています。
• 直接的かつ公平な比較ができるよう、RedshiftとImpalaのCPU数が同じになるように最適な数のインスタンスを使用しました。
• テスト中はRAMとデータの比率が一定に保たれるようにしました。

以下にハードウェア構成の詳細を示します：

（重要な注意： 表の内容は、米国で最もRedshiftが安価なリージョンの結果を反映したものです。例えば、北カルフォルニアでRedshiftを使用するユーザーは上記の料金に33％ の上乗せが必要となります）

Impala on S3はクエリエンジン用のコンピュートリソースをデータと独立して拡張できるため、より優れたスループットとパフォーマンスを実現することが可能です。前述のように「クラウドの従量制料金モデル ＋ S3統合 ＋ クラウドの弾力性、スケーラビリティ」によって、ジョブをより迅速に完了させるためのスループットを提供できるようになり、その結果より高いコストパフォーマンスを実現できます。

このパフォーマンスに与えるスループットの影響を測るため、（32ノードに加えて）64ノードでもImpala on S3を検証しました（1時間あたりのコストは当然ながら2倍になります）。

結果

レジュームまでの時間

パブリッククラウドの大きな特長の1つとして、使用量に応じて料金を支払えばよいという従量制料金モデルであることが上げられます。

前述のように、ImpalaのユーザーがS3に直接クエリを発行できるのとは対照的に、モノリシックなアーキテクチャーであるRedshiftのユーザーは、S3にデータを保存してオンデマンドでコンピュートを立ち上げることができません。次善策としては、Redshiftクラスターを使用していない間はスリープ状態におき、必要な時にレジューム（再開）させるという対応があります。

比較の公平性を確保するため、本分析ではRedshiftクラスターとImpalaクラスターが共にスリープ状態から結果を取得するまで、ユーザーがどれだけのコストを必要とするか相対的な比較を行いました。Redshiftの場合、S3からスナップショットをリストアするための時間が必要で、スナップショットが大きくなれば、その分だけクラスターを再開し再利用できるようになるまでの時間が長くなります。

上図のように、スリープ状態からクラスターを再開するまでに、RedshiftはEBS常にデータを格納するImpalaに比べ15倍の時間と11倍のコストがかかっています。つまり、Impalaならスリープ状態からの再開に約4.5分で済むところが、Redshiftでは1時間以上もかかるということです。

ETL ＋ シングルユーザーテスト

現在のクラウド上の分析データベースは、様々なソースのデータをETL処理にかけてから、データを取り込むようになっています。クラウドで最も一般的なユースケースの一つは、複数のソースからくるデータをApache HiveやApache Sparkを使ってバッチでETL処理してS3に結果を格納し、それを読み込んでImpalaやRedshiftでレポーティングや分析処理を行うというものです。

このテストでは、RedshiftとImpalaの両方でデータファイルをS3からロードし、統計情報の計算後、目的とするTPC-DSのクエリを発行しました。

上のグラフでは同じワークロードに対して以下のような結果になっています：

• 汎用スキーマを使ったRedshiftの場合、他の場合に比べ122～200％ と著しく劣勢
• 固定レポーティングスキーマを使ったRedshiftの場合、S3上のImpalaとほぼ同様のコストですがEBS上のImpalaに比べると27％ コスト高

純粋なパフォーマンスという観点では、EBS上のImpalaが最速（32分）ですべてのクエリを完了し、最も遅かったのはRedshiftで汎用スキーマを使用した場合でした（同じクエリの実行に5時間以上）。2番目は、固定レポーティングスキーマを使用したRedshiftの場合で42分。次が64ノードクラスターでのS3上のImpalaで44分と僅差でした。さらに、32ノードクラスターでのS3上のImpalaでは80分でした（パフォーマンスとコストパフォーマンスの詳細はマルチユーザーのセクションで説明）。

グラフからも分かるように、Redshift上のアドホックなワークロードは非常に遅く、コストもかかります。

ETL ＋ マルチユーザーテスト

ほぼ例外なく、現実のBIクラスターでは、複数のユーザーが同時並行でクエリを実行します。マルチユーザーテストでは、上記と同じクエリを4並列で実行しました。マルチユーザーの結果を見るため、以下2つの評価基準に着目します：

• コスト： ワークロードの開始から終了までにかかったコスト
• スループット： 一定の時間内にシステムが処理できるクエリ数（1分間あたりのクエリ数）

最初にコストは以下のグラフから分かるように、EBS上のImpalaのコスト効率が最高で、RedShiftがコスト高上位2つを占めています。

• 汎用スキーマを使用したRedShiftが最もコスト高で、EBS上のImpalaとの比較で275％、S3上のImpalaクラスターとの比較でも200％となっています。
• 固定レポーティングスキーマを使用したRedShiftは、EBS上のImpalaより28％コスト高で、S3上のImpalaに比べても8～10％コスト高でした。

パフォーマンスは下図の通り、システムが完全に稼働した後のスループットを測定しました（つまり、データロードと統計情報の計算は入っていません）。それによりエンドユーザーが実行時に体験するであろうパフォーマンスを計測できるからです。

こちらを見て分かる通り、S3上の64ノードImpalaが最大のパフォーマンスを発揮し、次にEBS上のImpalaと続き（コスト効率という点では最高）ます。最低はRedShiftを汎用スキーマで使用した場合で、S3上の64ノードImpalaクラスターはその10倍、EBS上のImpalaで7.8倍となっています。

RedShiftの最高のスループット（固定レポーティングスキーマを使用した場合）でも、EBS上のImpalaやS3上の64ノードImpalaクラスターには及びませんでした。

• EBS上のImpalaの方が42％ パフォーマンスに優れている
• S3上の64ノードImpalaの方が90％ パフォーマンスに優れている

以上のようにImpalaは、これまで誰も利用できていなかったクラウドの能力とユースケースを引き出しただけでなく、それをより優れたコスト効率、パフォーマンスを持って実現できました。

まとめ

もし皆様がパブリッククラウドへの分析データベースの導入を検討し、ImpalaとRedShiftの比較をされている場合、これらの結果からどちらを選択すべきか、その答えは明白です。S3に対するREAD/WRITEのサポート、コンピュートをデータサイズと独立しダウンタイムなしに拡張できること、類まれなデータのアジリティなどImpalaはRedShiftに比べ、わかりやすく、より優れたクラウドネイティブなエクスペリエンスを様々なよくあるユースケースに対して提供しています。

Clouderaでは、分析データベースソリューションの1つとしてImpalaのパフォーマンス向上に注力しています。実際、最新のリリースでは2つ前のバージョンに比べ、セキュアなワークロードのパフォーマンスは12倍にまで向上しています。Clouderaは、今後もコストパフォーマンスの向上に加え、パブリッククラウドの他のオブジェクトストアに対するサポートの追加など、クラウドに注力した機能向上を図って行きます。

Mostafa Mokhtarは、ClouderaのImpalaチームに所属するソフトウェアエンジニアです。Devadutta Ghatは、Clouderaのシニアプロダクトマネージャーです。Henry Robinsonは、Clouderaのソフトウェアエンジニアであり、Apache Impala PMCのメンバーです。Sailesh Mukilは、Clouderaのソフトウェアエンジニアであり、Apache Impala PMCのメンバーです。