Databricks 認定学習資料

テーマ切替

確認問題｜Professional ③ データ変換・クレンジング・品質（配点 10%） ​

教材 03-transformation-quality.md の内容に基づく確認問題です（全10問）。 まず問題を解き、下の「解答・解説」で答え合わせをしてください。

問題 ​

Q1. Lakeflow パイプラインの Expectations（期待値）の 3 つのアクションについて、構文と結果の対応として正しいものはどれか。

  • A. warn＝ON VIOLATION DROP ROW / dp.expect_or_drop、drop＝EXPECT / dp.expect、fail＝ON VIOLATION FAIL UPDATE / dp.expect_or_fail
  • B. 既定は drop で、無効レコードは常にターゲットから削除される
  • C. warn（既定）＝EXPECT / dp.expect は無効レコードもターゲットに書き込み合否件数のメトリックを収集。drop＝EXPECT ... ON VIOLATION DROP ROW / dp.expect_or_drop は書き込み前に削除し削除件数を記録。fail＝EXPECT ... ON VIOLATION FAIL UPDATE / dp.expect_or_fail は更新を失敗させトランザクションをアトミックにロールバックし、メトリックは記録されない
  • D. fail は無効レコードのみをスキップして更新自体は成功させ、メトリックに違反件数を記録する

Q2.（シナリオ）1 つのパイプライン内で複数のフローが並列に走っている。あるフローの期待値が expect_or_fail で違反を検出した。パイプラインの実行モードによる挙動の違いとして正しいものはどれか。

  • A. トリガーされたパイプラインでは 1 フローが失敗しても他の並列フローは失敗せず、失敗したフローの更新のみがロールバックされる。連続（continuous）パイプラインでは失敗した期待値がフローを停止し、すべての依存フローも停止して停止理由のメッセージが出力される
  • B. どちらのモードでもパイプライン全体が即座に停止し、全フローの更新がロールバックされる
  • C. トリガーされたパイプラインでは全依存フローが停止し、連続パイプラインでは当該フローのみロールバックされる
  • D. 実行モードに関係なく、失敗した期待値は警告としてログに記録されるだけでフローは継続する

Q3. 期待値の定義に関する制限として、正しいものはどれか。

  • A. 制約句にはカスタム Python 関数や他テーブルを参照するサブクエリを自由に使える
  • B. 複数の期待値を辞書でまとめて集合アクションを適用できる expect_all / expect_all_or_drop / expect_all_or_fail は Python 限定で、SQL では複数の CONSTRAINT ... EXPECT (...) をカンマ区切りで並べるだけ。制約句にはカスタム Python 関数・外部サービス呼び出し・他テーブルを参照するサブクエリは使用不可。期待値名は特定データセット内で一意である必要がある
  • C. expect_all 系は SQL でのみ利用でき、Python では個別のデコレーターしか使えない
  • D. 期待値はストリーミングテーブル・具体化ビュー・一時ビューに加え、シンク（sink）でもサポートされる

Q4. 無効レコードを「捨てずに」別経路で扱いたい。教材が示す隔離（quarantine）パターンの実装として正しいものはどれか。

python
rules = {"valid_pickup_zip": "(pickup_zip IS NOT NULL)", "valid_dropoff_zip": "(dropoff_zip IS NOT NULL)"}
quarantine_rules = "NOT({0})".format(" AND ".join(rules.values()))
  • A. expect_or_fail を使い、無効レコードが 1 件でもあればパイプラインを失敗させて手動で修正する
  • B. expect_or_drop を使えば削除された行が自動的に別テーブルへ退避されるので、追加の実装は不要
  • C. _rescued_data 列を使えば無効レコードが自動的に隔離される
  • D. is_quarantined フラグ列（上記の quarantine_rules 式）を付与した一時テーブルを @dp.expect_all(rules) 付きで作り、is_quarantined=false / true でフィルターしたビューを分けて定義する。データを失わずに有効／無効を分離しつつ、品質メトリックも取得できる

