Skip to main content
이 문서는 레이크하우스 아키텍처 섹션의 일부입니다.

왜 테이블 유형을 이해해야 하나요?

Databricks에서 테이블을 생성할 때, 데이터가 어디에 저장되고, 누가 관리하는지 에 따라 테이블 유형이 달라집니다. 잘못된 유형을 선택하면 데이터를 의도치 않게 삭제하거나, 반대로 불필요한 데이터가 영원히 남을 수 있습니다. 이 문서에서는 세 가지 테이블 유형의 차이점과 선택 기준을 자세히 살펴보겠습니다.

테이블 유형 한눈에 비교


Managed Table (관리형 테이블)

개념

💡 Managed Table(관리형 테이블) 은 Unity Catalog가 데이터의 저장 위치와 생명주기를 모두 관리 하는 테이블입니다. 테이블을 삭제(DROP)하면 데이터 파일까지 함께 삭제됩니다.
마치 회사 소유 창고 에 물건을 보관하는 것과 같습니다. 창고를 해체하면 안에 있는 물건도 모두 처분됩니다.

생성 방법

데이터 저장 위치

Managed Table의 데이터는 카탈로그 또는 스키마에 설정된 Managed Storage Location 에 자동 저장됩니다.

특징

  • Predictive Optimization 자동 적용 가능 (OPTIMIZE, VACUUM 자동화)
  • Unity Catalog의 거버넌스 기능을 100% 활용 가능
  • 데이터 생명주기를 Unity Catalog가 완전히 관리
  • 신규 프로젝트에서 권장되는 기본 유형

External Table (외부 테이블)

개념

💡 External Table(외부 테이블) 은 사용자가 지정한 클라우드 스토리지 경로에 데이터가 저장되는 테이블입니다. Unity Catalog는 메타데이터만 관리하며, 테이블을 삭제해도 실제 데이터 파일은 그대로 남습니다.
마치 외부 임대 창고 에 물건을 보관하는 것과 같습니다. Unity Catalog 등록을 해제해도 창고의 물건은 그대로입니다.

생성 방법

External Location 설정

외부 테이블을 생성하려면, 해당 스토리지 경로가 Unity Catalog의 External Location 으로 등록되어 있어야 합니다.

특징

  • 테이블 삭제 시 데이터가 보존 되므로 안전합니다
  • 여러 플랫폼에서 동일한 데이터에 접근 해야 할 때 유용합니다
  • Delta 외에 Parquet, CSV, JSON 등 다양한 포맷을 지원합니다
  • Predictive Optimization이 지원되지 않으므로 OPTIMIZE/VACUUM을 수동으로 관리 해야 합니다

Foreign Table (외래 테이블)

개념

💡 Foreign Table(외래 테이블)Lakehouse Federation 을 통해 외부 데이터베이스(MySQL, PostgreSQL, Snowflake 등)의 테이블을 Databricks에서 직접 조회할 수 있게 하는 테이블입니다. 데이터를 복사하지 않고 원본 시스템에 쿼리를 전달 합니다.
💡 Lakehouse Federation이란? 외부 데이터 소스에 저장된 데이터를 Databricks로 복사하지 않고도, Unity Catalog를 통해 거버넌스를 유지하면서 직접 조회할 수 있는 기능입니다.

생성 방법

지원하는 외부 소스

특징

  • 데이터 복사 없이 실시간으로 외부 데이터를 조회 합니다
  • Unity Catalog의 접근 제어(GRANT/REVOKE) 가 그대로 적용됩니다
  • 대량 데이터 조회 시에는 네트워크 지연이 발생할 수 있어, 필요한 데이터만 선별적으로 조회 하는 것이 좋습니다
  • 읽기 전용(SELECT)만 가능하며, INSERT/UPDATE/DELETE는 지원되지 않습니다

선택 가이드

💡 핵심 메시지: 특별한 이유가 없다면 Managed Table 을 기본으로 사용하세요. Databricks가 스토리지 관리, 최적화를 자동으로 처리해주므로 운영 부담이 가장 적습니다. 외부 시스템과의 연동이 필요한 경우에만 External Table이나 Foreign Table을 고려하시기 바랍니다.

테이블 유형 확인 방법


현업 사례: External Table 남발로 거버넌스를 잃어버린 팀

🔥 실제 프로젝트에서 흔한 문제입니다.
현업에서는 “데이터를 잃으면 안 되니까”라는 이유로 모든 테이블을 External Table로 생성하는 팀을 자주 만납니다. 처음에는 안전해 보이지만, 6개월~1년이 지나면 다음과 같은 상황이 벌어집니다.

전형적인 문제 시나리오

가장 치명적인 실수: “External Location 없이 직접 경로 지정”

초기에 Unity Catalog를 도입하면서 External Location을 체계적으로 설정하지 않고, 팀원들이 각자 s3://my-bucket/team-a/project-x/... 같은 경로를 자유롭게 지정하면 다음 문제가 발생합니다.
  • 경로 충돌: 두 팀이 같은 경로를 가리키는 서로 다른 External Table을 생성
  • 권한 사각지대: Unity Catalog 밖에서 직접 S3에 접근하면 거버넌스가 우회됨
  • 리니지 단절: 데이터 파일이 Unity Catalog 관리 영역 밖에 있어 추적 불가
💡 현업 교훈: External Table을 쓸 때는 반드시 External Location을 중앙에서 관리 하고, 팀원이 임의의 경로에 테이블을 만들 수 없도록 권한을 제한해야 합니다.

External Table에서 Managed Table로의 마이그레이션 전략

기존에 External Table로 운영하던 환경을 Managed Table로 전환하려면, 단계적으로 접근해야 합니다. 한 번에 전환하면 데이터 유실이나 파이프라인 장애가 발생할 수 있습니다.

마이그레이션 4단계 프로세스

마이그레이션 시 주의사항

💡 현업 팁: 마이그레이션은 중요도가 낮은 테이블부터 시작하세요. dev/staging 환경에서 먼저 검증하고, 프로덕션은 마지막에 진행합니다. 많은 팀이 “한 번에 전부 전환”을 시도하다가 장애를 겪습니다.

Foreign Table(Lakehouse Federation)의 실전 활용과 한계

Foreign Table이 빛나는 순간

현업에서 Foreign Table은 다음 시나리오에서 매우 유용합니다.

Foreign Table의 현실적인 한계

그러나 실무에서 Foreign Table을 주력으로 사용하면 반드시 부딪히는 문제가 있습니다.

실전 패턴: Foreign Table로 탐색 → Managed Table로 정착

가장 많이 사용되는 패턴은 “먼저 Foreign Table로 탐색하고, 가치가 확인되면 Managed Table로 가져오는” 흐름입니다.
💡 현업 팁: Foreign Table을 “영구적인 데이터 소스”로 사용하려는 유혹을 피하세요. 분석 쿼리 하나가 프로덕션 MySQL을 느리게 만들어서 CS팀에서 전화가 오는 일이 실제로 발생합니다. 탐색용으로 시작하되, 반복적으로 사용하는 데이터는 반드시 Delta Lake로 가져오세요.

정리


참고 링크