Unity Catalog 모범 사례

아티클
05/01/2024

이 문서에서는 데이터 거버넌스 요구 사항을 충족하기 위해 Unity 카탈로그 및 델타 공유를 사용하기 위한 권장 사항을 제공합니다.

Unity 카탈로그는 Databricks 플랫폼의 데이터 및 AI를 위한 세분화된 거버넌스 솔루션입니다. 데이터 액세스를 관리 및 감사할 수 있는 중앙 위치를 제공하여 데이터의 보안 및 거버넌스를 단순화하는 데 도움이 됩니다. 델타 공유는 Azure Databricks의 데이터를 조직 외부의 사용자와 공유할 수 있는 보안 데이터 공유 플랫폼입니다. Unity 카탈로그를 사용하여 공유 동작을 관리하고 감사합니다.

데이터 거버넌스 및 데이터 격리 구성 요소

조직에서 작동하는 데이터 거버넌스 모델 및 데이터 격리 계획을 개발하려면 Azure Databricks에서 데이터 거버넌스 솔루션을 만들 때 사용할 수 있는 기본 구성 요소를 이해하는 데 도움이 됩니다.

다음 다이어그램은 Unity 카탈로그의 기본 데이터 계층 구조를 보여 줍니다(일부 보안 개체는 카탈로그에서 관리되는 개체의 계층 구조를 강조하기 위해 회색으로 표시됨).

Unity Catalog 개체 모델 다이어그램

해당 계층의 개체에는 다음이 포함됩니다.

Metastore: 메타스토어는 Unity 카탈로그에 있는 개체의 최상위 컨테이너입니다. 메타스토어는 계정 수준에서 상주하며 Azure Databricks 데이터 거버넌스 모델에서 피라미드의 맨 위로 작동합니다.

메타스토어에서는 데이터 자산(테이블, 뷰 및 볼륨)과 해당 자산에 대한 액세스를 제어하는 권한을 관리합니다. Azure Databricks 계정 관리자는 작동하는 각 지역에 대해 하나의 메타스토어를 만들고 동일한 지역의 여러 Azure Databricks 작업 영역에 할당할 수 있습니다. Metastore 관리자는 metastore의 모든 개체를 관리할 수 있습니다. 메타스토어에 등록된 테이블을 읽고 쓸 수 있는 직접 액세스 권한은 없지만 데이터 개체 소유권을 전송하는 기능을 통해 간접적으로 액세스할 수 있습니다.

지정된 메타스토어에 대한 물리적 스토리지는 기본적으로 계정의 다른 메타스토어에 대한 스토리지에서 격리됩니다.

메타스토어에서는 지역 격리를 제공하지만 데이터 격리 단위로 의도된 것은 아닙니다. 데이터 격리는 카탈로그 수준에서 시작해야 합니다.
카탈로그: 카탈로그는 Unity 카탈로그 메타스토어에서 관리하는 데이터 계층 구조(카탈로그 > 스키마 > 테이블/뷰/볼륨)에서 가장 높은 수준입니다. 일반적인 Azure Databricks 데이터 거버넌스 모델에서 데이터 격리의 기본 단위로 사용됩니다.

카탈로그는 스키마의 논리적 그룹화(일반적으로 데이터 액세스 요구 사항에 의해 제한됨)를 나타냅니다. 카탈로그는 종종 조직 구성 단위 또는 소프트웨어 개발 수명 주기 범위를 미러. 예를 들어 프로덕션 데이터의 카탈로그와 개발 데이터의 카탈로그 또는 비고객 데이터에 대한 카탈로그와 중요한 고객 데이터에 대한 카탈로그를 포함하도록 선택할 수 있습니다.

카탈로그는 메타스토어 수준에서 저장하거나 나머지 부모 메타스토어와 별도로 저장되도록 카탈로그를 구성할 수 있습니다. 작업 영역이 자동으로 Unity 카탈로그에 사용하도록 설정된 경우 메타스토어 수준 스토리지가 없으며 카탈로그를 만들 때 스토리지 위치를 지정해야 합니다.

카탈로그가 Azure Databricks 데이터 거버넌스 모델에서 데이터 격리의 기본 단위인 경우 작업 영역 은 데이터 자산 작업을 위한 기본 환경입니다. Metastore 관리자 및 카탈로그 소유자는 작업 영역과 독립적으로 카탈로그에 대한 액세스를 관리하거나 특정 작업 영역에 카탈로그를 바인딩하여 특정 종류의 데이터가 해당 작업 영역에서만 처리되도록 할 수 있습니다. 예를 들어 별도의 프로덕션 및 개발 작업 영역 또는 개인 데이터를 처리하기 위한 별도의 작업 영역을 원할 수 있습니다.

기본적으로 보안 개체에 대한 액세스 권한은 계층 구조의 맨 위에 카탈로그가 있는 해당 개체의 자식에 의해 상속됩니다. 이렇게 하면 데이터에 대한 기본 액세스 규칙을 더 쉽게 설정하고 필요한 경우에만 계층의 각 수준에서 서로 다른 규칙을 지정할 수 있습니다.
스키마(데이터베이스): 데이터베이스라고도 하는 스키마는 테이블 형식 데이터(테이블 및 뷰), 테이블 형식이 아닌 데이터(볼륨), 함수 및 기계 학습 모델의 논리적 그룹입니다. 카탈로그보다 세분화된 데이터에 대한 액세스를 구성하고 제어할 수 있는 방법을 제공합니다. 일반적으로 단일 사용 사례, 프로젝트 또는 팀 샌드박스를 나타냅니다.

