正しいデータウェアハウスを選択することは、みなさんの一般的なデータおよび分析ビジネスにおいて求められる重要なポイントです。企業や組織がデータウェアハウス・プロバイダーを選択する際の最大の問題の1つは、 Snowflake、Amazon、Googleのうち、どのデータウェアハウスを使用すべきか？ということです。

すでにAmazon Redshift vs SnowflakeとGoogle BigQuery vs Snowflakeについて説明しましたが、Amazon Redshift vs Google BigQueryについてはどうでしょうか？

AmazonもGoogleも、RedshiftとBigQueryといった素晴らしいデータウェアハウスを持っています。これらのソリューションはそれぞれ、アナリティクスを大規模かつ迅速に実行することができます。ここでは全く別のソリューション同士を比較しているのではありません。これは同じカテゴリつまりデータウェアハウス同士の比較です。しかし、それぞれが得意とする実際のユースケースがあり、どちらのソリューションもビジネスのニーズに応じて価値あるものになります。

Integrate.ioでは、両方のソリューションをサポートしています。そこで、今回の記事では、自社のワークフローやプロジェクトに最適なデータウェアハウスを選択したいと考えている企業や組織のためにガイドを紹介します。

Table of Contents:

Data Warehouseについて

データウェアハウス（カラム型ストレージソリューションと呼ばれることもあります）は、分析処理のためにBIデータをすべて放り込むことができる集積所です。RedshiftもBigQueryもデータウェアハウスです。ブレンドされた技術スタックからすべてのデータを投入して、その上でアナリティクスを実行することで、重要なビジネス上の意思決定、トレンドの予測、予算計画などに役立てることができます。

典型的なデータウェアハウスの使用例は、トレンド分析です。企業は、分析ワークロードを実行するために、すべてのデータ（カスタマーサービス、マーケティング、販売、人事など）をウェアハウスにプッシュします。

例えば、ある企業では、見込み客についてもっと知りたいと考えているかもしれません。これは、顧客をよりよく理解し、セールスピッチやコンテンツ配信をパーソナライズするのに役立ちます。これを行うには、Salesforceデータをデータウェアハウスに接続し、クエリを実行して、どの見込み客が最も価値があり、どの見込み客が最も離脱しやすいかを見つけ出します。

カラム型ストレージの他に、RedshiftやBigQueryのようなデータウェアハウスには、Massively Parallel Processing (MPP)が特徴として挙げられます。MPPでは、それぞれが独自のメモリとオペレーティングシステムを持つ複数のプロセッサが、クエリの特定のセグメントを処理することになります。

データウェアハウスが分析ワークロードにとって価値のあるものである理由を本当に理解するためには、オンライントランザクション処理（OLTP）とオンライン分析処理（OLAP）のデータ処理システムの違いを理解する必要があります。

データ処理システムについて

OLTPとOLAPデータ処理システムの違いについて簡単に説明しましょう。

OLTP（またはオンライン・トランザクション・プロセッシング）は、ほとんどのビジネスが日々の業務でトランザクションを処理するために使用しているものです（ATM、小売店の販売システム、テキスト・メッセージングなどを考えてみてください）。

OLTPの第一の目的はデータ処理です。OLTPは、複数のシーケンスにわたってデータの整合性を維持する高速処理を得意としています。

例えば、二人の人が同じオンライン銀行口座から正確に同じ瞬間にお金を引き出したとします。OLTPは、最初に許可されたユーザーを取得し、そのトランザクションを処理します。そして、どちらのユーザーも銀行口座にある金額以上のお金を引き出すことができないようにします - たとえ二人が同時に操作を開始したとしても。これを行うために、OLTPはクエリの各行に対してチェックを実行します。  ACID (Atomicity, Consistency, Isolation, Durability) トランザクションを実行するこの機能は、エラーや停止時のデータの妥当性を確保するためにOLTPが非常に有用であることを意味しています。

