[Databricks] Data Migration에서 Lakehouse Federation을 활용하는 전략

대규모 데이터 마이그레이션의 가장 큰 어려움은 데이터를 한 번 옮기는 작업이 아니다. 원천 시스템이 계속 변경되는 동안 수백·수천 개의 테이블과 하위 소비자를 순차적으로 전환하고, 이관 전후의 결과가 같다는 것을 증명하며, 문제가 생기면 안전하게 되돌릴 수 있어야 한다.

전통적인 Big Bang 방식은 다음과 같은 위험을 만든다.

• 모든 데이터와 ETL을 옮길 때까지 신규 플랫폼을 사용할 수 없다.
• 원천과 타깃을 비교하기 위한 별도 추출·적재 작업이 필요하다.
• 일부 테이블의 지연이 전체 Cutover를 막는다.
• 전환 시점에 발견한 오류를 되돌리기 어렵다.
• 이관 기간 동안 원천과 신규 플랫폼의 데이터가 계속 달라진다.

Databricks Lakehouse Federation은 이런 문제를 줄이는 데 유용하다. 외부 데이터베이스나 카탈로그의 데이터를 복사하지 않고 Unity Catalog의 Foreign Catalog를 통해 조회할 수 있기 때문이다.

그러나 가장 중요한 전제가 있다.

Lakehouse Federation은 데이터 마이그레이션 자체가 아니라, 마이그레이션 과정에서 원천과 타깃을 연결하는 전환 브리지다.

Federation만 연결했다고 데이터가 Delta Lake로 이관된 것은 아니다. 장기적으로 높은 조회 성능, 낮은 원천 부하, 변경 이력, 재처리, 장애 격리가 필요하다면 데이터는 결국 Delta 테이블로 물리화해야 한다.

이 글에서는 Lakehouse Federation을 데이터 마이그레이션의 어느 단계에 사용해야 하는지, 어떤 데이터는 Federation으로 남길 수 있고 어떤 데이터는 반드시 CDC나 증분 적재로 전환해야 하는지, Cutover와 Rollback은 어떻게 설계해야 하는지 정리한다.

이 글은 2026년 8월 Databricks 공식 문서를 기준으로 작성했다. 지원 원천, Runtime, SQL Warehouse, Serverless 및 클라우드별 네트워크 기능은 변경될 수 있으므로 적용 전 현재 워크스페이스의 지원 범위를 확인해야 한다.

---

1. Lakehouse Federation은 무엇인가?

Lakehouse Federation은 외부 데이터베이스와 카탈로그를 Unity Catalog에 연결하고, 데이터를 복제하지 않은 상태에서 Databricks SQL로 조회할 수 있게 하는 기능이다.

Unity Catalog에는 다음 객체가 생성된다.

• Connection: 외부 시스템의 Host, Port, 인증 정보와 연결 설정을 관리하는 보안 객체
• Foreign Catalog: 외부 데이터베이스 또는 카탈로그의 구조를 Unity Catalog에 미러링하는 객체
• Foreign Table: 외부에 실제 데이터가 있고 Databricks에서는 읽기 경로와 권한을 제공하는 테이블

Lakehouse Federation은 크게 Query Federation과 Catalog Federation으로 나뉜다.

Query Federation

Oracle, PostgreSQL, MySQL, SQL Server, Snowflake, Redshift 등 외부 데이터베이스를 JDBC 기반으로 조회한다. Databricks가 지원되는 Filter, Projection, Aggregate 등을 원격 DB에 Pushdown하고, 원격 실행 결과를 Databricks로 가져온다.

Databricks SQL
    ↓ Pushdown SQL
External Database Compute
    ↓ Result Set
Databricks Compute

원천 DB의 현재 데이터를 즉시 조회하고 싶거나, ETL 개발 전에 데이터 구조를 탐색하거나, 마이그레이션 중 원천과 타깃을 비교할 때 유용하다.

Catalog Federation

Hive Metastore, AWS Glue, Snowflake 등 외부 Catalog와 연결하고, 실제 데이터 파일은 Object Storage에서 Databricks Compute가 직접 읽는다. Query Federation처럼 원격 데이터베이스 Compute에서 SQL을 실행하는 방식이 아니라, 외부 Catalog의 Metadata를 이용해 Databricks가 스토리지 데이터를 읽는다.

Unity Catalog
    ↓ Foreign Metadata
External Catalog

Databricks Compute
    ↓ Direct Read
Object Storage

기존 Hive Metastore 또는 외부 Catalog의 테이블을 Unity Catalog로 점진적으로 전환하거나, 일부 데이터는 기존 Catalog에 남겨두는 장기 Hybrid 구조에 적합하다.

Query Federation과 Catalog Federation 비교

구분	Query Federation	Catalog Federation
주요 원천	관계형 DB·Data Warehouse	외부 Catalog·Open Table Storage
쿼리 실행	Databricks와 원격 DB	Databricks Compute
데이터 접근	JDBC 결과 전송	Object Storage 직접 읽기
원천 Compute 부하	발생	일반적으로 DB Compute 부하 없음
쓰기	원칙적으로 Read-only	원칙적으로 Read-only
대표 마이그레이션 용도	원천 DB 탐색·병행 검증·임시 접근	Unity Catalog 점진 전환·장기 Hybrid
장기 Serving	저빈도·소규모에 제한적으로 적합	Open Format Hybrid 요구 시 검토