스키마는 부모 카탈로그와 동일한 실제 스토리지에 저장하거나 나머지 부모 카탈로그와 별도로 저장되도록 스키마를 구성할 수 있습니다.

Metastore 관리자, 부모 카탈로그 소유자 및 스키마 소유자는 스키마에 대한 액세스를 관리할 수 있습니다.
테이블: 테이블은 Unity 카탈로그의 세 번째 수준 네임스페이스의 세 번째 계층에 있습니다. 여기에는 데이터 행이 포함됩니다.

Unity 카탈로그를 사용하면 관리되는 테이블 및 외부 테이블을 만들 수 있습니다.

관리되는 테이블의 경우 Unity 카탈로그는 수명 주기 및 파일 레이아웃을 완전히 관리합니다. 기본적으로 관리되는 테이블은 메타스토어를 만들 때 구성하는 루트 스토리지 위치에 저장됩니다. 대신 카탈로그 또는 스키마 수준에서 관리되는 테이블에 대한 스토리지를 격리하도록 선택할 수 있습니다.

외부 테이블은 Unity 카탈로그가 아닌 클라우드 공급자 및 기타 데이터 플랫폼을 사용하여 데이터 수명 주기 및 파일 레이아웃을 관리하는 테이블입니다. 일반적으로 외부 테이블을 사용하여 많은 양의 기존 데이터를 등록하거나 Azure Databricks 클러스터 및 Databricks SQL 웨어하우스 외부의 도구를 사용하여 데이터에 대한 쓰기 액세스가 필요한 경우 외부 테이블이 Unity 카탈로그 메타스토어에 등록되면 관리되는 테이블과 마찬가지로 Azure Databricks 액세스를 관리하고 감사할 수 있습니다.

부모 카탈로그 소유자 및 스키마 소유자는 메타스토어 관리자(간접적으로)와 마찬가지로 테이블에 대한 액세스를 관리할 수 있습니다.
보기: 뷰는 메타스토어의 하나 이상의 테이블과 뷰에서 파생된 읽기 전용 개체입니다.
행 및 열: 데이터 마스킹과 함께 행 및 열 수준 액세스는 동적 보기 또는 행 필터 및 열 마스크를 사용하여 부여됩니다. 동적 보기는 읽기 전용입니다.
볼륨: 볼륨은 Unity 카탈로그의 세 번째 수준 네임스페이스의 세 번째 계층에 있습니다. 테이블 형식이 아닌 데이터를 관리합니다. 볼륨을 사용하여 구조화, 반구조화 및 구조화되지 않은 데이터를 비롯한 모든 형식의 파일을 저장, 구성 및 액세스할 수 있습니다. 볼륨의 파일을 테이블로 등록할 수 없습니다.
모델 및 함수: 엄밀히 말해, 데이터 자산, 등록된 모델 및 사용자 정의 함수는 Unity 카탈로그에서 관리되고 개체 계층 구조에서 가장 낮은 수준에 상주할 수도 있습니다. Unity 카탈로그의 모델 수명 주기 관리 및 UDF(사용자 정의 함수)를 참조하세요.

데이터 격리 모델 계획

조직에서 Azure Databricks와 같은 데이터 플랫폼을 사용하는 경우 환경(예: 개발 및 프로덕션) 또는 조직 운영 단위 간에 데이터 격리 경계가 필요한 경우가 많습니다.

격리 표준은 조직에 따라 다를 수 있지만 일반적으로 다음과 같은 기대치를 포함합니다.

사용자는 지정된 액세스 규칙에 따라 데이터에만 액세스할 수 있습니다.
데이터는 지정된 사용자 또는 팀에서만 관리할 수 있습니다.
데이터는 스토리지에서 물리적으로 구분됩니다.
지정된 환경에서만 데이터에 액세스할 수 있습니다.

데이터 격리가 필요하면 데이터 거버넌스와 협업을 불필요하게 어렵게 만들 수 있는 사일로 환경이 발생할 수 있습니다. Azure Databricks는 통합 데이터 거버넌스 플랫폼을 기본 동안 다양한 데이터 격리 옵션을 제공하는 Unity Catalog를 사용하여 이 문제를 해결합니다. 이 섹션에서는 Azure Databricks에서 사용할 수 있는 데이터 격리 옵션과 중앙 집중식 데이터 거버넌스 모델 또는 분산 모델을 선호하는지 여부에 관계없이 이를 사용하는 방법에 대해 설명합니다.

사용자는 지정된 액세스 규칙에 따라 데이터에만 액세스할 수 있습니다.

대부분의 조직은 내부 또는 규정 요구 사항에 따라 데이터 액세스에 대한 엄격한 요구 사항을 가지고 있습니다. 보안을 유지해야 하는 데이터의 일반적인 예로는 직원 급여 정보 또는 신용 카드 지불 정보가 있습니다. 이러한 유형의 정보에 대한 액세스는 일반적으로 엄격하게 제어되고 정기적으로 감사됩니다. Unity 카탈로그는 이러한 업계 표준을 충족하기 위해 카탈로그 내의 데이터 자산에 대한 세부적인 제어를 제공합니다. Unity 카탈로그에서 제공하는 컨트롤을 사용하여 사용자는 보고 쿼리할 수 있는 데이터만 보고 쿼리할 수 있습니다.

