STEP 11：DWH概念とアーキテクチャ

ホーム > クラウドデータ基盤 > STEP 11

🏛️ STEP 11: DWH概念とアーキテクチャ

データウェアハウスの仕組みを理解し、RedshiftとBigQueryを比較しよう

📋 このステップで学ぶこと

  • OLTP vs OLAP の違い（復習）
  • MPP（超並列処理）アーキテクチャ
  • カラムナーストレージとは
  • Amazon Redshift vs Google BigQuery 比較
  • データウェアハウスの設計思想（スタースキーマ）

🎯 このステップのゴール

このステップを終えると、データウェアハウスの仕組みを理解し、RedshiftとBigQueryを適切に選択できるようになります。STEP 10で学んだデータレイクとの違いも明確に理解できます。

🔄 1. OLTP vs OLAP（復習）

データベースには大きく分けて2種類の用途があります：OLTPとOLAPです。データウェアハウスを理解するには、この違いをしっかり押さえることが重要です。

💡 例え話：レジと売上レポート

【OLTP = コンビニのレジ】 ・お客さんが商品を買う → 1件ずつ記録 ・在庫が減る → 1件ずつ更新 ・お釣りを渡す → すぐ終わる（ミリ秒） → 「1件1件を速く処理する」のが目的 【OLAP = 本部の売上レポート】 ・今月の売上合計は？ → 100万件を集計 ・どの商品が売れてる？ → ランキング作成 ・去年と比べてどう？ → 年次比較 → 「大量データを分析する」のが目的 同じ「売上データ」でも、目的が違う！

OLTPとは

📝 OLTP = Online Transaction Processing（オンライントランザクション処理）

日常業務で使うデータベースのことです。

  • ECサイトで商品を注文する
  • 銀行でお金を振り込む
  • 社員が勤怠を入力する

特徴：「書き込み」が多い、1件〜数千件、超高速（ミリ秒）

OLAPとは

📝 OLAP = Online Analytical Processing（オンライン分析処理）

データを分析するためのデータベースのことです。

  • 今月の売上を集計する
  • 去年と今年の売上を比較する
  • どの商品が一番売れているか分析する

特徴：「読み込み・集計」が多い、数百万〜数億件、やや遅い（秒〜分）

OLTP vs OLAP の比較表

項目 OLTP OLAP
用途 業務処理（注文、振込など） 分析・レポート作成
主な操作 書き込み（INSERT、UPDATE） 読み込み（SELECT、集計）
データ量 少ない（1件〜数千件） 多い（数百万〜数億件）
レスポンス 超高速（ミリ秒） やや遅い（秒〜分）
データの鮮度 リアルタイム 日次・週次バッチ更新
データ構造 正規化（無駄を省く） 非正規化（集計しやすく）
利用者 一般ユーザー、アプリ アナリスト、経営層
DB例 MySQL、PostgreSQL、Oracle Redshift、BigQuery、Snowflake

💡 具体例：ECサイトの場合

【OLTP】業務システム（MySQL/PostgreSQL） ┌─────────────────────────────────────────┐ │ ユーザーが商品を注文 │ │ → INSERT INTO orders VALUES (…) │ │ → 処理時間: 10ミリ秒 │ │ │ │ 在庫を1つ減らす │ │ → UPDATE products SET stock = stock-1 │ │ → 処理時間: 5ミリ秒 │ └─────────────────────────────────────────┘ 特徴: 1件ずつ、超高速、リアルタイム 【OLAP】分析システム（Redshift/BigQuery） ┌─────────────────────────────────────────┐ │ 今月の売上合計は？ │ │ → SELECT SUM(amount) FROM orders │ │ WHERE month = ‘2025-01’ │ │ → 500万件を集計、処理時間: 3秒 │ │ │ │ 商品別売上ランキングは？ │ │ → SELECT product_id, SUM(amount) │ │ GROUP BY product_id ORDER BY 2 DESC │ │ → 500万件を集計、処理時間: 5秒 │ └─────────────────────────────────────────┘ 特徴: 大量データ、集計処理、バッチ更新

