필사 모드: OLAP エンジン 2025 比較ガイド: DuckDB・ClickHouse・Snowflake・StarRocks・Pinot・Druid・Trino、ベンチマークの罠、エンジン配置 (2025)

Season 5 Ep 3 — Ep 1 がストレージ、Ep 2 が流れだったとすれば、Ep 3 はクエリ。「1つのエンジンがすべてをこなす」時代は終わり、エンジン配置（Engine placement）が新しい設計領域になった。

• Prologue — 「エンジンは道具、問題はワークロード」
• 第1章 · OLAP エンジンの分類
  • 1.1 4つの軸
  • 1.2 主要エンジンの分類
• 第2章 · DuckDB — 「シングルノード OLAP の革命」
  • 2.1 アイデンティティ
  • 2.2 強み
  • 2.3 2024–2025 のモメンタム
  • 2.4 制限
  • 2.5 使いどころ
• 第3章 · ClickHouse — 「リアルタイム OLAP の王」
  • 3.1 アイデンティティ
  • 3.2 強み
  • 3.3 2024–2025 の動向
  • 3.4 制限
  • 3.5 使いどころ
• 第4章 · Snowflake・BigQuery — 「マネージドの巨人」
  • 4.1 Snowflake
  • 4.2 BigQuery
  • 4.3 強み
  • 4.4 制限
  • 4.5 2025年の戦略
• 第5章 · StarRocks・Doris — 「MPP リアルタイム BI」
  • 5.1 共通点
  • 5.2 StarRocks
  • 5.3 Apache Doris
  • 5.4 強み
  • 5.5 使いどころ
• 第6章 · Apache Pinot・Druid — 「超低レイテンシ OLAP」
  • 6.1 Apache Pinot
  • 6.2 Apache Druid
  • 6.3 使いどころ
  • 6.4 運用の難易度
  • 6.5 ClickHouse・StarRocks との違い
• 第7章 · Trino・Presto — 「連合クエリ（Federated Query）」
  • 7.1 アイデンティティ
  • 7.2 強み
  • 7.3 Starburst
  • 7.4 制限
  • 7.5 Presto vs Trino
• 第8章 · Databricks SQL・Redshift
  • 8.1 Databricks SQL
  • 8.2 Redshift
  • 8.3 使いどころ
  • 8.4 2025年の戦略
• 第9章 · ベンチマークの罠
  • 9.1 TPC-H・TPC-DS
  • 9.2 ClickBench
  • 9.3 StarSchema・JOB
  • 9.4 実戦的な評価プロトコル
  • 9.5 「価格性能比」こそが真の指標
• 第10章 · エンジン配置（Engine Placement）のパターン
  • 10.1 「1つのエンジン」アンチパターン
  • 10.2 「2–4 エンジン」という現実的なパターン
  • 10.3 データ共有
• 第11章 · 韓国企業向けの選定ガイド
  • 11.1 現状
  • 11.2 韓国固有の事情
  • 11.3 実務推奨マトリクス
• 第12章 · 性能チューニングの汎用原則
  • 12.1 スキーマ設計
  • 12.2 パーティション・ソート
  • 12.3 インデックス・投影（Projection）
  • 12.4 キャッシュ
  • 12.5 Materialized view
• 第13章 · アンチパターン10選
  • 13.1 「1つのエンジンですべてを」
  • 13.2 ベンチマークだけを見て選ぶ
  • 13.3 プロダクション負荷なしで PoC を承認
  • 13.4 スタースキーマの無視
  • 13.5 パーティションの過剰
  • 13.6 Materialized view の管理不在
  • 13.7 運用オンコールの準備なしでセルフホスティング
  • 13.8 ロックインを無視して SaaS にオールイン
  • 13.9 クエリチューニングなしでスケールアップ
  • 13.10 ユーザークォータ・ガードレールの不在
• 第14章 · チェックリスト — OLAP エンジン導入前の12項目
• 第15章 · 次回予告 — Season 5 Ep 4:「dbt・SQLMesh・Dagster・Airflow・Prefect」