---

2. Federation과 Ingestion을 혼동하면 안 된다

Federation은 외부 데이터를 그 자리에서 읽는 방식이고, Ingestion은 데이터를 Databricks의 Delta 테이블로 이동하고 지속적으로 동기화하는 방식이다.

관점	Federation	Ingestion to Delta
데이터 위치	원천에 유지	Databricks Storage에 복제
최신성	원천의 현재 상태	마지막 적재·CDC 반영 시점
원천 장애 영향	조회에 직접 영향	마지막 적재 데이터는 계속 사용 가능
원천 부하	조회할 때마다 발생 가능	적재 시점 중심으로 통제
대규모 반복 분석	부적합할 수 있음	적합
변경 이력	원천 보존 정책에 의존	Delta·SCD 정책으로 통제
재처리	원천 데이터가 남아 있어야 함	Bronze·Checkpoint 기반으로 설계 가능
Write·Merge	Foreign Table은 원칙적으로 불가	가능
성능 최적화	Pushdown과 원천 성능에 의존	Liquid Clustering 등 적용 가능

Databricks 역시 고용량과 낮은 조회 지연이 중요하고 지원 Connector가 있다면 Lakeflow Connect를 통한 Ingestion을 권장한다. Federation은 Ad-hoc Reporting, PoC, 점진적 마이그레이션과 같은 상황에서 강점이 있다.

따라서 데이터 마이그레이션의 실무 전략은 둘 중 하나를 고르는 것이 아니라 다음과 같이 조합하는 것이다.

Federation으로 즉시 접근하고 검증한 뒤, 중요 데이터는 CDC·증분 적재로 Delta에 물리화하고, 소비자를 단계적으로 전환한다.

---

3. 마이그레이션에서 Federation이 해결하는 문제

1) ETL 개발 전에 원천을 즉시 탐색할 수 있다

기존 방식에서는 테이블을 하나 검증하려고 해도 JDBC 코드, Landing Path, Schema, Job을 먼저 만들어야 했다. Federation을 사용하면 Foreign Catalog를 생성한 뒤 Databricks SQL로 원천 구조와 데이터를 탐색할 수 있다.

• 테이블·컬럼 Inventory 생성
• 데이터 타입 호환성 분석
• PK 후보와 증분 기준 컬럼 탐색
• NULL·중복·분포·최댓값 조사
• 테이블 간 의존 관계 분석
• 이관 우선순위 산정

2) 원천과 타깃을 같은 SQL 환경에서 비교할 수 있다

Foreign Table과 Delta Table을 Databricks에서 함께 조회할 수 있으므로 별도 비교 시스템 없이 Row Count, Aggregate, Key Match, Hash를 계산할 수 있다.

3) 데이터 이관과 소비자 전환을 분리할 수 있다

데이터를 먼저 이관해 검증하고, BI·Notebook·API는 별도 Wave로 전환할 수 있다. 반대로 소비자가 신규 플랫폼을 먼저 사용해야 한다면 일시적으로 Foreign Table을 통해 원천 데이터를 제공할 수도 있다.

4) Big Bang 대신 Domain·Schema·Table 단위 전환이 가능하다

각 데이터 도메인은 서로 다른 방식으로 운영할 수 있다.

• 이미 검증된 테이블: Delta로 전환
• 검증 중인 테이블: Federation과 Delta 병행
• 아직 이관하지 않은 테이블: Federation으로 임시 제공
• 장기 저빈도 데이터: Federation 유지

5) Cutover 전 Rollback 경로를 확보할 수 있다

소비자가 Presentation View를 통해 데이터에 접근하도록 설계하면, 문제가 생겼을 때 View의 하위 원천을 Delta에서 Foreign Table로 되돌리는 방식으로 빠르게 Rollback할 수 있다.

---

4. 권장 Target Architecture

flowchart LR
          A["Source · Foreign Catalog"] --> B{"Migration 역할"}
          B -->|즉시 접근| C["Discovery · Validation · Fallback"]
          B -->|물리 이관| D["Snapshot · CDC · Bronze Delta"]
          D --> E["Silver · Gold Data Product"]
          C --> F["Presentation · BI · AI · API"]
          E --> F

이 구조에서 Foreign Catalog는 영구 Bronze Storage가 아니다. 외부 원천에 대한 Governed Access Layer이며, 데이터의 소유권과 재처리 기준을 Databricks로 가져오려면 Bronze Delta가 별도로 필요하다.

각 계층의 책임은 다음과 같다.

• Foreign Catalog: 원천 탐색, 즉시 접근, 비교 검증, 임시 호환
• Bronze Delta: 원천 Snapshot·CDC 보존, 재처리 기준
• Silver: 타입·코드·중복·변경 표준화
• Gold: Fact·Dimension·KPI 데이터 제품
• Presentation View: 소비자 계약과 Cutover Switch

---

5. 단계별 마이그레이션 전략

Phase 0. Assessment와 Migration Wave 설계

연결부터 만들기 전에 테이블을 특성별로 분류해야 한다.

필수 Inventory