🎯 データウェアハウス = OLAP用データベース

データウェアハウス（DWH）は、OLAP用に最適化されたデータベースです。
大量のデータを高速に集計・分析できるように、MPPとカラムナーストレージという技術を使っています。

⚡ 2. MPP（超並列処理）アーキテクチャ

MPPとは

MPP = Massively Parallel Processing（超並列処理）とは、複数のコンピュータで同時に処理する仕組みのことです。

💡 例え話：引っ越しの荷物運び

【従来のDB = 1人で引っ越し】 ・段ボール100箱を1人で運ぶ ・1箱5分 × 100箱 = 500分（約8時間） ・疲れてくると遅くなる… 【MPP = 10人で引っ越し】 ・段ボール100箱を10人で分担 ・各自10箱ずつ担当 ・1箱5分 × 10箱 = 50分 ・10倍速い！ さらに荷物が増えても… ・段ボールが1000箱に増えた ・人を10人 → 100人に増やせばOK ・処理時間は変わらず50分！ これがスケールアウトの考え方

従来のデータベース vs MPP

❌ 従来のDB（単一サーバー）

1台のサーバーで全データを処理

  • データ量が増えると遅くなる
  • スケールアップ（高性能サーバーに交換）が必要
  • 限界がある（1台の性能上限）

✅ MPP（複数サーバー）

複数のサーバーで並列処理

  • データ量が増えてもサーバーを追加すればOK
  • スケールアウト（サーバー台数を増やす）が可能
  • 理論上、無限にスケール可能

MPPの仕組み

📊 MPPアーキテクチャの構成

【MPPの基本構成】 ┌─────────────────────────────────────────────────┐ │ リーダーノード │ │ （司令塔：クエリを受け取り、指示を出す） │ └─────────────────────────────────────────────────┘ ↓ ↓ ↓ ↓ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ワーカー1│ │ワーカー2│ │ワーカー3│ │ワーカー4│ │(25万件) │ │(25万件) │ │(25万件) │ │(25万件) │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ↓ ↓ ↓ ↓ 結果 結果 結果 結果 ↓ ↓ ↓ ↓ ┌─────────────────────────────────────────────────┐ │ リーダーノード │ │ （結果を集約して、ユーザーに返す） │ └─────────────────────────────────────────────────┘ 【役割分担】 1. リーダーノード（Leader Node） ・クエリを受け取る ・実行計画を作成（どのノードが何を処理するか） ・各ワーカーに指示 ・結果を集約 2. ワーカーノード（Worker Node） ・実際にデータを処理 ・各ノードが一部のデータを担当 ・並列で同時に処理

💡 具体例：100万件のデータを集計

【クエリ】 SELECT SUM(amount) FROM sales WHERE year = 2025; 【従来のDB（1台）】 ┌─────────────────────────────────────┐ │ 1台で100万件を処理 │ │ → 10秒かかる │ └─────────────────────────────────────┘ 【MPP（10台）】 ┌───────────┐ ┌───────────┐ ┌───────────┐ │ ノード1 │ │ ノード2 │ … │ ノード10 │ │ 10万件処理 │ │ 10万件処理 │ │ 10万件処理 │ │ → 1秒 │ │ → 1秒 │ │ → 1秒 │ └───────────┘ └───────────┘ └───────────┘ ↓ ↓ ↓ 結果1 結果2 結果10 ↓ ↓ ↓ ┌─────────────────────┐ │ リーダーが結果を集約 │ │ → 0.1秒 │ └─────────────────────┘ 合計: 1秒 + 0.1秒 = 約1秒で完了！（10倍高速） 【データが増えても大丈夫】 ・データが1000万件に増えた ・ノードを10台 → 100台に増やす ・処理時間は変わらず1秒！

🎯 RedshiftもBigQueryもMPP

