この度、Databricks Data Engineer Associate認定資格を取得しました！

この記事では、資格の取得に向けて私が学習した内容・おすすめの勉強法をまとめています。
Databricksの主要な概念から実践的な機能まで、以下の試験項目に分けて各トピックを整理しました。

Databricks公式より、試験内容と割合

試験サイト：
　https://www.databricks.com/jp/learn/certification/data-engineer-associate

試験時間は90分で45問

Databricks Intelligence Platform - 10%
Development and Ingestion - 30%
Data Processing & Transformations - 31%
Productionizing Data Pipelines -18%
Data Governance & Quality - 11%（本記事では扱いなし）

私は出題割合 30% を占める Development and Ingestion と Data Processing & Transformations に注力しました。

これから受験される方の参考になれば幸いです。

おすすめの勉強方法

まずはUdemy｜Practice Exams: Databricks Certified Data Engineer Associateの模擬試験を解いてみる
- 本試験に対する自分の知識のむらを確認、学習計画に活かす
間違えた問題についてChatGPTで解説を受ける
- Databricks公式ドキュメントでChatGPTの解説が合っているかを確認
苦手な分野はUdemy｜UPDATED: V25 JULY 2025 | Complete preparation for Databricks Data Engineer Associate certification + hands-on trainingで体系的に学ぶ
- 既に実務でDatabricksを使っているのであれば、全てを受講する必要は無いように感じた
- 時折レガシーな内容もある（Hive metastoreなど）

Databricks Data Engineer Associateの学習内容まとめ

以下、試験項目に分けて各トピックの整理になります。試験勉強に私がメモした内容から抜粋したものです。
試験範囲を全て網羅できているわけではありません。また、正確な情報は公式ドキュメントを参考にしてください。
試験前のおさらいなどにご活用ください。

Databricksの基本概念（Databricks Intelligence Platform）

データエンジニアといいつつ基本的な内容も出題される。
まずは、Databricks Fundamentals 資格の勉強をし、肩慣らしするのもいいかもしれません。この資格は基礎的な内容ですが、Delta Sahring やレイクハウスアーキテクチャなど、広く浅くカバーされていておすすめです。

レイクハウスアーキテクチャ

私がZennで以下記事を書いています。

Delta Lake

Delta Lakeは、Databricksレイクハウスのテーブルの基盤となるオープンソースのストレージフォーマットです。
Udemy｜UPDATED: V25 JULY 2025 | Complete preparation for Databricks Data Engineer Associate certification + hands-on trainingのDatabricks Intelligence Platformセクションであった、「Parquetファイルとトランザクションログを用いたトランザクションの流れ」の説明が具体的で非常にわかりやすかったです。

主な特徴:
- 実体: データ本体であるParquetファイルと、変更履歴を記録するトランザクションログ（_delta_log）で構成。
- ACIDトランザクション: トランザクションログにより、データ処理における原子性、一貫性、分離性、耐久性を保証。
- タイムトラベル: 過去の任意のバージョンにデータを遡って参照・復元することが可能。
- スキーマ適用と進化: テーブルのスキーマを強制したり、後から変更したりする柔軟なスキーマ管理。

データ取り込みとパイプライン（Development and Ingestion）

データをレイクハウスに取り込み、一連の処理を自動化するための機能です。

COPY INTO

クラウドストレージ上にあるデータを、べき等な操作でDeltaテーブルにロードするためのSQLコマンドです。

主な機能:
- べき等性: 同じコマンドを再実行しても、一度ロードされたファイルはスキップされるため、データの重複が発生しない。
- inferSchemaオプション: データ型を自動推定する
- mergeSchemaオプション: ターゲットテーブルのスキーマを変更することが可能
- 検証モード: VALIDATEオプションを使用することで、実際にデータをロードせずに、ファイルが正しくパースできるかやスキーマの互換性を検証。
Auto Loaderとの違い:
- COPY INTOはバッチ処理や都度の実行に適しているのに対し、Auto Loaderはクラウドストレージに到着するファイルを継続的かつ増分的に処理するのに適しています。

Databricks Connect

VSCode、PyCharm、Jupyterなど、使い慣れたIDEから直接Databricksクラスタに接続し、コードをインタラクティブに開発・実行できるライブラリです。ローカル環境での開発体験のまま、Databricksのコンピュートを活用できます。

データ処理と変換（Data Processing & Transformations）

Databricksにおけるデータ処理と変換の中核を担う機能です。

