はじめに
Oracle AI Data Platform Workbench、以下AIDP、でMedallion Architectureを体験するデモを作りました。
題材は架空のEC/小売データです。Notebook内でサンプルデータを生成し、RawファイルとしてManaged Volumeへ保存し、その後にBronze、Silver、GoldのManaged Tableへ段階的に加工します。
作成したデモ一式はGitHubに置いています。
- GitHub: https://github.com/shunsuke2828/aidp-medallion-demo
- Notebook: https://github.com/shunsuke2828/aidp-medallion-demo/blob/main/aidp_medallion_demo_cells.ipynb
この記事では、以下を整理します。
- なぜLakehouseやMedallion Architectureが必要なのか
- AIDP上でCatalog、Volume、Notebook、Spark Computeをどう使うのか
- Raw -> Bronze -> Silver -> Goldでデータがどう変わるのか
- 初心者がNotebookを読むときにどこを見ればよいか
- 一時Viewをなぜ使っているのか
今回作ったもの
このデモでは、架空のオンラインショップを想定し、次のデータを扱います。
| データ | 内容 | 使い道 |
|---|---|---|
| Customers | 顧客マスタ | 顧客360、都道府県別集計、顧客セグメント |
| Products | 商品マスタ | 商品別売上、カテゴリ別売上、粗利計算 |
| Orders | 注文ヘッダ | 注文日時、チャネル、支払方法、注文ステータス |
| Order Items | 注文明細 | 商品別数量、単価、値引き、売上計算 |
| Web Events | Web行動ログ | 閲覧、商品閲覧、カート追加、購入ファネル |
| Reviews | 商品レビュー | rating、レビュー件数、簡易sentiment集計 |
データ変換の全体像は次の通りです。
Notebookを実行すると、AIDP上に次の流れでデータが作成されます。
Raw files on Managed Volume
-> Bronze managed tables
-> Silver managed tables with data quality checks
-> Gold managed tables for BI/KPI
なぜDatabricksやOCI AIDPのような製品が必要なのか
企業のデータ活用は、以前より複雑になっています。
昔は、業務システムの構造化データをDWHへ集め、BIレポートで見る、という用途が中心でした。現在はそこに加えて、Webログ、外部データ、レビュー、IoT、画像、AI/ML用データなども扱います。
用途が増えると、以下のような問題が出ます。
| 問題 | 何が起きるか |
|---|---|
| データが分断される | BI用、AI用、ログ分析用に別々の基盤ができる |
| コピーが増える | 同じ顧客データや商品データが複数箇所に存在する |
| 品質が揺れる | どれが正しい売上か、どのデータが除外されたか説明しづらい |
| 権限管理が散る | システムごとにアクセス制御が分かれる |
| 再処理しづらい | 集計済みデータしか残っておらず、ロジック変更に弱い |
DatabricksやOCI AIDPのようなモダンデータプラットフォームは、データの保存、加工、Catalog管理、権限管理、分析、AI/MLを一つの流れで扱うためのものです。
重要なのは、単にデータを一か所へ置くことではありません。
Rawデータを残しつつ、信頼できる形に整え、どこから来たデータか追跡でき、SQLやPythonで再利用できる状態にすることが重要です。
Lakehouseとは何か
Lakehouseは、DWHとData Lakeの考え方を組み合わせた設計です。
| 基盤 | 得意なこと | 弱いところ |
|---|---|---|
| DWH | 構造化データの高速集計、BI | ログ、画像、非構造データ、大量Raw保管には窮屈 |
| Data Lake | 多様なファイルを安価に大量保存 | 品質、権限、履歴、SQL利用が曖昧になりやすい |
| Lakehouse | Rawの柔軟性とTable管理を両立 | 設計と運用ルールが必要 |
このデモでは、AIDPのManaged VolumeにRawファイルを置き、Managed TableとしてBronze/Silver/Goldへ整えます。
つまり、ファイルとしての柔軟性と、テーブルとしての扱いやすさを組み合わせています。
Medallion Architectureとは何か
Medallion Architectureは、データの信頼度を段階的に上げる設計パターンです。
このデモでは、以下のように分けています。
| Layer | 役割 | このデモで作るもの |
|---|---|---|
| Raw | 元ファイルを保管する | CSV/JSONL on Managed Volume |
| Bronze | RawをほぼそのままTable化する | demo_bronze_*_raw |
| Silver | 型変換、重複排除、品質チェック、JOINを行う |
demo_silver_*, demo_silver_sales_fact, demo_silver_dq_*
|
| Gold | BI/KPI向けに集計する | demo_gold_* |
RawデータをそのままBIやAIに使うと、型の揺れ、重複、不正値、参照切れ、集計ロジックのばらつきがそのまま結果に出ます。
Medallion Architectureでは、どの層で何を保証しているかを分けることで、データの扱いを説明しやすくします。
AIDPで使う主な部品
今回使うAIDPの部品は次の通りです。
| AIDP component | 役割 |
|---|---|
| Catalog | Schema、Table、Volumeなどのデータ資産を管理する最初の器 |
| Schema | Catalog内の整理単位。このデモでは production
|
| Managed Volume | CSV/JSONLなどのRawファイルや成果物を置く場所 |
| Managed Table | Catalogに登録されるSQL検索可能なテーブル |
| Notebook | Python/PySparkとSQLを実行する作業画面 |
| Spark Compute | Notebookの変換、JOIN、集計を実行する計算エンジン |
作成順としては、基本的に次のようになります。
Catalog
-> Schema
-> Managed Volume
-> Notebook実行でManaged Table作成
このデモでは次の構成を使います。
Catalog: <your_catalog>
└── Schema: production
├── Volume: demo_raw_landing
├── Volume: demo_artifacts
├── Table: demo_bronze_*
├── Table: demo_silver_*
└── Table: demo_gold_*
NotebookとSpark Computeは、Catalog配下のVolumeを読み、同じCatalog配下にTableを書き込みます。
実行前にAIDP UIで作るもの
Notebookの中でCatalogやVolumeを自動作成するのではなく、今回はAIDP UIで先に作成する前提にしています。
理由は、AIDP環境によってはNotebookから CREATE VOLUME を実行できない場合があるためです。
作成するものは以下です。
| 作成順 | Asset | 例 | 役割 |
|---|---|---|---|
| 1 | Workspace folder | /Shared/***/<your_name> |
自分のNotebookを置く場所 |
| 2 | Notebook | aidp_medallion_demo.ipynb |
デモを実行する作業画面 |
| 3 | Spark Compute | 任意 | Notebookの処理を動かす |
| 4 | Catalog | <your_catalog> |
データ資産の器 |
| 5 | Schema | production |
Demo用の整理単位 |
| 6 | Managed Volume | demo_raw_landing |
Rawファイル置き場 |
| 7 | Managed Volume | demo_artifacts |
出力ファイル置き場 |
Notebook内では、Catalog名だけを自分の環境に合わせて変更します。
CATALOG = "<your_catalog>"
SCHEMA = "production"
Raw層: 元データをファイルとして残す
Raw層では、Notebook内で生成した架空データをCSV/JSONLとしてManaged Volumeへ保存します。
保存先の例です。
/Volumes/<your_catalog>/production/demo_raw_landing/raw/customers/
/Volumes/<your_catalog>/production/demo_raw_landing/raw/products/
/Volumes/<your_catalog>/production/demo_raw_landing/raw/orders/
/Volumes/<your_catalog>/production/demo_raw_landing/raw/order_items/
/Volumes/<your_catalog>/production/demo_raw_landing/raw/web_events/
/Volumes/<your_catalog>/production/demo_raw_landing/raw/reviews/
Rawは「加工前の原本」です。
ここで重要なのは、最初から上書き加工しないことです。Rawを残しておけば、後から変換ロジックを変えたくなった場合でも再処理できます。
Bronze層: Rawを追跡可能なTableにする
Bronzeでは、RawファイルをほぼそのままManaged Table化します。
主なテーブルは以下です。
demo_bronze_customers_raw
demo_bronze_products_raw
demo_bronze_orders_raw
demo_bronze_order_items_raw
demo_bronze_web_events_raw
demo_bronze_reviews_raw
demo_bronze_ingestion_audit
Bronzeでは、各行に監査列を付けます。
| 監査列 | 意味 |
|---|---|
_ingest_batch_id |
どの取り込みバッチで入ったか |
_ingested_at |
いつ取り込んだか |
_source_file |
どのRawファイルから来たか |
_source_name |
customers/ordersなどのソース名 |
_raw_line_hash |
Raw行を識別するためのハッシュ |
Bronzeの目的は、きれいにすることではありません。
Rawを壊さずに残し、どのファイルから来たデータか追跡できる状態にすることです。そのため、不正データもBronzeには残します。
Silver層: 分析できる品質へ整える
Silverでは、データを分析に使える品質へ整えます。
このデモで行う主な処理は以下です。
| 処理 | 例 |
|---|---|
| 型変換 | 文字列の日付をtimestamp/dateへ、金額をdecimalへ |
| 重複排除 | 同じ order_id が複数ある場合は最新 updated_at を採用 |
| 参照整合性チェック | 注文の customer_id が顧客マスタに存在するか確認 |
| 不正値検出 | 負の金額、未知のstatus、rating=6などを検出 |
| DQ分離 | 不正データをDQテーブルへ記録 |
| JOIN | 注文、明細、商品、顧客を結合して売上Factを作成 |
作成する主なSilverテーブルです。
demo_silver_customers
demo_silver_products
demo_silver_orders
demo_silver_order_items
demo_silver_sales_fact
demo_silver_web_events
demo_silver_reviews
demo_silver_dq_issues
demo_silver_dq_summary
DQテーブルを作る理由
不正データを黙って捨てると、後で説明できません。
例えば、Rawに存在しない顧客IDが入っていた場合、Goldの売上集計からは除外したいです。しかし、なぜ除外したのかは説明できる必要があります。
そのため、このデモでは以下の2種類のDQテーブルを作ります。
| Table | 内容 |
|---|---|
demo_silver_dq_issues |
DQ問題の明細。どのキーがどのルールに引っかかったか |
demo_silver_dq_summary |
DQ問題の集計。ルール別に何件あったか |
Gold層: BI/KPI向けの完成データを作る
Goldは、業務ユーザーやBIでそのまま使える集計済みデータです。
このデモでは以下のGoldテーブルを作ります。
| Gold table | 内容 |
|---|---|
demo_gold_daily_sales |
日次・チャネル別の注文数、顧客数、数量、売上、粗利、平均注文額 |
demo_gold_product_performance |
商品別の販売数量、売上、粗利、レビュー件数、平均rating |
demo_gold_customer_360 |
顧客別の購入回数、LTV、粗利、初回/最終購入日、好みカテゴリ |
demo_gold_channel_funnel |
device/referrer別のセッション、閲覧、商品閲覧、カート追加、購入ファネル |
demo_gold_review_summary |
商品別レビュー数、平均rating、positive/neutral/negative件数 |
demo_gold_executive_kpis |
経営者向けの1行KPIサマリ |
SilverとGoldの違いは、粒度です。
| 観点 | Silver | Gold |
|---|---|---|
| 粒度 | 注文・明細など細かい粒度 | 日次、商品、顧客、チャネルなど業務粒度 |
| 主な利用者 | データエンジニア、分析者 | BI利用者、業務担当者、管理者 |
| 主な目的 | 正しい分析用データを作る | すぐ見られるKPIを提供する |
PythonとSQLを両方残した理由
AIDP Notebookでは、Python/PySparkとSQLを組み合わせて使えます。
このデモでは、同じGoldテーブルに対して、Python版とSQL版の抽出を両方残しています。
理由は、利用者によって得意なインターフェースが違うためです。
| 方法 | 向いていること |
|---|---|
| Python / PySpark | 複雑な変換、関数化、再利用、条件分岐 |
| SQL | 表示、抽出、集計、BI利用者への説明 |
例えば、日次売上、売上上位商品、DQサマリを、Python版とSQL版の両方で抽出し、最後に結果が一致することを確認しています。
これにより、「PythonでもSQLでも同じGoldデータを参照できる」ことを説明できます。
一時Viewはなぜ使うのか
このNotebookには、一時Viewを作るステップがあります。
結論として、一時ViewはPipeline本体には必須ではありません。
使っている理由は主に2つです。
1. Python結果とSQL結果を比較しやすくするため
Pythonで抽出した結果を demo_cmp_python_daily_sales、SQLで抽出した結果を demo_cmp_sql_daily_sales のような一時Viewにしておくと、後続セルで比較しやすくなります。
Python抽出結果 -> temp view
SQL抽出結果 -> temp view
両者を比較
2. デモ用に分かりやすい名前を付けるため
Goldテーブルから必要な列だけ抜いたものに、demo_vw_dashboard_sales のような名前を付けると説明しやすくなります。
ただし、AIDP Catalogが永続Viewをサポートしない環境があります。そのため、このデモでは CREATE OR REPLACE VIEW ではなく、CREATE OR REPLACE TEMP VIEW を使っています。
一時Viewが見えない、またはセッションをまたいで使えない環境では、Step 15をスキップして問題ありません。Step 16ではGold/DQテーブルを直接参照するSQLを残しているため、デモは続行できます。
代表的な確認SQL
Gold作成後、Notebook内のSQLセルで以下のような確認ができます。
SELECT *
FROM demo_gold_executive_kpis;
SELECT *
FROM demo_gold_daily_sales
ORDER BY order_date, channel;
SELECT *
FROM demo_gold_product_performance
ORDER BY net_sales DESC, product_id
LIMIT 10;
DQサマリは以下で確認できます。
SELECT *
FROM demo_silver_dq_summary
ORDER BY issue_count DESC, source_table, rule_name;
可視化について
AIDP Notebook側にVisualization機能がある場合は、SQL結果や集計表から折れ線グラフ、棒グラフを作成できます。
例です。
| データ | 可視化例 |
|---|---|
demo_gold_daily_sales |
order_date x net_sales の日次売上推移 |
demo_gold_product_performance |
product_name x net_sales の商品別売上 |
demo_silver_dq_summary |
rule_name x issue_count のDQ件数 |
なお、Notebook環境によっては matplotlib が入っていないことがあります。その場合でも、このデモではグラフ化しやすい集計表を表示するようにしています。
実行時の注意点
Volume作成はUIで行う
Notebookから CREATE VOLUME を実行できない環境があるため、VolumeはAIDP UIから作成します。
作成後、Notebook内で次のパスが見えるか確認します。
/Volumes/<your_catalog>/production/demo_raw_landing
/Volumes/<your_catalog>/production/demo_artifacts
Catalog名は各自で変える
Notebook内の設定セルで、Catalog名を自分の環境に合わせます。
CATALOG = "<your_catalog>"
SCHEMA = "production"
SQLセルは、Notebook側で現在のCatalog/Schemaを設定する前提で書いています。上から順番に実行すれば、Catalog名を変えても動く構成です。
料金にも注意する
Notebookを開くだけではなく、Spark Computeを稼働させると計算リソースの利用量に応じて課金対象になります。
デモ後は、不要なComputeを停止し、不要なRaw/Artifact/Tableを削除するか確認します。
まとめ
今回のデモでは、AIDP上で以下を一通り確認できるようにしました。
- Catalog/Schema/Volumeを作る
- Notebookで合成ECデータを生成する
- RawファイルをManaged Volumeへ保存する
- BronzeでRawを追跡可能なTableにする
- Silverで型変換、JOIN、DQ分離を行う
- GoldでBI/KPI向けの集計Tableを作る
- PythonとSQLで同じGold結果を確認する
- 一時Viewや確認SQLでデモを見せやすくする
Medallion Architectureは、単なるテーブル命名規則ではありません。
Rawを残し、Bronzeで取り込みを追跡し、Silverで品質を上げ、Goldで業務が使える形にすることで、データの信頼性と説明可能性を高める設計です。
AIDPは、Notebook、Spark Compute、Catalog、Managed Volumeを同じ作業環境で扱えるため、この流れを学習・デモするには分かりやすい環境だと感じました。