Zenn
🌏

Databricks Data Engineer Associate 資格対策

に公開
資格
Databricks
delta
associate
デルタレイク
idea

Databricks認定 Data Engineer Associate資格は、Databricks Lakehouse Platform 上でのデータエンジニアリングスキルを証明する認定資格です。このブログでは、出題ドメインの概要と、各ドメインで学習すべきポイントを整理し、資格取得のための学習ガイドとしてまとめます。

  • 2025年3月時点の情報で整理しています。
  • こちらの内容で試験に合格できました（正解率：85%程度）。

資格のドメイン構成

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

  1. Databricks Lakehouse Platform
  2. ELT with Spark SQL and Python
  3. Incremental Data Processing
  4. Production Pipelines
  5. Data Governance

1.Databricks Lakehouse Platform

  • Delta Lake の基礎技術：
    • ACIDトランザクション、スキーマの管理、Time Travel などの信頼性機能を Parquet と JSON ログファイルで実現。

-- Delta テーブルの作成
CREATE TABLE my_table (id INT, name STRING) USING DELTA;

  • OPTIMIZE と ZORDER：読み取り性能向上。

OPTIMIZE my_table ZORDER BY (id);

  • VACUUM：古いデータファイルを削除し、ストレージコスト削減。

VACUUM my_table RETAIN 168 HOURS;

  • 構成アーキテクチャ：
    • コントロールプレーン（UI、ワークフロー管理）
    • データプレーン（クラスタ、データ保存）
  • Databricks Repos（バージョン管理）：
    • Gitベースの開発フローに統合可能。
    • Databricks ノートブックと Git リポジトリの統合で、再現性・CI/CD 対応を実現。
    • サポート操作：Clone, Pull, Commit, Push
    • サポート外：競合解決(マージ)、rebase、タグ操作、サブモジュール利用などは不可

#Repos 内での基本操作例
#最新のコードを取得
Git Pull
#修正をローカルから Git に反映
Git Commit & Push

  • Databricks Repos + Security のポイント：
    • Repos におけるアクセス制御はワークスペースレベルのロールに基づく。
    • 個人・グループ単位で Repo の閲覧・編集権限が付与可能。
    • Unity Catalog とは独立して管理され、ノートブックやジョブと同様にオブジェクトアクセス管理の対象。
    • Repos 上での CI/CD 構成（例えば GitHub Actions 連携）は、クラウドストレージへの直接デプロイや DLT パイプラインとの接続にも活用される。
  • Control Plane / Data Plane：
    • Control Plane：メタデータ管理、UI操作、認証処理などを Databricks 側で管理
    • Data Plane：ユーザーデータの保存・処理を行うクラウドプロバイダ側の領域（S3/ADLS/GCS）

2.ELT with Spark SQL and Python

  • ビューの活用：物理データをコピーせずに分析用ビューを作成。

CREATE OR REPLACE TEMP VIEW temp_view AS
SELECT * FROM employees;

  • DML 操作（DELETE, UPDATE, MERGE）：

DELETE FROM products WHERE price <= 1000;
UPDATE products SET price = price * 0.5 WHERE price > 1000;
MERGE INTO target USING source ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

  • ビューの種類：
    • TEMP VIEW：セッション限定
    • GLOBAL TEMP VIEW：グローバルに共有
    • 標準VIEW：カタログに永続保存
  • JDBC 経由でのデータ接続：PostgreSQL, SQLite など。

CREATE TABLE orders
USING org.apache.spark.sql.jdbc
OPTIONS (
url "jdbc:sqlite:/bookstore.db",
dbtable "orders"
);

  • 高階関数（HOF）操作：ARRAY型に対する処理。

SELECT FILTER(students, s -> s.total_courses < 3) FROM faculties;
SELECT TRANSFORM(students, s -> s.total_courses + 1) FROM faculties;

  • CREATE TABLE USING CSV：CSVファイルから直接テーブル作成。

CREATE TABLE my_table (col1 STRING, col2 STRING)
USING CSV
OPTIONS (header = "true", delimiter = ";")
LOCATION "/path/input";

  • dbutils：Databricksが提供するノートブック用の補助ツールキット
    • dbutils.widgets：パラメータの受け取り（インタラクティブなノートブック実行）
    • dbutils.fs：DBFS（Databricks File System）などのファイル操作
    • dbutils.notebook：別ノートブックの呼び出し・パラメータ渡し
    • dbutils.secrets：シークレットスコープからの機密情報読み取り
    • dbutils.library：ライブラリのインストール（クラスターレベル）（非推奨）

