DEA 直前仕上げ — 方式選定・出題範囲対応表・数値総まとめ・引っかけの型

16.1取り込み方式の選定フロー — 件数・頻度・再アップロードから方式を決める

取り込みの設計で最初に迷うのは「どの仕組みで運ぶか」です。いきなり Structured Streaming を自分で書くと、認証・リトライ・スキーマ進化・API のレート制限まで全部を自前で面倒みることになります。ドキュメントが示す進め方は逆で、最もマネージドな層から始め、その層が要件を満たさないときだけ下の層へ降りるというものです。試験ではこの順序そのものが問われます。

4 つの層を「何が自動化されるか」で並べる

マネージドコネクタが作る宛先はストリーミングテーブル、つまり増分処理に対応した Delta テーブルです。外部表でも一時ビューでもありません。SaaS ソースの構成は「接続 + 取り込みパイプライン + 宛先ストリーミングテーブル」の 3 要素で、データベースの CDC ではここに取り込みゲートウェイとステージング用の Unity Catalog ボリュームが加わります。ゲートウェイはソース側の変更ログが切り詰められる前に変更を捕まえる必要があるため継続的に稼働し、取り込みパイプラインがアイドルでも課金が発生します。列の増減は既定で自動的に扱われ、ソースで消えた列は宛先から物理削除されずに非アクティブになります。

COPY INTO と Auto Loader は「頻度」と「件数」で割れる

再アップロードされたファイルの扱いが分岐点になる

• COPY INTO はファイル名で照合します。中身が書き換わっても取り込み済みならスキップされ、再ロードするには COPY_OPTIONS ('force' = 'true') を明示します。既定は false です。
• Auto Loader は cloudFiles.allowOverwrites が既定 false で、上書きされたファイルを再処理しません。
• 重複排除の追跡期間は cloudFiles.maxFileAge です。短くしすぎると追跡から外れた古いファイルが新規として再検出され、かえって重複取り込みになります。
• まだ届いていないファイルだけを処理したいなら cloudFiles.includeExistingFiles を false にします。既定は true で、開始時点の既存ファイルも対象です。
• 処理済みファイルを片付けるには cloudFiles.cleanSource に MOVE を指定し、退避先を cleanSource.moveDestination で与えます。移動元と移動先は同じバケットまたはコンテナ内に限られます。既定は OFF です。

ファイル検出モードは規模で切り替える

ディレクトリリスティングは既定のモードで、LIST API を毎回叩くためファイル数に比例して検出コストとレイテンシが増えます。ファイル通知モードはクラウドのオブジェクト作成イベントを購読するため、数百万ファイルでもコストがほぼ一定です。ただしクラウド側はイベントの 100% 配信を保証しないので、欠損が許されない要件では cloudFiles.backfillInterval を設定して定期バックフィルを併用します。検出モードはストリームの再起動をまたいで切り替えられ、その際も exactly-once は維持されます。読み取り元の外部ロケーションには READ FILES 権限が必要で、Unity Catalog の外部ロケーションでファイルイベントを有効にしておくと、ストリーム設定時に追加の権限付与が不要になります。

4 つの質問で方式が決まる

1. ソースは SaaS か、変更ログを持つデータベースか。該当すればマネージドコネクタで終わりです。
2. ファイルがオブジェクトストレージに並ぶか。並ぶなら Auto Loader、SQL だけで完結させたいなら COPY INTO です。
3. 到着は連続か、1 日数回か。数回なら trigger(availableNow=True) をジョブのスケジュールから起動するのが最も安く済みます。連続で低レイテンシが要るなら既定のマイクロバッチトリガーのまま常時稼働させます。いつ来るか分からないファイルを待つなら、ジョブ側の File arrival トリガーを使います。検知は 1 分ごとのベストエフォートです。
4. ファイル数は数百万を超えるか。超えるならディレクトリリスティングではなくファイル通知モードを選びます。

この 4 つは必ず上から順に当てます。件数から入ると Salesforce のような SaaS ソースにまで Auto Loader を当ててしまい、レイテンシから入ると常時稼働のストリームばかり増えます。設問も「ソースは何か」「どれくらいの規模か」の順で情報を出してくるので、読む順番と判断の順番を揃えると迷いが減ります。

