귀하의 데이터, 귀하의 스토리지, 귀하의 규칙: Unity Catalog 관리형 테이블 저장을 위한 2026년 가이드

Unity Catalog 관리형 테이블을 사용하면 조직에 별도의 스토리지가 필요할 때 데이터의 배치 위치를 제어할 수 있습니다. 다른 데이터 플랫폼과 달리, Databricks 테이블 데이터는 귀하가 소유한 S3 버킷, ADLS 컨테이너 또는 GCS 버킷과 같은 클라우드 스토리지 계정에 그대로 유지됩니다. 

Unity Catalog 관리형 테이블은 테이블 관리를 자동화합니다. Unity Catalog 관리형 테이블을 Iceberg 또는 Delta 형식 중 무엇으로 저장하든, Databricks는 귀하가 선택한 위치에서 데이터 레이아웃, 튜닝 및 정리를 대신 처리하며, 테이블이 변경됨에 따라 최적화를 자동으로 적용합니다. 

이 블로그에서는 관리형 테이블 스토리지 모델의 작동 방식과 Databricks 관리형 스토리지 위치를 선택하거나 변경하는 방법을 설명합니다. 

테이블이 귀하가 소유한 스토리지에 유지됩니다

자체 클라우드 스토리지를 가져오면 관리형 테이블 데이터가 귀하가 소유한 클라우드 계정에 저장됩니다. 귀하는 해당 스토리지의 소유권을 유지하고 데이터가 어떻게 구성되어 있는지 투명하게 확인할 수 있습니다. 데이터를 검사, 감사하고 자체 버킷 정책을 적용할 수 있을 뿐만 아니라 데이터의 위치를 제어할 수도 있습니다. 

제공업체가 제어하는 스토리지나 독점 데이터 형식으로 테이블을 보관하는 관리형 또는 네이티브 테이블 서비스를 제공하는 다른 플랫폼과 달리, Databricks에서는 데이터가 귀하의 계정에 그대로 유지됩니다.

설계부터 개방형

데이터를 귀하의 클라우드 계정에 보관하는 것은 Databricks의 관리형 테이블을 개방형으로 만드는 요소 중 일부에 불과합니다. Unity Catalog는 업계에서 유일하게 Iceberg 및 Delta 전반에 걸쳐 거버넌스가 적용된 완전한 읽기 및 쓰기 권한을 통해 귀하가 데이터의 소유자가 될 수 있도록 지원하며, 개방형 표준을 사용하여 다른 사람이 소유한 개방형 형식의 테이블과 연동할 수 있는 기능을 제공하는 주요 카탈로그입니다.

Apache Spark™, Flink, Trino, Kafka Connect 및 Snowflake와 같은 외부 도구는 Iceberg REST Catalog 및 Unity Catalog의 Open API를 통해 관리형 테이블을 읽고 쓸 수 있습니다. Open API 및 자격 증명 벤딩(credential vending)을 통해 안전한 액세스가 가능하므로, 외부 도구가 데이터를 복제하지 않고도 거버넌스가 적용된 데이터와 상호 작용할 수 있습니다. 이를 통해 아키텍처가 단순해지고 분석 및 AI 워크로드 전반에서 단일 진실 공급원(single source of truth)을 확보할 수 있습니다.

자체 스토리지를 가져오면 Unity Catalog가 파일에 대한 액세스를 제어하는 동안에도 클라우드 계정에서 파일에 계속 액세스할 수 있습니다.

데이터가 저장되는 위치를 직접 제어할 수 있습니다

Databricks의 관리형 테이블을 사용하면 관리형 테이블 데이터가 저장되는 위치를 결정할 수 있습니다. 메타스토어, 카탈로그 또는 스키마 수준에서 관리형 스토리지 위치를 한 번 설정하면 그 아래의 모든 테이블이 이를 상속합니다. 가장 구체적인 수준이 우선 적용됩니다. 즉, 스키마의 위치는 카탈로그의 위치보다 우선하고, 카탈로그의 위치는 메타스토어의 위치보다 우선합니다. 광범위한 기본값을 설정한 다음, 팀이나 도메인에 자체 스토리지가 필요한 곳마다 이를 재정의할 수 있습니다.

이러한 제어는 설정 시점에 고정되지 않습니다. 조직이 변화함에 따라, ALTER CATALOG 또는 ALTER SCHEMA ... SET MANAGED LOCATION가 새 테이블과 볼륨을 새 위치로 지정하더라도 이미 작성된 모든 데이터는 원래 위치에 그대로 유지됩니다.

