다음을 통해 공유

Unity Catalog 모범 사례

이 문서에서는 데이터 거버넌스 요구 사항을 가장 효과적으로 충족하기 위해 Unity 카탈로그를 사용하기 위한 권장 사항을 제공합니다. Azure Databricks의 데이터 거버넌스에 대한 소개는 Azure Databricks를 사용한 데이터 거버넌스를 참조하세요. Unity 카탈로그 소개는 Unity 카탈로그란 무엇인가?를 참조하세요.

정체성

Unity 카탈로그 보안 개체에 대한 권한을 할당하려면 보안 주체(사용자, 그룹 및 서비스 주체)를 Azure Databricks 계정 수준에서 정의해야 합니다. Databricks는 SCIM을 사용하여 IdP에서 Azure Databricks 계정에 주체를 프로비전하는 것을 권장합니다.

유용한 정보:

  • 작업 영역 수준 SCIM 프로비저닝을 방지(및 해제)합니다. Unity 카탈로그가 사용되지 않는 레거시 작업 영역에서는 보안 주체(사용자 또는 그룹)를 작업 영역에 직접 프로비전 하는 것이 예약되어야 합니다. 계정 수준에서 프로비저닝을 완전히 관리해야 합니다.

  • IdP에서 그룹을 정의하고 관리합니다. 조직 그룹 정의와 일치해야 합니다.

    그룹은 사용자 및 서비스 주체와 다르게 동작합니다. 작업 영역에 추가하는 사용자 및 서비스 주체는 Azure Databricksaccount와 자동으로 동기화되지만 작업 영역 수준 그룹은 동기화되지 않습니다. 작업 영역-로컬 그룹이 있는 경우 IdP에 복제하고(필요한 경우) 계정에 프로비전하여 수동으로 계정으로 마이그레이션해야 합니다.

  • 효과적으로 사용하여 데이터 및 기타 Unity 카탈로그 보안 개체에 대한 액세스 권한을 부여할 수 있도록 그룹을 설정합니다. 가능하면 사용자에게 직접 부여하지 마세요.

  • 그룹을 사용하여 대부분의 보안 개체에 소유권을 할당합니다.

  • 계정 또는 작업 영역에 사용자를 수동으로 추가하지 않습니다. Azure Databricks에서 그룹을 수정하지 마세요. IdP를 사용합니다.

  • 서비스 주체를 사용하여 작업을 실행합니다. 서비스 주체는 작업 자동화를 사용하도록 설정합니다. 사용자를 사용하여 프로덕션에 쓰는 작업을 실행하는 경우 실수로 프로덕션 데이터를 덮어쓸 위험이 있습니다.

자세한 내용은 SCIM을 사용하여 사용자, 서비스 주체 및 그룹 관리를 참조하고 Microsoft Entra ID에서 사용자 및 그룹 동기화를 참조하세요.

관리자 역할 및 강력한 권한

관리자 역할과 ALL PRIVILEGES, MANAGE 같은 강력한 권한을 할당할 때는 주의가 필요합니다.

  • 할당하기 전에 계정 관리자, 작업 영역 관리자 및 metastore 관리자의 권한을 이해합니다. Unity 카탈로그관리자 권한을 참조하세요.
  • 가능하면 이러한 역할을 그룹에 할당합니다.
  • Metastore 관리자는 선택 사항입니다. 필요한 경우에만 할당합니다. 지침은 (선택 사항) metastore 관리자 역할 할당을 참조하세요.
  • 특히 프로덕션 환경에서 개체를 사용하는 경우 그룹에 개체 소유권을 할당합니다. 물건의 창작자는 그 물건의 첫 번째 소유자입니다. 작성자는 소유권을 적절한 그룹에 다시 할당해야 합니다.
  • 개체에 대한 권한이 있는 MANAGE metastore 관리자, 소유자 및 사용자만 해당 개체에 대한 권한을 부여할 수 있습니다. 부모 카탈로그 및 스키마의 소유자는 카탈로그 또는 스키마의 모든 개체에 대한 권한을 부여할 수도 있습니다. 소유권과 MANAGE 권한을 할당할 때 절제하십시오.
  • ALL PRIVILEGES를 제외한 모든 권한을 포함하는 MANAGE의 할당을 아끼십시오.

권한 할당

Unity 카탈로그의 보안 개체는 계층 구조이며 권한은 아래쪽으로 상속됩니다. 이 상속 계층 구조를 사용하여 효과적인 권한 모델을 개발합니다.

