Databricks Certified Data Engineer Professional 資格対策

Databricks Certified Data Engineer Professional は、Databricks 上でのデータエンジニアリング全般に精通していることを証明する上級資格です。このブログでは、出題ドメインの概要と、各ドメインで学習すべきポイントを整理し、資格取得のための学習ガイドとしてまとめます。

• 2025年3月時点の情報で整理しています。

資格のドメイン構成

資格試験は以下の7つのドメインに分類されています：

1. Data Engineering Fundamentals（基礎知識）
2. Data Processing and Transformation
3. Data Pipeline Development
4. Data Modeling and Storage
5. Data Governance and Security
6. Performance Optimization and Troubleshooting
7. Advanced Spark Programming

1.Data Engineering Fundamentals（基礎知識）

「Data Engineering Fundamentals」では、DatabricksとSparkの基礎技術に加えて、クラウドストレージ連携、Delta Lakeの操作、ストリーミング、アクセス制御、Auto Loaderの動作など広範な知識が問われます。 特に、Delta Lakeのマネージド／アンマネージドの違いや制約（CHECK, NOT NULL）の追加方法、Auto Loader のスキーマ進化モード、Structured Streaming の設定（withWatermark + window関数）は頻出です。 UIやCLIベースの操作、Databricks独自の用語や挙動も問われるため、実環境で操作しておくことをおすすめします。

【1】Databricks ワークスペース・権限・シークレット

• ノートブックやクラスター、ジョブに対する最小限権限（例: 読み取り・実行）
• シークレット管理（Databricks CLI / REST APIでスコープ作成、dbutils.secrets.get() の出力形式）
• シークレットスコープに設定できる権限（例: 読み取り / 作成 / 書き込み / 管理）

対策：実際にノートブックやCLIで dbutils を使いながらアクセス制御を確認し、どの操作にどの権限が必要かを整理しておきましょう。

【2】クラスター・ライブラリ・ジョブの管理

• クラスターの作成方法（UI / CLI / API）
• クラスターに追加できるライブラリの種類（JAR, Python Egg, Wheel）
• クラスターアクセス制御（attachable, can restart, can manage など）
• ジョブの修復実行（Repair run）が使える条件

対策：クラスタータイプ（ジョブ vs 汎用）、Repair Runの対象範囲、固定クラスターの維持など、UI上での設定やその裏側の挙動も押さえておくと確実です。

【3】Delta Lake 基礎

• マネージド / アンマネージド（EXTERNAL）テーブルの違いと LOCATION 指定
• Z-ORDER：行数に基づくファイル最適化
• ディープクローン / シャロークローン：元のテーブル削除後の挙動やメタ情報の継承範囲
• VACUUM と DRY RUN オプション
• 制約の追加（CHECK、NOT NULL）

対策：Delta Lakeの制約や操作に関してはSQLベースでのコマンド挙動を確認するだけでなく、ファイルレベルの動作（クローンの依存関係やファイルサイズ）も見ておきましょう。

【4】ETLとデータパイプラインの設計基礎

• Bronze/Silver/Gold（マルチホップ構成、メダリオンアーキテクチャ）の役割
• 集計テーブル更新戦略（タイプ1/2/3のSCD）

比較：Type 1、Type 2、Type 3

特徴 / 種別	Type 1	Type 2	Type 3
説明	古い値は上書きされ、履歴は保持されない	古い値は維持され、新しい値が別行で挿入される	古い値と新しい値を同一行に持つ、履歴は1つのみ
履歴保持	×なし	〇フル	△一部（直近のみ）
テーブル構造	単純	複雑（複数行）	やや複雑（複数列）
データ件数の増加	↓増えない	↑増える	→行数変わらず
代表列	なし	is_current, start_date 等	current_〇〇, previous_〇〇
用途	最新情報だけ必要なケース	変更履歴が必要なケース	前後比較が重要なケース

• details Type 1（上書き）

MERGE INTO dim_table tgt
USING (
SELECT * FROM table_changes('src_table', latest_version - 1, latest_version)
WHERE _change_type IN ('insert', 'update_postimage')
) AS src
ON tgt.id = src.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

※ _change_type を使うことで、更新 or 追加のみを対象にできる。

• Type 2（履歴保持）

-- Step 1: 現在の行を終了
UPDATE dim_table
SET end_date = current_date(), is_current = false
WHERE id IN (
SELECT id FROM table_changes('src_table', v1, v2)
WHERE _change_type = 'update_postimage'
);