Amazon RedshiftもGoogle BigQueryも、MPPアーキテクチャを採用しています。
そのため、ペタバイト（1000TB）級のデータも高速に処理できるのです。

📊 3. カラムナーストレージ

カラムナーストレージとは

カラムナーストレージ（Column-oriented Storage）とは、データを列（カラム）ごとに保存する方式です。これがDWHの高速化の秘密です。

💡 例え話：本棚の整理

【行指向 = 作者ごとに本棚を分ける】 ・村上春樹の本棚：小説、エッセイ、インタビュー集 ・東野圭吾の本棚：小説、エッセイ、インタビュー集 ・宮部みゆきの本棚：小説、エッセイ、インタビュー集 →「村上春樹の本を全部見たい」時に便利 → でも「全作者のエッセイだけ見たい」時は、 全部の本棚を回る必要がある… 【列指向 = ジャンルごとに本棚を分ける】 ・小説の本棚：村上、東野、宮部… ・エッセイの本棚：村上、東野、宮部… ・インタビュー集の本棚：村上、東野、宮部… →「全作者のエッセイだけ見たい」時に便利 → エッセイの本棚だけ見ればOK！ DWHでは「特定の列だけ集計」が多いので、 列指向の方が速い！

行指向 vs 列指向

📝 行指向ストレージ（Row-oriented）

従来のDB（MySQL、PostgreSQLなど）は、行ごとに保存します。

【データ例】 | ID | 名前 | 年齢 | 都市 | |—-|———|——|——–| | 1 | Alice | 25 | Tokyo | | 2 | Bob | 30 | Osaka | | 3 | Charlie | 35 | Kyoto | 【ディスクへの保存方法】 [1, Alice, 25, Tokyo] ← 行1 [2, Bob, 30, Osaka] ← 行2 [3, Charlie, 35, Kyoto] ← 行3 → 1行ずつまとめて保存

📝 列指向ストレージ（Column-oriented）

DWH（Redshift、BigQueryなど）は、列ごとに保存します。

【同じデータ】 | ID | 名前 | 年齢 | 都市 | |—-|———|——|——–| | 1 | Alice | 25 | Tokyo | | 2 | Bob | 30 | Osaka | | 3 | Charlie | 35 | Kyoto | 【ディスクへの保存方法】 ID列： [1, 2, 3] 名前列： [Alice, Bob, Charlie] 年齢列： [25, 30, 35] 都市列： [Tokyo, Osaka, Kyoto] → 列ごとに分けて保存

なぜ列指向が速いのか？

💡 具体例：年齢の平均を計算

SELECT AVG(年齢) FROM users; 【行指向ストレージの場合】 1. ディスクから全行を読み込む [1, Alice, 25, Tokyo] ← 読み込む [2, Bob, 30, Osaka] ← 読み込む [3, Charlie, 35, Kyoto] ← 読み込む 2. その中から「年齢」だけ抽出 25, 30, 35 3. 平均を計算 (25 + 30 + 35) / 3 = 30 → 不要なデータ（ID、名前、都市）も読み込むので遅い 【列指向ストレージの場合】 1. 「年齢」列だけ読み込む [25, 30, 35] ← これだけ！ 2. 平均を計算 (25 + 30 + 35) / 3 = 30 → 必要なデータだけ読むので速い！ 【効果】 ・1000万行、100列のテーブル ・行指向：100列分すべて読み込み = 100GB ・列指向：1列分だけ読み込み = 1GB → 100倍の差！

カラムナーストレージのメリット

⚡ 高速なクエリ

必要な列だけ読み込めばOK。
例：「年齢」だけ必要なら、「年齢列」だけ読む。

💾 高い圧縮率

同じ型のデータがまとまるので、圧縮しやすい。
ストレージ容量を大幅に削減できる。

📊 集計に最適

「年齢の平均」「売上の合計」などの集計が超高速。
OLAP（分析）に向いている。

💡 圧縮の仕組み

