Lakehouseの要！Open Table Format深掘り（OCHaCafe Season 11 #6）

Lakehouseの要︕ Open Table Format深掘り AI時代のデータ基盤を考えるための基礎技術 Yuko Shibata July 15, 2026

Yuko Shibata クラウド・ソリューション統括クラウド・ソリューション推進本部 AIソリューション推進部 #OCHaCafe @yushibats 2 Copyright ©
2026, Oracle and/or its aﬃliates

今⽇のゴール細かい機能や仕様より、"どういうものか"の解像度を上げる ① AI時代のデータ基盤としてのレイクハウスの概念がわかる ② Open Table Format / Apache
Iceberg を、機能・仕様でなく"コンセプト"でつかむ ③ 複数⽤途でデータを“共有する”ための課題と、それを解決する仕組みがわかる → 「ちょっと触ってみようかな」となる 3 Copyright © 2026, Oracle and/or its affiliates

アジェンダ 4 1 2 3 4 5 なぜ今、 Open Table
Format︖ OTFが解決する課題 Apache Icebergの仕組み深掘りデモで⾒る Iceberg オープンな基盤から、AIへ Copyright © 2026, Oracle and/or its affiliates まとめ

1 なぜ今、Open Table Format︖ ▶ 従来のデータ活⽤基盤に、いま新たに何が求められているのかを考える 5 Copyright © 2026,
Oracle and/or its affiliates

企業には多くのデータソースが存在する従来のデータ活⽤︓各システムからDWHやデータマートに集め、BIやレポートで使うデータソース業務DB Oracle Databaseなど ERP CRM SaaS ログデータ
ファイルデータ DWHやデータマート利⽤者（BI・レポート） 6 Copyright © 2026, Oracle and/or its affiliates 経営層向けレポート営業担当マーケティング担当

この構成ではデータ活⽤の単位が⽐較的明確業務処理はSoR / 集計レポートはDWH / ⽣データやログはデータレイクデータソース業務DB Oracle Databaseなど
業務処理は ERP SoR 集計レポートは DWH DWHやデータマート利⽤者（BI・レポート） 7 Copyright © 2026, Oracle and/or its affiliates ⽣データやログはログデータデータレイクファイルデータ CRM SaaS 経営層向けレポート営業担当マーケティング担当

AIで変わること︓①データソースが増える構造化データに加えて、センサー・画像・⾳声・ログ・書類など、半構造・⾮構造化データが⼊⼒対象になるデータソース業務DB Oracle Databaseなど CRM SaaS ERP センサーデータ
IoTデータ地理空間データ気象データ外部ソースインターネットログデータ⼿書き/FAX 書類 Webアクセスログアプリケーションログ画像データファイルデータ⾳声データ … AIで“読ませたい”対象に加わったデータデータの種類が増えるだけなら、従来の「集める」の延⻑で対応できるが、より⼤きな変化は、次の“読み⼿”にある 8 Copyright © 2026, Oracle and/or its affiliates

AIで変わること︓②同じデータを読む処理エンジンが増える BI・ETL・ML・横断分析・RAGなど読み⼿が⼀気に増えるのがAI時代の⼤きな変化データソース（これまで + AIで増えた分） 1つの“同じデータ” BI / SQL分析 Spark
ETL・特徴量機械学習モデル学習 Trino 横断アドホックデータを読む処理エンジンそのものが増える 9 Copyright © 2026, Oracle and/or its affiliates RAG ベクトル検索 AIエージェント

実際に起きること︓エンジンごとのデータコピーが増える DWHから抽出してS3⽤・Spark⽤・ML⽤などコピーの分岐が増えるデータソース業務DB Oracle Databaseなど ERP センサーデータ IoTデータ地理空間データ
気象データ外部ソースインターネット 10 Copyright © 2026, Oracle and/or its affiliates CRM SaaS ログデータ⼿書き/FAX 書類 Webアクセスログアプリケーションログ画像データファイルデータ⾳声データ …

コピーが増えると増える負担コピーを増やすほど、「同じデータ」ではなくなる鮮度 — どれが最新のデータか分からない、コピーに時間がかかり古くなるコスト — ストレージ、転送、ETL維持のコストが増え続けるガバナンス —
権限やマスキングの基準がコピーごとにバラつく再現性 — “あの⽇のデータ”をもう⼀度作れないコピーの分岐が原因で、現場の「数字が合わない問題」が起こる 11 Copyright © 2026, Oracle and/or its affiliates

DWHに「集める」の限界多様化するデータをすべて1つのDWHに集めるのは難しいすべてを1つのDWHに集めると… ✕ ⼤量・多様なデータを⼊れるとコストが上がる ✕ ログ・半構造化・機械学習⽤データを扱いにくい ✕ 特定のDWHエンジンに処理が寄りやすい ✕
別エンジンで使いたいときにコピーが増える ✕ 将来、製品の基盤を変えづらい（ロックイン）低コストなクラウドストレージ上にデータを置き、複数エンジンから使える形にしたい。 Armbrust et al. “Lakehouse” (CIDR 2021)︓DWH＋データレイクの⼆層構成の課題として信頼性・鮮度・⼆重コスト・ロックインを挙げる 12 Copyright © 2026, Oracle and/or its affiliates

ここまでの整理︓AI時代のデータ基盤へのニーズ「もっと多様なデータを」「もっと多くのエンジンで」とその対応ニーズ① もっと多様なデータを扱いたい置き場は「安くて無限に置ける」クラウドストレージが適する画像・ログ・⽂書・⾳声までAIの⼊⼒になるニーズ② 同じデータを、多くのエンジンで使いたいエンジンごとにその⽤途専⽤のコピーを持つことになる BI・Spark
ETL・ML学習・RAG…読み⼿が⼀気に増えた扱うデータや、その使い道（エンジン）が多様化、これからも増え続けるコピーを増やさずに、それをどう実現するか 13 Copyright © 2026, Oracle and/or its affiliates

⽬指す形︓データは動かさず、エンジンが読みに来るストレージとエンジンを分離し、Object Storage上の“1つのデータ”を複数エンジンで共有する SQL分析 Spark Python Trino Databricks Snowflake など
様々なエンジンが読みに来る Open Table Format（例︓Apache Iceberg）— ファイル群を“テーブル”として管理するレイヤー Object Storage — データは“1つだけ”。ここから動かさないこの形の利点 ① 安価に⼤量に置ける ② コピーを配らない ③ どのエンジンでも不整合なしデータの置き場は1つ、どのエンジンからも読める 14 Copyright © 2026, Oracle and/or its affiliates

