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

  • このエントリーをはてなブックマークに追加

最終更新

データウェアハウスサービス 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 は、ビッグデータを物理的にねじふせるやり方と言っていいでしょう。

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

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

この場所には ↓ にある表が自動的にしゅっとまとめられるはずですが、この文章が見えているということは Javascript がうまく動いていないということなので、その場合は教えてもらえるとありがたいです。

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

インスタンスの考え方

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
インスタンスサイズ4種類DW100〜DW6000 12種類× (概念なし)

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 RedshiftAzure SQL Data WarehouseGoogle BigQuery
インスタンス料金/月・東京 (2018/1 調査)0.314USD〜/時間 (≒25,000円〜/月)148,768円〜なし (概念なし)

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

ストレージ料金 について

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
ストレージ料金/月・東京 (2018/4 調査)インスタンス料金に込み17,409円/TB東京: $0.023/GB (≒2,590円/TB)
US/EU: $0.02/GB (≒2,252円/TB)
長期保存で半額

ストレージの金額です。 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円/月となります。

クエリ課金 について

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
クエリ課金 (月・2018/4 調査)なしなし東京: $8.55 / TB
US/EU: $5 / TB

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

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

SELECT col FROM mytable

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

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

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
ストレージリアルタイム連携の料金 (月・2019/4 調査) 5 USD/1TB 無料 (だと思う)

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

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
ストレージ転送料金 (月・2018/1 調査)◯ 無料 (同一リージョン間のみ)△ 有料だが HOT なら無料× 有料

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 RedshiftAzure SQL Data WarehouseGoogle BigQuery
定額制概念なし (不要) 概念なし (不要) あり

チューニング

クラスタリングについて

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
クラスタリング可能可能自動

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 RedshiftAzure SQL Data WarehouseGoogle BigQuery
インデックス (的なもの)× (概念なし)

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

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

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

パーティション について

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
パーティション×○ 値による分割◯ 日付分割テーブル、取り込み時間分割テーブル

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

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
チューニング観点インスタンスタイプ, ノード数, SORTKEY, DISTKEY, 列圧縮方式, 統計情報, VACUUMサービスレベル, インデックス, 分散指定, 統計情報なし

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

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

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

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

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

機能

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
独自関数..Javascript
Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
特殊な型なしなしSTRUCT, ARRAY

更新について

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
更新苦手

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

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

リージョンについて

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
リージョン全リージョン指定可全リージョン指定可US・EU・Tokyo より選択

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 RedshiftAzure SQL Data WarehouseGoogle BigQuery
テーブル名・カラム名の日本語使用×

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 RedshiftAzure SQL Data WarehouseGoogle BigQuery
主キー・一意制約×××

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

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

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

NOT NULL 制約

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
NOT NULL 制約

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

トランザクション

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
トランザクション○ (SERIALIZABLE)○ (READ UNCOMMITTED)

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 RedshiftAzure SQL Data WarehouseGoogle BigQuery
ストレージりあるたいむ連携S3 (Redshift Spectrum)?Cloud Storage, Cloud Bigtable, Google ドライブ (外部データソース機能)

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 なるものを使えばできるのかも?

管理

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
コストクォータ..
Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
メンテナンスウィンドウあり.概念なし
Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
インスタンス課金単位1時間1時間概念なし

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

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
インスタンス停止× (停止不可)概念なし

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

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

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

権限 について

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
権限..IAMではデータセット単位。承認済ビューを使えば行・列単位まで

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

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
スナップショット・バックアップ◯ 最大35日のスナップショットを保持 (8時間経過または 5GB のデータ変更時)◯ 最大7日のスナップショットを保持 (8時間ごと)◯ 7日以内の任意時点の状態を取得可能 (削除テーブルは 2日以内)

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ツール連携

Amazon RedshiftAzure SQL Data WarehouseGoogle BigQuery
Amazon QuickSight
Power BI (Microsoft)
Google Data Studio (Data Portal)
Tableau (タブロー)

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

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

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

メモ

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


  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。

Leave a Reply

*

CAPTCHA