데이터는 지정된 사용자 또는 팀에서만 관리할 수 있습니다.

Unity 카탈로그는 중앙 집중식 거버넌스 모델과 분산 거버넌스 모델 중에서 선택할 수 있는 기능을 제공합니다.

중앙 집중식 거버넌스 모델에서 거버넌스 관리자는 metastore의 소유자이며 모든 개체의 소유권을 가져와서 권한을 부여하고 취소할 수 있습니다.

분산 거버넌스 모델에서 카탈로그 또는 카탈로그 집합은 데이터가 수행하는 기본. 해당 카탈로그의 소유자는 모든 자산을 만들고 소유하고 해당 내에서 거버넌스를 관리할 수 있습니다기본. 지정된 do기본 소유자는 다른 do기본 소유자와 독립적으로 작동할 수 있습니다.

데이터처럼 메타스토어 또는 카탈로그를 선택하든기본 Databricks는 그룹을 metastore 관리자 또는 카탈로그 소유자로 설정하는 것이 좋습니다.

Unity 카탈로그 소유권 및 액세스

데이터는 스토리지에서 물리적으로 구분됩니다.

조직은 특정 유형의 데이터를 클라우드 테넌트에 있는 특정 계정 또는 버킷 내에 저장하도록 요구할 수 있습니다.

Unity 카탈로그는 이러한 요구 사항을 충족하도록 메타스토어, 카탈로그 또는 스키마 수준에서 스토리지 위치를 구성하는 기능을 제공합니다.

예를 들어 조직에 인적 자원과 관련된 프로덕션 데이터가 컨테이너 abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net 상주해야 하는 회사 규정 준수 정책이 있다고 가정해 보겠습니다. Unity 카탈로그에서는 카탈로그 수준에서 위치를 설정하고, 예를 들어 hr_prod호출된 카탈로그를 만들고, 위치 abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog를 할당하여 이 요구 사항을 달성할 수 있습니다. 즉, 카탈로그에서 hr_prod 만든 관리 테이블 또는 볼륨(예: 사용 CREATE TABLE hr_prod.default.table …)은 해당 데이터를 abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog에 저장합니다. 필요에 따라 스키마 수준 위치를 제공하여 보다 세분화된 수준에서 데이터를 hr_prod catalog 구성할 수 있습니다.

이러한 스토리지 격리가 필요하지 않은 경우 메타스토어 수준에서 스토리지 위치를 설정할 수 있습니다. 그 결과 이 위치는 메타스토어의 카탈로그 및 스키마에 관리되는 테이블과 볼륨을 저장하기 위한 기본 위치로 사용됩니다.

시스템은 스키마에서 카탈로그, 메타스토어에 이르는 스토리지 위치의 계층 구조를 평가합니다.

예를 들어 테이블 myCatalog.mySchema.myTable 이 만들어 my-region-metastore지면 다음 규칙에 따라 테이블 스토리지 위치가 결정됩니다.

위치가 제공된 mySchema경우 해당 위치가 저장됩니다.
그렇지 않은 경우 위치가 제공된 myCatalog경우 해당 위치가 저장됩니다.
마지막으로, 위치가 제공되지 myCatalog않은 경우 해당 위치가 연결된 my-region-metastore위치에 저장됩니다.

Unity 카탈로그 스토리지 계층 구조

지정된 환경에서만 데이터에 액세스할 수 있습니다.

조직 및 규정 준수 요구 사항은 종종 특정 환경에서만 액세스할 수 있는 개인 데이터와 같은 특정 데이터를 유지하도록 지정합니다. 또한 프로덕션 데이터를 개발 환경과 격리된 상태로 유지하거나 특정 데이터 세트와 do기본가 함께 조인되지 않도록 할 수도 있습니다.

Databricks에서 작업 영역은 기본 데이터 처리 환경이며 카탈로그는 기본 데이터입니다기본. Unity 카탈로그를 사용하면 메타스토어 관리자와 카탈로그 소유자가 특정 작업 영역에 카탈로그를 할당하거나 "바인딩"할 수 있습니다. 이러한 환경 인식 바인딩은 사용자에게 부여된 데이터 개체에 대한 특정 권한에 관계없이 작업 영역 내에서 특정 카탈로그만 사용할 수 있도록 하는 기능을 제공합니다.

이제 요구 사항에 맞게 Unity 카탈로그를 설정하는 프로세스를 자세히 살펴보겠습니다.

Unity Catalog 메타스토어 구성

메타스토어는 Unity 카탈로그에 있는 개체의 최상위 컨테이너입니다. 메타스토어에서는 데이터 자산(테이블, 뷰 및 볼륨)뿐만 아니라 Unity 카탈로그에서 관리하는 기타 보안 개체를 관리합니다. 보안 개체의 전체 목록은 Unity 카탈로그의 보안 개체를 참조 하세요.

이 섹션에서는 메타스토어 만들기 및 구성에 대한 팁을 제공합니다. Unity 카탈로그에 대해 작업 영역을 자동으로 사용하도록 설정한 경우 메타스토어를 만들 필요가 없지만 이 섹션에 제시된 정보는 여전히 유용할 수 있습니다. Unity 카탈로그의 자동 사용 기능을 참조하세요.

메타스토어 구성을 위한 팁:

Azure Databricks 작업 영역이 있는 각 지역에 대해 하나의 메타스토어를 설정해야 합니다.