【都市列のデータ】 Tokyo, Tokyo, Tokyo, Osaka, Osaka, Kyoto, Kyoto, Kyoto 【列指向ストレージ】 同じ値が連続しているので、Run-Length Encoding（RLE）で圧縮 Tokyo × 3, Osaka × 2, Kyoto × 3 → 8個のデータが6個に圧縮 【さらにDictionary Encoding】 Tokyo = 1, Osaka = 2, Kyoto = 3 1 × 3, 2 × 2, 3 × 3 → 文字列が数値になり、さらに小さく 【効果】 ・元のデータ: 1TB ・圧縮後: 100GB〜200GB（1/5〜1/10） → ストレージコスト、クエリコストが大幅削減！

⚠️ カラムナーストレージのデメリット

  • 1行全体を読む時は遅い：全列を読む必要があるため
  • 書き込みが遅い：列ごとに分散して書き込むため
  • UPDATE/DELETEが苦手：行指向より複雑

だから、OLAP（分析）には最適だけど、OLTP（業務処理）には不向きなのです。

🆚 4. Redshift vs BigQuery 比較

Amazon RedshiftとGoogle BigQueryは、どちらもクラウド型のデータウェアハウスです。基本的な考え方は同じですが、細かい違いがあります。

比較表

項目 Amazon Redshift Google BigQuery
提供元 AWS（Amazon） GCP（Google）
アーキテクチャ MPP + カラムナー MPP + カラムナー
管理方法 クラスターを作成
（ノード数を指定）		 サーバーレス
（自動スケール）
料金体系 時間課金
（クラスター稼働時間）		 クエリ課金
（スキャンしたデータ量）
スケーリング 手動
（ノードを増減）		 自動
（必要に応じて自動拡張）
SQL方言 PostgreSQL互換 標準SQL + 独自拡張
ストレージと計算 結合（同じクラスター） 分離（独立）
機械学習 SageMaker連携 BigQuery ML（組込）

詳細な比較

🟠 Amazon Redshift の特徴

管理方法：

  • クラスター（ノードの集まり）を作成する必要がある
  • ノード数やノードタイプを選択
  • クラスターを起動・停止できる（コスト管理）

料金体系：

料金 = ノード数 × 時間単価 × 稼働時間 【計算例】 ・dc2.large（2ノード）× $0.25/時間 ・1ヶ月（730時間）稼働 料金 = 2 × $0.25 × 730 = $365/月 【コスト削減Tips】 ・使わない時は停止 → 夜間・週末は$0 ・リザーブドインスタンス → 最大75%割引

🔵 Google BigQuery の特徴

管理方法：

  • サーバーレス（インフラ管理不要）
  • 自動でスケールアップ・ダウン
  • 常に起動状態（停止の概念がない）

料金体系：

料金 = スキャンしたデータ量 × $5/TB + ストレージ × $0.02/GB/月 【計算例1：軽い使い方】 ・1日10GB × 30日 = 300GB/月 ・料金 = 0.3TB × $5 = $1.50/月 【計算例2：ヘビーな使い方】 ・1日100GB × 30日 = 3TB/月 ・料金 = 3TB × $5 = $15/月 【コスト削減Tips】 ・パーティション/クラスタリング → スキャン量削減 ・フラットレート課金 → 大量利用時にお得

💰 コスト比較シミュレーション

【シナリオ】データ量1TB、1日10クエリ（各100GBスキャン） ┌─────────────────────────────────────────────────┐ │ Redshift（dc2.large × 2ノード、24時間稼働） │ ├─────────────────────────────────────────────────┤ │ 月額: 2 × $0.25 × 730 = $365/月 │ │ │ │ クエリが増えても料金は変わらない（固定） │ └─────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────┐ │ BigQuery（オンデマンド課金） │ ├─────────────────────────────────────────────────┤ │ 月額: 100GB × 10回 × 30日 = 30TB │ │ 料金: 30TB × $5 = $150/月 │ │ │ │ クエリが増えると料金も増える（従量） │ └─────────────────────────────────────────────────┘ 【結論】 ・クエリが少ない → BigQueryが安い ・クエリが多い → Redshiftが安い（上限がある） ・たまにしか使わない → BigQueryが安い ・24時間使う → Redshiftが安い

