適切なデータウェアハウスの選択は、一般的なデータおよび分析的なビジネスニーズにおいて重要な要素ですが、企業がデータウェアハウスのプロバイダーを選ぶ際に「 ビジネスニーズに合わせて、Snowflake、Amazon RedShift、または Google の BigQuery のデータウェアハウスを使うべきか」というのが、最大の疑問の一つとして浮かびます。

Amazon RedShift と Snowflake、Google BigQuery と Snowflake の比較は既にご紹介しましたが、では Amazon RedShift と Google BigQuery はどうでしょうか。

Amazon と Google はどちらにも、RedShift と BigQuery を備えた印象深いデータ ウェアハウスがあり、このソリューションはそれぞれ、分析を大規模かつ高速に実行することができます。ここでは、単純には比べられないものを比較しているのではなく、同一条件で比較しているのですが、それぞれが得意とする実際のユースケースがあり、ビジネスの状況ニーズに応じてどちらのソリューションもその価値を発揮してくれます。

Integrate.io はどちらのソリューションにも対応していることから、本記事が、特定のワークフローやプロジェクトに最適なデータウェアハウスを把握したい企業のためのガイドになれば幸いです。

目次

はじめに

Amazon RedShift と Google BigQuery は、どちらもビジネスにとって有効なツールであり、この２つのどちらを選ぶかは、ビジネスモデルや好みによります。

以下の場合だと、RedShift の方がよりいい結果が期待できるでしょう：

  • 日常業務でデータウェアハウスを使用している
  • 常に予測可能なワークロードとオペレーションがある
  • コストや管理の面で、よりシンプルなソリューションが必要
  • ワークフローが、他の Google テクノロジーに基づくものではない

以下の場合だと、BigQuery を使った方がいい結果が出ると思われます：

  • データマイニング業務にデータウェアハウスを利用している
  • データウェアハウスは、日常業務に大きく関わるものではない
  • 条件が大きく異なるプロジェクトを数多く受注している
  • 業務が頻繁に変わるため、ワークフローの一貫性がない
  • すでに他の Google プラットフォームに依存している

ビジネスはどれも同じではなく、業務内容や両者の特徴のより詳しい確認が必要です。本記事で、各プラットフォームの詳細と、それがどのように役立つかをぜひご確認ください。

RedShift と BigQueryの主な違い３つ

  1. Amazon RedShift はクラスタとノードでプロビジョニングされ、Google BigQuery はサーバーレスである。
  2. RedShift は１つのテーブルで１,６００カラムをサポートし、BigQuery は１０,０００カラムをサポートする。
  3. RedShift はテーブルをバキュームするなどの定期的な管理作業が必要であり、BigQueryは自動管理である。

データウェアハウスとは

データウェアハウス（”カラムナ（列）型ストレージソリューション”と呼ばれることもある）は、企業のBI（ビジネスインテリジェンス）のための保管装置であり、 RedShift と BigQuery はどちらもデータウェアハウスです。ブレンドされた技術スタックから得られるデータをすべてこのウェアハウスの１つに入れ、その上で分析を開始し、重要なビジネス上の意思決定、トレンドの予測、予算、その他の重要なビジネスプロセスの決定に役立てることができます。

トレンド分析は、データウェアハウスの典型的な使用例です。企業は、分析ワークロードの実行のために、カスタマーサービス、マーケティング、セールス、HRなどの技術スタックデータをすべてウェアハウスに押し込みます。

データウェアハウスのユースケース事例

例：企業は、売上につながりそうな見込み客についてもっと知りたいと思うものです。そうすることで、顧客をより深く理解し、セールストークやコンテンツ配信を個別化することができますからね。それには、どの見込み客が最も価値があり、どの見込み客が最も離反しやすいかを発見するのに、Salesforceのデータをデータウェアハウスに接続してクエリを実行するといいでしょう。

その他のデータウェアハウスの機能

RedShift や BigQuery のようなデータウェアハウスには、カラム型ストレージの他に、MPP（超並列処理）があります。これにより、クエリのリクエストを複数のサーバーに分散して処理を高速化することができるので、それぞれ独自のメモリと OS（オペレーティングシステム）がある複数のプロセッサーが、クエリの特定のセグメントを処理してくれます。

ちなみに、データウェアハウスが分析ワークロードに価値がある理由を本当に理解するには、OLTP（オンライントランザクション処理）と OLAP（オンライン分析処理）のデータ処理システムの違いがわかってないといけません。

