クラウドデータウェアハウス比較解説まとめ

最終更新 2020-01-30

データウェアハウスサービス Amazon Redshift・Azure SQL Data Warehouse・Google BigQuery について、様々なポイントから機能や料金の比較をしてみます。

データウェアハウスとは

データウェアハウス (Data Warehouse = DWH) とは「データ倉庫」という意味です。

MySQL・Oracle・PostgreSQL などの一般的な RDBMS と似ていますが、 テラバイト・ペタバイト級の大量データをそこそこの速度で処理するという特徴があります。 「そこそこ」というのは、例えば「1秒では終わらないけど、数十秒〜数分で終わる」というようなレベルです。

用途としては、売上データ・在庫データ・顧客データなど数年単位のデータをデータウェアハウスに格納して分析するというのが一般的です。なお、特定レコードを高速に更新するという用途には向いていないので、ECサイトのデータベースなどには向いていません。

各社クラウドサービスのデータウェアハウスエンジン

Amazon・Microsoft・Google 各社が提供しているデータウェアハウスエンジンは下記のとおりです。

• Amazon Redshift
• Azure SQL Data Warehouse
• Google BigQuery

Amazon Redshift は、オープンソースの RDBMS である PostgreSQL をベースに、データウェアハウスに特化させたもので、 AWS 上で動作するマネージドサービスです。

Azure SQL Data Warehouse は、マイクロソフトの SQL Server をベースにしたデータウェアハウスに特化させたもので、 Azure 上で動作するマネージドサービスです。

Google BigQuery は、Google 社が独自開発したデータウェアハウスで、GCP 上で動作するマネージドサービスです。

Amazon Redshift・Azure SQL Data Warahouse は、いずれも既存 RDBMS にカラム型を取り入れたり、 分散処理させたりといった、「これまでデータウェアハウス業界がオンプレミス上でやってきたことを、クラウドに載せました」という、 いわば正常進化系のサービスです。

一方、Google BigQuery はクラウド的で、「おもしろい」サービスとなっています。

おもしろい点、一つ目。 Amazon と Azure は、

• インスタンスを使うのに 1時間いくら
• インスタンスサイズは何種類かある
• 速いものは当然高い

というよくあるパターンでサービスを展開しています。 コンピュータリソースを専有する代わりにお金を払うということですね。

一方、Google BigQuery はインスタンスという概念がありません。 リソースを専有することはそもそもできず、世界中の BigQuery 利用者全員で共有しています。 専有できないと料金はどうなるかと言うと、BigQuery で発行した SQL に対して「スキャンしたデータ量」で課金することで、 軽い処理はお安く、重い処理はたくさんお金が必要、というふうにしています。

おもしろい点、2つ目。 Amazon と Azure は、チューニングが可能です。 例えば、クラスタ数を 10 にして並行処理させましょうとか、 インデックスのソートキー選択はこうしましょうとか、そういうたぐいのものです。 一方で BigQuery には、このようなチューニングがありません。

なぜならば、BigQuery は「数十台以上のマシンで」「常にフルスキャン」だからです。 Google BigQuery は、ビッグデータを物理的にねじふせるやり方と言っていいでしょう。

データウェアハウス比較表

機能比較表をまとめてみました。 詳細は後述。

比較表はここまでです。以下、詳細解説です。

インスタンスの考え方

Amazon Redshift は、下記のように 4つのインスタンスサイズが用意されています。

• dc2.large VCPU:2、メモリ:15GB、ストレージ:0.16TB(SSD)、価格:0.314USD/時間
• dc2.8xlarge VCPU:32、メモリ:244GB、ストレージ:2.56TB(SSD)、価格:6.095USD/時間
• ds2.xlarge VCPU:4、メモリ:31GB、ストレージ:2TB(HDD)、価格:1.19USD/時間
• ds2.8xlarge VCPU:36、メモリ:244GB、ストレージ:16TB(HDD)、価格:9.52USD/時間

なお、dc2.8xlarge と ds2.8xlarge は最低ノード数が 2 なので、最低料金は上記の 2倍となります。

