데이터 플랫폼을 운영하다 보면 “외부 DB에 있는 데이터를 꼭 다 적재해야만 분석할 수 있을까?”라는 질문을 자주 하게 됩니다. 이때 Databricks의 Lakehouse Federation은 데이터를 대규모로 복제하지 않고도 외부 데이터 소스를 조회할 수 있게 해주는 선택지입니다. 반면 JDBC 연결은 훨씬 더 낮은 수준의 연결 방식으로, 애플리케이션이나 도구가 데이터베이스 혹은 Databricks에 직접 붙기 위한 표준 인터페이스에 가깝습니다. Databricks 공식 문서에 따르면 Lakehouse Federation은 여러 외부 데이터 소스를 대상으로 쿼리를 실행할 수 있게 해주는 federation 플랫폼이며, query federation의 경우 내부적으로 JDBC API를 활용해 원격 DB로 쿼리를 푸시다운합니다. 즉, Lakehouse Federation은 “제품/플랫폼 기능”이고, JDBC는 그 아래에서 활용될 수 있는 “연결 기술”이라고 보는 것이 핵심입니다. Source Source
이미지: Databricks Query Federation overview diagram Databricks Documentation
Databricks Lakehouse Federation란?
Lakehouse Federation은 Databricks에서 제공하는 query federation 플랫폼입니다. 쉽게 말해, MySQL, PostgreSQL, Oracle, SQL Server, Redshift, Snowflake, BigQuery 같은 외부 시스템에 있는 데이터를 Databricks에서 마치 카탈로그에 연결된 데이터처럼 조회할 수 있게 해줍니다. 모든 데이터를 Delta Lake로 옮겨 담지 않아도 되기 때문에, 운영계 데이터나 외부 플랫폼 데이터를 빠르게 탐색하거나 POC를 진행할 때 특히 유용합니다. Source
Databricks는 Lakehouse Federation을 크게 Query Federation과 Catalog Federation으로 구분합니다. Query Federation은 Unity Catalog 쿼리를 외부 데이터베이스로 푸시다운하고, 실제 실행은 Databricks와 원격 시스템 양쪽에서 일어납니다. 반면 Catalog Federation은 외부 카탈로그와 오브젝트 스토리지에 직접 접근하는 방식이라 쿼리가 Databricks compute 쪽에서만 실행되며, Databricks 문서상 일반적으로 Query Federation보다 비용 효율성과 성능 측면에서 유리할 수 있습니다. Source
실무적으로 보면 Lakehouse Federation의 장점은 단순 조회를 넘어서 Unity Catalog 기반 거버넌스와 결합된다는 점입니다. 외부 시스템 연결 정보를 connection 객체로 관리하고, 외부 DB를 Databricks 내부에 비춘 듯한 foreign catalog로 노출한 뒤, Unity Catalog 권한 모델로 접근 제어를 할 수 있습니다. 즉 “외부 데이터를 읽어오는 기술”이라기보다, 외부 데이터에 대한 Databricks식 관리 계층이라고 이해하는 편이 더 정확합니다. Source
Lakehouse Federation은 어떻게 동작할까?
Databricks 공식 설명에 따르면 Query Federation은 외부 시스템 접근 경로와 자격 증명을 담은 connection과, 외부 데이터베이스를 반영한 foreign catalog를 기반으로 동작합니다. 사용자가 Databricks SQL로 쿼리를 실행하면 Databricks는 이를 외부 데이터 소스가 이해할 수 있는 형태로 변환해 가능한 부분을 pushdown하고, 나머지 처리는 Databricks runtime이 맡습니다. 그래서 Federation은 “그냥 원격 테이블을 읽는다”가 아니라, 어디까지 원격 DB에 맡기고 어디부터 Databricks가 처리할지 최적화하는 계층이라고 볼 수 있습니다. Source
이 과정은 EXPLAIN FORMATTED나 Query Profile을 통해 어느 정도 확인할 수 있습니다. Databricks는 문서에서 어떤 SQL이 원격 데이터베이스로 전달되는지 확인할 수 있다고 안내하고 있으며, 필터나 조인 같은 연산이 얼마나 푸시다운되는지가 성능에 큰 영향을 준다고 설명합니다. 즉 Federation의 핵심은 “연결 성공” 자체보다 푸시다운 품질에 있습니다. Source Source
JDBC 연결과는 무엇이 다를까?
많이 헷갈리는 지점이 바로 여기입니다. Databricks 공식 JDBC 문서에서 말하는 Databricks JDBC Driver는 DataGrip, DBeaver, SQL Workbench/J 같은 도구나 애플리케이션이 Databricks에 접속하기 위한 드라이버입니다. 즉 이 경우 JDBC의 방향은 외부 클라이언트 → Databricks입니다. Source
반면 Lakehouse Federation의 Query Federation은 Databricks가 외부 데이터 소스에 쿼리를 푸시다운할 때 JDBC API를 사용할 수 있는 구조입니다. 즉 이 경우의 방향은 Databricks → 외부 DB입니다. 그래서 이름만 보고 “둘 다 JDBC 아닌가?”라고 생각하기 쉽지만, 실제로는 사용 목적도 다르고, 아키텍처 레벨도 다릅니다. JDBC는 연결 표준이고, Lakehouse Federation은 그 연결을 포함해 카탈로그화·권한관리·쿼리 푸시다운까지 감싼 상위 기능입니다. Source Source
한 줄 요약:
JDBC는 ‘접속 방식’이고, Lakehouse Federation은 ‘Databricks가 외부 데이터를 다루는 운영 모델’입니다. Source Source
한눈에 보는 차이점
| 항목 | Lakehouse Federation | JDBC 직접 연결 |
|---|---|---|
| 성격 | Databricks의 상위 플랫폼 기능 | 범용 데이터베이스 연결 표준 |
| 주 목적 | 외부 데이터를 Unity Catalog 아래에서 조회·거버넌스 | 애플리케이션/도구가 DB 또는 Databricks에 직접 접속 |
| 관리 단위 | connection, foreign catalog, 권한 | URL, 드라이버, 계정, 코드/도구 설정 |
| 거버넌스 | Unity Catalog와 긴밀히 연동 | 별도 구현 필요 |
| 사용자 경험 | SQL/카탈로그 중심 | 드라이버/속성/세션 중심 |
| 쿼리 최적화 | pushdown, 일부 조인 pushdown, 병렬 읽기 옵션 | 구현 방식에 따라 다름 |
| 적합한 상황 | 외부 운영 DB를 빠르게 분석에 연결, 데이터 이동 최소화 | 앱 개발, BI 툴 연결, 세밀한 제어가 필요한 직접 통신 |
| 핵심 한계 | 대체로 read-only, 캐시 제약, pushdown 한계 존재 | 거버넌스/카탈로그/권한 모델을 스스로 구성해야 함 |
위 표는 Databricks의 Lakehouse Federation 문서와 JDBC 드라이버 문서를 바탕으로 실무 관점에서 재정리한 것입니다. 특히 Federation은 관리형 데이터 접근 계층, JDBC는 연결용 인터페이스라는 차이를 이해하면 대부분의 혼동이 사라집니다. Source Source Source
JDBC가 있는데 왜 굳이 Federation이 필요할까?
직접 JDBC로 붙는 방식은 유연하지만, 연결 정보 관리, 권한 설계, 카탈로그 노출, 사용자별 접근 제어 같은 운영 문제를 별도로 풀어야 합니다. 반면 Lakehouse Federation은 외부 데이터를 Unity Catalog의 보안/권한 체계 안으로 편입시키기 때문에, 분석가나 데이터 엔지니어 입장에서는 훨씬 일관된 경험을 제공합니다. 즉 개발자가 코드 안에서 JDBC URL과 계정을 들고 다니는 방식보다, 플랫폼 팀이 중앙에서 connection과 foreign catalog를 관리하는 구조에 더 가깝습니다. Source
또한 Databricks는 Query Federation이 특히 애드혹 분석, POC, 운영계 데이터에 대한 라이브 접근, 데이터 이동 최소화에 적합하다고 설명합니다. 다만 데이터 양이 크고 더 낮은 지연시간이나 높은 성능이 중요하다면, Databricks는 일부 소스에 대해 Lakeflow Connect 같은 적재/동기화 기반 접근을 권장하기도 합니다. 다시 말해 Federation은 “모든 상황의 정답”이라기보다, 데이터를 옮기지 않고 빠르게 연결해야 할 때 강한 전략입니다. Source
이미지: JDBC connectivity diagram Oracle
성능과 한계도 꼭 알아야 한다
Lakehouse Federation은 편리하지만 만능은 아닙니다. Databricks 문서에 따르면 Federated Query는 일반적으로 read-only이며, Result Cache와 Disk Cache를 지원하지 않고, Unity Catalog에 맞지 않는 이름의 스키마/테이블은 무시될 수 있습니다. 또한 테이블/스키마 이름이 소문자로 변환되는 제약, 큰 결과 집합을 읽을 때 메모리 이슈가 발생할 수 있는 점도 주의해야 합니다. Source
성능은 특히 푸시다운 가능 여부에 크게 좌우됩니다. Databricks는 ILIKE처럼 소스 DB에 그대로 번역되지 않는 조건은 원격으로 내려보내지 못할 수 있다고 설명하며, 반대로 AND로 결합된 다른 조건은 일부라도 푸시다운될 수 있다고 안내합니다. 또한 fetchSize, numPartitions, partitionColumn, lowerBound, upperBound 같은 파라미터를 통해 배치 읽기와 병렬 읽기를 조정할 수 있고, 일부 소스에서는 조인 푸시다운도 지원합니다. 즉 Federation을 잘 쓰려면 “연결만 해두면 끝”이 아니라 어떤 SQL이 실제로 원격 DB까지 내려가는지 확인하는 습관이 중요합니다. Source
언제 Lakehouse Federation을 쓰고, 언제 JDBC를 쓸까?
외부 데이터베이스를 Databricks 분석 환경 안으로 자연스럽게 끌어와서, Unity Catalog 권한 체계로 관리하면서 SQL로 조회하고 싶다면 Lakehouse Federation이 잘 맞습니다. 특히 데이터 이동을 최소화하면서 운영 데이터를 빠르게 분석해야 하는 경우에 좋습니다. Source Source
반대로 애플리케이션이 Databricks에 직접 접속해야 하거나, BI 도구가 Databricks SQL Warehouse에 붙어야 하거나, 혹은 아주 세밀한 연결 제어가 필요한 상황이라면 JDBC가 더 직접적인 선택입니다. Databricks JDBC Driver는 바로 이런 목적으로 제공됩니다. Source
마무리
정리하면, Lakehouse Federation은 JDBC의 경쟁자가 아니라 JDBC를 포함할 수 있는 상위 개념입니다. JDBC가 “어떻게 연결할까?”에 대한 답이라면, Lakehouse Federation은 “외부 데이터를 Databricks 안에서 어떻게 관리 가능하게 사용할까?”에 대한 답입니다. 그래서 둘의 차이를 물을 때는 기술 스택의 같은 층위를 비교하는 것이 아니라, 연결 기술과 데이터 운영 모델을 비교하고 있다는 점을 먼저 이해하는 것이 중요합니다. Source Source
참고 자료
-
Databricks: What is Lakehouse Federation?
https://docs.databricks.com/aws/en/query-federation/ -
Databricks: What is query federation?
https://docs.databricks.com/aws/en/query-federation/database-federation -
Databricks: Lakehouse Federation performance recommendations
https://docs.databricks.com/aws/en/query-federation/performance-recommendations -
Databricks: JDBC Driver (Simba)
https://docs.databricks.com/aws/en/integrations/jdbc/