🎯 どちらを選ぶべきか？

Redshiftがおすすめ

  • AWSエコシステムを使っている
  • 安定した利用量（予測可能）
  • PostgreSQLの知識がある
  • コストを固定したい
  • 夜間は停止してコスト削減したい

BigQueryがおすすめ

  • GCPエコシステムを使っている
  • 利用量が不定期（たまに大量クエリ）
  • インフラ管理をしたくない
  • 機械学習（BigQuery ML）を使いたい
  • まずは小さく始めたい

🏗️ 5. データウェアハウスの設計思想（スタースキーマ）

スタースキーマとは

データウェアハウスでは、スタースキーマという設計パターンがよく使われます。OLTP用のデータベース設計とは異なる考え方です。

💡 例え話：新聞の5W1H

【ファクト（事実）】= 何が起きた？ 「売上100万円」という事実 【ディメンション（次元）】= 5W1H ・いつ？ → 日付ディメンション（2025年1月19日） ・誰が？ → 顧客ディメンション（Alice） ・何を？ → 商品ディメンション（ノートPC） ・どこで？ → 店舗ディメンション（東京店） ・どうやって？ → 支払いディメンション（クレジットカード） 【スタースキーマ】 商品 ↑ 日付 ← 売上ファクト → 顧客 ↓ 店舗 → 中心（ファクト）から放射状に広がる → 星（スター）のような形

ファクトテーブルとディメンションテーブル

📊 ファクトテーブル（事実テーブル）

測定可能な事実を記録するテーブル。売上、アクセス数、在庫数など。

【sales_fact テーブル】 | 売上ID | 日付ID | 商品ID | 顧客ID | 売上金額 | 数量 | |——–|———-|——–|——–|———-|——| | 1 | 20250119 | 100 | 500 | 80000 | 1 | | 2 | 20250119 | 101 | 501 | 4000 | 2 | | 3 | 20250120 | 100 | 502 | 80000 | 1 | 【特徴】 ・数値データ（売上金額、数量）が中心 ・大量のレコード（数百万〜数億件） ・IDで他のテーブルと結合 ・「測定」できるものを記録

📚 ディメンションテーブル（次元テーブル）

詳細情報を記録するテーブル。商品名、顧客名、日付情報など。

【product_dim テーブル】 | 商品ID | 商品名 | カテゴリ | 価格 | |——–|———-|———-|——-| | 100 | ノートPC | 電化製品 | 80000 | | 101 | マウス | 電化製品 | 2000 | 【customer_dim テーブル】 | 顧客ID | 顧客名 | 都市 | 会員ランク | |——–|———|——-|————| | 500 | Alice | Tokyo | ゴールド | | 501 | Bob | Osaka | シルバー | | 502 | Charlie | Kyoto | ブロンズ | 【date_dim テーブル】 | 日付ID | 日付 | 年 | 月 | 曜日 | 祝日 | |———-|————|——|—-|—-|——| | 20250119 | 2025-01-19 | 2025 | 1 | 日 | 0 | | 20250120 | 2025-01-20 | 2025 | 1 | 月 | 0 | 【特徴】 ・説明的なデータ（名前、カテゴリ） ・比較的少ないレコード（数千〜数万件） ・「分類」「属性」を記録

スタースキーマのメリット

⚡ クエリが速い

JOINが少ない（1回で済むことが多い）。DWHで最適化されやすい構造。

📖 理解しやすい

構造がシンプル。ビジネスユーザーでも理解できる。SQLが書きやすい。

🔧 柔軟性

新しいディメンションを追加しやすい。分析軸を増やしやすい。

💡 クエリ例：カテゴリ別の売上集計

