Associate 学習教材 ① プラットフォーム基礎

Databricks 公式ドキュメント（日本語版）の内容を、重要用語・概念を漏らさずまとめた自習用教材です。参照した公式ページ:
Azure Databricks とは（Introduction）: https://learn.microsoft.com/ja-jp/azure/databricks/introduction/
Azure Databricks コンポーネント（Concepts）: https://learn.microsoft.com/ja-jp/azure/databricks/getting-started/concepts
Data Lakehouse とは: https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse/
Azure Databricks の Delta Lake とは: https://learn.microsoft.com/ja-jp/azure/databricks/delta/
開発言語の選択（Languages Overview）: https://learn.microsoft.com/ja-jp/azure/databricks/languages/overview
（補足）ACID 保証とは: https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse/acid
※ 上記はいずれも WebFetch により本文を実際に読み込んでまとめています。

1. このセクションの概要

このセクションでは、Databricks 認定データエンジニア Associate 試験の土台となる「プラットフォーム基礎」を扱います。Databricks データインテリジェンスプラットフォーム（Databricks Data Intelligence Platform）が何であるか、その中心概念である**データレイクハウス（Data Lakehouse）**とは何か、レイクハウスを支える 2 大テクノロジ（Delta Lake と Unity Catalog）の役割を学びます。あわせて、アカウント／ワークスペース、クラスター・SQL ウェアハウスなどのコンピュート、ノートブック・ジョブ・パイプラインといった開発コンポーネント、そして開発に使える言語（Python / SQL / Scala / R）の位置づけを整理します。Delta Lake については、ACID トランザクション・トランザクションログ・タイムトラベル・スキーマ適用など、試験頻出の仕組みを重点的に解説します。

2. 重要用語集

用語（日本語）	English	説明
データインテリジェンスプラットフォーム	Databricks Data Intelligence Platform	エンタープライズグレードのデータソリューションを大規模に構築・デプロイ・共有・保守するための統合ツール群。クラウドのストレージ・セキュリティと統合され、生成 AI でデータの意味（セマンティクス）を理解する。
データレイクハウス	Data Lakehouse	データレイクとデータウェアハウスの利点を組み合わせたデータ管理システム。単一の信頼できる情報源（single source of truth）を提供する。
データウェアハウス	Data Warehouse	BI 分析用にクリーンで構造化されたデータを提供するシステム。約 30 年 BI を支えてきたが、独自形式が多く ML サポートが限定的。
データレイク	Data Lake	あらゆる種類・形式のデータを安価かつ効率的に永続保存する仕組み。データサイエンス／ML に使われるが、未検証ゆえ BI には不向きとされてきた。
メダリオンアーキテクチャ	Medallion Architecture	データを段階的（ステージング→変換）に改善・強化していく設計パターン。ブロンズ／シルバー／ゴールドの複数レイヤーで構成される。
Delta Lake	Delta Lake	Parquet をトランザクションログで拡張した、最適化されたオープンソースのストレージレイヤー。Azure Databricks の既定のテーブル形式。ACID を提供。
ACID トランザクション	ACID Transactions	Atomicity（原子性）・Consistency（一貫性）・Isolation（分離性）・Durability（永続性）を保証するトランザクション特性。
トランザクションログ	Transaction Log（Delta Log / `_delta_log`）	Delta テーブルへの全変更を記録するファイルベースのログ。コミットの原子性・タイムトラベル・並行制御の基盤。
タイムトラベル	Time Travel	書き込みごとに作られるテーブルバージョンを使い、過去バージョンのテーブルへクエリできる機能。
スキーマ適用	Schema Enforcement	書き込み時にスキーマを検証し、要件に合わないデータを弾く仕組み。
スキーマ進化	Schema Evolution	データを書き換えずにテーブルスキーマを変更（列追加など）できる機能。
アップサート／マージ	Upsert / MERGE	既存行の更新と新規行の挿入を 1 操作で行う DML。`MERGE` を使う。
Parquet	Parquet	Delta Lake が基盤とする列指向データファイル形式。
Apache Spark	Apache Spark	ストレージと分離された、非常にスケーラブルな分散処理エンジン。Databricks の基盤。
構造化ストリーミング	Structured Streaming	Spark のストリーミング／増分処理フレームワーク。Delta Lake と緊密に統合。
Unity Catalog	Unity Catalog	データと AI 資産の統合ガバナンスソリューション。一元的なアクセス制御・監査・リネージ（系列）・検出を提供。
アカウント	Account	複数ワークスペースを含められる 1 つのエンティティ。
ワークスペース	Workspace	チームが Databricks 資産にアクセスする環境（クラウド上のデプロイ）。
DBU	Databricks Unit	VM インスタンス種別に基づく処理能力の課金単位。
クラスター	Cluster	ノートブックやジョブを実行するコンピュートリソースと構成のセット。汎用とジョブの 2 種。
プール	Pool	すぐ使えるアイドルインスタンスの集合。クラスターの起動・自動スケールを高速化。
Databricks Runtime	Databricks Runtime	クラスター上で動作するコアコンポーネント群。Apache Spark を含む。
SQL ウェアハウス	SQL Warehouse	SQL クエリを実行するコンピュート。クラシック／プロ／サーバーレスの 3 種。
ノートブック	Notebook	実行可能コード・可視化・説明テキストを含む Web ベースのインターフェイス。複数言語対応。
ジョブ	Job（Lakeflow Jobs）	ノートブック・SQL・その他コードを調整・スケジュールする非対話型メカニズム。
Lakeflow パイプライン	Lakeflow Pipelines	宣言的に ETL を構築するフレームワーク（Spark 宣言型パイプライン SDP 上に構築）。
DBFS	Databricks File System	既定で全ユーザーが使える保存領域。DBFS ルート／マウント経由の利用は非推奨。
カタログ / スキーマ / テーブル	Catalog / Schema / Table	Unity Catalog の 3 階層データ構造（catalog.schema.table）。
ボリューム	Volume	クラウドオブジェクトストレージ上の非表形式データを管理する論理ストレージ。
メタストア	Metastore	データ・AI・アクセス許可のメタデータを登録するアカウントレベルの領域。
自動ローダー	Auto Loader	クラウドストレージから増分的・べき等的にファイルを取り込むツール。
PySpark	PySpark	Spark の Python API。DataFrame を用いた変換記述に使う。
DataFrame	DataFrame	Spark の表形式データ抽象。Delta Lake の読み書きに使える。
UDF	User-Defined Function	ユーザー定義関数。Unity Catalog の関数としても実行可能。