データレイクとDWHの“いいとこ取り” 「レイクハウス」データレイクの開放性・低コスト × DWHの管理機能。その中核技術がOpen Table Format 15 RDB
/ DWH 業務アプリに分散したデータを、集計して中央に集約。データサイロを解消し、全社横断の分析を実現。 DWH専⽤機 Netezza等、⼤量データを⾼速に処理する専⽤アプライアンスや並列処理技術(MPP)が普及。DWHの性能課題を克服。ビッグデータ Webログ・位置情報・センサー・画像など、⼤量かつ多様なデータが急増。従来DWHでは対応が困難に。データレイクに⾜りなかった管理を担う — ここがOTF データレイク構造化・⾮構造化データを⽣データのまま安価なクラウドストレージに蓄積。柔軟性は⾼いが、運⽤・品質管理が課題。レイクハウスデータレイクの「柔軟な蓄積」とDWHの「信頼性・管理性」を統合。 2021年、CIDR会議の論⽂（Armbrustら）で定式化。管理層の実装がOpen Table Format。 Copyright © 2026, Oracle and/or its affiliates

位置づけ︓置き換えではなく、共有レイヤー SoRとDWHは担う役割が異なる。OTFはどこからも参照できる共有データ層を担う。 DWH︓ 分析するデータレイク︓ 保持する分析向けに整備されたデータを⾼速に集計・参照する領域 BI、レポート、定型分析、ダッシュボードに強い
Open Table Formatの概念と対⽴するものではなく、DWHやSQL エンジンが参照する共有データ層として使われることがある • Object Storageなどに低コストで⼤量データを保存できる SoR︓ 記録する • • • SoR ＝ System of Record 業務トランザクションの正本を管理する領域業務整合性、トランザクション処理、低レイテンシ、厳格な更新制御が求められる Open Table Format︓ 状態を管理する 16 Copyright © 2026, Oracle and/or its affiliates • • • • • ただし、単にParquetやCSVファイルを置くだけでは以下のような課題 • テーブルとしての⼀貫性 • スキーマ変更 • 履歴管理 • 削除更新 Object Storage上のファイル群をテーブルとして扱うための仕様・仕組み

第1章まとめ AI時代に求められること︓データを1つのエンジンに閉じ込めず、複数エンジンから利⽤できる形で管理する 1 AI活⽤で、同じデータの読み⼿（エンジン・利⽤者）が増えていく 2 エンジンごとのコピー運⽤は、鮮度・コスト・ガバナンス・再現性などの課題を⽣む 3 基本の考え⽅︓置き場を1つにして、エンジンが読みに来る（＝レイクハウス構成） 4
DWHやSoRの置き換えではなく、全員の⼟台となれる “共有テーブルレイヤー”を⾜す What’s next? 17 安価な置き場に“置くだけ”で、共有データ基盤にはならない → どのような仕組みで実現するか Copyright © 2026, Oracle and/or its affiliates

2 Open Table Formatが解決する課題 ▶ 共有データソースにするとどんな課題が⽣じるのか、解決すべきポイントを理解する 18 Copyright © 2026,
Oracle and/or its affiliates

複数のエンジンから使う共有データソース︓ストレージとエンジンを分ける⼀体型のDWHから、置き場と計算を分ける構成へこれまで︓DWH＝⼀体型分析エンジンこれから︓置き場と計算を分ける・計算と置き場が⼀体 BI Spark ML・RAG ・このエンジン経由でしか触
れないストレージ・増設も⼀体＝⾼コスト AI時代の量・多様さ・読み⼿の数に、 1つの箱では追いつかない Object Storage（共通の置き場）・どのエンジンからも同じデータへ・置き場は安く⼤量に、計算は使う分だけただしObject storageにファイルを置くだけでは “ただのファイル置き場” テーブルとしての管理機能をどう⾜すかがポイント 19 Copyright © 2026, Oracle and/or its affiliates

データレイクの課題— Object Storageは優れた"置き場"、ただし管理までは担わない⼤量のデータを低コストで保存し共有できる。ただし提供されるのは"ファイル置き場"までバケット file file file file file
file 構造は「フォルダとファイル」だけただし—— ◎ 低コスト⼤容量でも安価に保存 ◎ 実質無限のスケール容量計画からの解放 ◎ ⾼い耐久性複製・冗⻑化はサービス任せ ◎ どこからでもアクセス HTTPで全エンジン・全チームから共有可更新はファイル全体の置き換え／リネームは実質コピー／⼀覧取得（LIST）は遅い「どれが今のテーブルか」「更新中かどうか」を知る術がない。そもそも”テーブル”という概念が存在しない。 20 Copyright © 2026, Oracle and/or its affiliates

全体像︓データ分析スタックの5層エンジンは計算、カタログは名前解決、テーブルフォーマットはテーブルの定義、ファイルフォーマットは中⾝の持ち⽅、ストレージは置き場クエリエンジンカタログ AWS Glue Data Catalog テーブル
フォーマットファイルフォーマットストレージ 21 Copyright © 2026, Oracle and/or its affiliates json csv

全体像︓データ分析スタックの5層エンジンは計算、カタログは名前解決、テーブルフォーマットはテーブルの定義、ファイルフォーマットは中⾝の持ち⽅、ストレージは置き場クエリエンジンカタログ AWS Glue Data Catalog ↑↓
Open Table Formatでの読み書きテーブルフォーマットファイルフォーマットストレージ 22 Copyright © 2026, Oracle and/or its affiliates 本⽇の主題 json ↑↓ メタデータの管理、効率的なデータ操作など csv

ファイルフォーマットの代表例︓Parquet形式列指向・圧縮・統計で「1ファイルの中の分析効率」を最適化する⾏指向（CSVなど）列指向（Parquet） 1⾏ずつ格納 — 1列だけ欲しくても全列を読む列ごとに格納 — 必要な列だけ読む・強く圧縮できる
ファイル内に列のmin/max等の統計も持つ ▶ファイルを開く前に統計情報を確認し、効率的に読み取る管理できるのは“ファイル1個の内側” ファイル“群”をテーブルとして束ねる仕組みはない → それがないと何が起きるか 23 Copyright © 2026, Oracle and/or its affiliates

“ファイルの外側”を管理しないと、データの整合性が崩れる更新の途中に読みに来た読み⼿は、新旧が混ざった“存在しないはずの状態”を⾒てしまう時間処理エンジン︓10ファイルを書き換え中新新新旧旧旧
旧旧旧旧 3個だけ書き換え済み（残り7個はこれから）この瞬間、読み⼿がディレクトリをLISTして読む新3ファイル + 旧7ファイルの混合を読む件数も合計⾦額も“どの時点にも存在しない値”になる 24 Copyright © 2026, Oracle and/or its affiliates ディレクトリには「書き込み中」という札を出せない