단일 지역 메타스토어에 연결된 모든 작업 영역은 메타스토어에서 관리하는 데이터에 액세스할 수 있습니다. 메타스토어 간에 데이터를 공유하려면 델타 공유를 사용합니다.
각 메타스토어는 관리되는 테이블 및 관리되는 볼륨을 저장하는 데 사용할 수 있는 클라우드 테넌트에서 관리되는 스토리지 위치(루트 스토리지라고도 함)로 구성할 수 있습니다.

메타스토어 수준 관리되는 위치를 만들도록 선택하는 경우 사용자에게 직접 액세스할 수 없는지 확인해야 합니다(즉, 이 위치가 포함된 클라우드 계정을 통해). 이 스토리지 위치에 대한 액세스 권한을 부여하면 사용자가 Unity 카탈로그 메타스토어의 액세스 제어를 우회하고 감사 가능성을 방해할 수 있습니다. 이러한 이유로 메타스토어 관리 스토리지는 전용 컨테이너여야 합니다. DBFS 루트 파일 시스템이거나 이전에 DBFS 루트 파일 시스템이었던 컨테이너를 다시 사용하면 안 됩니다.

카탈로그 및 스키마 수준에서 관리 스토리지를 정의하고 메타스토어의 루트 스토리지 위치를 재정의하는 옵션도 있습니다. 대부분의 시나리오에서 Databricks는 카탈로그 수준에서 관리되는 데이터를 저장하는 것이 좋습니다.
Unity 카탈로그에 사용하도록 설정된 작업 영역에서 작업 영역 관리자의 권한을 이해하고 기존 작업 영역 관리자 할당을 검토해야 합니다.

작업 영역 관리자는 사용자 및 서비스 주체 추가, 클러스터 만들기 및 다른 사용자를 작업 영역 관리자로 위임하는 등 작업 영역에 대한 작업을 관리할 수 있습니다. 작업 영역이 자동으로 Unity 카탈로그에 사용하도록 설정된 경우 작업 영역 관리자는 기본적으로 카탈로그 및 다른 많은 Unity 카탈로그 개체를 만들 수 있습니다. Unity 카탈로그에 대해 작업 영역이 자동으로 사용하도록 설정된 경우 작업 영역 관리자 권한 참조

또한 작업 영역 관리자는 작업 소유권 관리 및 Notebook 보기와 같은 작업 영역 관리 작업을 수행할 수 있으므로 Unity 카탈로그에 등록된 데이터에 간접적으로 액세스할 수 있습니다. 작업 영역 관리자는 신중하게 배포해야 하는 권한 있는 역할입니다.
작업 영역을 사용하여 사용자 데이터 액세스를 격리하는 경우 작업 영역 카탈로그 바인딩을 사용할 수 있습니다. 작업 영역 카탈로그 바인딩을 사용하면 작업 영역 경계별로 카탈로그 액세스를 제한할 수 있습니다. 예를 들어 작업 영역 관리자와 사용자가 프로덕션 작업 영역 환경에서prod_workspace만 프로덕션 데이터에 prod_catalog 액세스할 수 있도록 할 수 있습니다. 기본값은 카탈로그를 현재 메타스토어에 연결된 모든 작업 영역과 공유하는 것입니다. (선택 사항) 특정 작업 영역에 카탈로그 할당을 참조 하세요.

작업 영역이 Unity 카탈로그에 자동으로 사용하도록 설정된 경우 미리 프로비전된 작업 영역 카탈로그는 기본적으로 작업 영역에 바인딩됩니다.

Unity 카탈로그 메타스토어 만들기를 참조하세요.

외부 위치 및 스토리지 자격 증명 구성

외부 위치를 사용하면 Unity 카탈로그가 사용자를 대신하여 클라우드 테넌트에서 데이터를 읽고 쓸 수 있습니다. 외부 위치는 클라우드 스토리지에 대한 경로로 정의되며, 해당 위치에 액세스하는 데 사용할 수 있는 스토리지 자격 증명과 결합됩니다.

외부 위치를 사용하여 Unity 카탈로그에 외부 테이블 및 외부 볼륨을 등록할 수 있습니다. 이러한 엔터티의 콘텐츠는 사용자가 볼륨 또는 테이블을 만들 때 참조되는 외부 위치의 하위 경로에 물리적으로 위치합니다.

스토리지 자격 증명은 클라우드 스토리지에 대한 액세스를 제공하는 장기 클라우드 자격 증명을 캡슐화합니다. Azure 관리 ID(강력 권장) 또는 서비스 주체일 수 있습니다. Azure 관리 ID를 사용하면 서비스 주체를 사용할 때보다 다음과 같은 이점이 있습니다.

관리 ID를 사용하면 자격 증명을 유지 관리하거나 비밀을 회전할 필요가 없습니다.
Azure Databricks 작업 영역이 사용자 고유의 VNet(VNet 삽입이라고도 함)에 배포된 경우 스토리지 방화벽으로 보호되는 Azure Data Lake Storage Gen2 계정에 연결할 수 있습니다.

팁

외부 위치는 스토리지 자격 증명과 스토리지 경로를 결합하여 스토리지 액세스에 대한 강력한 제어 및 감사 기능을 제공합니다. 사용자가 Unity 카탈로그에서 제공하는 액세스 제어를 우회하지 못하도록 하려면 외부 위치로 사용되는 컨테이너에 직접 액세스할 수 있는 사용자 수를 제한해야 합니다. 같은 이유로 스토리지 계정이 외부 위치로 사용되는 경우 DBFS에 탑재해서는 안 됩니다. Databricks는 카탈로그 탐색기를 사용하여 클라우드 스토리지 위치의 탑재를 Unity 카탈로그의 외부 위치로 마이그레이션하는 것이 좋습니다.