-- Step 2: 新しい行を挿入
INSERT INTO dim_table
SELECT id, ..., current_date() AS start_date, null AS end_date, true AS is_current
FROM table_changes('src_table', v1, v2)
WHERE _change_type IN ('insert', 'update_postimage');

※ update_postimage は「更新後の状態」。
※ update_preimage を使えば「更新前の状態」での比較も可能。

• Type 3（直近の履歴を列で保持）

-- 変更がある行を更新
UPDATE dim_table tgt
SET
previous_value = tgt.current_value,
current_value = src.current_value
FROM (
SELECT id, current_value
FROM table_changes('src_table', v1, v2)
WHERE _change_type IN ('insert', 'update_postimage')
) AS src
WHERE tgt.id = src.id;

• Structured Streamingの適切な使い方
  • withWatermark vs window
  • dropDuplicates() の使い方と trigger 時間の設計

対策：foreachBatch() の活用、集計レイヤーの更新戦略（フル vs インクリメンタル）などを一度サンプルで書いてみると、本番での選択肢に迷わなくなります。

【5】Auto Loader / スキーマ管理

• Auto Loader の rescue モード：新しい列 → _rescued_data に記録、スキーマ進化なし
• パーティション推論：s3://path/year=2023/month=11/... → year, month が列に推論
• 大文字・小文字の扱い（ReaderCaseSensitive=false）

対策：Auto Loader の仕様はやや細かいため、デフォルト動作と設定可能なオプションを切り分けて覚えるのがコツです。

【6】Sparkのキャッシュ・パーティション・実行計画

• persist() はストレージレベル指定可能、cache() は MEMORY_ONLY
• Spark UI での Jobs, Stages, Storage, Environment タブの意味
• DataFilters, PushedFilters などは物理プランに属する情報
• Spark の partition ヒント：repartition, coalesce, repartitionByRange

対策：Spark UIの画面を開きながら、どの処理がどのプランに属しているかや、UIの各タブの意味と活用を確認しておきましょう。

【7】テストとバージョン管理

• テストフレームワーク（Python: pytest, R: testthat）
• 単体テスト → 統合テスト → システムテスト → 受け入れテスト
• Databricks Repos のバージョン管理：merge conflict 解決 などは GitHub 側

対策：一般的なテスト戦略に加え、DatabricksでのノートブックテストやReposのGit連携操作も確認しましょう。

2.Data Processing and Transformation

「Data Processing and Transformation」では、Spark（Structured API）を用いたデータの読み取り・変換・出力処理に関する深い理解が求められます。バッチ処理・ストリーム処理の両方が対象で、特にDelta LakeやAuto Loaderと組み合わせた高度なパターンも出題されます。

【1】データ変換処理（ETL）の基本操作

• 結合操作の最適化（例：小さいテーブルをbroadcast()して結合）
  • df1.join(broadcast(df2), "id", "inner")
• 結合後の重複列削除 → .drop() 関数が正解
• DataFrameのキャッシュ vs persist の違いとストレージレベル（MEMORY_ONLY など）
• foreachBatch() の使用 → ストリーミングマイクロバッチ処理における制御構文

対策：結合パターン・重複除去・キャッシュの挙動は実装コードで一度は書いて確認しておきましょう。

【2】構造化ストリーミング（Structured Streaming）

• withWatermark() → 遅延データの破棄しきい値の定義
• window() → 時間集約・スライディングウィンドウ処理
• dropDuplicates() → イベントキーとWatermarkを組み合わせて重複除去
• ストリーム-ストリーム結合 → 外部結合にはウォーターマーク必須
• トリガー間隔（デフォルトは 500ms）
• Auto Loaderとの組み合わせにおけるスキーマ進化モード（Rescue モード）

対策：Watermark・Window・Deduplicationの組み合わせはコードベースで整理し、どういう挙動を示すかを説明できるようにしましょう。

【3】Auto Loader & スキーマ進化

• Rescue モード → スキーマ展開せず、新しい列を _rescued_data に格納し続行
• ReaderCaseSensitive = false → 列名の大文字小文字を無視する設定
• パーティション推論 → year=2023/month=11/ 形式のディレクトリからの自動列追加
• Auto Loaderで読み込んだ Parquet や JSON のスキーマ進化管理

対策：Rescueモードの挙動パターンの理解と制御方法を整理。大文字小文字設定などのプロパティ名は選択肢として細かく問われます。

【4】Delta Lake を用いた変換パターン