Azure では、DW100・DW200…DW6000 というラインナップですが、 それぞれの CPU やメモリは明確ではなく、DWU という単位で表されています。 では「DWU って何」となるわけですが、明記されていません。 「試してみたい SQL を実行して、インスタンスサイズを変更して、どれだけ時間がかかるかで最適なサイズを探してくれ」とのことです。

• DW100… DWU 100 (ノード数 1)、203.24円/時間
• DW200… DWU 200 (ノード数 2)、406.48円/時間
• DW300… DWU 300 (ノード数 3)、609.71円/時間
• DW400… DWU 400 (ノード数 4)、812.95円/時間
• (略)
• DW3000… DWU 3000 (ノード数 30)、6,097.06円/時間
• DW6000… DWU 6000 (ノード数 60)、12,194.12円/時間

BigQuery は、前述したとおりインスタンスという概念がありません。 インスタンス的なものを起動するというアクションも存在しません。 クエリを投げたいときに投げる、というだけです。

料金・費用・コスト

インスタンス料金 について

インスタンスの料金は上記のとおりですが、Amazon での月 25,000円以上、 Azure で月 15万円近くというのは高額すぎです。遅くてもよいから、 安価なプランを切望いたします。

ストレージ料金 について

ストレージの金額です。 AWS の場合、ストレージのみの金額というものはないのですが、 2TB を維持するとなると約 95,000円/月かかります。 Azure SQL Data Warehouse は 2TB で 35,000円/月 程度。 Google BigQuery は 2TB で 5,000円/月。 Google BigQuery が圧倒的に安いですね。

Google BigQuery の場合、さらに 90日間更新しなかったテーブルについては ストレージ料金が約半額の $0.016/GB となります。毎月同じ量のデータが蓄積していった結果 1年間で 2TB の容量になったと仮定し、さらに一度作成したデータは更新しなかったとして試算すると、 約 3,200円/月となります。

クエリ課金 について

クエリ課金は Google BigQuery のみに発生します。 AWS・Azure はリソース専有にお金を払っているので、それに対して どのようなクエリを発行しても (あるいは発行しなくても) 定額です。 Google BigQuery はリソースの専有ができず、リソース専有費用もかからない代わりに、 このクエリ課金が行われます。

Google BigQuery の「$6/TB」は「データ処理量 1TB あたり $6」という意味です。 データ処理量とは、

SELECT col FROM mytable

という SQL があるとして、 mytable の col 列が例えば INTEGER であるとすると、データサイズは 8バイト。 それが 1000万レコードあったとすると、この SQL のデータ処理量は 76MB (8バイト×1000万レコード)。 SQL ごとのデータ処理量を積算し、1TB に達するごとに $6 請求ということです。 なお、1TB 未満であれば請求なしというわけではなく、例えばデータ処理量が 76MB の場合、約 0.047円となります。 このような SQL を 100回実行すると、約 4.7円というわけです。

ストレージリアルタイム連携の料金 について

ストレージ転送料金 について

S3 などのストレージに配置したファイルから、DWH にデータを取り込む際の、 ストレージの転送料金についてです。

AWS の場合、S3 と Redshift 間のデータ転送は無料です。 S3 から Redshift にデータをロードしたり、その逆にアンロードで Redshift → S3 と転送する際の転送料金はかかりません S3 へのバックアップも同様です。

Azure の Azure Storage → SQL Data Warehouse では Azure Storage の転送料金がかかりますが、 HOT Storage であればデータ取得料金はもともと無料です (多分)。Cool では有料です (多分)。

GCP の Cloud Storage → BigQuery は、Cloud Storage のネットワーク転送量がかかります。 $0.08/GB 程度ではあるのですが、仮に 1ペタバイトとなると 900万円を超えてしまいます。 これが原因で BigQuery をあきらめて Amazon Redshift を選ぶ人もいるそうです。

定額制

チューニング

クラスタリングについて