3. 詳細解説

3-1. Databricks とは / レイクハウスとは

Azure Databricks とは（Introduction ページより）

Azure Databricks は、エンタープライズグレードのデータソリューションを大規模に構築・デプロイ・共有・保守するための統合ツールセット。その中核が Databricks データインテリジェンスプラットフォーム（Databricks Data Intelligence Platform）。
クラウドアカウントのストレージ・セキュリティと統合され、クラウドインフラを自動的に管理・デプロイする。
データレイクハウス上で生成 AI（generative AI）を使い、データ固有のセマンティクス（意味）を理解し、ビジネスニーズに合わせてパフォーマンスを自動最適化・インフラ管理する点が「データインテリジェンス」の要。
**自然言語処理（NLP）**がビジネスの言葉を学習するため、自分の言葉でデータを検索・発見でき、コード記述・エラーのトラブルシュート・ドキュメント検索も自然言語で支援される。

マネージドオープンソース統合（Databricks 発祥の OSS）

Databricks はオープンソースコミュニティにコミットし、Databricks Runtime リリースで OSS 統合を管理する。以下は元々 Databricks 従業員が作った OSS プロジェクト:

Delta Lake と Delta Sharing / OpenSharing
MLflow（ML ライフサイクル管理）
Apache Spark と 構造化ストリーミング（Structured Streaming）
Redash（可視化）
Unity Catalog

一般的なユースケース（Databricks が担う主なワークロード）

エンタープライズデータレイクハウスの構築: データウェアハウスとデータレイクを組み合わせ、データエンジニア・サイエンティスト・アナリスト・運用システムが単一の信頼できる情報源を共有。分散データシステムの構築・保守・同期の複雑さを軽減。
ETL とデータエンジニアリング: Apache Spark + Delta Lake + カスタムツールで ETL を実現。SQL / Python / Scala で ETL ロジックを書き、スケジュールジョブとしてデプロイ。Lakeflow パイプラインが依存関係を管理し、インフラを自動デプロイ・スケール。**自動ローダー（Auto Loader）**でクラウドストレージから増分・べき等にデータをロード。
機械学習・AI・データサイエンス: MLflow、Databricks Runtime for Machine Learning でコア機能を拡張。
大規模言語モデル（LLM）と生成 AI: Hugging Face Transformers などを統合。基礎 LLM（foundation LLM）を独自データでトレーニング／ファインチューニング可能。SQL アナリスト向けに AI 関数（AI Functions） を用意し、パイプライン内から LLM にアクセスできる。
データウェアハウス・分析・BI: 使いやすい UI + コスト効率の高いコンピュート + 低価格で拡張可能なストレージ。管理者がスケーラブルなクラスターを SQL ウェアハウス として構成し、エンドユーザーは複雑さを意識せずクエリ実行。SQL エディターやノートブックでレイクハウスのデータをクエリ。Unity Catalog のセマンティックレイヤーで共有 KPI（メトリックビュー）を一度定義し、AI/BI ダッシュボードや自然言語で探索する Genie Agents を構築できる。
データガバナンスとセキュアなデータ共有: Unity Catalog が統合ガバナンスモデルを提供。権限は UI または SQL の ACL で管理。Delta Sharing / OpenSharing で環境外への安全な共有が可能。
DevOps・CI/CD・タスクオーケストレーション: ジョブ（Jobs） で任意コードをスケジュール。宣言型オートメーションバンドル（Databricks Asset Bundles） でリソースをプログラム的に定義・デプロイ。Git フォルダー（旧 Repos） で Git プロバイダーと同期。
リアルタイムストリーミング分析: Apache Spark Structured Streaming でストリーミング・増分変更を処理。Delta Lake と緊密統合され、Lakeflow パイプラインと自動ローダーの基盤。
オンライントランザクション処理（OLTP）: Lakebase（フルマネージド Postgres）でプラットフォームに統合された OLTP データベースを提供。