3.Incremental Data Processing

  • Auto Loaderを活用したデータ取り込み
    • 特徴 大量のファイルを効率的にスキャンし、新規ファイルのみをストリーミングまたはバッチ的に取り込む。
    • オプション cloudFiles.format、cloudFiles.schemaLocation、cloudFiles.useNotifications などを指定し、スケーラビリティやパフォーマンスを向上。
      • Incremental File Listing：新しいファイルのみをリスト化し、フルスキャンを回避する
      • Cloud Notifications：AWS S3, Azure ADLS のイベント通知を利用してファイルの追加を即時検出
      • Checkpointing：取り込み済みのファイル情報を保存し、重複を防ぐ
      • Schema Evolution：新しい列が追加された場合にスキーマを自動更新
      • Stream & Batch 対応：ストリーミングモード（リアルタイム処理）とバッチモード（定期処理）の両方をサポート
      • Optimize File Reads：ストレージリスト操作のコストを削減し、大量のファイルでもスケーラブル
    • コード例

      spark.readStream
      .format("cloudFiles")
      .option("cloudFiles.format", "json")
      .option("cloudFiles.schemaLocation", "/path/to/schema")
      .option("cloudFiles.useNotifications", "true")
      .load("/mnt/raw")
      .writeStream
      .option("checkpointLocation", "/mnt/checkpoints/bronze")
      .table("bronze_table")

  • Structured Streamingとトリガー設定
    • Streamingクエリの起動時に .trigger(...) を指定することで、実行モードを制御可能。
      • processingTime="2 minutes"：2分間隔のマイクロバッチ
      • availableNow=True：バッチ処理を一回走らせて即終了するモード
      • once=True：似たように単発バッチで処理し終了
    • コード例

      (spark.readStream
      .table("cleaned_data")
      .writeStream
      .trigger(processingTime="2 minutes")
      .option("checkpointLocation", "/mnt/chk")
      .outputMode("append")
      .table("silver_table"))

  • Structured Streaming でサポートされない（または制限される）主な操作
    操作・構文 サポート状況 理由・備考
    ORDER BY サポート外 無限データ全体に対する並べ替えはできない（ソート対象が終わらない）
    LIMIT サポート外 無限ストリームに対して「N 件だけ取得」は意味を成さない
    DISTINCT（一部制限あり） 状態保持のため慎重に扱う必要あり 大量のキーでメモリ使用が膨大になる可能性
    サブクエリ（スカラーサブクエリなど） 一部制限あり ストリーミング側のデータとバッチ的に比較する場合は制限されることがある
    JOIN（ストリーミング同士） 制限あり ストリーミング vs ストリーミング JOIN にはウォーターマークと時間制限が必須
    UNION 可だが、スキーマが完全一致している必要あり --
    GROUP BY + HAVING ウィンドウ付きなら可 状態を保持しながら集計可能。無限グループに注意
    WINDOW 関数（OVER句） サポート外 通常のウィンドウ関数はサポートされない（window() 集計は可能）
    PIVOT / CUBE / ROLLUP サポート外 全件を把握する必要があるため
    JOIN + 外部クエリ（非ストリーム） （Broadcast JOINなど） ストリーム × 静的テーブル は OK（よく使われるパターン）
    DROP / ALTER TABLE ランタイム中は使用不可 ストリーム処理中にテーブル定義を変更できない
  • Delta Live Tables（DLT）
    • 宣言的パイプラインにより、データフロー・依存関係を自動管理。
    • メダリオンアーキテクチャ（Bronze・Silver・Gold）の実装に最適。
    • 例 テーブル依存関係とCDC処理:

      CREATE STREAMING LIVE TABLE silver_orders
      AS
      SELECT order_id, total + tax AS total_after_tax
      FROM STREAM(LIVE.bronze_orders);

      APPLY CHANGES INTO LIVE.gold_aggregated_orders
      FROM STREAM(LIVE.silver_orders)
      KEYS (order_id)
      SEQUENCE BY timestamp
      COLUMNS *

  • データ品質管理（Expectations）
    • DLTの EXPECT句により、無効なデータを検出・除外・失敗扱いなど柔軟に制御。
    • EXPECT のみ：違反データを除外せずに保持しつつ、メトリクスやイベントログに "failed" として記録される（これがデフォルト）
    • ON VIOLATION DROP ROW：制約違反の行を**ターゲットテーブルから除外（ドロップ）**する
    • ON VIOLATION FAIL UPDATE：パイプライン全体を失敗させる（厳格モード）
    • コード例

      CREATE LIVE TABLE validated_data
      CONSTRAINT valid_id EXPECT (id IS NOT NULL) ON VIOLATION DROP ROW
      AS
      SELECT * FROM raw_data;

    • 上記で id が NULL の行は除外され、イベントログで違反件数を確認できる。
  • マルチホップ・メダリオンアーキテクチャ
    • Bronze：生データをAppend-Onlyで格納（例：ログ、IoTなど）
    • Silver：結合・重複排除・クレンジング後の整形データ
    • Gold：BIやML用の集約済みデータ、KPIなど
    • データレイヤを段階的に分けることで品質管理・メンテナンス性を高める。

