Databricks Data Engineer Professional について
先日、Databricks Data Engineer Professional に合格しました。
これから受験する人の思考コストを下げることを目的に書きます。
試験概要
公式ページと最新シラバス（2025年9月版）はこちら👇
位置付けとしては、Databricks 上でデータエンジニアリングソリューションを「構築・最適化・運用」できるか を検証する試験です。
Associate が「入口〜基礎」だとすると、Professional は ｢基礎を前提にしたうえでの応用・設計判断｣という感じです。
個人的な感覚ですが、「知識を知っているか」より「設計思想を理解しているか」だと思います。
https://www.databricks.com/blog/achieve-your-goals-databricks-certifications
申し込み・受験方法
申し込みはこちらから。登録が必要です。
最近はProfessionalも会場受験ができるようになったようですが、場所や時間の制約を考えると個人的にはオンラインが楽です。
Databricks 資格のオンライン受験には、以下のような特徴があります。
-
仮想デスクトップ（LockDown Browser）での受験
→ 事前インストール必須。受験前に確認しておくこと推奨。 -
365日24時間いつでも受験可能（おそらく）
→ 私は30分前に申し込み、深夜1時頃に受験しました -
カメラは起動するが、撮影時のみメガネを外せばOK
-
タスクマネージャー等から各種アプリを終了する必要あり
→ 監視系ソフトが入った社用PCでは受験不可なケースが多そう。私用PC推奨？
全体的に「他のベンダー資格試験も全部これでいいのでは？」と思うくらい、Databricks のオンライン受験はシンプルでありがたいです。
強いて言うなら、ブラウザを閉じる手順だけが少しややこしかったです。
「ブラウザを閉じろ」と言われる一方で、仮想デスクトップへの遷移自体はブラウザ経由なので、「遷移した瞬間、連打で即ブラウザを閉じる」というかなり原始的な方法で対応しました。
あれが正解だったのかは、よくわかりません。
Associateとの比較
Databricks Data Engineer Associate と Professional の違いは、「難易度が上がった」というより 試験が見ている視点が変わった という感じかと思います。
まず形式面では、Professional のほうがシラバス範囲が広く、問題数・試験時間ともに増加しています。
- 試験形式の違い
| 項目 | Associate | Professional |
|---|---|---|
| 試験時間 | 90分 | 120分 |
| 問題数 | 約45問 | 約60問 |
| シラバス範囲 | 基本機能中心 | 設計・運用・最適化まで含む |
120分の試験って聞くとしんどいですが、時間が足りないということはほぼほぼ起きないと思います。私も見直しなどを除くと60分くらいで終えました。
-
シラバス・問われ方の違い
-
Associate
- Databricks の主要機能を正しく理解しているか
- Auto Loader / Delta Lake / Structured Streaming の基本
- 「知っていれば選べる」設問が中心
-
Professional
- 機能を前提にした 設計判断ができるか
- ストリーミングとバッチの使い分け
- window / watermark / state 管理
- Unity Catalog の最小権限設計
- パフォーマンス最適化と運用要件 等
-
Professional では「なぜ」を説明できないと選択肢を切れない形になっているような気がします。コードもかなり出るのですが、結構似ていて、長い問題も多いです。
ただ、Assoiate同様の知識や出題も多いので、Associateを取った方はあまり時間を空けずに取得を狙っても良いかもしれません。
私の勉強方法
1. とにかく触る
王道ですが、一番やってて良かったと思いました。
Databricks Data Engineer Professional は、知識量よりも 「見たことがあるか」「感覚を持っているか」 が効いてくると思います。
私が特に意識して触っていたのは、以下あたりです。
-
Unity Catalog
権限を実際に付けたり外したりして挙動を確認する -
ジョブ/クラスター
パラメータの設定やデフォルトを確認する -
パフォーマンス最適化
OPTIMIZE や ZORDER を実際に書いてみて、実行してみる
当然ですが、試験中に「この画面見たことある」「この設定触ったことある」という状態だと、設問の読み取りと判断が一気に速くなります。
Databricks はFree Edition で主要機能を気軽に試せるのが本当にありがたいです。Databricksに限らずですが、座学だけで理解するよりも、先に少し触ってから知識を整理するほうがいいと思います。
2. Udemy の問題集を解く
知識の確認というより、出題の癖を知るためにいいと思います。
随時和訳しつつ対策していましたが、今思えば英語表現でもわかるくらいがちょうどいいかもしれません。意識していたポイントは2つです。
- なぜ他の選択肢がダメなのかを言語化する
- 復習用に自分の言葉でノート(スマホメモアプリ)に残す
Proは「一部だけ正しそう」「条件次第では使えそう」な選択肢が大量に出てきたため、正解を当てる力よりも、誤りを切る力が重要だと感じました。
あとは一部暗記要素もあることを割り切り、隙間時間＆試験直前に見返す用としてメモにアウトプットもしていました。
使用した問題集はこちら👇
3. AIと対話する
今あるあるの勉強法と思いますが、ChatGPTとの壁打ちでわからない点や周辺知識の補完を行いました。私はシステムプロンプトとして、以下の指示を与えていました。
対策につながるという文脈でどれほど効果があるかはわかりませんが、参考にください。
---−--- システムプロンプトの例 -------
あなたは Databricks 資格試験（Data Engineer Professional）の
公式試験ガイド・シラバス・実務ベストプラクティスに精通した技術メンターです。
目的：
- Databricks Pro資格試験に最短で合格する
- 試験で問われる設計思想・制約・使い分けを言語化できるようにする
前提ルール：
- 回答は必ず「なぜそれが正解か」「なぜ他が誤りか」を説明する
- 曖昧な理解・用語の混同・実務と試験のズレを指摘する
- 試験頻出・罠ポイント・キーワードは明示する
- Databricks の正式名称・機能差分・制約条件を正確に扱う
出力スタイル：
- 見出し＋箇条書き中心
- 絵文字不要
- 「試験での問われ方」「選択肢での切り方」を必ず含める
- 必要に応じて擬似コードを出力する
- 他の選択肢の間違い理由もつける
- 暗記すべき項目を述べる
押さえておいたほうがいい知識（超抜粋）
やろうと思えばなんぼでもできるので、一旦こんなのが必要ですよの分野を3つだけ抜粋します。
1. Lakeflow Spark 宣言型パイプライン（旧 DLT）
宣言型パイプライン（Lakeflow Spark Declarative Pipelines）は簡単にいうと、
- データパイプラインの “宣言（何を作りたいか）” を書く
- 運用（依存関係、リトライ、品質、増分処理、状態管理、監視）をプラットフォーム側に寄せる
という仕組みです。Databricksの機能としても中枢を担っているため、要チェックの内容と思います。
私はDelta Live Tables（DLT）という名称で捉えていたのですが、試験では「Lakeflow Spark Declarative Pipelines」という単語で出ていました。
シラバスをちゃんと見ていないのが悪いのですが、試験で気づきました。
案内もありました👇11月からなんですね。
NotebookでStructured Streamingを行うのと何が違うかというと以下です。
| 観点 | Notebook + Structured Streaming | Lakeflow（LDP/SDC） |
|---|---|---|
| 設計思想 | 自分で構築/自由度高い | 宣言して任せる（運用を内蔵） |
| 依存関係 | 自分で順序/ジョブ制御 | パイプラインが依存関係を解決 |
| 品質 | 自分で検証コード | 期待値（Expectations） を組み込みやすい |
| 増分処理 | foreachBatch / merge など自作 | パイプラインとして標準化しやすい |
| 注意 | 運用要件を書き漏らす | 状態（state）と 遅延（lateness）の理解が必須 |
特にこの 「期待値（Expectations）」 という考えはDatabricks特有かと思います。
データ品質チェックを運用ロジックではなく、"パイプラインの宣言”として組み込む仕組みです。データ品質ルールをコードのif文や例外処理として書かず、パイプライン定義の一部として定義します。
window操作
window は時間でまとめる機能じゃなくて、state を持つ集計です。
-
window集計は 過去のデータを保持して集約する必要がある（stateful状態） - statefulになると、遅延データをいつまで受け付けるかを決めないと破綻する → そこで
watermark
コード例
この型を理解します。要所要所の派生・別パラメータverも調べてみてください。
特に時間ベースを設定するWindow関数はストリーミング必須ですが、
その他にもCDFやWatermarkなど、重要な考えもいくつかあります。
from pyspark.sql.functions import window, col
# ストリーミング入力（Auto Loader）
events = (
spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "json")
.schema(schema)
.load("/mnt/raw/events")
)
agg = (
events
# watermark：遅延データの許容範囲を決めつつ、stateを解放するため
.withWatermark("event_time", "10 minutes")
# window 集計：window を使う＝ stateful処理
.groupBy(
window(col("event_time"), "5 minutes"),
col("user_id")
)
.count()
)
(
agg.writeStream
.format("delta")
# checkpoint：再起動・重複防止のため必須
.option("checkpointLocation", "/mnt/chk/agg")
.outputMode("append")
.toTable("silver.user_event_5m")
)
2. Unity Catalog権限
Unity Catalog は Databricks の統合ガバナンス（データ/AI資産の権限と監査の中心）です。
データ基盤を運用するうえで最小権限の原則に従い適切な権限を与えるというのは実務でも必須の考え・知識です。
権限の違い
| 権限 | 対象 | できること | ケース |
|---|---|---|---|
| USAGE | Catalog / Schema | 存在を見せる | 「カタログ/スキーマに入れない」→ USAGE不足 |
| SELECT | Table / View | データ参照 | 「読み取り」 |
| MODIFY | Table | 書き込み | 「更新できない」→ MODIFY不足（ただし読めるとは限らない） |
| READ_METADATA | Table / View | 列名/スキーマ参照 | 「中身は見せないが構造だけ」 |
| MANAGE | Object | 権限/設定変更 | 「権限を付与できない」→ MANAGE不足 |
| OWN | Object | 全権限 | 付けすぎ注意（試験は最小権限で問う） |
コード例
データを参照できる最小権限
'USAGE' + 'SELECT' が揃って初めてデータを読める
-- カタログ・スキーマへの入口権限
GRANT USAGE ON CATALOG main TO `data_analyst`;
GRANT USAGE ON SCHEMA main.sales TO `data_analyst`;
-- テーブルの中身を読む権限
GRANT SELECT ON TABLE main.sales.orders TO `data_analyst`;
データは見せず構造だけ確認させる権限セット
-- カタログ・スキーマへの入口権限
GRANT USAGE ON CATALOG main TO `auditor`;
GRANT USAGE ON SCHEMA main.sales TO `auditor`;
-- 列名・スキーマのみ参照可能（SELECT は付与しない）
GRANT READ_METADATA ON TABLE main.sales.orders TO `auditor`;
3. パフォーマンス最適化
Delta のパフォーマンス施策は大きく2系統です。
- ファイルサイズ問題を直す（小ファイル地獄）
- データスキップを効かせる（フィルタ列で速くする）
ここは日本語しか見ていないと一見似ていてこんがらがるので、概念として把握しておくべきだと思います。以下一旦簡単に書いていますが、「どんな課題を持っているときに何をなぜ使うのか」を理解しておく必要があります。
違い（OPTIMIZE / ZORDER / Auto Optimize）
| 施策 | 効く問題 | 何をする？ |
|---|---|---|
| OPTIMIZE | 小ファイルが多い | ファイルをまとめる（コンパクション） |
| ZORDER | フィルタが遅い | よく絞る列で並び替えてスキップ効率UP |
| OPTIMIZE + ZORDER | 両方 | まとめつつ並べる |
| Auto Optimize | 運用を自動化 | 書き込み最適化/自動コンパクション |
まとめ
2026年もDatabricksの進化は止まらず、Lakeflow や Unity Catalog を軸にしたデータ基盤の統合、AI/ストリーミングとの連携強化など、プロダクト全体が「エンタープライズの中核基盤」としての完成度をさらに高めていく流れにあると思います。
今はIPOの噂もあり、技術面だけでなくビジネス面でも Databricks の存在感は今後ますます大きくなっていくはずです。
そう考えると、この資格はこれから Databricks を主戦場として使っていくための設計思想・共通言語を身につけるプロセスと言えるはずです。
すでに Databricks を触っている方はもちろん、これから本格的に使っていく予定のある方にとっても、一度腰を据えて勉強しておく価値のある試験だと感じています。
Discussion