データレイクハウスとは（Lakehouse ページより）

データレイクハウスは、データレイクとデータウェアハウスの利点を組み合わせたデータ管理システム。
目的: ML と BI などのワークロードがバラバラのシステムで処理されるのを避け、単一の信頼できる情報源（single source of truth） を確立し、冗長コストをなくし、データの鮮度を保証する。
しばしば メダリオンアーキテクチャ（Medallion Architecture） を採用し、ステージング→変換のレイヤーを移動しながらデータを増分的に改善・強化・調整する。

なぜレイクハウスなのか — 3 者の比較（重要）

観点	データウェアハウス（DWH）	データレイク	データレイクハウス
主用途	BI / レポート	データサイエンス / ML	BI・ML の両方を単一基盤で
データ	クリーンで構造化	あらゆる形式・生データ	検証済みデータを標準形式で
形式	独自形式が多い	オープン（安価に保存）	オープン標準形式に直接アクセス
ML サポート	限定的	得意	ML/データサイエンス向け最適化インデックス
弱点	結果生成に数分〜数時間、変更が苦手、ML 弱い	未検証で BI に不向き	（両者の弱点を克服）

データウェアハウスは頻繁に変わらないデータ向けに設計され、同時実行クエリ間の競合を防ぐが、独自形式依存・ML サポート限定という弱点がある。
データレイクは安価に大量データを保存できるが、未検証な性質から BI レポートには使われにくい。
レイクハウスが提供する 3 つの価値: (1) 標準データ形式に直接アクセスできるオープン性、(2) ML・データサイエンス向けに最適化されたインデックス作成プロトコル、(3) BI・高度分析向けの低レイテンシで信頼性の高いクエリ。
仕組みの本質: 最適化されたメタデータレイヤー ＋ クラウドオブジェクトストレージ上の標準形式で保存された検証済みデータ を組み合わせることで、異なるユースケースが同じデータ・同じプラットフォームで作業できる。

3-2. アーキテクチャと主要コンポーネント

Databricks Lakehouse のしくみ（2 大テクノロジ）

Databricks は Apache Spark 上に構築されている。Spark により、ストレージと分離（decouple）されたコンピュートリソースで動く高スケーラブルなエンジンを実現する。レイクハウスは次の 2 つの重要テクノロジを使う:

Delta Lake: ACID トランザクションとスキーマ適用をサポートする最適化ストレージレイヤー。
Unity Catalog: データと AI 用の統一されたきめ細かい（fine-grained）ガバナンスソリューション。

レイクハウスのデータフロー（3 レイヤー＝メダリオンの考え方）

データインジェスト（ingestion）: バッチ／ストリーミングのデータが多様なソース・形式で生（raw）のまま到着する層。Delta テーブルへ変換する際にスキーマ適用で欠損・想定外データをチェック。Unity Catalog にテーブルを登録し、系列（lineage）を追跡。
データ処理・キュレーション・統合: 検証後にデータをクレンジング・調整。サイエンティストや ML 実践者が特徴量を作成。書き込み時スキーマ（schema-on-write） ＋ Delta のスキーマ進化 により、ダウンストリームのロジックを書き換えずに変更を加えられる。
データ提供（serving）: クリーンでエンリッチされたデータをエンドユーザーへ。統合ガバナンスモデルで系列を単一ソースまで追跡でき、ML・データエンジニアリング・BI/レポートに最適化されたレイアウトでアクセス。

アカウントとワークスペース（Concepts ページより）

ワークスペース（workspace）: チームが Databricks 資産にアクセスするクラウド上のデプロイ環境。組織は複数持つことも 1 つだけにすることもできる。オブジェクト（ノートブック・ライブラリ・ダッシュボード・実験）はフォルダーに整理され、データオブジェクトとコンピュートへのアクセスを提供する。
アカウント（account）: 複数ワークスペースを含められる 1 つのエンティティ。Unity Catalog を有効化したアカウントでは、全ワークスペースのユーザーとデータアクセスを一元管理できる。

課金: DBU（Databricks Unit）

Azure Databricks は DBU（VM インスタンス種別に基づく処理能力の単位） で課金される。

認証と認可（identity と権限）

ユーザー（User）: システムにアクセスできる一意の個人。ID は電子メールアドレスで表される。
サービスプリンシパル（Service Principal）: ジョブ・自動化ツール・CI/CD などの用途に作るサービス ID。アプリケーション ID で表される。
グループ（Group）: ID のコレクション。権限割り当てを簡素化。全 Databricks ID をメンバーにできる。
アクセス制御リスト（ACL, Access Control List）: ワークスペース・クラスター・ジョブ・テーブル・実験などに紐づく権限一覧。「サブジェクト（誰）」と「操作（何ができるか）」を指定。
個人用アクセストークン（PAT, Personal Access Token）: REST API 呼び出しやツール認証に使う文字列。Microsoft Entra ID トークンも REST API 認証に利用可能。

