Why now
なぜDatabricksやOCI AIDPのような製品が必要なのか
企業のデータ活用は、BIだけでなくAI/ML、データ共有、ガバナンスまで広がりました。従来のようにDWH、データレイク、ETL、分析環境、機械学習環境が分断されると、同じデータのコピー、品質のばらつき、権限管理の分散が起きやすくなります。
データが増え、用途も増えた
業務データ、ログ、Web行動、レビュー、外部データを、BI、AI、ML、アプリケーションで再利用したい場面が増えています。
正しいデータを説明する必要がある
どのRawから来て、どこで品質チェックされ、どの集計に使われたかを追跡できないと、分析結果を信頼しにくくなります。
Lakehouse basics
レイクハウスが重要になった理由
初学者が最初に押さえるべきポイントは、レイクハウスは「新しい保存先の名前」ではなく、DWHとデータレイクの弱点を埋めるための設計思想だということです。2つの記事でも、なぜそのアーキテクチャが求められるのかという背景理解が重要だと説明されています。
DWHはBIに強い
売上や会計のような表形式データをきれいに集計するには強力です。一方で、ログ、レビュー、画像、音声のようなAI時代のデータを同じ形で扱うには窮屈になりがちです。
データレイクは保存に強い
Rawファイルを安価に大量保存できます。ただし、置くだけでは「正しいデータ」「誰が使ってよいデータ」「どの分析に使われたデータ」までは説明しにくくなります。
レイクハウスは両方をつなぐ
Rawの柔軟性を残しながら、テーブル、品質管理、権限、履歴、SQL/Python処理を組み合わせます。今回のAIDPデモはこの考え方を小さく体験するものです。
Why Lakehouse
初学者が理解すべき6つの価値
レイクハウスを理解すると、なぜSpark、SQL、Catalog、Volume、Medallion、DQ、リネージが同じ話題として出てくるのかがつながります。ここでは、今回のデモで見せる内容に寄せて整理します。
BIとAIのデータを分けすぎない
BI用にDWH、AI用に別ストレージ、ログ分析用に別基盤を作ると、同じ顧客や商品データが複数コピーされます。レイクハウスでは、同じRawから用途別の完成データを作る考え方を取ります。
Rawを残して、後から作り直せる
集計結果だけを保存すると、ロジック変更や障害時に戻れません。RawをVolumeに残し、Bronzeに監査列を付けることで、再処理と説明がしやすくなります。
ファイルをテーブルとして扱う
CSVやJSONLを置くだけでは、型、更新、品質、アクセス制御の管理が難しくなります。Managed Table化することで、SQLで読める、Catalogで探せる、処理順序を設計できる状態にします。
品質問題を隠さない
不正な値を黙って捨てると、あとで数字の説明ができません。SilverでDQテーブルに理由付きで分離し、Goldから除外することで、信頼できるKPIとデータ品質レポートを同時に作れます。
SQL利用者とPython利用者をつなぐ
データエンジニアはPySparkで変換し、アナリストはSQLで確認したいことが多いです。Notebook内にPythonセルとSQLセルを並べると、同じテーブルを異なるスキルの人が理解できます。
ガバナンスを後付けにしない
データが増えるほど、権限、所在、来歴、影響範囲の管理が重要になります。Catalog、監査列、DQサマリ、Goldテーブル名の統一は、小さなデモでもガバナンスの入口になります。
Glossary bridge
参考記事に出てくる用語を、このデモで読み替える
初めて読むと、Spark、Lakehouse、Medallion、Catalog、Lineageなどの用語が一気に出てきます。ここでは参考記事のキーワードを、今回のAIDPデモで実際に触る部品へ対応づけます。
Databricksが広めた概念を知る
OSSへの貢献、Spark、Delta Lake、MLflow、Unity Catalog、Medallion、Lakehouse、リネージといった言葉がなぜ広まったのかを押さえます。
Whyから学ぶ
「なぜ今このアーキテクチャが必要か」を理解してから、Notebook、Compute、SQL、Python、品質管理、ガバナンスへ進む流れを重視します。
このページで伝えたいメッセージ
レイクハウスの価値は、データを一か所に置くことだけではありません。Rawを残し、品質を上げ、Catalogで見つけられるようにし、SQLとPythonで再利用できる状態にすることです。AIDPのMedallionデモでは、その流れをECデータで目に見える形にしています。
Platform principles
モダンデータプラットフォームに共通する観点
Databricksで広がったLakehouseやMedallion Architectureの考え方は、AIDPのような環境でデータ活用を説明するときにも役立ちます。このデモでは、製品比較ではなく、現場で重要になる共通パターンを体験します。
Open data processing
PySparkとSQLの両方で抽出・集計を行い、エンジニアにもSQL利用者にも説明しやすい形にします。
Lakehouse-style design
RawファイルとManaged Tableを組み合わせ、ファイルベースの柔軟性とテーブル管理の扱いやすさを両立します。
Governance and lineage
Catalog、監査列、DQテーブル、ソースファイル情報を使い、どこから来たデータかを追えるようにします。
Medallion Architecture
Rawをいきなり使わず、段階的に信頼度を上げる
RawデータをそのままBIやAIに使うと、型の揺れ、重複、不正値、参照切れ、集計ロジックのばらつきが結果に影響します。Medallion Architectureでは、Raw/Bronze/Silver/Goldに分け、どの時点で何を保証しているかを明確にします。
Raw
元ファイルを保管します。再処理できる原本として、CSV/JSONLをManaged Volumeに残します。
Bronze
Rawをほぼそのままテーブル化します。取り込み日時、ソースファイル、ハッシュなどの監査列を付与します。
Silver
型変換、重複排除、参照整合性チェック、不正データ分離を行い、分析に使える品質に整えます。
Gold
日次売上、商品実績、顧客360、ファネル、経営KPIなど、業務ユーザーがすぐ使える形に集計します。
Transformation detail
このデモでデータがどう変わるか
難しいポイントは、単にテーブル名が変わることではなく、各層でデータの意味と品質が変わることです。次の図では、RawのECデータがBronze、Silver、Goldへ進むにつれて、どのような加工を受けるかを示しています。
1Raw -> Bronze: 原本を壊さず、証跡を足す
Notebookで生成したCSV/JSONLをManaged Volumeに置き、Bronzeでは値をなるべくそのままテーブル化します。ここでは「正しいか」よりも「いつ、どのファイルから、どの行を取り込んだか」を追えることが重要です。
| Bronze列 | 例 | 意味 |
|---|---|---|
| order_id | O10002 | Rawの注文ID |
| _source_file | /Volumes/.../raw/orders/orders_2026-05-21.csv | どのファイルから来たか |
| _raw_line_hash | a9f3c1... | Raw行を追跡する指紋 |
| customer_id | C99999 | 例外: 存在しない顧客ID |
| order_ts | not_a_timestamp | 例外: 日時に変換できない |
2Bronze -> Silver: 型と意味を揃え、DQで分岐
Silverでは、文字列だった日時・金額・数量を分析可能な型へ変換し、重複や参照切れを検出します。正常データはSales Factへ進み、不正データはDQテーブルに理由付きで残します。
| 処理 | Bronzeでの状態 | Silverでの結果 |
|---|---|---|
| timestamp変換 | order_ts = "2026-05-21 10:15:00" | order_ts_ts / order_date を作成 |
| numeric変換 | order_total = "12800.50" | decimal型の売上金額に変換 |
| 重複排除 | 同じ order_id が複数行 | 最新 updated_at の1行を採用 |
| 参照整合性 | customer_id = C99999 | invalid_customer_id としてDQへ |
| JOIN | 注文・明細・商品・顧客が別々 | demo_silver_sales_fact を作成 |
3Silver -> Gold: 業務が読むKPI粒度へ集計
Silverは明細粒度のきれいなFact、Goldは業務がそのまま読む集計済みKPIです。たとえば日次売上では、複数の注文明細を日付・チャネル単位にまとめます。
| Silver: demo_silver_sales_fact（明細粒度） | |||
|---|---|---|---|
| order_id | order_date | channel | net_sales |
| O10001 | 2026-05-21 | web | 12,000 |
| O10001 | 2026-05-21 | web | 3,400 |
| Gold: demo_gold_daily_sales（日次・チャネル粒度） | ||||
|---|---|---|---|---|
| order_date | channel | order_count | net_sales | gross_margin_rate |
| 2026-05-21 | web | 132 | 1,245,800 | 32.0% |
4同じ1件のデータがどう扱われるか
たとえば不正な注文 O10002 は、Raw/Bronzeでは消さずに保持します。Silverで理由を付けてDQテーブルへ分離し、Goldの売上KPIからは除外します。これにより「捨てた」のではなく「説明できる形で除外した」と示せます。
| 層 | 扱い | デモで見るもの |
|---|---|---|
| Bronze | 監査列付きで保存 | _source_file / _raw_line_hash |
| Silver | DQ issueとして記録 | rule_name / severity |
| Gold | KPI集計から除外 | 信頼できる売上・粗利 |
AIDP components
このデモで使うAIDPの部品
AIDPでは、Notebook、Spark Compute、Catalog、Managed Volumeを同じ作業環境で扱えます。これにより、データ生成、加工、確認、資産管理を一連のデモとして見せやすくなります。
Notebook
Python/PySparkとSQLを実行し、データ生成、加工、確認を順番に進める作業画面です。
Spark Compute
Notebookの処理を実行する計算エンジンです。JOINや集計を分散処理します。
Catalog
Schema、Table、Volumeなどのデータ資産を管理します。作成した各層のテーブルを確認できます。
Managed Volume
CSV/JSONLなどのファイル置き場です。RawファイルとArtifact出力に使います。
Cost awareness
AIDPデモで課金が発生しやすい場所
AIDPは便利ですが、Notebookを開くだけでなくSpark Computeを稼働させると、計算リソースの利用量に応じて課金対象になります。Oracle公式ドキュメントでは、AIDP UnitはOCPU、メモリ、GPUなどの使用量から計算される課金単位として説明されています。
AIDP Unitは、AMD/ARM/Intel OCPU、メモリ、GPUなどの使用量に応じて積み上がります。ドキュメント例では、AMD 2 OCPU + 32GB memory のデフォルトMaster Catalog Computeが 230 AIDP Units/hour、$0.230/hour として示されています。
主な換算例: AMD OCPU/hour = 67 AIDP Units、ARM OCPU/hour = 27、Intel OCPU/hour = 87、NVIDIA GPU/hour = 4110、Memory GB/hour = 3。Object Storage、Logging、Metrics、DatabaseはOCI側で別途課金対象です。
| 見るポイント | 課金の考え方 |
|---|---|
| Spark Compute | NotebookやWorkflowで稼働させると、AIDP Unitとして消費 |
| Managed Volume / Table | Rawファイル、Artifact、Managed Tableを残すとストレージ費用に注意 |
| ADW / ADB連携 | 参照・出力先として追加した場合、DB側のCompute/Storageも別管理 |
| 価格表 | Oracle Cloud Price ListのData Lake / AI Data Platform欄を確認 |
価格はリージョン、契約、通貨、将来の価格改定で変わるため、デモ実施前に公式価格表とCost Estimatorで確認してください。Oracle Cloud Price List
Demo assets
何を作り、何を確認するか
| Layer | 作成するもの | 確認するポイント |
|---|---|---|
| Raw | customers, products, orders, order_items, web_events, reviews |
Volume上にCSV/JSONLとして置かれた原本ファイルを確認します。 |
| Bronze | demo_bronze_*_raw, demo_bronze_ingestion_audit |
Raw取り込み件数、監査列、ソースファイル、取込バッチを確認します。 |
| Silver | demo_silver_*, demo_silver_dq_issues, demo_silver_dq_summary |
型変換、重複排除、不正データ分離、売上ファクトを確認します。 |
| Gold | demo_gold_daily_sales, demo_gold_product_performance, demo_gold_customer_360, demo_gold_executive_kpis |
BI/KPI向けに集計済みのテーブルをSQLとPythonの両方で確認します。 |
Run it
AIDPで実行する流れ
実行前チェック
NotebookにSpark Computeがアタッチされていること、Catalog名を自分の環境に合わせて変更していること、Schema production とManaged Volume demo_raw_landing / demo_artifacts が作成済みであることを確認します。
Notebook内の設定例
CATALOG = "<your_catalog>"
SCHEMA = "production"
RAW_VOLUME = "demo_raw_landing"
ARTIFACT_VOLUME = "demo_artifacts"