이 문서는 Unity Catalog 섹션의 일부입니다.
Unity Catalog의 3-Level 네임스페이스
💡 Unity Catalog는 Catalog → Schema → Object 3단계 계층 구조로 모든 데이터 자산을 관리합니다. 이 구조는 ANSI SQL 표준의 3-Level 네임스페이스를 따릅니다.전통적인 데이터베이스에서
database.table 형식으로 2단계 네임스페이스를 사용하는 것과 달리, Unity Catalog는 Catalog 라는 최상위 계층을 추가하여 3단계로 확장했습니다. 이를 통해 환경별(production/staging/dev), 팀별, 도메인별 데이터를 명확하게 분리하고 독립적으로 권한을 관리할 수 있습니다.
완전한 이름 (Fully Qualified Name)
Unity Catalog에서 모든 객체는 3단계 이름 으로 고유하게 식별됩니다. 이 이름 규칙은 SQL 표준을 따르므로, 다른 SQL 도구나 플랫폼에서도 동일한 방식으로 접근할 수 있습니다.Metastore — 최상위 컨테이너
💡 Metastore 는 Unity Catalog의 최상위 컨테이너 입니다. 하나의 클라우드 리전에 하나의 Metastore가 존재하며, 해당 리전의 모든 Workspace가 이 Metastore를 공유합니다.Metastore는 직접 데이터를 담지 않고, 그 아래의 Catalog → Schema → Object를 메타데이터(이름, 위치, 권한, 리니지 등) 로 관리하는 카탈로그 역할을 합니다.
Metastore 설정
Metastore는 계정 관리자가 생성하며, 보통 클라우드 리전당 하나만 필요합니다. 여러 Workspace를 하나의 Metastore에 연결하면, Workspace 간에 데이터를 안전하게 공유할 수 있습니다.각 레벨의 역할
객체 유형 상세
Unity Catalog에서 관리하는 객체는 10가지 유형이 있습니다. 각 객체 유형의 특성과 사용 시나리오를 이해하면 데이터 자산을 효과적으로 구성할 수 있습니다.Table (테이블)
테이블은 행(Row)과 열(Column)로 구성된 구조화된 데이터입니다. Unity Catalog에서 가장 기본적이고 중요한 객체 유형입니다.View (뷰)
뷰는 SQL 쿼리를 저장한 가상 테이블 입니다. 데이터를 물리적으로 저장하지 않고, 조회할 때마다 정의된 쿼리를 실행합니다. 복잡한 조인이나 필터를 미리 정의해두면 사용자가 간단하게 데이터에 접근할 수 있습니다.Materialized View (Materialized View)
Materialized View는 쿼리 결과를 물리적으로 저장 하고, 원본 데이터가 변경되면 자동으로 증분 갱신합니다. 복잡한 집계 쿼리를 매번 실행하는 대신 미리 계산된 결과를 사용하므로 조회 성능이 크게 향상됩니다.Streaming Table (스트리밍 테이블)
Streaming Table은 스트리밍 데이터를 증분 처리 하는 특수 테이블입니다. SDP(Streaming Data Pipeline)에서 주로 사용되며, 새로 도착한 데이터만 처리하여 효율적으로 테이블을 갱신합니다.Volume (볼륨)
Volume은 비테이블 형태의 파일(PDF, 이미지, CSV, JSON 등)을 저장하는 공간입니다. 기존의 DBFS(Databricks File System)를 대체하며, Unity Catalog의 거버넌스(권한, 감사)가 적용됩니다.Function (함수)
SQL 또는 Python으로 정의한 사용자 정의 함수(UDF)입니다. Unity Catalog에 등록하면 어떤 Workspace에서든 동일한 함수를 사용할 수 있으며, 함수에 대한 접근 권한도 관리됩니다.Model (ML 모델)
MLflow로 학습하고 등록한 ML 모델입니다. Unity Catalog에 등록되면 데이터 테이블과 동일한 거버넌스(권한, 리니지, 태그)가 적용되며, Model Serving으로 직접 배포할 수 있습니다.Connection (연결)
외부 시스템(MySQL, PostgreSQL, Snowflake 등)의 연결 정보 를 저장합니다. Lakeflow Connect에서 외부 데이터 소스를 연결할 때 사용합니다.기타 보안 관련 객체
네임스페이스 구성 전략
전략 1: 환경별 카탈로그 + 도메인별 스키마 (가장 일반적)
가장 널리 사용되는 패턴입니다. 환경(production/staging/dev)을 카탈로그로 분리하고, 각 환경 내에서 비즈니스 도메인으로 스키마를 나눕니다. 환경별 접근 권한을 카탈로그 수준에서 쉽게 관리할 수 있다는 것이 장점입니다.전략 2: 환경별 카탈로그 + Medallion별 스키마
데이터 엔지니어링 관점에서 데이터의 처리 단계를 중심으로 스키마를 구성하는 패턴입니다. ETL 파이프라인의 흐름이 스키마 구조에 자연스럽게 반영됩니다.전략 3: 팀별 카탈로그 (대규모 조직)
대규모 조직에서 팀 간 데이터 독립성을 최대화할 때 사용합니다. 각 팀이 자체 카탈로그를 소유하고, 공유 데이터는 별도의 shared 카탈로그에 공개합니다.💡 권장: 대부분의 조직에서는 전략 1 (환경별 카탈로그 + 도메인별 스키마) 로 시작하는 것을 권장합니다. 조직이 커지고 요구사항이 복잡해지면 전략 3으로 확장할 수 있습니다.
SQL로 네임스페이스 생성
Information Schema — 메타데이터 조회
Unity Catalog는 ANSI SQL 표준의 information_schema 를 제공하여, 카탈로그, 스키마, 테이블 등의 메타데이터를 SQL로 조회할 수 있습니다.Managed vs External
💡 Managed를 권장하는 이유: Managed Table은 Databricks가 데이터 레이아웃 최적화(Predictive Optimization), 파일 정리(VACUUM), 소형 파일 병합 등을 자동으로 수행합니다. External Table에서는 이러한 최적화 기능이 제한되므로, 특별한 이유가 없다면 Managed Table을 사용하는 것이 좋습니다.