Databricks 認定学習資料

テーマ切替

確認問題｜Professional ⑩ データ共有・フェデレーション（配点 5%） ​

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

問題 ​

Q1.（シナリオ）2 つの相手にデータを共有する。(a) 相手は Databricks を使っておらず Power BI から読みたい。(b) 相手は別アカウントの Unity Catalog 対応 Databricks ワークスペースを持ち、テーブルに加えてノートブックとモデルも渡したい。適切な共有方式の組み合わせはどれか。

  • A. (a) Databricks 間（D2D）共有、(b) オープン共有
  • B. (a) オープン共有プロトコル（Databricks 利用有無を問わず任意のプラットフォーム上の任意のユーザーと共有。認証はベアラートークンまたは OIDC フェデレーション。Databricks / Apache Spark / pandas / Power BI 等のコネクタで読める）、(b) Databricks 間（D2D）共有（トークン不要・共有識別子で接続。表形式に加えノートブック・ボリューム・モデル・ビューも共有可）
  • C. (a)(b) ともにオープン共有プロトコルで対応でき、ノートブックやモデルもオープン共有で渡せる
  • D. (a)(b) ともに Lakehouse フェデレーションを使う

Q2. D2D 共有で受信者が行う手順として、正しい説明はどれか。

  • A. 受信者は自分の UC メタストアの共有識別子（形式 <cloud>:<region>:<uuid>、例 aws:eu-west-1:b0c978c8-...）をプロバイダーに提供する。取得は Catalog Explorer の Delta Sharing 設定、または SQL の SELECT CURRENT_METASTORE();（標準／専用アクセスモードで実行）。資格情報ファイルは不要で、Databricks が安全な接続を処理し、共有データはワークスペースで自動的に検出可能になる
  • B. 受信者はアクティブ化リンクから資格情報ファイルをダウンロードし、ベアラートークンで認証する
  • C. 受信者は SELECT CURRENT_RECIPIENT(); で共有識別子を取得する
  • D. D2D 共有でも受信者ごとにトークンを発行し、プロバイダーがローテーションを管理する必要がある

Q3. オープン共有の認証方式について、正しい説明はどれか。

  • A. ベアラートークンは無期限に有効で、ローテーションの必要がない
  • B. 資格情報ファイルは何度でもダウンロードできるため、紛失しても再取得すればよい
  • C. OIDC フェデレーションは長期間有効なトークンを発行するため、ベアラートークンよりセキュリティ上不利である
  • D. ベアラートークン方式（TOKEN） では受信者作成時にトークン・資格情報ファイル・アクティブ化リンクが生成され、トークンは作成後最大 1 年間有効（既定の受信者トークン有効期間はメタストアで構成）。資格情報ファイルは 1 回だけダウンロード可能で、アクティブ化リンクは他者と共有しない。ローテーションでは受信者は同時に最大 2 トークン（アクティブ＋ローテーション中）を保持でき、--existing-token-expire-in-seconds（0 で即時失効）で旧トークンの失効タイミングを制御する。OIDC フェデレーション方式は受信者の IdP が発行する JWT と引き換えに有効期間の短い Databricks OAuth トークンを付与し、ベアラートークンよりセキュリティ・利便性で優れる（U2M / M2M フロー）

Q4. テーブルを共有に追加するときの WITH HISTORY について、正しい説明はどれか。

  • A. WITH HISTORY はストレージコストを削減するためのオプションである
  • B. 履歴を共有しなくても受信者はタイムトラベルと CDF クエリを実行できる
  • C. タイムトラベル・ストリーミング読み取り・CDF（table_changes()）のクエリには履歴付き共有（WITH HISTORY）が必要。プロバイダーが履歴付きでテーブルを共有すると、受信者はストリーミングソースとして低レイテンシ増分処理でき、Delta Lake タイムトラベルや CDF もクエリできる。既定は DBR 16.2 以降で WITH HISTORY、それ未満で WITHOUT HISTORY（スキーマ共有は常に WITH HISTORY）
  • D. WITH HISTORY を指定すると受信者がソースデータを更新できるようになる

Q5. Delta Sharing の制限について、正しい説明はどれか。

  • A. Parquet 形式のテーブルはそのまま共有でき、変換は不要である
  • B. 共有できる表形式データは Delta または Managed Iceberg 形式のみ（Parquet は CONVERT TO DELTA で変換可能、UniForm は Delta として読み取り）。共有できないテーブルにはパーティションフィルタ付きリキッドクラスタリング、V2 チェックポイント・R2、照合順序有効、行フィルター・列マスク付き、SHALLOW CLONE、外部キー制約付きのものがある。ノートブック・ボリューム・モデルは D2D 共有でのみ共有可能。共有可能なビューは Delta テーブルまたは他の共有可能ビューで定義する必要がある。親オブジェクト（カタログ／スキーマ）の削除は共有中の子オブジェクトも連鎖削除するため、削除前に共有から資産を外す
  • C. 行フィルター・列マスク付きのテーブルは、テーブルレベルでもオープン共有できる
  • D. 共有からテーブルを削除しても、受信者は引き続きアクセスできる