16.2DEA 出題範囲対応表 — 章 × 公式セクション × 演習問題 ID のトレーサビリティ

直前期にやるべきことは、新しい知識を足すことではありません。自分が落とした問題を、公式セクションのどこに属するかで束ねることです。演習カテゴリ ID は公式セクション名を英小文字のスラッグにしたもので、模試の結果画面に出る ID を控えれば読み直すべき章が絞れます。

公式セクションと本書の章の対応

セクションごとに「取りこぼしやすい形」が違う

• Data Ingestion and Loading は既定値の暗記が中心です。maxFilesPerTrigger や FORMAT_OPTIONS と COPY_OPTIONS の区別など、覚えていれば取れる問題の比率が最も高い領域です。
• Working with Lakeflow Jobs は状態遷移と上限値です。Run if 未達時の状態、Run Job タスクの入れ子の深さ、SQL タスクが要求するウェアハウス種別が狙われます。
• Troubleshooting, Monitoring, and Optimization は数値と「どちらが先か」です。VACUUM とタイムトラベルの関係、Liquid Clustering とパーティショニングの排他関係が定番です。
• Governance and Security は SQL 構文そのものです。付与と解除で書き方が違う点、Unity Catalog では使えない構文がある点が狙われます。
• Implementing CI/CD は「バンドルは便利だ」で済む設問ばかりではありません。既存クラスタ ID を lookup: で解決する、構造化した値に type: complex を使う、mode: production が何を検証するか、変数値の解決順序はどれか、といった知識問題が並びます。
• Data Transformation and Modeling はコードを読ませる問題が混ざります。when の評価順に加え、outputMode の制約や MERGE INTO の失敗条件など、実行結果を頭の中で追う練習が要ります。
• Databricks Intelligence Platform はコンピュートの選び分けに加え、Databricks Connect、init script の保存先、プールとオートスケールの関係まで広がります。

何が問われているのかを 4 分類で見る

本書が分析した DEA の実問題 850 問を「何を答えさせているか」で分類すると、次のようになりました。

操作・構文と設定値の暗記だけで 50.9% を占めます。直前期の投資先は、次の第 3 節にまとめた数値と構文です。概念問題は落としにくく伸びしろも小さいので後回しで構いません。

復習の順番と、この表の限界

1. 演習アプリでカテゴリ別に解き、正答率が最も低いカテゴリを 2 つ選びます。
2. そのカテゴリを上の表で公式セクションに変換し、対応する章へ戻ります。
3. 章の数値と既定値だけを読み直し、第 3 節の表と突き合わせます。表にない数値が章にあれば、そこが自分の穴です。
4. 同じカテゴリを解き直し、間違いが「知識不足」か「引っかけ」かを仕分けます。後者なら第 4 節です。

ただし 1 つの設問が複数のセクションにまたがることがあります。「Auto Loader を実行するユーザーに必要な権限」は取り込みに見えて、答えは外部ロケーションへの READ FILES というガバナンスの知識です。カテゴリ ID は入口にすぎません。なお受験料や申込方法といった受験情報は本書では扱わず、演習アプリ側の解説記事と無料問題集に置いています。

16.3数値・既定値・構文の総まとめ（直前チェック）

この節は暗記用です。前日に上から指でなぞってください。2 周目は右の欄を隠し、値だけで症状を言えるか試します。数値そのものより、数値と症状の結びつきが問われます。

Auto Loader の既定値

スキーマ推論のサンプリングは最初に検出した 50 GB または 1000 ファイルのうち先に達した方までです。schemaEvolutionMode は addNewColumns / addNewColumnsWithTypeWidening / rescue / failOnNewColumns / none の 5 種類で、古い教材は先頭を除く 4 種類としています。int から long のような型の拡張まで許すのは 2 番目だけです。既定の addNewColumns は新列で UnknownFieldException を投げて止まり、再起動すると続きから取り込みます。スキーマに合わない値は rescuedDataColumn(既定名 _rescued_data)へ JSON で退避されます。cloudFiles.schemaLocation は推論を使うなら必須です。