OLAP（Online Analytic Processing）は、データウェアハウスがクエリを実行するために使用するものです。 OLAPは各カラムをオブジェクトとして保存します。 だから、それは大規模なデータセットから傾向を見つけるための検索に最適です。さらに、OLAPは集計が必要なデータを見つけるのに関係のないデータをスキップすることができます。

例えば、OLTPデータベース上でクエリ(例えば、Wikipediaの全てのリビジョンを見つけること)を実行したいとします。そのOLTPデータベースは、そのプロセスを実行するために、すべての行のすべてのフィールドにアクセスしなければなりません。しかし、OLAPではカラムを利用して必要なフィールドだけにアクセスすることができるので、膨大な演算処理にかかるコストと時間を節約することができます。

実際、OLAPは分析処理で非常に速く、データウェアハウスを利用している大多数の企業で10秒以下の速度（すなわち10秒以下）を求めています。

OLTPの詳細については、こちらをクリックしてください。
OLAPの詳細については、こちらをクリックしてください。

Redshiftについて

RedshiftはAmazonのデータウェアハウスであり、Amazonの巨大なクラウドアーキテクチャであるAWSの一部です。

カラム型データ構成を利用したPostgreベースのデータベースParAccel Analytic Databaseを開発したParAccel社から、AmazonはRedshiftのソースコードを取得しました。つまり、RedshiftはPostgreSQL上に構築されたMPPデータウェアハウスというわけです。RedshiftはPostgreと多くの共通点（リレーショナルな性質など）を共有していますが、カラム型であること、インデックスをサポートしていないこと、データ編成に分散スタイルとキーを使用していることなど、ユニークな点もあります。また、AmazonはRedshift用にPostgreとは異なる独自のクエリ実行エンジンを搭載しています。

RedshiftがPostgre上に構築されていることで注目すべき重要なことは、RedshiftがそのトランザクションDBとしての性質の一部を保持しているということです。つまり一種のハイブリッドデータベースになっているということです。Redshiftはトランザクションをロールバックすることができますが、これはデータウェアハウス市場においてある意味ユニークな機能です。

BigQueryについて

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

BigQueryは、C-Store、Monet DBに続く、市場に出回った最初のメジャーなデータウェアハウスの1つです。BigQueryは、Dremel（Googleが開発した、SQLに似た構文をサポートする読み取り専用のネストされたデータのためのクエリエンジン）をRESTインターフェース上で実行します。

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 の内部データネットワーク）は、Colossus システム上のデータを翻訳し、Dremelジョブのデータ読み取りをサポートします。

価格: Redshift vs. BigQuery

RedShift

Redshiftの価格モデルは非常にシンプルです。この比較のために、Redshift Spectrum*の価格については触れませんが、詳細はこちらをご覧ください。

*Redshift Spectrumでは、Amazon S3ストレージに対してRedshiftのクエリを直接実行することができます。

Redshiftでは、Dense Computeか大規模なDense Storageのどちらかを選択することができます。利用できる最も安いノードは1時間あたり0.25ドルで、dc2.largeノードで160GBです。Dense Storageは1時間単位、1TBあたり0.425ドルで動作します。この費用はストレージと処理の両方をカバーしています。Redshift だから、Redshiftの最安値は1TBあたり306ドルです。しかも、前払いで大幅な割引を受けることができます。

これによりRedShiftでの作業は魅力的になります。ランタイムと各ノードの利用に必要な頻度を計算できれば、コストを大幅に削減できます。ほとんどのビジネスでは、Redshiftノードを常に実行しているわけではないので、通常は細かく管理することが最善の策になります。

例えば、人々がスタックやサービスとやり取りし作業している日中だけRedshiftを動かすかもしれません。そのような場合は、購入前に調整し、企業の特性を反映させることができます。

BigQuery

BigQueryの価格設定はもっと複雑です。表面上はBigQueryの方が安く見えます。ストレージは1TBあたり月額20ドルで、Redshiftよりも286ドルも安いです。しかし、BigQueryはストレージとクエリの料金を別々に請求します。クエリーは5ドル/TBです。つまり、ストレージの方が安い反面、クエリのコストはすぐに加算されてしまうのです。

