Skip to main content

クラウド型データウェアハウスのベンチマーク2020:Redshift、Snowflake、Presto、BigQuery

最新のベンチマークで、BigQuery、Presto、Redshift、Snowflakeの価格、パフォーマンス、機能の特長を比較

過去2年間、主なクラウドデータウェアハウスのパフォーマンスは、どれもほぼ同程度でした。RedshiftとBigQueryは、Snowflakeと同程度のユーザーエクスペリエンスを実現しています。この業界では、コンピューティングとストレージの分離、断続的なワークロードの処理で「急上昇」する可能性のある料金を定額に抑えることの二つが重要とされています。

Fivetranは、アプリ、データベース、ファイルストアのデータを、顧客のデータウェアハウスに同期するデータパイプラインです。最も多くユーザーからいただく質問は、「どのデータウェアハウスを選ぶべきか」というものです。この質問にお答えするために、最も利用されている以下の4大データウェアハウスについて、速度とコストを比較するベンチマークを実施しました。

  • Amazon Redshift
  • Snowflake
  • Presto
  • Google BigQuery

ベンチマークには、

  • 「どのような種類のデータを使用するか?」
  • 「料金は?」
  • 「どんなクエリを処理するか?」

といった項目の選択が重要です。これらの質問にどう回答するかが非常に重要です。データの形状やクエリの構造を変更すると、最速のウェアハウスが最も遅いという結果が出ることもあります。そこで、典型的なFivetranユーザーが行うであろう選択を試みました。そうすれば、Fivetranを使用する企業に役立つ結果が得られます。

典型的なFivetranユーザーは、Salesforce、JIRA、Marketo、Adwords、およびそれらの本番Oracleデータベースをデータウェアハウスに同期することがあります。これらのデータソースはそれほど大きくなく、一般的なソースには数十から数百ギガバイトのデータが含まれます。しかし、それらのデータは複雑です。正規化されたスキーマには数百のテーブルが含まれており、お客様がこのデータのサマリを作るには複雑なSQLクエリを作成することになります。

このベンチマークのソースコードは、https://github.com/fivetran/benchmarkで入手できます。


どのデータをクエリしたか?

TPC-DS[1]データセットを1TBの規模で生成しました。TPC-DSには、Snowflakeのスキーマに、架空の小売業者のWeb、カタログ、そして店舗の売上を表す24のテーブルがあります。最大のファクトテーブルは40億行でした[2]。

 

どのクエリを実行したか?

2020年2月から9月に、99回のTPC-DSクエリ[3]を実行しました。これらのクエリは複雑で、多くの結合、集計、サブクエリが含まれています。ウェアハウスが以前の結果をキャッシュしないように、各クエリを1回のみ実行しました。
 

ウェアハウスのコンフィギュレーション

100GBと1TB規模の大小の構成で、各ウェアハウスを設定しました。

  Configuration Cost / Hour [4]
Redshift 5x ra3.4xlarge $16.30
Snowflake [5] Large $16.00
Presto [6] 4x n2-highmem-32 $8.02
BigQuery [7] Flat-rate 600 slots $16.44

ウェアハウスの微調整

データウェアハウスには、それぞれ、ソートキー、クラスタリングキー、デートパーティショニングなどの高度な機能があります。
今回のベンチマークでは、これらの機能を使用しないことにしました[7]。
Redshiftでは列圧縮エンコーディングを、SnowflakeとBigQueryでは自動圧縮を適用し、Prestoは圧縮形式であるHDFSでORCファイルを使用しました。

 

2020 データウェアハウスベンチマークレポート

本レポートでは、Redshift、Snowflake、Presto、BigQueryを比較しています。こちらからダウンロードが可能です。

 

結果

すべてのウェアハウスが、アドホックでインタラクティブなクエリに適した、優れた実行速度でした。コストを計算するために、ランタイムに構成1秒あたりのコストを掛けました[8]。

 

各ウェアハウスの違い

各ウェアハウスには、独自のユーザーエクスペリエンスと価格モデルがあります。スペクトルに沿って並べると以下のようになります。