Prologue — 「エンジンは道具、問題はワークロード」

2015–2020 の OLAP 論争は「どのエンジンが最も速いか」だった。2025年は違う:

• ベンチマークはマーケティングツールだ（TPC-H・TPC-DS の解釈は条件付き）
• エンジンごとに特定のワークロードで圧倒的な強みがある
• 1社が 2–4 個のエンジンを使うのが一般的だ
• 「適材適所の配置」がコスト・性能・チーム能力のすべてを決める

この記事では、2025年の主要 OLAP エンジンの現実的な長所と短所、そして配置戦略を整理する。

---

第1章 · OLAP エンジンの分類

1.1 4つの軸

• デプロイ: シングルノード / 分散 MPP / サーバーレス
• ワークロード: BI（複雑な JOIN）/ Real-time（低レイテンシ）/ Ad-hoc（探索）
• マネージド vs セルフ: SaaS / オープンソース + セルフ運用
• データの所在: 内蔵ストレージ / Lakehouse 連携

1.2 主要エンジンの分類

---

第2章 · DuckDB — 「シングルノード OLAP の革命」

2.1 アイデンティティ

• 2019年に CWI で開始
• Embedded OLAP: SQLite が OLTP をノート PC に持ち込んだように、DuckDB は OLAP をノート PC に
• Parquet/CSV/JSON を直接クエリ、Iceberg・Delta の読み取り拡張

2.2 強み

• インストール 5秒、単一バイナリ
• Python/R/Node/Go/Rust バインディング
• 8–16GB の RAM で数十億行の分析が可能（カラムナ + ベクトル化）
• Parquet を「ネイティブ SQL で」クエリ

2.3 2024–2025 のモメンタム

• MotherDuck: DuckDB のクラウド拡張
• Iceberg・Delta 読み取りサポートの正式化
• DuckDB WASM によるブラウザ内 OLAP
• dbt-duckdb でローカル開発・CI の標準に

2.4 制限

• シングルノード（垂直スケール限定）
• 同時実行はアプリ内レベル
• 大規模サーバークラスタの代替ではない

2.5 使いどころ

• アナリストのローカル開発
• CI でのデータ検証
• 中小規模プロジェクトの OLAP バックエンド
• Notebook/Python スクリプトの SQL エンジン

---

第3章 · ClickHouse — 「リアルタイム OLAP の王」

3.1 アイデンティティ

• 2009年 Yandex 社内 → 2016年オープンソース化 → 2021年 ClickHouse Inc.
• 分散カラムナ、MergeTree エンジンがベース
• リアルタイムで数十億行を挿入 + 秒単位のクエリ

3.2 強み

• 圧倒的な挿入・クエリ性能（特定のワークロードで）
• リアルタイムダッシュボードの事実上の標準
• Kafka/Kinesis Engine で直接コンシューマに
• コスト効率（自前運用時）

3.3 2024–2025 の動向

• ClickHouse Cloud（SaaS）が急成長
• Iceberg 読み取りの拡大
• Materialized view・Dictionary の高度化
• 多くのオブザーバビリティプラットフォーム（Datadog の一部、Axiom、Tinybird、PostHog）が ClickHouse ベース

3.4 制限

• JOIN の最適化が一部のエンジンに比べて弱い（最近大きく改善）
• 運用が複雑（セルフ運用時）
• SQL 互換性に一部の差異

3.5 使いどころ

• ログ・イベント分析
• リアルタイムダッシュボード
• Ads/Marketing analytics
• APM/Observability バックエンド

---

第4章 · Snowflake・BigQuery — 「マネージドの巨人」

4.1 Snowflake

• サーバーレス、コンピュートとストレージの分離
• Multi-cluster warehouse（自動スケール）
• Native Iceberg table（2024年）
• Cortex AI（LLM・ML 機能の統合）
• データ共有（Data Sharing）

4.2 BigQuery

• Google Cloud のサーバーレス
• Slot ベースのコンピュート、高速な ad-hoc
• Iceberg External + BigLake
• Gemini 統合（クエリ SQL の自然言語化）
• BI Engine（in-memory 高速化）