Q6. 受信者プロパティに応じて行／列を制限したい。正しい実装はどれか。

  • A. CURRENT_RECIPIENT()（DBR 14.2 以降）を使う動的ビューを共有する。行レベルなら WHERE country = CURRENT_RECIPIENT('country')、列レベルなら CASE WHEN CURRENT_RECIPIENT('country') = 'US' THEN pii ELSE 'REDACTED' END。パーティションを受信者プロパティで動的にフィルターする PARTITION (country = CURRENT_RECIPIENT().country) も使える。プロバイダー自身は共有コンテキストのため直接クエリできず、自分を受信者として共有してテストする
  • B. is_account_group_member() を使う動的ビューを共有する
  • C. 受信者ごとに別のテーブルを物理的にコピーして共有する以外に方法はない
  • D. 行フィルター／列マスクをテーブルに設定してからオープン共有する

Q7. Delta Sharing のエグレスコストについて、正しい説明はどれか。

  • A. すべての共有でクラウドベンダーのエグレス料金が発生する
  • B. Delta Sharing はデータをレプリケートするため、常に重複ストレージ費用が発生する
  • C. 同一リージョン内はエグレス費用なしでデータレプリケーションも不要。ただしクラウド／リージョンをまたぐとクラウドベンダーのエグレス料金が発生し得る（Cloudflare R2 からの共有はエグレス無料）。なおビュー／具体化ビュー／ストリーミングテーブルの共有・アクセスではコストが発生し得るため、system.billing（Billable usage）や materialization history システムテーブルで確認する
  • D. エグレス料金はプロバイダーではなく必ず受信者側に課金される

Q8. Lakehouse フェデレーションの 2 タイプについて、正しい説明はどれか。

  • A. クエリフェデレーションは Databricks コンピューティング上のみで実行され、カタログフェデレーションはリモート側にプッシュダウンする
  • B. どちらも書き込み（INSERT / UPDATE）に対応している
  • C. カタログフェデレーションは外部リレーショナル DB に JDBC 接続してクエリをプッシュダウンする方式である
  • D. クエリフェデレーションは JDBC 経由で外部リレーショナル DB にクエリをプッシュダウンし、Databricks コンピューティングとリモートコンピューティングの両方で実行される（運用 DB へのアドホックレポート・BI・PoC アクセス向け）。カタログフェデレーションは外部カタログ（Hive Metastore / Glue / Snowflake 等）を接続してオブジェクトストレージ上のデータを直接照会し、Databricks コンピューティング上のみで実行されるためより低コスト・高性能（UC への段階的移行やハイブリッドモデル維持向け）。どちらも読み取り専用で書き込みは非対応

Q9. Lakehouse フェデレーション（クエリフェデレーション）のセットアップ手順として、正しいものはどれか。

  • A. CREATE FOREIGN CATALOG → CREATE CONNECTION → GRANT の順
  • B. ①**CREATE CONNECTION（特定のフェデレーションサーバーを UC に登録し、URL・ポート・資格情報などの通信手段を確立。UC のセキュリティ保護可能オブジェクト）→ ②CREATE FOREIGN CATALOG（3 レベル名前空間をサポートする接続なら外部 DB のカタログ全体を UC に登録。スキーマ定義と関係は外部ソースと同期）→ ③GRANT**（カタログ／スキーマ／テーブルレベルでアクセス権を付与）。接続の資格情報は secret()（シークレットスコープ） で隠すのがベストプラクティス
  • C. 接続と外部カタログは UC 管理外のオブジェクトなので GRANT による権限管理はできない
  • D. 外部カタログを作成すると外部 DB のスキーマ定義はスナップショットとして固定され、以後同期されない

Q10. Lakehouse フェデレーションの適用要件と、他手段との使い分けについて、正しい説明はどれか。

  • A. Lakehouse フェデレーションは書き込みにも対応しているため、外部 DB への ETL 書き戻しに使える
  • B. Lakehouse フェデレーションは Hive メタストアでも利用でき、Unity Catalog は必須ではない
  • C. Lakehouse フェデレーションは Databricks SQL / Databricks Runtime 13.3 LTS 以降 / Unity Catalog のみが適用対象で読み取り専用。ソースが非対応の場合・書き込みアクセスが必要な場合・クエリの並列化を細かく制御したい場合は Spark データソース API を使う（DBR には PostgreSQL / SQL Server / MySQL / Snowflake / Redshift などのバンドルコネクタが含まれ、JDBC 互換 DB では JDBC の UC 接続で独自ドライバも使える。PySpark DataSource API でカスタムコネクタも構築可能）。ソースが Lakehouse Federation と Lakeflow Connect の両方をサポートし、データ量増大や低レイテンシのパフォーマンスが優先される場合は Lakeflow Connect（インジェスト） が推奨される
  • D. データ量が多く低レイテンシが必要な場合は、Lakeflow Connect よりも Lakehouse フェデレーションが推奨される