항목	확인 내용
규모	Row Count, 저장 크기, 일 증가량
변경 유형	Append, Update, Delete, Full Snapshot
키	PK, Business Key, 중복 가능성
증분 기준	Commit LSN/SCN, 수정 시각, Sequence
SLA	실시간, 시간, 일 단위
이력	현재 상태만 필요한지, 변경 이력이 필요한지
사용량	조회 빈도, 동시 사용자, Dashboard 수
의존성	View, Procedure, ETL, Report, API
보안	개인정보, 접근 그룹, 망 구간
Cutover	중단 가능 시간, Rollback 허용 시간

Migration Wave 예시

1. 소규모 Reference·Master Table
2. 독립적인 Batch Transaction Table
3. 대용량 Append Fact
4. Update·Delete가 많은 CDC Table
5. 다수 View·Procedure가 얽힌 핵심 업무 영역
6. Archive·저빈도 데이터

먼저 쉬운 테이블을 옮기는 것이 아니라, 공통 하위 의존성이 많고 검증 기준이 명확한 테이블부터 옮기면 후속 Wave의 중복 작업을 줄일 수 있다.

Phase 1. Connection과 Foreign Catalog 구성

Connection은 개인 계정이 아닌 전용 Read-only Service Account를 사용하고, 자격 증명은 코드에 평문으로 넣지 않는다.

CREATE CONNECTION erp_prod_conn TYPE postgresql
OPTIONS (
  host 'erp-db.internal.example.com',
  port '5432',
  user secret ('federation-scope', 'erp-read-user'),
  password secret ('federation-scope', 'erp-read-password')
);

외부 Database를 Foreign Catalog로 등록한다.

CREATE FOREIGN CATALOG IF NOT EXISTS erp_prod_fed
USING CONNECTION erp_prod_conn
OPTIONS (
  database 'erp_prod'
);

사용자에게 Connection 자체를 광범위하게 공개하기보다 Foreign Catalog의 필요한 Catalog·Schema·Table에 최소 권한을 부여한다.

GRANT USE CATALOG ON CATALOG erp_prod_fed
TO `migration_engineers`;

GRANT USE SCHEMA ON SCHEMA erp_prod_fed.sales
TO `migration_engineers`;

GRANT SELECT ON TABLE erp_prod_fed.sales.orders
TO `migration_engineers`;

환경과 목적도 분리한다.

• erp_dev_fed, erp_prd_fed: 환경별 분리
• 업무 Domain별 Schema 권한 분리
• Migration 계정과 Ad-hoc 분석 계정 분리
• Source DB에 Read-only Resource Group 또는 Query Timeout 적용

Phase 2. 원천 Profiling과 Schema Mapping

Foreign Catalog를 이용해 데이터 이관 전에 문제를 발견한다.

SELECT
  COUNT(*) AS row_count,
  COUNT(DISTINCT order_id) AS distinct_order_count,
  MIN(updated_at) AS min_updated_at,
  MAX(updated_at) AS max_updated_at,
  SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) AS null_key_count
FROM erp_prod_fed.sales.orders;

특히 다음 항목은 사전에 Mapping Rule을 확정해야 한다.

• NUMBER·DECIMAL Precision과 Scale
• DB별 Timestamp·Timezone 의미
• 빈 문자열과 NULL의 차이
• Fixed-length CHAR의 공백
• 대소문자 구분 Identifier
• Boolean·Binary·LOB 타입
• 날짜 최솟값과 비정상 값
• 원천 Collation과 문자열 비교 규칙
• PK가 없거나 논리적으로 중복되는 행

Query Federation에서는 지원되지 않는 이름이 무시될 수 있고, Table·Schema 이름이 Unity Catalog에서 소문자로 변환된다. 대소문자만 다른 객체가 충돌하지 않는지 Inventory 단계에서 확인해야 한다.

Phase 3. Initial Snapshot과 변경 캡처 시작

가장 중요한 원칙은 Snapshot과 CDC 사이에 공백이 없어야 한다는 것이다.

flowchart LR
          A["기준 Watermark 기록"] --> B["Snapshot · CDC 동시 시작"]
          B --> C["Initial Snapshot을 Bronze에 적재"]
          C --> D["보존된 변경분 순차 적용"]
          D --> E["Current Watermark 추적 완료"]

일반적인 순서는 다음과 같다.

1. 원천의 기준 Watermark 또는 Log Position을 기록한다.
2. 해당 기준과 일관된 Initial Snapshot을 시작한다.
3. Snapshot 진행 중 발생한 변경을 CDC가 보존하도록 한다.
4. Snapshot 완료 후 보존된 변경을 순서대로 적용한다.
5. Target이 Source의 현재 Watermark를 따라잡을 때까지 동기화한다.

Managed CDC Connector를 사용할 수 있다면 Lakeflow Connect가 Snapshot과 변경 로그를 추적해 Delta Streaming Table에 반영하는 방식을 우선 검토한다. 2026년 8월 기준 Managed Database Connector는 MySQL, PostgreSQL, SQL Server, Oracle의 CDC를 지원하며, 세부 제공 상태와 제약은 Connector별 문서를 확인해야 한다.

CDC 인프라를 사용할 수 없고 단일 증가 컬럼이 있다면 Query-based Connector 또는 직접 증분 적재를 검토할 수 있다.

