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

"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世代は 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層構成です。

• Storage: S3/Azure Blob/GCS 上の micro-partition (平均50-500MB) として圧縮されたカラムデータ。独自フォーマット (FDN, columnar) ですが、2025年から Iceberg 外部テーブルも一級市民として対応
• Compute (Virtual Warehouse): 仮想コンピュートクラスタ。サイズは XS/S/M/L/XL/2XL/3XL/4XL/5XL/6XL、秒単位課金
• Cloud Services: メタデータ、クエリオプティマイザ、トランザクション、セキュリティ — ユーザーには見えないコントロールプレーン

-- 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 で発表された主要な変更点。

• Apache Iceberg ネイティブテーブル: Snowflake が Iceberg メタデータを直接書き、外部エンジン (Trino, Spark) が同じデータを読む。ロックイン懸念解消の決定打
• Dynamic Tables: 宣言的 ETL — CREATE DYNAMIC TABLE で定義すると Snowflake が増分自動更新
• Snowpark Container Services: コンテナを Snowflake 内部で実行し、Python/R/Java ワークロードをデータの隣で
• Snowflake Cortex: 組み込み LLM API (SNOWFLAKE.CORTEX.COMPLETE, SUMMARIZE, TRANSLATE) — Mistral, Llama, Reka, Anthropic Claude を直接呼び出し
• Snowflake Polaris (オープンソースカタログ, 2024年 Apache 財団へ寄贈) — REST API 標準 Iceberg カタログ

価格は 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 ワークロード市場に参入しました。主要コンポーネント。

• Delta Lake: データレイク上の ACID トランザクション・スキーマ進化・time-travel をサポートするテーブルフォーマット。2019年オープンソース化、Linux Foundation 配下
• Photon Engine: C++ で書き直したベクトル化クエリエンジン。Spark API 互換、平均3-12倍高速
• Databricks SQL (DB SQL): BI ワークロード専用 SQL ウェアハウス。Photon + 自動スケーリング
• Unity Catalog: 統合ガバナンスカタログ。テーブル・ビュー・ノートブック・ML モデル・LLM をすべて一箇所で権限管理。2024年オープンソース化
• Mosaic AI: ML/AI ワークロードプラットフォーム。Vector Search、Model Serving、AI Functions
• DBRX: Databricks が2024年3月に公開した自社製132B MoE LLM。Apache 2.0 ライセンス

-- 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 主要コンポーネント。

• Dremel: カラムストレージ上の分散クエリエンジン。tree-based 実行モデル
• Colossus: GFS の後継となる分散ファイルシステム — BigQuery のバックエンドストレージ
• Jupiter: ペタビット級データセンターネットワーク — コンピュートとストレージ間帯域の要
• BigQuery ML (BQML): SQL で ML モデルの学習・予測。CREATE MODEL ... OPTIONS(model_type='linear_reg')
• BigQuery Studio: 2024年 GA。ノートブック・dbt・Looker Studio 統合 IDE
• BigQuery Omni: AWS/Azure のデータを BigQuery エンジンで照会 (multi-cloud)
• BigQuery GIS: 地理データ型と関数 (ST_GEOGFROMTEXT など)

-- 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種類。

• On-demand: スキャンしたデータ1TB あたり $5 (us リージョン基準)。月の最初の1TB は無料。予測しづらいが小規模ワークロードには有利
• Slot-based (Editions): Standard/Enterprise/Enterprise Plus エディション、slot-hour あたり $0.04-$0.10。大規模で安定したワークロードに有利

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 リリース後に再び活気を取り戻しました。

主要コンポーネント。

• RA3 ノード: コンピュートとストレージが分離した新世代ノードタイプ。マネージドストレージ (S3 ベース)、ノード単位 SSD キャッシュ
• Aqua (Advanced Query Accelerator): FPGA ベースハードウェアアクセラレーション。解凍とフィルタリングをノード外で処理
• Concurrency Scaling: 同時クエリ急増時に一時コンピュートを追加 (時間単位の無料時間あり)
• Redshift Spectrum: S3 外部テーブル照会 (Parquet, ORC, Avro)
• Redshift Serverless: 2022年 GA。RPU (Redshift Processing Unit) 単位課金、RPU-hour あたり $0.36
• Zero-ETL: 2023年から Aurora/RDS/DynamoDB から Redshift へ自動レプリケーション (変更データキャプチャ)
• Redshift + Bedrock: 2024年 GA。SQL から直接 Bedrock LLM 呼び出し