解答・解説 ​

Q1. 正解: B 判断基準は「相手が UC 対応 Databricks ワークスペースを持つか」。持たない／Databricks を使っていない相手にはオープン共有プロトコル（任意のプラットフォーム上の任意のユーザーと共有でき、認証はベアラートークンまたは OIDC フェデレーション。Databricks / Apache Spark / pandas / Power BI など多数のコネクタでアクセスできる）。持つ相手には D2D 共有（トークン不要で共有識別子から安全な接続を確立し、表形式データに加えノートブック・ボリューム・モデル・ビューも共有できる。UC ガバナンス・監査・使用状況追跡など他方式にない機能をサポート）。ノートブック・ボリューム・モデルは D2D 共有限定なので C は誤り。D の Lakehouse フェデレーションは「外部 DB のデータを Databricks から読み込む」機能で、共有（送り出す）とは目的が逆。

Q2. 正解: A D2D モデルでは受信者が自分の UC メタストアの共有識別子（形式 <cloud>:<region>:<uuid>）をプロバイダーに提供し、プロバイダーが受信者・共有を作成してアクセスを付与する。取得方法は Catalog Explorer の Delta Sharing 設定、または SQL の SELECT CURRENT_METASTORE();（標準／専用アクセスモードで実行）。資格情報ファイルは不要で、Databricks が安全な接続を処理し、共有データは受信者ワークスペースで自動的に検出可能になる（必要なら UC できめ細かいアクセス制御を追加できる）。B はオープン共有（トークン方式）の手順。C の CURRENT_RECIPIENT() は動的ビューで受信者プロパティを参照する関数で別物。D は D2D でトークン管理が不要である点に反する。

Q3. 正解: D ベアラートークン方式では受信者作成時にトークン・資格情報ファイル・アクティブ化リンクが生成され、トークンは作成後最大 1 年間有効（無期限ではない。A が誤り）。資格情報ファイルは 1 回だけダウンロード可能で、再クリックするとボタンが無効化されるため、紛失したらプロバイダーに連絡する必要がある（B が誤り）。ローテーションでは既存トークンを期限切れに設定して新トークン＋アクティブ化 URL に置換し、受信者は同時に最大 2 トークン（アクティブ＋ローテーション中）を保持できる。--existing-token-expire-in-seconds（0 で即時失効）で旧トークンの失効タイミングを制御し、侵害時は即時失効が推奨。OIDC フェデレーション方式は受信者の IdP が発行する JWT と引き換えに有効期間の短い Databricks OAuth トークンを付与し、ベアラートークンよりセキュリティ・利便性で優れる（C が逆）。なお 2025/12/8 より前に発行され有効期限が 2026/12/8 より後または無期限のトークンは 2026/12/8 に自動失効する。

Q4. 正解: CALTER SHARE ... ADD TABLE ... [WITH HISTORY | WITHOUT HISTORY] の WITH HISTORY は履歴付き共有を意味し、タイムトラベル・ストリーミング読み取り・CDF（table_changes()）のクエリに必須（B が誤り）。プロバイダーが履歴付きで共有すると、受信者は Apache Spark 構造化ストリーミングのソースとして低レイテンシ増分処理でき、Delta Lake タイムトラベルクエリや CDF クエリも可能になる。既定は DBR 16.2 以降で WITH HISTORY、それ未満で WITHOUT HISTORY（スキーマ共有は常に WITH HISTORY）。A のストレージコスト削減や D の書き込み許可とは無関係で、共有は常に読み取り専用である。

Q5. 正解: B 共有できる表形式データは Delta または Managed Iceberg 形式のみで、Parquet は CONVERT TO DELTA で変換が必要（A が誤り）、UniForm は Delta として読み取られる。共有できないテーブルにはパーティションフィルタ付きリキッドクラスタリング／V2 チェックポイント・R2／照合順序有効／行フィルター・列マスク付き／SHALLOW CLONE／外部キー制約付きがある。特にテーブルレベルの行フィルター・列マスク付きテーブルは OpenSharing プロバイダーが共有できない（ABAC ベースのものは共有所有者がポリシーから除外されていれば共有可能）ため C は誤り。ノートブック・ボリューム・モデルは D2D 共有でのみ共有可能。共有可能なビューは Delta テーブルまたは他の共有可能ビューで定義する必要がある。親オブジェクト（カタログ／スキーマ）の削除は共有中の子オブジェクトも連鎖削除するため、削除前に共有から資産を外すこと。D は誤りで、UC メタストアから共有を削除すると全受信者がアクセスを失う（REVOKE でも同様にアクセスは失われる）。