⾜りないのは“テーブルとしての管理” 4つの課題これらを解決するレイヤーがあることで、ファイル群がテーブルとして扱えるようになる ① ⼀貫性 ② 現在と履歴・更新途中の不整合が⾒える・どのファイル集合が“今の正”か分からない・複数書き⼿・読み⼿の整合が取れない
・過去の状態・変更履歴を保持できない ③ 変化への対応 ④ 発⾒と権限・スキーマ変更（列の追加・改名）が危険・テーブル名・所在を引く台帳がない・パーティション構成を後から変えられない・アクセス権限を⼀元管理できないこの4つを提供するレイヤーが Open Table Format。ファイル群に“テーブルとしての構造・履歴・⼀貫性・更新管理”を与える 25 Copyright © 2026, Oracle and/or its affiliates

Open Table Formatの原点︓Hiveテーブル形式が実現したことと限界「ディレクトリ＝パーティション」でビッグデータのSQL化を実現。ただしHDFS時代が前提限界 ✕ 原⼦性がない仕組みメタストア (RDB)
sales/ ✕ 状態の⼆重管理 year=2025/part-0001.parquet メタストアと実ファイルがズレうる year=2026/part-0001.parquet パーティションの場所はメタストア（RDB）に登録。個々のデータファイルは追跡しない。複数ファイル・複数パーティションの更新が中途半端に⾒えるファイルシステムテーブルの状態が 2箇所に割れる ✕ ⼤量のLIST操作クエリ計画がパーティション数に⽐例して遅くなる ✕ ⼈がパーティションを意識 WHERE dt=…を書き忘れるとフルスキャン ✕ オブジェクト・ストレージと不整合 rename前提の設計がクラウドで安全に成⽴しない設計前提（HDFS時代）が変わった —次はテーブルの定義を“フォルダ”から“ファイルの⼀覧”へ移す 26 Copyright © 2026, Oracle and/or its affiliates

３社それぞれの課題から誕⽣— Iceberg・Hudi・Delta Lake 2016〜2019年に相次いで登場し、いずれもOSSとして公開されている 2016 2017 2019 本⽇深掘り Uber →
Apache Hudi 2016年〜（2019年 Apache⼊り）課題 Netflix → Apache Iceberg 2017年〜（2018年ASF寄贈 → 2020年トップレベル）課題配⾞データを準リアルタイムでデータレイクに反映したいアプローチ 100PB級のS3データで、Hiveの正確性・スケール限界を解決したいアプローチ⾏レベル更新（upsert）と増分処理の先駆ファイル単位の追跡＋変更をまとめて1回で commit Databricks → Delta Lake 2019年OSS化（のちLinux Foundation傘下）課題バッチとストリーミングを1つの信頼できるテーブルで扱いたいアプローチトランザクションログ（_delta_log）⽅式優先課題がそのままフォーマットの個性になっているが、⽬指したものは同じ「ファイル群にテーブルの信頼性を与える」 27 Copyright © 2026, Oracle and/or its affiliates

第2章まとめ “テーブルとしての管理”を担うのがOpen Table Format 1 ⼤量のデータの置き場はオブジェクト・ストレージ︓安価でどのエンジンからも共有できる 2 ただしファイルを置くだけでは4つが⽋ける︓⼀貫性／現在と履歴／変化への対応／発⾒と権限 3
この⽋落を埋めるレイヤーがOTF︓3社それぞれの課題から⽣まれ、Apache Icebergが代表例 What’s Next? 28 Icebergはこの4つの課題を、どんな仕組みで埋めるのか︖——4つの問いで⾒ていきます。 Copyright © 2026, Oracle and/or its affiliates

3 Apache Icebergの仕組み深掘り Q1 複数エンジンは、どうやって同じテーブルを⾒つける︖ Q2 どのファイルが“今のテーブル”︖ Q3 更新中の未完成データを、なぜ読み⼿は読まない︖
Q4 過去のデータをどう再現する︖ まず構成要素の“名前”と“実体”を掴んでから、この4問に1つずつ答えていきます。 29 Copyright © 2026, Oracle and/or its affiliates

Open Table Formatとは︖ Apache Icebergとは︖ “深掘り”に⼊る前に、2つの⾔葉の意味を確認 Open Table Format（OTF）とは Apache
Iceberg とは Object Storage上に置いた⼤量のファイル（Parquet等）を、そのOTFを実装した、代表的なオープンソース。 “1つのテーブル”として扱うためのオープンな仕様 Netflix発 → Apacheプロジェクト → 事実上の標準ファイル群に、“テーブルの意味”を⾜す︓ OTFという“仕様”に対する“実物”︓ ・どれが今の正しいデータか（現在と履歴）・主要エンジン（ADB・Spark・Trino…）が対応・更新しても壊れない⼀貫性（commit）・主要クラウド・製品が続々サポート・スキーマ・パーティションの変更に対応・今⽇の深掘りは、この実物の中⾝を⾒ること・カタログ経由で複数エンジンから共有 “仕様”だから特定の製品に縛られない——これがマルチエンジンで同じデータを共有できる⼟台 30 Copyright © 2026, Oracle and/or its affiliates

ここで深掘らないこと「仕組みの勘所」に集中します。次の内容は割愛します実装の「内部」（本編は概念まで）今⽇の「範囲外」のトピック・⾏レベル更新の⽅式（COW／MOR）と削除の内部動作・他フォーマット（Delta Lake／Hudi）との仕様⽐較（deletion vector・Puffin ファイル）
・スキーマ／パーティション進化の詳細ルール・データ／メタデータ各ファイルの中⾝（スキーマ・統計）・Branch／Tag（WAP）などの応⽤機能・同時実⾏制御の内部実装（「概念」だけ触れます）・ストリーミング取り込み（Flink 等）・ファイル形式（Parquet 等）や圧縮・エンコーディング・エンジン別の SQL 構⽂・性能チューニング・カタログ製品ごとの構築・運⽤⼿順・セキュリティ／アクセス制御の実装詳細（Hive Metastore／REST／JDBC／各クラウド） ※ これらは「知らなくてよい」のではなく、「今⽇の主題（仕組みの勘所）から外れる」ので割愛、という意味です。 31 Copyright © 2026, Oracle and/or its affiliates

Icebergの全体アーキテクチャ — 構成要素は5種類 Catalog → metadata file → manifest list（＝snapshot）→
manifest file → data file metadata layer catalog Catalog db.table1 → 現在のmetadataの場所 manifest list metadata file r3 metadata file r2 s2 s1 s1 manifest list manifest list manifest file manifest file catalog = このテーブル metadata file = テーブル全体に関する定義と履歴（テーブルの状態が変わるたびに作成される） metadata file r1 s0 s0 manifest list manifest file manifest list manifest file スナップショット = ある時点でのデータファイルの集合（INSERT、DELETE、MERGE、Compactionなどデータの状態の変更があるたび作成される） manifest list = あるスナップショトが使うマニフェストの⼀覧 data layer manifest file = データファイル/削除ファイルの⼀覧 32 data file data file Copyright © 2026, Oracle and/or its affiliates data file data file data file ＝実際のデータファイル、削除ファイルなど

