LESSON 30分

ストーリー

田中VPoE
データレイクは「データを貯める場所」だった。次はそのデータを分析可能にする「データウェアハウス(DWH)」の設計だ
あなた
BigQueryやSnowflakeですよね。データレイクとの違いは何ですか?
田中VPoE
データレイクは「何でも入る」が「そのままでは分析しにくい」。DWHは「スキーマが定義された構造化データ」を「高速にクエリ」できる。Medallionアーキテクチャでいうと、Silver層やGold層をDWHに配置する
あなた
DWHの選定と、その上でのデータモデリングが今回のテーマですね
田中VPoE
その通り。クラウドDWHはそれぞれ設計思想が異なる。BigQueryはサーバーレスでストレージとコンピュートが分離、Snowflakeはマルチクラスター共有データ、Redshiftはプロビジョニング型。用途に応じた選定が必要だ

クラウドDWHの比較

主要サービス

観点BigQuerySnowflakeRedshift
ベンダーGoogle CloudSnowflakeAWS
アーキテクチャサーバーレスマルチクラスター共有データプロビジョニング / Serverless
ストレージ分離完全分離完全分離Serverless版で分離
課金モデルスキャン量課金 / スロット予約クレジット(時間課金)ノード時間課金
スケーリング自動(スロット)手動/自動(ウェアハウスサイズ)手動/自動(ノード数)
同時実行高い(自動スケール)高い(マルチクラスター)中程度(WLM)
半構造化データネイティブ(JSON, ARRAY)VARIANT型SUPER型
ML統合BigQuery MLSnowparkRedshift ML
エコシステムGCP統合マルチクラウドAWS統合

選択基準

要件推奨
既存クラウドがGCPBigQuery
既存クラウドがAWSRedshift 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/                   # カスタムテスト

まとめ

ポイント内容
クラウドDWHBigQuery、Snowflake、Redshiftの特性と選定基準
スキーマ設計スタースキーマが標準、用途に応じてワイドテーブルやデータボルト
クエリ最適化パーティショニング、クラスタリング、マテリアライズドビュー
dbtモデル層分離(bronze/silver/gold)で変換を管理

チェックリスト

  • クラウドDWH 3製品の特性と選定基準を説明できる
  • スタースキーマの設計方法を理解した
  • パーティショニングとクラスタリングでクエリ最適化ができる
  • dbtプロジェクトの構造と役割を理解した

次のステップへ

次は「レイクハウスアーキテクチャ」を学びます。データレイクとDWHの長所を統合した新しいアーキテクチャパターンを理解しましょう。


推定読了時間: 30分