インターフェイス

UI: ワークスペース・データ・コンピュートを操作するグラフィカルインターフェイス。
Genie One: ビジネスユーザー向けの簡略化インターフェイス（AI/BI ダッシュボード閲覧・質問・Apps を 1 エントリで）。
REST API / SQL REST API: アカウント・ワークスペースオブジェクトを操作するエンドポイント。SQL タスクの自動化も可能。
CLI: Databricks REST API 上に構築されたコマンドラインツール（GitHub でホスト）。

データ管理オブジェクト（Unity Catalog の階層）

Unity Catalog: ワークスペース横断で一元的なアクセス制御・監査・系列・データ検出を提供する統合ガバナンス。
カタログ（Catalog）: データを整理・分離する最上位レベルのコンテナー。同一リージョン・アカウント内のワークスペース間で共有可能。
スキーマ（Schema／データベース）: カタログ内に含まれる第 2 階層。テーブル・ボリューム・関数・モデルなどを含む。
テーブル（Table）: 構造化データを整理・管理。Spark SQL / Spark API でクエリ。
ビュー（View）: 1 つ以上のテーブル・ビューから派生する読み取り専用オブジェクト（保存されたクエリ）。
ボリューム（Volume）: クラウドオブジェクトストレージ上の非表形式（non-tabular）データを管理する論理ストレージ。非表形式データのアクセスはボリューム管理が推奨。
Delta テーブル（Delta Table）: 既定で作成される全テーブルは Delta テーブル。Delta Lake OSS プロジェクトに基づく高性能 ACID テーブルストレージ。データはクラウドオブジェクトストア上のファイルのディレクトリとして保存し、メタデータをメタストアに登録。
メタストア（Metastore）: データ・AI・アクセス許可のメタデータを登録するアカウントレベルの領域。Unity Catalog 未採用者向けにレガシ Hive メタストア も提供。
カタログエクスプローラー（Catalog Explorer）: スキーマ・テーブル・モデル・ボリューム・関数などを探索・管理する UI。
DBFS ルート（DBFS Root）: 既定で全ユーザーが使える保存場所。重要: DBFS ルート／マウント経由の保存・アクセスは非推奨（deprecated）。Unity Catalog でのアクセス管理が推奨。

（3 階層の完全修飾名は catalog.schema.table の形になる点を押さえる。）

コンピュート管理

クラスター（Cluster）: ノートブック・ジョブを実行するコンピュートリソースと構成のセット。2 種類:
- 汎用クラスター（all-purpose / general）: UI・CLI・REST API で作成。手動で終了・再起動でき、複数ユーザーで共有して対話的な共同分析ができる。
- ジョブクラスター（job cluster）: ジョブスケジューラが「新しいジョブクラスター」で実行を開始し、ジョブ完了時に自動終了する。再起動はできない。
プール（Pool）: すぐ使えるアイドルインスタンスの集合。接続クラスターはドライバー／ワーカーをプールから割り当てるため、起動・自動スケールが高速。アイドルが足りなければプロバイダーから新規割り当てで拡張、クラスター終了時にインスタンスはプールへ返却され再利用される。
Databricks Runtime: クラスター上で動くコアコンポーネント群。
- Databricks Runtime: Apache Spark を含み、使いやすさ・パフォーマンス・セキュリティを向上させる多数のコンポーネントを追加。
- Databricks Runtime for Machine Learning: Databricks Runtime 上に構築。TensorFlow・Keras・PyTorch・XGBoost など ML/DL ライブラリを事前構成。GPU サポートも組み込み。
ワークロード（Workload）の 2 種類:
- データエンジニアリング（自動化）ワークロード: ジョブスケジューラがワークロードごとに作るジョブクラスターで実行。
- データ分析（対話型）ワークロード: 汎用クラスターで実行。通常はノートブック内でコマンド実行。既存の汎用クラスターでジョブを実行する場合も対話型扱い。
実行コンテキスト（Execution Context）: 各言語（Python・R・Scala・SQL）の REPL（read–eval–print loop）環境の状態。

開発コンポーネント

ジョブ（Job / Lakeflow Jobs）: ノートブック・ライブラリ・タスクを調整・スケジュールする非対話型メカニズム。
パイプライン（Pipelines）: Lakeflow パイプラインは Apache Spark 宣言型パイプライン（SDP, Spark Declarative Pipelines） 上に構築された、信頼性・保守性・テスト性の高い宣言型 ETL フレームワーク。
ノートブック（Notebook）: 実行可能コマンド・可視化・説明テキストを含む Web ベースインターフェイス。
ライブラリ（Library）: クラスターで実行するノートブック／ジョブが使えるコードパッケージ。Runtime に多数同梱、独自アップロードも可。
Git フォルダー（Git Folders、旧 Repos）: リモート Git リポジトリと同期し、共同でバージョン管理するフォルダー。

データウェアハウジング（Databricks SQL 関連）

