跳到主要内容
得到一个演示

クラウドデータウェアハウスのベンチマーク2020：红移，雪花，转眼间，BigQuery的

作者乔治·弗雷泽

最新のベンチマークで，BigQuery中，的Presto，红移，雪花の価格，パフォーマンス，机能の特长を比较

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

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

亚马逊红移

雪花

普拉斯托

谷歌bigquery.

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

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

このベンチマークのソースコードは，HTTPS：//github.com/fivetran/benchmarkで入手できます。
どのデータをクエリしたか吗?
TPC-DS[1]データセットを1 tbの規模で生成しました。TPC-DSには,雪花のスキーマに,架空の小売業者の网络,カタログ,そして店舗の売上を表す24のテーブルがあります。最大のファクトテーブルは40億行でした[2]。
どのクエリを実行したか吗?
2020年2月から9月に，99回のTPC-DSクエリ[3]を実行しました。これらのクエリは复雑で，多くの结合，集计，サブクエリが含まれています。ウェアハウスが以前の结果をキャッシュしないように，各クエリを1回のみ実行しました。
ウェアハウスをどのように构成したか？
100GB 1TBと规模の大小の构成で，各ウェアハウスを设定しました。
構成
コスト/時間[4]
ウェアハウスをどのように調整したか吗?
データウェアハウスには，それぞれ，ソートキー，クラスタリングキー，デートパーティショニングなどの高度な机能があります。
今回のベンチマークでは,これらの機能を使用しないことにしました[7]。
红移では列圧縮エンコーディングを,雪花とBigQueryでは自動圧縮を適用し,转眼间は圧縮形式であるHDFSで兽人ファイルを使用しました。
データウェアハウスベンチマーク2020
红移，雪花，转眼间，BigQuery的を比较
レポートをダウンロード
结果
すべてのウェアハウスが，アドホックでインタラクティブなクエリに适した，优れた実行速度でした。コストを计算するために，ランタイムに构成1秒あたりのコストを挂けました[8]。
各ウェアハウスはどのように异なるのか？
各ウェアハウスには，独自のユーザーエクスペリエンスと価格モデルがあります。スペクトルに沿って并べると以下のようになります。
最も「自己ホスト型」なのは的Prestoで，ユーザーはサーバーのプロビジョニングと的Prestoクラスターの详细な构成を実施することになります。一部のユーザーにとっては重要なことですが，今回のベンチマークで扱ったの他のウェアハウスと异なり，普雷斯托はオープンソースです。
RA3以前の红移はほぼ十分に管理されていますが，それでもユーザーは，固定量のメモリ，コンピューティング，およびストレージを使用して，个々のコンピューティングクラスターを构成しなければなりません.Redshift RA3は，コンピューティングをストレージから分离することにより，雪花のユーザーエクスペリエンスに近いものを红移で実现しています。
雪花は,ほぼサーバーレスで,ユーザーはコンピューティングクラスターのサイズと数のみを設定します。コンピューティングクラスターは数秒で作成,削除可能であり,すべてのクラスターは同じデータを認識します。雪花にはさまざまな機能に紐付いた複数の価格帯があり、最も安価な「スタンダード」に基づいて計算されています。ワークロードに「エンタープライズ」または「ビジネスクリティカル」を使用する場合、コストは1.5倍か2倍になります。
BigQuery的の定额料金は雪花と同じくらいですが，BigQuery的にはコンピューティングクラスターの概念がなく，构成可能な多くの「计算スロット」が存在する点で雪花と异なっています.BigQueryオンデマンドは纯粋なサーバーレスモデルであり，ユーザーはクエリを1つずつ送信し，クエリごとに支払うことになります。オンデマンドモードはワークロードの性质に応じて，かなり高価になることも，かなり安価になることもあります。コンピューティング能力を24时间年中无休で利用する「安定した」ワークロードは，定额モードで利用した方がはるかに安価になります。长期间利用されない状态または使用率の低下が散见される，定期的かつ大规模なクエリのある「とがった」ワークロードは，オンデマンドモードで利用した方がはるかに安価になります。
今回の结果が以前のベンチマークと异なるのはなぜか？
GigaOm等のクラウドデータウェアハウスのパフォーマンスベンチマーク
2019年4月，GigaOm等は，BigQuery中，红移，雪花，および天青SQL数据仓库（天青突触）で，TPC-DSクエリを実行しました。このベンチマークはマイクロソフトの支援を受けて実施されました0.30倍以上のデータを使用しました（1TBに対する30TBの规模）。システムごとに异なるサイズのクラスターを构成し，ランタイムは私たちが実施した场合よりもはるかに遅いことを确认しました。
システム
クラスターコスト
几何平均值の所要时间
$181 / 時間
$ 144 /时间
$128 / 時間
$ 55 /时间
Gigaomのベンチマークで,クラスターで5 ~ 10倍,データで30倍も私たちのものよりも規模が大きかったことを考えると,このような時間がかかったのは不思議なことです。
亚马逊红移与BigQuery的のベンチマーク
2016年10月,亚马逊はBigQueryと红移の両方でTPC-DSクエリを実行しました。亚马逊は,红移が6倍高速であり,BigQueryの実行時間は通常1分より長いと報告しました。亚马逊のベンチマークと当社のベンチマークの主な違いは次のとおりです。
亚马逊は10倍大きいデータセット结核対1 tb(10)と2倍大きい红移クラスター(38.40美元/時間対19.20美元/時間)を使用。
亚马逊はソートキーと分散キーを使用してウェアハウスを调整。当社は调整せず。
BigQuery的标准-SQLは2016年10月时点ではベータ版。このベンチマークを実行した2018年后半までに高速化した可能性あり。
自社制品が最良であると主张するベンダーによるベンチマークの结果は，割り引いて捉えるべきです.Amazonのブログ投稿には明记されていない点も多くあります。たとえば，亚马逊は巨大な红移クラスターを使用したと述べています。现実的な构成ではないですが，このベンチマークを超高速で完了するために，すべてのメモリを単一ユーザーに割り当てたのでしょうか？事実は不明です.AWSがベンチマークを再现するために必要なコードを公开して，それがどれほど现実的であるかを评価できれば素晴らしいと思います。
潜望镜の红移与雪花与BigQueryのベンチマーク
同じく2016年10月,潜望镜数据は10億行のファクトテーブルを小さなディメンションテーブルに結合する,1時間ごとの集約クエリの3つのバリエーションを用いて,红移,雪花,BigQueryを比較しました。その結果,红移はBigQueryとほぼ同じ速度であり,雪花はBigQueryより2倍遅いことが判明しました。潜望镜のベンチマークと当社のベンチマークの主な違いは次のとおりです。
潜望镜は同じクエリを复数回実行し，红移のコンパイル时间の遅延を除外。
潜望镜のクエリは，TPC-DSクエリよりもはるかに単纯。
「简単な」クエリでベンチマークを実行すると，すべてのウェアハウスがかなり良いパフォーマンスを発挥するでしょう。
雪花が简単なクエリを高速で実行し，红移が简単なクエリを非常に高速で実行するといったことは重要ではありません。重要なのは，难しいクエリを十分な速さで実行できるかどうかです。
潜望镜もコストを比較しましたが,クエリあたりのコストを当社とは多少異なるアプローチで計算していました。当社と同じように,潜望镜は顧客が実際使用するデータを調べましたが,利用されない期間の割合を調べる代わりに,1時間あたりのクエリ数を調べました。ほとんどの(すべてではありませんが)潜望镜の顧客は红移の方が安価だと思うだろうと考えましたが,実際のところ価格に大きな違いはありませんでした。
马克Litwintschikによる“十一億回のタクシー乗車”ベンチマーク
马克Litwintshikは,2016年4月にBigQueryを,2016年6月に红移をベンチマークしました。11億行の単一のテーブルに対して4つの単純なクエリを実行するというものでした。そして,BigQueryの速度が红移クラスターとほぼ同じであり,当社のクラスターの約2倍(41美元/時間)であることがわかりました。どちらのウェアハウスも1 ~ 3秒でクエリを完了しましたが,おそらく,これが最も単純なクエリの最短の実行時間である”パフォーマンスの下限”なのでしょう。

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