별도의 스토리지가 필요할 때 더 강력한 제어 기능 제공

대부분의 팀은 카탈로그와 스키마를 통해 데이터를 논리적으로 구성하므로 기본 파일이 물리적으로 어디에 저장되는지 고민할 필요가 없습니다. 카탈로그와 스키마가 상속하는 관리형 스토리지 위치만 있으면 충분하기 때문입니다. Unity Catalog의 역할 및 속성 기반 액세스 제어와 결합된 이 접근 방식은 표준 GDPR 데이터 격리 요구 사항을 충족합니다.

그러나 일부 조직은 물리적 스토리지 자체까지 확장되는 경계가 필요합니다. 특정 사업 부서에서 관리 또는 클라우드 비용 할당을 위해 별도의 스토리지가 필요할 수 있습니다. 또는 지역 및 규제 규칙에 따라 특정 데이터가 물리적으로 저장되는 위치가 규정될 수도 있습니다. 이러한 경우 특정 카탈로그나 스키마에 자체 관리형 스토리지 위치를 부여하여 데이터의 물리적 배치가 이를 필요로 하는 경계와 일치하도록 할 수 있습니다.

관리형으로 변환할 때 데이터가 저장되는 위치 선택

외부 테이블을 관리형으로 변환하면 데이터는 해당 카탈로그 또는 스키마가 현재 가리키는 관리형 스토리지 위치에 저장됩니다. 해당 외부 테이블이 이미 임시 또는 비표준 위치에 있는 경우, 현재 해당 도메인에 사용하는 스토리지의 다른 위치에 관리형 테이블이 저장되기를 원할 수 있습니다.

변환하는 동안 Databricks는 테이블의 데이터와 트랜잭션 로그를 사용자가 설정한 관리형 스토리지 위치로 복사하므로, 관리형 테이블이 사용자가 선택한 위치에 저장됩니다.

요약

관리형 테이블은 테이블 유지 관리를 자동화하는 동시에 데이터를 귀하가 소유한 스토리지에 유지할 수 있도록 합니다. 이는 테이블 데이터를 제공업체가 제어하는 스토리지에 보관하는 다른 관리형 플랫폼과 다릅니다. 메타스토어, 카탈로그 또는 스키마 수준에서 배치를 제어하고, 새 테이블이 저장되는 위치를 변경하고, 외부 테이블을 관리형으로 변환할 때 위치를 선택할 수 있습니다. 데이터는 개방형 형식으로 유지되며 Iceberg REST Catalog 및 Unity Catalog의 Open API를 통해 액세스할 수 있습니다.

관리형 스토리지 위치를 설정하거나 변경할 준비가 되면, 관리형 스토리지 설명서에서 자세한 내용을 확인할 수 있습니다.

용어 정의

이러한 용어 중 상당수는 동일한 몇 가지 단어를 재사용하므로 혼동하기 쉽습니다. 이 게시물에서 각 용어가 의미하는 바는 다음과 같습니다.

• 관리형 테이블: Unity Catalog가 데이터와 수명 주기를 대신 관리해 주는 테이블입니다. LOCATION 절 없이 생성합니다.
• 관리형 스토리지 위치: 메타스토어, 카탈로그 또는 스키마의 관리형 테이블과 볼륨이 기록되는 클라우드 스토리지 경로입니다. SET MANAGED LOCATION 절을 사용하여 설정합니다.
• 외부 위치(External location): 클라우드 경로를 스토리지 자격 증명과 쌍으로 연결하여 해당 경로에 대한 액세스를 제어하는 Unity Catalog 오브젝트입니다. 외부 위치는 외부 테이블과 관리형 스토리지 모두를 제어하며, 카탈로그 또는 스키마 수준의 관리형 스토리지 위치가 이 안에 위치합니다.
• 고객 소유 스토리지: 기본 클라우드 스토리지가 고객의 자체 클라우드 계정에 있는 스토리지 옵션입니다. 이는 Databricks에 있는 테이블의 대부분을 차지합니다.
• 기본 스토리지(Default storage): 사용자가 자체 버킷을 가져오는 대신 Databricks가 사용자를 위해 기본 클라우드 스토리지를 프로비저닝하는 대체 스토리지 옵션입니다.
• ALTER CATALOG / ALTER SCHEMA … SET MANAGED LOCATION: 카탈로그 또는 스키마에 대한 새로운 관리형 테이블 및 볼륨이 기록되는 위치를 변경하는 명령입니다. 기존 테이블은 영향을 받지 않습니다.
• 외부에서 관리형으로의 변환(ALTER TABLE … SET MANAGED): 외부 테이블을 관리형 테이블로 변환하는 명령입니다. 변환하는 동안 데이터와 트랜잭션 로그가 현재 관리형 스토리지 위치로 복사됩니다.