외부 위치 관리에 대한 모범 사례 목록은 외부 위치, 외부 테이블 및 외부 볼륨 관리를 참조 하세요. 또한 클라우드 스토리지를 Azure Databricks에 연결하는 외부 위치 만들기를 참조하세요.

데이터 구성

Databricks는 카탈로그를 사용하여 조직의 정보 아키텍처 전반에 걸쳐 분리를 제공할 것을 권장합니다. 이는 종종 카탈로그가 소프트웨어 개발 환경 범위, 팀 또는 사업부에 해당한다는 것을 의미합니다. 작업 영역을 데이터 격리 도구로 사용하는 경우(예: 프로덕션 및 개발 환경에 다른 작업 영역을 사용하거나 매우 중요한 데이터로 작업하기 위해 특정 작업 영역을 사용하는 경우) 카탈로그를 특정 작업 영역에 바인딩할 수도 있습니다. 이렇게 하면 지정된 데이터의 모든 처리가 적절한 작업 영역에서 처리됩니다. (선택 사항) 특정 작업 영역에 카탈로그 할당을 참조 하세요.

Unity Catalog 카탈로그

스키마(데이터베이스라고도 함)는 Unity 카탈로그의 3개 수준 네임스페이스의 두 번째 계층이며 테이블, 뷰 및 볼륨을 구성합니다. 스키마를 사용하여 자산에 대한 권한을 구성하고 정의할 수 있습니다.

Unity 카탈로그에서 관리하는 개체는 관리되거나 외부로 관리할 수 있습니다.

관리되는 개체 는 Unity 카탈로그에서 데이터 개체를 만드는 기본 방법입니다.

Unity 카탈로그는 이러한 보안 개체의 수명 주기 및 파일 레이아웃을 관리합니다. Azure Databricks 외부의 도구를 사용하여 관리되는 테이블 또는 볼륨의 파일을 직접 조작해서는 안 됩니다.

관리되는 테이블 및 볼륨은 지정된 테이블 또는 볼륨의 메타스토어, 카탈로그 또는 스키마 수준에 존재할 수 있는 관리형 스토리지에 저장됩니다. 스토리지에서 데이터가 물리적으로 구분되어 있는지 확인합니다.

관리되는 테이블 및 볼륨은 외부 위치 및 스토리지 자격 증명을 만들고 관리하는 오버헤드 없이 콘텐츠에 대한 관리되는 위치를 프로비전하려는 경우 편리한 솔루션입니다.

관리되는 테이블은 항상 델타 테이블 형식을 사용합니다.
외부 개체 는 Unity 카탈로그에서 데이터 수명 주기 및 파일 레이아웃을 관리하지 않는 보안 개체입니다.

외부 볼륨 및 테이블은 외부 위치에 등록되어 데이터 복사 작업 없이 클라우드 스토리지에 이미 있는 많은 수의 파일에 대한 액세스를 제공합니다. 다른 시스템에서 생성된 파일이 있고 Azure Databricks 내에서 액세스하도록 준비하려는 경우 또는 Azure Databricks 외부의 도구에서 이러한 파일에 직접 액세스해야 하는 경우 외부 개체를 사용합니다.

외부 테이블은 Delta Lake 및 Parquet, JSON 및 CSV를 비롯한 기타 여러 데이터 서식을 지원합니다. 관리되는 볼륨과 외부 볼륨을 모두 사용하여 임의의 형식의 파일에 액세스하고 저장할 수 있습니다. 데이터는 구조화되거나 반구조화되거나 구조화되지 않을 수 있습니다.

테이블 및 볼륨을 만드는 방법에 대한 자세한 내용은 Unity 카탈로그에서 테이블 만들기 및 볼륨 만들기 및 작업을 참조하세요.

외부 위치, 외부 테이블 및 외부 볼륨 관리

아래 다이어그램은 하나의 스토리지 자격 증명을 공유하는 4개의 외부 위치가 있는 단일 클라우드 스토리지 컨테이너의 파일 시스템 계층 구조를 나타냅니다.

외부 위치

Unity 카탈로그에서 외부 위치를 구성한 후에는 외부 위치 내의 디렉터리에 외부 테이블과 볼륨을 만들 수 있습니다. 그런 다음 Unity 카탈로그를 사용하여 이러한 테이블 및 볼륨에 대한 사용자 및 그룹 액세스를 관리할 수 있습니다. 이렇게 하면 클라우드 스토리지 컨테이너의 특정 디렉터리 및 파일에 대한 특정 사용자 또는 그룹 액세스를 제공할 수 있습니다.

참고 항목

볼륨을 정의할 때 볼륨 경로 아래의 데이터에 대한 클라우드 URI 액세스는 볼륨의 권한에 의해 제어됩니다.

외부 위치 사용에 대한 권장 사항

외부 위치에 대한 사용 권한을 부여하는 권장 사항:

Unity 카탈로그와 클라우드 스토리지 간의 연결을 설정하는 임무를 맡은 관리자 또는 신뢰할 수 있는 데이터 엔지니어에게만 외부 위치를 만들 수 있는 기능을 부여합니다.