Amazon Redshift はノード数を指定できます。 1ノードで動かしてもいいし、10 ノードで動かしてもよいです。 ノードを増やせば分散処理されるので高速になりますが、10ノードならお金は10倍になります。 ノード数の範囲は

• dc2.large は 1〜32ノード
• dc2.8xlarge は 2〜128 ノード
• ds2.large は 1〜32ノード
• ds2.8xlarge は 2〜128 ノード

というふうに決まっており、この中で自由に設定可能です。 dc2.8xlarge と ds2.8xlarge は 1ノードは不可であることに注意が必要です。

Azure SQL Data Warehouse は、DW100〜DW6000 のサービスレベルを選択することでノード数を指定することになります。 例えば DW100 は 1ノード固定であるので、「DW100 を 4 ノード」ということはできません。 4ノードほしければ DW400 以上を使わないといけません。

BigQuery は、BigQuery が勝手にインスタンス数を決定しますので、コントロールはできません。 当ページ管理人の観測結果によると、40 であったり、100 であったり、 検索対象テーブルが 1テーブルのみであれば 1インスタンスのみ使用していたり、であるようですが、 Google はインスタンス数決定の仕様を一切公開していないので、今後も同じであるかはわかりません。

インデックス (的なもの) について

インデックス的なものについて。 Amazon Redshift では、RDBMS で一般的な主キー・インデックスはありません。 代わりに SORTKEY でソート順序を指定したり、DISTKEY で各ノードへの分散方式を指定することができます。

Azure SQL Data Warehouse も同様に、一般的な主キー・インデックスはありません。 代わりにクラスター化列ストア インデックス、クラスター化インデックス、非クラスター化インデックスなどで高速化することができます。

Google BigQuery は、インデックス的なものはありません。 Amazon Redshift の SORTKEY・DISTKEY や、Azure SQL Data Warehouse のインデックスに相当するものもありません。 なぜなら常にフルスキャンだからです。

パーティション について

チューニング観点 について

各 DWH のチューニング観点をまとめました。 BigQuery については、チューニングすべき箇所が全くありません。

当ページ管理人は下記のように思います。

• Amazon Redshift と Azure SQL Data Warehouse 寄りの発言をするならば、これらにはチューニングの余地があり、高速化が望める。エンジニアが付加価値を作り込むことができる、とも言える。
• Google BigQuery 寄りの発言をするならば、BigQuery はシンプルで、難しいことを考える必要がない。 チューニングやメンテナンスの手間を省くことができる、とも言える。

なお、いずれのサービスにも、下記のような基本的な高速化は可能です。

• テーブル構成を見直す
• SQL を見直す

機能

更新について

Amazon Redshift・Azure SQL Data Warehouse・Google BigQuery いずれも、UPDATE での更新や DELETE でのレコード削除が可能です (当初は BigQuery は更新不可だったが、2016/11 より更新に対応)。

ただ、BigQuery の場合、INSERT や DELETE は 1テーブルあたり最大1000回/日 といった若干厳しい制限があります。 これは、BigQuery においては一度格納したデータは分散配置されており、 更新には Google 側のリソースをそれなりに使うためと思われます。

リージョンについて

Amazon Redshift も Azure SQL Data Warehouse も、インスタンスを作成する際、 どのリージョンに作成するか決める必要があります。2018/4 に確認したところ、 Amazon Redshift・Azure SQL Data Warehouse いずれも、全リージョンで作成可能のようです。

Google BigQuery は、これまで US・EU・Tokyo という 3つの地域から選択することができます。 これ以外のリージョンには BigQuery サービスがないので、いずれかを選ぶ必要があります。 なお、2018/4 に Tokyo が追加になりましたが、ストレージコストは US/EU の約1.2倍、 クエリコストは 1.7倍という結構なお値段です。

テーブル名・カラム名の日本語使用 について