자주 묻는 질문(FAQs)

1. Unity Catalog은 관리형 테이블 데이터를 Databricks 소유 스토리지와 제 자체 클라우드 계정 중 어디에 저장하나요?

귀하의 자체 계정에 저장됩니다. 관리형 테이블 데이터는 메타스토어, 카탈로그 또는 스키마에 설정한 관리형 스토리지 위치의 S3, ADLS 또는 GCS 등 귀하의 자체 계정에 있는 클라우드 스토리지에 기록됩니다. Databricks는 테이블의 레이아웃과 수명 주기를 관리하지만, 기본 파일은 Databricks가 제어하는 계정이 아니라 귀하가 소유하고 Unity Catalog에 등록한 버킷 또는 컨테이너에 저장됩니다.

2. Unity Catalog 관리형 테이블을 사용하면 Databricks에 종속(lock-in)되나요?

아닙니다. 관리형 테이블은 귀하가 소유한 클라우드 스토리지에 유지되는 Iceberg 및 Delta를 포함한 오픈 테이블 포맷을 사용합니다. 외부 엔진은 Iceberg REST Catalog 및 Unity Catalog의 오픈 API를 통해 이를 읽고 쓸 수 있으므로 데이터가 독점 인터페이스에 갇히지 않습니다. 귀하는 스토리지의 소유권을 유지하고 데이터는 오픈 포맷으로 유지되며 오픈 표준을 통해 액세스가 이루어집니다. 관리형 테이블은 종속을 유발하지 않습니다. 외부 테이블과 마찬가지로 관리형 테이블에서도 Databricks로 이전하거나 Databricks에서 나가는 것이 완전히 가능하며, 두 경우 모두 데이터를 물리적으로 동일한 위치에 유지할 수 있습니다.

3. 규정 준수 또는 데이터 레지던시를 위해 특정 데이터를 별도의 스토리지에 보관할 수 있나요?

네, 가능합니다. 필요한 경우 특정 카탈로그 또는 스키마에 다른 모든 것과 분리된 자체 관리형 스토리지 위치를 부여하여 여러 국가 또는 규제 체계의 데이터를 고유한 스토리지에 보관하거나 스토리지 비용을 특정 팀이나 사업 부문에 할당할 수 있습니다. 

4. Databricks 이외의 엔진 및 도구에서도 제 관리형 테이블을 읽고 쓸 수 있나요?

네, 가능합니다. 관리형 테이블은 Iceberg REST Catalog 및 Unity Catalog의 오픈 API를 통해 읽거나 쓸 수 있으므로 Apache Spark, Trino, Flink와 같은 외부 엔진에서 액세스할 수 있습니다. Unity Catalog는 스토리지 액세스에 대한 거버넌스를 처리하여 이를 우회할 때 발생할 수 있는 데이터 손상을 방지합니다. 또한 경로 기반 리디렉션(path-based redirect) 및 호환성 모드(Compatibility Mode)를 통해 직접 경로 기반 액세스도 가능합니다.

5. 관리형 테이블 데이터가 저장되는 위치를 설정한 후에 변경할 수 있나요?

네, 가능합니다. 조직 개편, 새로운 버킷, 새로운 리전 등 물리적 분리가 필요한 조직의 변경 사항이 발생할 때마다 ALTER CATALOG … SET MANAGED LOCATION 또는 ALTER SCHEMA … SET MANAGED LOCATION을 사용하여 새 테이블이 다른 위치를 가리키도록 하십시오. 기존 테이블은 원래 위치에 그대로 유지되고 새 테이블은 새 위치에 저장됩니다. 외부 테이블을 관리형 테이블로 변환할 때마다 해당 데이터가 설정한 위치로 복사되므로, 동일한 단계의 일부로 데이터를 올바른 위치로 이동할 수 있습니다. 

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)