CREATE TABLE IF NOT EXISTS migration_bronze.orders
USING DELTA
AS
SELECT
  *,
  current_timestamp() AS _loaded_at,
  'initial_snapshot' AS _load_type
FROM erp_prod_fed.sales.orders
WHERE 1 = 0;

초기 적재 예시:

INSERT INTO migration_bronze.orders
SELECT
  *,
  current_timestamp() AS _loaded_at,
  'initial_snapshot' AS _load_type
FROM erp_prod_fed.sales.orders
WHERE order_date < DATE '2026-08-25';

수정 시각 기반 증분 적재 예시:

MERGE INTO migration_bronze.orders AS target
USING (
  SELECT
    *,
    current_timestamp() AS _loaded_at,
    'incremental' AS _load_type
  FROM erp_prod_fed.sales.orders
  WHERE updated_at >= TIMESTAMP '2026-08-25 00:00:00'
    AND updated_at <  TIMESTAMP '2026-08-25 01:00:00'
) AS source
ON target.order_id = source.order_id

WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

이 예시는 원리를 보여주기 위한 것이다. Timestamp 기반 방식은 동일 시각 값, 늦은 Commit, Clock Skew, Delete 미탐지 문제가 있으므로 실제 운영에서는 다음 보완이 필요하다.

• 구간을 [start, end) 형태로 고정
• 마지막 성공 Watermark를 별도 Control Table에 기록
• 안전한 Lookback Window 적용
• Business Key로 Idempotent MERGE
• 삭제 감지를 위한 CDC Log 또는 Snapshot 비교
• Source Transaction Timestamp와 Commit 순서 구분

Query-based Connector도 Cursor Column이 단일 컬럼이고 단조 증가해야 하며, NULL Cursor는 적재하지 않는다. 중간 변경 상태를 모두 보존해야 하거나 낮은 지연이 필요하면 CDC Connector가 더 적합하다.

Phase 4. Dual Run과 데이터 검증

Snapshot 적재가 끝났다고 바로 소비자를 전환하면 안 된다. 일정 기간 Source와 Target을 함께 운영하며 검증해야 한다.

Level 1. Schema 검증

• 컬럼 수와 순서
• 데이터 타입·Precision·Scale
• NULL 허용 여부
• Default와 Generated Column
• Table·Column Comment

Level 2. Volume 검증

WITH source_count AS (
  SELECT order_date, COUNT(*) AS cnt
  FROM erp_prod_fed.sales.orders
  GROUP BY order_date
),
target_count AS (
  SELECT order_date, COUNT(*) AS cnt
  FROM migration_bronze.orders
  GROUP BY order_date
)
SELECT
  COALESCE(s.order_date, t.order_date) AS order_date,
  s.cnt AS source_count,
  t.cnt AS target_count,
  COALESCE(t.cnt, 0) - COALESCE(s.cnt, 0) AS count_diff
FROM source_count s
FULL OUTER JOIN target_count t
  ON s.order_date = t.order_date
WHERE COALESCE(s.cnt, 0) <> COALESCE(t.cnt, 0);

Level 3. Business Aggregate 검증

• 일자·공장·법인별 Row Count
• 금액 합계·평균·최솟값·최댓값
• Distinct Business Key 수
• 상태 코드별 분포
• NULL과 중복 건수

Level 4. Row-level 검증

WITH source_data AS (
  SELECT
    order_id,
    xxhash64(
      customer_id,
      CAST(order_date AS STRING),
      CAST(amount AS STRING),
      status
    ) AS row_hash
  FROM erp_prod_fed.sales.orders
),
target_data AS (
  SELECT
    order_id,
    xxhash64(
      customer_id,
      CAST(order_date AS STRING),
      CAST(amount AS STRING),
      status
    ) AS row_hash
  FROM migration_bronze.orders
)
SELECT
  COALESCE(s.order_id, t.order_id) AS order_id,
  s.row_hash AS source_hash,
  t.row_hash AS target_hash
FROM source_data s
FULL OUTER JOIN target_data t
  ON s.order_id = t.order_id
WHERE NOT (s.row_hash <=> t.row_hash)
   OR s.order_id IS NULL
   OR t.order_id IS NULL;

Hash 비교는 빠른 이상 탐지 수단이지만 충돌 가능성과 표현 차이가 있으므로 핵심 테이블에서는 Key 기반 Row 비교와 Business Aggregate를 함께 사용해야 한다. Decimal Scale, Timestamp Precision, NULL, 공백을 동일한 Canonical Format으로 변환한 뒤 Hash해야 한다.

Level 5. Consumer Query 검증

테이블이 같아도 기존 Report의 결과가 같다는 보장은 없다. 기존 SQL과 변환된 Databricks SQL을 같은 기준 시점에서 실행하고 다음을 비교한다.

• Dashboard KPI
• 마감 보고서
• 정산·회계 결과
• 업무 Rule 적용 건수
• 조회 성능과 동시성

Phase 5. Consumer Cutover

소비자가 Physical Table을 직접 참조하면 전환과 Rollback이 어렵다. Presentation View를 안정적인 계약으로 사용한다.

전환 전:

CREATE OR REPLACE VIEW presentation.sales_orders AS
SELECT
  order_id,
  customer_id,
  order_date,
  amount,
  status
FROM erp_prod_fed.sales.orders;