この方法には賛否両論あります。BigQueryは特定のタイプの顧客に最適です。例えば、あなたのビジネスでは波のあるワークロードを扱っているとしましょう。1日に数回、急ぎのクエリを実行します。Redshiftは時間単位での支払いなので、BigQueryの方がはるかに良い選択肢になるでしょう。また、非常に大規模かつ波のあるワークロードを扱っているのであれば、BigQueryはMLやデータマイニングを実行しているデータサイエンティストにとっても最適なソリューションかもしれません。

勝者は?

BigQueryは、ストレージコストが1TBあたり月20ドル、クエリのコストが1TBあたり5ドルです。

RedShiftは、ストレージかつそのストレージでの無制限のクエリに対して、1TBあたり月額306ドルかかります。

どちらが勝者かということに意味はありません。なぜなら、ほとんどのビジネスで日常的なデータウェアハウス運用を行う場合は、RedShiftの方が経済的です。しかし、データマイニングを行うビジネスや、非常に多様なワークロードを扱うビジネスでは、BigQueryの方が適しています。

いくつかの例を見てみましょう。

例1. 1日のうちクエリを実行するのは5%程度だとします。この場合、オンデマンドでクエリ処理を行うため、BigQueryの方が費用対効果は高いでしょう。処理されるデータ量が5ドル/TBですが、1日に100GBのチャンクを3回処理するだけの場合があります。これには$1.50とストレージ代$0.70がかかります。これは、主にデータウェアハウスを使用してデータマイニングを行うビジネスでよく見られることです。また、1日に数回のジョブを実行しているデータサイエンティストにとっても、BigQueryは費用対効果の見合うものとなります。

例2. セールスやマーケティングのスタックを支援するために、日々利用するウェアハウスを必要としているとしましょう。この場合、一定のランタイムと、1日に何百、何千回ものクエリを実行する能力が必要です。Redshiftは、これらのクエリ単位で課金されることはないので、おそらく安価になるでしょう。例えば、何百ものクエリが50GBを処理するとします。BigQueryでは5ドル/TBを支払うことになり、コストはどんどん膨らんでいきます。Redshiftでは、ノードの使用時間に応じて課金されます。

詳しくは、BigQueryの価格ページとRedshiftの価格ページをチェックしてみてください。

パフォーマンス: Redshift vs. BigQuery

RedshiftとBigQueryの比較となると、パフォーマンスは厄介です。BigQueryは、処理するデータ量に基づいて価格を抽象化しているだけなので、クエリを実行する際に特定のリソースにロックされることはありません。一方、Redshiftは、実行しているノードによって制限されます。しかし、クエリのパフォーマンスに影響するのはそれだけではありません。

実行しているデータテーブルのサイズ、スキーマの複雑さ、同時に実行するクエリの数（両方とも最大で50個）も大きな違いをもたらします。この2つを比較したベンチマークは、長年にわたって数多く存在しています。しかし、それらのベンチマークはどれも広い意味では特に役に立つものではありません。

BigQueryとAmazonの間で行われているベンチマーク戦争がどれほど無意味なものかを知るために、ここではドラマの一部を紹介しよう。

  • Googleは2016年にサンフランシスコで開催されたCloudAirで、BigQueryがAmazonを上回るパフォーマンスを示したTPC-Hベンチマークを発表した（彼らは26のパフォーマンス指標をすべて使用するのではなく、1つの指標のみを使用することにしました）。
  • Amazonは（非常に皮肉を込めて）Googleが自分たちに都合の良いクエリをピックアップしていると主張して反論し、同様のTPC-Hベンチマークを実行し、ほぼすべてのテストでRedshiftがBigQueryを上回ったことを発表しました（彼らは都合よく月20kドル程度で動作する8ノードのDC1.8XLを使用することにしました）。
  • 独立した研究機関がタクシーデータで同様のテストを実施したところ、BigQueryの方がRedshiftよりも43倍高速であることがわかりました（この研究には、ノードの選択とクエリタイプに問題がありました）。
  • その後、両者の間でさらなるやりとりが行われました。
  • この時点で、約500社の民間企業が独自のベンチマークを公開しており、それぞれの製品を売るために結果を都合良くピックアップしています。