유용한 정보:

  • (또는USE CATALOG)와 USE SCHEMA: 사이의 BROWSE 차이점을 이해합니다.

    • USE CATALOG | SCHEMA 는 카탈로그 또는 스키마에서 데이터를 볼 수 있는 권한을 부여합니다. 단독으로는 이러한 권한이 카탈로그 또는 스키마 내의 개체에 SELECT 또는 READ을 부여하지 않지만, 이는 사용자에게 그 액세스 권한을 부여하기 위한 필수 조건입니다. 카탈로그 또는 스키마에서 데이터를 볼 수 있어야 하는 사용자에게만 이러한 권한을 부여합니다.
    • USE CATALOG | SCHEMA카탈로그 또는 스키마에 대한 액세스를 제한하여 개체 소유자(예: 테이블 작성자)가 액세스 권한이 없어야 하는 사용자에게 해당 개체(테이블)에 대한 액세스를 실수로 할당하지 못하도록 합니다. 팀별로 스키마를 만들고 USE SCHEMA 및 CREATE TABLE 권한을 해당 팀에만 부여하며, 부모 카탈로그에 대해 USE CATALOG 권한을 추가로 부여하는 것이 일반적입니다.
    • BROWSE 는 카탈로그 수준에서 광범위하게 부여되어 사용자가 카탈로그의 개체와 연결된 메타데이터를 볼 수 있도록 할 수 있습니다.

  • 개체 소유권과 MANAGE 권한의 차이점을 이해하십시오.

    • 개체의 소유자는 테이블과 같은 SELECTMODIFY 개체에 대한 모든 권한과 보안 개체에 대한 권한을 다른 보안 주체에게 부여하고 소유권을 다른 보안 주체에게 이전할 수 있는 권한을 가집니다.
    • 소유자는 개체의 MANAGE 소유권 기능을 다른 보안 주체에게 위임할 수 있는 권한을 부여할 수 있습니다.
    • 카탈로그 및 스키마 소유자는 카탈로그 또는 스키마에 있는 모든 개체의 소유권을 이전할 수 있습니다.
    • 소유권을 구성하거나 개체에 대한 권한 관리를 담당하는 그룹에 모든 개체에 대한 권한을 부여하는 MANAGE 것이 가장 좋습니다.

  • 서비스 주체에게 프로덕션 테이블의 직접 MODIFY 액세스를 제한합니다.

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

메타스토어

다음은 메타스토어 만들기 및 관리에 대한 규칙 및 모범 사례입니다.

  • 지역당 하나의 메타스토어만 가질 수 있습니다. 해당 지역의 모든 작업 영역은 해당 metastore를 공유합니다. 지역 간에 데이터를 공유하려면 지역 간 및 플랫폼 간 공유를 참조하세요.

  • 메타스토어에서는 지역 격리를 제공하지만 데이터 격리의 기본 단위로 의도된 것은 아닙니다. 데이터 격리는 일반적으로 카탈로그 수준에서 시작됩니다. 그러나 보다 중앙 집중식 거버넌스 모델을 선호하는 경우 메타스토어 수준 관리 스토리지를 만들 수 있습니다. 권장 사항은 Managed Storage를 참조하세요.

  • metastore 관리자 역할은 선택 사항입니다. 선택적 metastore 관리자를 할당할지 여부에 대한 권장 사항은 관리자 역할 및 강력한 권한을 참조하세요.

중요합니다

자주 액세스하는 테이블을 둘 이상의 메타스토어에서 외부 테이블로 등록하지 마세요. 이렇게 하면 메타스토어 A에 대한 쓰기의 결과로 발생하는 스키마, 테이블 속성, 주석 및 기타 메타데이터를 변경해도 metastore B에는 전혀 등록되지 않습니다. Azure Databricks 커밋 서비스에서 일관성 문제를 일으킬 수도 있습니다.

카탈로그 및 스키마

카탈로그는 일반적인 Unity 카탈로그 데이터 거버넌스 모델에서 데이터 격리의 기본 단위입니다. 스키마는 조직의 추가 계층을 추가합니다.