Icebergの実体 — いつ、何が作られる︖ 書き込み時のライフサイクル 1 CREATE TABLE 2 1回⽬のINSERT 3
2回⽬のINSERT TABLE LOCATION oci://<bucket>@<namespace>/iceberg/db/sales/ STEP 1 / 3 metadata/ CREATE TABLE v1.metadata.json CREATE TABLE dev.db.sales (…) data/ NEW （まだ空） Parquetは1回⽬のINSERTで⽣まれる USING iceberg; 2 0 0 この操作で新規この操作で更新すでに存在ここがポイント CREATE TABLEで作られるのは metadata（テーブルの設計図）だけ。dataはまだ無い現在の版を指すポインタはカタログが保持（⻘い⾏が現在） 33 Copyright © 2026, Oracle and/or its affiliates

2回⽬のINSERT TABLE LOCATION oci://<bucket>@<namespace>/iceberg/db/sales/ STEP 2 / 3 1回⽬の INSERT INSERT INTO dev.db.sales VALUES (1, 'apple'), …; -- COMMIT 4 1 1 この操作で新規この操作で更新すでに存在 metadata/ data/ v1.metadata.json 00000-0-7f8….parquet v2.metadata.json NEW 7bfc…-m0.avro NEW snap-83b….avro NEW NEW この INSERT＋COMMIT で作られる順番 ① 実データを Parquet ファイル（既定）で書く ② その Parquet を列挙する Manifest File ③ Manifest File を列挙する Manifest List ④ 新しい snapshot を含む metadata.json ⑤ カタログのポインタを更新（＝commit）ここがポイント INSERT＋COMMITで snapshot が1つ⽣まれる——data ・manifest・manifest listが揃い、metadataはv2へ世代交代現在の版を指すポインタはカタログが保持（⻘い⾏が現在） 34 Copyright © 2026, Oracle and/or its affiliates

2回⽬のINSERT TABLE LOCATION oci://<bucket>@<namespace>/iceberg/db/sales/ STEP 3 / 3 2回⽬の INSERT INSERT INTO dev.db.sales VALUES (4, 'grape'), …; -- COMMIT metadata/ data/ v1.metadata.json 00000-0-7f8….parquet v2.metadata.json 00000-0-a91….parquet NEW 7bfc…-m0.avro 2回⽬の INSERT で追記される差分 4 1 5 この操作で新規この操作で更新すでに存在ここがポイント既存ファイルは⼀切書き換えず、新しいファイルが増えるだけ。過去の版が残る＝time travelの⼟台（ポインタ切り替え＝ snap-83b….avro ① 新しいデータファイルを作る ② それを登録する Manifest file 2 を作る v3.metadata.json NEW snap-102….avro NEW a91d…-m0.avro ④ Snapshot 2 を加えた metadata.json を作る（current-snapshot-id → S2） NEW ⑤ カタログのポインタが新しい metadata.json へ（＝commit） ③ Manifest 1＋2 を指す Snapshot 2 ⽤の Manifest List を作る commit の詳しい話は、後ほど Q3 で）読み順 ① Catalog → ② metadata.json → ③ manifest list → ④ manifest → ⑤ data file 現在の版を指すポインタはカタログが保持（⻘い⾏が現在） 35 Copyright © 2026, Oracle and/or its affiliates

Q1︓どのように“同じテーブル”を⾒つける︖ — Catalogの役割カタログは「テーブル名 → 現在のmetadataファイルの場所」を返す台帳の役割。データは中継しない ADB Spark Trino ①
まずカタログに聞く︓ 「sales.orders は︖」→ 現在のmetadataの場所が返る Catalog（AICAT） sales.orders → oci://…/v3.metadata.json（場所を返すだけ・データは中継しない） ② データ本体は直接読み書き OCI Object Storage — metadata / data の実ファイル “同じテーブルを⾒ている”とは＝同じカタログから、同じポインタをもらっていること 36 Copyright © 2026, Oracle and/or its affiliates

Q1︓どのように“同じテーブル”を⾒つける︖ — Catalogの要件だから多様なバックエンドが“Icebergカタログ”になれる ① 現⾏metadataポインタを保持する ② それをアトミックに更新できる（check-and-put /
compare-and-swap）本質はatomic pointer swap ＝ commitを成⽴させる唯⼀の要件実装は多様な選択肢を検討できる Hive Metastore Hadoop AWS Glue JDBC （RDBの1⾏） Object Storage RESTカタログ（現在主流の共通API） Apache Polaris / Unity Catalog / Apache Gravitino / S3 Tables / 本⽇デモで使⽤ Oracle AI Data Catalog（AICAT） … 補⾜︓ファイル名のrenameでcommitする旧⽅式（Hadoop Catalog系）は、S3系ストレージでは競合検出が弱くコミュニティが⾮推奨と決定 37 Copyright © 2026, Oracle and/or its affiliates Nessie

Q2︓テーブルの「現在の状態」はどう決まるのか metadata.jsonのcurrent-snapshot-idが指すスナップショットが、読み取り時に⾒えるデータを⼀意に規定 metadata.json が持つもの・schemas（列の定義）・partition-spec（分割の定義）読み取り時の解決順序 Catalog 最新のmetadata.jsonの位置を保持 v3.metadata.json（現在の版）
current-snapshot-id = S2 ・snapshot ⼀覧（＝保持されている履歴すべて） current-snapshot-id ← 「現在の状態」として参照されるsnapshotを⽰す snapshot S2 ＝ manifest list このsnapshotに属する manifestの⼀覧、manifest listを指す manifest → data files ＝読み取り対象のデータファイル（Parquetファイル群）が決まるテーブルの“状態”は全部このファイルに。だから、ここを⾒れば「今」が分かるエンジンは current-snapshot-id 以外を参照しないため、読み取り時点の状態が⼀意に定まるコミットは metadata.json の上書きではなく新しいバージョンの⽣成(v1 → v2 → v3) カタログが保持するポインタをアトミックに差し替えることで、読み取り側は常に整合した1つの版を参照する 38 Copyright © 2026, Oracle and/or its affiliates

Q2︓manifestは“索引”でもある — 開けずに、必要なものだけ取り出す data file を読む前に、manifest list と manifest の統計からスキャン対象を絞り込む
例えるなら — manifest list は「引き出し⼀覧」、manifest は「引き出しの中の⽬録」。どちらも中⾝が外から読めるので、開ける引き出しを先に決められる統計で読むファイルを絞り込む manifest list manifest A day: 07-01〜07-07 ✕ manifest A 07/01〜07/07 WHERE day = '2026-07-10' manifest B 07/08〜07/10 manifest C 07/11〜 manifest B day: 07-08〜07-10 → f1.parquet f2.parquet f3.parquet manifest C day: 07-11〜 ✕ f4.parquet ラベルを2段たどるだけで、読むファイルが決まる。Iceberg はメタデータに統計があるため、ストレージにファイル⼀覧を問い合わせる必要がない。 39 Copyright © 2026, Oracle and/or its affiliates