Delta Tableのデータ配置最適化

Databricks SQLでは、標準SQLに加えて、パフォーマンスチューニングやデータ管理のためのコマンドが提供されています。
以下のほとんどが、データスキッピングしクエリ効率化するために、いかにデータ配置を最適化するか、の機能ですが、私は、この前提をわかっておらず、はじめ各クエリの機能がごっちゃになっていました。

パーティショニング
- カラム値でparquetファイルをフォルダ分けする
- カーディナリティが高いIDなどを指定するとフォルダが大量にできて検索効率が悪くなるため、カーディナリティが程よく低いカラムを指定するとよい。
- パーティショニングのデメリット
  - データ追加時に再度パーティショニングする必要があり、すべてのデータに対して再実行され、計算量が多くなりやすい
  - このデメリットにはリキッドクラスタリングで対処できる
OPTIMIZE
- 小さな Delta ファイルをまとめて、大きな Delta ファイルにする
- ZORDER
  - OPTIMIZEと組み合わせて使用する
  - 指定したカラムでソートした上で、OPTIMIZEコマンドでファイルをまとめることができる
  - カーディナリティが高いカラムに対して有効な最適化手法
  - インクリメンタルではないため、新しいデータが取り込まれたらOPTIMIZEコマンドを再実行して、データを再編成する必要がある
  - パーティショニングとの違い
    - パーティションはフォルダ単位で整理、ZORDERはファイル単位でデータを整理する
リキッドクラスタリング
- 従来のパーティショニングとは異なり、既存のデータは無視し、追加されたデータのみを対象にデータレイアウトを最適化する機能
- クラスタリングキーは、クエリフィルターで頻繁に使用されるカラムを選択するとよい（手動）
- 自動リキッドクラスタリング
  - 過去のクエリワークロードを分析し、自動でクラスタリングキーを選択してクエリのパフォーマンスを最適化してくれる
  - 以下公式サイトの例と図を使った説明がとても参考になった
    - https://www.databricks.com/blog/announcing-automatic-liquid-clustering
VACUUM
- Deltaテーブルのトランザクションログで不要とマークされた古いデータファイルや、保持期間を過ぎたファイルを物理的に削除
- デフォルトは、過去7日以前のデータを削除
AUTO CDC
- チェンジデータフィード(CDF)から、ターゲットのDeltaテーブルにマージ（UPSERTおよびDELETE）
  - CDF：データに対する変更（＝CDC）をリストにしたものを、一般的に CDC フィード といい、変更データフィード（CDF）はDeltaテーブル独自のCDCフィードのことを指す
  - つまりAUTO CDCは、元テーブルでなく変更履歴テーブルを使ってテーブルを更新する
- データ量が多くなってきてテーブル洗い替えのコストも無視できないときに、CDCの価値が出る
  - ソースデータセット全体を読み取るのではなく、CDC フィードに対して操作するから、データをはるかに高速に処理できる
- APPLY CHANGES INTOクエリを書かずに自動でできるようにした仕組み
  - APPLY CHANGES INTOは廃止はされていないが、AUTO CDCが推奨されている
  - https://docs.databricks.com/aws/en/ldp/cdc
- SCD（Slowly Changing Dimensions）タイプ1の処理
  - CDC（変更イベント）をストリーミングで取り込み、最新状態だけを保持する Delta テーブル（SCD Type 1）を自動生成・更新する
- SCD（Slowly Changing Dimensions）タイプ2の処理
  - 最新状態に加えて、変更履歴も保持する Delta テーブル（SCD Type 2）を自動生成・更新する

Spark Structured Streaming

リアルタイムデータ（ストリーミングデータ）を無限に増え続けるテーブルのように扱える技術です。
私は使ってないですが、以下学習教材を使うのも良さそうでした。

Sparkの読み込みAPIは次の「2軸」で分かれている

軸	バッチ	ストリーミング
ファイル / ソース	`spark.read`	`spark.readStream`
テーブル	`spark.read.table()`	`spark.readStream.table()`

構造化ストリーミングのトリガー間隔
- 増分バッチ処理をしたいとき
  - .trigger(availableNow=True)
    - Spark Declarative Pipeline（SDP）のトリガーパイプラインモードのようなイメージ
    - ソースデータセットの未処理のレコードをすべて処理
    - ストリームを実行したままにすることを心配することなく、コードを安全に実行できる
    - 公式では、onceでなくavailableNowを使うことが推奨されている
      - https://docs.databricks.com/aws/ja/structured-streaming/triggers