COPY INTO の構文と上限

COPY INTO target_table
FROM ( SELECT CAST(c1 AS DECIMAL(10,2)), c2 FROM 's3://bucket/path' )
FILEFORMAT = CSV
FORMAT_OPTIONS ('header' = 'true', 'multiLine' = 'true')
COPY_OPTIONS ('mergeSchema' = 'true')

• FORMAT_OPTIONS はリーダーへ渡す引数で、header や multiLine はこちらです。
• COPY_OPTIONS が持つのは force と mergeSchema の 2 つだけで、どちらも既定は false です。
• FILES 句は最大 1000 ファイルまで列挙でき、PATTERN とは同時に指定できません。
• VALIDATE ALL や VALIDATE 20 ROWS は書き込まずに検証し、プレビューは 50 行以下です。
• BY POSITION は列を序数位置で対応付けます。ヘッダー行のない CSV 専用です。
• ターゲット表は自動作成されません。

Delta のメンテナンスと履歴

版の下限は出題時期で揺れます。現行ドキュメントは一般提供を 15.4 LTS 以上としますが、プレビュー時代の 13.3 LTS 以上を正解とする設問も残っています。

RESTORE TABLE sales TO VERSION AS OF 5;
SELECT * FROM sales TIMESTAMP AS OF '2026-01-01T00:00:00';
ALTER TABLE sales CLUSTER BY (region, order_date);
CONVERT TO DELTA parquet.`/mnt/raw/sales`;

Change Data Feed はテーブル側で delta.enableChangeDataFeed = true、読み取り側で readChangeFeed と startingVersion を指定します。記録は有効化したあとの書き込みからで、遡れません。付与される列は _change_type / _commit_version / _commit_timestamp の 3 つで、SQL では table_changes('sales', 5) を使います。

変換とストリーミングの必修事項

complete は毎バッチ全集約を書き出すためファイルシンクでは使えず、update はバッチ writer には存在しません。

Lakeflow Jobs の上限と既定

Run if は 6 種類です。All succeeded(既定)/ At least one succeeded / None failed / All done / At least one failed / All failed。狙われるのは条件が満たされなかったときの状態です。上の並びで成功系の 3 つが未達なら Upstream failed、失敗系の 2 つが未達なら Excluded になります。All done は上流の結果によらず必ず実行されます。

dbutils.jobs.taskValues.set(key="record_count", value=1500)
# 下流タスクのパラメータ欄: {{tasks.count_rows.values.record_count}}
# For each のネストタスク内では {{input}} / {{input.region}}

If/else 条件タスクでは == と != が文字列比較なので 12.0 == 12 は false ですが、>= などは数値比較なので 12.0 >= 12 は true です。必須フィールドは left / op / right の 3 つです。

CI/CD — databricks.yml と CLI

ガバナンスとコンピュート

16.4引っかけの型 — 捏造オプション名の見分け方と複数選択問題の攻略

知識はあるのに 4 択で外す状態には原因があります。誤答の選択肢は数種類の型を使い回して作られており、型を覚えれば知識があいまいでも選択肢を 2 つまで絞れます。

型 1: 存在しないオプション名

最も多い型です。もっともらしい英単語を組み合わせた、実在しない名前が並びます。知らない名前は「まだ習っていない機能」ではなく「捏造」を先に疑ってください。Auto Loader のオプションは必ず cloudFiles. で始まりますが、プレフィックスが正しいことは実在を意味しません。cloudFiles.onViolation は存在せず、ON VIOLATION は Expectations 側のキーワードです。

型 2: 「存在しない」と「存在するが対象外」の混同

型 1 の裏返しで、実在する機能を「そんな構文はない」と切る失点です。DENY は Databricks SQL に実在しますが、Unity Catalog では非対応で hive_metastore 配下にのみ適用されます。捏造だと決めつけると、正解が「Unity Catalog では未サポート」だったときに落とします。切るときは「無い」のか「あるが対象外」なのかを言葉にします。

型 3: 名前空間の取り違え

実在する 2 つの入れ物のうち、間違った方に正しいオプションを入れて見せる型です。名前は正しいので、うろ覚えだと引っかかります。

