ストーリー
田
田中VPoE
データレイクは「データを貯める場所」だった。次はそのデータを分析可能にする「データウェアハウス(DWH)」の設計だ
あなた
BigQueryやSnowflakeですよね。データレイクとの違いは何ですか?
あ
田
田中VPoE
データレイクは「何でも入る」が「そのままでは分析しにくい」。DWHは「スキーマが定義された構造化データ」を「高速にクエリ」できる。Medallionアーキテクチャでいうと、Silver層やGold層をDWHに配置する
あなた
DWHの選定と、その上でのデータモデリングが今回のテーマですね
あ
田
田中VPoE
その通り。クラウドDWHはそれぞれ設計思想が異なる。BigQueryはサーバーレスでストレージとコンピュートが分離、Snowflakeはマルチクラスター共有データ、Redshiftはプロビジョニング型。用途に応じた選定が必要だ
クラウドDWHの比較
主要サービス
| 観点 | BigQuery | Snowflake | Redshift |
|---|
| ベンダー | Google Cloud | Snowflake | AWS |
| アーキテクチャ | サーバーレス | マルチクラスター共有データ | プロビジョニング / Serverless |
| ストレージ分離 | 完全分離 | 完全分離 | Serverless版で分離 |
| 課金モデル | スキャン量課金 / スロット予約 | クレジット(時間課金) | ノード時間課金 |
| スケーリング | 自動(スロット) | 手動/自動(ウェアハウスサイズ) | 手動/自動(ノード数) |
| 同時実行 | 高い(自動スケール) | 高い(マルチクラスター) | 中程度(WLM) |
| 半構造化データ | ネイティブ(JSON, ARRAY) | VARIANT型 | SUPER型 |
| ML統合 | BigQuery ML | Snowpark | Redshift ML |
| エコシステム | GCP統合 | マルチクラウド | AWS統合 |
選択基準
| 要件 | 推奨 |
|---|
| 既存クラウドがGCP | BigQuery |
| 既存クラウドがAWS | Redshift or Snowflake |
| マルチクラウド | Snowflake |
| アドホッククエリが多い | BigQuery(スキャン量課金) |
| 定常ワークロードが多い | Snowflake or Redshift(時間課金) |
| データ共有が重要 | Snowflake(Data Sharing) |
DWHの設計パターン
スキーマ設計
| パターン | 特徴 | 適用場面 |
|---|
| スタースキーマ | 中央にファクト、周囲にディメンション | 標準的なBI/分析 |
| スノーフレークスキーマ | ディメンションを正規化 | ディメンションが階層的な場合 |
| ワイドテーブル(OBT) | 1つの大きなテーブルに結合 | シンプルなクエリ、BIパフォーマンス |
| データボルト | ハブ、リンク、サテライトの3構造 | 監査要件が厳しい、変更が多い |
スタースキーマの例
-- ファクトテーブル: 売上実績
CREATE TABLE gold.fact_sales (
sale_id INT64 NOT NULL,
order_date_key INT64 NOT NULL, -- dim_date への参照
customer_key INT64 NOT NULL, -- dim_customer への参照
product_key INT64 NOT NULL, -- dim_product への参照
channel_key INT64 NOT NULL, -- dim_channel への参照
quantity INT64,
unit_price NUMERIC,
discount_amount NUMERIC,
net_amount NUMERIC,
tax_amount NUMERIC,
gross_amount NUMERIC,
_loaded_at TIMESTAMP
);
-- ディメンションテーブル: 顧客
CREATE TABLE gold.dim_customer (
customer_key INT64 NOT NULL,
customer_id STRING NOT NULL, -- ビジネスキー
customer_name STRING,
segment STRING, -- Enterprise / SMB / Startup
industry STRING,
country STRING,
region STRING,
created_at DATE,
-- SCD Type 2 (Slowly Changing Dimension)
effective_from DATE,
effective_to DATE,
is_current BOOLEAN,
_loaded_at TIMESTAMP
);
クエリ最適化
BigQueryにおける最適化手法
| 手法 | 効果 | 実装 |
|---|
| パーティショニング | スキャン量の削減 | PARTITION BY DATE(order_date) |
| クラスタリング | 同一値のデータを近接配置 | CLUSTER BY customer_id, product_id |
| マテリアライズドビュー | 事前計算で高速化 | CREATE MATERIALIZED VIEW |
| BI Engine | インメモリアクセラレーション | BIダッシュボードの高速化 |
| *SELECT の回避 | 不要列のスキャン削減 | 必要な列のみ指定 |
-- パーティション + クラスタリングの例
CREATE TABLE gold.fact_sales
PARTITION BY DATE(order_date)
CLUSTER BY customer_id, product_id
AS
SELECT * FROM silver.orders
WHERE status = 'COMPLETED';
コスト管理
| 対策 | 方法 |
|---|
| クエリあたりの上限設定 | maximum_bytes_billed の設定 |
| スロット予約 | 定常ワークロードは予約で割安に |
| 不要テーブルの削除 | TTL設定、テーブル有効期限 |
| クエリ監査 | INFORMATION_SCHEMA.JOBS で高コストクエリを特定 |
「DWHのコスト最適化はパーティショニングとクラスタリングが基本だ。これだけでクエリコストが10分の1になることもある。まずここから始めてくれ」 — 田中VPoE
dbtによるデータモデリング
dbtプロジェクト構造
dbt_project/
├── dbt_project.yml
├── models/
│ ├── bronze/ # Bronze層: 最小限の変換
│ │ ├── brz_orders.sql
│ │ └── brz_customers.sql
│ ├── silver/ # Silver層: クレンジング
│ │ ├── slv_orders.sql
│ │ └── slv_customers.sql
│ ├── gold/ # Gold層: ビジネスロジック
│ │ ├── dimensions/
│ │ │ ├── dim_customer.sql
│ │ │ └── dim_product.sql
│ │ ├── facts/
│ │ │ └── fact_sales.sql
│ │ └── marts/
│ │ ├── revenue_daily.sql
│ │ └── customer_ltv.sql
│ └── schema.yml # テスト定義
├── seeds/ # 静的データ
├── macros/ # 再利用可能なSQL
└── tests/ # カスタムテスト
まとめ
| ポイント | 内容 |
|---|
| クラウドDWH | BigQuery、Snowflake、Redshiftの特性と選定基準 |
| スキーマ設計 | スタースキーマが標準、用途に応じてワイドテーブルやデータボルト |
| クエリ最適化 | パーティショニング、クラスタリング、マテリアライズドビュー |
| dbt | モデル層分離(bronze/silver/gold)で変換を管理 |
チェックリスト
次のステップへ
次は「レイクハウスアーキテクチャ」を学びます。データレイクとDWHの長所を統合した新しいアーキテクチャパターンを理解しましょう。
推定読了時間: 30分