4. Production Pipelines

  • Databricks Jobs
    • マルチタスクジョブのDAG化：ワークフローをビジュアルに定義し、複数ノートブックやJAR、Pythonスクリプトを連携。
    • 依存関係設定：Depends onでタスク間の実行順序を制御。
    • 通知設定 ジョブページの “Edit notifications” から、成功／失敗時のメール送信先を指定。
  • クラスタータイプ
    • All-Purpose Cluster：ノートブック実行や対話的分析向け。起動中は常に課金。
    • Job Cluster：ジョブ実行時のみ立ち上がり、自動終了。コスト効率が良く、本番運用で推奨。
    • SQL ウェアハウス：Databricks SQL 用のクラスター。BIツールやSQLダッシュボードでの利用に最適。
    • Cluster Pools：事前にVMをプールし、起動時間を短縮。
  • ジョブスケジューリング（Cron表記）
    • 時間ベースの定期実行を設定可能。
    • 例：毎朝6時に起動 → 0 6 * * *
  • ジョブのリカバリ機能（Repair Job）
    • 複数タスクのワークフローにおいて、一部のみ失敗した場合、失敗タスクだけを再実行できる。
    • ロングランのジョブが多い本番環境では時短に繋がる重要機能。
  • DLTパイプライン（Triggered / Continuous）
    • Triggered モード：1度テーブル更新したら停止。日次などのバッチ処理に向いている。
    • Continuous モード：常時実行し、新着データをリアルタイム処理。Auto LoaderやKafkaと連動して低レイテンシ分析に活用。
  • ジョブ間の依存関係の主な種類（4パターン）
    • 線形依存関係（Linear）
      • ジョブ A → ジョブ B → ジョブ C のように、1本の直線的な流れで順番に実行される。
      • A → B → C
    • ブランチ依存関係（Branching）
      • ジョブ A の後に、ジョブ B・C が並列に実行される。
      • A → {B, C}
    • 集約依存関係（Join）
      • 複数のジョブ（B, C）が完了したら、ジョブ D を実行
      • {B, C} → D
    • DAG（有向非巡回グラフ）依存関係
      • 複数のパターンが混在する複雑なグラフ型依存
      • A → B → D, A → C → D など
  • SQL Alerts / Dashboards
    • Databricks SQLでクエリ結果が一定閾値を超えた場合に通知する機能。
    • SlackやWebhookなどの外部サービスと連携し、問題発生をいち早く検知。

5. Data Governance

  • Data Explorer
    • Databricks SQLのUIで、テーブル・ビューのメタデータと権限を管理する画面。
    • テーブルやDB（スキーマ）の所有者変更や GRANT/REVOKE の実行が簡単に行える。
  • 主要な権限
    • SELECT：読み取り操作
    • MODIFY：データ挿入／更新／削除（INSERT, UPDATE, DELETE, MERGE など）
    • USAGE：スキーマ・カタログにアクセスする基本権限（他の権限と組み合わせて使う）
    • ALL PRIVILEGES：全権限（SELECT, MODIFY, CREATE, USAGE, READ_METADATA など）を一括付与

    GRANT SELECT ON TABLE employees TO hr_team;
    REVOKE MODIFY ON TABLE employees FROM ex_hr_member;

  • 所有権（OWNERSHIP）
    • テーブル・ビューなどのオブジェクトごとにOwnerが設定される。
    • Data Explorer からUI操作、または ALTER TABLE ... OWNER TO ... で変更可能。
  • Unity Catalog
    • 複数ワークスペースを統合的にガバナンスする仕組み（上位資格でより詳しく問われる可能性あり）。
    • カタログ／スキーマ／テーブル／ビューに対する統一的なアクセス制御、行レベルセキュリティや列マスキングなどもサポート。
  • ダイナミックビュー（Dynamic View）：SQLの VIEW をベースに、アクセスユーザーの属性に応じて表示するデータを動的に制御できるビュー。

    少し実用的な例：ロールベース制御（is_member）
    CREATE OR REPLACE VIEW sales_view AS
    SELECT *
    FROM sales
    WHERE
    (dept_id = 'HR' AND is_member('hr_team')) OR
    (dept_id = 'IT' AND is_member('it_team'));

  • メダリオンアーキテクチャとガバナンス
    • Bronze/Silver/Goldレイヤに対して、それぞれのレイヤで必要な権限を絞り込む運用を推奨（例：BronzeはETL担当のみ書き込み可、GoldはBIユーザー向け読み取りのみなど）。
    • Data Explorerでオブジェクトごとの権限を整理し、アクセス管理を徹底する。

Discussion