Q5.（シナリオ）変換後の行数が一致するかを expect_or_fail で検証する「検証テーブル」を作成した。この検証テーブルをダウンストリームのデータセットから読んでいるが、検証が失敗してもダウンストリームが更新されてしまう。原因と対処として正しいものはどれか。

  • A. 検証テーブルを具体化ビューではなくストリーミングテーブルにすれば、自動的にゲートされる
  • B. expect_or_fail ではなく expect_or_drop を使うべきである
  • C. Expectations はオーケストレーションではなく品質担保のための仕組みであり、検証テーブルを他データセットから読んでも、そのデータセットは検証結果を待たない（ダウンストリームは自動でゲートされない）。検証失敗でダウンストリームを止めたいなら、検証とダウンストリーム作業を別々のパイプラインに分割し、ジョブのタスク依存で調整する
  • D. 検証テーブルに pipelines.reset.allowed = false を設定すれば、失敗時にダウンストリームが止まる

Q6. MERGE INTO の WHEN 句のルールについて、正しい説明はどれか。

  • A. 同じ種類の WHEN 句を複数書く場合、最初の句以外は条件（AND ...）を持ってはならない
  • B. 各種類の句は複数指定でき指定順に評価される。同じ種類の句が複数ある場合、最後の句を除くすべてに条件が必須（省略すると NON_LAST_..._CLAUSE_OMIT_CONDITION エラー）。WHEN NOT MATCHED BY SOURCE の条件・アクションはターゲット列のみ参照可で、条件なしで使うとテーブル全書き換えにつながるため必ず条件で範囲を絞る
  • C. WHEN NOT MATCHED BY SOURCE ではソース列を参照して条件を書くのが一般的である
  • D. WHEN NOT MATCHED [BY TARGET] では INSERT に加えて UPDATE / DELETE も指定できる

Q7. CDC フィードを手書きの MERGE で適用したところ、「複数一致（multiple matches）」でエラーになった。原因と回避策として正しいものはどれか。

  • A. ON と WHEN MATCHED の条件により、ソースの複数行がターゲットの同一行に一致すると「どのソース行で更新すべきか曖昧」なため操作が失敗する。回避策はソースを前処理して一致を一意化すること（CDC ならキーごとに最新変更のみを残す）。ただし無条件の DELETE は曖昧でないため複数一致でも許可される
  • B. 複数一致が起きた場合、Spark は自動的に任意の 1 行を選んで正常に更新するため、エラーの原因は別にある
  • C. 複数一致を許可するには MERGE WITH MULTIPLE MATCHES 構文を使う
  • D. ターゲットに主キー制約を追加すれば複数一致は解消される

Q8. ログ追記型 ETL で MERGE による重複排除を実装する。教材の記述として正しいものはどれか。

sql
MERGE INTO logs USING newDedupedLogs
ON logs.uniqueId = newDedupedLogs.uniqueId
WHEN NOT MATCHED THEN INSERT *
  • A. この insert-only マージは、ターゲット既存データとの重複だけでなく、新データセット内部の重複も自動的に排除する
  • B. insert-only マージは冪等ではないため、再実行すると同じ行が二重に挿入される
  • C. WHEN MATCHED THEN UPDATE SET * を追加しないと重複排除にならない
  • D. insert-only マージ（WHEN NOT MATCHED THEN INSERT *）は同じキーの再挿入を防ぐため、再実行や重複ログでも二重書き込みされず冪等。ただし新データセット内部の重複は挿入されてしまうので、マージ前に新データ側を重複排除しておく必要がある。数日だけ重複が起きうるなら ON と WHEN NOT MATCHED に日付範囲条件を付けて探索範囲を絞ると最適化できる

Q9. バッチ処理とストリーミング処理のセマンティクス、およびメダリオン各層での推奨について、正しい説明はどれか。

  • A. バッチは新データのみを処理するため効率的で、ストリーミングは毎回全データを再処理するため低速である
  • B. バッチはソースで現在利用可能な全データを毎回処理し、ロジックが単純で結果は常に正確だが非効率・低速。ストリーミングは処理済みを追跡し新データのみを処理するため効率的・低遅延だが、結合・集計・重複除去などステートフル処理で複雑化し、順序ずれ・遅延データで結果が常に正確とは限らない。推奨は Bronze＝ストリーミング処理（ステートレスな増分追加が多く、ステートフルの複雑さに触れずに増分の利点を得られる）、Silver / Gold＝バッチ処理（具体化ビューは増分更新）
  • C. 遅延到着データは、バッチではその時間帯の既処理データとは別に処理され、ストリーミングでは次回バッチで上書き修正される
  • D. Gold 層は最終段の集約でデータサイズが大きいため、必ずストリーミング処理を使う