— カテゴリ別の売上合計を集計 SELECT p.カテゴリ, SUM(s.売上金額) as 売上合計, COUNT(*) as 件数 FROM sales_fact s JOIN product_dim p ON s.商品ID = p.商品ID GROUP BY p.カテゴリ ORDER BY 売上合計 DESC; — 実行結果 — | カテゴリ | 売上合計 | 件数 | — |———-|———-|——| — | 電化製品 | 164000 | 3 |

💡 クエリ例：月別・顧客ランク別の売上

— 月別、会員ランク別の売上を集計 SELECT d.年, d.月, c.会員ランク, SUM(s.売上金額) as 売上合計, COUNT(DISTINCT s.顧客ID) as 顧客数 FROM sales_fact s JOIN date_dim d ON s.日付ID = d.日付ID JOIN customer_dim c ON s.顧客ID = c.顧客ID GROUP BY d.年, d.月, c.会員ランク ORDER BY d.年, d.月, 売上合計 DESC; — 実行結果 — | 年 | 月 | 会員ランク | 売上合計 | 顧客数 | — |——|—-|———–:|———-|——–| — | 2025 | 1 | ゴールド | 80000 | 1 | — | 2025 | 1 | ブロンズ | 80000 | 1 | — | 2025 | 1 | シルバー | 4000 | 1 |

📝 STEP 11 のまとめ

✅ このステップで学んだこと

  • OLTPは業務処理用、OLAPは分析用のデータベース
  • MPP（超並列処理）で、複数サーバーが同時にデータを処理
  • カラムナーストレージで、列ごとに保存し高速・高圧縮を実現
  • Redshiftはクラスター管理型、BigQueryはサーバーレス
  • スタースキーマでファクトテーブルとディメンションテーブルを設計

💡 重要ポイント

  • データウェアハウスは分析に特化した設計
  • MPPとカラムナーストレージで大量データを高速処理
  • RedshiftとBigQueryは料金体系と管理方法が異なる
  • スタースキーマはシンプルで高速な設計パターン

🎯 次のステップの準備

次のSTEP 12では、「Amazon Redshift入門」を学びます。
実際にRedshiftを使って、データウェアハウスを構築してみましょう！

📝 理解度チェック

問題 1 基礎

OLTPとOLAPの主な違いを3つ挙げてください。

【解答例】

  1. 用途：OLTPは業務処理（注文、振込など）、OLAPは分析・レポート作成
  2. 主な操作：OLTPは書き込み中心、OLAPは読み込み・集計中心
  3. データ量：OLTPは少量（1件〜数千件）、OLAPは大量（数百万〜数億件）
問題 2 基礎

カラムナーストレージのメリットを2つ説明してください。

【解答例】

  1. 高速なクエリ：必要な列だけ読み込めばよいので、不要なデータを読まずに済む。集計クエリが特に速い。
  2. 高い圧縮率：同じ型のデータがまとまるので圧縮効率が高い。ストレージコストを大幅に削減できる。
問題 3 応用

RedshiftとBigQueryの料金体系の違いを説明し、それぞれどのような使い方に向いているか述べてください。

【解答】

料金体系の違い：

  • Redshift：時間課金（クラスターが動いている時間 × ノード数）
  • BigQuery：クエリ課金（スキャンしたデータ量に応じて課金）

Redshiftが向いている使い方：

  • 定期的に使う（毎日クエリを実行）
  • 使用量が予測可能
  • コストを固定したい

BigQueryが向いている使い方：

  • 不定期に使う（たまに大量クエリ）
  • インフラ管理をしたくない
  • まずは小さく始めたい
問題 4 発展

ECサイトの注文データを例に、スタースキーマでファクトテーブルとディメンションテーブルを設計してください。

【解答例】