4.3 強み

• 運用負担ゼロ
• 初期セットアップは数日
• セキュリティ・監査・バックアップを内蔵
• 大企業・エンタープライズで圧倒的なシェア

4.4 制限

• コスト: 規模が大きくなると月に数万〜数十万ドル
• ロックイン（Iceberg サポートで緩和中）
• 一部のワークロード（超低レイテンシ）には不向き

4.5 2025年の戦略

• Iceberg External Table で Lake の外部データをクエリ
• Hot/Cold の分離: Hot はネイティブ、Cold は Iceberg
• dbt・Airflow・Dagster との統合が標準

---

第5章 · StarRocks・Doris — 「MPP リアルタイム BI」

5.1 共通点

• リアルタイム + BI + Lakehouse サポート
• Iceberg/Hudi/Delta の読み取り
• MySQL プロトコル互換（BI フレンドリー）
• 中国発、グローバルに拡大

5.2 StarRocks

• Apache DorisDB のフォーク → 独立
• CelerData が商用サポート
• 2024–2025 に急成長
• Cost-based optimizer が成熟

5.3 Apache Doris

• Apache 財団のプロジェクト
• Baidu 発
• Routine Load（Kafka 直結）
• リアルタイムダッシュボードに強い

5.4 強み

• リアルタイムと複雑な JOIN の両方に強い
• Lakehouse + 自前ストレージの二重運用
• ClickHouse に比べて JOIN で優位

5.5 使いどころ

• リアルタイムの運用 BI
• Lakehouse エンジンの補完
• 中国・韓国・日本で採用が増加

---

第6章 · Apache Pinot・Druid — 「超低レイテンシ OLAP」

6.1 Apache Pinot

• LinkedIn 発 → Apache
• 100ms 未満のクエリレイテンシを目標
• Upsert サポート（2023年〜）
• StarTree（SaaS）を提供

6.2 Apache Druid

• Metamarkets 発 → Imply が商用化
• 時系列・ストリームに特化
• Kafka indexing service

6.3 使いどころ

• LinkedIn、Uber、Netflix などの超低レイテンシ分析
• ユーザー対面のダッシュボード（Customer-facing）
• リアルタイムのレコメンド・異常検知

6.4 運用の難易度

• セットアップが複雑、運用エンジニアが必要
• SaaS（StarTree/Imply）が負担を軽減

6.5 ClickHouse・StarRocks との違い

• Pinot/Druid: 100ms 未満の超低レイテンシに特化
• ClickHouse: 幅広いワークロード + 優れたコストパフォーマンス
• StarRocks: BI の複雑な JOIN + Lakehouse との親和性

---

第7章 · Trino・Presto — 「連合クエリ（Federated Query）」

7.1 アイデンティティ

• Facebook Presto → Trino（2020年フォーク、オリジナル開発者たちによる）
• Iceberg/Delta/Hudi、Hive、MySQL、Postgres、Kafka など数十のコネクタ
• 複数のデータソースを1つの SQL で

7.2 強み

• マルチソース JOIN
• Iceberg の読み書きで最高性能の1つ
• セルフホスティングが可能
• 企業内の「中央クエリエンジン」の役割

7.3 Starburst

• Trino の商用ディストリビューション、エンタープライズ機能とサポート
• Gateway・キャッシュ・セキュリティの統合

7.4 制限

• ダッシュボード用途よりも ad-hoc・ELT に強み
• 運用が複雑（Coordinator・Worker の管理）
• リアルタイム収集よりも読み取り中心

7.5 Presto vs Trino

• Presto: Meta/PrestoDB が維持
• Trino: 事実上のコミュニティ標準
• 2025年の新規案件では Trino を選ぶのが一般的

---

第8章 · Databricks SQL・Redshift

8.1 Databricks SQL

• Delta + Spark ベースの SQL warehouse
• Photon エンジン（ベクトル化）
• 2024年に Iceberg UniForm をサポート
• ML + BI の統合が強み