전환 후:

CREATE OR REPLACE VIEW presentation.sales_orders AS
SELECT
  order_id,
  customer_id,
  order_date,
  amount,
  status
FROM analytics_silver.sales_orders;

소비자는 동일한 View를 계속 사용하고, 내부 원천만 Foreign Table에서 Delta Table로 바뀐다. Schema, 데이터 타입, 컬럼 의미를 동일하게 유지하면 BI·API 변경을 최소화할 수 있다.

Phase 6. Stabilization과 Federation 축소

Cutover 후 즉시 원천과 Federation을 제거하지 않는다. 정해진 안정화 기간 동안 다음을 확인한다.

• CDC Lag과 누락
• Dashboard 결과 차이
• Target Query 성능
• Source DB 부하 감소
• 장애와 재처리 절차
• 사용자별 미전환 Query

안정화가 끝나면 세 가지로 분류한다.

1. Retire: Delta 전환이 완료된 원천 접근 제거
2. Restricted Fallback: 운영팀만 사용할 수 있는 Rollback 경로 유지
3. Long-term Federation: 저빈도·소규모·실시간 참조 데이터만 제한적으로 유지

Federation을 계속 남긴다면 목적, Owner, SLA, Cost Center, 종료 검토일을 Metadata와 운영 문서에 명시한다. 임시 연결이 영구 Shadow Architecture로 남지 않게 해야 한다.

---

6. 어떤 데이터를 Federation으로 남길 수 있는가?

판단 기준	Federation 유지 가능	Delta 물리화 권장
조회 빈도	낮음	높음
데이터량	작음	큼
SLA	원천 성능에 종속 가능	일정한 응답 시간 필요
원천 부하	여유 있음	운영 DB 보호 필요
장애 격리	불필요	필요
이력·재처리	원천 보존으로 충분	자체 보존 필요
Write·Merge	불필요	필요
다수 소비자	제한적	광범위
Cross-source Join	드묾	반복적·대규모
규제·Residency	이동 제한	Databricks 저장 허용
사용 기간	임시	장기 핵심 데이터 제품

Federation 유지가 합리적인 예

• 월 1회 조회하는 소규모 Reference Table
• 원천의 최신 상태를 반드시 즉시 확인해야 하는 운영 조회
• 데이터 이동이 규제로 제한된 영역
• 이관 대상 여부를 검토하는 PoC Table
• Unity Catalog 전환 중인 외부 Catalog의 임시 접근
• 장기 Archive 중 실제 조회 확률이 매우 낮은 데이터

Delta 물리화가 필요한 예

• 많은 Dashboard가 반복 조회하는 Transaction Table
• 대규모 Join·Aggregate의 공통 원천
• 원천 운영 DB의 CPU와 Connection을 보호해야 하는 데이터
• SCD Type 2와 감사 이력이 필요한 Master
• 원천 삭제 이후에도 보존해야 하는 데이터
• AI·ML Feature와 장기 학습 데이터
• 원천 장애 중에도 제공해야 하는 핵심 데이터 제품

---

7. Query Federation 성능 전략

Federation 성능은 Databricks Warehouse 크기만 키운다고 해결되지 않는다. 원격 DB, 네트워크, Pushdown, 결과 크기가 함께 영향을 준다.

1) 원천에서 최대한 줄이고 가져온다

SELECT
  plant_code,
  order_date,
  SUM(amount) AS daily_amount
FROM erp_prod_fed.sales.orders
WHERE order_date >= current_date() - INTERVAL 7 DAYS
GROUP BY plant_code, order_date;

SELECT *로 전체 데이터를 가져온 뒤 Databricks에서 Filter하지 않도록 한다. Projection, Predicate, Aggregate가 원천에 Pushdown되는지 확인한다.

2) 실행된 원격 SQL을 확인한다

EXPLAIN FORMATTED
SELECT
  plant_code,
  SUM(amount) AS total_amount
FROM erp_prod_fed.sales.orders
WHERE order_date >= DATE '2026-08-01'
GROUP BY plant_code;

Query Profile의 Foreign Data Source Scan Node에서도 시스템이 생성한 원격 SQL을 확인할 수 있다. Pushdown 지원 범위는 원천별로 다르므로 추측하지 말고 실행 계획을 검증한다.

3) 대규모 Cross-source Join을 Serving Query로 사용하지 않는다

대형 Oracle Table과 대형 Delta Table을 매 Dashboard 조회마다 Join하면 원천 결과 전송량과 응답 편차가 커진다. 반복되는 Join은 필요한 원천 데이터를 Delta로 적재한 뒤 로컬에서 수행한다.

4) Result Cache를 전제로 설계하지 않는다

Databricks의 Result Cache와 Disk Cache는 Federated Query에 지원되지 않는다. 첫 실행만 느리고 이후에는 빨라질 것이라는 가정으로 SLA를 설계하면 안 된다.

5) 큰 결과 전송을 피한다

Query Federation은 Foreign Table별 원격 Subquery 결과를 단일 Stream으로 Databricks Executor Task에 반환할 수 있다. 결과가 지나치게 크면 Memory 문제가 발생할 수 있으므로 대용량 Full Extract의 기본 수단으로 사용하지 않는다.

6) 원천 보호 장치를 둔다

