AWSとAzureにおけるデータウェアハウスに対するサービスへのアプローチの違いを考える

ビッグデータというバズワードを聞いて久しいですが、各ベンダそれぞれがビッグデータのコンポーネントとして、クラウドDWH(データウェアハウス)のサービスを提供しています。
クラウドベースのDWHはスケーラビリティにも優れ、オンデマンドで調達ができる便利なサービスです。

ここでは、AWSのRedshiftとAzureのSQL Data Warehouseを比較してみようと思います。
まだまだ、私も勉強を進めている所ですので、忌憚の無いご意見をお待ちしています。

AWSにおけるデータウェアハウス Redshift

Amazon Redshiftについては、公式ドキュメントのデータウェアハウスシステムのアーキテクチャを読むのが一番とは思います、ペタバイトクラスまで展開できるスケーラビリティを実現する仕組みがしっかりと解説されています。
クラスタには、リーダーノードと呼ばれるDBへの実行計画などを管理するものがあります。
また、その配下にはCompute Nodeが1・・・n台まで展開され、Compute Nodeにはノードスライスという単位で分散されたデータが接続されたディスクに保存されている事がわかります。
いわゆる大量並列処理 (MPP) アーキティクチャと呼ばれているクラスタになります。

メリット

  • ds2.8xlarge 101台 (コントロールノード1台、データノード100台)で、1.6PBまでスケールアウト可能
  • PostgreSQLによく似たクエリ体系

デメリット

  • 停止できないので、削除する事で停止
  • 削除後S3にあるバックアップ(スナップショット)を戻す事で復元
  • スケールアウトには時間がかかる
  • VACUUMによるメンテナンス
  • PostgreSQL完全互換では無い
  • ノート単位課金(ストレージとコンピュート一式で課金)
  • SLAが無い

少し古い情報ではありますが、re:Invent 2014で行われていた、このRedshiftの話によると展開などの時間は以下の通りです。

capture20160326215153430.png

609TBの展開(100ノード展開時) 101ノード 8XL クラスタ

  • スナップショット取得完了時間 30分
  • リストア時間 完了まで48時間
  • リサイズ時間 完了まで 48時間 (48ノードから100ノードにリサイズした場合)
  • VACUUMメンテナンス完了まで 30分 (100ノード時)

リストア完了時間とリサイズ時間から察する限り、おそらくリサイズは新しいクラスタを作ってデーターを再投入、再度分散を行っているのかな?と思います。

Redshiftがノード単位でストレージを持っているので、台数を増やし再分散する場合、とてもコストのかかる処理となります。

運用面で考えると、Redshiftは一時停止が無いので、一度削除して、必要な時にレストアって事になるのですが、台数に比例して時間がかかるので、正直止めないで運用を続けたいって思います。

Azureにおけるデータウェアハウス SQL Dataware House

SQL Dataware Houseについては、公式ドキュメントのAzure SQL Data Warehouse の概要を読むのが一番です、ペタバイトクラスまで展開できるスケーラビリティを実現する仕組みがしっかりと解説されています。また、井上大輔さんが纏めてくれた、SQL Data Warehouseの資料が参考になるでしょう。

dwarchitecture.png
クラスタには、コントロールノードと呼ばれるDBへの実行計画などを管理するものがあり、その配下にはコンピュートノードがいます、そのコンピュートノードはAzure Storage Blobに接続されています。

こちらも、Redshift同様の大量並列処理 (MPP) アーキティクチャと呼ばれているクラスタですが、ストレージ部分はAzure Storage Blobを利用しています、分散計算+分散ストレージと分離されています。

分離されているので計算とストレージは各々調整ができます、容量は多いけど・パフォーマンスは悪くても良い、容量は少ないけども兎角パフォーマンスが欲しいなどバランスが調整できます。

すべてのノードには、インメモリでDMS(Data Movement Service)という機能が存在し、相互ノード間のデータ移動に使われています。Redshiftはスケールアウト時に48時間かかっていましたが、瞬時にスケールアウトできるのは、DMSがあり、Compute側にストレージを保持させていないからと考えられます。

メリット

  • SQL ServerのT-SQLサポート
  • 数秒でスケールアウト、スケールインできるので
  • 一時停止、再開が可能
  • SQL Server互換なので、BCPなどでもインポートできる
  • 8時間毎に自動スナップショットバックアップ、過去7日間のデータを保持
  • ストレージはAzure Storageなので、東日本、西日本に合計6つの冗長バックアップがある
  • スナップショットからのリストア、PITR(時間指定でその時点まで復元)をサポート
  • 非構造化データに対して、Polybaseが使える
  • Azure Storageなので容量制限がほぼ無い(クォータ解除申請が必要とは思う)

デメリット

  • DWUっていう単位がイマイチわかりにくい
  • 現在はプレビュー中なのでSLAが無い(GAするとSLAあります)
  • 最大テーブル数が32,768個(まもなく制限撤廃予定)
  • 1TB未満では逆に分散がオーバヘッドになり、速度面で弱点がある。(1TB未満はSQL Databaseで対応)

数秒でスケールアウト、スケールインができる事、バックアップ周りが充実している事、一時停止、再開ができる事など充実しています。例えば、夜間バッチではCompute増やすなどもその場でできるので、Azure Schedulerを使って時間指定でスクリプト流してスケールアウトなどできそうです。

データのインポートならPolybaseが便利

SQL Data Warehouse で PolyBase によってデータを読み込むを読んでもらうとわかるのですが、データのインポートの方法の一種です。Azure Storage Blobに、以下のようなカンマ区切りテキストがあるとします。

20150301,1,3
20150501,2,4
20151001,4,2
…

スクリプトが長いので、一部割愛して要所だけ記載しますがAzure Storageの/datedimension/というコンテナ配下にある、カンマ区切りテキストを外部テーブルとして読み込み、外部テーブルに最後クエリをしています。

CREATE EXTERNAL TABLE dbo.DimDate2External (
    DateId INT NOT NULL,
    CalendarQuarter TINYINT NOT NULL,
    FiscalQuarter TINYINT NOT NULL
)
WITH (
    LOCATION='/datedimension/',
    DATA_SOURCE=AzureStorage,
    FILE_FORMAT=TextFile
);

-- CSVの外部テーブルにクエリ
SELECT count(*) FROM dbo.DimDate2External;

どれほどの速度なのかは、計算ノード次第と思いますが、ストレージにテキストファイルさえ設置すれば良く、DWHへのテキストデータのインポート作業がとても楽になります。

DWHに投入するための処理プログラムをわざわざ書かずに済むので、工数削減になるかなと思います。

僕の視点から考えるクラウドDWH

どちらも便利なクラウドDWHであり、各ベンダの方向性の違いなどが見えます。
いずれのDWHサービスも、今までこんなにも手軽にDWHを展開できる事が無かったのですから、クラウドDWHの存在意義は高いと思っていますし、解析を行う事で新しい視座が見えてくる事をそもそもビッグデータと呼んでいたのです。

大きなデータを持っている、もしくは今後大きくなるデータを作る予定があれば、是非各DWHサービスの利用を検討してみてください。