8.2 Redshift

• AWS の伝統的な DW
• RA3 + AQUA でコンピュートとストレージを分離
• Spectrum で S3 Iceberg にアクセス
• AWS エコシステムとの深い統合

8.3 使いどころ

• Databricks SQL: すでに Databricks を使っているチーム
• Redshift: AWS 中心の企業、SAP・Salesforce との接続

8.4 2025年の戦略

• Databricks: Iceberg 互換 + Mosaic AI
• Redshift: サーバーレス・AI 統合の強化
• どちらもロックイン緩和の方向

---

第9章 · ベンチマークの罠

9.1 TPC-H・TPC-DS

• 業界標準だが実際のワークロードとは異なる
• エンジンベンダーが自らチューニングした結果を宣伝に使う
• クエリプラン・データスケール・同時実行設定が結果を大きく左右する

9.2 ClickBench

• ClickHouse チーム主導（公正性を巡る議論あり）
• ただし多様なエンジンを比較できるオープンなベンチ

9.3 StarSchema・JOB

• 複雑な JOIN のベンチ、実際に近い
• エンジン間の差を明らかにするのに有用

9.4 実戦的な評価プロトコル

1. 自前データのサンプリング（10–100GB）
2. よく使うクエリを 5–15 本
3. 同時実行 10–100 を模擬
4. コスト対性能を計算
5. 運用の複雑さを評価（インフラ・監視・オンコール）

9.5 「価格性能比」こそが真の指標

• 単純な ms 単位よりも $/クエリ または $/TB スキャン
• 同時ユーザー数・待ち時間の SLA も含める

---

第10章 · エンジン配置（Engine Placement）のパターン

10.1 「1つのエンジン」アンチパターン

• Snowflake だけですべてを → 超低レイテンシで失敗、コストが暴騰
• ClickHouse だけですべてを → BI の複雑な JOIN と管理負担
• Trino だけですべてを → リアルタイムが不可能

10.2 「2–4 エンジン」という現実的なパターン

パターン A: Startup（小規模）

• DuckDB: 開発・CI
• Snowflake/BigQuery: プロダクション BI

パターン B: SaaS（リアルタイムダッシュボード中心）

• ClickHouse: プロダクション分析・顧客対面
• DuckDB: ローカル分析
• Snowflake: 社内 BI + ELT

パターン C: Enterprise（大企業）

• Snowflake/Databricks: 全社 BI
• Trino: Lakehouse の連合クエリ
• ClickHouse/Pinot: 特定の高性能アプリ
• DuckDB: アナリストの開発

パターン D: 高性能なユーザー対面

• Pinot/Druid: ミリ秒の UX
• ClickHouse: 管理者ダッシュボード
• BigQuery/Snowflake: 経営・戦略 BI

10.3 データ共有

• 元データは Iceberg に集約
• 各エンジンが Iceberg を読み、必要に応じて自前ストレージへ複製
• メタデータカタログは共通（Polaris/Unity/Glue）

---

第11章 · 韓国企業向けの選定ガイド

11.1 現状

• 金融・公共: Teradata/Oracle + Hadoop → Snowflake/Databricks へ移行中
• コマース・ゲーム: ClickHouse + BigQuery・Snowflake が混在
• スタートアップ: DuckDB + Snowflake/BigQuery が急増

11.2 韓国固有の事情

• 網分離の要件: オンプレのエンジン（ClickHouse・StarRocks・Trino）が好まれる
• 韓国語 SQL ツールの互換性（Metabase・Redash・Superset などの韓国語画面）
• 大容量ログ・ゲーム分析: ClickHouse がコストパフォーマンスで優位
• 金融 BI: Snowflake・Databricks の採用が急増

11.3 実務推奨マトリクス

---

第12章 · 性能チューニングの汎用原則

12.1 スキーマ設計

• Star schema（Fact + Dim）は依然として強力
• Denormalization の水準をエンジン・ワークロードごとに調整
• カラム型の最適化（Int32 vs Int64 など）

12.2 パーティション・ソート