• Read-only 계정
• Query Timeout
• Resource Group·Warehouse 분리
• Connection·동시 실행 제한
• 업무 Peak Time 회피
• Source CPU, I/O, Connection 모니터링

---

8. Materialized View를 Migration 적재 수단으로 써도 될까?

Foreign Table을 원천으로 Materialized View를 생성할 수 있다.

CREATE OR REPLACE MATERIALIZED VIEW migration_silver.mv_product_master
SCHEDULE EVERY 1 DAY
AS
SELECT
  product_id,
  product_name,
  category,
  updated_at
FROM erp_prod_fed.master.product;

소규모 Master나 하루 한 번 Snapshot이면 간단하고 효과적이다. 그러나 Foreign Catalog는 Materialized View의 증분 새로고침 지원 원천이 아니다. 따라서 Full Recompute가 발생해도 감당 가능한 데이터에만 사용해야 한다.

상황	MV 적합성
소규모 전체 Snapshot	적합
하루 1회 Reference 동기화	적합
대규모 Transaction	부적합
한 번만 처리해야 하는 이벤트	부적합
Delete·순서가 중요한 CDC	부적합
원천이 과거 데이터를 삭제	주의 필요

MV는 편리한 Snapshot·Transformation 도구이지, 대용량 CDC Migration Engine은 아니다.

---

9. Catalog Federation을 이용한 Unity Catalog 점진 전환

기존 Hive Metastore나 AWS Glue에 등록된 데이터는 관계형 DB와 상황이 다르다. 실제 파일이 이미 Object Storage에 있으므로 데이터를 다시 복사하기보다 Catalog와 Governance를 전환하는 것이 핵심일 수 있다.

Catalog Federation의 일반적인 전략은 다음과 같다.

1. 외부 Catalog와 Storage 접근 경로를 Unity Catalog에 연결한다.
2. Foreign Catalog를 통해 기존 Table을 Unity Catalog 권한으로 조회한다.
3. 신규 Workload부터 Unity Catalog 기반으로 전환한다.
4. 기존 Workload를 Schema·Domain 단위로 점진 전환한다.
5. Table Ownership과 관리 주체를 Unity Catalog로 이동한다.
6. 외부 Catalog 의존성이 사라진 영역부터 Federation을 종료한다.

Catalog Federation은 Query Federation보다 Migration Path 자체에 더 가까운 기능이다. 데이터 파일을 옮기지 않고 Governance Layer를 먼저 Unity Catalog로 전환할 수 있기 때문이다.

다만 다음은 반드시 확인해야 한다.

• Authorized Path와 Storage Credential 범위
• 외부 Catalog Metadata 변경 권한
• Table Format과 Runtime 호환성
• Schema Evolution과 Partition Metadata 갱신
• 외부 Engine이 동시에 Metadata를 변경할 때의 책임
• Foreign Catalog 종료 후 최종 Ownership

Authorized Path는 외부 Metastore 사용자가 Table Location을 임의 변경해 Unity Catalog 권한을 우회하지 못하도록 제한하는 보안 Guardrail이다. 필요한 공통 상위 경로만 허용하고, 지나치게 넓은 Bucket 전체 권한은 피한다.

---

10. Metadata Refresh 전략

Foreign Catalog Metadata는 상호작용 시 자동으로 갱신되지만, 대규모 마이그레이션에서는 다음 상황에 수동 갱신이 유용하다.

• 첫 조회 전에 Catalog Metadata를 미리 준비해야 할 때
• 외부 Engine에서 Schema가 변경됐을 때
• Migration Inventory를 일정 기준 시점으로 맞춰야 할 때
• 조회 시 Metadata Refresh 지연을 피하고 싶을 때

REFRESH FOREIGN CATALOG erp_prod_fed;

REFRESH FOREIGN SCHEMA erp_prod_fed.sales;

REFRESH FOREIGN TABLE erp_prod_fed.sales.orders;

Metadata Refresh는 데이터 적재나 CDC가 아니다. 외부 Table의 정의와 최신 Metadata를 Unity Catalog에 반영하는 작업이다.

---

11. Cutover와 Rollback Runbook

flowchart LR
          A["Cutover Readiness"] --> B{"Snapshot · CDC · Validation 통과?"}
          B -->|아니오| C["Cutover 보류"]
          B -->|예| D["Presentation View 전환"]
          D --> E{"KPI · Lag · SLA 정상?"}
          E -->|예| F["Stabilization"]
          E -->|아니오| G["Rollback · 재처리 · 재검증"]
          G --> A

Cutover 전 조건

• Initial Snapshot 완료
• CDC Lag이 허용 SLA 이내
• 핵심 검증 Rule 100% 통과
• 미해결 데이터 차이에 Owner와 처리 계획 존재
• Consumer별 전환 대상 목록 확정
• 권한과 Service Principal 검증
• Target 성능·동시성 테스트 완료
• Rollback 실행 시간 측정

Cutover 절차

1. 변경 공지와 Freeze 범위를 확정한다.
2. Source 최종 Watermark를 기록한다.
3. CDC가 해당 Watermark까지 반영됐는지 확인한다.
4. 최종 Reconciliation을 실행한다.
5. Presentation View 또는 Consumer Connection을 Target으로 전환한다.
6. 핵심 Dashboard와 API Smoke Test를 수행한다.
7. Source와 Target의 지표를 집중 모니터링한다.