これが業界ベンチマークの残念な現状です。クエリを実行してベンチマークを実行することはできますが、一般化可能性の問題を伴います。また、両方のソリューションがお互いを上回るケースも確かにあるかと思います。スキーマ構造、結合処理、リソース、テーブルなどの複雑度は多様すぎて、ベンチマークのパフォーマンスについて根拠のある答えを出すことはできません。

そこで、それぞれが本当に得意とすることについて話をしてみましょう。

私たちのクライアントとの経験では、Redshiftは日常的なビジネスプロセスの処理に優れています。これはBIツールやインターフェイスのために業務時間中はノードを稼働する場合においてという意味です。Redshiftはコストが安く、半複雑なスキーマを扱うのに十分なパワーを持っていて、使いやすい製品です。

BigQueryは、細かい時間枠で大きなチャンクをクエリするニッチなビジネス・ワークロードの処理や、データ・サイエンティストやML/データ・マイニングに最適です。

多くの場合、この2つの製品の違いはRedshiftのリソースに依存することになります。もし、1つのdc2.largeノードにお金を払っている場合、パフォーマンスにおいてBigQueryの方がRedshiftを上回る可能性が高くなります。しかし、高価な8ノードのDC1.8XLの場合は、おそらくRedshiftがBigQueryを上回るパフォーマンスを発揮するでしょう。

悪魔は細部に宿ります。

管理機能: Redshift vs. BigQuery

管理機能面の話を始めると、話は再び複雑になります。RedshiftとBigQueryの両方で提供されている膨大な機能は、使いやすさに関する評価を非常に複雑なものにしています。

ここでは、管理機能面の4つの重要なレイヤーに焦点を当てることにします。しかし、追加で考慮しなければならない変数も確かにあります。

このブログでは、以下の項目を取り上げます。

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

データタイプ/Updates と Deletes

Redshiftは標準SQLデータ型をサポートしており、BigQueryはいくつかの標準SQLデータ型と小さな範囲の標準以下のSQLで動作します。BigQueryの最大の利点の1つは、Dremelの機能により、ネストされたデータクラスを普通のデータ型として扱うことです。Redshiftでは、クエリを実行する前にデータをフラットにする必要があります。

どちらも、クエリで何か問題が発生したときに更新や削除を行うことができます。BigQueryとRedshiftはAppend Onlyなので、多くの人は更新や削除ができないと思い込んでいます。しかし、可能です。BigQueryでは、更新と削除のプロセスは存在しますが、比較的コストが高く、オプションも限られています。そのため、広く使われている機能ではありません。Redshiftでは、PostgreのVACUUMを（独自のの複雑なホストを持つ）使ってテーブルを再利用することができるので、更新と削除のサポートは一般的に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はPostgresベースで構築されており、元々は多くのネイティブ統合機能を持っていましたが、Googleで処理するウェアハウストランザクションが膨大な量に及ぶため、競争は平準化されています。

最後に

BigQueryもRedshiftも、ビジネスの日々のワークフローを再定義するのに役立つ、驚くべきデータウェアハウスシステムです。いくつかの違いはありますが、類似点の方がはるかに多いです。おそらく、ほとんどの企業や組織において最も大きな懸念事項は価格です。Redshiftはオンデマンドで時間単位コストのため、価格を予測するのは簡単です。しかし、多くのビジネスシナリオにおいては、BigQueryの5ドル/TBのクエリコストの方が理にかなっているのかもしれません。

Google BigQueryを使うにしろ、Amazon Redshiftを使うにしろ、Integrate.ioはクラウドベースのETLソリューションで、様々なビジネスデータを両データウェアハウスに統合することができます。データをクリーンにし、シンプルにし、整理するツールが必要な場合は、ページ右上のボタンからオンライン相談/無償トライアルをお申し込みください 。

（本ブログは、2019年7月に投稿された記事を翻訳したものです。）