Amazon Redshift と Azure SQL Data Warehouse は、テーブル名・カラム名にマルチバイト文字が使えます (つまり日本語が使える)。 一方、Google BigQuery は英数字記号のみです。 新しくスキーマを設計するならなら英数字にすればよいのでしょうが、 すでに既存データがあり、例えば商品コード・商品管理コード・商品集約コード・商品分類コード・商品店舗コードといった似て非なるカラム名がたくさんある場合、日本語が使えるかどうかでわかりやすさや既存 SQL 修正工数が大幅に変わってきます。

下記は株式会社ゲオホールディングスの Azure SQL Data Warehouse の事例紹介ですが、日本語対応が重要であったことがわかります。 Azure SQL Data Warehouse を活用し、ビッグ データを全社活用 – 株式会社ゲオホールディングス – マイクロソフト導入事例 – Microsoft for Business

なお、上記ページには Redshift がマルチバイト文字非対応とありますが、2016/11 に Redshift はマルチバイト文字に対応しました。

主キー・一意制約

Amazon Redshift・Azure SQL Data Warehouse・Google BigQuery いずれも、 主キー (プライマリキー)・一意制約 (ユニークキー) は使えません。

Redshift では主キーや一意制約を設定することはできますが、重複データは格納できてしまいます。 ただしクエリプランナは主キーなどを認識した上で、実行計画作成時の参考にするようです。

重複データがあると困るというケースは世の中には多々あります。 特に接続不可の際はデータ再送などとしていると容易にデータは重複します。 世の中の皆様は、一時テーブルを使って DISTINCT や DELETE で重複行を除外したり、 副問合せで、格納対象テーブルに入っていないレコードのみを INSERT したり、苦労しておられるようです。

NOT NULL 制約

Amazon Redshift・Azure SQL Data Warehouse・Google BigQuery いずれも、NOT NULL 制約は設定可能で、 NOT NULL 制約を設定したカラムに NULL を入れようとするとエラーになります。

トランザクション

Amazon Redshift はトランザクションをサポートしています。 ただし分離レベルは SERIALIZABLE (直列化可能) のみです。

Azure SQL Data Warehouse もトランザクションをサポートしています。 ただし分離レベルは READ UNCOMMITTED (確定していないデータまで読み取る) のみです。

参考: トランザクション分離レベル – Wikipedia

Google BigQuery は、トランザクションはあるにはあるのですが、 1回の操作限定のトランザクションです。 つまり、データロードや更新などのある操作について、成功するか失敗してロールバックするかのいずれかであることは保証されています。 中途半端な状態にはなりません。 ただし、Amazon Redshift や Azure SQL Data Warehouse のように、 BEGIN でトランザクションを開始し、複数回 SQL を発行し、COMMIT する、といった RDMBS で一般的なトランザクションは BigQuery では使うことができません。

ストレージ

ストレージ リアルタイム連携について

Amazon Redshift は、S3 に置いたファイルに対してリアルタイムにクエリを投げることができます。これは「Amazon Redshift Spectrum」というサービス名になっています。

イメージとしては、S3 にファイルを配置し、

create external table mytable (
   col1 integer,
   col2 smallint,
   col3 timestamp
)
fields terminated by '\t'
stored as textfile location 's3://[バケット名]/mytable/' 

という DDL を発行してテーブルスキーマと S3 配置場所を指定しておけば、 それ以降は普通のテーブルとして SELECT できる、という感じです。これは、S3 にあるデータを Redshift にロードするのではなく、クエリが発行されるたびに Redshift が都度 S3 からデータを取得する形です。

Redshift 内に置いておくにはデータサイズが大きすぎるとか、 現在のインスタンスではデータ容量がいっぱいだが 金額的にこれ以上インスタンスサイズやクラスタ数を上げるのは避けたい、というときに使うとよいでしょう。 Redshift Spectrum の対応フォーマットは下記です。

• CSV
• TSV
• Parquet
• Sequence
• RCFile

Google BigQuery でも、Cloud Storage や Google BigTable、さらには Google ドライブに配置されているデータに対してクエリを実行することができます。Amazon Redshift Spectrum と同様に、事前にスキーマ定義を作成しておくやり方です。 対応フォーマットは下記のとおりです。