Rollback 조건

• 핵심 KPI 불일치
• 허용치를 초과한 CDC Lag
• Target 성능 SLA 미달
• 권한 누락으로 핵심 업무 중단
• 복구 불가능한 Data Quality 오류

Rollback 절차

1. 추가 Target Write 또는 Consumer 변경을 중지한다.
2. Presentation View를 Foreign Table 또는 기존 Source 경로로 복구한다.
3. 실패 시점과 Watermark를 고정한다.
4. Target 오류 범위를 분석하고 재처리한다.
5. 재검증 후 새로운 Cutover Window를 잡는다.

Rollback 기간 동안 Source가 계속 System of Record인지, 신규 Target에서 발생한 Write-back이 있는지 명확히 해야 한다. 양쪽 시스템에서 동시에 Write가 발생하면 단순 View 전환으로 복구할 수 없다.

---

12. 보안과 네트워크 전략

Connection 보안

• 개인 계정 대신 전용 Read-only Service Account 사용
• Secret 또는 지원되는 OAuth 방식 사용
• Connection Owner를 개인이 아닌 운영 그룹으로 설정
• Migration, BI, Ad-hoc 목적별 계정과 권한 분리
• 최소 Table·Schema 단위 SELECT 부여

네트워크

Databricks Compute에서 외부 Database로의 네트워크 연결이 필요하다. 보안과 안정성을 위해 가능한 경우 Private Connectivity를 우선 검토한다.

• VPN, Direct Connect, Peering, Private Endpoint 등 환경별 연결 방식 검토
• Serverless와 Classic Compute의 네트워크 경로 차이 확인
• Firewall·Security Group·NACL·Route Table 검증
• DNS와 TLS 인증서 검증
• Source Allowlist 자동화
• Connection Timeout과 재시도 기준 정의

Unity Catalog Connection은 자격 증명과 연결 설정을 관리하지만, Network Traffic을 제한하는 방화벽 역할을 대신하지 않는다. Connection 권한과 Network Policy를 별도로 설계해야 한다.

데이터 거버넌스

• Foreign Catalog에도 Owner, Domain, 민감도 Tag 부여
• 원천과 Delta Target 간 Lineage 확인
• Foreign Table 직접 접근 그룹 최소화
• 최종 사용자는 Presentation 또는 Silver·Gold만 접근
• 이관 완료 Table의 Foreign 권한 회수

---

13. 운영 모니터링 지표

영역	핵심 지표
Migration Progress	전체·이관·검증·Cutover 완료 Table 수
Data Freshness	Source Watermark와 Target Watermark 차이
Data Quality	Count·Hash·Aggregate 불일치 수
CDC	Lag, 처리량, 재시도, Delete 반영 건수
Federation	쿼리 수, p95 응답 시간, 전송 Row·Bytes
Source Impact	CPU, I/O, Connection, Lock, Query Time
Target	적재 시간, Query SLA, 비용, Storage 증가량
Consumer	미전환 Query·Dashboard·API 수
Reliability	실패율, MTTR, Rollback 실행 시간

Migration Dashboard에는 “몇 TB를 옮겼는가”보다 다음 질문에 답할 수 있어야 한다.

• 이 테이블은 누가 검증했는가?
• 마지막 검증 시점과 Watermark는 무엇인가?
• 어떤 Consumer가 아직 원천을 사용하는가?
• Cutover가 실패하면 몇 분 안에 어디로 되돌리는가?
• Federation을 언제 종료할 것인가?

---

14. 자주 발생하는 안티패턴

안티패턴 1. Foreign Catalog를 만들고 마이그레이션이 끝났다고 판단한다

데이터는 여전히 원천에 있고 장애·성능·보존 정책에도 종속된다.

개선: Federation은 임시 접근과 검증 계층으로 정의하고, 중요 데이터는 Delta 물리화 계획을 별도로 수립한다.

안티패턴 2. 모든 원천 테이블을 한 번에 Foreign Catalog로 공개한다

운영 DB에 예상하지 못한 Ad-hoc Query가 몰릴 수 있다.

개선: Schema·Table 권한을 최소화하고 원천 Resource Group과 Query Timeout을 설정한다.

안티패턴 3. Federation Query를 대용량 Full Extract 수단으로 사용한다

원격 결과 전송, 단일 Stream, Memory와 원천 부하 문제가 생길 수 있다.

개선: Managed CDC, Query-based Ingestion, 병렬 JDBC, 파일 Export 등 데이터량에 맞는 Ingestion 경로를 사용한다.

안티패턴 4. updated_at만 있으면 CDC가 완성된다고 생각한다

Delete, 동일 Timestamp, 늦은 Commit, Clock Skew를 놓칠 수 있다.

개선: 가능하면 Database Log 기반 CDC를 사용하고, Timestamp 방식에는 Lookback·Idempotent Merge·삭제 감지를 추가한다.

안티패턴 5. Row Count만 같으면 검증이 끝났다고 판단한다

같은 건수 안에서 값이 바뀌거나 서로 다른 행이 빠질 수 있다.

개선: Schema, Count, Business Aggregate, Hash, Row-level, Consumer Query를 계층적으로 검증한다.