Q3︓更新中の未完成データを、なぜ読み⼿は読まない︖更新の流れ新しいデータとmetadata⼀式を“横に”書いておき、最後にポインタ1個を差し替える（＝commit） ◀ 書く（何度でも・時間がかかってよい） ① 現在 = S0 Catalog ②
→ v2 (S0) ③ → v2 (S0) Catalog v2 (S0) 新metadata（S1）を書く v2 (S0) 新 S0の世界は何も変わらない新 ④ → v2 (S0) Catalog v2 (S0) 新読み⼿はS0を読む新data fileを“横に”書く公開（⼀瞬・原⼦的） ▶ まだ誰にも⾒えない → v3 (S1) Catalog v3 (S1) 新 commit＝ポインタを1個だけ上書き v2 (S0) 新 v3 (S1) 新 CASで⼀瞬・原⼦的に公開 commit の実体＝カタログが持つ「現在の metadata.json の場所」を v2.metadata.json → v3.metadata.json に原⼦的に上書き（CAS）するだけ。data も既存ファイルも書き換えない。 40 Copyright © 2026, Oracle and/or its affiliates

Q3補⾜︓書き込み⼀貫性 — 同時に書いても、⽚⽅の更新は消えない commit はカタログのポインタ切替。では同時に2⼈が書いたら︖ ——CAS（compare-and-swap）で先勝ち・後発はやり直し書き⼿ A ✓ A:
差し替え成功（commit） Catalog CAS （compare-and-swap）書き⼿ B ✕ B: 前提が古いので失敗 → 最新 snapshot を⼟台に変更を作り直してリトライ（論理的に衝突すれば検証エラー）だから同時書き込みでも“更新の取りこぼし（lost update）”が起きない。失敗した側（今回は書き⼿B）もデータを失わない。 41 Copyright © 2026, Oracle and/or its affiliates

Q3続き︓読み⼿がS0しか⾒ない理由 — 読み取り⼀貫性（snapshot isolation）読み⼿は読み始めに掴んだsnapshotを最後まで使う。ロックは取らない。commit後に読み直せばS1 commit（原⼦的）読み⼿ 1 S0で読み続ける（途中でcommitが起きても影響なし）書き⼿
新data file + 新metadataを“横に”書く → commit 読み⼿ 2 S1で読む（commit後に開始）時間仕様の保証︓読み取りは常にcommit済みsnapshotを使い、書き込みが部分的に⾒えることはない metadataファイルのアトミック交換が "the basis for serializable isolation"（Apache Iceberg Table Spec） 42 Copyright © 2026, Oracle and/or its affiliates

Q4︓過去をどう再現する︖ — Time travel とロールバック snapshotは保持期限内は消えない。過去を“読む”のがTime travel、“今”を過去に戻すのがロールバック S0 S1 S2
初期ロード MERGE後現在 Time travel ＝過去を“読む” 過去のsnapshotをID・時刻で指定して読むだけ。テーブルの“今”は変わらない。 SELECT … FROM orders FOR VERSION AS OF <S0のID> ⽤途︓障害調査／監査／MLの学習時点を固定（→第5章） commitのたびにsnapshotが履歴として積み上がる保持期限内はどれも消えないので、過去のどの時点にも戻れるスナップショットのロールバック＝ “今”を過去に戻す現在のポインタを過去のsnapshotに戻す。戻した状態が新しい“今”としてcommitされる。 CALL … rollback_to_snapshot('orders', <S1のID>) ⽤途︓誤った更新をまるごと巻き戻す（メタデータ操作なので⼀瞬）どちらも“履歴が残る”という同じ仕組みの上に成り⽴つ。過去は消さずに積み上げるのがIcebergの前提 ※ tag / branch という“名前付き参照”も仕様にある。無限には残らず、保持ポリシー（次ページのメンテナンス）で管理する 43 Copyright © 2026, Oracle and/or its affiliates

Iceberg が備えるもう⼀つの柱︓テーブルの変化に対応するスキーマやパーティションの変更は metadata の更新だけで完結する。既存の data file は書き換えない Schema Evolution
— スキーマの進化列列を名前ではなく“列ID”で追跡。列の追加・改名・削除・型拡張を、既存データファイルを書き換えずに⾏えるだから CSV時代の“列ズレで全滅”が起きない Hidden Partitioning — 隠しパーティション区「day(order_ts)」のような“値からの変換”をメタデータが管理。利⽤者は普通のWHEREを書くだけで⾃動的に枝刈りが効くだから⼈⼯の区分列を書き忘れる事故がない Partition Evolution — パーティションの進化粒パーティションの粒度（⽉→⽇など）を後から変更しても、過去のデータは書き換えない。新旧のspecはメタデータが区別だから運⽤が⻑くなるほど効いてくるこれらはIcebergの“テーブルフォーマット仕様”そのものの機能——特定のエンジンによらず標準で使える 44 Copyright © 2026, Oracle and/or its affiliates

（補⾜）Schema Evolution — スキーマが変わっても同じテーブル列は名前ではなく“列ID”で追跡。既存データファイルを書き換えずに、追加・改名・削除・型拡張できる列ID 昔のdata file 今のスキーマ id=1
order_id order_id id=2 amount amount_jpy id=3 （存在しない） status 旧parquet (order_id, amount) 新parquet (order_id, amount_jpy, status) 何が起きた︖ そのまま改名してもIDが同じ＝同じ列後から追加 → 旧ファイルはNULLで読める読むときに列IDで解決 → どちらのファイルも“1つのテーブル”として読める CSV時代の「列がズレて全滅」が起きない理由＝ID。ファイルはそのまま、スキーマだけ安全に進化する 45 Copyright © 2026, Oracle and/or its affiliates

（補⾜）Hidden Partitioning と Partition Evolution パーティションはメタデータが管理。利⽤者は通常のWHEREを書くだけ Hive︓⼈⼯列を⼈が意識する Iceberg︓変換をメタデータが知っている WHERE dt
= '2026-07-10' WHERE order_ts >= '2026-07-10' ・dtという“パーティション⽤の列”を別途⽤意・書き忘れると全ファイルスキャン・partition spec＝「day(order_ts)」という変換・普通のWHEREだけで⾃動的に枝刈り・tsとdtの関係をシステムは知らない・書き忘れフルスキャンが起きない Partition Evolution︓粒度を後から変えても、過去データは書き換えない〜6⽉のdata file群 partition spec︓month(order_ts) 7⽉〜のdata file群新spec︓day(order_ts) data fileはパーティション単位で分かれて作られ、どのファイルがどのspecかはmetadataが管理する——だから過去データを書き換えずにレイアウトを変更でき、クエリは透過的に両⽅を読む運⽤が⻑くなるほど効く——Hive経験者ほど刺さる機能 46 Copyright © 2026, Oracle and/or its affiliates