카탈로그 및 스키마 사용에 대한 모범 사례:

  • 데이터 및 AI 개체를 조직 부서 및 프로젝트를 반영하는 카탈로그 및 스키마로 구성합니다. 이는 카탈로그가 환경 범위, 팀, 사업부 또는 이들의 일부 조합에 해당한다는 것을 의미합니다. 이렇게 하면 권한 계층 구조를 더 쉽게 사용하여 액세스를 효과적으로 관리할 수 있습니다.
  • 작업 환경과 데이터 둘 다 동일한 격리 요구 사항이 있는 경우 카탈로그를 특정 작업 영역에 바인딩할 수 있습니다. 필요한 경우 제한된 작업 영역 집합으로 범위를 지정할 수 있는 카탈로그를 만듭니다.
  • 항상 프로덕션 카탈로그 및 스키마의 소유권을 개별 사용자가 아닌 그룹에 할당합니다.
  • USE CATALOG 및 USE SCHEMA를 포함된 데이터를 보거나 쿼리할 수 있어야 하는 사용자에게만 부여하십시오.

카탈로그 및 스키마에 대한 권한 부여에 대한 자세한 내용은 권한 할당을 참조하세요.

관리되는 스토리지

수명 주기가 Unity 카탈로그에서 완전히 관리되는 개체인 관리되는 테이블 및 볼륨은 관리되는 스토리지라고 하는 기본 스토리지 위치에 저장됩니다. 메타스토어, 카탈로그 또는 스키마 수준에서 관리되는 스토리지를 설정할 수 있습니다. 데이터는 계층 구조에서 사용 가능한 가장 낮은 위치에 저장됩니다. 자세한 내용은 관리되는 스토리지 위치 계층 구조를 참조하고 Unity 카탈로그에서 관리되는 스토리지 위치 지정을 참조하세요.

관리되는 스토리지 위치에 대한 모범 사례:

  • 카탈로그 수준 스토리지를 기본 데이터 격리 단위로 지정합니다.

    메타스토어 수준 스토리지는 초기 Unity 카탈로그 환경에서 필요했지만 더 이상 필요하지 않습니다.

  • 메타스토어 수준 관리되는 위치를 만들도록 선택하는 경우 전용 컨테이너를 사용합니다.

  • Unity 카탈로그 외부에서 액세스할 수 있는 컨테이너는 사용하지 마세요.

    외부 서비스 또는 보안 주체가 Unity 카탈로그를 우회하여 관리되는 스토리지 위치의 데이터에 액세스하는 경우 관리되는 테이블 및 볼륨에 대한 액세스 제어 및 감사 기능이 손상됩니다.

  • DBFS 루트 파일 시스템에 사용되었거나 사용된 컨테이너를 다시 사용하지 마세요.

  • 스토리지 집약적 워크로드가 있는 경우 관리되는 스토리지 및 기타 외부 위치에 단일 스토리지 계정 및 컨테이너를 사용하지 마세요.

    re:[ADLS] 계정은 기본적으로 초당 20,000개의 요청을 지원합니다. 이로 인해 워크로드 제한 및 속도가 느려질 수 있습니다. 동일한 스토리지 계정에서 여러 컨테이너를 사용하면 계정 전체 제한이 변경되지 않습니다. 따라서 여러 스토리지 계정에 걸쳐 스토리지를 분산 저장해야 합니다.

    이러한 스트라이프는 Unity 카탈로그 최종 사용자에게 보이지 않습니다.

관리 테이블 및 외부 테이블

관리되는 테이블 은 Unity 카탈로그에서 완전히 관리되므로 Unity 카탈로그는 관리되는 각 테이블에 대한 거버넌스 및 기본 데이터 파일을 모두 관리합니다. 항상 델타 또는 Apache Iceberg 형식입니다.

외부 테이블 은 Azure Databricks에서 액세스가 Unity 카탈로그에서 관리되지만 데이터 수명 주기 및 파일 레이아웃이 클라우드 공급자 및 기타 데이터 플랫폼을 사용하여 관리되는 테이블입니다. Azure Databricks에서 외부 테이블을 만들 때 해당 위치를 지정합니다. 이 위치는 Unity 카탈로그 외부 위치에 정의된 경로에 있어야 합니다.

관리되는 테이블 사용:

  • 대부분의 사용 사례. Databricks는 다음을 비롯한 Unity 카탈로그 거버넌스 기능 및 성능 최적화를 최대한 활용할 수 있도록 관리되는 테이블 및 볼륨을 권장합니다.

    • 자동 압축
    • 자동 최적화
    • 빠른 메타데이터 읽기(메타데이터 캐싱)
    • 지능형 파일 크기 최적화

    새 Azure Databricks 기능은 관리되는 테이블보다 우선합니다.

  • 모든 새 테이블의 경우

