LabHub

ブログ

モダンクラウドデータウェアハウス 2026 完全ガイド - Snowflake / Databricks SQL / BigQuery / Redshift / Firebolt / Azure Synapse / MotherDuck 徹底分析

2026-05-16 · 41 分で読めます · #data-warehouse#snowflake#databricks#bigquery#redshift#firebolt#azure-synapse#motherduck#lakehouse#olap#japanese

한국어English日本語

"Lakehouse は製品ではなくアーキテクチャだ。2026年までに、まともなデータプラットフォームはそうあるか、そうあるものに対抗するかのどちらかになる。" — Matei Zaharia, Databricks CTO, Data + AI Summit 2025 基調講演

データウェアハウス (DW) は1980年代の Teradata と IBM DB2 Parallel Edition から始まり、2000年代の Vertica・Greenplum・Netezza のような MPP (Massively Parallel Processing) アプライアンスへ進化し、2014年に Snowflake が「ストレージとコンピュートを完全に分離した SaaS DW」を発表してクラウド時代へ移行しました。2020年には Databricks が「Lakehouse」という用語を定義し、データレイクと DW の境界が曖昧になり、2024年には Apache Iceberg が事実上の標準オープンテーブルフォーマットとなり「どのエンジンを使っても同じデータにアクセスできる」新時代が幕を開けました。

2026年5月現在、モダン DW 市場は Snowflake・Databricks SQL・Google BigQuery・AWS Redshift・Azure Synapse・Firebolt・MotherDuck・ClickHouse Cloud・StarRocks Cloud・Apache Druid/Pinot・Doris・DuckDB・CrateDB など20を超えるエンジンが共存する多極体制です。本稿では各エンジンのアーキテクチャ、価格モデル、AI 統合、ロックイン度合い、そしてクーパン・Naver・メルカリ・LINE ヤフー・サイバーエージェント・楽天など日韓企業の実採用事例まで一気通貫で整理します。

1. MPP DW の進化 — Teradata から Lakehouse へ

データウェアハウスはおよそ50年で4回の大きなパラダイムシフトを経験しました。

世代代表製品特徴
第1世代 (1980-2000)Teradata, IBM DB2 PE, Oracle ExadataShared-nothing MPP アプライアンス、専用ハードウェア
第2世代 (2005-2015)Vertica, Greenplum, Netezza, ParAccelカラム型 MPP、ソフトウェア中心
第3世代 (2014-2020)Snowflake, BigQuery, Redshiftクラウドネイティブ、ストレージ・コンピュート分離
第4世代 (2020-)Databricks Lakehouse, Iceberg + Trino/Spark, Apache Polarisオープンテーブルフォーマット + エンジン自由選択

第1世代は DEC・Tandem のようなメインフレーム級ハードウェア上で動作し、100TB を扱うのに数十億円が必要でした。1992年に Walmart が運用した 24TB の Teradata DW が当時の世界最大規模でした。

第2世代は x86 コモディティハードウェアにカラムストレージと圧縮を適用して価格を一桁下げましたが、オンプレミスが基本で、ストレージ・コンピュートが一つの箱に結合しスケーリングが困難でした。

第3世代の革命は 分離 (Decoupling) です。Snowflake はデータを S3 に置き、コンピュート (Virtual Warehouse) を分単位でオン/オフするモデルを発表しました。BigQuery はさらに進んで「クエリごとの課金」というサーバーレスモデルを提示しました。これにより「クエリ1本にクラスタ1個」という第1・2世代モデルは完全に消滅しました。

第4世代は オープン化 (Openness) です。Apache Iceberg、Delta Lake、Apache Hudi のようなオープンテーブルフォーマットが事実上の標準となり、同じデータに Snowflake からも Trino からも Spark からも DuckDB からも接続できるようになりました。データの「単一の真実の源 (single source of truth)」がもはや特定ベンダーの独占フォーマットではない時代が開かれました。

2. Snowflake — 市場リーダー、ストレージ/コンピュート分離の代名詞

Snowflake (snowflake.com) は2012年に Oracle 出身の Benoit Dageville と Thierry Cruanes が創業し、2020年に NYSE に当時最大規模の SaaS IPO で上場しました。2026年5月時点で時価総額は約600億ドル、四半期売上は約10億ドルで、クラウド DW 市場の不動のリーダーです。

Snowflake のコアアーキテクチャは3層構成です。

-- Snowflake 仮想ウェアハウスの作成と利用
CREATE WAREHOUSE etl_wh
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 60         -- 60秒アイドル後に自動停止
  AUTO_RESUME = TRUE
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4     -- multi-cluster, concurrency scaling
  SCALING_POLICY = 'STANDARD';

