はじめに
OLAP（分析系）基盤は、「大量データを速く集計して意思決定に使う」ための仕組みです。
本記事では、OLAPを支えるデータ基盤が どんな部品の組み合わせで成り立っているのか を、ストレージからクエリエンジンまでの レイヤー構造 で整理し、用語や役割のつながりを俯瞰できるようにします。
1. OLAPとは
まず、OLAP（分析系）ワークロード向けのシステムは、ざっくり言うと 「大量データを、速く・柔軟に集計して、意思決定に使える形で見せる」 ために作ります。
OLAP（Online Analytical Processing） は、売上やKPIの集計、部門横断の分析、原因の深掘りなど、意思決定に直結する分析を支える仕組みです。特徴はシンプルで、大量のデータを、さまざまな切り口で、速く・繰り返し集計すること。
この「大量」「切り口が多い」「繰り返し」という性質が、システム設計の難しさにつながります。
“分析”するためのデータ基盤、なぜ難しいのか
OLAPは、単にデータを集めれば終わりではありません。実際の現場では次のような問題が頻出します。
- データが揃わない：必要なソースが取り込めていない／更新が間に合わない
- 遅くて使われない：クリックのたびに待たされ、探索が進まない
- 数字が合わない：部署ごとに「売上」「顧客数」などの定義が違う
- 安全に見せられない：個人情報や機微情報が混ざり、権限設計が破綻する
- 壊れても気づかない：処理が途中で落ちたり、欠損が出ても検知できない
ここで厄介なのは、これらが“表面上は気づきにくい”ことです。
ダッシュボード自体は表示できてしまう。でも中身は古い、遅い、ズレている、あるいは危険。そうなると、分析の信頼が落ち、最終的には「使われない基盤」になってしまいます。
このような問題が起きないように、適切なデータ基盤を設計することが重要です。
OLTP（業務処理）とOLAP（分析）は、得意なことが違う
ポイントとして、OLAPが業務DB（OLTP）と同じ設計思想ではうまくいかないことがあげられます。
-
OLTP は「1件の更新を正確に」「同時にたくさんのユーザーが処理できる」ことが重要
-
OLAP は「大量データを読み」「集計し」「切り口を変えて試行錯誤する」ことが重要
つまり、OLAPは本質的に “読むこと（Read）と集計” が主役 です。
この前提があるから、列指向やパーティション、並列処理、事前集計のような“OLAP向けの武器”が効いてきます。
OLAP基盤の全体像
ここからは、OLAPを成り立たせるデータ基盤を学ぶ際に出てくる、技術的な構成要素をレイヤーで整理して俯瞰的に理解していきます。
下に行くほど「データの実体（保存形式）」に近く、上に行くほど「SQLで分析できる体験」を支える層です。
このあと下から順に、各レイヤーが何を担当しているかを見ていきます。
1. ストレージ (Storage)
「データの置き場所」 です。
物理的にデータが保存されている場所を指します。以前はHDFS（分散ファイルシステム）が主流でしたが、現在はクラウド上の「オブジェクトストレージ」が一般的です。
主な役割: データの永続化、高可用性の確保、安価な大容量保存
具体例: OCI Object Storage, Amazon S3, Azure Blob Storage
2. ファイル形式 (File Format)
「データの詰め方・並べ方」 です。
ストレージに置かれる個々のファイルの内部構造を定義します。つまり、
1つのファイルの中で、データをどのような規則で並べて保存するかを定義します。分析用途では、特定の項目（列）だけを高速に読み取れる「列指向（カラムナ）」形式が好まれます。
主な役割: データの圧縮効率の向上、読み取りパフォーマンスの最適化
具体例: Parquet, Avro, ORC, CSV
Apache Parquet： 分析クエリに最適化された「列指向」形式であり、高い圧縮率と高速な読み取り性能を持つ現代のデファクトスタンダードです。
参考：【10分解説】Parquet形式とは？：大量データの分析を効率化するファイル形式の特徴を理解する
Apache Avro： データ構造の変化（スキーマ進化）に強く、リアルタイムなデータ転送やストリーミング処理の書き込みに適した「行指向」形式です。
Apache ORC： Parquet同様の「列指向」形式であり、特にHadoopエコシステム（Hive等/多数の安価なサーバーでビッグデータを安全かつ高速に分散・保存する処理する伝統的な仕組み）において非常に高い圧縮効率とパフォーマンスを発揮します。
CSV： テキストベースで人間が直接読める汎用的な形式ですが、データ量が増えると読み込み速度や型定義の面で非効率になります。
3. テーブルフォーマット (Table Format)
「大量のファイル群を “1つのテーブル” として扱うためのルール」 です。
ファイル形式は「個別のファイル」の内部構造なのに対して、これは「大量のファイル」を対象に一つのテーブルと定義するためのレイヤーです。これがあることにより、データに対し
- 更新・削除
- スキーマ変更
- 過去のスナップショット参照（タイムトラベル）
等の操作をできるようになります。
主な役割: ACIDトランザクション（整合性）、タイムトラベル（過去のデータ参照）、スキーマ進化の管理
具体例: Apache Iceberg, Delta Lake, Apache Hudi
ACIDトランザクション
データベース更新を「中途半端に残さず（原子性）、ルールを守り（一貫性）、同時実行でも干渉せず（独立性）、確定結果は失われない（永続性）」ように保証する考え方です。
4. ストレージエンジン (Storage Engine)
「テーブルフォーマットに従ってデータを配置し、関連するファイル/構造を最新に保つ仕組み」 です。
主な役割: データの物理的最適化の実行、インデックスの保守、古いデータの削除
これらの操作は、実際にはSpark / Flink / Trino などの処理エンジン上のジョブとして実行されることが多いです。
5. カタログ（Catalog/Metastore）
「“そのテーブルはどこにあって、どういう定義か” を管理する台帳」 です。
様々な大規模なデータを扱う場合に、分析に必要なデータを迅速に特定する必要があります。カタログは、処理エンジンやユーザーがテーブルの存在を確認したり、テーブル名、テーブル定義、テーブルのデータがストレージシステムのどこに保存されているかなどの追加情報を得るための役割を果たします。
主な役割: テーブル定義管理、スキーマ管理、権限・参照の起点
具体例: Hive Metastore、AWS Glue Data Catalog、（製品組み込みのCatalog）
6. 処理エンジン (Compute / Query Engine)
**「計算・加工を実行する演算リソース」**です。
SQLクエリやプログラムを解析し、ストレージからデータを読み取って集計や加工を行う「頭脳」の部分です。
主な役割: クエリ解析、実行計画作成、データの並列分散処理、キャッシュ
具体例: Trino (旧Presto), Apache Spark, Amazon Athena, Google BigQuery (Compute部)。
-
Trino（旧Presto）：分散SQLクエリエンジンで、もともとPrestoとして開発・普及した系譜を引き継ぎつつ、複数のデータソースにまたがる高速な対話分析（フェデレーション）に強いです。
-
Apache Spark：分散データ処理エンジンで、ETL/バッチ処理から機械学習まで幅広いワークロードを大規模並列で実行できます。
-
Amazon Athena：S3上のデータを対象に、サーバ管理なしでSQL分析できるAWSのマネージドサービス（クエリ実行ごとの従量課金）です。
-
Google BigQuery（Compute部）：BigQueryはストレージと計算が分離されたDWHで、そのうちSQLの実行・並列処理を担うスケーラブルなクエリエンジン側を指します。
まとめ
- OLAPは「読む・集計する・切り口を変えて試す」 が主役で、OLTPとは最適な設計思想が異なります。
- OLAP基盤は「データの置き場所」だけでなく、ファイル形式 → テーブルフォーマット → ストレージエンジン → カタログ → 処理エンジン の積み重ねで “分析できるテーブル” を成立させています。
- ファイル形式 は1ファイルの詰め方、テーブルフォーマット は多数ファイルをテーブルとして扱うためのルール（ACID/タイムトラベル/スキーマ進化）を担当します。
- ストレージエンジン が最適化・保守（コンパクション等）を回し、カタログ が「どこに何があるか」を台帳として管理し、処理エンジン がSQLを実行して体験を作ります。
参考