データ処理システムを理解しよう

では早速、OLTP と OLAP のデータ処理システムの違いをみてみましょう。

OLTP（オンライントランザクション処理）

OLTP（オンライントランザクション処理）は、ほとんどの企業で日常業務でのトランザクション処理に使用されているものであり（ATM、小売販売システム、テキストメッセージなどを考えてみてください）、４０年以上にわたって使用されてきました（SQL が７０年代初頭にリリースされたというのは、いまだに信じられない話です）。OLTPでは、テーブルの各行はオブジェクトとして保存されます。

OLTP はデータ処理を主な目的としており、複数のシーケンスでデータの整合性を保ちながらの迅速な処理に長けています。

OLTP のユースケース事例

例えば、２人が同じオンライン銀行口座から正確に同じ瞬間にお金を引き出すとします。OLTP は、最初に承認されたユーザーを選び、そのトランザクションを処理します。そして、たとえ２人が同時に操作を開始したとしても、どちらのユーザーも銀行口座の残高以上のお金を引き出すことができないようにします。

これを行うには、OLTP はクエリ内の行すべてに対してチェックを実行します。 このようにACID（原子性、一貫性、分離、耐久性）トランザクションを実行できることから、OLTP はエラーや障害が発生した場合のデータの有効性の確保に非常に有効です。

OLAP（オンライン分析処理）

OLAP（オンライン分析処理）は、データウェアハウスがクエリの実行に使うものです。各カラムをオブジェクトとして保存するため、膨大なデータセットをクロールしてトレンドを見つけるのに適しています。また、データの断片を飛び越えて、集計に必要な正確なデータを見つけることができます。

OLAPのユースケース事例

例えば、「ウィキペディアの全改訂を検索する」のように、OLTP データベースでクエリを実行したいとします。OLTP データベースは、その処理の実行のために、すべての行の全フィールドにアクセスしないといけないですが、OLAPだと、カラムを使って必要なフィールドだけにアクセスすることができるので、膨大な計算パワーと時間の節約になります。

実際、OLAPの分析処理は非常に速く、データウェアハウスを利用する企業の大半は、１０秒以内（１０秒以下）の速度を求めています。確かに１時間以上かかるようなユースケースもありますが、その場合は大量のデータと超複雑なスキーマを扱っているのでしょう。

OLTPとOLAPについての詳細はコチラ

RedShift とは

RedShift は Aamzon のデータウェアハウスで、同社の巨大なクラウド全体のアーキテクチャである AWS の一部です。

Amazon は、ParAccel Analytic Database（カラムナデータ編成を利用した PostgreSQL ベースのデータベース）を開発していた ParAccel から、 RedShift のソースコードを入手しました。つまり、RedShift は PostgreSQL のフォークで構築された MPP データウェアハウスなのです。

RedShift には、リレーショナルであることなど、 PostgreSQL との共通点が多くありますが、ユニークなカラム構造です。インデックスに対応しておらず、データ整理には分散スタイルとキーが使われます。また、Amazon は RedShift に対して、PostgreSQL とは異なる独自のクエリ実行エンジンを搭載しています。

RedShift が PostgreSQL のフォークの上に構築されていることにおける重要な点は、トランザクションの特質をある程度維持していることで、一種のハイブリッドデータベースになっていることです。RedShift はトランザクションのロールバックが可能であり、これはデータウェアハウス市場において半端なくユニークな機能です。

Integrate.io の RedShift ネイティブコネクタの詳細については、統合のページをご覧ください。

BigQueryとは

BigQuery は Google のデータウェアハウスであり、Google の巨大なクラウド全体のアーキテクチャである Google Cloud の一部です。

BigQuery は、C-Store と Monet DB に続いて市場に登場した最初の主要なデータウェアハウスの１つであり、RESTインターフェース上で Dremel（Googleが開発した、SQLに似た構文をサポートする読み取り専用のネストデータ用クエリーエンジン）を実行することで機能します。

Google は Dremel をこのように定義しています：

「Dremel "は、非常に大きなデータセットに対してSQLのようなクエリを実行し、わずか数秒で正確な結果を得ることができるクエリサービスです。」

BigQuery が発売された当初は、Dremel の奇妙なハイブリッドSQL言語を厳密に維持していましたが、これは最高に厄介でした。現在は、標準的な SQL言語に対応しています。