USE WAREHOUSE etl_wh;

-- micro-partition pruning を活用するクエリ
SELECT customer_id, SUM(amount) AS total
FROM orders
WHERE order_date BETWEEN '2026-04-01' AND '2026-04-30'
  AND region = 'APAC'
GROUP BY customer_id;

2025年6月の Snowflake Summit で発表された主要な変更点。

価格は credit 単位で、1 credit は通常 $2-$4 (Standard から Business Critical まで) で、XS ウェアハウスは1時間あたり1 credit、サイズが1段階上がるごとに2倍になります。つまり 4XL は1時間あたり128 credit で、Business Critical 基準で1時間あたり約 $512 です。AUTO_SUSPEND でアイドルコストを最小化することが鉄則です。

3. Databricks SQL + Lakehouse — Delta Lake, Photon, Unity Catalog

Databricks (databricks.com) は2013年に UC Berkeley AMPLab で Apache Spark を生んだ Matei Zaharia、Ion Stoica らが創業しました。2026年5月時点の評価額は約620億ドルで、Snowflake と肩を並べます。

Databricks はもともと Spark + ノートブックの会社でしたが、2020年に「Lakehouse」ビジョンを発表して以降、本格的に Snowflake と直接競合する SQL ワークロード市場に参入しました。主要コンポーネント。

-- Databricks SQL の例 — Delta Lake テーブル + AI Function
SELECT
  c.customer_id,
  c.name,
  AI_SUMMARIZE(
    ARRAY_AGG(r.review_text)
  ) AS review_summary,
  AVG(r.rating) AS avg_rating
FROM customers c
JOIN reviews r ON r.customer_id = c.customer_id
WHERE r.created_at > current_date() - INTERVAL 90 DAY
GROUP BY c.customer_id, c.name;

Databricks の差別化要素は 一つのプラットフォームで SQL + Spark + ML + LLM を扱える点です。Snowflake が SQL ワークロード中心なら、Databricks はデータサイエンティストと ML エンジニアが同じデータに直接アクセスしてモデルを学習・サービングできます。

価格は DBU (Databricks Unit) 単位で、ワークロード種別とコンピュートクラスにより DBU 単価が変わります。SQL ワークロードは通常 $0.22-$0.55/DBU、それに加えてクラウドインフラ (EC2/GCE/Azure VM) 費用が別途請求されます。Snowflake の all-in 価格と比較すると分離請求のため最初は安く見えますが、実際は近い水準になることが多いです。

4. Google BigQuery — サーバーレス DW の元祖

BigQuery (cloud.google.com/bigquery) は2010年に Google 社内の Dremel 論文をベースに登場しました。最大の差別化要素は真の サーバーレス (Serverless) — ユーザーはクラスタ・ノード・ストレージサイズを定義せず、ただ SQL を投げれば Google が自動で数千ノードを立ち上げて実行します。

BigQuery 主要コンポーネント。

-- BigQuery の例 — ML と GIS を組み合わせ
CREATE OR REPLACE MODEL mydataset.churn_model
OPTIONS(
  model_type = 'logistic_reg',
  input_label_cols = ['churned']
) AS
SELECT
  age,
  tenure_months,
  monthly_spend,
  ST_DISTANCE(home_location, store_location) AS distance_m,
  churned
FROM `mydataset.customer_features`
WHERE _PARTITIONTIME BETWEEN '2026-01-01' AND '2026-04-30';

-- 予測 + Gemini テキスト生成を組み合わせ
SELECT
  customer_id,
  predicted_churned_probs[OFFSET(1)].prob AS churn_prob,
  ML.GENERATE_TEXT(
    MODEL `mydataset.gemini_model`,
    'Suggest 2 retention offers for this customer'
  ) AS retention_suggestion
FROM ML.PREDICT(MODEL mydataset.churn_model, TABLE customer_segment_apac);

価格モデルは2種類。

BigQuery は 最もロックインが強い DW に分類されます。データは BigQuery 専用 capacitor フォーマットで保存され、他エンジンから直接読むのは困難です。2024年から BigLake により Iceberg 外部テーブルが対応されロックイン懸念はある程度緩和されましたが、真のマルチエンジン互換性はまだ Snowflake に劣ります。

5. AWS Redshift Serverless — RA3, Aqua, 新サーバーレスモデル

AWS Redshift は2012年に ParAccel ベースで登場した AWS 初の DW サービスです。一時期はクラウド DW 市場シェア1位でしたが、Snowflake に押されて停滞し、2022年の Redshift Serverless リリース後に再び活気を取り戻しました。

主要コンポーネント。