안티패턴 6. Consumer가 Foreign Table과 Delta Table을 직접 참조한다

Cutover와 Rollback 시 모든 Notebook과 Dashboard를 수정해야 한다.

개선: 안정적인 Presentation View 또는 Semantic Contract를 둔다.

안티패턴 7. 임시 Federation을 종료 기준 없이 유지한다

원천과 Target을 모두 운영하는 이중 비용과 Shadow Data Path가 남는다.

개선: Owner, 사용 목적, 종료 검토일, 허용 SLA를 Metadata에 기록한다.

---

15. 실무 시나리오별 전략

Oracle·SAP 운영 DB에서 Databricks로 전환

flowchart LR
          A["Oracle · SAP"] --> B["Query Federation"]
          A --> C["CDC · Incremental Ingestion"]
          B --> D["Profiling · Validation · Fallback"]
          C --> E["Bronze Delta"]
          E --> F["Silver Standard"]
          F --> G["Gold Data Product"]

• 소규모 Master: MV 또는 주기적 Snapshot
• 대용량 Transaction: Log 기반 CDC
• 수정 시각만 존재: Query-based 또는 Window MERGE + Lookback
• 실시간 운영 조회: 제한적인 Federation 유지 가능
• 반복 분석·BI: Delta로 전환

기존 Data Warehouse에서 Databricks로 전환

• Foreign Catalog로 기존 Table과 View를 탐색한다.
• 중요 Table부터 Delta로 Backfill한다.
• 변경분을 CDC 또는 Cursor 방식으로 동기화한다.
• 동일 SQL의 원천·Target 결과를 병행 비교한다.
• Dashboard는 Presentation View를 통해 Wave별 전환한다.
• 저빈도 Archive는 비용과 규제 조건에 따라 Federation 유지 여부를 결정한다.

Hive Metastore·Glue에서 Unity Catalog로 전환

• Catalog Federation으로 기존 Storage를 그대로 조회한다.
• Authorized Path로 접근 범위를 제한한다.
• 신규 Workload를 Unity Catalog 기반으로 먼저 전환한다.
• Domain 단위로 Table Ownership과 Metadata 관리를 이관한다.
• 기존 Catalog의 Write와 Metadata 변경을 단계적으로 중단한다.

---

16. 최종 체크리스트

설계

• Query Federation과 Catalog Federation 중 원천에 맞는 방식을 선택했는가?
• Federation의 종료 또는 장기 유지 기준이 있는가?
• Table별 Snapshot·CDC·Query-based 적재 전략이 정해졌는가?
• Source of Record와 Write Owner가 명확한가?

데이터

• PK·Business Key·Delete 처리 방식을 정의했는가?
• Snapshot과 CDC 사이의 Gap을 막았는가?
• Timestamp·Decimal·NULL·공백 변환 규칙이 있는가?
• Schema·Count·Aggregate·Row 검증을 자동화했는가?

성능

• Predicate와 Aggregate Pushdown을 확인했는가?
• 대규모 Cross-source Join을 제거했는가?
• Source CPU·Connection 보호 장치가 있는가?
• Federation Result Cache를 전제로 하지 않았는가?

보안

• Read-only Service Account를 사용하는가?
• Secret을 코드에 평문으로 저장하지 않았는가?
• Private Network와 Firewall 정책을 검증했는가?
• Foreign Catalog 접근을 최소 권한으로 제한했는가?

Cutover

• Presentation View 또는 논리 계약 계층이 있는가?
• 최종 Watermark와 검증 승인 기준이 있는가?
• Rollback 조건·담당자·실행 시간을 정의했는가?
• 안정화 기간 이후 Foreign 접근 회수 계획이 있는가?

---

17. 결론

Lakehouse Federation의 가장 큰 가치는 데이터를 옮기지 않는 데 있지 않다. 데이터를 옮기기 전에도 신규 플랫폼에서 원천을 이해하고, 옮기는 동안 원천과 Target을 비교하고, 옮긴 후에는 소비자를 안전하게 전환할 수 있다는 점에 있다.

성공적인 마이그레이션에서는 Federation이 다음 순서로 역할을 바꾼다.

Discovery → Temporary Access → Validation → Cutover Fallback → Restricted or Retired

반면 Delta Ingestion은 다음 책임을 가져간다.

Snapshot → CDC → History → Reprocessing → Stable Serving

따라서 가장 실용적인 전략은 다음 한 문장으로 정리할 수 있다.

Federation으로 빠르게 연결하고 검증하되, 반복 분석과 핵심 데이터 제품은 Delta로 물리화하고, Presentation 계층을 통해 단계적으로 Cutover한다.

Federation을 어디에 사용할지보다 더 중요한 질문은 언제 제거할지다. 임시 Bridge와 장기 Architecture를 구분할 수 있을 때 Lakehouse Federation은 Big Bang Migration의 위험을 줄이는 강력한 전환 도구가 된다.

---

참고 문서

• Connect to external databases and catalogs
• What is query federation?
• What is catalog federation?
• Manage and work with foreign catalogs
• Networking recommendations for Lakehouse Federation
• Lakehouse Federation performance recommendations
• Managed database connectors
• Query-based connectors
• Query-based connector limitations
• Unity Catalog connections
• Incremental refresh for materialized views