외부 테이블 사용:

  • 이미 사용하고 있고 Hive 메타스토어에서 Unity 카탈로그로 업그레이드하는 경우

    • 외부 테이블을 사용하면 데이터를 이동하지 않고도 빠르고 원활한 "원클릭" 업그레이드를 제공할 수 있습니다.
    • Databricks는 결국 외부 테이블을 관리되는 테이블로 마이그레이션하는 것이 좋습니다.

  • 관리되는 테이블에서 충족할 수 없는 이 데이터에 대한 재해 복구 요구 사항이 있는 경우

    관리되는 테이블은 동일한 클라우드의 여러 메타스토어에 등록할 수 없습니다.

  • 외부 판독기 또는 기록기가 Databricks 외부에서 데이터와 상호 작용할 수 있어야 하는 경우

    일반적으로 Unity 카탈로그에 등록된 외부 테이블에 대해서도 외부 액세스를 허용하지 않아야 합니다. 이렇게 하면 Unity 카탈로그 액세스 제어, 감사 및 계보가 무시됩니다. 델타 공유를 사용하여 관리 테이블을 사용하고 지역 또는 클라우드 공급자 간에 데이터를 공유하는 것이 좋습니다. 외부 테이블에 대한 외부 액세스를 허용해야 하는 경우 모든 쓰기가 Azure Databricks 및 Unity 카탈로그를 통해 발생하는 읽기로 제한합니다.

  • 파케이, 아브로, ORC 등 델타 또는 빙산 테이블이 아닌 테이블을 지원해야 합니다.

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

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

Azure Databricks 테이블 소개도 참조하세요.

관리되는 볼륨 및 외부 볼륨

관리되는 볼륨 은 Unity 카탈로그에 의해 완전히 관리됩니다. 즉, Unity 카탈로그는 클라우드 공급자 계정에서 볼륨의 스토리지 위치에 대한 액세스를 관리합니다. 외부 볼륨은 Azure Databricks 외부에서 관리되지만 Azure Databricks 내에서 액세스를 제어하고 감사하기 위해 Unity 카탈로그에 등록된 스토리지 위치의 기존 데이터를 나타냅니다. Azure Databricks에서 외부 볼륨을 만들 때 해당 위치를 지정합니다. 이 위치는 Unity 카탈로그 외부 위치에 정의된 경로에 있어야 합니다.

관리되는 볼륨 사용:

  • 대부분의 사용 사례에서 Unity 카탈로그 거버넌스 기능을 최대한 활용합니다.
  • COPY INTO 또는 CTAS(CREATE TABLE AS) 문을 실행하지 않고 볼륨의 파일에서 시작하여 테이블을 만들고자 한다면,

외부 볼륨 사용:

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

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

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

팁

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

관리되는 볼륨과 외부 볼륨 및 외부 위치도 참조하세요.

외부 위치

스토리지 자격 증명과 스토리지 경로를 결합하여 외부 위치 보안 개체는 스토리지 액세스에 대한 강력한 제어 및 감사 기능을 제공합니다. 사용자가 Unity 카탈로그에서 제공하는 액세스 제어를 우회하여 외부 위치로 등록된 컨테이너에 직접 액세스하지 못하도록 하는 것이 중요합니다.

외부 위치를 효과적으로 사용하려면 다음을 수행합니다.

  • 외부 위치로 사용되는 컨테이너에 직접 액세스할 수 있는 사용자 수를 제한해야 합니다.

  • 스토리지 계정이 외부 위치로 사용되는 경우 DBFS에 탑재하지 마세요. Databricks는 카탈로그 탐색기를 사용하여 클라우드 스토리지 위치의 탑재를 Unity 카탈로그의 외부 위치로 마이그레이션하는 것이 좋습니다.

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

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

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

    특정 작업 영역에 바인딩하여 외부 위치에 대한 액세스를 제어할 수도 있습니다. (선택 사항) 특정 작업 영역에 외부 위치 할당을 참조 하세요.

  • 최종 사용자에게 외부 위치에 대한 일반 READ FILES 또는 WRITE FILES 권한을 부여하지 마세요.

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

    테이블 형식이 아닌 데이터에 대한 경로 기반 액세스의 경우 볼륨을 사용합니다. 볼륨 경로 아래의 데이터에 대한 클라우드 URI 액세스는 볼륨이 저장된 외부 위치에 부여된 권한이 아니라 볼륨에 부여된 권한에 의해 제어됩니다.

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

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

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

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