-- Redshift Serverless ワークグループ + 外部テーブル + Bedrock の組み合わせ
CREATE EXTERNAL TABLE spectrum.orders_raw (
  order_id BIGINT,
  customer_id BIGINT,
  amount DECIMAL(18, 2),
  order_date DATE
)
STORED AS PARQUET
LOCATION 's3://my-data-lake/orders/'
TABLE PROPERTIES ('skip.header.line.count'='1');

-- Bedrock LLM を SQL から呼び出し
SELECT
  o.order_id,
  o.customer_id,
  AWS.BEDROCK.INVOKE_MODEL(
    'anthropic.claude-sonnet-20240229-v1:0',
    'Summarize this order: ' || o.notes
  ) AS summary
FROM spectrum.orders_raw o
WHERE o.order_date >= current_date - 7;

Redshift Serverless は BigQuery 流の使用量ベース課金で参入障壁を下げましたが、「最小ベース RPU」があり完全に0からは始まりません。軽いワークロードでは依然として BigQuery が有利です。

6. Azure Synapse Analytics — Dedicated/Serverless SQL + Spark + Kusto

Microsoft Azure Synapse Analytics (azure.microsoft.com/services/synapse-analytics) は2019年に Azure SQL Data Warehouse (旧 SQL DW) をリブランドして登場した統合分析プラットフォームです。

3種類のエンジンを一つのワークスペースで統合提供します。

2024年11月の Microsoft Ignite で発表された Microsoft Fabric は Synapse を吸収・拡張した次世代 SaaS 分析プラットフォームで、OneLake (Iceberg/Delta ベース統合ストレージ)、Power BI、Data Factory、Synapse Real-Time Intelligence を一つの SKU にまとめています。2026年現在 Synapse はまだ利用可能ですが、新規導入は Fabric へ向かう流れが明確です。

Synapse の強みは Microsoft 生態系統合 — Active Directory、Azure DevOps、Power BI、Office 365 が自然に接続します。弱みは複数エンジンを一つのワークスペースで運用するため UX が複雑で、コスト予測が難しい点です。

7. Firebolt — 「Snowflake-killer」を標榜する高速 OLAP

Firebolt (firebolt.io) は2019年にイスラエルで創業した会社で、Sisense の元創業者が再挑戦した次世代 OLAP エンジンです。「Snowflake より10倍速く10倍安い」を掲げ、2021年シリーズ C $127M、2023年シリーズ D $100M を調達しました。

差別化要素は インデックス・コンピュート・キャッシュの積極活用 です。Snowflake が micro-partition pruning に依存するのに対し、Firebolt は以下を追加で持ちます。

-- Firebolt の例 — Aggregate Index + dimension テーブル
CREATE AGGREGATING INDEX orders_daily_agg ON orders (
  order_date,
  region,
  SUM(amount),
  COUNT(*)
);

-- インデックスを自動活用するクエリ
SELECT order_date, region, SUM(amount), COUNT(*)
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-04-30'
  AND region IN ('APAC', 'EMEA')
GROUP BY order_date, region;

Firebolt の弱みは エコシステムの狭さ です。Snowflake が Tableau、Looker、dbt、Fivetran など数百のツールと一級市民として統合されているのに対し、Firebolt は統合範囲がまだ狭いです。ただし一部の dashboarding-heavy なワークロード (Looker/Tableau で毎日数千ユーザーがクエリを発行) では価格対性能が非常に良いと報告されています。

8. MotherDuck — DuckDB-as-a-Service

MotherDuck (motherduck.com) は2023年に登場した DuckDB ベースのクラウド DW で、DuckDB の創業者 Hannes Mühleisen が共同創業しました。「シングルノード DW が再び魅力的な時代」を作るというビジョンを掲げます。

中心アイデアは ハイブリッド実行 (Hybrid Execution) です。

# MotherDuck Python の例 — ローカル + クラウド結合
import duckdb

# md: で始まるとMotherDuck クラウドに接続
conn = duckdb.connect('md:my_db?motherduck_token=...')

# ローカル Parquet とクラウドテーブルを結合
df = conn.execute("""
    SELECT
        l.customer_id,
        l.local_event_count,
        c.lifetime_value
    FROM read_parquet('local_events.parquet') l
    JOIN my_db.customers c ON c.customer_id = l.customer_id
    WHERE c.region = 'JP'
""").df()

MotherDuck は2025年から Iceberg 外部テーブル、Snowflake 直接接続、そして自社ノートブック UI を提供します。価格は使用量ベースで非常に安価 (本格利用は月 $15-$25 から)、小規模チームに魅力的です。ただしペタバイト級ワークロードには適合せず、「100TB までのスイートスポット」を狙います。

9. DuckDB 1.x — 組み込み分析の標準