Google には BigQuery の運用を支える独自の技術がいくつかありますが、ここでは、典型的なジョブの実行について簡単にご紹介します：

  • Borg（Googleの大規模クラスタ管理）：Dremel のジョブ（通常、GoogleのWeb UI またはRESTで実行される）にリソースを割り当てる。
  • Colossus（Google の惑星規模のストレージシステム）：Dremel の各ジョブにデータを提供する。
  • Capacitor（Googleのカラムナストレージフォーマット）：Dremel のジョブのために引き出されるデータを整理して圧縮する。
  • Juniper（Googleの内部データネットワーク）：Dremel のジョブが Colossus システムのデータを読み取るのを翻訳して支援する。

Integrate.io のネイティブ Google BigQuery コネクタの詳細については、統合のページをぜひご覧ください。

RedShift と BigQuery の比較

どのプラットフォームが適しているかを判断するには、ビジネスに関連するものに基づいて、価格、性能、管理性など、それぞれの機能を比較します。ただ、自分のビジネスが他のビジネスとは違った優先順位である場合があり、それによって比較の結果が変わってきます。

価格

RedShift

RedShift の価格モデルは、非常にシンプルです。この比較のために RedShift Spectrum の価格について掘り下げるつもりはありませんが、詳細については、コチラで確認することができます。

ちなみに RedShift Spectrumは、追加機能を持つプレミアム製品であるため、この分析には含まれていません。RedShift Spectrum は BigQuery が提供するどの製品ともあまり比較にならず、その機能を特に必要とする企業向けと言えるでしょう。

RedShift Spectrum は、Amazon S3ストレージに対して RedShift クエリを直接実行することができ、それがビジネスニーズに Amazon シンプルストレージを使っている場合だと、データレイクを利用するのに便利です。もしそうであれば、RedShift Spectrum はほぼ自動的にあなたのビジネスにとってより良い選択肢となります。

RedShift では、『Dense Compute（DC2）』か大容量の『Dense Storage』を選べ、一番安いノードをスピンアップすると、１時間あたり０.２５ドルで、dc2.large ノードで１６０GBになります。Dense Storage は１時間あたり１TB（テラバイト）あたり０.４２５ドルで実行され、このコストは、ストレージと処理の両方をカバーします。計算すると、RedShift で得られる最安値は１TBあたり月額３０６ドルになりますが、前払いによる大規模な割引もあります。

これで、RedShift を扱うのが面白くなります。実行時間や各ノードをスピンアップする頻度を計算できれば、特に前払いならコストを劇的に削減できます。ほとんどの企業は RedShift ノードを常時稼働させるわけではないので、細分化するのが通常は最善の方法です。

例えば、あなたのスタックやサービスが利用される日中だけ RedShift を実行することもできます。そのような場合は、その行動を反映させるために、先行購入の習慣を調整するといいでしょう。

BigQuery

BigQuery の価格設定はもっと複雑です。表面的には、BigQuery の方が安く見えます。ストレージは１TBあたり月額２０ドルで、RedShift より２８６ドルも安いです。ただ、BigQuery はストレージとクエリに別々に課金し、クエリは１TBあたり５ドルです。つまり、ストレージは安くても、クエリのコストはすぐに膨らんでしまうのです。

この方法には良し悪しがあります。本当に、BigQuery はある一定の顧客には最適です。例えば、急増するワークロードを扱っているビジネスがあるとしましょう。急激なクエリを１日に数回実行するような場合、RedShift は時間単位で支払う必要があるため、BigQuery の方がはるかに良い選択肢でしょう。また、非常に大規模でスパイキーなワークロードを扱うことになることから、MLやデータマイニングを行うデータサイエンティストにとっても、BigQuery は最適なソリューションかもしれません。

どっちがいい？

BigQuery は、ストレージ回線に１TBあたり月額２０ドル、そのストレージ回線での処理に１TBあたり５ドルかかります。

対する RedShift は、ストレージとそのストレージに対する無制限の処理に対して、１TBあたり月額３０６ドルかかります。

どっちがいいとかはないですね。ほとんどの企業で日常的に行うデータウェアハウス運用では RedShift の方が経済的ですが、データマイニングを行いたい企業や、極めて多様なワークロードを扱う企業にとっては、BigQuery の方がいいでしょう。