クエリ（Query）: データを操作する有効な SQL ステートメント。SQL エディターや SQL コネクタ／ドライバー／API で作成。
SQL ウェアハウス（SQL Warehouse）: SQL クエリを実行するコンピュート。クラシック / プロ / サーバーレスの 3 種。可能ならサーバーレスが推奨。
クエリ履歴（Query History）: 実行済みクエリとパフォーマンス特性の一覧。ボトルネック特定に使う。
可視化（Visualization） / ダッシュボード（Dashboard）: クエリ結果のグラフィカル表現、およびその提示。Genie で自然言語から可視化を作成できる。

AI と機械学習コンポーネント（参考）: 機械学習ランタイム、MLflow 実験（Experiment）、特徴量ストア（Feature Store）、生成 AI モデル（AI Playground、基盤モデル API、外部モデル、ファインチューニング）、モデルレジストリ（Unity Catalog 上の MLflow モデルレジストリ）、Model Serving（モデルを REST API として提供）。

3-3. Delta Lake の基礎（ACID・タイムトラベル・スキーマ・トランザクションログ）

Delta Lake とは

Delta Lake は、Databricks 上のレイクハウスにテーブルの基盤を提供する最適化されたストレージレイヤー。
Parquet データファイルを、ファイルベースのトランザクションログで拡張したオープンソースソフトウェア（OSS）。これにより ACID トランザクションとスケーラブルなメタデータ処理を実現する。
Apache Spark API と完全互換で、構造化ストリーミングと緊密に統合。データの 1 コピーをバッチとストリーミングの両方に使え、大規模な増分処理を提供する。
Azure Databricks の既定（default）のストレージ形式。特に指定しない限り、すべてのテーブルは Delta Lake テーブル。Spark DataFrames でも SQL でも、既定設定でレイクハウスに保存するだけで Delta の利点を得られる。
Databricks が Delta Lake プロトコルを開発し、OSS に貢献し続けている。プラットフォームの最適化の多くが Spark と Delta の保証に基づく。
トランザクションログにはオープンプロトコルがあり、任意のシステムでログを読める（Delta Transaction Log Protocol）。

ACID トランザクションとは（補足 ACID ページより）

Azure Databricks は全読み書きに既定で Delta Lake を使い、OSS Delta Lake プロトコルの ACID 保証に基づく。ACID の各要素:

原子性（Atomicity）: すべてのトランザクションが完全に成功するか、完全に失敗するかのどちらか。
一貫性（Consistency）: 同時操作がデータの状態をどう観察するかに関する保証。
分離性（Isolation）: 同時操作が互いにどう競合し得るかを規定。
永続性（Durability）: コミットされた変更は永続的であること。

補足: ACID は多くの技術で語られるが、具体的な保証はシステムごとに異なる。ここでの保証は Delta Lake がサポートするテーブルに関するもので、他形式や外部システムでは読み書きのトランザクション保証が得られない場合がある。

トランザクションログと原子性の実装

トランザクションログがコミットの原子性を制御する。
トランザクション中、データファイルはテーブルを裏付けるディレクトリに書き込まれる。完了時に、書き込まれた全ファイルのパスを含む新しいエントリがトランザクションログにコミットされる。
コミットごとにテーブルバージョンがインクリメントされ、新しいデータファイルが読み取りに公開される。テーブルの現在状態は「ログで有効とマークされた全データファイル」で構成される。
ログに新バージョンが記録されない限り、データファイルは追跡されない。トランザクションが失敗しても、書き込み済みファイルはテーブルの一部にならず、状態を損なわない。 VACUUM が追跡されていない残存ファイル（失敗トランザクションの未コミットファイル含む）を削除する。
クラウドオブジェクトストレージへの書き込みはトランザクションコミットを使い、データファイルと共に _started_<id> / _committed_<id> で始まるメタデータファイルが作られる（古いものは定期的に自動クリーンアップ）。

永続性・一貫性・分離性の実装

永続性: 全データファイルとトランザクションログをクラウドオブジェクトストレージに保存。高可用・高耐久なストレージの保証を継承。
一貫性＝楽観的並行性制御（Optimistic Concurrency Control）: 書き込みは 3 段階で動作する:
1. 読み取り（Read）: 変更対象ファイルを特定するため、最新バージョンのテーブルを読む（必要な場合）。追加のみ（append-only）の書き込みは事前読み取り不要でメタデータのみ検証。
2. 書き込み（Write）: テーブル定義に使うディレクトリにデータファイルを書き込む。
3. 検証とコミット（Validate & Commit）: 読み取ったスナップショット以降に他の書き込みと競合していないか確認。競合なしなら新バージョンとしてコミットして成功。競合ありなら同時変更例外（concurrent modification exception）で失敗し、データ破損を防ぐ。
- 楽観的並行性は「ほとんどの同時トランザクションは競合しないが、競合し得る」ことを前提とする。
分離性: 既定で書き込みは書き込みシリアライザブル分離（write serializable isolation）、読み取りはスナップショット分離（snapshot isolation）。書き込みシリアライザブルはスナップショットより強い保証だが、書き込み操作にのみ適用される。書き込みシリアライザブル＋楽観的並行制御の連動で高い書き込みスループットを実現。