最も「自己ホスト型」なのはPrestoで、ユーザーはサーバーのプロビジョニングとPrestoクラスターの詳細な構成を実施することになります。一部のユーザーにとっては重要なことですが、今回のベンチマークで扱ったの他のウェアハウスと異なり、Prestoはオープンソースです。
RA3以前のRedshiftはほぼ十分に管理されていますが、それでもユーザーは、固定量のメモリ、コンピューティング、およびストレージを使用して、個々のコンピューティングクラスターを構成しなければなりません。Redshift RA3は、コンピューティングをストレージから分離することにより、Snowflakeのユーザーエクスペリエンスに近いものをRedshiftで実現しています。
Snowflakeは、ほぼサーバーレスで、ユーザーはコンピューティングクラスターのサイズと数のみを設定します。コンピューティングクラスターは数秒で作成、削除可能であり、すべてのクラスターは同じデータを認識します。Snowflakeにはさまざまな機能に紐付いた複数の価格帯があり、最も安価な「スタンダード」に基づいて計算されています。ワークロードに「エンタープライズ」または「ビジネスクリティカル」を使用する場合、コストは1.5倍か2倍になります。
BigQueryの定額料金はSnowflakeと同じくらいですが、BigQueryにはコンピューティングクラスターの概念がなく、構成可能な多くの「計算スロット」が存在する点でSnowflakeと異なっています。BigQueryオンデマンドは純粋なサーバーレスモデルであり、ユーザーはクエリを1つずつ送信し、クエリごとに支払うことになります。オンデマンドモードはワークロードの性質に応じて、かなり高価になることも、かなり安価になることもあります。コンピューティング能力を24時間年中無休で利用する「安定した」ワークロードは、定額モードで利用した方がはるかに安価になります。長期間利用されない状態または使用率の低下が散見される、定期的かつ大規模なクエリのある「とがった」ワークロードは、オンデマンドモードで利用した方がはるかに安価になります。

 

前回のベンチマークの結果と異なるのはなぜか?

Gigaomのクラウドデータウェアハウスのパフォーマンスベンチマーク


 

2019年4月、Gigaomは、BigQuery、Redshift、Snowflake、およびAzure SQL Data Warehouse(Azure Synapse)で、TPC-DSクエリを実行しました。このベンチマークはマイクロソフトの支援を受けて実施されました。30倍以上のデータを使用しました(1TBに対する30TBの規模)。システムごとに異なるサイズのクラスターを構成し、ランタイムは私たちが実施した場合よりもはるかに遅いことを確認しました。


システム
クラスターコスト
Geomeanの所要時間
$181 / 時間
$144/ 時間
$128 / 時間
$55 / 時間
Gigaomのベンチマークで、クラスターで5〜10倍、データで30倍も私たちのものよりも規模が大きかったことを考えると、このような時間がかかったのは不思議なことです。
Amazon Redshift vs. BigQueryのベンチマーク
2016年10月、AmazonはBigQueryとRedshiftの両方でTPC-DSクエリを実行しました。Amazonは、Redshiftが6倍高速であり、BigQueryの実行時間は通常1分より長いと報告しました。Amazonのベンチマークと当社のベンチマークの主な違いは次のとおりです。
Amazonは10倍大きいデータセット(10TB 対 1TB)と2倍大きいRedshiftクラスター($38.40/時間 対 $19.20/時間)を使用。
Amazonはソートキーと分散キーを使用してウェアハウスを調整。当社は調整せず。
BigQuery Standard-SQLは、2016年10月時点ではベータ版。このベンチマークを実行した2018年後半までに高速化した可能性あり。
自社製品が最良であると主張するベンダーによるベンチマークの結果は、割り引いて捉えるべきです。Amazonのブログ投稿には明記されていない点も多くあります。たとえば、Amazonは巨大なRedshiftクラスターを使用したと述べています。現実的な構成ではないですが、このベンチマークを超高速で完了するために、すべてのメモリを単一ユーザーに割り当てたのでしょうか?事実は不明です。AWSがベンチマークを再現するために必要なコードを公開して、それがどれほど現実的であるかを評価できれば素晴らしいと思います。
PeriscopeのRedshift vs. Snowflake vs. BigQuery のベンチマーク
同じく2016年10月、Periscope Dataは、10億行のファクトテーブルを小さなディメンションテーブルに結合する、1時間ごとの集約クエリの3つのバリエーションを用いて、Redshift、Snowflake、BigQueryを比較しました。その結果、RedshiftはBigQueryとほぼ同じ速度であり、SnowflakeはBigQueryより2倍遅いことが判明しました。Periscopeのベンチマークと当社のベンチマークの主な違いは次のとおりです。
Periscopeは同じクエリを複数回実行し、Redshiftのコンパイル時間の遅延を除外。
Periscopeのクエリは、TPC-DSクエリよりもはるかに単純。
「簡単な」クエリでベンチマークを実行すると、すべてのウェアハウスがかなり良いパフォーマンスを発揮するでしょう。
Snowflakeが簡単なクエリを高速で実行し、Redshiftが簡単なクエリを非常に高速で実行するといったことは重要ではありません。重要なのは、難しいクエリを十分な速さで実行できるかどうかです。
Periscopeもコストを比較しましたが、クエリあたりのコストを当社とは多少異なるアプローチで計算していました。当社と同じように、Periscopeは顧客が実際使用するデータを調べましたが、利用されない期間の割合を調べる代わりに、1時間あたりのクエリ数を調べました。ほとんどの(すべてではありませんが)Periscopeの顧客はRedshiftの方が安価だと思うだろうと考えましたが、実際のところ価格に大きな違いはありませんでした。
Mark Litwintschikによる「11億回のタクシー乗車」ベンチマーク
Mark Litwintshikは、2016年4月にBigQueryを、2016年6月にRedshiftをベンチマークしました。11億行の単一のテーブルに対して4つの単純なクエリを実行するというものでした。そして、BigQueryの速度がRedshiftクラスターとほぼ同じであり、当社のクラスターの約2倍($ 41 /時間)であることがわかりました。どちらのウェアハウスも1〜3秒でクエリを完了しましたが、おそらく、これが最も単純なクエリの最短の実行時間である「パフォーマンスの下限」なのでしょう。

