Lakehouse Federationで外部DBを仮想化: CONNECTION・FOREIGN CATALOG・制約

Lakehouse Federationは、Databricksから外部データベース（PostgreSQL、MySQL、Snowflake、BigQuery等）のテーブルをデータ移動なしでクエリする仕組みです。 Unity CatalogのCONNECTIONとFOREIGN CATALOGを使って外部DBをDatabricksの名前空間に仮想的にマッピングし、 通常のSQL文でアクセスできます。ETL不要で外部データをDatabricks分析に取り込めるのが最大の利点です。

Lakehouse Federationとは

Federationは「データを移動させず、クエリを外部DBに中継する」アプローチです。 外部DBのテーブルがあたかもDatabricks上のテーブルであるかのように3レベル名前空間（catalog.schema.table）でアクセスできます。

• データのコピーは発生しない: クエリ実行時にリアルタイムで外部DBにリクエストが飛ぶ
• 読み取り専用: SELECT文のみ実行可能。INSERT/UPDATE/DELETEは不可
• Unity Catalog統合: 外部テーブルにもUCのアクセス制御（GRANT/REVOKE）が適用可能
• Pushdown最適化: WHERE句やSELECTカラムの絞り込みが外部DBにプッシュダウンされ、転送量を削減

対応データベース

CONNECTIONの作成

CONNECTIONは外部DBへの接続情報（ホスト、ポート、認証情報）を定義するUCオブジェクトです。 作成にはCREATE CONNECTION権限が必要です。

PostgreSQLの場合

CREATE CONNECTION pg_production
TYPE POSTGRESQL
OPTIONS (
  host     'prod-db.example.com',
  port     '5432',
  user     'databricks_reader',
  password SECRET('federation-scope', 'pg-password')
);

Snowflakeの場合

CREATE CONNECTION sf_analytics
TYPE SNOWFLAKE
OPTIONS (
  host     'myorg-myaccount.snowflakecomputing.com',
  user     'DATABRICKS_SVC',
  password SECRET('federation-scope', 'sf-password'),
  sfWarehouse 'COMPUTE_WH'
);

BigQueryの場合

CREATE CONNECTION bq_data_warehouse
TYPE BIGQUERY
OPTIONS (
  GoogleServiceAccountKeyJson SECRET('federation-scope', 'bq-sa-key')
);

認証情報にはDatabricksのSecret（SECRET関数）を使い、SQLテキスト内にパスワードを直書きしないのが鉄則です。 Secret Scopeは事前にdatabricks secrets create-scope等で作成しておきます。

FOREIGN CATALOGの作成

FOREIGN CATALOGはCONNECTIONを使って外部DBのスキーマ・テーブルをUCの名前空間にマッピングするオブジェクトです。

-- PostgreSQLのデータベースをFOREIGN CATALOGとしてマッピング
CREATE FOREIGN CATALOG pg_catalog
USING CONNECTION pg_production
OPTIONS (database 'production_db');

-- Snowflakeのデータベースをマッピング
CREATE FOREIGN CATALOG sf_catalog
USING CONNECTION sf_analytics
OPTIONS (database 'ANALYTICS_DB');

-- BigQueryのプロジェクトをマッピング
CREATE FOREIGN CATALOG bq_catalog
USING CONNECTION bq_data_warehouse
OPTIONS (project 'my-gcp-project');

作成後は通常のUCテーブルと同じ3レベル名前空間でアクセスできます。

-- PostgreSQLのテーブルをクエリ
SELECT * FROM pg_catalog.public.customers WHERE region = 'APAC';

-- SnowflakeのテーブルとローカルのテーブルをクロスデータベースJOIN
SELECT
  c.customer_name,
  o.total_amount
FROM pg_catalog.public.customers c
JOIN main.gold.orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= '2026-01-01';

-- BigQueryのテーブルを参照
SELECT * FROM bq_catalog.my_dataset.events LIMIT 100;

アクセス制御

FOREIGN CATALOGのテーブルにもUCのGRANT/REVOKEが適用されます。 外部DBのネイティブ権限とUC権限の2層で制御されるため、両方で許可された操作のみ実行可能です。

-- FOREIGN CATALOGの使用権限をグループに付与
GRANT USE CATALOG ON CATALOG pg_catalog TO data_analysts;
GRANT USE SCHEMA ON SCHEMA pg_catalog.public TO data_analysts;
GRANT SELECT ON TABLE pg_catalog.public.customers TO data_analysts;

-- CONNECTIONの管理権限
GRANT CREATE FOREIGN CATALOG ON CONNECTION pg_production TO catalog_admins;

• CONNECTION作成: メタストア管理者またはCREATE CONNECTION権限保持者
• FOREIGN CATALOG作成: CONNECTION上のCREATE FOREIGN CATALOG権限保持者
• テーブルのSELECT: UC上のGRANT SELECT + 外部DBの読み取り権限の両方が必要

Pushdown最適化

Federationのクエリ実行時に、一部の操作が外部DBにプッシュダウンされます。 プッシュダウンされると外部DBからDatabricksに転送されるデータ量が削減され、パフォーマンスが向上します。

-- プッシュダウンの確認（EXPLAIN文）
EXPLAIN FORMATTED
SELECT customer_id, customer_name
FROM pg_catalog.public.customers
WHERE region = 'APAC' AND created_at >= '2026-01-01';

-- 結果の PushedFilters セクションに
-- [region = 'APAC', created_at >= '2026-01-01'] が表示されれば
-- フィルタがプッシュダウンされている

制約と注意事項

• 読み取り専用: SELECT文のみ。DML（INSERT/UPDATE/DELETE/MERGE）は不可
• パフォーマンス: 大量データの転送はネットワークボトルネックになる。WHERE句で絞り込むか、定期的にDeltaに取り込む運用を検討
• 型マッピング: 外部DBの型がSparkの型に自動マッピングされるが、一部の型（geometry、array等）は未対応の場合がある
• トランザクション分離: 外部DBのトランザクション分離レベルに依存。ダーティリードの可能性は外部DBの設定次第
• ネットワーク要件: Databricksのコンピュートプレーンから外部DBへのネットワーク到達性が必要（VPCピアリング、Private Link等）
• Deltaテーブルとの結合: FOREIGN CATALOGのテーブルとローカルのDeltaテーブルをJOINできるが、外部テーブル側のデータはすべてSpark側に転送されるため大テーブル同士のJOINは非推奨

Federation vs ETL: 使い分け判断

実務運用パターン

[外部DB: PostgreSQL / MySQL / Snowflake / BigQuery]
       │
       │  CONNECTION (認証情報はSecretで管理)
       v
[FOREIGN CATALOG] → UC名前空間にマッピング
       │
       ├── アドホック分析: SELECT ... WHERE で直接クエリ
       │     → Pushdownで転送量を最小化
       │
       └── ETLパイプライン: 定期的にDelta Lakeに取り込み
             → CTAS/MERGEでDeltaテーブルにマテリアライズ
             → 大量データの結合・集約はDelta上で高速処理

Federationを「探索フェーズ」で使い、価値が確認できたデータをETLでDeltaに取り込むハイブリッド運用が現実的です。

問題で確認

よくある質問