다음을 수행하려면 외부 위치만 사용해야 합니다.

  • 또는 CREATE EXTERNAL VOLUME 명령을 사용하여 외부 테이블 및 볼륨을 CREATE TABLE 등록합니다.
  • 위치를 관리되는 스토리지로 등록합니다. 권한은 CREATE MANAGED STORAGE 전제 조건입니다.
  • 특정 접두사에서 외부 테이블 또는 볼륨을 만들기 전에 클라우드 스토리지의 기존 파일을 탐색합니다. 권한은 READ FILES 전제 조건입니다. 이 권한을 아쉽게 할당합니다. 자세한 내용은 이전 목록의 권장 사항을 참조하세요.

외부 위치 및 외부 볼륨

볼륨이 릴리스되기 전에 일부 Unity 카탈로그 구현은 READ FILES 를 통해 데이터 탐색 목적으로 외부 위치에 직접 액세스 권한을 할당했습니다. 구조화, 반구조화 및 구조화되지 않은 데이터를 포함하여 모든 형식으로 파일을 등록하는 볼륨의 가용성으로 인해 테이블, 볼륨 또는 관리되는 위치를 만드는 것 외에는 외부 위치를 사용할 이유가 없습니다. 외부 위치를 사용하는 시기와 볼륨을 사용하는 시기에 대한 자세한 내용은 관리 볼륨 및 외부 볼륨 및 외부 위치를 참조하세요.

지역 간 및 플랫폼 간 공유

지역당 하나의 메타스토어만 가질 수 있습니다. 다른 지역의 작업 영역 간에 데이터를 공유하려면 Databricks-to-Databricks 델타 공유를 사용합니다.

유용한 정보:

  • 개발, 테스트, prod, 영업 및 마케팅과 같은 모든 소프트웨어 개발 수명 주기 범위 및 사업부에 단일 지역 메타스토어를 사용합니다. 자주 공유 데이터 액세스가 필요한 작업 영역이 동일한 지역에 있는지 확인합니다.
  • 클라우드 지역 또는 클라우드 공급자 간에 Databricks-to-Databricks Delta Sharing를 사용합니다.
  • 클라우드 지역 간의 송신 요금에 대한 책임이 사용자에게 있으므로, 자주 액세스하지 않는 테이블에는 델타 공유를 사용하세요. 지역 또는 클라우드 공급자 간에 자주 액세스하는 데이터를 공유해야 하는 경우 다음을 참조하세요. 델타 공유 송신 비용 모니터링 및 관리(공급자의 경우).

Databricks-to-Databricks 공유를 사용하는 경우 다음과 같은 제한 사항에 유의하세요.

  • 계보 그래프는 메타스토어 수준에서 생성되며 지역 또는 플랫폼 경계를 넘지 않습니다. 이는 리소스가 동일한 Databricks 계정 내의 메타스토어 간에 공유되는 경우에도 적용됩니다. 원본의 계보 정보는 대상에 표시되지 않으며 그 반대의 경우도 마찬가지입니다.
  • 액세스 제어는 메타스토어 수준에서 정의되며 지역 또는 플랫폼 경계를 넘지 않습니다. 리소스에 할당된 권한이 있고 해당 리소스가 계정의 다른 메타스토어에 공유되는 경우 해당 리소스에 대한 권한은 대상 공유에 적용되지 않습니다. 대상 공유에 대한 권한을 부여해야 합니다.

컴퓨팅 구성

Databricks는 컴퓨팅 정책을 사용하여 규칙 집합에 따라 클러스터를 구성하는 기능을 제한하는 것이 좋습니다. 컴퓨팅 정책을 사용하면 사용자가 Unity 카탈로그 사용 클러스터, 특히 표준 액세스 모드(이전의 공유 액세스 모드) 또는 전용 액세스 모드(이전의 단일 사용자 또는 할당된 액세스 모드)를 사용하는 클러스터를 만들도록 제한할 수 있습니다.

이러한 액세스 모드 중 하나를 사용하는 클러스터만 Unity 카탈로그의 데이터에 액세스할 수 있습니다. 모든 서버리스 컴퓨팅 및 DBSQL 컴퓨팅은 Unity 카탈로그를 지원합니다.

Databricks는 모든 워크로드에 표준 액세스 모드를 권장합니다. 필요한 기능이 표준 액세스 모드에서 지원되지 않는 경우에만 전용 액세스 모드를 사용합니다. 액세스 모드참조하십시오.