トランザクションのスコープ

既定では、各 SQL ステートメントが 1 テーブルに対する独立したアトミックトランザクションとして実行される。
BEGIN ATOMIC ... END; 構文で、複数テーブルにまたがる複数ステートメントを 1 つのアトミックトランザクションにまとめられる（参加テーブルでカタログコミットの有効化が必要）。
楽観的並行制御を使うため、ロックがなくデッドロックが起きない。
マルチクラスター書き込み: 複数クラスターから同一テーブルへ同時書き込みしてもテーブルは破損しない（一部書き込みは競合し得る）。
異なるワークスペースからの変更: 同じ Delta テーブルを別ワークスペースから同時変更でき、書き込み中でも他ワークスペースのリーダーには一貫したビューが見える。
主キー・外部キー関係は情報（informational）であり強制（enforce）されない。

タイムトラベル（Time Travel）とバージョニング

Delta テーブルへの書き込みごとに新しいテーブルバージョンが作成される。
トランザクションログを使えば、テーブルの変更履歴を確認し、以前のバージョンに対してクエリできる（タイムトラベル）。

スキーマの機能強化

スキーマ適用（Schema Enforcement）: 書き込み時にスキーマを検証し、書き込まれる全データが設定要件と一致することを確認（データ品質検証）。
制約（Constraints）: 強制される整合性制約と、情報的な主キー・外部キー・一意制約。
生成列（Generated Columns）: ユーザー指定関数で列値を自動生成。
スキーマ進化（Schema Evolution）: データを書き換えずに手動／自動でスキーマを更新。
列マッピング（Column Mapping）: データを書き換えずに列の名前変更・削除。
カスタムメタデータ: テーブル・列にコメントやカスタムメタデータを付与しデータ検出を強化。

データの取り込み・更新・管理機能

取り込み（ingest）: Lakeflow パイプライン、自動ローダー（Auto Loader）、COPY INTO（SQL で増分・べき等ロード）、ストリーミングテーブル、ファイルアップロード、Parquet/Iceberg からの CLONE / CONVERT TO DELTA など。
更新・変更: MERGE によるアップサート、選択的上書き（selective overwrite）、スキーマ進化、列マッピング。
- 重要: テーブル破損を避けるため、Delta ファイルディレクトリ内のデータ／トランザクションログファイルを直接操作しないこと。
増分・ストリーミング: readStream / writeStream で Delta テーブルをソース／シンクに使用。変更データフィード（Change Data Feed, CDF） でバージョン間の行レベル変更を追跡。
ファイル管理・インデックス（メタデータ解析＋物理レイアウトでスキャンファイルを削減）:
- 液体クラスタリング（Liquid Clustering）: パーティション分割なしにデータレイアウトを簡素化・最適化。
- データスキッピング（Data Skipping）: 列統計・Z オーダー（Z-Order）・最適化レイアウトで、クエリ時に無関係なファイルをスキップ。
- OPTIMIZE（ファイルレイアウト最適化）: 小さなファイルを圧縮（コンパクション）してクエリ性能を向上。
- VACUUM: 古い未使用データファイルを削除しストレージコスト削減。
- 自動 TTL（Time-to-Live）: 設定期間経過後、マネージドテーブルから行を自動削除。
- ファイルサイズ制御: 目標ファイルサイズの手動制御、または自動チューニング。
設定確認: DESCRIBE DETAIL でテーブル構成・メタデータを表示。テーブルプロパティで挙動を制御。
機能互換性: すべての Delta 機能が全 Databricks Runtime にあるわけではない（Delta Lake のバージョン管理・プロトコルに依存）。
API: Delta テーブルの読み書きは Spark SQL または Spark DataFrame API を使える。Python / Scala / Java 向け OSS Delta Lake API も提供。

3-4. ワークスペース・クラスター・ノートブック・開発言語

ワークスペースと開発の選択肢（Languages ページより）

データプロジェクト・パイプラインは、ローカル IDE でも Databricks ワークスペースでも開発できるが、新規プロジェクトはワークスペースでの開始が推奨。ワークスペースは Web ブラウザーでアクセスでき、Unity Catalog のデータへ簡単にアクセスでき、Genie Code などの強力なデバッグ機能を持つ。
ワークスペースでは Databricks ノートブックまたは SQL エディターでコードを開発。ノートブックは同一ノートブック内でも複数言語をサポート（Python・SQL・Scala）。
ワークスペースで直接開発する利点: フィードバックループが速い（実データですぐテスト）／コンテキスト対応 Genie Code で高速化・問題解決／ノートブック・クエリを直接スケジュール／Python はワークスペース内の Python パッケージとしてファイルを構造化できる。
ローカル IDE 開発の利点: ナビゲーション・リファクタリング・静的解析などのツール／ソース管理方法を選べる（Git のより高度な機能）／サポート言語が広い（例: Java を JAR タスクとしてデプロイ）／デバッグ支援が強い／単体テストのサポートが良い。

サポートされる言語と推奨（重要）

