はじめに
最近業務でDatabricksを触る機会がありまして、せっかくなら体系的に学ぼうということでDatabricks Certified Data Engineer Associateを目指して勉強 & 受講してきました。
私は普段Snowflakeをメインで触っています。
SnowPro CoreやAdvanced(Architect)も取ってきたので、資格試験の戦い方はある程度わかっているつもりでした。
ただ、Databricksは文化が違う。Snowflakeとは思想もエコシステムも違うので、同じノリで挑むと痛い目を見そうだなと。
そこで今回は 「Snowflake脳からの翻訳」 と 「AI学習ツールのフル活用」 という2軸で勉強してみた話をまとめてみました。
試験の概要
- Databricks Certified Data Engineer Associate
- 45問 / 90分
- テストセンター受験(Kryterion)
SnowProと比べると問題数が少ないです。
SnowPro Coreは100問/115分、Advancedは65問/115分だったので、45問はだいぶコンパクトに感じます。
ただ、1問あたりの持ち時間で見ると実はDatabricks Associateが一番余裕があります。
| 試験 | 問題数 | 時間 | 1問あたり |
|---|---|---|---|
| SnowPro Core | 100問 | 115分 | 約1.2分 |
| SnowPro Advanced | 65問 | 115分 | 約1.8分 |
| Databricks Associate | 45問 | 90分 | 2.0分 |
| Databricks Professional | 59問 | 90分 | 約1.5分 |
学習戦略
全体のアプローチ
SnowProの時と同じく「模擬試験 → 公式ドキュメント → 繰り返し」が基本です。
ただ今回は既存知識とAIフル活用で取り組みました。
戦略を整理するとこんな感じです。
- Snowflakeからの「翻訳」思考: 知っている概念をDatabricksではどう表現するか
- Databricksの「気持ち」になる: この製品は何を推しているのか、思想を理解する
- データエンジニアリング一般知識の昇華: 「そういうもん」という感覚で行けるレベルにする
- AI学習ツールで効率化: NotebookLM、プロンプトエンジニアリングをフル活用
特に2番、「Databricksの気持ちになる」はSnowProの時にも使った考え方です。
Snowflakeの試験では「Snowflakeが言いそうなこと」を推測する力が効きましたが、同じことがDatabricksでも通用しました。
製品が推している機能、アピールしたいポイント、つまり「Databricksならこうする」みたいなことを理解しておくと、選択肢を絞る時に役立ちます。
3番も地味に大きかったです。Snowflakeとは関係なく、データエンジニアリングの一般知識として「そうするよね」と自然に判断できるレベルになっていると、初見の問題でもある程度戦えます。
SQLなんかは共通言語なので、方言が来たとしても「自然な流れ」「自然な書き方」は察しが効きます。
使ったもの
| リソース | 用途 | 備考 |
|---|---|---|
| 公式シラバス | 試験範囲の把握 | 無料。まずはここから |
| 公式ドキュメント | 知識の深掘り | 概要部分を重点的に。こいつをいきなり見るとめげるので、模擬試験→ドキュメントの順で参照。 |
| Udemy模擬試験 | 実践的な問題演習 | 日本語版 Databricks Data Engineer Associate オリジナル問題集 |
| 先人の知恵 | 知恵を借りる |
Databricks認定データエンジニアアソシエイト公式練習問題を翻訳&解説してみた Databricks認定データエンジニアアソシエイト公式練習問題 翻訳&解説 質問31以降 |
| NotebookLM | 音声ガイド・スライド資料生成、資料分析 | 今回の最大の武器 |
| AI(Gemini等) | Snowflake ↔ Databricks翻訳、不明点の深掘り | プロンプトを工夫して使い倒した |
AI活用ムーブ
ここが今回の一番のポイントかもしれません。私のAI活用は大きく4つのムーブがありました。
ムーブ1: NotebookLMに全部食わせて分析
公式シラバスとUdemy模擬試験等の情報をNotebookLMに投入して、徹底分析させました。
- 出題傾向の整理
- 重要トピックの抽出・優先度付け
- 理解が曖昧な部分の洗い出し
- トピック間の関連性の可視化
人力でやると数日かかりそうな作業が一気に片付きます。
前提として、Snowflakeの知識レベル、業務利用状況等バックグラウンドの情報を与えた上で、今の私がDatabricksの理解を深めるために「この範囲のうち、どこに集中すべきか」の優先順位付・重み付ができ、やることの判断が早くなったのは大きかったです。
ムーブ2: スライド資料と音声ガイドで多角的にインプット
NotebookLMで生成したスライド資料で可視化して全体像を掴みつつ、音声ガイドを家事しながらひたすら聞きました。
テキストを目で追う勉強と違って、聴覚からの情報は「体験」として記憶に残るんですよね。
試験中に「あ、あの音声で言ってたやつだ!」と思い出せる場面が複数ありました。
トーク形式の音声だと、話の流れの中で記憶が紐づくので、想起しやすい印象です。
聴覚記憶、侮れないです。
ムーブ3: ハルシネーションチェック
AI生成コンテンツをそのまま信用するわけにはいかないので、気になった点は公式ドキュメントで裏取りしました。
結果、大体あっていました。思ったよりすごい(小並感)。
が、一部古い情報やカバーされていない要素もありました。
例えばLiquid Clusteringが全然出てこなかったり。
「Databricks Repos」じゃなくて今は「Git folders」だったり。
これはUdemy模擬試験等のソースが古かった影響かもしれませんが。
DLTも「LakeFlow Spark宣言型パイプライン (SDP) 」になった模様ですが、現段階では「dlt」のままの知識で特に支障なかったです。(今後は要注意かなと)
AIを使い倒すのは大賛成ですが、最後の裏取りは人間の責任になる部分ですね。
ここをサボると「AIに教わった嘘」をそのまま試験に持ち込むことになるので注意。
ムーブ4: Snowflake vs Databricks 翻訳プロンプト
「この概念、Snowflakeで言うと何?」「Snowflakeの〇〇に相当するDatabricksの機能は?」をAIに聞きまくりました。
その逆も然り。これってSnowflakeに近しい物あったかな、ちょっと違うかな、とか。
- 権限モデル: Snowflakeの
GRANT USAGE→ DatabricksのGRANT USE - 階層構造: Database.Schema.Table → Catalog.Schema.Table
- データ共有: Secure Data Sharing → Delta Sharing
- パイプライン: dbt的なWHERE句でのnull除外 → DLT ExpectationsのCONSTRAINT句
- コンピュート: 仮想ウェアハウス → Databricksの各種クラスター(用途別)
既知の知識体系にマッピングすることで、ゼロから覚えるよりも理解が格段に早くなります。「あ、Snowflakeで言うところのアレね」となれば、あとは差分だけ覚えればいい。
おまけ: 受講後のフォローアップ
受講後、帰宅途中にカフェに入って記憶が新しいうちに自分の受験メモ(脳内ダンプ)を書きまくりました。それを勉強過程で使っていたAIのチャットスレッドに再投入して「仮に受験前にこの情報があったら、どうギャップを埋められていたか」の検証もやりました。
これは知識強化も兼ねた実験的なムーブです。
受験直後に覚えている限り書き殴った雑な生々しいメモを、「過去の自分にフィードバックする」みたいな使い方ですね。
受験前の自分に戻った設定で、その情報を得て学習・試験対策していたらどうなっていたか、という水平世界の検証です。
これは次に別の資格を取る時にも使えるアプローチだと思います。
シンプルに「おさらい」としても理解が深まりますし、出題傾向等出題者の気持ちやメタ読みの強化にも生きてくると思います。
試験本番の話
テストセンター(Kryterion)
SnowProはピアソンVUEですが、DatabricksはKryterionでした。文化の違いを感じます。
もしかしたらセンターや場所によるのかもしれませんが...
-
紙とボールペンが支給された
- ピアソンではホワイトボードとマーカーでした。マーカーが乾きやすいという罠もある
- 紙とボールペンは圧倒的に書きやすい。紙3枚もらえました。バインダー(学校の先生が持ってそうな、紙をパチンと止めるやつ)付き
- 思い出すため図式を描く等、バリバリ書き殴りました
- 小規模センターだと回線が細いのか、試験中に画面が止まることがある
- 「アクセス集中でしばらくお待ちください」的な画面に切り替わってびっくりした
- 最初は「何かやらかしたか?操作ミスったか?」と焦ったが、待てば復帰するので待つ
- 他のセンターでは見たことなかったので、センター選びも地味に重要か
時間配分
45問、90分なので1問あたり2分。2分が長いのか短いのか...長い方といえばそうかな。
- 1周目: サクサク進める。SQLを読んで考える問題は時間かかるのでスパッと飛ばして2周目に回す。例外なく。余計な時間を使ってられない試験での割り切り最強ムーブです
- 2周目: フラグをつけた問題(未着手12問くらい、自信ないものが15問くらい)を丁寧に解く。改めて冷静に見ると「ああ〜あれか」と直ぐわかるものもありました
- 3周目: 流し見。中盤までやってタイムオーバーでしたが、十分です
出題の傾向
模擬試験より明らかに難しいと感じました。
Udemyの模擬試験のチョイスがよくなかった可能性があります。
Databricks Certified Data Engineer Associate Practice Examsがいいのかもしれない。
先人の知恵(ブログ)にあった、公式模試解説ブログが有益な情報だった感じです。
出題形式の特徴
| 特徴 | 詳細 |
|---|---|
| シナリオベース | 「こういう状況で、どうする?」系が多い。暗記だけで解ける問題が少なめ〜半分以下な印象。 |
| 長文選択肢 | フルSQLが書かれた選択肢から正しいものを選ぶ。1選択肢に複数SQLも。 |
| 総合知が必要 | 問題数が少ない分、基礎をベースにした応用力が問われる。 |
| 似た問題が複数 | 同じ状況で微妙に違うケースの問いかけ。「さっきこれ出たな、あ、ちょっと違う」 |
| 細かい閾値は少ない | これはSnowPro Coreでよくある問題。あっても1-2問レベル。数値暗記はほぼ不要だった。まあでも問われるっちゃ問われる。 |
よく出たトピック(推定問題数)
| カテゴリ | ポイント |
|---|---|
| DLT | Expectations構文、ストリーミングテーブル |
| クラスター選択 | All-Purpose・Jobs・Serverless・Pro |
| Auto Loader | スキーマ進化オプション、ファイルフィルタリング |
| Unity Catalog |
GRANT USE、3層権限モデル、最小権限の原則 |
| メダリオン | 各層の意味 |
| Delta Sharing | オープンプロトコル、組織間共有、追加構成要否 |
| パフォーマンス | CPU時間・タスク時間、Spark UI、ヒープメモリエラー、Liquid Clustering |
やっぱパイプライン周りがメインですかね。
DLT、オートローダーが多い。
SQL、spark記述、両方押さえておかないとです。
import dltから始まるコードとか、CREATE OR REFRESH STREAMING TABLEとか、DLTの構文をしっかり理解しておくのは必須。
複数選択・否定形について
- 複数選択は少なかった(2問くらい)
- 「正しくないものを選べ」はほぼなかった
- 「全て正しい記述を1つ選べ」形式がある。これはSnowPro Advancedでも見かけたやつ
Snowflake脳で「メタ読み」した話
Snowflakeの試験対策で身につけた「メタ読み」が、Databricksでも効きました。いくつか紹介します。
製品が推している機能は「万能」寄り
Databricksが推している機能は、大抵なんでもできる方向で設計されています。
- DLT: バッチもストリーミングもいける
- Auto Loader: バッチもストリーミングもいける
- Delta Sharing: オープンプロトコルで制約少ない
なので、「DLTでは〜はできるが、〜ができない」みたいな選択肢は疑ってかかりました。DLTは素晴らしいんだよ!というDatabricksのアピールと出題者の意図を汲み取ってポジティブな選択肢を選ぶ、みたいなムーブです。
極論・強い否定は疑う
「〜のみ」「〜はできない」「〜だけで」みたいな強い限定表現は、大抵間違いです。
これはSnowProでも同じでしたね。
ただし、似た機能を比較する問題においてはその限りではないので要注意。
明らかに非効率な選択肢は除外
- 「CSVにエクスポートしてDLTで読み取る」→ Databricksの旨みがない。論外
- 「手動で〜」→ 自動化機能があるはず
- 「VPNでネットワーク高速化」→ VPNの目的は高速化じゃない
こういう「それっぽくない」選択肢をメタ読みで除外できると、実質2択くらいまで絞れることが多いです。
方言・文化の違い
これはSnowflake経験者だからこそ(良くも悪くも)ハマる + 逆転発想的に利用できるポイントです。
仮に準備不足でよく知らない、こんなんあったっけ?となった場合に、冷静になって考えてみる。
- (回答選択肢を眺めて) Databricksではこうするのか
- 問題文を見て「何をしたくてこうしているか」を観察
- Snowflakeではこうだよな
- 今はDatabricksの気持ちになって、基本的な思想、やり方はこうだな
- あ!あのことか!...みたいな知識・記憶降臨へと繋げる
試験問題を見直す2週目がこのチャンス。
体感、3-4割くらいこのメタ読み・ひらめきで、試験対策知識との結びつけを降臨させました。
Snowflakeではdbtでパイプライン組む時こう書いた..
一方、ここはDatabricksの世界。だから書き方、書く場所が違うんだわ...
「同じように書ける・動作するけど思想が違う」
「それを実現するネイティブな機能がある」
「手続きで解決する VS 宣言で解決する」
みたいな。ここも「音声」が脳内再生されて、知識と問いが紐づいたりしました。
Unity Catalogの権限はSnowflakeと同じ知識で解ける
db.schema.tableの3層モデルは、Snowflakeと本質的に同じです。
カタログ→スキーマ→テーブルの各階層にUSE(USAGE)権限を付与して、末端にSELECTやCREATEを付与する。最小権限の原則。
スキーマに無駄にCREATEつけている選択肢とかは「そりゃねえだろ」と迷わず落とせました。
クエリ問題は読めばわかる
こういうテーブルがあって、こんな結果が欲しい。
さてどのようなクエリを書けば良いか?という問題が複数出た。
回答選択肢には、SQLで書いたり、Sparkで書いたり、その選択肢が入り混じっていたり。
Sparkに慣れていなくても、メソッドチェインの流れ、SQLの順番とかわかれば、常識的に回答できそうです。
幸い、業務でSnowparkを書いていたので雰囲気でわかりました。
というか考え方は同じです。
Gold層 = 読み取り最適化
これは現場の肌感で解けた問題です。
実態として、Staging(Silver)層をそのまま横流しにするMartもあるっちゃありますが、BI向けなら非正規化もありですよね。
BIの見せ方次第であえて冗長にするところもあるし、BI向けにピボット・アンピボット演算をすることもある。
正規化はSilver層の仕事で、Goldはビジネスユースケースに最適化された形。
正規化、非正規化。
言葉だけ並べてみると後者って否定的なイメージな気もしますが、冷静にレイヤーの目的を考えてみる。
試験対策として該当する公式ガイドを見ていなくても、自ずと選択できました。
もうちょい勉強すべきだったと思う箇所(振り返り)
これから受ける方の参考に、俺俺振り返りベースでまとめます。
まあ、単に勉強してて印象に残った・残ってない、うろ覚えかも?ベースってだけかもですが...
-
DLT
- Expectations構文(
expect_or_drop等) - ストリーミングテーブル定義
-
dlt.read_stream,spark.readStream
- Expectations構文(
-
Auto Loader
- スキーマ進化オプション(
failOnNewColumns、rescue、addNewColumns) - ファイルフィルタリング(
pathGlobFilter等)
- スキーマ進化オプション(
-
パフォーマンス診断
- CPU時間, タスク時間の解釈
- Spark UI、デバッガー
- パーティショニング周り
-
クラスター選択
- 閉域網要件, Classic, Pro
- All-Purpose, Job Cluster, SQL Warehouseの使い分け
知っておくべき
- ノートブックの制限
- Delta Sharing(オープンプロトコル)
- Liquid Clustering(パーティション/ZORDERとは共存不可)
- Databricks Connect(ローカルIDE + リモート実行)
- Asset Bundle(YAML形式)
- 監査ログ(JSON形式)
おわりに
模擬試験より難しかったですが、データエンジニアリングの基礎的な考え方は共通しているなと感じました。
Snowflake経験者はアドバンテージがあります。権限モデル、データガバナンス、パイプラインの考え方など、「翻訳」すれば通じるものが多いです。
AI活用は「一緒に模擬試験を考えながら解く」「知識として覚える」「Snowflake to Databricks翻訳」等あらゆるフェーズで効きました。
NotebookLMの音声ガイドとスライド資料は本当におすすめです。
ただし生成されたコンテンツのハルシネーションチェックはお忘れなく。
え、結果?
無事合格できました!
以上です。