データウェアハウス選定フローチャート（2022年4月時点版）

前置き

最近、色々な会社でデータの活用というのが叫ばれていると思うのですが、いざデータ基盤を構築するとなると詳しい人が少ない状況です。
どういう基盤を作ればいいのかとか、どのデータウェアハウスを使えばいいのかという相談を、私もよく受けます。

ここのところ特にあまりにもよく受けるので、毎回答えるよりも記事にしておいたほうが早いなと思ったので、この記事を書きました。
今回のお話は 「どのデータウェアハウスを使えばいいのか」 という質問に対しての現時点での私なりの回答になります。

データウェアハウスの選択肢は3つ

データウェアハウスのサービスはたくさんあるのですが、この記事を書いている2022年4月時点で自然に選択肢に挙がるのは3つです。

1. BigQuery
2. Redshift
3. Snowflake

それぞれの特徴については後述します。

データウェアハウスの選定基準

今回挙げた3つのデータウェアハウスからどれを選べばいいのかについてアドバイスを求められた時、私は以下の2つを重視して選択するように勧めます。

• 初期の構築のしやすさ
• 費用

逆に以下の点についてはあまり考慮する必要はないと説明します。

• クエリの処理速度などのデータウェアハウスとしての性能
• 機能についての制約

データを活用するというのは実際にやってみないとイメージがつきにくいものなので、まずはデータを貯めて活用するという体験をするのが重要です。なので構築のしやすさは重要です。
導入にあたっての社内での稟議などを考えると、その次に気にしなくてはならないのは費用になるでしょう。

それらと比較すると、実行したクエリの処理に5秒かかるのか10秒かかるのかという違いは大した問題ではありません。
そもそも性能面で致命的な差があったら候補に挙げることはしませんからね。

機能についての制約については考慮する必要がないと言うと語弊があるかもしれません。
ここに挙げた3つのデータウェアハウスは一般的に必要となるような事項が制約によってできないということはほぼないので、比較する必要がないという意味です。

データウェアハウス選定フローチャート

以上を踏まえると、基本的には構築しやすさと費用の観点から選べばいいことになります。
ということは、ある程度機械的に選ぶことができます。

そういうわけで、簡単なフローチャートを用意しました。

このフローチャートを踏まえてそれぞれのサービスについて解説していきます。

各データウェアハウスの特徴と選ぶ理由

BigQuery（費用◎、AWS連携X）

GCPが提供しているデータウェアハウスのサービスです。
データウェアハウスといえばBigQueryだと思っている人も多いと思います。

2020年くらいにデータウェアハウスはどれがいいのかと聞かれたらBigQueryと即答する程度には優れていました。
性能的に優れており、 費用が最も安く済みます。
しかし、最近だと総合的に見て残りの2つも選択肢に挙がる程度には追いついてきた感じです。

実際のところ、BigQueryにデータを転送するパイプラインを構築できるのであればBigQueryを使っていて間違いはありません。

逆に、BigQueryに対して他の2つのデータウェアハウスが優れているのはどちらもAWSを利用したサービスであるという点です。
プロダクトがAWSを使って構築されている場合、BigQueryにデータを転送する部分が構築するのが相対的に非常に大変です。

また、AWSの外部にデータを持ち出す形になるので通信量などが発生します。
権限管理などにおいて、複数のクラウドのしきたりを覚える必要があったりするのもなかなかの手間です。

以上のことから、 プロダクトがAWSに載っていないのであればまずはBigQueryを検討しましょう。 特にGCPに載っているなら迷う必要があまりないでしょう。
AWSに載っているのであれば後述の2つから検討していきましょう。

Redshift（費用X、AWS連携◎）

AWSが提供しているデータウェアハウスです。
他の2つの候補と比較するとRDBに近い仕様になっており、それ故のやりやすさとやりにくさがあります。

Redshiftの最大の利点は AWSの他のサービスとの連携が最もやりやすい ことです。
特にRDSのデータをリアルタイムに近い速度で同期するDMSというサービスが非常に便利で、この機能の需要が高い場合にはRedshiftは非常に有力な候補になります。

Redshiftの最大の欠点は 費用が高い ことです。
細かい見積もりについての説明は省きますが、すごくざっくり言うと BigQueryの2~3倍くらい の料金がかかります。
なので、Redshiftを選ぶ場合には費用が高いことを補うだけの理由が必要になります。それが前述のAWSの他のサービスとの連携のしやすさということになります。

過去にはさらに性能面での無視できない問題などもありましたが、現在はかなり解消されています。Redshiftを選ばない理由は費用の面が大きいと思います。

Snowflake（費用○、AWS連携○）

Snowflakeは近年メジャーになったデータウェアハウスです。
データウェアハウスとしての特性がBigQueryに似ているので使用感はBigQueryに近いです。

snowflakeはサービスの実体を置くクラウドを選ぶことができ、AWSを選べばAWSにあるデータとの連携が非常にやりやすくなります。
費用に関してはBigQueryとRedshiftの中間くらいです。

プロダクトがAWSを使っていて、DMSにそこまで魅力を感じない状況であれば、Snowflakeは最有力の選択肢となります。

プロダクトでAWSを使っていない場合には、現状では費用の面でBigQueryに軍配が上がります。
弊社で試算した限りでは、snowflakeは BigQueryの1.5~2倍くらい の料金がかかります。

ただ、今後の展開次第ではプロダクトでGCPを使っている場合にBigQueryにするかSnowflakeにするかという選択肢がうまれてくるかもしれません。
まだまだ新興のデータウェアハウスといった感じですのでググっても資料が出てきにくかったりしますが、今後はよりメジャーになって実例も増えてくるのではないかと思います。

本日の結論

本日の結論は以下の通りです。

1. プロダクトがAWS以外を使っているのなら BigQuery
2. AWSを使っていてRDSのデータをリアルタイムに参照したい需要があるなら Redshift
3. AWSを使っていてDMSに強い需要がないなら Snowflake

ね、簡単でしょ？

結びの言葉

そういうわけで、本日はチームに詳しい人がいない状況において、データウェアハウスを選定する方法について簡単に説明させていただきました。

私が所属している株式会社GENDAではこれらの基準を元になんやかんやでSnowflakeを採用しました。
今後はSnowflakeの運用に関してのTipsなどの記事も順次出していけると思いますので、導入を検討されている方はご期待ください。

さらに詳細が聞きたいという方は、私がわかる範囲であればお答えしますので、Twitterあたりでお気軽にお声がけください。
@kommy_jp

本日はこのあたりで。
それじゃあ、バイバイ！