データウェアハウスベンチマーク2020
红移，雪花，转眼间，BigQuery的を比较
レポートをダウンロード
注釈
[1] TPC-DSは，データウェアハウス向けの业界标准のベンチマークです。当社はTPC-DSデータとクエリを使用しましたが，このベンチマークは公式のTPC-DSベンチマークではありません。当社では1つのスケールのみを使用し，クエリをわずかに変更し，データウェアハウスを调整したり代替バージョンのクエリを生成したりしなかったためです。
[2]これはデータウェアハウスの基準では小規模ですが,Fivetranユーザーは,複雑なスキーマでありながらサイズが適度なSalesforceやMySQLなどのデータソースにご関心があることがほとんどです。
[3]若干クエリを変更して,すべてのウェアハウスで実行できるようにしなければなりませんでした。当社が行った変更はわずかで,ほとんどは型名の変更でした。レガシーSQLではなくBigQuery標準SQLを使用しました。
[4]クエリあたりのコストを計算するにあたり,各ウェアハウスの使用率を50%であると仮定しました。
[5]雪花のコストは,AWSの”標準”価格に基づいています。”“エンタープライズや”ビジネスクリティカル”などの上位プランを使用する場合,コストは1.5倍か2倍になります。
[6]转眼间はオープンソースのクエリエンジンであるため,実際にはこのベンチマークの商用データウェアハウスとは比較できません。しかし,この分野における重要なオープンソースの代替手段となり得ます。当社は转眼间の亮光のうちv0。329年を使用しました。利用料は谷歌云上に例示されているオンデマンドコストに基づいています。
[7]的BigQueryは纯粋な共有リソースクエリサービスであり，「构成」に相当するものは存在しません。単纯に大量查询へクエリを送信すれば，结果が返ってきます。
[8]ウェアハウスで実行されるクエリの種類が分かっている場合は,これらの機能でテーブルを調整し,特定のクエリをはるかに高速で処理することができます。ただし,一般的なFivetranユーザーは,あらゆる種類の予測不可能なクエリをウェアハウスで処理するため,同機能による調整の効果が反映されないクエリが常に多数存在します。
[9]実際のデータウェアハウスは,稼働期間の50%は使用されていない状態であると想定されるため,1秒あたりの基本コストに2を乗じています。