【ファクトテーブル: orders_fact】 | 注文ID | 日付ID | 商品ID | 顧客ID | 売上金額 | 数量 | 配送料 | |——–|———-|——–|——–|———-|——|——–| | 1 | 20250119 | 100 | 500 | 80000 | 1 | 500 | | 2 | 20250119 | 101 | 501 | 4000 | 2 | 500 | 【ディメンションテーブル: product_dim】 | 商品ID | 商品名 | カテゴリ | 価格 | 在庫数 | |——–|————|———-|——-|——–| | 100 | ノートPC | 電化製品 | 80000 | 50 | | 101 | マウス | 電化製品 | 2000 | 500 | 【ディメンションテーブル: customer_dim】 | 顧客ID | 顧客名 | 都市 | 会員ランク | 登録日 | |——–|———|——-|————|————| | 500 | Alice | Tokyo | ゴールド | 2024-01-01 | | 501 | Bob | Osaka | シルバー | 2024-06-15 | 【ディメンションテーブル: date_dim】 | 日付ID | 日付 | 年 | 月 | 日 | 曜日 | 祝日 | |———-|————|——|—-|—-|——|——| | 20250119 | 2025-01-19 | 2025 | 1 | 19 | 日 | 0 |

❓ よくある質問

Q1: なぜOLTPとOLAPを分ける必要があるのですか？
目的が違うからです。OLTPは「速く書き込む」ことが重要で、OLAPは「大量データを速く集計する」ことが重要です。一つのDBで両方をやろうとすると、どちらも中途半端になってしまいます。例えば、ECサイトで注文処理（OLTP）をしながら、同時に売上集計（OLAP）を実行すると、注文処理が遅くなりユーザー体験が悪化します。
Q2: MPPアーキテクチャは何ノードくらい必要ですか？
データ量と要件によります。Redshiftの場合：
・小規模（〜1TB）：2〜4ノード
・中規模（1〜10TB）：4〜16ノード
・大規模（10TB〜）：16ノード以上
BigQueryはサーバーレスなので、ノード数を意識する必要はありません。まずは小さく始めて、必要に応じてスケールアウトするのがおすすめです。
Q3: カラムナーストレージなのに、なぜ行を追加できるのですか？
内部的に賢く管理しているからです。カラムナーストレージでは、データを列ごとに保存しますが、新しい行を追加する時は、各列の最後に値を追加します。実装は複雑ですが、ユーザーは普通のテーブルのように扱えます。ただし、頻繁にINSERT/UPDATEするとパフォーマンスが落ちるため、定期的なバッチロードが推奨されます。
Q4: スタースキーマ以外の設計パターンはありますか？
はい、スノーフレークスキーマがあります。スノーフレークスキーマは、ディメンションテーブルをさらに正規化した構造です。例えば、商品ディメンションを「商品テーブル」と「カテゴリテーブル」に分割します。メリットはストレージ容量が少なくて済むこと、デメリットはJOINが増えてクエリが遅くなることです。一般的にはスタースキーマが推奨されます。
Q5: RedshiftとBigQuery、どちらが速いですか？
ケースバイケースです。一般的にはBigQueryの方が大規模データの集計に強いとされています。ただし、Redshiftも適切にチューニング（ディストリビューションキー、ソートキーの設定）をすれば十分高速です。小規模データではRedshiftの方が速いこともあります。自分のユースケースで試してみるのが一番です。
Q6: データウェアハウスに直接書き込んでもいいですか？
推奨されません。データウェアハウスは読み込み・集計に最適化されており、頻繁な書き込みは苦手です。ベストプラクティスは：
1. OLTP DB（MySQLなど）に書き込む
2. 定期的（毎時・毎日）にバッチでDWHにロード
3. DWHで分析・レポート作成
STEP 10で学んだデータレイク経由でロードするのも一般的です。
← 前のステップ
STEP 10: データレイク設計 次のステップへ →
STEP 12: Amazon Redshift入門

📝

学習メモ

クラウドデータ基盤（AWS・GCP） - Step 11

💾 自動保存 · 0文字
📋 過去のメモ一覧 ▼
#artnasekai #学習メモ
LINE
ホーム
クラウドデータ基盤（AWS・GCP）