- 時間間隔を指定したいとき
  - .trigger(processingTime='10 seconds')
- デフォルトのトリガー間隔
  - 500ms
  - ただ、Databricks公式から、カスタマイズされたトリガーを指定することが推奨されている。

新しいデータが到着したかどうかの確認や、サイズが小さいバッチの処理に関連するコストを最小限に抑えるために、常にカスタマイズされた trigger を指定することをお勧めします。
Databricks｜デフォルトのトリガー間隔はどれくらいですか?

データパイプラインの製品化（Productionizing Data Pipelines ）

Delta Live Tables (DLT)

現在は Spark Declarative Pipeline（SDP）に命名変更されていますが、2026年1月に受けた試験では、まだDelta Live Tablesとして出題されていました。

以下の私の記事で解説しています。

以下の２✕２の設定値がある。

軸	選択肢
実行モード	開発モード / プロダクションモード
実行方式	トリガーパイプラインモード / 連続パイプラインモード

開発モード or 本番モード

モード	クラスタ	リトライ	用途
開発モード (Development Mode)	残す（2時間）	しない（即エラー）	Notebookでテストする
本番モード (Production Mode)	ジョブ後に terminate	する	本番実行

開発モード = 開発者向けのテスト用モード
- 従来のノートブックエディターで作成されたパイプラインは、デフォルトで開発モード
- クラスタを頻繁に止めない。すぐ再実行できるように残す。
  - 再起動のオーバーヘッドを避けるためにクラスターを再利用します。
  - デフォルトでは、クラスタは２時間動いたまま
- エラーが起きたら即止まる。なぜなら開発中だから。
  - パイプラインの再試行は無効
本番モード = 自動で再試行したり、クラスタを再起動したりする。
- クラスタを都度破棄 → コスト最適化
- リトライあり → 一時的障害に強い

トリガーパイプラインモード or 連続パイプラインモード

トリガーパイプラインモード
- 実行時点の入力データをすべて処理して、完了したら自動で停止する。
連続パイプラインモード
- ストリーミング的な実行モデル
- データソースに到着した新しいデータを継続的に処理する
- 手動で停止するまで動き続ける
- 依存する Delta テーブルを自動的に監視し、依存テーブルの内容が変更された場合にのみ更新を実行する
- パイプライン全体のテーブルを常に最新状態に保つ

Dry run機能

テーブルの更新を待たずにパイプラインのエラーをチェックできる。
データセットを具体化・公開することはない。

Auto Loaderのスキーマ進化モード

オプションcloudFiles.schemaEvolutionModeで設定できる。

addNewColumns
- スキーマ進化モードのデフォルト設定
- ストリーム失敗
  - ジョブ履歴に「この時点でスキーマが変わった」が刻まれ、スキーマ変更に気づける
- 新しい列がスキーマに追加される
  - 次の実行では新スキーマになり、取り込み処理は成功する
- 既存の列の型が変更された場合は、データ型は進化しない
failOnNewColumns
- ストリームは失敗
- 新しい列はスキーマに追加されない
- 提供されたスキーマが更新されるか、問題のあるデータファイルが削除されない限り、ストリームは再起動されない
rescue
- ストリームは止めない
- 新しい列はスキーマに追加されず、退避カラムに記録される
- 退避カラムの設定: rescuedDataColumn
none
- スキーマの変更によってストリームは失敗しない
- 新しい列は追加されない
- rescuedDataColumnオプションが設定されていない限りデータはrescueされない

Databricks アセットバンドル

ジョブやパイプラインなどの Databricks リソースをソースファイルとして記述できる、DatabricksのCI/CDツール。

おわりに

受験して気づいたこと感じたこと
- Spark Declarative Pipeline（SDP）はまだDelta Live Tablesとして出題されていた（2026年1月）
- 模擬試験、Udemy｜Practice Exams: Databricks Certified Data Engineer Associateは、試験に近かった・合格のためになったと感じた
難しかったこと
- Udemyの学習教材や、ChatGPTなどAIの言う事がレガシーな可能性もあるため、公式ドキュメントを中心の学習が必要な点
- 最新の情報を追っても試験内容がレガシーである可能性もあること
  - 試験本番ではDLT以外はレガシーさは感じなかった

この記事が皆さんの学習の一助となれば幸いです。