Season 5 Ep 3 — Ep 1 がストレージ、Ep 2 が流れだったとすれば、Ep 3 はクエリ。「1つのエンジンがすべてをこなす」時代は終わり、エンジン配置（Engine placement）が新しい設計領域になった。
- Prologue — 「エンジンは道具、問題はワークロード」
- 第1章 · OLAP エンジンの分類
- 第2章 · DuckDB — 「シングルノード OLAP の革命」
- 第3章 · ClickHouse — 「リアルタイム OLAP の王」
- 第4章 · Snowflake・BigQuery — 「マネージドの巨人」
- 第5章 · StarRocks・Doris — 「MPP リアルタイム BI」
- 第6章 · Apache Pinot・Druid — 「超低レイテンシ OLAP」
- 第7章 · Trino・Presto — 「連合クエリ（Federated Query）」
- 第8章 · Databricks SQL・Redshift
- 第9章 · ベンチマークの罠
- 第10章 · エンジン配置（Engine Placement）のパターン
- 第11章 · 韓国企業向けの選定ガイド
- 第12章 · 性能チューニングの汎用原則
- 第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 主要エンジンの分類
| エンジン | デプロイ | 主なワークロード | モデル |
|---|---|---|---|
| DuckDB | シングル | Ad-hoc, Embedded | オープン |
| ClickHouse | 分散 | Real-time, Log | オープン + Cloud |
| Snowflake | サーバーレス | BI, ELT | SaaS |
| BigQuery | サーバーレス | BI, ELT | SaaS |
| Databricks SQL | 分散 | BI + ML | マネージド |
| Redshift | 分散 | BI | マネージド |
| StarRocks | 分散 | Real-time BI | オープン + SaaS |
| Apache Doris | 分散 | Real-time BI | オープン |
| Apache Pinot | 分散 | 超低レイテンシ | オープン |
| Apache Druid | 分散 | 時系列・ストリーム | オープン |
| Trino/Presto | 分散 | 連合クエリ | オープン |
第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 実戦的な評価プロトコル
- 自前データのサンプリング（10–100GB）
- よく使うクエリを 5–15 本
- 同時実行 10–100 を模擬
- コスト対性能を計算
- 運用の複雑さを評価（インフラ・監視・オンコール）
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 実務推奨マトリクス
| シナリオ | 第1候補 | 補助 |
|---|---|---|
| 全社 BI（大企業） | Snowflake/BigQuery | DuckDB・Trino |
| リアルタイムログ・APM | ClickHouse | Druid/Pinot |
| ユーザー対面ダッシュボード | Pinot/StarTree | ClickHouse |
| ML + BI の統合 | Databricks SQL | Snowflake |
| Lakehouse の連合 | Trino | DuckDB |
| スタートアップの最初の DW | BigQuery/Snowflake | DuckDB |
| オンプレ・金融 | StarRocks/Doris | ClickHouse |
第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年の教訓。