-- 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種類のエンジンを一つのワークスペースで統合提供します。

• Dedicated SQL Pool (旧 Azure SQL DW): MPP SQL、DWU (Data Warehouse Unit) 単位プロビジョニング
• Serverless SQL Pool: Azure Data Lake Storage Gen2 の Parquet/CSV/JSON を T-SQL で照会。スキャン1TB あたり $5
• Spark Pool: Synapse Spark、.NET for Spark 対応
• Data Explorer Pool (Kusto): KQL (Kusto Query Language) ベースのログ・時系列分析
• Synapse Link: Cosmos DB、Dataverse、SQL DB のデータを ETL なしで分析 (HTAP パターン)

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 は以下を追加で持ちます。

• Sparse Index: カラム単位の sparse インデックスで正確な行位置を特定
• Aggregate Indexes: 事前集計インデックス、materialized view より軽量
• Result + Sub-result Cache: クエリ結果だけでなく中間結果もキャッシュ
• F3 Engine: 独自カラムフォーマット (F3)、Parquet より小さなサイズ
• SSD Direct Cache: F3 データをコンピュートノードの NVMe SSD にキャッシュ

-- 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) です。

• 小さなデータ・インタラクティブクエリはユーザーのノートパソコン上で DuckDB が直接実行
• 大きなデータ・複雑なクエリはクラウド (MotherDuck サーバー) で実行
• 同じ SQL、同じ SDK で2つのモードを自動ルーティング

# 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 の威力は以下のシナリオで圧倒的です。

• ノートブックで 10GB Parquet を分析: pandas 比10-100倍高速
• CI/CD でのデータ検証: dbt + DuckDB で PR 単位データテスト
• ML 前処理: PyTorch DataLoader の前段でウィンドウ集計
• MotherDuck/Definite のバックエンド: クラウド DW のローカルエンジン

# 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: shared-data アーキテクチャ (コンピュート/ストレージ分離)、Iceberg/Hudi/Delta 外部カタログを一級市民として
• Doris: MySQL 互換プロトコル + ANSI SQL、materialized view + rollup 自動化

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 の構造。

• Real-time Indexer: Kafka/Kinesis からストリーミング取り込み、即座に照会可能
• Historical Node: 古いデータを保管、S3/HDFS ベース
• Broker Node: クエリルーティングと結果マージ
• Coordinator: セグメント配置管理

{
  "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 の注文リアルタイムボードが代表例です。

中心技術。

• Star-tree Index: 事前集計インデックス。SUM、COUNT を事前計算してクエリ時間を短縮
• Real-time + Offline Hybrid: Kafka 取り込み + S3 バッチを一つのテーブルで
• Multi-stage Query Engine: 2023年から複雑な JOIN をサポート

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

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

• Vertica (vertica.com): 2005年に Michael Stonebraker が創業、2011年に HP が買収、2017年に Micro Focus、2023年に OpenText に再売却。いまだ一部の金融・通信業界で利用。カラムストア MPP の原型の一つ
• Greenplum (greenplum.org): Postgres ベース MPP、2010年に EMC 買収、2020年に Pivotal 譲渡 (その後 VMware Tanzu Data)、2023年に Broadcom。2026年現在オープンソースとして維持されているが本格的な新規導入はほぼなし
• Yellowbrick (yellowbrick.com): 2014年創業、アプライアンス + クラウドハイブリッド DW。Kubernetes ベースコンテナデプロイが特徴
• Netezza: IBM に買収され、Cloud Pak for Data Netezza Performance Server として残存

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

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

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

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) です。カタログは「どのテーブルがどこにあり誰が権限を持つか」を管理します。