結論

これらのウェアハウスはすべて、コストもパフォーマンスも優れています。高速な列指向データウェアハウスを構築する基本的な手法は、2005年にC-Storeの論文が公開されて以来よく知られているので、異なるウェアハウスが互いに似通っていても驚くことではありません。これらのデータウェアハウスは間違いなく、列指向ストレージ、コストベースのクエリ計画、パイプラインの実行、ジャストインタイムコンパイルといった、通常効果的だとされている手法を用いています。あるデータウェアハウスが別のデータウェアハウスよりも劇的に高速だと主張するベンチマークには、疑いの目を向けるべきでしょう。
ウェアハウス間の最も大きな違いは、設計の違いによって生じる質的な違いです。同調性を強調するウェアハウスもあれば、使いやすさを強調するものもあります。データウェアハウスを評価する際は、複数のシステムをデモで試したうえで、貴社にとって最適なバランスのシステムを選んでください。
Fivetranについて:データの自動統合ツールのリーダー企業であるFivetranは、スキーマとAPIの変更に応じて自動的に適応し、すぐに利用可能なコネクタを提供することで、信頼性の高い一貫したデータへのアクセスを保証します。Fivetranは、ソースアプリケーションから任意の宛先にデータを継続的に同期することで、
データ駆動型の意思決定の精度を向上し、アナリストが可能な限り最新のデータを処理できるようにします。分析を加速するために、Fivetranはウェアハウス内でのデータの変換を可能にし、ソース固有の分析テンプレートを提供します。fivetran.comで、変化への柔軟な対応を実現するデータ統合の詳細をご覧いただけます。fivetran.com/signupでは、無料トライアルをお試しいただくことも可能です。

データウェアハウスベンチマーク2020
Redshift、Snowflake、Presto、BigQueryを比較
レポートをダウンロード


注釈

[1] TPC-DSは、データウェアハウス向けの業界標準のベンチマークです。当社はTPC-DSデータとクエリを使用しましたが、このベンチマークは公式のTPC-DSベンチマークではありません。当社では1つのスケールのみを使用し、クエリをわずかに変更し、データウェアハウスを調整したり代替バージョンのクエリを生成したりしなかったためです。

[2] これはデータウェアハウスの基準では小規模ですが、Fivetranユーザーは、複雑なスキーマでありながらサイズが適度なSalesforceやMySQLなどのデータソースにご関心があることがほとんどです。

[3] 若干クエリを変更して、すべてのウェアハウスで実行できるようにしなければなりませんでした。当社が行った変更はわずかで、ほとんどは型名の変更でした。レガシーSQLではなくBigQuery標準SQLを使用しました。

[4]クエリあたりのコストを計算するにあたり、各ウェアハウスの使用率を50%であると仮定しました。

[5] Snowflakeのコストは、AWSの「標準」価格に基づいています。「エンタープライズ」や「ビジネスクリティカル」などの上位プランを使用する場合、コストは1.5倍か2倍になります。

[6] Prestoはオープンソースのクエリエンジンであるため、実際にはこのベンチマークの商用データウェアハウスとは比較できません。しかし、この分野における重要なオープンソースの代替手段となり得ます。当社はPrestoのStarburstのうちv0. 329を使用しました。利用料はGoogle Cloud上に例示されているオンデマンドコストに基づいています。

[7] BigQueryは純粋な共有リソースクエリサービスであり、「構成」に相当するものは存在しません。単純にBigQueryへクエリを送信すれば、結果が返ってきます。

[8] ウェアハウスで実行されるクエリの種類が分かっている場合は、これらの機能でテーブルを調整し、特定のクエリをはるかに高速で処理することができます。ただし、一般的なFivetranユーザーは、あらゆる種類の予測不可能なクエリをウェアハウスで処理するため、同機能による調整の効果が反映されないクエリが常に多数存在します。

[9] 実際のデータウェアハウスは、稼働期間の50%は使用されていない状態であると想定されるため、1秒あたりの基本コストに2を乗じています。