DuckDB (duckdb.org) は2018年にオランダの CWI 研究所で Hannes Mühleisen と Mark Raasveldt が作った組み込み OLAP データベースです。「SQLite for analytics」を標榜し、2024年6月に 1.0 GA、2025年11月に 1.3 stable がリリースされました。

DuckDB の威力は以下のシナリオで圧倒的です。

# DuckDB で S3 Parquet + Postgres + ローカル CSV を一つのクエリに
import duckdb

con = duckdb.connect()

con.execute("INSTALL httpfs; LOAD httpfs;")
con.execute("INSTALL postgres; LOAD postgres;")
con.execute("""
    CREATE SECRET s3 (
        TYPE S3,
        KEY_ID '...',
        SECRET '...',
        REGION 'ap-northeast-1'
    );
""")

result = con.execute("""
    SELECT
        s.customer_id,
        s.order_count,
        p.tier,
        l.city
    FROM read_parquet('s3://my-bucket/orders/*.parquet') s
    JOIN postgres_scan(
        'host=db.example.com user=admin password=...',
        'public', 'customers'
    ) p ON p.id = s.customer_id
    JOIN read_csv('regions.csv') l ON l.code = p.region_code
""").df()

DuckDB の人気は爆発的で、2026年に GitHub star が25,000を超え、dbt-duckdb、ibis-duckdb、datafusion-duckdb などのアダプタが活発に開発されています。小規模組織は DW を別途購入せず S3 + Parquet + DuckDB + dbt-duckdb で十分なケースが増えました。

10. ClickHouse Cloud — カラムストア SaaS

ClickHouse (clickhouse.com) は2009年にロシア Yandex で始まったオープンソースのカラムストア DBMS で、2016年のオープンソース化以降爆発的に成長しました。2021年に米国へ本社移転と ClickHouse Inc 設立、2022年に ClickHouse Cloud GA、2024年後半にシリーズ C $350M を調達しました。

ClickHouse の得意分野は 数十億行のリアルタイム分析 です。MergeTree エンジンはカラム単位圧縮 + パーティション + primary key (sparse index) を組み合わせて、一般 DW の1/10コストで1/10応答時間を実現します。Cloudflare Analytics、Uber、Shopify、eBay が ClickHouse 上でリアルタイム分析を運用しています。

-- ClickHouse テーブル定義 — 時系列イベント分析
CREATE TABLE events (
    event_time DateTime,
    user_id UInt64,
    event_type LowCardinality(String),
    properties JSON
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_type, event_time, user_id)
TTL event_time + INTERVAL 90 DAY;

-- 1秒以内に数十億行を集計
SELECT
    event_type,
    toStartOfHour(event_time) AS hour,
    count() AS events,
    uniq(user_id) AS uniq_users
FROM events
WHERE event_time >= now() - INTERVAL 24 HOUR
GROUP BY event_type, hour
ORDER BY hour DESC;

ClickHouse Cloud は stateless compute + S3 ストレージ分離、自動スケーリング、レプリケート MergeTree のマネージド運用を提供します。価格は分単位コンピュート時間 + ストレージ GB ベースで、dev tier は1時間あたり $0.31 から始まります。

ClickHouse の弱みは トランザクションと UPDATE の難しさ です。UPDATE/DELETE は非同期 mutation でのみ可能で、一般 DW の row-level transaction とは意味が異なります。CDC ベースの DW 取り込みには追加設計が必要です。

11. StarRocks / Apache Doris — 次世代 MPP オープンソース

StarRocks (starrocks.io) は中国 Baidu の Apache Doris (旧 Palo) からフォークした次世代 MPP OLAP エンジンで、2021年に米国 CelerData が商用化しました。Apache Doris (doris.apache.org) はそのまま Apache 財団内で発展中です。

両エンジンとも MPP + ベクトル化 + materialized view + 一部 lakehouse 機能 を組み合わせ、ClickHouse とは異なる側面に強みを持ちます。

StarRocks の ClickHouse に対する強みは マルチテーブル結合 です。ClickHouse が巨大な単一 fact テーブル集計に最適化されているのに対し、StarRocks は fact-dimension の star schema でより良いパフォーマンスを示します。

CelerData Cloud は StarRocks のマネージド SaaS バージョンで、AWS/GCP 上で動作します。韓国では NHN と Kakao の一部チームが StarRocks を自社ホスティングで利用しているとされます。

12. Apache Druid + Imply — リアルタイム OLAP

Apache Druid (druid.apache.org) は2011年に Metamarkets (現 Imply) で作られたリアルタイム OLAP データストアです。中心的特徴は ミリ秒〜秒単位の応答時間でペタバイト級データの集計 です。