テーブルを健全に保つ機能（運⽤の管理操作）書き込みのたびに新しいsnapshotが増える。放置すると肥⼤化するので、ライフサイクル管理が必要になる前提︓Icebergは書き込みのたびにテーブルの新しいsnapshotを作る。Time travelやロールバックに便利な⼀⽅、放置するとsnapshot・metadata・data fileが際限なく増える → 適切なライフサイクルで“⽚付ける”操作が必要 Snapshot expiration
— 古いsnapshotの失効古いmetadataの削除 — メタデータの整理保持期間を過ぎた古いsnapshotを失効させ、それだけが参照していた不要なdata fileを削除する世代交代で増える古いmetadata.jsonを整理。テーブル設定（保持世代数）で⾃動削除もできる Orphan fileの削除 — 迷⼦ファイルの掃除 Compaction — ⼩ファイルの再編成書き込み失敗などで、どのsnapshotからも参照されなくなったファイルを掃除する（既定は3⽇より古いもの）追記で増えた⼩さなファイルを⼤きくまとめ直し、読み取り速度とメタデータの軽さを保つ位置づけ︓これらは“読み書きの仕組み”ではなく、テーブルを運⽤するための管理操作。エンジン（Sparkの⼿続き等）やマネージド基盤が定期的に実⾏する。⼀部はテーブル設定で⾃動化できる 47 Copyright © 2026, Oracle and/or its affiliates

第3章まとめ Catalog・metadata・snapshotが、ファイル群を“複数エンジンで共有できる1つのテーブル”にする 1 実体はすべて“ただのファイル”——だから、どのエンジンからも読める 2 「書く」と「公開する」の分離︓commit＝現⾏ポインタのアトミックな差し替え 3 読み⼿はcommit済みsnapshotだけを読む。書き⼿と衝突しない 4
履歴（Time travel）も、スキーマ進化やメンテナンスも、snapshot と metadata で実現される What’s next? 48 Copyright © 2026, Oracle and/or its affiliates ここまでが仕組み。次は実機で確かめます。

【デモ】複数エンジンが同じIcebergテーブルを共有し、更新中でも⼀貫した状態を読めるか︖ 読み⼿はADBとTrino、更新はSparkが実⾏——更新が⾛っても、どの業務も⽌まらない Object Storage上の「注⽂テーブル」を利⽤する部署受注管理部⾨経営企画部⾨データサイエンスデータ基盤チームデータ分析チーム
毎朝の受注・キャンセル・遅延の定型集計受注状況ダッシュボードの参照需要予測モデルの学習データ抽出配送状況など、後から届く変更の⼀括反映他部⾨データと組み合わせた横断分析 ADB BIツール Databricks など Spark Trino 書き込み今回のデモ今回のデモ MERGEによる⼀括更新が⾛っている最中でも、どの部署の読み取りも問題なく動き続ける読み⼿に⾒えるのは確定済みの状態だけ｜デモ画⾯︓✓ CREATE ICEBERG TABLE ✓ 読み⼿ループ ✓ MERGE実⾏ ✓ snapshot履歴 50 Copyright © 2026, Oracle and/or its affiliates

デモの進め⽅ 1つの注⽂テーブル（Olist・1週間・1,071件）を3エンジンで。左が“流れ”、右が“確認できること” デモの流れ STEP 1 → 5 確認できること 5 POINTS
1 ADBからIcebergテーブルを作成＋1,071件のデータを投⼊（S0） ✓ 3エンジンがコピーなしで同じ1テーブルを共有 2 ADBでS0を集計 ✓ 読み取り⼀貫性（更新中も⾒えるのはS0だけ） 3 TrinoでS0を読む ✓ commit境界（“書く”と“公開する”は別） 4 SparkからMERGEを実⾏し83件を修正読み⼿はS0のまま→ ✓ Time travel（過去のどの時点も再現） 5 履歴と Time travel（SQL 1句で過去へ）（“普通の表”に⾒える→実体はParquetファイル）（ADBで作成したデータを読む）

デモ構成︓共通カタログ（REST Catalog） + Object Storage + 3エンジン Oracle AI Data
Catalog (Iceberg REST Catalog) ADB 26ai 書き⼿・読み⼿ REST（名前解決とcommit） Trino 482 （読み⼿） OCI Compute Step 1・2. 作成・S0投⼊・集計 OCI Object Storage Step 3. Trinoで読む Step 4. SparkでMERGE 認証︓AICATへOAuth2（DBユーザー資格情報）／Object StorageへS3互換キー 52 Copyright © 2026, Oracle and/or its affiliates Spark 3.5（書き⼿） OCI Data Flow 5レイヤーのカテゴリ（凡例）エンジンカタログテーブルF ファイルF ストレージ

使⽤するデータ分析に利⽤するデータ︓ECサイトの注⽂データ orders テーブル︓ • ブラジルECサイト「Olist」の公開データ（Kaggle） order_id status purchase_ts e481f…
ACCEPTED 2017-09-04 • 初期は全件 order_status = 「ACCEPTED（受付済み）」＝S0 53cdb… ACCEPTED 2017-09-05 • その後更新 → 83件 = キャンセル12件 + 配送遅延71件 47770… ACCEPTED 2017-09-05 • 対象︓ 受発注データの、2018-08-20〜08-26の1週間の注⽂ = 1,071件 n データ更新の想定状態 53 accepted canceled delayed total S0（受付時点） 1,071 0 0 1,071 S1（MERGE後） 988 12 71 1,071 Copyright © 2026, Oracle and/or its affiliates 注⽂受付後にキャンセルや配送遅延が後から届くため更新が⾛る

Step 1︓ADBからS0を作る — SQLでオープンなIceberg tableを作成 OracleのSQLだけで、Object Storage上のオープンなIceberg tableを作成できる 1 2
3 CREATE ICEBERG TABLE …（WITHIN CATALOG "AICAT"） INSERT INTO … SELECT — 1,071件を 'ACCEPTED' で投⼊作成を確認 — AICATのカタログと、Object Storage上の実体ポイント・INSERTの完了と同時に、snapshot（S0）としてcommitされる・Object StorageにはParquet（データ）とmetadataが書かれる作成後にAICATのカタログ画⾯とObject Storageのバケットで、テーブルの実体ができていることを確認します・マウントされているAICAT（Iceberg REST Catalog）の参照先が最新のメタデータに更新される S0がcommitされ、作った瞬間から他のエンジンと共有される 54 Copyright © 2026, Oracle and/or its affiliates