• CSV
• JSON (改行区切り)
• Avro ファイル
• Google スプレッドシート (最初のタブのみ)

Azure SQL Data Warehouse で同じようなことができるかはわかりませんでした。 PolyBase なるものを使えばできるのかも?

管理

Google BigQuery にクエリを投げるほどお金がかかるサービスです。意図せぬ高額請求を防ぐため、コストクォータ (料金上限) の仕組みがあります。具体的には下記3つがあります。

• プロジェクト単位での上限設定
• アカウント単位での上限設定
• SQL 発行時の上限設定

Amazon Redshift・ Azure SQL Data Warehouse にはこのような仕組みはありませんが、そもそもクエリを投げると課金されるという仕組みではないので問題ないでしょう。

インスタンス停止について

Amazon Redshift は、インスタンスを停止できません。それはつまり、インスタンスを停止してお金を節約、という方法が取れないということです。 使わないときはスナップショットを取得し、インスタンスを削除するしかありません。 再開したいときはスナップショットから起動するのですが、データ量が多いと起動だけで数時間かかったりします。 それなりのデータ量だと、夜間や土日は誰も使わないのに起動しっぱなしで無駄なお金がかかるというケースもあります。

Azure SQL Data Warehouse は、インスタンスの停止が可能です。 停止中はインスタンスの費用がゼロとなりますが、ストレージ料金はかかります。

Google BigQuery には、インスタンス起動や停止という概念がありません。 BigQuery を使っていないときにかかるのは、ストレージ料金のみです。

権限 について

スナップショット・バックアップについて

Amazon Redshift では、8時間経過または 5GB のデータ更新が行われたときに、 スナップショットが作成されます。スナップショットは S3 に保持され、 デフォルトで 1日、設定変更で最大 35日保持できます。 S3 の費用はかかりますが、スナップショットは前回との差分であるため、まるごとダンプするほどのサイズにはなりません。 スナップショッからクラスタを復元したり、特定テーブルのみ復元することができますが、 任意時点のデータの復元はできません。 あくまでスナップショット取得時点での復元のみが可能です。

Google BigQuery では、データ更新が自動的に記録されます。 下記のように “@ミリ数” というテーブルデコレータという機能を使うことで、任意時点のデータを取り出すことができます。

#legacySQL
-- 1時間前の mytable を取得
SELECT * FROM [myprojectid:mydataset:mytable@-3600000] 

コマンドラインからであれば bq query にて別テーブルにコピーできます。

% bq query --destination_table=myproject:mydataset.mytable_snapshot \
  'SELECT * FROM [myproject:mydataset.mytable@-3600000]'

bq cp でも可能です。

% bq cp myproject:mydataset.mytable@-3600000 myproject:mydataset.mytable_snapshot

最大 7日前までの任意時点のデータを取得できるので、5分前でも、1時間前でも、1日前でも可能です。 ただし削除したテーブルからの取得は 2日前までとなります。 追加費用は不要です。 リストアはテーブル単位のみで、全データセットや全テーブルをまるごと復旧ということはできません。

BIツール連携

上記は、主要な BI ツールが、各データウェアハウスへの接続をサポートしているかを表した表です。

BIツールとは、ビジネスインテリジェンスツールの略で、「売上などのデータを グラフや表形式で簡単に見られるようにしよう」というツールです。経営管理や意思決定の迅速化のために、などと大げさなことを言ってますが、グラフや表のツールです。 例えば以下のような画面を作ることができます。

上記では 4種類だけあげましたが、このような画面を表示するための BI ツールはたくさんの種類があります。多分 100種類は軽く超えるような気がしますので、比較検討してみてください。

関連コンテンツ

BigQuery FAQ もぜひ読んでください。

メモ

下記要追記。
Redshift の concurrency scaling と、resize。リザーブドインスタンス。同時実行スケーリング。
鍵管理。SQL詳細 (DML・型・VIEW・FUNCTION等)
BigQuery Transfer
BigQuery Scheduled Query