💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "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 Exadata | Shared-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層構成です。

- **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 の例 — ローカル + クラウド結合

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 を一つのクエリに

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. ロックインマトリクス — 誰が最も縛られるか

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

|---|---|---|---|---|

| Redshift (Dense) | 高 | 高 | 困難 | 独自カラムフォーマット、AWS 専用 |

| Redshift Spectrum + RA3 | 中 | 中 | 普通 | S3 外部テーブル可能 |

| Snowflake | 中 | 中 | 普通 | FDN フォーマットだが Iceberg 外部テーブル対応 |

| Snowflake + Iceberg | 低 | 低 | 容易 | 外部 Iceberg を公式サポート |

| Databricks + Delta | 低 | 低 | 容易 | Delta はオープン、Unity Catalog もオープン |

| ClickHouse Cloud | 低 | 中 | 普通 | OSS 自社ホスティング可能 |

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

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

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

| エンジン | 単位 | 価格 (2026年5月) | 備考 |

|---|---|---|---|

**価格比較の罠**: 「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/`