• ストリーミング → Bronze テーブル → Change Data Feed（CDF）で差分取得
• データの型変換、フィルタ、SCD（Type 1/2/3）などの処理
• OPTIMIZE や Z-ORDER によるファイル最適化

対策：Change Data Feed（delta.enableChangeDataFeed = true）による変更検知の仕組みと、Type 1/2/3 テーブルの違いは覚えておきましょう。

【5】パーティション・ファイル出力最適化

• Parquet 出力でのシャッフル数調整（spark.sql.shuffle.partitions）
• ファイルサイズ調整（例：1TB を 512MB で分割 → 2048 partitions）
• Delta Lake ではなく Parquet を使う場合の最適化方法に注意（自動圧縮が無いため明示的な設定が必要）

対策：shuffle.partitions の計算（データサイズ ÷ 目標ファイルサイズ）を例題で練習。

【6】Spark 実行計画の理解

• 論理計画（Logical Plan）と物理計画（Physical Plan）の違い
  • DataFilters, PushedFilters は物理計画に含まれる
• explain() で確認できる情報

対策：Spark UI や df.explain() で確認できる内容をスクリーンショットで整理しておくと安心。

3.Data Pipeline Development

「Data Pipeline Development」では、Databricks 上での実用的なパイプラインの設計・実行・制御方法が問われます。 Delta Live Tables の設定、ジョブのアクセス権限制御、REST API や Secrets の活用、修復実行（Repair Run）の制限など、運用実務を見据えた知識が求められます。さらに、クラウド横断のETL設計やマウント共有戦略など、信頼性とセキュリティの観点も重要です。

【1】ジョブとタスクの構成・依存関係

• 複数タスクを含むDatabricksジョブの制御と依存性（例：A→BとCの依存構造）
• Repair run の制限 → 単一タスクジョブには適用不可
• タスク失敗時の影響範囲理解（例：一部成功、一部失敗時の振る舞い）

対策：ワークフロー実行順とリカバリ手法（Repair Run）について具体例で整理。

【2】ジョブ実行とアクセス権限

• ノートブックに付与できる最小限のアクセス権限 → 「読み取り権限」で %run 可能
• Databricksジョブに関する適切な権限設定（例：「管理可能」「実行可能」「表示可能」など）
• Databricks Secrets との連携によるジョブのセキュア実行（例：dbutils.secrets.get()）

対策：ジョブ／ノートブック／クラスター単位の アクセス権限の粒度と範囲 を理解。

【3】Delta Live Tables (DLT) の構成

• 保存パスに対してイベントログの保存場所
  • /teams/prod → /teams/prod/system/events
• DLTのサポート言語 → Python と SQL（Scala は未対応）
• DLTでのCDC処理：allowOverwrites = false による削除／更新の防止
• ストリーミングからDLTへの安定した取り込み戦略

対策：DLTのパイプライン構成、設定オプション、実行ログの場所を把握。公式ドキュメントの例を確認。

【4】ジョブクラスター vs 汎用クラスター

• ジョブクラスターは実行時に作成・完了時に削除される一時的クラスター
• 汎用クラスターは手動・再利用型
• 間違った知識選択肢例：「ダッシュボードはジョブクラスターしか使えない」→誤り

対策：クラスター種類ごとの特徴、ライフサイクル、費用対効果を整理。

【5】マウント／クラウド連携

• 異なるクラスターでのマウント共有には dbutils.fs.refreshMounts() が必要
• Secretsを使ってマウント時の資格情報をセキュアに管理するのが推奨

対策：S3 / Blob / GCSへのアクセスにおけるマウント戦略とセキュリティ考慮を確認。

【6】REST API／CLIによるパイプライン操作

• REST API 呼び出しのユーザーIDが 監査ログに正しく記録される ことの理解
• REST API のレスポンス構造や正誤判断（例：run-now → { "run_id": 123 }）

対策：REST API によるジョブ作成・実行・監査ログ追跡などの基本的なシーケンスを押さえる。

【7】パイプライン信頼性設計（複数クラウド）

• 異なるクラウド間をまたぐ ETL：
  • S3 → Azure Blob → GCP など、1ノートブックでの段階的なロード
• 再実行時の副作用や冪等性（Idempotency）の考慮

対策：クラウド横断パイプライン構成の例や、部分失敗時の再処理設計を確認。

4.Data Modeling and Storage

「Data Modeling and Storage」では、Delta Lake による高信頼データ管理の知識が求められます。管理対象／外部テーブルの定義、Z-ORDER やパーティションによる検索最適化、PIIデータへの制約設定、Clone機能による開発フロー効率化など、設計・運用視点のモデリング能力が問われます。
Parquet の統計情報や Auto Loader との連携によるスキーマ進化の制御も理解が必要です。