• 時間パーティションが基本
• Sort key は WHERE・JOIN のパターンに基づく
• ClickHouse: Primary key = Sort key

12.3 インデックス・投影（Projection）

• ClickHouse: Skip index, Projection
• StarRocks: Bitmap index, MV
• Snowflake: Search Optimization Service
• Iceberg: Puffin 統計

12.4 キャッシュ

• Result cache（クエリ結果）
• Metadata cache
• Query plan cache
• CDN/edge cache（ダッシュボード）

12.5 Materialized view

• よく使う集計をプリコンピュート
• 増分更新が肝
• ClickHouse・Snowflake・Materialize が強い

---

第13章 · アンチパターン10選

13.1 「1つのエンジンですべてを」

失敗は確定。ワークロードごとに分離する。

13.2 ベンチマークだけを見て選ぶ

自前のデータ・クエリでの再評価が必須。

13.3 プロダクション負荷なしで PoC を承認

同時実行・SLA のテストが不足。

13.4 スタースキーマの無視

Denormalization の過剰 → 保守が悪夢に。

13.5 パーティションの過剰

小さなファイルが数万個 → プランニング地獄。

13.6 Materialized view の管理不在

古びていき、コストだけが積み上がる。

13.7 運用オンコールの準備なしでセルフホスティング

ClickHouse・Trino・Druid はオンコール負担が大きい。

13.8 ロックインを無視して SaaS にオールイン

データ主権 + コストのリスク。

13.9 クエリチューニングなしでスケールアップ

コストだけが増えて根本解決にならない。

13.10 ユーザークォータ・ガードレールの不在

「1人が全体をダウンさせる」を招く。

---

第14章 · チェックリスト — OLAP エンジン導入前の12項目

• ワークロードの分解（BI/リアルタイム/Ad-hoc/ユーザー対面）
• エンジン候補 3–5 個の自前ベンチマーク
• 価格性能マトリクス
• 運用の複雑さの評価（マネージド vs セルフ）
• セキュリティ・監査・RBAC の要件
• Lakehouse 互換性（Iceberg/Delta/Hudi）
• BI ツール・ETL ツールの互換性
• データ共有・カタログ戦略
• 災害復旧・バックアップ
• 拡張性のシミュレーション（10–100倍）
• 人材・教育のプラン
• エンジン配置図の最終版

---

第15章 · 次回予告 — Season 5 Ep 4:「dbt・SQLMesh・Dagster・Airflow・Prefect」

エンジンがデータをクエリするなら、オーケストレーターはパイプラインを治める。Ep 4 はデータ変換・オーケストレーションのツールエコシステム。

• dbt の標準化と限界
• SQLMesh の登場: dbt の代替か補完か
• Dagster: データアセット（asset-centric）オーケストレーション
• Airflow 2.x、3.0 の進化
• Prefect 3.0 の再誕
• Temporal との境界
• データ契約（Data Contracts）とスキーマ進化
• CI/CD for data pipelines
• オブザーバビリティ + アラート
• 韓国企業のスタック選定
• 「1つのツールがすべてをこなす」vs「ツールチェーン」のバランス

「データパイプラインの CI/CD」が 2025年のデータエンジニアリングの真の最前線。

次回の記事で会おう。

---

まとめ: 2025年の OLAP は「1つのエンジンですべてを」という幻想から抜け出し、ワークロード別のエンジン配置の時代になった。DuckDB はシングルノードと開発・CI を、ClickHouse はリアルタイム分析を、Snowflake・BigQuery・Databricks SQL はマネージド BI を、StarRocks・Doris はリアルタイム BI + Lakehouse を、Pinot・Druid は超低レイテンシのユーザー対面を、Trino は連合クエリを担う。ベンチマークは出発点、自前のワークロード評価は必須、そして 2–4 個のエンジン配置が現実的な支配パターン。韓国企業は網分離・韓国語 BI ツール・ゲーム・金融の固有事情を考慮してエンジンミックスを設計する。「エンジン配置がデータプラットフォーム設計の核心」が 2025年の教訓。