最近、データ基盤に関する記事や製品説明で、次のような言葉をよく目にします。
Data Lake、Data Warehouse、Lakehouse、Lakebase、Parquet、Apache Iceberg、Data Catalog、RDBMSなどなど、、、
「ParquetとIcebergは、どちらを選べばよいのか」
「Lakehouseがあれば、RDBMSはもう不要なのか」
「Data Catalogには、実際のデータが保存されているのか」
「Lakebaseは、RDBMSに代わる新しいデータベースなのか」
データ基盤について調べていると、このような疑問を見聞きすることがあります。
どれも自然な疑問ですが、答えが分かりにくくなる大きな理由は、比較している言葉のレイヤーがそもそも違うからです。
例えば、Data LakeやLakehouseは、データ基盤やそのアーキテクチャを表す言葉です。
一方、Parquetはファイル形式、Apache Icebergはテーブル形式、Data Catalogはメタデータ管理、RDBMSはデータベース管理システムです。
物流に例えると、
物流センターの運用方式、段ボール箱の規格、在庫台帳、受発注システムを、同じ種類のものとして比較する
ようなものです。
それぞれは密接に関係していますが、同じものではなく、単純な競合技術でもありません。
さらに、AI時代には、データ基盤を利用するのは人間だけではなくなります。
AIエージェントやアプリケーションもデータを探し、意味や権限を確認し、分析や推論を行い、場合によっては業務アクションまで実行するようになります。
そう考えると、企業システム全体はLakehouseだけでは表しきれません。本記事では、より広いEnterprise Data & AI Platformとして捉えます。
本記事では、前半でData Lake、Data Warehouse、Lakehouse、Parquet、Apache Iceberg、Data Catalog、RDBMSなどをレイヤーごとに整理します。
そして後半の発展編では、それらを含むAI時代のEnterprise Data & AI Platformの全体像まで視野を広げます。
ということで、似ているようで役割の異なるデータ基盤用語を、レイヤーごとに整理してみてみます。
■ Agenda
-
基礎編：データ基盤用語をレイヤーで整理
- 用語一覧
- 全体構成を図にしてみる
- Data Lakeとは
- Data Warehouseとは
- Lakehouseとは
- Parquetとは
- Apache Icebergとは
- Data Catalogとは
- Data Catalog、Metastore、Iceberg Catalogの違い
- RDBMSとは
- Oracle Databaseの位置付け
- Lakebaseとは
- Oracle DatabaseとDatabricks Lakebaseを比較する
- OLTP、OLAP、HTAP、DSS、DWHの違い
- Object StorageとQuery Engineも分けて考える
- Data GovernanceとData Lineage
- よくある誤解を整理する
- 技術を正確に説明する文章例
- どの言葉を使えばよいか
- 物流に例えてみる
- 基礎編のまとめ
- 発展編・まとめ：AI時代のEnterprise Data & AI Platform
■ 用語一覧
最初に、今回登場する用語を分類します。
| 分類・レイヤー | 主な用語 | 何を表すか |
|---|---|---|
| データ基盤全体 | Data Lake、Data Warehouse、Lakehouse | データを保存・管理・利用する全体構成 |
| ワークロード | OLTP、OLAP、HTAP | データをどのように処理するか |
| 利用領域／ユースケース | DSS、BI、機械学習 | データを何のために利用するか |
| データベース管理システム | RDBMS、Oracle Database、PostgreSQL | データを管理・検索・更新するDBMS |
| 製品・サービス名 | Databricks Lakebase | Databricks統合型のPostgresサービス |
| クエリ／コンピュート | Spark、Trino、Flink、SQL Engine | データを実際に読み、加工、集計する |
| メタデータ管理 | Data Catalog、Metastore、Iceberg Catalog | データやテーブルの所在・定義・識別・意味などを管理する |
| テーブル形式 | Apache Iceberg、Delta Lake、Apache Hudi | 複数ファイルを一つのテーブルとして管理する |
| ファイル形式 | Parquet、ORC、Avro、CSV、JSON | 一つのファイルの中にデータをどう記録するか |
| 物理ストレージ | Object Storage、Block Storage、File Storage | 実際のデータをどこに保存するか |
重要なのは、横に並んでいる用語がおおむね同じ分類に属するという点です。
例えば、次の比較は同じレイヤー同士です。
Apache Iceberg と Delta Lake
Parquet と ORC
Data Lake と Data Warehouse
Oracle Database と PostgreSQL
一方、次の組合せはレイヤーが異なります。
Lakehouse と Parquet
Data Catalog と Iceberg
RDBMS と Object Storage
Oracle Database と Apache Iceberg
アーキテクチャを選ぶために比較することはできますが、「同じ種類の技術」という意味ではありません。
■ 全体構成を図にしてみる
● Lakehouse側の典型的な構成
Lakehouseは、複数の技術レイヤーを組み合わせて構成されることが一般的です。
利用者・アプリケーション
├─ BI
├─ SQL分析
├─ データサイエンス
└─ 機械学習
│
▼
クエリ／コンピュートエンジン
├─ Spark
├─ Trino
├─ Flink
└─ SQL Engine
│
▼
Catalog／Metastore
├─ Data Catalog
├─ Metastore
└─ Iceberg Catalog
│
▼
テーブル形式
├─ Apache Iceberg
├─ Delta Lake
└─ Apache Hudi
│
▼
データファイル形式
├─ Parquet
├─ ORC
└─ Avro
│
▼
物理ストレージ
├─ OCI Object Storage
├─ Amazon S3
├─ Azure Data Lake Storage
└─ Google Cloud Storage
この複数レイヤーを、取り込み、権限管理、品質管理、監視、リネージュなども含めて運用する全体構成がLakehouseです。
● RDBMS側の典型的な構成
一方、RDBMSは多くの機能を一つのDBMSとして統合しています。
業務アプリケーション／BI
│
▼
RDBMS
├─ SQL実行エンジン
├─ トランザクション管理
├─ 同時実行制御
├─ データディクショナリ
├─ オプティマイザ
├─ 索引
├─ バックアップ／リカバリ
├─ セキュリティ
└─ ストレージ管理
│
▼
データベースストレージ
つまり、Lakehouseではレイヤーごとに別の技術を組み合わせることが多いのに対し、RDBMSは複数の機能を一つの製品内に統合して提供します。
この違いを理解すると、
Oracle Database と Parquetはどちらが優れているか
という比較が、そのままでは成立しにくい理由が分かります。
Oracle DatabaseはDBMS全体です。
Parquetはファイル形式です。
比較する対象の大きさと役割が違います。
■ Data Lakeとは
Data Lakeは、構造化データ、半構造化データ、非構造化データなど、多様なデータを大規模に保存・利用するためのデータ基盤です。
クラウドでは、Object Storageを保存先として使用する構成がよく見られます。
Data Lake
├─ CSV
├─ JSON
├─ XML
├─ アプリケーションログ
├─ センサーデータ
├─ 画像
├─ 音声
├─ 動画
├─ Parquet
└─ Icebergテーブル
ただし、
Object Storageにファイルを置いたらData Lakeが完成する
というわけではありません。
実際のData Lakeには、次のような仕組みも必要です。
- データ取り込み
- スキーマ管理
- Data Catalog
- アクセス制御
- データ品質管理
- データリネージュ
- クエリエンジン
- 監視
- ライフサイクル管理
これらがないまま大量のファイルだけが保存されると、どこに何があるのか分からなくなります。
このような管理されていない状態は、Data Lakeに対して Data Swamp と呼ばれることがあります。
AWSの説明でも、Data Lakeは、構造化・非構造化を含むデータを任意の規模で保存し、さまざまな分析に利用する中央リポジトリとされています。
■ Data Warehouseとは
Data Warehouse、略してDWHは、主に分析、集計、レポート、意思決定支援のために、複数のシステムから集めたデータを整理して保存するデータ基盤です。
一般的には、次のような処理で利用されます。
SELECT
region,
SUM(sales_amount)
FROM
sales
GROUP BY
region;
Data Warehouseでは、次のような設計や機能が利用されます。
- スター・スキーマ
- スノーフレーク・スキーマ
- ファクト表
- ディメンション表
- パーティショニング
- マテリアライズド・ビュー
- クエリー・リライト
- データ圧縮
- 列指向処理
- 並列問合せ
Oracle AI Database 26aiのData Warehousing Guideでも、Data Warehouseはトランザクション処理よりも問合せと分析を目的に設計され、履歴データや複数ソースのデータを扱うものとして説明されています。
従来は、Data LakeとData Warehouseを次のように整理する説明がよく行われてきました。
| Data Lake | Data Warehouse |
|---|---|
| 多様な形式のデータを保存 | 分析しやすく整理したデータを保存 |
| 生データも保存 | 加工・クレンジング済みデータが中心 |
| 探索的分析や機械学習にも利用 | SQL、BI、定型分析を中心に利用 |
| Object Storageがよく使われる | RDBMSや分析DBがよく使われる |
| Schema on Readがよく使われる | Schema on Writeがよく使われる |
ただし、現在のData WarehouseはJSON、外部表、Object Storageなども扱えます。
一方、Data Lake側でも、Icebergなどを利用して厳格なスキーマ管理やトランザクション管理を行えます。
そのため、この違いは絶対的な境界ではなく、典型的な傾向として理解する方がよいと思います。
■ Lakehouseとは
Lakehouseは、
Data Lakeの柔軟性、拡張性、オープン性と、Data Warehouseのテーブル管理、データ品質、トランザクション、SQL分析能力などを組み合わせるデータ基盤アーキテクチャ
です。
典型的には、次のような構成になります。
Object Storage
└─ Parquetファイル
└─ Icebergなどでテーブル管理
└─ Catalogで識別・管理
└─ SparkやSQLエンジンで分析
ここで注意したいのは、
Lakehouseはファイル形式でも、単一のデータベース製品でもない
という点です。
Apache Icebergを導入しただけで、自動的にLakehouseが完成するわけではありません。
Lakehouseとして運用するには、次の要素も必要になります。
- Object Storage
- クエリ／コンピュートエンジン
- Catalog
- アクセス制御
- データ品質管理
- データ取り込み
- オーケストレーション
- 監視
- データリネージュ
- バックアップや災害対策
- コスト管理
IcebergはLakehouseを構成する重要な部品ですが、Lakehouse全体と同じものではありません。
■ Parquetとは
Apache Parquetは、分析処理に適したオープンな列指向データファイル形式です。
Apache Parquetの公式ドキュメントでは、効率的な保存と取得を目的とした、オープンソースの列指向データファイル形式と説明されています。
例えば、次のデータがあるとします。
id | name | region | amount
1 | Alice | Tokyo | 1000
2 | Bob | Osaka | 2000
3 | Carol | Tokyo | 1500
CSVのような行単位の形式では、概念的に次のように保存されます。
1,Alice,Tokyo,1000
2,Bob,Osaka,2000
3,Carol,Tokyo,1500
Parquetでは、概念的には列ごとにデータがまとまります。
id列 : 1, 2, 3
name列 : Alice, Bob, Carol
region列 : Tokyo, Osaka, Tokyo
amount列 : 1000, 2000, 1500
そのため、次のような問合せでは、必要な列を中心に読み取れます。
SELECT SUM(amount)
FROM sales;
Parquetには、圧縮やエンコーディング、列単位の読み取りなど、分析に適した特徴があります。
ただし、Parquetはあくまでファイル形式です。
Parquet単体が、次のようなテーブル全体の管理機能を提供するわけではありません。
- 複数ファイルにまたがるトランザクション
- スナップショット
- タイムトラベル
- テーブル単位のロールバック
- 複数ライターの競合制御
- 現在有効なファイルの管理
- パーティション方式の進化
これらを担当するのが、Apache Icebergなどのテーブル形式です。
■ Apache Icebergとは
Apache Icebergは、大規模な分析データ向けのオープンテーブル形式です。
公式ドキュメントでも、巨大な分析データセット向けのOpen Table Formatと説明されています。
Icebergは、複数のデータファイルを一つの論理的なテーブルとして管理します。
Icebergテーブル
├─ テーブルメタデータ
├─ スキーマ
├─ パーティション定義
├─ スナップショット
├─ マニフェストリスト
├─ マニフェストファイル
└─ データファイル
├─ part-001.parquet
├─ part-002.parquet
└─ part-003.parquet
Icebergのデータファイルには、Parquetがよく使用されます。
しかし、IcebergとParquetは同じものではありません。
Parquet
= 一つのデータファイルの中身をどう保存するか
Iceberg
= 複数のデータファイルを
一つのテーブルとしてどう管理するか
Icebergは、次のような機能を提供します。
- スキーマ進化
- 隠蔽パーティショニング
- パーティション方式の進化
- スナップショット
- タイムトラベル
- ロールバック
- 原子的なテーブル更新
- 複数ライターの同時実行制御
- メタデータを利用したファイルの絞り込み
ただし、安全な複数ライター構成は、Icebergのテーブル形式だけで完結するとは限りません。
Icebergは楽観的同時実行制御を提供しますが、実際に安全なコミットを行えるかは、Catalog実装とストレージの組合せにも依存します。
例えば、Apache Iceberg公式ドキュメントでは、Hadoop CatalogをAmazon S3で使用する構成について、安全な同時書き込みを保証しないと注意されています。
そのため、複数のエンジンやライターから同じIcebergテーブルを更新する場合は、Iceberg対応という点だけで判断せず、Catalogのコミット方式やロック機構、ストレージの整合性まで含めて確認する必要があります。
また、仕組みを説明する場合は、次の言い方が分かりやすいと思います。
△ Icebergファイルを保存する
○ Parquetなどのデータファイルを
Icebergテーブルとして管理する
製品画面や会話では「Iceberg形式」と簡略化されることがありますが、概念整理では、
Icebergはテーブル形式、Parquetはファイル形式
と分けると理解しやすくなります。
● Open Table Formatとは
Open Table Formatは、Object Storage上などにある複数のデータファイルを、論理的なテーブルとして管理するためのオープンな仕様・仕組みです。
代表例として、次のものがあります。
| テーブル形式 | 大まかな特徴 |
|---|---|
| Apache Iceberg | マルチエンジン、スキーマ進化、隠蔽パーティション、スナップショット |
| Delta Lake | ACIDトランザクション、バッチとストリーミングの統合 |
| Apache Hudi | UPSERT、変更データ、増分処理を重視 |
これらはParquetなどのファイル形式と競合するものではありません。
むしろ、Parquetをデータファイルとして利用し、その上にテーブル管理機能を追加する関係です。
■ Data Catalogとは
Data Catalogは、データ資産に関するメタデータを管理する仕組みです。
例えば、次のような情報を管理します。
- データセット名
- テーブル名
- 列名
- データ型
- 保存場所
- データ所有者
- データの説明
- 機密区分
- タグ
- 更新日時
- データ品質
- データリネージュ
- アクセス権限
- 利用状況
重要なのは、
Data Catalogが管理する中心的なものは、データそのものではなく、データについての情報である
という点です。
Data Catalog
└─ sales.orders
├─ 保存場所
│ └─ object-storage://sales/orders/
├─ テーブル形式
│ └─ Apache Iceberg
├─ ファイル形式
│ └─ Parquet
├─ 所有者
│ └─ Sales Data Team
├─ 機密区分
│ └─ Confidential
└─ 説明
└─ ECサイトの受注明細
実際の受注明細データは、Object Storageやデータベースに保存されています。
AWS Glue Data Catalogも、S3上のデータセットに関する構造的・運用上のメタデータを保持する中央メタデータリポジトリとして説明されています。
■ Data Catalog、Metastore、Iceberg Catalogの違い
「Catalog」という名前も複数の意味で使われるため、注意が必要です。
| 用語 | 主な役割 | 主な利用者 |
|---|---|---|
| Data Catalog | データを検索、理解、分類、統制する | データ利用者、管理者、ガバナンス担当者 |
| Metastore | テーブル定義やスキーマなどの技術メタデータを管理する | Spark、Hive、Trinoなどのエンジン |
| Iceberg Catalog | Icebergテーブルを名前から特定し、作成・ロード・更新する | Iceberg対応エンジン、アプリケーション |
● Data Catalog
人や組織がデータ資産を検索し、意味、所有者、機密区分、品質、リネージュなどを理解するための仕組みです。
● Metastore
エンジンがテーブルのスキーマ、保存場所、パーティションなどを取得するための、技術的なメタデータ管理です。
● Iceberg Catalog
Icebergテーブルを名前から検索し、作成、ロード、登録、更新、名称変更などを行うための仕組みです。
実際の製品では、一つのCatalog製品がこれら複数の役割を持つことがあります。
そのため、
製品として一体化されている
ことと、
概念として同じものである
ことは分けて考えた方がよいと思います。
■ RDBMSとは
RDBMSは、Relational Database Management Systemの略です。
表、行、列、主キー、外部キー、SQL、制約、トランザクションなどを使ってデータを管理するデータベース管理システムです。
代表例として、次のような製品があります。
RDBMS
├─ Oracle Database
├─ PostgreSQL
├─ MySQL
├─ Microsoft SQL Server
└─ IBM Db2
RDBMSは、必ずしもOLTP専用ではありません。
製品、構成、設計によって、次のような用途に利用できます。
RDBMS
├─ OLTP
├─ OLAP
├─ DSS
├─ Data Warehouse
├─ バッチ処理
├─ リアルタイム分析
└─ 混合ワークロード
ただし、すべてのRDBMSが、すべての用途を同じ性能や同じ規模で処理できるという意味ではありません。
用途に応じて、次のような設計が必要です。
- データモデル
- 正規化／非正規化
- 索引
- パーティショニング
- マテリアライズド・ビュー
- メモリー構成
- 並列度
- ストレージ
- リソース管理
- 可用性
- ワークロード分離
「汎用RDBMS」という言葉は、何も設計しなくても万能という意味ではなく、複数種類のワークロードに対応できる機能と構成の選択肢を持つ、という意味で捉えるのがよいと思います。
■ Oracle Databaseの位置付け
Oracle Databaseは、OLTP用途だけに限定されたRDBMSではありません。
構成や設計に応じて、次のような用途に利用できます。
Oracle Database
├─ OLTP
│ ├─ 受発注
│ ├─ 決済
│ └─ 基幹業務
│
├─ OLAP
│ ├─ 集計
│ ├─ 分析問合せ
│ └─ BI
│
├─ DSS
│ └─ 意思決定支援
│
├─ Data Warehouse
│ ├─ スター・スキーマ
│ ├─ パーティショニング
│ ├─ マテリアライズド・ビュー
│ └─ クエリー・リライト
│
└─ Mixed Workload
├─ トランザクション
└─ リアルタイム分析
Oracle AI Database 26aiのData Warehousing Guideには、Data Warehouse設計、スター・スキーマ、パーティショニング、マテリアライズド・ビュー、並列実行、圧縮などが体系的に記載されています。
また、Database In-Memoryは、リアルタイム分析や混合ワークロードの性能向上を目的とする機能として説明されています。
したがって、
RDBMS = OLTP専用
と考えるのは正確ではありません。
より正確には、
OLTPやOLAPはワークロードの種類
RDBMSはデータベース管理システムの種類
です。
■ Lakebaseとは
2026年8月時点で、Databricksの公式ドキュメントでは、LakebaseはDatabricksプラットフォームに統合された、フルマネージドのPostgresデータベースとして説明されています。
中心的な用途として、次のものが挙げられています。
- 低遅延アプリケーション
- トランザクションワークロード
- アプリケーションバックエンド
- Lakehouseデータの低遅延サービング
- AIエージェントの状態管理
- オンラインFeature Store
技術的な位置付けを整理すると、次のようになります。
製品・サービス名
└─ Databricks Lakebase
データベース
└─ Postgres
一般分類
└─ RDBMS
中心的な用途
└─ OLTP／アプリケーションデータベース
したがって、Lakebaseは、
RDBMSを置き換える新しい一般分類
というより、
Databricksプラットフォームに統合された
PostgresベースのマネージドRDBMS
と理解する方が自然です。
ベンダーに依存しないアーキテクチャ図では、Lakebaseではなく、次のように書く方が一般化できます。
RDBMS
または、
OLTP Database
Operational Database
Application Database
実際にDatabricks Lakebaseを採用する場合に、その箇所を製品名へ置き換えます。
RDBMS
└─ Databricks Lakebase
■ Oracle DatabaseとDatabricks Lakebaseを比較する
Oracle DatabaseとDatabricks Lakebaseは、どちらもRDBMS側に分類できます。
ただし、製品の位置付けと機能範囲は同じではありません。
| 項目 | Databricks Lakebase | Oracle Database |
|---|---|---|
| 種別 | Databricks統合型のマネージドPostgres | 汎用RDBMS製品 |
| 中心的な位置付け | アプリケーション向けトランザクションDB | OLTP、DWH、分析、混合ワークロード |
| データベースエンジン | Postgres | Oracle Database Engine |
| Lakehouseとの関係 | Databricks Lakehouseとネイティブに連携 | 単独でもRDBMS、DWH、分析基盤として利用可能 |
| 名前の性質 | 製品・サービス名 | データベース製品名 |
| 一般化した表現 | RDBMS／OLTP Database | RDBMS |
Databricks中心の構成を単純化すると、次のように表せます。
Lakebase = 主にOLTP側
Lakehouse = 主にOLAP／分析側
ただし、この分類をすべてのRDBMSへそのまま当てはめることはできません。
Oracle Databaseの場合は、構成や設計によってOLTP側にも、OLAP／DWH側にも配置できます。
OLTP OLAP／DWH
│ │
Databricks Lakebase ● △
Lakehouse △ ●
Oracle Database ● ●
ここでの記号は、次の大まかな意味です。
● = 主要用途、または十分に対応可能
△ = 利用できる場合はあるが、中心的な位置付けではない
もちろん、Oracle DatabaseでOLTPと大規模分析を同居させる場合も、リソース管理、可用性、ライセンス、ワークロード分離などを含めた設計が必要です。
■ OLTP、OLAP、HTAP、DSS、DWHの違い
これらも、同じ分類の言葉ではありません。
| 用語 | 分類 | 意味 |
|---|---|---|
| OLTP | ワークロード | 多数の小さな登録、更新、検索を高速に処理する |
| OLAP | ワークロード | 大量データを集計・分析する |
| HTAP | ワークロード／アーキテクチャ | OLTPとOLAPを同一または密接に連携したデータ基盤で扱う |
| DSS | 利用目的／システム | 意思決定を支援する |
| DWH | データ基盤 | 分析用データを統合・整理して保存する |
| BI | 利用目的／ツール | 可視化、レポート、分析を行う |
例えば、次のような関係になります。
DSS
└─ 意思決定を支援する仕組み
└─ OLAPを利用
└─ DWHのデータを分析
└─ RDBMSやLakehouse上に構築
つまり、
OLAP = Data Warehouse
ではありません。
OLAPは処理の性質で、Data Warehouseはデータ基盤です。
同じように、
RDBMS = OLTP
でもありません。
RDBMSはデータベース管理システムの分類であり、OLTPはワークロードです。
● DWSという略称について
DWSは、Data Warehouse SystemやData Warehouse Serviceなどを表す場合があります。
ただし、DWHほど意味が統一された略称ではなく、製品や組織によって意味が異なることがあります。
一般的な説明では、
Data Warehouse（DWH）
と書き、必要な場合だけ、
Data Warehouse System
Data Warehouse Service
と正式名称を記載した方が誤解を減らせます。
■ Object StorageとQuery Engineも分けて考える
● Object Storage
Object Storageは、データファイルを物理的に保存するストレージです。
代表例として、次のものがあります。
- OCI Object Storage
- Amazon S3
- Azure Data Lake Storage
- Google Cloud Storage
Object Storageは保存場所であり、それ単体がParquet、Iceberg、Data Catalog、Data Lake、Lakehouseになるわけではありません。
Object Storage
└─ Parquetファイルを保存できる
└─ Icebergテーブルのデータファイルとして利用できる
└─ Lakehouseの保存層を構成できる
● Query Engine／Compute Engine
Query EngineやCompute Engineは、データを実際に読み、加工、集計する処理エンジンです。
代表例として、次のものがあります。
- Apache Spark
- Trino
- Apache Flink
- DuckDB
- 各種SQL分析エンジン
ParquetやIcebergはデータを管理する形式であり、通常は、それだけでSQLを実行するわけではありません。
対応するエンジンがParquetファイルやIcebergテーブルを読み取って処理します。
■ Data GovernanceとData Lineage
● Data Governance
Data Governanceは、
誰が、どのデータを、何の目的で、どのように利用できるか
という方針、責任、ルール、運用のことです。
Data CatalogはData Governanceを実現するための重要な道具ですが、両者は同じものではありません。
Data Governance
= 方針、責任、ルール、運用
Data Catalog
= データを検索、理解、分類、統制するための仕組み
● Data Lineage
Data Lineageは、データがどこから来て、どの処理を通り、どこへ渡されたかという経路です。
業務DB
↓
CDC／ETL
↓
raw.orders
↓
クレンジング
↓
curated.orders
↓
売上レポート
Data LineageはData Catalogの一機能として提供されることもあれば、別の製品や仕組みとして提供されることもあります。
■ よくある誤解を整理する
| よくある説明 | より正確な説明 |
|---|---|
| Parquetはテーブル形式である | Parquetはデータファイル形式である |
| Icebergファイルを保存する | ParquetなどのデータファイルをIcebergテーブルとして管理する |
| Parquetにタイムトラベル機能がある | Icebergなどのテーブル管理層がスナップショットやタイムトラベルを提供する |
| Icebergはデータベースである | Icebergは分析データ向けのテーブル形式である |
| IcebergはData Catalogである | IcebergはCatalogを利用してテーブルを管理する |
| Data Catalogに売上データを保存する | Data Catalogには主に売上データのメタデータを登録する |
| Object Storageを作ればData Lakeが完成する | Catalog、権限、品質、処理基盤なども必要になる |
| Icebergを導入すればLakehouseになる | IcebergはLakehouseを構成する部品の一つである |
| LakebaseはRDBMSに代わる新しい一般分類である | Databricks LakebaseはPostgresベースの製品・サービス名である |
| RDBMSはOLTP専用である | 製品や設計によってOLAP、DWH、混合ワークロードにも利用できる |
| LakehouseはRDBMSの上位互換である | 対象ワークロードや管理方式が異なり、併用されることも多い |
| Oracle DatabaseはLakebaseに相当するだけである | どちらもRDBMS側だが、Oracle Databaseはより広い用途に対応する |
| OLAPはDWHの別名である | OLAPはワークロード、DWHはデータ基盤である |
| Data CatalogとMetastoreは完全に同じである | 製品上は統合される場合があるが、概念上の主目的は異なる |
■ 技術を正確に説明する文章例
● Lakehouse構成を説明する場合
OCI Object Storage上にParquet形式のデータファイルを保存し、Apache Icebergで論理テーブルとして管理します。テーブルをCatalogで識別・管理し、SparkやTrinoなどのクエリエンジンから参照します。アクセス制御、データ品質、リネージュを含めた全体をLakehouseとして運用します。
● 業務システムとLakehouseを連携する場合
業務アプリケーションのトランザクションは、Oracle DatabaseやPostgreSQLなどのRDBMSで処理します。変更データをCDCやETLでLakehouseへ連携し、BI、履歴分析、データサイエンス、機械学習に利用します。
● Databricks Lakebaseを利用する場合
アプリケーションのトランザクションデータはDatabricks Lakebaseで管理し、Databricks Lakehouseのデータをアプリケーション向けにサービングしたり、Postgres側の変更データをLakehouseへ連携したりします。
● Oracle DatabaseをDWHとして利用する場合
Oracle Database上にスター・スキーマを構築し、パーティショニング、マテリアライズド・ビュー、クエリー・リライト、並列問合せなどを利用してData Warehouseを構成します。
この場合、Data Warehouseを構築するために、必ずIcebergやParquetが必要になるわけではありません。
■ どの言葉を使えばよいか
迷った場合は、「今、何について説明しているのか」を確認します。
システム全体の構成を説明したい
└─ Data Lake / Data Warehouse / Lakehouse
トランザクションDBを説明したい
└─ RDBMS / OLTP Database / Operational Database
実際のDB製品を説明したい
└─ Oracle Database / PostgreSQL / Databricks Lakebase
データファイルの保存形式を説明したい
└─ Parquet / ORC / Avro
複数ファイルのテーブル管理を説明したい
└─ Apache Iceberg / Delta Lake / Apache Hudi
データの所在や意味を説明したい
└─ Data Catalog
テーブルの技術的な定義を説明したい
└─ Metastore / Iceberg Catalog
データを実際に処理する仕組みを説明したい
└─ Query Engine / Compute Engine
実際の保存場所を説明したい
└─ Object Storage / Database Storage
■ 物流に例えてみる
最後に、全体を物流に例えてみます。
| データ用語 | 物流の例え |
|---|---|
| Object Storage | 倉庫の建物や棚 |
| Parquet | 箱の中の商品を並べる規格 |
| Iceberg | 現在有効な箱と履歴を管理する在庫台帳 |
| Iceberg Catalog | 商品番号から在庫台帳を特定する仕組み |
| Data Catalog | 商品検索、説明、分類、担当者、取扱ルールを管理する台帳 |
| Query Engine | 商品を取り出して集計する作業員や設備 |
| Data Lake | 多様な商品を大量に保管する倉庫群 |
| Lakehouse | 倉庫に在庫管理、品質管理、検索、分析設備を加えた全体システム |
| RDBMS | 受注、在庫、更新、整合性を一体的に処理する業務システム |
| Databricks Lakebase | Databricks環境に統合されたPostgresベースの業務DBサービス |
この例えも完全ではありませんが、それぞれの用語が同じ階層ではないことは分かりやすくなると思います。
■ 基礎編のまとめ
今回の用語を一行ずつまとめると、次のようになります。
Data Lake
= 多様なデータを大規模に保存・利用するデータ基盤
Data Warehouse
= 分析用に統合・整理されたデータを扱うデータ基盤
Lakehouse
= Data LakeとData Warehouseの特徴を組み合わせたアーキテクチャ
RDBMS
= リレーショナルデータを管理するデータベース管理システム
Oracle Database
= OLTP、DWH、分析、混合ワークロードなどに対応できる汎用RDBMS
Databricks Lakebase
= Databricksに統合されたPostgresベースのマネージドRDBMS
Parquet
= 分析向けの列指向データファイル形式
Apache Iceberg
= 複数のデータファイルを一つのテーブルとして管理する形式
Data Catalog
= データの所在、意味、所有者、分類などを管理するメタデータ基盤
Metastore
= テーブル定義などの技術メタデータを管理する仕組み
Query Engine
= データを実際に読み、加工、集計する処理エンジン
Object Storage
= データファイルを物理的に保存する場所
最も重要なのは、
これらの言葉を、同じレイヤーの技術として横並びに比較しないこと
です。
「アーキテクチャ」「ワークロード」「データベース」「テーブル形式」「ファイル形式」「Catalog」「処理エンジン」「物理ストレージ」に分けて考えると、それぞれの役割が見えやすくなります。
また、Lakebaseは一般的な技術分類として無理に使用せず、ベンダーに依存しない説明では、
RDBMS
OLTP Database
Operational Database
と表現する方が分かりやすいと思います。
Oracle Databaseについては、単純にLakebase相当のOLTPデータベースと位置付けるのではなく、
OLTP、Data Warehouse、分析、混合ワークロードなどに利用できる汎用RDBMS
として整理する方が、実際の機能と使われ方に合っています。
■ 発展編：データ基盤からAI時代のEnterprise Data & AI Platformへ
ここまで、Data Lake、Data Warehouse、Lakehouse、Parquet、Apache Iceberg、Data Catalog、RDBMSなどを、レイヤーごとに整理しました。
しかし、これらを組み合わせた企業システム全体を考えると、Lakehouseだけでは名前として少し足りません。
Lakehouseは、データを蓄積、管理、処理、分析するための重要なデータ基盤です。一方、実際の企業システムには、その上に人間、AIエージェント、AIモデル、業務アプリケーション、API、ワークフロー、業務アクションなどがあります。
そこで本記事では、次の全体をまとめて、Enterprise Data & AI Platformと呼びます。
本記事での定義
Enterprise Data & AI Platformとは、RDBMS、Data Lake、Data Warehouse、Lakehouseなどのデータ管理基盤に、Data Catalog、AIモデル、AIエージェント、人間、アプリケーション、業務アクション、ガバナンスを加えた企業全体のデータ＆AI基盤です。
Enterprise Data & AI Platformは、本記事で全体像を説明するために使用するベンダー非依存の呼び方です。特定の一製品や、一つの標準仕様を指すものではありません。
各ベンダーでは、Data Intelligence Platform、AI Data Platform、Unified Data Platformなど、似た範囲を異なる名前で表現しています。
● Lakehouseだけでは全体像を表せない
Lakehouseの代表的な役割は、次のようなものです。
データを取り込む
↓
Object Storageなどへ保存する
↓
Icebergなどでテーブルとして管理する
↓
Catalogでテーブルを識別・管理する
↓
SQL、BI、機械学習などで利用する
これは非常に重要な仕組みですが、企業システム全体には、さらに次の要素があります。
- 人間が質問、判断、承認するためのインタフェース
- AIエージェントがデータやツールを利用するための実行環境
- LLM、Embedding Model、機械学習モデル
- Semantic Layer、Ontology、Knowledge Graph
- 業務アプリケーション、API、ワークフロー
- RDBMS上のトランザクション処理
- 業務システムへの登録、更新、通知などのアクション
- Identity、Security、Data Governance、監査
- AIの実行結果を改善へ戻すフィードバックループ
そのため、関係は次のように捉えると分かりやすいと思います。
Lakehouse
⊂ Enterprise Data & AI Platform
Lakehouseは、Enterprise Data & AI Platformを構成する重要な部分ですが、全体そのものではありません。
● 一番上にいるのは「人間・AIエージェント・アプリケーション」
従来のデータ基盤図では、一番上に「利用者」「BI」「データサイエンティスト」などが置かれることが多くありました。
AI時代の全体図では、最上位に次の三つを置く方が実態に合います。
利用者・実行主体
├─ 人間
├─ AIエージェント
└─ アプリケーション／サービス
ここでは、単なる利用者というより、データを利用して判断や処理を行う主体という意味で、**Consumers & Actors（利用者・実行主体）**と表現します。
| 利用者・実行主体 | 主な役割 |
|---|---|
| 人間 | 目的の設定、質問、分析、判断、承認、例外対応、最終的な責任 |
| AIエージェント | データ探索、分析、推論、計画、ツール実行、許可された業務アクション |
| アプリケーション／サービス | API呼出し、定型処理、イベント処理、システム間連携 |
AIエージェントは、データを読むだけとは限りません。
権限とポリシーの範囲内で、APIやツールを呼び出し、業務システムへ処理を返す実行主体になる可能性があります。
● Enterprise Data & AI Platformをレイヤーで表してみる
今回の用語整理を、AI時代の企業システム全体へ広げると、次のように表せます。
利用者・実行主体：Consumers & Actors
├─ 人間
├─ AIエージェント
└─ アプリケーション／サービス
│
▼
体験・業務・アクション層：Experience & Action
├─ Chat／Copilot／Agent UI
├─ BI／Dashboard／Notebook
├─ API／Application
├─ Workflow／Business Automation
└─ Human Approval
│
▼
AI・知識・セマンティック層：AI, Knowledge & Semantic
├─ LLM／Machine Learning Model
├─ Agent Runtime／Orchestration
├─ RAG／Vector Search
├─ Knowledge Graph／Ontology
├─ Semantic Layer
└─ MCP／Tools
│
▼
分析・処理・データ提供層：Analytics, Processing & Serving
├─ SQL Engine
├─ Spark／Trino／Flink
├─ Stream Processing
├─ Data API
├─ Feature Serving
└─ Model Serving
│
▼
統合データ管理層：Unified Data Management
├─ RDBMS／Operational Database
├─ Data Warehouse
├─ Data Lake
├─ Lakehouse
├─ Search Engine／Vector Store
├─ Document Store
└─ 管理層を支えるテーブル・ファイル・ストレージ
├─ Apache Iceberg／Delta Lake／Apache Hudi
├─ Parquet／ORC／Avro／JSON／CSV
├─ Object Storage
├─ Database Storage
└─ Block／File Storage
▲
│ 取り込み／同期／仮想化／直接参照
│
データソース・System of Record
├─ Oracle Database／PostgreSQL／MySQL
├─ ERP／CRM／HCM／SCM
├─ SaaS／外部サービス
├─ 文書／画像／音声／動画
├─ IoT／ログ／イベント
└─ 外部データ
────────────────────────────────────────
すべての層を横断する機能
├─ Identity and Access Management
├─ Security／Privacy
├─ Data Governance／AI Governance
├─ Data Catalog／Metadata
├─ Data Quality／Freshness
├─ Data Lineage／Provenance
├─ Observability／Audit
└─ DataOps／MLOps／LLMOps
この図は、製品を一つの箱へ固定するためのものではなく、役割を理解するための概念図です。
この図では、データソースを統合データ管理層の下位レイヤーとして積み重ねるのではなく、取り込み、同期、仮想化、直接参照などを通じて、統合データ管理層へ接続する入力元として表現しています。
例えば、Oracle DatabaseはSystem of Recordとしてデータソース側に位置することもあれば、統合データ管理層でOLTP、DWH、分析を担うこともあります。
同じ製品が両方に現れる可能性があるのは製品の重複ではなく、同じ製品でも構成や利用目的によって担う役割が異なるためです。
Data Catalogも単一のレイヤーだけに閉じるものではありません。RDBMS、Lakehouse、ファイル、AIモデル、データプロダクトなど、複数レイヤーの資産を横断して管理するため、この図では横断機能として配置しています。
● AIエージェントとAIモデルは同じ位置ではない
「AI」を一つの箱にまとめると、AIエージェントとAIモデルの役割が分かりにくくなります。
AIエージェント
= 目的に向けてデータ、モデル、ツールを組み合わせ、
判断や処理を進める利用者・実行主体
AIモデル
= 生成、推論、分類、予測、Embeddingなどの
能力を提供する技術コンポーネント
例えば、AIエージェントは次のように動作します。
人間から目的を受け取る
↓
Data Catalogから利用可能なデータを探す
↓
Semantic Layerから業務上の意味を確認する
↓
権限とポリシーを確認する
↓
SQL、検索、APIなどのツールを選ぶ
↓
AIモデルを利用して分析・推論する
↓
回答、計画、または業務アクションを作成する
↓
必要に応じて人間の承認を得る
AIモデルは、エージェントに能力を提供するコンポーネントの一つです。AIエージェントはモデルだけでなく、データ、メタデータ、ツール、権限、ワークフローを組み合わせて動作します。
● 一方向の分析基盤から、循環するData–AI–Actionへ
従来のデータ分析は、次のような一方向の流れで説明されることがよくありました。
データソース
↓
Data Lake／Data Warehouse
↓
分析
↓
レポート
↓
人間が判断する
AIエージェントと業務アクションを含む場合、全体は一方向ではなく循環します。
業務システムでデータが発生する
↓
データを統合・管理する
↓
Data CatalogとSemantic Layerで意味を与える
↓
AIや分析が推論・判断案を作る
↓
人間が承認する、またはポリシーに基づいて自動判定する
↓
APIやWorkflowで業務アクションを実行する
↓
業務システムの状態が変化する
↓
新しいデータが発生する
これを短く表すと、次のようになります。
Data
↓
Context
↓
Intelligence
↓
Decision
↓
Action
↓
Feedback
└─────────→ Dataへ戻る
今後のデータ基盤では、Data to Insightだけでなく、Data to Intelligence to Actionまでを設計する必要があります。
● AI時代にData Catalogがさらに重要になる理由
人間は、列名やレポート名が多少曖昧でも、経験や周囲の会話から意味を補える場合があります。
AIは、明示されていない意味を誤って解釈する可能性があります。
例えば、sales_dateという列があっても、次のどれを表すのかは名前だけでは分かりません。
注文を受けた日
商品を出荷した日
売上を会計計上した日
入金を確認した日
AIが安全かつ正確にデータを利用するには、Data Catalogなどを通じて、次の情報へアクセスできる必要があります。
- データの保存場所とスキーマ
- 業務上の定義
- データ所有者
- 機密区分
- 利用可能な目的と禁止事項
- データ品質
- 更新頻度と最終更新時刻
- データリネージュ
- 参照元と生成過程
- 利用者またはAIエージェントの権限
ただし、Data Catalogに技術メタデータを登録するだけで、AIが業務を完全に理解できるわけではありません。
AI向けのデータ基盤では、次の要素も重要になります。
Data Catalog
= どのデータが、どこにあり、誰が管理しているか
Semantic Layer
= 売上、顧客、利益などを業務上どう定義するか
Ontology／Knowledge Graph
= 顧客、注文、契約、製品などがどう関係するか
Data Governance
= 誰が、何の目的で、どのように利用できるか
Provenance
= AIの回答や判断が、どのデータと処理に基づくか
Data Catalogは、AIが企業データを探し、理解し、安全に利用するための重要な入口になります。
● 基礎編の用語は全体像のどこにあるのか
ここまで整理した用語を、Enterprise Data & AI Platformの中へ配置すると、次のようになります。
| 用語 | Enterprise Data & AI Platformでの位置付け |
|---|---|
| RDBMS | 業務トランザクション、System of Record、DWH、分析などを担うデータ管理基盤 |
| Data Lake | 多様なデータを大規模に保存・利用するデータ基盤 |
| Data Warehouse | 分析用に統合・整理したデータを扱うデータ基盤 |
| Lakehouse | Data LakeとData Warehouseの特徴を組み合わせた分析・データ管理基盤 |
| Apache Iceberg | Lakehouseなどで複数のデータファイルを論理テーブルとして管理するテーブル形式 |
| Parquet | 分析データを効率よく保存する列指向ファイル形式 |
| Data Catalog | 各レイヤーのデータ資産を検索、理解、分類、統制するメタデータ基盤 |
| Query Engine | データを実際に読み、変換、集計、提供する処理層 |
| Object Storage | Parquetなどのデータファイルを物理的に保存するストレージ層 |
| AIモデル | 推論、生成、分類、予測などの能力を提供するコンポーネント |
| AIエージェント | データ、モデル、ツールを利用して目的を達成する利用者・実行主体 |
この表からも、Lakehouse、Iceberg、Parquet、Data Catalog、RDBMSが、同じ種類の技術ではないことが分かります。
そして、Enterprise Data & AI Platformは、それらを競合する一つの製品へ置き換える概念ではなく、異なる役割を持つ技術を組み合わせた企業システム全体です。
● AIが主なデータ利用者になる未来
これまで、多くのデータ基盤は、人間がSQLを書き、ダッシュボードを見て、判断することを中心に設計されてきました。
人間
↓
データを探す
↓
SQLを書く
↓
結果を読む
↓
判断する
↓
業務を実行する
今後は、人間の要求とデータ基盤の間にAIエージェントが入り、多くの処理を仲介する構成が増えると考えられます。
人間
↓ 目的・質問・制約
AIエージェント
↓
データを探す
↓
意味、品質、権限を確認する
↓
SQL、検索、APIを実行する
↓
分析・推論する
↓
回答またはアクション案を作る
↓
人間の承認またはポリシー判定
↓
業務を実行する
この意味では、AIエージェントは、将来のEnterprise Data & AI Platformにおける主要なデータ利用者の一つになる可能性があります。
ただし、人間が不要になるという意味ではありません。
企業システムでは、人間が次の役割を持ち続けます。
- 目的と評価基準を決める
- 権限とポリシーを定義する
- 重要な処理を承認する
- 例外を判断する
- AIの結果を評価する
- 最終的な説明責任を持つ
AIが日常的なデータ探索、分析、実行を仲介し、人間が目的、統制、承認、責任を担う構成が、現実的なEnterprise Data & AI Platformの姿だと思います。
■ 全体のまとめ
今回は、Data Lake、Data Warehouse、Lakehouse、Parquet、Apache Iceberg、Data Catalog、RDBMSなど、似ているようで役割の異なる言葉を、レイヤーごとに整理してみてみました。
整理してみると、これらは一つの技術で置き換え合うものではなく、それぞれ異なる役割を持っていることが分かります。
Parquetはファイル形式
Icebergはテーブル形式
Data Catalogはメタデータ管理
RDBMSはデータベース管理システム
Lakehouseは、それらを組み合わせたデータ基盤アーキテクチャ
今回、Data Catalogの記事を続けて書く中で、最初はData Lake上のファイルやテーブルを、どのように見つけて管理するのかを整理したいと考えていました。
しかし、調べていくと、Data Catalogは単に「どこに何のデータがあるか」を登録するためだけのものではありませんでした。
データの意味、所有者、品質、由来、権限、利用条件を整理し、人間だけでなくAIエージェントが企業データを安全に利用するための入口にもなります。
ここから、話がData LakeやLakehouseだけでは収まらず、RDBMS、AIモデル、AIエージェント、アプリケーション、ガバナンス、そして業務アクションまで含む、Enterprise Data & AI Platformの全体像へつながっていきました。
Oracle Databaseを長く触ってきた自分にとっても、Oracle DatabaseとData Lake、Lakehouseを競合するものとして見るのではなく、レイヤーを分けて組み合わせて考えることで、それぞれの得意な役割が、かえってはっきり見えてきました。
Oracleだけですべてを置き換えるのではなく、Object Storage、Parquet、Iceberg、Data Catalog、各Cloudのサービスなど、それぞれが得意なところを活かしながら、Oracle Databaseからつなげて使う。
ここが今回、整理していて一番面白いと感じたところです。
AI時代のデータ基盤では、データを大量に保存するだけでは十分ではありません。
AIがデータの意味を理解し、あらかじめ定義された権限とポリシーに基づいて利用可能な範囲を確認し、回答や業務アクションの根拠まで説明できるように、人間側がデータ、メタデータ、セマンティクス、権限、ガバナンスを設計しておく必要があります。
これからは、Data Lakeを作る、Lakehouseを作る、AIを導入するという個別の話だけでなく、次の循環全体を、どのように安全で再利用可能な仕組みとして設計するかが重要になりそうです。
Data
↓
Context
↓
Intelligence
↓
Decision
↓
Action
↓
Feedback
└─────────→ Dataへ戻る
今後は今回整理した全体像をもとに、Data CatalogやSemantic LayerがAIエージェントへデータの意味や権限をどのように伝え、実際の業務アクションまで安全につなげられるのかも、一つずつ試してみてみたいと思います。
■ 解説
初心者でもわかりやすいように解説しています。セールストークにどうぞ。
■ おまけ
■ 参考資料
- AWS - What is a Data Lake?
- Oracle AI Database 26ai Data Warehousing Guide - Introduction to Data Warehousing Concepts
- Oracle AI Database 26ai Data Warehousing Guide
- Oracle AI Database 26ai In-Memory Guide - Introduction
- Apache Parquet - Overview
- Apache Iceberg - Introduction
- Apache Iceberg - Java API Quickstart
- AWS Glue - Managing the Data Catalog
- Databricks - Lakebase Postgres
- Databricks - Databricks reference architectures
- Oracle - AI Data Platform
- Microsoft Learn - Microsoft Fabric documentation
- Microsoft Learn - Data architecture for AI agents across your organization
- Google Cloud - Agentic AI use case: Build a cross-cloud open data lakehouse