【1】テーブルの種類と管理対象／非管理対象

• CREATE TABLE と LOCATION キーワードの使い方
  • テーブル作成時に LOCATION を指定すると → 外部テーブル（非管理対象）
  • データベース作成時の LOCATION → テーブルのデフォルト保存先を定義
• 外部テーブル強制設定には CREATE TABLE EXTERNAL を使用

対策：管理対象／非管理対象の違いを理解し、DLT・ETLでの使い分けを明確に。

【2】Delta Lake のクローン機能（Shallow / Deep Clone）

• Deep Clone：データとメタデータを完全コピー（元のテーブル削除後も利用可能）
• Shallow Clone：メタデータのみコピー（元テーブル削除でエラー）
• コメントやTBLPROPERTIESの継承に違いあり：
  • コメント → 継承されない
  • プロパティ → 継承される

例：Deep Clone と Shallow Clone の使い分けイメージ

-- Deep Clone: 本番データのバックアップやテスト環境複製に
CREATE TABLE my_table_backup DEEP CLONE prod_table VERSION AS OF 10;
-- Shallow Clone: メタデータ確認用の一時派生テーブルに
CREATE TABLE temp_table SHALLOW CLONE prod_table;

比較：Deep CloneとShallow Clone

特徴	Deep Clone	Shallow Clone
データのコピー	データもコピー	× データはコピーせず参照のみ
メタデータ（スキーマ、履歴、プロパティなど）	一部コピー	一部コピー
元のテーブル依存	× 依存しない	依存する
使用ユースケース	本番→テスト環境用に完全複製	軽量なテーブル派生・一時的用途
クローン作成時のストレージ増加	↑（データ複製）	↓（メタデータのみ）

対策：クローンの動作や用途（テスト、バックアップ）を整理。

【3】Z-Order とパーティション設計

• Z-ORDER はフィルターでよく使う列をまとめて保存し、I/O効率を向上
  • テキスト列以外にも利用可能、行数を均等にファイル分割
• パーティション列は、カーディナリティが低く、フィルタリングに頻出の列を選ぶ
• パーティション列の統計収集は、32列目までがデフォルト

対策：OPTIMIZE ZORDER BY の適用タイミングや、列の並び順変更によるデータスキッピング効率向上に注意。

【4】制約とテーブルスキーマ管理

• サポートされる制約：
  • NOT NULL
  • CHECK（→ 構文に ADD CONSTRAINT <name> CHECK (...) が必要）
  • DEFAULT（一部プレビュー機能）
• 特定列（例：性別など）は PII に分類されない → GDPR対応設計も問われる

対策：テーブル定義時の制約構文、制約適用によるデータ品質保証、匿名化戦略の理解。

【5】データ削除・ストレージの整理（VACUUM）

• VACUUM <table> RETAIN <hours> DRY RUN で削除予定ファイル確認
• 規定の最小保持期間（デフォルト：168時間（7日間））より短い値を指定するには特別な設定が必要

対策：不要な履歴削除の仕組みと、DRY RUNでの安全確認方法を理解。

【6】スキーマ進化とAuto Loaderとの関係

• Auto Loader + Rescue モード：
  • 新しい列 → _rescued_data に格納
  • スキーマ自体は進化しない
• スキーマ進化時の大小文字区別無視 → ReaderCaseSensitive = false で対応

対策：Auto Loader の設定項目と、進化モードの動作を明確に区別すること。

【7】Parquet のカラム統計と保存形式

• Parquet ファイルフッターに含まれる情報：
  • min値 / max値 / null count / データ型
  • 平均値は含まれない（試験では頻出のひっかけ）

対策：Parquet における統計情報の活用方法（データスキッピング、フィルタープッシュダウン）を理解。

5.Data Governance and Security

「Data Governance and Security」では、Databricks 環境におけるセキュリティ設計とデータ保護が問われます。シークレット管理、PII対応、アクセス権限の適切な設定、監査ログの記録に対する理解を深めることが重要です。特に、最小権限の原則に基づいた操作制限の設計や、GDPR/CCPAなど法令遵守の実装は実務でも即戦力となります。

【1】Databricks Secrets（シークレット管理）

• シークレットの作成は CLI または REST API のみ
  • dbutils.secrets() は参照のみ
• シークレットの取得：
  • dbutils.secrets.get(scope='prod', key='認証情報') # => '[REDACTED]'