Q6. 正解: A 共有における行／列レベル制御は CURRENT_RECIPIENT()（Databricks Runtime 14.2 以降）を使う動的ビューで実現する。行レベルなら WHERE country = CURRENT_RECIPIENT('country')、列レベルなら CASE WHEN CURRENT_RECIPIENT('country') = 'US' THEN pii ELSE 'REDACTED' END。マルチテナント共有では ALTER SHARE ... ADD TABLE ... PARTITION (country = CURRENT_RECIPIENT().country) で受信者プロパティによる動的パーティションフィルターも使える。プロバイダー自身は共有コンテキストのため直接クエリできず、自分を受信者として共有してテストする。B の is_account_group_member() は自社ワークスペース内ユーザーのグループ判定用（Unity Catalog の動的ビュー）で、外部の共有受信者の判定には使えない。D は行フィルター・列マスク付きテーブルがそもそもオープン共有できない点で誤り。

Q7. 正解: C Delta Sharing はゼロコピー（データを移動しない）方式なのでデータレプリケーションが不要で重複ストレージも発生しない（B が誤り）。エグレスは同一リージョン内は費用なしで、クラウド／リージョンをまたぐとクラウドベンダーのエグレス料金が発生し得る（A が誤り）。Cloudflare R2 からの共有はエグレス無料。なお、ビュー／具体化ビュー／ストリーミングテーブルの共有・アクセスではコストが発生し得るため、system.billing（Billable usage）や materialization history システムテーブルで確認する。D のような「必ず受信者側に課金」という規定はない。

Q8. 正解: Dクエリフェデレーションは JDBC 経由で外部リレーショナル DB（MySQL / PostgreSQL / Teradata / Oracle / Redshift / Salesforce Data 360 / Snowflake / SQL Server / Azure Synapse / BigQuery / Databricks）にクエリをプッシュダウンし、Databricks コンピューティングとリモートコンピューティングの両方で実行される（運用 DB へのアドホックレポート・BI・PoC アクセス向け）。カタログフェデレーションは外部カタログ（従来の Databricks Hive メタストア／外部 Hive メタストア／Salesforce Data 360 / Snowflake / OneLake）を接続してオブジェクトストレージ上のデータを直接照会し、Databricks コンピューティング上のみで実行されるためより低コスト・高性能（UC への段階的移行やハイブリッドモデル維持向け）。A・C は 2 タイプの説明が入れ替わっている。どちらも読み取り専用で書き込みは非対応なので B も誤り。

Q9. 正解: B セットアップは 3 ステップ。①**CREATE CONNECTION：特定のフェデレーションサーバーを UC に登録し、URL・ポート・資格情報（ユーザー名／パスワード等）などの通信手段を確立する。②CREATE FOREIGN CATALOG：3 レベル名前空間（catalog.schema.table）をサポートする接続なら、外部 DB のカタログ全体を UC に登録できる。スキーマ定義とその関係は外部ソースと同期される（D が誤り。REFRESH FOREIGN CATALOG で明示的な再同期も可能）。③GRANT**：通常のセキュリティ保護可能リソース同様、カタログ／スキーマ／テーブルレベルで付与できる（接続と外部カタログはどちらも UC のセキュリティ保護可能オブジェクトなので C は誤り）。A は順序が逆で、接続がなければ外部カタログは作れない。資格情報は user secret('secrets.r.us', 'postgresUser') のように secret()（シークレットスコープ） で隠すのがベストプラクティス。

Q10. 正解: C Lakehouse フェデレーションの適用対象は Databricks SQL / Databricks Runtime 13.3 LTS 以降 / Unity Catalog のみ（B が誤り）で、読み取り専用（A が誤り）。ソースが非対応の場合・書き込みアクセスが必要な場合・クエリの並列化を細かく制御したい場合は Spark データソース API を使う（DBR には PostgreSQL / SQL Server / MySQL / Snowflake / Redshift などのバンドルコネクタが含まれ、JDBC 互換 DB では JDBC の UC 接続で独自ドライバも使える。PySpark DataSource API でカスタムコネクタも構築可能）。またソースが Lakehouse Federation と Lakeflow Connect の両方をサポートし、データ量増大や低レイテンシのパフォーマンスが優先される場合は Lakeflow Connect（インジェスト）が推奨される（D が逆）。同様に、データ重複を制限したい／可能な限り最新データをクエリしたい場合は Delta Sharing、大量データ・低レイテンシ・サードパーティ API 制限対応が優先ならマネージドコネクタ（インジェスト）という使い分けになる。