외부 위치는 Unity 카탈로그 내에서 클라우드 스토리지의 광범위한 위치(예: 전체 버킷 또는 컨테이너(abfss://) 또는 광범위한 하위 경로(abfss://my-container@storage-account.dfs.core.windows.netmy-container@storage-account.dfs.core.windows.net/경로/경로/하위 디렉터리)에 대한 액세스를 제공합니다. 클라우드 관리자가 몇 개의 외부 위치를 설정한 다음, 해당 위치를 관리하는 책임을 조직의 Azure Databricks 관리자에게 위임할 수 있습니다. 그런 다음, Azure Databricks 관리자는 외부 위치 아래의 특정 접두사에 외부 볼륨 또는 외부 테이블을 등록하여 외부 위치를 보다 세부적인 권한이 있는 영역으로 추가로 구성할 수 있습니다.

외부 위치가 매우 포괄적이기 때문에 Databricks는 Unity 카탈로그와 클라우드 스토리지 간의 연결을 설정하는 임무를 맡은 관리자 또는 신뢰할 수 있는 데이터 엔지니어에게만 권한을 부여하는 CREATE EXTERNAL LOCATION 것이 좋습니다. 다른 사용자에게 보다 세부적인 액세스를 제공하기 위해 Databricks는 외부 위치 위에 외부 테이블 또는 볼륨을 등록하고 볼륨 또는 테이블을 사용하여 데이터에 대한 액세스 권한을 사용자에게 부여하는 것이 좋습니다. 테이블 및 볼륨은 카탈로그 및 스키마의 자식이므로 카탈로그 또는 스키마 관리자는 액세스 권한을 최종적으로 제어할 수 있습니다.
최종 사용자에게 외부 위치에 대한 일반 READ FILES 또는 WRITE FILES 권한을 부여하지 마세요.

볼륨의 가용성을 사용하면 사용자는 테이블, 볼륨 또는 관리되는 위치를 만드는 것 외에는 외부 위치를 사용하지 않아야 합니다. 데이터 과학 또는 기타 테이블 형식이 아닌 데이터 사용 사례의 경로 기반 액세스에 외부 위치를 사용하면 안 됩니다.

볼륨은 SQL 명령, dbutils, Spark API, REST API, Terraform 및 파일 검색, 업로드 및 다운로드를 위한 사용자 인터페이스를 사용하여 파일 작업을 지원합니다. 또한 볼륨은 아래 /Volumes/<catalog_name>/<schema_name>/<volume_name>/의 로컬 파일 시스템에서 액세스할 수 있는 FUSE 탑재를 제공합니다. FUSE 탑재를 사용하면 많은 기계 학습 또는 운영 체제 라이브러리에서 요구하는 대로 데이터 과학자와 ML 엔지니어가 로컬 파일 시스템에 있는 것처럼 파일에 액세스할 수 있습니다.

외부 위치의 파일에 대한 직접 액세스 권한을 부여해야 하는 경우(예: 사용자가 외부 테이블 또는 볼륨을 만들기 전에 클라우드 스토리지의 파일을 탐색하기 위해) 부여 READ FILES할 수 있습니다. 허용 WRITE FILES 에 대한 사용 사례는 드물다.

외부 위치를 사용하여 다음을 수행해야 합니다.

또는 CREATE TABLE 명령을 사용하여 외부 테이블 및 볼륨을 CREATE EXTERNAL VOLUME 등록합니다.
특정 접두사에서 외부 테이블 또는 볼륨을 만들기 전에 클라우드 스토리지의 기존 파일을 탐색합니다. 권한은 READ FILES 전제 조건입니다.
메타스토어 루트 버킷 대신 카탈로그 및 스키마에 대한 관리 스토리지로 위치를 등록합니다. 권한은 CREATE MANAGED STORAGE 전제 조건입니다.

외부 위치 사용에 대한 추가 권장 사항:

경로 겹침 충돌을 방지합니다. 외부 위치의 루트에 외부 볼륨 또는 테이블을 만들지 마세요.

외부 위치 루트에서 외부 볼륨 또는 테이블을 만드는 경우 외부 위치에 추가 외부 볼륨 또는 테이블을 만들 수 없습니다. 대신 외부 위치 내의 하위 디렉터리에 외부 볼륨 또는 테이블을 만듭니다.

외부 볼륨을 사용하기 위한 권장 사항

외부 볼륨을 사용하여 다음을 수행해야 합니다.

ETL 파이프라인 및 기타 데이터 엔지니어링 활동의 초기 단계에서 처리를 지원하기 위해 외부 시스템에서 생성된 원시 데이터에 대한 랜딩 영역을 등록합니다.
예를 들어 자동 로더 COPY INTO또는 CTAS(CREATE TABLE AS) 문을 사용하여 수집을 위한 준비 위치를 등록합니다.
관리 볼륨이 옵션이 아닌 경우 데이터 과학자, 데이터 분석가 및 기계 학습 엔지니어가 예비 데이터 분석 및 기타 데이터 과학 작업의 일부로 사용할 수 있는 파일 스토리지 위치를 제공합니다.
Azure Databricks 사용자는 감시 시스템 또는 IoT 디바이스에서 캡처한 구조화되지 않은 데이터(예: 이미지, 오디오, 비디오 및 PDF 파일)의 대규모 컬렉션 또는 로컬 종속성 관리 시스템 또는 CI/CD 파이프라인에서 내보낸 라이브러리 파일(JAR 및 Python 휠 파일)과 같은 다른 시스템에서 클라우드 스토리지에 생성 및 보관된 임의 파일에 액세스할 수 있도록 합니다.
관리 볼륨이 옵션이 아닌 경우 로깅 또는 검사포인트 파일과 같은 운영 데이터를 저장합니다.

외부 볼륨을 사용하기 위한 추가 권장 사항:

Databricks는 하나의 스키마 내의 한 외부 위치에서 외부 볼륨을 만드는 것이 좋습니다.

팁

데이터를 다른 위치(예: 자동 로더 사용) 또는 COPY INTO외부 볼륨으로 복사하는 수집 사용 사례의 경우입니다. 데이터를 테이블로 쿼리하려는 경우 외부 테이블을 사용하며 복사본은 포함하지 않습니다.

외부 테이블 사용에 대한 권장 사항

관리 테이블을 만들 때는 외부 테이블을 사용하여 클라우드 스토리지에 저장된 데이터 위에 일반적인 쿼리 패턴을 지원해야 합니다.

외부 테이블 사용에 대한 추가 권장 사항:

Databricks는 스키마당 하나의 외부 위치를 사용하여 외부 테이블을 만드는 것이 좋습니다.
Databricks는 일관성 문제의 위험으로 인해 둘 이상의 메타스토어에서 테이블을 외부 테이블로 등록하지 않도록 강력히 권장합니다. 예를 들어 한 메타스토어에서 스키마를 변경하면 두 번째 메타스토어에 등록되지 않습니다. 메타스토어 간에 데이터를 공유하기 위해 Delta Sharing을 사용합니다. Delta Sharing을 사용하여 안전하게 데이터 공유를 참조하세요.

액세스 제어 구성

Unity 카탈로그의 각 보안 개체에는 소유자가 있습니다. 개체를 만드는 보안 주체는 초기 소유자가 됩니다. 개체의 소유자는 테이블에 대한 SELECT 및 MODIFY와 같은 개체에 대한 모든 권한과 보안 개체에 대한 권한을 다른 주체에게 부여할 수 있는 권한을 가집니다. 보안 개체의 소유자만 해당 개체에 대한 권한을 다른 보안 주체에게 부여할 수 있는 권한이 있습니다. 따라서 모든 개체에 대한 소유권을 개체에 대한 권한 부여 관리를 담당하는 그룹으로 구성하는 것이 가장 좋습니다. 소유자와 메타스토어 관리자 모두 보안 개체의 소유권을 그룹으로 전송할 수 있습니다. 또한 개체가 카탈로그(예: 테이블 또는 보기)에 포함된 경우 카탈로그 및 스키마 소유자는 개체의 소유권을 변경할 수 있습니다.

Unity 카탈로그의 보안 개체는 계층적이며 권한은 아래로 상속됩니다. 즉, 카탈로그 또는 스키마에 대한 권한을 부여하면 카탈로그 또는 스키마 내의 모든 현재 및 미래 개체에 대한 권한이 자동으로 부여됩니다. 자세한 내용은 상속 모델을 참조하세요.

테이블에서 데이터를 읽거나 보기 위해서는 사용자에게 다음 권한이 있어야 합니다.

SELECT - 테이블 또는 보기에서
USE SCHEMA - 테이블을 소유하고 있는 스키마에서
USE CATALOG - 스키마를 소유하는 카탈로그에서

USE CATALOG 를 사용하면 피부여자가 자식 개체에 액세스하기 위해 카탈로그를 트래버스할 수 있고 USE SCHEMA 피부여자가 해당 자식 개체에 액세스하기 위해 스키마를 트래버스할 수 있습니다. 예를 들어 테이블에서 데이터를 선택하려면 사용자는 해당 테이블에 대한 권한과 USE CATALOG 부모 카탈로그에 대한 권한과 USE SCHEMA 부모 스키마에 대한 권한이 있어야 합니다SELECT. 따라서 이 권한을 사용하여 데이터 네임스페이스의 섹션에 대한 액세스를 특정 그룹으로 제한할 수 있습니다. 일반적인 시나리오는 해당 팀만 스키마에 대해 USE SCHEMA 및 CREATE가 있는 팀별로 스키마를 설정하는 것입니다. 즉, 팀 구성원이 생성한 모든 테이블은 팀 내에서만 공유할 수 있습니다.

다음 SQL 구문을 사용하여 테이블에 대한 액세스를 보호할 수 있습니다.

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

다음 SQL 구문과 같이 보조 스키마의 동적 보기를 사용하여 열에 대한 액세스를 보호할 수 있습니다.

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

다음 SQL 구문과 같이 보조 스키마의 동적 보기를 사용하여 행에 대한 액세스를 보호할 수 있습니다.

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

행 필터 및 열 마스크를 사용하여 사용자에게 테이블에 대한 보안 액세스 권한을 부여할 수도 있습니다. 자세한 내용은 행 필터 및 열 마스크를 사용하여 중요한 테이블 데이터 필터링을 참조하세요.

Unity 카탈로그의 모든 권한에 대한 자세한 내용은 Unity 카탈로그의 권한 관리를 참조 하세요.

클러스터 구성 관리

Databricks는 클러스터 정책을 사용하여 규칙 집합을 기반으로 클러스터를 구성하는 기능을 제한할 것을 권장합니다. 클러스터 정책을 사용하면 Unity Catalog가 사용하도록 설정된 클러스터만 만들도록 액세스를 제한할 수 있습니다. 클러스터 정책을 사용하면 사용 가능한 선택 사항이 줄어들어 사용자의 클러스터 만들기 프로세스가 크게 단순화되고 데이터에 원활하게 액세스할 수 있습니다. 클러스터 정책을 사용하면 클러스터당 최대 비용을 제한하여 비용을 제어할 수도 있습니다.

액세스 제어의 무결성을 보장하고 강력한 격리 보장을 적용하기 위해 Unity Catalog는 컴퓨팅 리소스에 보안 요구 사항을 적용합니다. 이러한 이유로 Unity Catalog는 클러스터 액세스 모드의 개념을 도입합니다. Unity 카탈로그는 기본적으로 안전합니다. 클러스터가 적절한 액세스 모드로 구성되지 않은 경우 해당 클러스터는 Unity 카탈로그의 데이터에 액세스할 수 없습니다. Unity 카탈로그에 대해 지원되는 컴퓨팅 및 클러스터 액세스 모드를 참조 하세요.

Databricks는 클러스터를 공유할 때 공유 액세스 모드를 사용하고 자동화된 작업 및 기계 학습 워크로드에 대한 단일 사용자 액세스 모드를 사용하는 것이 좋습니다.

아래 JSON은 공유 액세스 모드를 사용하는 클러스터에 대한 정책 정의를 제공합니다.

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

아래 JSON은 단일 사용자 액세스 모드를 사용하여 자동화된 작업 클러스터에 대한 정책 정의를 제공합니다.

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

액세스 감사

완전한 데이터 거버넌스 솔루션에는 데이터에 대한 액세스 감사와 경고 및 모니터링 기능이 필요합니다. Unity Catalog는 메타스토어에 대해 수행된 작업의 감사 로그를 캡처하고 이러한 로그는 Azure Databricks 감사 로그의 일부로 전달됩니다.

시스템 테이블을 사용하여 계정의 감사 로그에 액세스할 수 있습니다. 감사 로그 시스템 테이블에 대한 자세한 내용은 감사 로그 시스템 테이블 참조를 참조하세요.

Databricks Data Intelligence 플랫폼과 관련된 중요한 이벤트에 대한 완전한 가시성을 얻는 방법에 대한 자세한 내용은 감사 로그를 사용하여 Databricks Data Intelligence 플랫폼 모니터링을 참조하세요.

Delta Sharing은 사용하는 컴퓨팅 플랫폼에 관계없이 다른 조직 또는 조직 내 다른 부서와의 안전한 데이터 공유를 위해 Databricks에서 개발한 개방형 프로토콜입니다. 메타스토어에서 델타 공유를 사용하도록 설정하면 Unity 카탈로그는 델타 공유서버를 실행합니다.

메타스토어 간에 데이터를 공유하기 위해 Databricks 간 Delta Sharing을 활용할 수 있습니다. 이를 통해 다른 지역의 메타스토어에서 테이블을 등록할 수 있습니다. 이러한 테이블은 소비하는 메타스토어에서 읽기 전용 개체로 나타납니다. 이러한 테이블에는 Unity Catalog 내의 다른 개체와 마찬가지로 액세스 권한이 부여될 수 있습니다.

Databricks 간 Delta Sharing을 사용하여 메타스토어 간에 공유하는 경우 액세스 제어는 하나의 메타스토어로 제한됩니다. 테이블과 같은 보안 개체에 권한이 부여되어 있고 해당 리소스가 계정 내 메타스토어에 공유되는 경우 원본의 권한 부여가 대상 공유에 적용되지 않습니다. 대상 공유는 자체 권한 부여를 설정해야 합니다.

Unity Catalog 모범 사례

데이터 거버넌스 및 데이터 격리 구성 요소

데이터 격리 모델 계획

사용자는 지정된 액세스 규칙에 따라 데이터에만 액세스할 수 있습니다.

데이터는 지정된 사용자 또는 팀에서만 관리할 수 있습니다.

데이터는 스토리지에서 물리적으로 구분됩니다.

지정된 환경에서만 데이터에 액세스할 수 있습니다.

Unity Catalog 메타스토어 구성

외부 위치 및 스토리지 자격 증명 구성

데이터 구성

외부 위치, 외부 테이블 및 외부 볼륨 관리

외부 위치 사용에 대한 권장 사항

외부 볼륨을 사용하기 위한 권장 사항

외부 테이블 사용에 대한 권장 사항

액세스 제어 구성

클러스터 구성 관리

액세스 감사

자세한 정보

피드백

피드백

추가 리소스

Unity Catalog 모범 사례

데이터 거버넌스 및 데이터 격리 구성 요소

데이터 격리 모델 계획

사용자는 지정된 액세스 규칙에 따라 데이터에만 액세스할 수 있습니다.

데이터는 지정된 사용자 또는 팀에서만 관리할 수 있습니다.

데이터는 스토리지에서 물리적으로 구분됩니다.

지정된 환경에서만 데이터에 액세스할 수 있습니다.

Unity Catalog 메타스토어 구성

외부 위치 및 스토리지 자격 증명 구성

데이터 구성

외부 위치, 외부 테이블 및 외부 볼륨 관리

외부 위치 사용에 대한 권장 사항

외부 볼륨을 사용하기 위한 권장 사항

외부 테이블 사용에 대한 권장 사항

액세스 제어 구성

클러스터 구성 관리

액세스 감사

델타 공유를 사용하여 안전하게 데이터 공유

자세한 정보

피드백

피드백

추가 리소스