価格選択の例

両者が実際のシナリオでどのように比較されるかを見てみると、いい参考になるでしょう。ここでは、実際の使用例に基づいて、例を２つご紹介します。

例１

例えば、１日のうち５％程度しかクエリを実行しないとしましょう。この場合、クエリ処理にオンデマンドでお金を払うことになるので、おそらく BigQuery の方が費用対効果が高くなります。処理したデータに対して５ドル/TBを支払うので、１日に１００GBの塊を３つしか処理できないかもしれません。この場合、１.５０ドルにストレージの０.７０ドルがかかることになります。このようなことは、データウェアハウスを使ってデータマイニングのジョブを塊で実行することをメインにしている企業ではよくあることです。また、１日に数回ジョブを実行するデータサイエンティストにとっても、BigQuery は貴重な存在となっています。

例２

ビジネスをするにあたって、販売やマーケティングのために、日常的にウェアハウスを利用したいと考えているとすると、一定の実行時（ランタイム）と、１日に何百、何千回とクエリを実行できる能力が必要です。RedShift だと、クエリごとに課金されることがないため、おそらく安価になるはずです。では、その数百のクエリがそれぞれ５０GBを処理するとしましょう。BigQuery では５ドル/TBを支払うことになり、コストはどんどん膨らんでいきますが、RedShift の場合は、ノードの使用時間に応じて課金されるだけです。

詳しくは、BigQuery の価格ページ と RedShift の価格ページをご覧ください。

性能

RedShift と BigQuery の比較では、性能面が厄介です。BigQuery は、処理するデータ量に応じて価格を抽象化するだけなので、クエリを実行するときに特定のリソースに縛られることはありません。一方、RedShift は実行するノードによって制限されます。しかし、クエリの性能に関わる要因はそれだけではありません。

データテーブルのサイズやスキーマの複雑さ、実行する同時クエリの数（どちらも最大５０）なども大きな違いになります。長年にわたり、両者を比較するベンチマークは数多く存在していますが、そのベンチマークはいずれも、広い意味で言えば特に参考になるものではありません。


以下に挙げられたリストを見れば、BigQuery と Amazon のベンチマーク戦争の一部がいかに訳のわからないものであるかがわかると思います。

  • Google は２０１６年にサンフランシスコで開催された CloudAir で TPC-H ベンチマークを発表し、BigQuery が Amazon を上回ることを示しました（性能のメトリクスは２６個すべてではなく、１つだけ使われることになりました）。

  • Amazonは（非常に皮肉なことに）Google がクエリを選んでいると反論し、同様の TPC-H ベンチマークを実行したところ、ほぼすべてのテストで RedShift が BigQuery を上回りました（彼らは都合よく、月額約２万ドルで動作する８ノードのDC1.8XL を使うことにしました）。

  • 独立したリサーチャーがタクシーデータで同様のテストを行うことにしたところ、BigQuery は RedShift より４３倍速いという結果が出ました（ノードの選択とクエリの種類によって、このリサーチには欠陥があります）。

  • その後、両者のやりとりが始まりました。

  • この時点で、民間企業約５００社が独自のベンチマークを発表し、自社製品のスリングに必要な結果を選び出しています。

これが業界のベンチマークの残念な現状です。クエリをスピンアップしてベンチマークを実行することはできますが、一般化には問題があるでしょうね。また、両方のソリューションがお互いを上回るケースも確かに存在します。スキーマの複雑さ、結合、リソース、テーブルなどはあまりにも多様で、ベンチマークの性能について根拠のある答えを出すことはできないのです。

各プラットフォームの性能のメリット

クライアントとのエクスペリエンスでは、RedShift が日常のビジネスプロセスを処理するのに適しています。つまり、BI ツールやインターフェースのために勤務時間中にノードを回転させるということです。価格も安く、半複雑なスキーマを処理するパワーも十分にあり、使いやすいです。

対する BigQuery は、小さな時間枠で大きな塊をクエリするニッチなビジネスワークロードや、データサイエンティストやML/データマイニングに対応するのに適しています。

多くの場合、両者の差は RedShift のリソースに依存すると思われます。つまり、１つの DC2.large ノードにお金を払っている場合、BigQuery の方が RedShift よりもいい可能性が高いですが、高価な 8ノードのDC1.8XLをスピンアップしている場合は、おそらく RedShift が BigQuery を上回ることになるでしょう。