Druid の構造。

{
  "type": "kafka",
  "ioConfig": {
    "topic": "user-events",
    "consumerProperties": {
      "bootstrap.servers": "kafka:9092"
    },
    "taskCount": 4,
    "replicas": 1,
    "useEarliestOffset": false
  },
  "dataSchema": {
    "dataSource": "events",
    "timestampSpec": { "column": "event_time", "format": "iso" },
    "dimensionsSpec": {
      "dimensions": ["user_id", "event_type", "country"]
    },
    "metricsSpec": [
      { "type": "count", "name": "events" },
      { "type": "longSum", "name": "amount_sum", "fieldName": "amount" }
    ],
    "granularitySpec": {
      "segmentGranularity": "HOUR",
      "queryGranularity": "MINUTE"
    }
  }
}

Imply (imply.io) は Druid の商用マネージドサービスで、Polaris (SaaS)、Hybrid (自社クラウド)、Enterprise (自社ホスティング) の3形態で提供されます。Twitch、Lyft、Wikimedia、Confluent が Druid 上でリアルタイムダッシュボードを運用しています。

13. Apache Pinot + StarTree — ユーザー直接公開分析

Apache Pinot (pinot.apache.org) は2014年に LinkedIn で作られたリアルタイム OLAP データストアで、2018年に Apache インキュベーション入り、2021年に TLP (Top-Level Project) を卒業しました。2019年に Apache Druid のコア開発者が合流して StarTree を創業しました。

Pinot の差別化要素は user-facing analytics への特化 — つまりエンドユーザーが直接見るダッシュボード、ゲームのリーダーボード、レコメンドフィードなどで100ms 未満の応答を保証します。LinkedIn Feed の "Who viewed your profile"、Uber Eats の注文リアルタイムボードが代表例です。

中心技術。

StarTree Cloud は Pinot のマネージド SaaS で、複数クラスタ・自動スケーリング・セグメントライフサイクルを管理します。

14. Vertica · Greenplum · Yellowbrick — レガシー・ハイブリッド DW

これらは新規導入を推奨される対象ではありませんが、マイグレーションコンサルティング市場は活発です。Snowflake と Databricks の両社が「Vertica/Teradata からこちらへ移行を」マイグレーションインセンティブプログラムを運用しています。

15. モダンオープンテーブルフォーマット — Iceberg vs Delta vs Hudi

2026年最大の変化は オープンテーブルフォーマットの標準化 です。3つが競合します。

フォーマット出自強み弱み
Apache IcebergNetflix、2018年に Apache へ寄贈広範なエンジンサポート、スキーマ進化、time travel、hidden partitioningUPDATE/MERGE 性能が Delta より弱い (改善中)
Delta LakeDatabricks、2019年オープンソースPhoton など Databricks エンジンとの深い統合、ACID、MERGE 性能が優秀外部エンジンサポートが Iceberg より少ない (delta-rs で改善中)
Apache HudiUber、2016年オープンソースupsert/CDC が最強、多様なインデックス概念が複雑 (Copy-on-Write vs Merge-on-Read)、学習コストが高い

2024年から市場は Iceberg へ急速に標準化されています。AWS、Google、Snowflake、Salesforce、Tabular、Confluent がいずれも Iceberg を一級サポートします。Databricks は2024年に Tabular (Iceberg 創業者が作った会社) を $2B で買収し、Delta と Iceberg の両方をサポートする戦略へ転換しました。

-- 同じ Iceberg テーブルを複数エンジンから (同じデータ)
-- 1) Snowflake
CREATE OR REPLACE EXTERNAL VOLUME my_vol ...;
CREATE ICEBERG TABLE orders
  EXTERNAL_VOLUME = my_vol
  CATALOG = 'snowflake_polaris'
  BASE_LOCATION = 'orders/';

-- 2) Spark
spark.sql("""
  CREATE TABLE polaris.production.orders (
    order_id BIGINT, amount DECIMAL(18,2), order_date DATE
  )
  USING iceberg
  PARTITIONED BY (days(order_date))
""")

-- 3) Trino
CREATE TABLE polaris.production.orders (
  order_id BIGINT, amount DECIMAL(18,2), order_date DATE
)
WITH (
  partitioning = ARRAY['day(order_date)'],
  format = 'PARQUET'
);

-- 4) DuckDB
INSTALL iceberg; LOAD iceberg;
SELECT * FROM iceberg_scan('s3://my-bucket/orders/');

16. オープンカタログ — Polaris · Lakekeeper · Unity · Gravitino

テーブルフォーマットが標準化されると、次の前線は メタデータカタログ (Catalog) です。カタログは「どのテーブルがどこにあり誰が権限を持つか」を管理します。