新規プロジェクトの推奨は Python と SQL。
- Python: 非常に一般的な汎用言語。PySpark DataFrames でテスト可能・モジュール型の変換を書ける。豊富なライブラリエコシステム。Databricks でファーストクラスのサポート。ノートブック・Lakeflow パイプライン・ワークフローで使え、UDF 開発、Python スクリプト／ホイール（wheel）としてデプロイ可能。Unity Catalog の関数としても実行可。
- SQL: リレーショナルデータセットの管理・操作（クエリ・更新・挿入・削除）に非常に一般的。データベース／DWH 出身者に向く。spark.sql を使って Python に埋め込むこともできる。ノートブックや SQL エディターで使い、ジョブ／パイプラインとしてデプロイ可能。dbt（data build tool） でのパイプライン開発にもよく使われる。
サポートが限定的で新規データエンジニアリングには非推奨の言語:
- Scala: Apache Spark の開発（オリジナル）に使われた言語。強力だが学習曲線が急。ノートブックでサポートされるが、クラス・オブジェクトの作成・保守に関する制限があり複雑なパイプライン開発が難しい場合がある。通常は IDE の方がサポートが良く、JAR タスクとしてデプロイできる。
- R: Databricks ノートブックでのみ完全にサポートされる。
言語サポートは使う機能にも依存する: 例として Lakeflow パイプラインは Python と SQL をサポート、ワークフロー（ジョブ）は Python・SQL・Scala・Java でパイプラインを作れる。
その他の言語でも Databricks と対話可能だが、主に外部システム統合の文脈: REST API、ODBC/JDBC ドライバー、Databricks SQL コネクタ（Go・Python・JavaScript/Node.js）、または Spark Connect 実装を持つ言語（Go・Rust など）を介する。

開発ツール（参考）

Databricks Connect: ローカル環境から Databricks クラスターに接続してコード実行・ステップデバッグ。
VS Code 拡張機能 / PyCharm プラグイン（JetBrains）。
宣言型オートメーションバンドル（Databricks Asset Bundles）: ジョブやパイプラインを宣言的に定義・デプロイ。
Genie Code: コンテキスト対応でコード生成・問題解決を支援。

4. 構文・コード例

公式ページ本文はリンク中心でコードそのものの掲載は少なめでした。以下は本文中で言及された操作・構文を、学習用に一般的な Delta Lake 構文として補ったものです（挙動はドキュメントの記述に基づく）。

Delta テーブルの作成（既定で Delta 形式）

sql

-- 特に指定しなければ Delta テーブルとして作成される
CREATE TABLE main.sales.orders (
  id BIGINT,
  amount DECIMAL(10,2),
  created_at TIMESTAMP
);
-- USING DELTA は省略可（既定が Delta のため）

DataFrame から Delta 形式で保存（Python / PySpark）

python

# 既定設定で保存するだけで Delta Lake の利点を得られる
df.write.saveAsTable("main.sales.orders")

# Python に SQL を埋め込む
result = spark.sql("SELECT * FROM main.sales.orders WHERE amount > 100")

アップサート（MERGE）

sql

MERGE INTO main.sales.orders AS t
USING updates AS s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET t.amount = s.amount
WHEN NOT MATCHED THEN INSERT (id, amount, created_at) VALUES (s.id, s.amount, s.created_at);

タイムトラベル（過去バージョンのクエリ）

sql

-- バージョン番号で参照
SELECT * FROM main.sales.orders VERSION AS OF 3;

-- タイムスタンプで参照
SELECT * FROM main.sales.orders TIMESTAMP AS OF '2026-07-01';

-- 変更履歴の確認
DESCRIBE HISTORY main.sales.orders;

ファイル管理・メンテナンス

sql

-- 小さいファイルを圧縮（データスキッピング向けに Z-Order も指定可）
OPTIMIZE main.sales.orders ZORDER BY (created_at);

-- 古い未使用データファイルを削除
VACUUM main.sales.orders;

-- テーブルの構成・メタデータ確認
DESCRIBE DETAIL main.sales.orders;

複数テーブルにまたがるアトミックトランザクション

sql

BEGIN ATOMIC
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
END;

構造化ストリーミングで Delta を利用（Python）

python

# ソース／シンクとして Delta テーブルを使用
spark.readStream.table("bronze").writeStream.toTable("silver")

ノートブックでの言語混在（イメージ）: ノートブックは複数言語をサポートし、spark.sql(...) で SQL を Python に埋め込める。セル単位で Python / SQL / Scala を切り替えて使う（同一ノートブック内での混在が可能）。

5. 試験で問われるポイント