• **機密情報（アクセスキー、パスワードなど）**は、ノートブックにハードコードせず Secrets で管理

対策：scope の作成方法、アクセス方法、表示されない理由を理解する。

【2】シークレットのアクセス許可

• シークレットのアクセス権レベルは以下の4つ：
  • read / write / create / manage
• 最小権限の原則に基づいた設定が前提

対策：ユーザーやグループごとに適切なアクセスレベルを設定できるようにする。

【3】ノートブックやジョブへのアクセス権管理

• ノートブック：
  • 実行のみ許可したい場合 → 「読み取り」権限で %run が可能
• ジョブ：
  • 実行管理権限 があれば、削除権限なしで UI 実行が可能
• クラスター：
  • 再起動可能 や アタッチ可能（Attach） 権限の違い
• Databricks Repos（Git連携）：
  • 競合解決など一部のバージョン管理操作はGitHubで実施

対策：それぞれの権限レベルの具体的な操作可否を整理。

【4】監査ログ（Audit Logs）とユーザー識別

• REST API 使用時も、個別のユーザーIDはログに記録される
  • ジョブ作成とジョブ実行は、それぞれの呼び出しユーザーの ID が記録
• ログの用途：
  • 操作追跡・不正利用検出・セキュリティインシデント対応

対策：実際にどう識別されるか、API 呼び出し時のログ出力の違いを押さえる。

【5】PII・GDPR/CCPA 対応とデータ匿名化

• デルタテーブルに含まれる PII列（名前、生体情報、パスポート番号など） は匿名化や削除対象
• GDPR対応で問われる主な技術手法：
  • 列の削除
  • データの匿名化（例：ハッシュ化、マスキング）
  • アクセス制限（ACL）
  • DELETE + VACUUM による物理削除（注意：保持期間制限あり）

対策：「削除」「匿名化」「制約（NOT NULL など）」の使い分けとその影響を理解。

【6】クラスター構成のセキュリティ管理

• 30日以上停止してもクラスター構成を維持したい場合 → クラスターを固定（pin）
• 停止中のクラスターでも、ノートブックの権限設定は維持される

対策：ジョブ実行の際のクラスター起動、固定の仕組みを整理。

【7】Databricks SQL アラートの挙動

• 複数値を返す列に対してアラートを設定した場合：
  • 「最初の値」などを選択してトリガー条件を定義
• 通知トリガー条件：「アラートが評価されるたびに」などの頻度指定が可能

対策：通知頻度設定やアラート評価対象の意味を把握。

6.Performance Optimization and Troubleshooting

「Performance Optimization and Troubleshooting」では、Databricks におけるクエリとジョブのパフォーマンス最適化スキルが問われます。Spark UI と Ganglia の使い分け、キャッシュやファイル出力サイズの最適化、ブロードキャスト結合やストリーミングの制御など、実践的な知識が中心です。
特に、AutoOptimize の副作用やエラーメッセージの意味を正しく理解し、トラブル時の切り分けができることが求められます。

【1】Spark UIとGangliaの使い分け

• Spark UI
  • DAG 可視化 → 「ジョブ」「ステージ」「タスク」タブ
  • 環境タブ → ランタイム情報・Sparkプロパティ・Hadoopプロパティ
  • 「ストレージ」タブ → キャッシュ状況やメモリ使用量
• Ganglia UI
  • CPU使用率・ディスクIO・ネットワーク使用率 などのシステムメトリクスを可視化

対策：「クラスター CPU 使用率の確認は Ganglia」「DAG の可視化は Spark UI のジョブタブ」など役割の違いを整理。

【2】キャッシュと永続化の最適化

• cache() は persist(MEMORY_ONLY) のショートカット
• persist() は任意のストレージレベルを選べる（例：MEMORY_AND_DISK）
• キャッシュ失敗の兆候：Spark UI のストレージタブに ' アノテーションあり（例：サイズ不足）

対策：cache() / persist() の違いと失敗時の確認方法（UIでの兆候）を押さえる。

【3】ファイルサイズ最適化（書き出しパフォーマンス）

• Delta でない Parquet 書き込み時は自動調整されない
  • spark.sql.shuffle.partitions や maxPartitionBytes で調整が必要
• 最適なファイルサイズの目安：128〜512MB
• optimizeWrite や AutoOptimize は Delta 特有の機能

対策：Parquet を使う場合、シャッフル数とターゲットファイルサイズの計算に注意

【4】MERGE 処理時のファイルサイズが小さくなる理由