Step 2︓ADBでS0を集計 → 通常のSelectで表が⾒える snapshotなどを意識しなくても、いつものSQLでcurrent data（最新のデータ）を読めるアクション︓同じテーブルを、通常のSELECTで集計する SELECT order_state, COUNT(*)
FROM "demo"."orders_…"@AICAT GROUP BY order_state; accepted canceled delayed 1,071 0 0 ＝ S0（受付時点）のまま技術ポイント・@AICAT というカタログ参照構⽂・ADBはRESTでmetadataの位置を取得し、data fileを直接読む ADBの利⽤者には、Iceberg tableが“普通の表”に⾒える 55 Copyright © 2026, Oracle and/or its affiliates

Step 3︓TrinoでS0を読む別エンジンからADBで作成した同じテーブル・同じデータを読むアクション︓ TrinoからSQLで、同じテーブルを集計する（スクリプトで実⾏） # step3.sh — Trino CLIに1クエリ
podman exec trino trino --execute " SELECT (直近の snapshot_id …), count_if(order_state='ACCEPTED'), count_if(order_state='CANCELED'), … FROM aicat.demo.orders_…" 画⾯に出る結果 snapshot=S0:1250675833300994520 accepted=1071 canceled=0 delayed=0 total=1071 これが意味すること・再コピーなしで、ADBが作ったテーブルをそのまま読めた・snapshot ID＝テーブルの“版番号”が⾒える技術ポイント・IcebergコネクタがAICATを参照（OAuth2）・snapshot IDは $snapshots メタデータ表から取得再コピーなしで、別のエンジンから同じテーブルが読めた 56 Copyright © 2026, Oracle and/or its affiliates

Step 4︓SparkでMERGE — 3つ⽬のエンジンが“書き⼿”に後から届いた83件（キャンセル12・配送遅延71）を、1回のMERGE（update-only）で反映する実⾏ OCI Data Flow でSparkアプリケーションをRun（Spark
3.5） 1,071件のうち、83件（キャンセル12件・配送遅延71件）をMERGE ⽅式 copy-on-write︓更新⾏を含むdata fileを新しいファイル群として書き直し、最後に1回だけcommit 時間書込みは約2分——意図的な遅延で“実務の⼤規模更新”の時間感覚を再現） ※ 書き込まれる data file は、例えば配送エリアごとに分かれている想定——更新は“該当エリアのファイルだけ”を書き直す。ここに注⽬——「書いている最中に、読んだら︖」 57 Copyright © 2026, Oracle and/or its affiliates

Step 4︓更新中も、⼀貫した状態を読み続ける——デモの核⼼読み⼿ループを実⾏し続けたまま、SparkのMERGE（約2分の書込み）を開始する 1 2 3 Trinoからループを実⾏し、1秒間隔でクエリを流し続ける（毎秒、snapshotと集計を表⽰） OCI Data
Flow からSparkのMERGEを実⾏（約2分）書き込み中に、ADBでも同じ集計を1回実⾏する画⾯の注⽬ポイント・data-filesが1→4と増える＝新ファイルは“存在”している・それでも読み⼿は 1071/0/0 のまま不動（ADBから⾒てもS0） commitがエンジン横断で唯⼀の切替点。次のスライドで実測値を確認・◀◀◀ COMMIT の⼀瞬だけで、ポインタが切り替わり 988/12/71（S1）へ新ファイルが“存在”しても、commitされるまで決して読まれない 58 Copyright © 2026, Oracle and/or its affiliates

実測︓ COMMIT の⼀瞬に、ポインタが指すSnapshotがS0 → S1 に切り替わる MERGE中もaccepted=1,071のまま不動（data-filesは増加）→ commit後の初回SELECTから988 / 12
/ 71 MERGE実⾏中（約2分）毎秒のSELECTは 1,071 / 0 / 0 のまま不動 data-filesは1→4に増加（読まれない） ◀◀◀ COMMIT の⼀瞬で 988 / 12 / 71（S1）へ⼀⻫切替以後 data-files=5（新4＋旧1。旧ファイルはStep 5で過去（S0）を読むために保持）事後検証（step4_verify）: 書込み完了→commitまで93秒間、読み⼿はS0のみ（S1・混在は0回） 59 Copyright © 2026, Oracle and/or its affiliates

検証記録ファイル書込み・commit・読み⼿の観測を集計 1 新しいdata fileが書き終わった時刻を、Object Storageの記録から取得 2 commitの時刻を、snapshotの記録から取得 — その間隔が93秒
3 その93秒間の読み⼿の観測を全数集計 → S0のみ（S1・新旧混在の参照はなかった）新ファイルの存在とcommitの間に“93秒の窓”があった間、途中の状態は⼀度も読まれていない commitされるとカタログのポインタがatomic（原⼦的）に置き換わるため、中途半端なデータが読まれない 60 Copyright © 2026, Oracle and/or its affiliates

補⾜︓もしこのテーブル管理が無かったら — “存在しない数字”が成功として返るフォルダ内のファイルの集まりで、commitという概念がない場合深夜バッチが更新している最中に、集計してしまうと… なぜ誰も気づけないか ✕ SQLはエラーなく成功するエリア1 更新済み
エリア2 旧のままエリア3 旧のままエリア4 旧のまま 4ファイル（配送エリアごと）のうち、1地域だけ置き換わった瞬間︓ 1,050 / 3 / 18（合計1,071）更新前（1,071/0/0）でも更新後（988/12/71）でもない、業務上存在しない中途半端な状態 ✕ 合計は1,071で合っている ✕ 処理が途中で⽌まると、中途半端な状態が残り続ける Icebergではこの中間状態が構造的に⾒えない——Step 4で⾒たとおり、S0 → ◀◀◀ COMMIT → S1 の2状態だけ 61 Copyright © 2026, Oracle and/or its affiliates

Step 5︓履歴とTime travel — SQLに1句加えて過去を読む Trinoから5つの確認クエリを順に実⾏する（デモ⽤スクリプトで進⾏） 1 履歴を確認する S0=append ←
S1=overwrite（親がS0） 2 現在（S1）の集計 → 988 / 12 / 71 更新されていることを確認 3 タイムトラベルを試す FOR VERSION AS OF <S0のID> を1句 → 1071 / 0 / 0 SELECT … FROM aicat.demo.orders_… FOR VERSION AS OF <S0のID>; -- 通常のSELECTにこの1句を追加なぜ戻れるのか・旧data fileと旧metadataが残っているから（Step 4の“data-files=5”はこのための保持）履歴はS0 ← S1と線形につながっている・不要になれば snapshot expire で削除 FOR VERSION AS OF を1句加えると、MERGE前の世界全体が読める 62 Copyright © 2026, Oracle and/or its affiliates