• header / multiLine / ignoreCorruptFiles は FORMAT_OPTIONS。COPY_OPTIONS に入れると誤りです。
• CDF はテーブル側が delta.enableChangeDataFeed、読み取り側が readChangeFeed です。
• 行フィルタの解除は列を指定しません。列を指定するのは ALTER COLUMN ... DROP MASK の側です。
• Photon の有効化は spark_version を -photon 付きにするか runtime_engine を指定します。Spark conf のキーで切り替える方法はありません。

型 4: 役割の入れ替え

2 つの機能の説明文を丸ごと交換してある型です。ペアで覚えているものほど弱いので、どちらがどちらかを一言で言えるようにしておきます。

• trigger(once=True) は単一マイクロバッチで停止、trigger(availableNow=True) は複数マイクロバッチに分割して全消化してから停止。後者が後継です。
• マテリアライズドビューは再計算、ストリーミングテーブルは増分追記。
• ディレクトリリスティングは LIST 駆動、ファイル通知はイベント駆動。
• ローカル SSD は高速で揮発、EBS やマネージドディスクは低速で永続。
• 取り込みゲートウェイはソース DB から変更を抽出する側、取り込みパイプラインは宛先へ適用する側です。

型 5: 数値のすり替えと極端な限定語

正しい数値の周辺に、それらしい別の数値を置く型です。24 時間・168 時間・30 日、100・1,000・2,000 のように、同じ単位で別の正解になり得る数値が混ざります。ここは推理が効かないので、第 3 節の表を数字だけ縦読みして覚えてください。とくに VACUUM の 168 時間と logRetentionDuration の 30 日は取り違えを誘われます。あわせて「常に」「必ず」「一切」「唯一」が入った記述は疑ってかかります。ただし例外もあります。「For each タスクを入れ子にすることはできない」のように、仕様として本当に例外がない文はそのまま正解になります。限定語は「疑うためのフラグ」であって「消すためのフラグ」ではありません。

複数選択問題の攻略

「2 つ選んでください」の問題は、正解が1 本の軸の両端になっていることが多いという性質があります。Auto Loader のスキーマ進化なら「新しい列を取り込む設定」と「型が合わない値を救う設定」で 1 組です。

1. まず互いに矛盾する 2 つ (排他ペア) を探し、両方が正解になり得ないことを使って片方を落とします。
2. 残りのうち、機能のカテゴリが明らかに違うもの (性能の話に混ざったガバナンスの話など) を落とします。
3. 最後に残った 2 つが「別々の軸をカバーしているか」を確認します。同じことを言い換えただけの 2 つは、たいてい片方が誤りです。

排他関係を知っていると一気に絞れる論点があります。Liquid Clustering とパーティショニングは同一テーブルで併用できません。For each タスクは入れ子にできず、Run Job タスクは 3 段を超えて入れ子にできません。行フィルタはテーブル属性であって権限ではないため、REVOKE ROW FILTER のような構文は存在しません。「両方できます」と書かれた選択肢は、排他関係の知識で落とせることが多いのが DEA の特徴です。

決められないときはより狭く具体的な記述を選びます。「Photon は SQL と DataFrame の演算を高速化する」と「Photon はすべてのワークロードを高速化する」なら前者が正解です。Python UDF のように JVM と Python をまたぐ処理では効果が限定的だからです。反転設問にも注意します。「誤っているものを選んでください」では正しい説明が 3 つ並ぶので、設問文の末尾を読んでから選択肢に入る順番を固定します。

時間配分

DEA は 45 問を 90 分で解くため、1 問あたりの平均は 2 分です。5 つの型は数秒で判定できます。捏造名を消し、名前空間を確かめ、極端な限定語を疑うところまでを機械的に済ませ、残った選択肢だけに時間を使います。1 分で決まらない問題は印を付けて先へ進みます。全問を一巡してから戻るほうが確実に点が伸びます。復習では解説の後半まで読みます。捏造オプションは「そのようなオプションは存在しない」と一言だけ書かれることが多く、そこを飛ばすと次も引っかかります。