Databricks は Apache Spark 上に構築され、コンピュートとストレージが分離されている、という基本アーキテクチャ。
レイクハウス = データレイク + データウェアハウスの利点の統合。単一の信頼できる情報源を実現し、BI と ML を同一基盤・同一データで扱える。3 者の違い（形式のオープン性、ML サポート、レイテンシ）を説明できること。
レイクハウスを支える 2 大テクノロジ = Delta Lake（ストレージ）と Unity Catalog（ガバナンス）。
Delta Lake は Azure Databricks の既定テーブル形式。特に指定しない限りすべてのテーブルは Delta テーブル。Parquet + トランザクションログで構成される。
ACID の各語（Atomicity / Consistency / Isolation / Durability）の意味と、Delta がそれぞれをどう実装するか（原子性＝トランザクションログのコミット、永続性＝クラウドオブジェクトストレージ、一貫性・分離性＝楽観的並行性制御＋書き込みシリアライザブル）。
トランザクションログ（_delta_log）の役割: 変更記録、コミットの原子性制御、バージョン管理（タイムトラベル）、並行制御の基盤。書き込みごとにテーブルバージョンが増える。
タイムトラベルで過去バージョンをクエリできる（VERSION AS OF / TIMESTAMP AS OF）。
**スキーマ適用（書き込み時検証）とスキーマ進化（書き換えなしで変更）**の違い。
MERGE（アップサート）、OPTIMIZE（小ファイル圧縮）+ Z-Order（データスキッピング）、VACUUM（古いファイル削除） の用途。
クラスターの 2 種類: 汎用（対話型・共有・手動終了/再起動可）とジョブ（自動作成・完了時自動終了・再起動不可）。ワークロードの 2 種類（データエンジニアリング＝ジョブクラスター、データ分析＝汎用クラスター）との対応。
SQL ウェアハウスの 3 種類（クラシック / プロ / サーバーレス）。可能ならサーバーレス推奨。
Unity Catalog の 3 階層（catalog.schema.table） と、ボリューム（非表形式データ）・メタストア（アカウントレベル）・カタログエクスプローラーの役割。
DBFS ルート／マウントは非推奨、アクセス管理は Unity Catalog を使う。
DBU が課金単位。アカウントは複数ワークスペースを含む。
開発言語: 新規は Python / SQL 推奨、Scala / R は限定的。Lakeflow パイプラインは Python と SQL、ワークフローは Python/SQL/Scala/Java。R はノートブックのみ完全サポート。ノートブックは複数言語混在可能。
主キー・外部キーは情報的で強制されない点（引っかけ問題に注意）。
Databricks 発の OSS（Delta Lake、MLflow、Apache Spark/構造化ストリーミング、Redash、Unity Catalog）。

6. 理解度チェックリスト

[ ] Databricks データインテリジェンスプラットフォームとは何か、生成 AI や自然言語支援の役割を自分の言葉で説明できる
[ ] データレイクハウスが、データレイクとデータウェアハウスのどの利点・弱点を組み合わせ／克服しているか説明できる
[ ] レイクハウスを支える 2 大テクノロジ（Delta Lake と Unity Catalog）の役割を区別して説明できる
[ ] メダリオンアーキテクチャ（インジェスト→処理・キュレーション→提供）の流れを説明できる
[ ] Delta Lake が Parquet + トランザクションログである、既定のテーブル形式である、と説明できる
[ ] ACID の 4 要素（原子性・一貫性・分離性・永続性）をそれぞれ定義し、Delta がどう実装するか説明できる
[ ] トランザクションログが「コミットの原子性」「バージョン管理」「タイムトラベル」「並行制御」にどう関わるか説明できる
[ ] 楽観的並行性制御の 3 段階（読み取り→書き込み→検証とコミット）と、競合時に何が起きるか説明できる
[ ] 書き込みシリアライザブル分離と読み取りスナップショット分離の違いを説明できる
[ ] タイムトラベルで過去バージョンをクエリする方法（VERSION/TIMESTAMP AS OF）を説明できる
[ ] スキーマ適用とスキーマ進化の違いを説明できる
[ ] MERGE / OPTIMIZE / Z-Order / VACUUM がそれぞれ何をするか説明できる
[ ] アカウントとワークスペースの関係、DBU 課金の仕組みを説明できる
[ ] 汎用クラスターとジョブクラスターの違い（終了・再起動・共有・ワークロード種別）を説明できる
[ ] SQL ウェアハウスの 3 種類を挙げられる
[ ] Unity Catalog の 3 階層（カタログ・スキーマ・テーブル）とボリューム・メタストアの役割を説明できる
[ ] DBFS ルート／マウントが非推奨で Unity Catalog が推奨である理由を説明できる
[ ] ユーザー・サービスプリンシパル・グループ・ACL・PAT の違いを説明できる
[ ] Databricks でサポートされる言語と、Python/SQL が推奨される理由、Scala/R の制限を説明できる
[ ] ノートブックが複数言語を混在できること、spark.sql で SQL を Python に埋め込めることを説明できる
[ ] Lakeflow パイプラインとワークフロー（ジョブ）でサポート言語が異なることを説明できる

Associate 学習教材 ① プラットフォーム基礎 ​

1. このセクションの概要 ​

2. 重要用語集 ​

3. 詳細解説 ​

3-1. Databricks とは / レイクハウスとは ​

3-2. アーキテクチャと主要コンポーネント ​

3-3. Delta Lake の基礎（ACID・タイムトラベル・スキーマ・トランザクションログ） ​

3-4. ワークスペース・クラスター・ノートブック・開発言語 ​

4. 構文・コード例 ​

5. 試験で問われるポイント ​

6. 理解度チェックリスト ​