デモまとめ — 違いは「テーブル単位のcommit境界」があるかどうか観点テーブル管理がないと︖ 更新中に読み⼿が⾒るもの S0のみ（ファイルが増えても不動）中間状態が漏れる（1,050/3/18）更新後 commitの⼀瞬でS1へ
置換が終わった順に徐々に処理が途中で死んだら commitされない＝S0のまま無傷中途半端な状態が残り、SQLは成功し続ける過去に戻れるか time travel可（S0が読める）不可（上書きされたら消える） What’s next? 63 Iceberg（Step 4で実演）この⼀貫性がAI・データ活⽤の⼟台になる。AI活⽤のイメージを次のデモで。 Copyright © 2026, Oracle and/or its affiliates

同じテーブルが、そのままAIの⼊⼝になる SQL分析・ETL・ML・⾃然⾔語問い合わせ・ベクトル検索・RAGが、同じIcebergテーブルを再利⽤できる BI・SQL分析 Spark ETL ML学習 Select AI （⾃然⾔語→SQL） AI
Vector Search RAG・チャットボット demo.orders_… デモで作成した Icebergテーブル追加の置き場もコピーも作らず、同じテーブルがそのまま各⽤途の⼊⼝になる AIのためだけの“特別なデータ置き場”は作らない Icebergの価値は、個別の分析やAI機能ではなく——それらが共通して利⽤できる、オープンで⼀貫したデータの⼟台を提供すること 65 Copyright © 2026, Oracle and/or its affiliates

AIデモのアーキテクチャ ︓レビュー本⽂はIcebergでバケット内、ベクトル・索引をADB 受発注データで対象を絞り、レビューデータに対してベクトル検索を⾏い分析⽇本語の質問（ブラウザ） Webアプリ「配送分析アシスタント」（FastAPI）質問のたびに︓ ① 質問⽂を埋め込み（GenAI）
② ADBでベクトル検索 ③ 回答を⽣成（GenAI） ADB（Autonomous AI Database 26ai）作る・書く CREATE ICEBERG TABLE（AICAT経由）／INSERT×3 回 → snapshotが3時点積まれるベクトル表 REVIEWS_RETRO_EMB＝review_id・グループ・ VECTOR(1024, FLOAT32) のみ（本⽂は持たない） Object Storage Iceberg テーブルで保管︓ 受発注/配送ログ IVFベクトル索引顧客レビュー全件⽐較を避け、近傍クラスタだけを探索（近似検索）—— データが増えても検索を⾼速に保つ OCI Generative AI Trino — タイムトラベル読取りのみ SQL FOR VERSION AS OF で3時点の配送イベントを読取り・集計 AI Vector Search VECTOR_DISTANCE(emb, :qv, COSINE) でグループ別 top-8 × 2 ＝ 16件を抽出埋め込み︓cohere.embed-multilingual-v3.0 回答⽣成︓Gemini 2.5 Flash（⼤阪） ※ADBのIceberg読取りはタイムトラベル未対応のため、ここだけTrino データはすべて Object Storage 上の Iceberg（題材＝Kaggle の受発注/配送ログ＋顧客レビュー）。カタログ＝AICAT（ADB内蔵 REST）で、本編 Step 1〜5 と同じ基盤・専⽤の追加なし。 67 Copyright © 2026, Oracle and/or its affiliates

結果︓配送は3倍速くなった。しかし評価はほぼ改善しなかった遅れ平均4.0⽇ vs 12.0⽇、評価★2.0 vs ★1.54 数字だけでは⾒えないインサイトをAI分析で⾒る切り替えなかった注⽂（遅れ平均12.0⽇・★1.54）主な不満は「配送の遅さ」・到着まで時間がかかった
・予定⽇に間に合わなかった・もっと早く知らせてほしかった＝トラブルの影響がそのまま表れた群。改善アクションの⽐較基準になる切り替えた注⽂（遅れ平均4.0⽇・★2.0）配送は早くなった。⼀⽅で—— ・途中で追跡情報が⽌まった・配送会社が変わったことを知らされなかった・メールと追跡画⾯の⽇付が違った・「配達済み」と表⽰されたが届いていなかった・問い合わせ先が分からなかった・荷物の外装が傷んでいた結論︓到着は早くなったが、追跡情報と配送会社間の情報連携の問題が顧客の不安を増やしていた 68 Copyright © 2026, Oracle and/or its affiliates

このデモを⽀えている Iceberg オープンで⼀貫したテーブルが⼟台にあるから実現できる ① 最新は commit で⼀意に決まる ② "いつのデータか" を機械が読める
（commit時刻） ADB・Spark・Trino・AI が、常に commit 済みの最新 snapshot だけを読む。→ コピーや同期を配って回る必要がない。回答に「どの時点のデータか」を⾃動で付けられる。⽣のフォルダにはその情報がなく、監査や説明ができない。 ③ 過去時点をそのまま再現（time travel） ④ データを動かさない「あの時点ではどうだったか」に、当時のデータで答えられる。レポートの根拠を、後から正確に再現できる。本⽂もベクトルも Iceberg のまま、ADB は索引だけ。⼆重投⼊がなく、鮮度ズレの発⽣源をそもそも作らない（検索も常に commit 済みに⼀貫）。 AI の答えの質は、⼟台データで決まる AI は、外部からデータを読む⽴場。古いデータでも気づかず誤った回答をするので、⼟台となるデータの鮮度と⼀貫性が重要。誰でも “⾃然⾔語” で聞ける（SQL を書けなくても） 69 Copyright © 2026, Oracle and/or its affiliates 多⾔語を越えて “意味で” 検索（⽇本語の質問→ポルトガル語レビュー）膨⼤なデータ・⽂章を要約（読んで、まとめる）

本⽇のまとめ 1 2 3 4 5 70 AI時代に求められる「1つのデータ、複数のエンジン」エンジンごとのコピー運⽤は、鮮度・コスト・ガバナンス・再現性で破綻しやすい Object
Storage + Parquetは共有ストレージであって、共有テーブルではない⾜りないのは⼀貫性・履歴・変化対応・カタログ——“テーブルとしての管理” Icebergの仕組みは⼟台の４要素で成り⽴つ不変のデータファイル + 階層メタデータ + snapshot + カタログのアトミックなポインタ更新（commit）「書く」と「公開する」の分離（commit境界）更新中でも⼀貫した読み取り＝マルチエンジン共有を成⽴させる⼩さく始められる既存データを1テーブルIceberg化し、REST Catalog（例︓AICAT）経由で2エンジンから読むところから Copyright © 2026, Oracle and/or its affiliates

Lakehouseの要！Open Table Format深掘り（OCHaCafe Seaso...

Lakehouseの要！Open Table Format深掘り（OCHaCafe Season 11 #6）

More Decks by oracle4engineer

Featured

Transcript