つまり、性能で選ぶならどちらがいいかとなった時は、細かいところで差が出るということです。

管理性

管理性について話し始めると、またしても事態は複雑になります。RedShift と BigQuery の両方が提供する膨大な機能によって、使いやすさの推定は信じられないほど複雑になるんです。

そこで、管理しやすい４つの重要なレイヤーに焦点を当てていきますが、考慮すべき追加の変数は絶対１００万とかあります。

ここでは、以下をご紹介します：

  1. データ型／更新と削除
  2. 使いやすさ
  3. セキュリティ
  4. 統合

データ型／更新と削除

RedShift は標準SQL のデータ型に対応し、BigQuery は一部の標準SQL のデータ型と狭い範囲の標準外SQL で動作します。BigQuery の最大のメリットは、Dremel 機能によりネストしたデータクラスを「第一級オブジェクト」として扱えることであり、RedShift だと、クエリを実行する前にデータを平坦化する必要があります。

どちらも、クエリに何か問題が発生したときに更新や削除の処理ができます。BigQuery と RedShift は追記型なので、更新や削除ができないと思い込んでいる人が多いようですが、できます。BigQuery では、更新と削除のプロセスは存在しますが、比較的高価であり、選択肢は限られているため、広く使われている機能ではありません。一方 RedShiftでは、Postgre Vacuuming（独自の複雑なホスト有り）でテーブルを再利用できるので、更新と削除のサポートは通常、RedShift の方がいいです。

また、RedShift ではトランザクションのロールバックが可能ですが、BigQueryにはありません。

使いやすさ

すぐに使える状態にある BigQuery は、RedShift よりずっとシンプルです。調整はそこまで必要なく、クラスタ管理も簡単で、複雑なデータベース設定なども BigQuery で処理されます。とはいえ、Integrate.io が簡単に実行できるワークフローや統合でユーザーから RedShift の複雑さを抽象化しているので、RedShiftが使いにくいということはありません。

セキュリティ

セキュリティに関しては、どちらも同じような感じです。RedShift は ID に Amazon IAM を使い、BigQuery は Google Cloud IAM を使っています。両サービスも、ほとんどすべてのビジネスシナリオで完璧に機能します。また、Google には OAuth を使った素晴らしいB2B ID管理があるので、サードパーティをエコシステム全体に導入することなく、ID管理をサードパーティに与えることができます。

統合

Google も Amazonも（当然のことながら）、豊富な統合機能を備えており、ほぼすべての主要な BI およびデータ分析ツールは、両方のウェアハウスで完全にうまく動作します。この項では深入りしないでおきましょう。確かに、RedShift は PostgreSQL のフォークで構築されているので、もともとはより多くのネイティブな統合機能を持っていましたが、Google が処理するウェアハウスのトランザクションの膨大な量のために、競争の場は単純に平準化されました（BI ツールは収益源を逃したくないですからね）。

最終的な感想

BigQuery と RedShift はどちらも、企業が日々のワークフローを再確定するのに役立つ、素晴らしいデータウェアハウスシステムです。違いはいくつかありますが、類似点の方がはるかに多いのです。

おそらく、ほとんどの企業にとって最大の検討材料は価格でしょう。RedShift は、オンデマンドで時間単位という性質上、価格の予測が若干しやすいですが、多くのビジネスシナリオでは、BigQuery のクエリ１TBにつき５ドルの方が都合がいいかもしれません。

価格は重要ですが、それ以外の要素も無視できません。どのシステムがニーズに一番合っているかは、細かい部分が大きな違いを生むのです。どれがベストなのかの判断は難しいものですが、だからこそ私たちは、その判断のお手伝いをする IT サービスを提供しています。

Integrate.ioは、データ管理をサポートします

Integrate.io は、データ管理をお手伝いします。当社のクラウドベースの ETL ソリューションは、どちらのシステムとも統合することができ、どちらのシステムを選んでもニーズに応えられますが、現在お使いのシステムを調べ、どちらを選ぶのがいいのか、両者の主な違いを特定するお手伝いをすることも可能です。

Integrate.io は RedShift および BigQuery と統合し、それによってデータのクリーニング、簡素化、整理がしやすくなります。データウェアハウスとの統合によってビジネスの生産性を上げる方法については、Integrate.io にデモのご予約のご連絡をいただければ、そこで詳細をご確認できます。