• AutoOptimize は MERGE の応答性向上のため、小さいファイルを生成することがある
  • パーティションサイズに関係なく、小ファイルが多くなる可能性
• OPTIMIZE + Z-Order は手動で補完可能

対策：AutoOptimize の目的・副作用を理解して使い分け

【5】Broadcast Join の動作理解

• df.join(broadcast(df2), ...) の場合 → df2 が全ワーカーにコピーされる
• 小さなルックアップテーブルを結合する場合に有効（数十MB以内が理想）

対策：ブロードキャストされるのは broadcast() を明示した方のDF、全体に展開される仕組みを確認

【6】ストリーミングジョブのトラブルシューティング

• デフォルトのトリガー間隔は 500ms
• foreachBatch() を使うことで 各マイクロバッチ単位の処理をカスタム可能
• エラーの位置特定には DAG・ジョブステータス・クラスターUI を活用
• dropDuplicates() などを使って重複データ抑制も重要

対策：マイクロバッチ単位の制御、トリガー間隔、ウォーターマーク設定の使い分けを把握

【7】Databricks SQLアラートとパフォーマンス

• 集計対象の選択（最初の値 / 平均値など）
• トリガー頻度：「アラートが評価されるたびに」「一度だけ」などの設定を活用

【8】エラーメッセージと対処例

• AMBIGUOUS_REFERENCE: 結合後の 重複列（同じ名前の列）に対する select が曖昧
• 解決方法：明示的に df.col("xxx") で参照元を指定
• VACUUM の DRY RUN オプションを使って、削除対象ファイルの事前確認が可能

7.Advanced Spark Programming

「Advanced Spark Programming」では、Spark の内部動作や高度なプログラミング手法について深く問われます。論理計画や物理計画の構造、パーティションの制御、マイクロバッチ処理のための foreachBatch() の利用法など、実装レベルの最適化スキルが求められます。特に、パフォーマンスや効率を意識した構文の選択や、UIを用いたトラブルシューティング技術 が試験突破のカギになります。

【1】論理プラン / 物理プランの理解

• explain() で確認できるのは、論理計画 → 最適化論理計画 → 物理計画
• DataFilters / PushedFilters / PartitionFilters は物理プランに表示される要素
• Spark UI 上では DAG や各ステージの構造が可視化可能

対策：explain() の出力形式とフィルタのプッシュダウン確認方法を押さえる。

【2】パーティショニング戦略とヒント

• Spark のパーティショニングヒント：
  • repartition, coalesce, repartitionByRange, rebalance など
• 誤答肢: shuffleHash（存在しない）

対策：パーティション制御の各関数の効果と使い所（シャッフル有無など）を理解しておくこと。

【3】foreachBatch() の活用

• Structured Streaming で各マイクロバッチに対し処理を実行するには foreachBatch() を使用
• foreachUDF() などの関数は存在しない（誤選択肢として出題）

対策：マイクロバッチごとに RDBMS への書き込みや条件付きロジックを実装するにはforeachBatch() を使う。

【4】cache() / persist() の違い

• cache() → persist(StorageLevel.MEMORY_ONLY) のエイリアス
• persist() はストレージレベルを指定可能（例：MEMORY_AND_DISK）
• 永続化の解除には unpersist() を使用（cache() 使用時も可）

対策：ストレージレベルによる違いと選定基準（メモリ不足時の動作）を整理。

【5】ジョブ・ステージ・タスクの可視化と制御

• DAG（有向非巡回グラフ）やステージの依存関係を把握できるのは Spark UI の「ジョブ」タブ
• ストリーミング DAG の視覚化も「ジョブ」タブに表示される

【6】Spark の REST API 操作とレスポンス

• 2.0/jobs/run-now や 2.0/jobs/runs/submit → 正常レスポンスは { "run_id": ... }
• 間違い例：2.0/jobs/run-now - {"job_id": 5876}（→ job_id ではなく run_id）

対策：REST API エンドポイントと対応するレスポンススキーマの紐付け理解が必要。

【7】UDFの使用に関する注意点

• PySpark で UDF を使用する場合、シリアライゼーションやスカラー変換のコストが高くなる
• broadcast() を活用することで結合の効率化が可能（DataFrame のブロードキャスト）

【8】クラスターのカスタムライブラリ

• Databricks クラスターにアップロード可能なファイル形式：
  • JAR, Python Egg, Python Wheel
• pip install ではノートブック単位のインストールになるが、クラスターに追加するには上記形式が必要