2026年の市場は Polaris vs Unity Catalog の2陣営に絞られる傾向です。Polaris は Iceberg 標準に忠実、Unity は Iceberg + Delta の両方 + より広いアセット管理 (ノートブック・モデル) を強調します。

17. ロックインマトリクス — 誰が最も縛られるか

エンジン別のロックイン度合いを整理すると以下の通りです。

エンジンデータロックインコンピュートロックインマイグレーション難度主因
BigQuery非常に高い非常に高い非常に困難Capacitor フォーマット、GCP 専用
Redshift (Dense)高高困難独自カラムフォーマット、AWS 専用
Redshift Spectrum + RA3中中普通S3 外部テーブル可能
Snowflake中中普通FDN フォーマットだが Iceberg 外部テーブル対応
Snowflake + Iceberg低低容易外部 Iceberg を公式サポート
Databricks + Delta低低容易Delta はオープン、Unity Catalog もオープン
ClickHouse Cloud低中普通OSS 自社ホスティング可能
StarRocks / Doris非常に低い低容易OSS、外部カタログ対応
Trino + Iceberg非常に低い非常に低い非常に容易両者とも OSS、データはそのまま

重要な洞察: データが Iceberg/Delta のようなオープンフォーマットにあれば、コンピュートロックインはほぼ0です。本気でロックインを避けたければ、どの DW を使うにしても「データは外部のオープンフォーマットに」という原則を守りましょう。

18. 価格モデル比較 — Credit · Slot · DBU · RPU

各エンジンの価格単位はすべて異なります。

エンジン単位価格 (2026年5月)備考
SnowflakeCredit$2-$4 per creditXS = 1 credit/hr、サイズごとに2倍
BigQuery on-demandTB scanned$5 per TBus リージョン、最初の1TB は月無料
BigQuery EditionsSlot-hour$0.04-$0.10 per slot-hourStandard/Enterprise/Enterprise Plus
Databricks DB SQLDBU$0.22-$0.55 per DBU+ クラウドコンピュート別途
Redshift ServerlessRPU-hour$0.36 per RPU-hour最小ベース RPU あり
Redshift RA3時間あたりノード$3.26-$13.04 per node-hourra3.xlplus 〜 ra3.16xlarge
Azure Synapse DedicatedDWU$1.20 per 100 DWU/hrGen2 基準
Synapse ServerlessTB scanned$5 per TBBigQuery と同じ
FireboltF-credit$1-$3 per F-creditエンジンサイズで変動
ClickHouse CloudCompute-min + storage$0.31/hr からdev tier
MotherDuck使用量ベース月 $15-$25 からpersonal/team/scale

価格比較の罠: 「TB あたり $5」のような表面価格を見ただけでは実際のコストはわかりません。クラスタリング/パーティショニング/キャッシュヒット率/idle 時間によって同じワークロードが10倍違う請求になり得ます。実 PoC を同じデータ・同じクエリで回すのが唯一の正解です。

19. コスト最適化 — Materialized Views, Clustering, Auto-Suspend

DW コストを30-70%削減する7つのパターン。

1) Auto-suspend / Auto-resume: Snowflake はアイドル1分以上で自動停止が標準。夜間 idle を遮断するだけでコストが60%下がるケースが頻繁にあります。

2) Materialized Views: よく使う集計を事前計算して保存。Snowflake は自動更新、BigQuery は別途更新ポリシーを指定。

3) Clustering Keys / Partitioning: Snowflake の cluster key、BigQuery の partition + cluster column。クエリが stat 経由で不要なパーティションをスキップすればスキャンコストが1/10まで下がります。

-- Snowflake clustering key
ALTER TABLE orders CLUSTER BY (order_date, region);

-- BigQuery partitioning + clustering
CREATE TABLE orders_p (
  order_id INT64, customer_id INT64, region STRING, amount NUMERIC, order_date DATE
)
PARTITION BY order_date
CLUSTER BY region, customer_id;

4) Result Caching: Snowflake は同じクエリ結果を24時間キャッシュ (テーブル変更がなければ)。BigQuery も24時間キャッシュ。キャッシュヒットはコスト0です。

5) Column Pruning + Predicate Pushdown: SELECT * は厳禁。必要なカラムのみ明示します。

6) 適切なウェアハウスサイジング: Snowflake で XL を24時間つけっぱなしより、4XL を1時間だけつけるほうが同じ64 credit ですが応答時間は16倍速いです。速く短くがほぼ常に正解。

7) Reserved Capacity / Slot Commitment: BigQuery slot commitment、Redshift Reserved Instances は1-3年契約で40-65%割引。安定ワークロードに有利。

