「BigQueryを契約したのに、社内では『で、何に使うの？』という空気が漂っている」「DWHとデータベースの違いを聞かれて、うまく説明できない」——データ活用を進めようとしている担当者が抱えるこの疑問は、意外と整理されていないケースが多いです。
DWHは「分析専用のデータベース」ですが、この一言ではなぜ通常のMySQLやPostgreSQLで代替できないのかが伝わりません。データレイクとはどう使い分けるのか、データマートとは何が違うのか——この3つの「何が違うか」を押さえると、DWHの役割が腹落ちします。
DWH（Data Warehouse、データウェアハウス）とは、複数のシステムから収集したデータを統合・蓄積し、分析に特化した構造で保管するデータベースのことです。
「倉庫（Warehouse）」という名前が示す通り、DWHは「使うために整理して保管する場所」です。営業のSalesforce、マーケティングのGoogle Analytics、経理の会計ソフト——これらバラバラのシステムに散在するデータを一箇所に集め、横断的に分析できる状態にします。
ここが多くの担当者が引っかかるポイントです。MySQLやPostgreSQLといった一般的なデータベース（RDB）でも、データは保管できます。なぜ分析には向かないのでしょうか。
理由は設計思想の違いにあります。
一般的なRDBは OLTP（Online Transaction Processing） 向けに設計されています。OLTPは「1件の注文を素早く登録する」「特定の顧客情報を検索する」といった、少量のデータへの高速な読み書きに最適化されています。ECサイトの注文処理や在庫管理のように、1件ずつのトランザクションを正確に、速く処理するための仕組みです。
一方、分析では「過去3年分の売上データから、商品カテゴリ別・地域別の傾向を集計する」といった処理が必要です。これは OLAP（Online Analytical Processing） と呼ばれるアクセスパターンで、数百万〜数十億件のレコードを横断的にスキャンします。OLTPのRDBにこうした分析クエリを投げると、本来の業務処理に影響が出るうえ、処理に何時間もかかることがあります。
DWHはOLAP向けに設計されており、大規模な分析クエリを高速に処理できます。その中心的な仕組みが列指向ストレージです。
通常のRDBは行単位でデータを保存します。「顧客ID、名前、メール、購入日、金額」という1レコードを、ディスク上でも1まとまりとして保存する方式です。
DWHが採用する列指向ストレージは、列単位でデータを保存します。「金額」列のデータだけを取り出す場合、行指向では全行のすべての列を読む必要があります。列指向では「金額」列だけを読めば済みます。
売上合計を集計するクエリなら、読み込むデータ量が10分の1以下になることも珍しくありません。これがDWHでの分析が速い根本的な理由です。BigQueryやSnowflakeはすべて列指向ストレージを採用しています。
「DWH、データレイク、データマート」は同じデータ基盤の文脈で登場するため混同しやすいです。役割の違いを整理します。
| 種類 | 主な役割 | 保管するデータ | 向いている用途 |
|---|---|---|---|
| データベース（RDB） | 業務処理 | 最新の確定データ | 注文・在庫・顧客管理 |
| データレイク | 生データの保管 | 加工前の生データ・非構造化データ | ログ保管、将来の分析に備えた蓄積 |
| DWH | 分析 | 統合・加工済みのデータ | BI・集計・レポート |
| データマート | 部門別分析 | DWHから絞り込んだデータ | 営業レポート、マーケティング分析 |
データレイクは「とりあえず全部入れておく」場所です。Webサーバーのアクセスログ、IoTセンサーのデータ、画像や動画など、加工前の生データを安価に大量保管します。Amazon S3やGoogle Cloud Storageが代表例で、1GBあたり月数円のストレージコストです。分析前提の整備はされていないため、そのままでは集計やBIには使えません。
DWHは「分析のために整備された」場所です。データレイクの生データを加工・統合し、集計クエリが高速に動く形で保管します。BIツールはDWHに接続して可視化します。
データマートは「特定の用途向けに切り出した」DWHのサブセットです。全社売上データのDWHから、営業部門が見る指標だけを切り出した「営業マート」を作るイメージです。DWH内のテーブルとして実装するケースが大半で、物理的に別システムを立てることは減っています。
2010年代以前のDWHは、Oracle ExadataやTeradata、IBM Netezzaといったオンプレミス製品が中心でした。導入に数千万〜数億円かかり、容量を増やすにはハードウェアを追加購入するしかなく、中堅企業が手を出せるものではありませんでした。
状況を変えたのがクラウドDWHです。
ストレージとコンピュートの分離が最大の革新でした。従来のDWHはデータの保管と処理を同じハードウェアが担っていたため、データ量が増えれば処理能力も同時に増強する必要がありました。クラウドDWHは保管と処理を独立させたため、「大量のデータを安く保管しながら、処理は必要なときだけ強力にする」が実現できます。
BigQuery（2011年一般提供開始）はこの分離を徹底した設計で、Googleの分散処理インフラの上で動きます。Snowflake（2015年）は「仮想ウェアハウス」と呼ぶ計算リソースを複数起動でき、部門ごとに分離して課金できる設計が特徴です。
3つが主要な選択肢です。簡単に特徴をまとめると：
選定の判断基準は「どのクラウドをメインで使っているか」「複数チームが並列でクエリを実行するか」「スモールスタートか大規模運用か」の3点で8割が決まります。コスト・性能・マルチクラウド・データ共有の7軸での詳細な比較はSnowflakeとBigQueryの違いを徹底比較：コスト・性能・機能で選ぶで、BigQueryのコスト設計についてはBigQueryコスト最適化：コスト爆発を防ぐ設計原則でそれぞれ詳しく解説しています。
DWHを構築する際に押さえておくべき設計の基本を2つ紹介します。
DWHのテーブル設計で最もよく使われるのがスタースキーマです。
中心に「ファクトテーブル」（売上、注文、アクセスログなど、数値データを持つテーブル）を置き、その周囲に「ディメンションテーブル」（顧客マスタ、商品マスタ、日付テーブルなど）を配置します。図にすると星形になることが名前の由来です。
たとえば「売上ファクトテーブル」には顧客ID・商品ID・日付ID・売上金額だけを持たせ、顧客の名前・地域・年代は「顧客ディメンション」に持たせます。BIツールで「地域別・年代別の月次売上」を集計するとき、JOINで組み合わせる仕組みです。
スタースキーマのメリットはクエリがシンプルになることです。通常のRDBで正規化されたテーブルは結合が複雑になりがちですが、スタースキーマは結合するテーブルが少なく、BIツールからも扱いやすい設計です。
BigQueryやSnowflakeで費用を抑えながら高速な分析を実現するために不可欠なのがパーティションとクラスタリングです。
パーティションは、データを日付などの単位で物理的に分割して保管する設計です。「2026年6月1日のデータ」だけをスキャンすれば済むクエリで、テーブル全体をスキャンしなくなります。BigQueryでは日付パーティションを設定するだけで、スキャン量（＝費用）を10分の1以下に削減できるケースがあります。
クラスタリングは、パーティション内をさらに特定の列でソートして保管する仕組みです。「地域=東京」のデータだけをスキャンするクエリで、東京以外のブロックを読み飛ばせます。
この2つを設定しないまま本番稼働させると、データ量が増えるにつれて費用が青天井になります。Evastでは設計フェーズで必ずパーティション設計を確定してから実装を始めることをルールにしています。
失敗1：SELECT * が横行して費用が月数十万円に膨らむ
BigQueryのオンデマンド課金は、スキャンしたデータ量が課金の基準です。SELECT *（全列取得）を習慣的に使うと、1クエリで数GBをスキャンする状態になります。Evastが支援した事例では、開発者3名がそれぞれSELECT *で探索クエリを投げていたところ、1か月で20万円以上のBigQuery費用が発生していたケースがあります。必要な列だけを指定する習慣と、ドライラン（スキャン量の事前確認）の義務化で対処しました。
失敗2：パーティション・クラスタリングなしで設計してしまう
後からパーティションを追加する場合、テーブルの再作成が必要になります。データ量が多いと数時間のダウンタイムが発生し、ETL処理の一時停止が必要になることも。設計フェーズで決めておかないと、本番稼働後に修正コストが数倍になります。
失敗3：データマートが乱立して「どれが正しいのか」わからなくなる
「部門ごとに好き勝手に集計テーブルを作る」状態が続くと、6か月後には同じKPIが3パターン存在し、「どれが正しいのか」を誰も把握できなくなります。raw・staging・martの3層設計と、martテーブルのオーナー制（誰が責任を持つか）を最初に決めておくことが予防策です。dbtを使ったレイヤー管理についてはETLとELTの違いとは？でも触れています。
失敗4：BIツールが直接生テーブルに接続する
BIツール（TableauやLooker）が最適化されていない生テーブルに直接接続すると、ダッシュボードを開くたびに大量のスキャンが走ります。BIツールはmart層のみに接続する設計にすることで、費用とパフォーマンスの両方を安定させられます。
DWHの役割を3行でまとめると：
クラウドDWHはBigQuery・Snowflake・Redshiftのいずれも、かつてのオンプレミスDWHと比べて圧倒的に安く始められます。ただし「とりあえず入れて、あとで考える」は費用爆発と設計の混乱を招きます。前章の失敗事例で挙げた設計の前提を本番稼働前に決めておくことが、長期運用コストを左右します。
DWHにデータを運ぶETLの仕組みはETLとは？データ統合の基礎と選定ポイントを解説で、DWH内でのデータ変換にはdbtが使われます。dbtの役割についてはdbtとは？SQLでデータ変換を行うツールの基本と導入メリットで解説しています。
株式会社Evastでは、DWH選定・設計から、ETL/ELT実装・BIダッシュボード開発まで、データ基盤の一気通貫支援を行っています。
現状のデータ環境の診断から、ロードマップ策定・実装まで伴走します。
BigQueryを導入したのに月次請求が想定を大きく超えた——そんな経験を持つデータ担当者向けに、スキャン課金の仕組み、パーティション設計の重要性、SELECT *の罠、マートテーブルによる再利用、INFORMATION_SCHEMAによるコスト分析、Cloud Schedulerの設計を解説します。
変換SQLが個人フォルダやSlackで共有される課題を抱えるデータ担当者向けに、dbt（data build tool）の定義、ELTとの位置づけ、Modelファイル・ref関数・テスト・ドキュメント自動生成の4機能、BigQueryとの親和性、3ステップの導入プロセスを解説します。
ETLの基本機能（抽出・変換・書き出し）、ELTやEAIとの違い、データ基盤における役割、ツール選定の観点まで体系的に解説します。「データ活用を進めたいが、何から手をつけるべきか分からない」企業のご担当者様向けに、現場の知見と図解を交えてわかりやすくまとめました。
データパイプラインのスケジューリング・依存管理・監視を担うオーケストレーションツールを4軸で比較します。Airflow（業界標準・大規模向け）、Dagster（データ資産中心・dbt親和性）、Prefect（シンプル・スモールスタート）の設計思想の違いと、チーム規模・技術スタックに応じた選び方をEvastの現場経験をもとに解説します。