Q10. Expectations（インライン品質）と「データ品質の監視（旧 Lakehouse Monitoring）」の役割分担について、正しい説明はどれか。

  • A. どちらも同じ機能の別名であり、Expectations は SQL 用、データ品質の監視は Python 用である
  • B. データ品質の監視はパイプライン実行中に無効レコードを warn / drop / fail で制御する機能である
  • C. Expectations はパイプライン内で通過時に品質を作り込む（warn / drop / fail、隔離）。データ品質の監視はテーブルに対する事後・継続的な観測で、異常検知（鮮度＝コミット履歴から次コミット時刻を予測し異常に遅れれば「古い」とマーク、完全性＝過去 24 時間の書き込み行数が予測範囲の下限を下回れば「不完全」とマーク）とデータプロファイル（分布・null 率・パーセンタイル・ドリフト）から成り、監視対象テーブルを変更せずサーバーレスで実行される。運用では両者を併用する
  • D. データ品質の監視は監視対象テーブルに _quality 列を追加して品質スコアを書き込むため、テーブルスキーマが変更される

解答・解説 ​

Q1. 正解: C 3 アクションの対応は最頻出。warn（既定）は EXPECT / dp.expect で違反レコードも有効レコードと共にターゲットへ追加し、合否件数のメトリックを収集する。drop は EXPECT ... ON VIOLATION DROP ROW / dp.expect_or_drop で書き込み前に削除し、削除件数をメトリックに記録する。fail は EXPECT ... ON VIOLATION FAIL UPDATE / dp.expect_or_fail で更新を失敗させ、テーブル更新はアトミックにロールバックされ、再処理には手動介入が必要で、メトリックは記録されない（更新が失敗するため）。A は warn と drop の対応が逆、B は既定が warn である点、D は fail の挙動が誤り。

Q2. 正解: Afail 時の挙動はパイプライン実行モードに依存する。トリガーされたパイプラインでは 1 フローが失敗しても他の並列フローは失敗せず、失敗したフローの更新のみロールバックされる。連続（continuous）パイプラインでは失敗した期待値がフローを停止し、すべての依存フローも停止して停止理由のメッセージを出力する。なお fail 用に構成された期待値は、違反を検出・報告するために Spark クエリプランを変更し、違反した入力レコードを特定できるようにする（[EXPECTATION_VIOLATION.VERBOSITY_ALL] ... の専用エラー）。

Q3. 正解: B 1 データセットに複数の期待値を持てるのは SQL・Python 共通だが、グループ化して集合アクションを指定できるのは Python のみ（expect_all / expect_all_or_drop / expect_all_or_fail、引数は「名前→制約」の辞書）。SQL は複数 CONSTRAINT をカンマ区切りで並べるだけ（C が誤り）。制約句は各レコードで true/false に評価される SQL 条件で、カスタム Python 関数・外部サービス呼び出し・他テーブルを参照するサブクエリは使えない（A が誤り）。期待値をサポートするのはストリーミングテーブル・具体化ビュー・一時ビューのみで、シンクは非対応（D が誤り）。また AUTO CDC FROM SNAPSHOT でも期待値は非対応。

Q4. 正解: D 隔離（quarantine）は「データを失わずに無効レコードを別経路で扱う」パターン。is_quarantined フラグ列（NOT(ルールの AND 結合) の式）を付与した一時テーブルを @dp.expect_all(rules) 付きで作り（partition_cols=["is_quarantined"]）、is_quarantined=false / true でフィルターした有効／無効ビューを別々に定義する。これによりデータを捨てずに分離でき、expect_all により品質メトリックも取得できる。A は隔離ではなく即時失敗、B は drop された行が自動退避されるという誤り、C の _rescued_data は Auto Loader のスキーマ不一致データの退避列で別概念。

Q5. 正解: C 教材の重要な原則は「Expectations はオーケストレーションではなく品質担保」。検証テーブルを他データセットから読んでも、そのデータセットは検証結果を待たないため、ダウンストリームは自動的にゲートされない。検証失敗でダウンストリームを止めたいなら、検証とダウンストリーム作業を別々のパイプラインに分割し、ジョブのタスク依存で調整する。B のように expect_or_drop にしても更新は成功するので要件を満たさない。