20. AI 統合 — Cortex · AI Functions · Gemini · Bedrock

2025-2026年の DW トレンドは SQL から直接 LLM を呼ぶ ことです。

Snowflake Cortex (SNOWFLAKE.CORTEX.*):

SELECT
  customer_id,
  review_text,
  SNOWFLAKE.CORTEX.SENTIMENT(review_text) AS sentiment_score,
  SNOWFLAKE.CORTEX.SUMMARIZE(review_text) AS summary,
  SNOWFLAKE.CORTEX.COMPLETE(
    'claude-3-5-sonnet',
    'Suggest a follow-up email: ' || review_text
  ) AS followup
FROM product_reviews
WHERE review_date > current_date - 30;

Cortex は Mistral、Llama、Reka、Claude を組み込み関数のように呼べます。credit ベース課金で、データは Snowflake の外に出ません。

Databricks AI Functions:

SELECT
  customer_id,
  AI_SUMMARIZE(notes) AS summary,
  AI_CLASSIFY(notes, ARRAY('billing', 'support', 'sales')) AS category,
  AI_EXTRACT(notes, ARRAY('date', 'amount', 'product')) AS extracted
FROM customer_notes;

BigQuery + Gemini (ML.GENERATE_TEXT):

SELECT
  product_id,
  description,
  ml_generate_text_result['predictions'][0]['content'] AS marketing_copy
FROM ML.GENERATE_TEXT(
  MODEL `mydataset.gemini_pro_model`,
  TABLE `mydataset.products`,
  STRUCT(
    0.4 AS temperature,
    200 AS max_output_tokens,
    'Write a marketing tagline for this product: ' || description AS prompt
  )
);

Redshift + Bedrock:

SELECT
  feedback_id,
  feedback_text,
  AWS.BEDROCK.INVOKE_MODEL(
    'anthropic.claude-sonnet-20240229-v1:0',
    JSON_OBJECT('prompt' VALUE 'Analyze: ' || feedback_text)
  ) AS analysis
FROM customer_feedback
WHERE submitted_at >= current_date - 7;

DW から直接 LLM を呼ぶとデータ移動がなく、セキュリティ・コンプライアンスが単純化されますが、トークンコストが急速に累積するためモニタリング必須です。100万行に Claude Sonnet を1回ずつ呼ぶと、1回あたり平均1,000トークンとしても100万行 × $0.003/1K の入出力で数千ドルが1クエリで請求されます。

21. Reverse ETL · データオブザーバビリティ · カタログガバナンス

DW を導入したら、その周辺生態系も一緒についてきます。

データオブザーバビリティツールは DW のメタデータ (query log, table stat) を受け取り、自動で anomaly を検出します。例: 「昨日まで毎日1億行が入っていたテーブルが今日500万行しか入らなかった — アラート」。Monte Carlo はこのカテゴリを最初に定義した会社で、2024年に評価額 $2.4B を受けました。

22. 韓国企業の事例 — クーパン · Naver · NCsoft · Kakao

クーパン (Coupang): 2025年のクーパンエンジニアリングブログによれば、クーパンはデータプラットフォームを Spark + Snowflake + 自社データカタログの組み合わせで運用しています。商品・注文・決済のような中核ドメインは Snowflake に取り込み、ログ・イベント分析は自社の ClickHouse クラスタを使います。マーケティング ML 学習は Databricks Lakehouse 上で行い、Reverse ETL は Hightouch 経由で広告プラットフォームへ戻します。日処理量はペタバイト級で、BigQuery → Snowflake のマイグレーションを2023年に完了しています。

Naver Cloud: Naver は自社クラウド (NCP) 上で自社 DW と Trino ベースの自社クエリエンジンを運用します。検索ログ・広告クリック分析は自社カラムストア、ビジネス分析 (ショッピング、Pay) は Snowflake on AWS Tokyo を使っていると2024年の DEVIEW で共有されました。2025年から自社 LLM HyperCLOVA X を DW と組み合わせた社内 BI ツールを開発中です。

NCsoft: ゲームデータは量と時間敏感度の両方で極端です。NCsoft は Lineage W、Throne and Liberty のリアルタイムログ・イベントを Apache Druid + Imply で処理し、長期保管・分析は Snowflake に取り込みます。2024年 NDC (Nexon Developers Conference) の発表によれば、単一ゲームで日数十億イベントが発生し、Druid の sub-second 応答がライブ運営 (不正検知、売上モニタリング) の要です。

Kakao: Kakao は KakaoTalk、Daum、Pay などの巨大トラフィックサービスのデータ分析を自社 Hadoop + Hive + Trino + 自社データカタログで処理してきました。2024年から Apache Iceberg + Polaris へマイグレーション中で、一部ワークロードは Databricks on AWS Seoul に移したと if(kakao) 2024 で共有されました。

