夜間バッチが朝までに終わりません。分析の同時実行が増えると、本番の処理まで遅くなります。容量を増やすには深夜にシステムを止めてサーバーを足すしかなく、見積もりと調達に何週間もかかります。オンプレミスや従来型のデータウェアハウス（DWH）を運用していると、こうした壁に何度もぶつかります。データ量と分析ニーズが増えるほど、基盤が足かせになっていきます。
クラウドデータウェアハウスは、この壁を「ストレージ（保管）とコンピュート（計算）の分離」という発想で解きました。両者を切り離し、それぞれ独立に増減できるようにしたのです。これにより、必要なときだけ計算力を足し、終わったら止める、という使い方ができます。まず、従来型と何が違うのかを押さえてください。
| 従来型DWH（オンプレ等） | クラウドDWH | |
|---|---|---|
| 保管と計算 | 一体（同じサーバー） | 分離（別々に増減） |
| 増強 | サーバー調達・停止が必要 | 設定変更で即時 |
| 同時実行 | 互いに干渉して遅くなる | 計算資源を分けて干渉を避ける |
| 課金 | 固定（持っているだけで費用） | 従量（使った分）が基本 |
| 運用 | 自前でハード・チューニング | 多くをサービス側が肩代わり |
なぜストレージとコンピュートの分離が効くのか
従来型では、データを置く場所と計算する場所が同じサーバーにありました。だから計算力を増やしたいだけでも、ストレージごとサーバーを増設するしかなく、無駄が出ます。さらに、重い分析が走ると、同じサーバーを使う他の処理まで遅くなります。
クラウドDWHは、データを安価なクラウドストレージに1か所で持ち、計算はそのつど必要な分だけ立ち上げます。分析チームごとに別の計算資源を割り当てれば、互いに干渉しません。重いバッチと、軽いダッシュボード参照を、別々の計算力でさばけます。使い終われば計算を止め、課金も止まります。この「分けて、必要な分だけ」が、クラウドDWHの最大の利点です。
| 用途別の計算資源 | 担当する処理 | 参照するデータ |
|---|---|---|
| 計算資源A | 夜間バッチ | 共有ストレージ（データは1か所） |
| 計算資源B | BIダッシュボードの参照 | |
| 計算資源C | データ分析・機械学習 |
同じデータを共有しながら、用途ごとに計算資源を分ける。これがクラウドDWHの基本構造です。
主要3つの早見表
クラウドDWHの代表格が、Snowflake・Google BigQuery・Databricksの3つです。いずれもストレージとコンピュートを分離していますが、成り立ちと得意分野が違います。
| Snowflake | BigQuery | Databricks | |
|---|---|---|---|
| 成り立ち | クラウド専用DWH | サーバーレスDWH（Google） | Spark発のレイクハウス |
| 計算の考え方 | 仮想ウェアハウスを起動 | サーバー管理なし・自動 | クラスタ／SQLウェアハウス |
| 課金の軸 | 使った計算時間（クレジット） | スキャンしたデータ量 or 定額枠 | 使った計算量（DBU） |
| 得意 | SQL分析・データ共有 | サーバーレス・GCP連携 | 大規模処理・機械学習 |
それぞれの詳しい仕組みと使いどころは、Snowflakeとは、BigQueryとは、Databricksとはでくわしく解説します。
どう選ぶか：判断の軸
3つとも優れた選択肢です。だからこそ「どれが最強か」ではなく、「自社の状況にどれが合うか」で選びます。次の軸で当たりをつけてください。
| 状況 | 相性のよい選択 |
|---|---|
| すでにGoogle Cloudを使っている | BigQuery（連携が滑らか） |
| SQL中心の分析・データ共有が主 | Snowflake |
| 機械学習・大規模データ処理が主 | Databricks |
| 運用の手間を最小にしたい | BigQuery（サーバーレス） |
| 複数クラウドにまたがる | Snowflake / Databricks |
もう一つ大事なのが、チームのスキルと既存資産です。SQLが中心のチームならSnowflakeやBigQueryが馴染みやすく、PythonやSparkで機械学習まで踏み込むならDatabricksが力を発揮します。すでに使っているクラウドに寄せると、認証やデータ連携が楽になります。
具体的な場面で考えると、当たりがつきやすくなります。たとえば、Web/アプリのアクセスログを分析したい中規模のEC企業で、すでにGoogle系のツールを使っているなら、BigQueryが素直な選択です。複数部門がSQLで分析し、グループ会社ともデータを共有したい全社基盤なら、Snowflakeが向きます。需要予測などの機械学習モデルを、データ加工から学習まで一気通貫で回したいなら、Databricksが力を発揮します。いずれも「やりたいことの中心」から逆算するのがコツです。
DWHは単体では完結しない
クラウドDWHは強力ですが、それだけでデータ活用が完成するわけではありません。各システムからデータを取り込み（ELT）、使える形に整え（変換）、見せる（BI）という前後の工程とつないで、はじめて価値が出ます。とくに、DWHの中でデータを層に分けて整える設計は、品質と再利用性を大きく左右します。
層に分けて整える代表的な考え方が、メダリオンアーキテクチャです。設計の考え方はメダリオンアーキテクチャの解説、その変換をdbtで実装する具体はdbtでの実装ガイドにまとめています。DWHを選んだら、この変換層の設計もあわせて検討してください。
まとめ
- クラウドDWHは「ストレージとコンピュートの分離」で、従来型の増強・干渉・運用の壁を解く。
- 同じデータを共有しつつ、用途ごとに計算資源を分け、使った分だけ課金される。
- 主要3つはSnowflake（SQL分析・共有）、BigQuery（サーバーレス・GCP）、Databricks（大規模処理・ML）。
- 選び方は「最強探し」でなく、既存クラウド・主なワークロード・チームスキルとの相性で決める。
まずは「自社の主なワークロードはSQL分析か、機械学習か」「すでに使っているクラウドはどこか」を整理すると、候補が絞れます。DWHの選定や移行、変換層の設計を一緒に詰めたいときは、DE-STKの初回スポット相談を壁打ち相手に使っていただけたらうれしいです。
よくある質問（FAQ）
Q. クラウドDWHは、従来のデータベースと何が違うのですか？
A. 用途が違います。一般的なデータベース（OLTP）は、注文の登録のような日々の処理を高速にこなすためのものです。DWH（OLAP）は、大量のデータを集計・分析するために最適化されています。クラウドDWHは後者をクラウドで提供し、ストレージとコンピュートを分離して柔軟に拡張できるようにしたものです。
Q. 従量課金だと、費用が青天井になりませんか？
A. 使うほど増えるのは事実なので、歯止めが要ります。多くのサービスに、計算資源を自動停止する設定や、利用額の上限・通知の仕組みがあります。これらを設定し、毎月の利用内訳を確認する役割を置けば、想定外の膨張は防げます。小さく始めて実際の費用感を掴んでから広げると、予算も読みやすくなります。
Q. 3つのうち、迷ったらどれを選べばいいですか？
A. すでに特定のクラウドを使っているなら、それに合わせるのが無難です（Google CloudならBigQuery）。クラウドが決まっておらず、SQLでの分析が中心なら、扱いやすいSnowflakeが有力です。機械学習や大規模なデータ処理まで一気通貫でやりたいなら、Databricksが向きます。迷う場合は、いずれも無料枠や試用があるので、自社の代表的なデータで小さく試すのが確実です。
Q. 既存のオンプレDWHから移行するのは大変ですか？
A. 一度に全部を移すと大変です。まず1つの分析領域だけをクラウドDWHに載せ、効果と費用を確かめてから広げるのが定石です。データの取り込みや変換の仕組みも段階的に移します。最初から全社のデータを完全移行しようとすると、要件が膨らんで止まりやすいので、小さく始めて育てる進め方をおすすめします。