Q6. 正解: B 3 種類の WHEN 句（WHEN MATCHED / WHEN NOT MATCHED [BY TARGET] / WHEN NOT MATCHED BY SOURCE）はそれぞれ複数指定でき指定順に評価される。同じ種類の句が複数ある場合、最後の句を除くすべてに条件が必須で、省略すると NON_LAST_..._CLAUSE_OMIT_CONDITION エラーになる（A は「最初の句以外」としており誤り）。WHEN NOT MATCHED BY SOURCE（DBR 12.2 LTS 以上）の条件・アクションは、ソース行が存在しないためターゲット列のみ参照可（C が誤り）で、リテラルやターゲット列演算で指定する。条件なしで使うと多数のターゲット行の更新／削除・テーブル全書き換えにつながりコスト増になるため、必ず条件で範囲を絞る。D は WHEN NOT MATCHED [BY TARGET] で使えるのが INSERT * / INSERT (...) VALUES (...) のみである点が誤り。

Q7. 正解: AON と WHEN MATCHED の条件により、ソースの複数行がターゲットの同一行に一致すると、どのソース行で更新すべきか曖昧なため操作は失敗する。回避策はソースを前処理して一致を一意化すること（CDC ではキーごとに最新変更のみを残す）。ただし無条件の DELETE は曖昧でないため複数一致でも許可される。なお DBR 16.0 以降は ON ＋ WHEN MATCHED 条件で重複一致を判定し、15.4 LTS 以下は ON 条件のみで判定する。C・D のような構文・制約は存在しない（Delta の主キーは情報的で強制されない）。

Q8. 正解: D insert-only マージ（WHEN NOT MATCHED THEN INSERT *）は同じキーの再挿入を防ぐため、再実行や重複ログでも二重書き込みされず冪等になる。ログ追記型 ETL の重複対策の定番。ただし重要な注意として、ターゲット既存データとの重複は防ぐが、新データセット内部の重複は挿入されてしまうため、マージ前に新データ側を重複排除しておく必要がある（A が誤り）。数日だけ重複が発生し得る場合は、テーブルを日付でパーティションし ON と WHEN NOT MATCHED に日付範囲条件を付けると、テーブル全体でなく直近のみを探索してクエリを最適化できる。また insert-only マージは foreachBatch と組み合わせた構造化ストリーミングの継続的重複排除にも使える。

Q9. 正解: B バッチセマンティクスはエンジンが処理済みデータを追跡せず、ソースで現在利用可能な全データを毎回処理する（ロジックが単純・結果は常に正確・ただし非効率で秒／ミリ秒レベルは不可）。ストリーミングセマンティクスは処理済みを追跡し新データのみを処理する（効率的・時間〜ミリ秒まで対応・ただしステートフル処理で複雑化し順序ずれ／遅延データで結果が常に正確とは限らない）。遅延到着データはバッチでは次回バッチで既存データと合わせて再処理され前回結果が上書き修正され、ストリーミングではその時間帯の既処理データとは別に処理されるため状態（state）の保持が必要 —— C はこの説明が逆。メダリオンの推奨は Bronze＝ストリーミング、Silver / Gold＝バッチ（具体化ビューの増分更新）。D は Gold のデータサイズが小さい点でも誤り。

Q10. 正解: C Expectations はパイプライン内で通過時に品質を作り込む「インライン品質」で、無効データを warn / drop / fail で制御したり隔離したりする。一方「データ品質の監視（旧 Lakehouse Monitoring）」はテーブルに対する事後・継続的な観測で、異常検知（鮮度＝コミット履歴から次コミット時刻を予測し異常な遅れを「古い（stale）」とマーク、完全性＝過去 24 時間の書き込み行数が履歴からの予測範囲の下限を下回れば「不完全」とマーク）とデータプロファイル（分布・null 率・パーセンタイル・ドリフト、カスタムメトリック、時間粒度の制御）から成る。監視対象テーブルを変更せず、設定ジョブにオーバーヘッドを追加せず、サーバーレスコンピューティングで実行され DATA_QUALITY_MONITORING として課金される（D が誤り）。運用では両者を併用し、パイプラインで不良を制御しつつ監視で経時的な品質劣化・異常を検知する。