Woowa Brothers (Baemin): 注文・ライダーデータは BigQuery に取り込まれ、広告 ML と推薦は Vertex AI + BigQuery ML の組み合わせで運用されます。2025年から一部リアルタイム分析を ClickHouse Cloud に移したと Woowacon 2024 で発表されました。

23. 日本企業の事例 — メルカリ · LINE ヤフー · サイバーエージェント · 楽天

メルカリ (Mercari): メルカリは GCP の深い採用事例で、BigQuery を中核 DW として運用します。2024年のメルカリエンジニアリングブログによれば、BigQuery 上で日にペタバイト級のスキャンが発生し、dbt + BigQuery Studio + Looker Studio の組み合わせで分析ワークフローを標準化しました。2025年から Gemini + BigQuery ML 統合により自然言語クエリ (NLQ) の社内ツールを開発し、ユーザーにはより精緻な推薦 (パーソナライズ) を提供しています。

LINE ヤフー (LINE Yahoo Japan): 合併前の LINE は Hadoop ベースの自社 DW を運用し、Yahoo Japan は Teradata + 自社分析プラットフォームを使用していました。合併後の2024年から統合データプラットフォームとして BigQuery + Iceberg + Trino を採用したと LINE DEVELOPER DAY 2024 で発表されました。ペタバイト級の Hive 資産を Iceberg へマイグレーションしつつ、BigLake 外部テーブルで BigQuery からも照会可能にしました。

サイバーエージェント (CyberAgent): AbemaTV (現 ABEMA)、広告事業のデータを Snowflake on AWS Tokyo で統合運用します。2025年 CyberAgent Developers Conference の発表によれば、広告入札ログ (日数十億件) は BigQuery、ビジネス分析は Snowflake、リアルタイムアトリビューションは ClickHouse の組み合わせで多重エンジン戦略を展開しています。dbt + Airflow + Datadog ですべてのパイプラインを観測。

楽天 (Rakuten): 楽天は早期から Treasure Data (treasuredata.com) を採用し、2020年代に入ってから Snowflake へワークロードを段階的に移行中です。Treasure Data は Hive ベースのマネージド CDP で、Snowflake に移った中心理由は ML ワークロード統合とコスト予測可能性です。2025年 Rakuten Tech Conference の発表によれば、楽天ショッピング・証券・モバイルのデータがすべて Snowflake の単一アカウント内でガバナンスされます。

DeNA: ゲーム・ヘルスケアデータに BigQuery、ML ワークロードに Vertex AI を使用し、Pokémon GO 運営の Niantic との協業データも BigQuery に統合。2024年から Apache Iceberg を採用してロックイン分散戦略を始めたと DeNA TechCon 2024 で発表されました。

24. 意思決定チェックリスト — どう選ぶか

DW 選択はほぼ常に「チーム + データ形態 + 予算 + ロックイン許容度」の関数です。

チームが SQL 中心で、分析がメイン → Snowflake。最も滑らかな SQL UX、最大の生態系。

チームに ML エンジニアとデータサイエンティストが一緒におり、Spark/Python ワークロードが大きい → Databricks Lakehouse。SQL + Spark + ML が一つのプラットフォーム。

GCP 中心インフラ、小さなワークロードも頻繁に回す PMF 前のスタートアップ → BigQuery on-demand。初期に0から始められ、BQML で ML 無料学習。

AWS 中心インフラ、既存 Redshift を運用中 → Redshift Serverless へ移行。Zero-ETL と Bedrock 統合が強み。

Microsoft 365 / Power BI 中心エンタープライズ → Microsoft Fabric (または Synapse)。強い ID/アクセス統合。

リアルタイムでユーザーに直接見せる分析が中核 → Apache Pinot (StarTree) または Apache Druid (Imply)。

数十億行ログ分析、速い応答が中核 → ClickHouse Cloud。

100TB 以下、1-10人チーム、コスト最小化が一番 → MotherDuck (または DuckDB + S3 + dbt)。

ロックイン回避が一番の原則 → Trino + Apache Iceberg + Polaris (自社ホスティングまたは Starburst Galaxy)。

ほとんどの会社は最終的に マルチエンジン戦略 (Multi-engine) へ向かいます。Snowflake で一般分析、ClickHouse でリアルタイム、BigQuery で広告、そして同じデータを Iceberg に置く形です。2026年のベストプラクティスは「データは Iceberg、エンジンはワークロードごと」です。

25. 参考文献 / References

コメント

まだコメントはありません。

ログインするとコメントできます