• Apache Polaris (polaris.apache.org): Snowflake が2024年6月にオープンソース化し Apache 財団へ寄贈。REST API 標準 Iceberg カタログ。Snowflake、Trino、Spark、Flink、Dremio がいずれもサポート
• Lakekeeper (lakekeeper.io): ドイツ発の Rust ベース Iceberg REST カタログ。軽量で高速。自社ホスティングに優しい
• Apache Gravitino (gravitino.apache.org): 中国の Datastrato が作った多メタデータカタログ。Iceberg + Hive + リレーショナル DB まで統合
• Unity Catalog (unitycatalog.io): Databricks が2024年6月にオープンソース化。テーブル・ビュー・ノートブック・ML モデル・LLM トークンまで統合管理
• AWS Glue Data Catalog: AWS のマネージドカタログ。Athena、EMR、Redshift Spectrum のデフォルトバックエンド
• Nessie (projectnessie.org): Dremio が主導する Git-style カタログ。branch/merge/tag でデータバージョニング

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

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

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

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

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

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

価格比較の罠: 「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 を導入したら、その周辺生態系も一緒についてきます。

• Reverse ETL: DW のデータを Salesforce、HubSpot、Iterable のような SaaS へ戻します。Hightouch (hightouch.com)、Census (getcensus.com) が2強で、いずれも Snowflake/BigQuery/Databricks を一級ソースとしてサポート
• データオブザーバビリティ: データ品質・鮮度・系譜 (lineage) を監視。Monte Carlo (montecarlodata.com)、Anomalo (anomalo.com)、Bigeye (bigeye.com)、Datafold (datafold.com)、Metaplane (metaplane.com) が主要プレーヤー
• カタログ・ガバナンス: データ資産検索・ドキュメント化・アクセス管理。Atlan (atlan.com)、Castor (castordoc.com)、Data.world (data.world)、Alation (alation.com)、Collibra (collibra.com)、Apache Atlas (atlas.apache.org)

データオブザーバビリティツールは 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

• Snowflake documentation — https://docs.snowflake.com/
• Snowflake Cortex AI — https://docs.snowflake.com/en/guides-overview-ai-features
• Apache Polaris — https://polaris.apache.org/
• Databricks documentation — https://docs.databricks.com/
• Databricks Lakehouse Architecture — https://www.databricks.com/glossary/data-lakehouse
• Delta Lake — https://delta.io/
• Unity Catalog (OSS) — https://www.unitycatalog.io/
• Apache Spark — https://spark.apache.org/
• DBRX model — https://www.databricks.com/blog/introducing-dbrx-new-state-art-open-llm
• Google BigQuery documentation — https://cloud.google.com/bigquery/docs
• BigQuery ML — https://cloud.google.com/bigquery/docs/bqml-introduction
• BigQuery Omni — https://cloud.google.com/bigquery/docs/omni-introduction
• AWS Redshift documentation — https://docs.aws.amazon.com/redshift/
• Redshift Serverless — https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-whatis.html
• Azure Synapse Analytics — https://learn.microsoft.com/en-us/azure/synapse-analytics/
• Microsoft Fabric — https://learn.microsoft.com/en-us/fabric/
• Firebolt documentation — https://docs.firebolt.io/
• MotherDuck — https://motherduck.com/docs/
• DuckDB — https://duckdb.org/docs/
• ClickHouse — https://clickhouse.com/docs
• StarRocks — https://docs.starrocks.io/
• Apache Doris — https://doris.apache.org/docs/
• Apache Druid — https://druid.apache.org/docs/latest/
• Apache Pinot — https://docs.pinot.apache.org/
• StarTree — https://startree.ai/
• Apache Iceberg — https://iceberg.apache.org/
• Apache Hudi — https://hudi.apache.org/docs/overview
• Lakekeeper — https://lakekeeper.io/
• Apache Gravitino — https://gravitino.apache.org/
• Project Nessie — https://projectnessie.org/
• Trino — https://trino.io/docs/current/
• Starburst Galaxy — https://www.starburst.io/platform/starburst-galaxy/
• dbt documentation — https://docs.getdbt.com/
• Hightouch — https://hightouch.com/docs
• Census — https://docs.getcensus.com/
• Monte Carlo Data — https://www.montecarlodata.com/
• Atlan — https://atlan.com/
• Coupang Engineering Blog — https://medium.com/coupang-engineering
• Naver DEVIEW archive — https://deview.kr/
• LINE DEVELOPER DAY — https://linedevday.linecorp.com/
• Mercari Engineering Blog — https://engineering.mercari.com/
• CyberAgent Developers Blog — https://developers.cyberagent.co.jp/blog/
• Rakuten Tech Conference — https://tech.rakuten.com/