엔터프라이즈 규모 거버넌스: Hive Metastore에서 Unity Catalog로 마이그레이션

데이터 환경의 복잡성

비즈니스가 디지털 및 데이터 역량을 계속 확장함에 따라 데이터 인프라의 복잡성은 증가하며, 지속적인 가치를 창출하려면 시기적절하고 신뢰할 수 있으며 액세스 가능한 정보가 중요합니다. 하지만 많은 기업이 여전히 레거시 Hive Metastore(HMS)에 의존하고 있는데, 이는 단일 작업 공간 경계를 넘어선 최신 대규모 거버넌스 요구 사항에 맞게 설계되지 않았습니다.

HMS는 근본적으로 리니지 추적, 다중 작업 공간 거버넌스 및 최신 보안 제어가 부족합니다. 예를 들어 레거시 Databricks 작업 공간별 HMS를 사용하는 사용자는 여러 작업 공간 환경에서 정책이 중복되고 가시성이 단편화되는 문제에 직면합니다. 한편 외부 HMS를 사용하는 사용자는 잘못 구성된 마운트로 인해 모든 작업 공간 사용자에게 의도치 않게 민감한 데이터가 노출될 위험이 있습니다. 팀이 더욱 분산되고 데이터 사용이 가속화됨에 따라 이러한 한계는 민첩성과 규정 준수를 저해하고, 궁극적으로 데이터 기반 의사 결정에 대한 신뢰를 약화시킵니다.

Unity Catalog(UC)는 Databricks 데이터 인텔리전스 플랫폼의 모든 데이터 및 AI 자산에 대한 통합 거버넌스 모델을 도입하여 이러한 문제를 해결합니다. 세분화된 액세스 제어, 중앙 집중식 리니지 추적, 다중 작업 공간 지원을 통해 Unity Catalog는 조직이 안전하게 확장하고 더 효율적으로 운영하는 데 필요한 기반을 제공합니다. 이는 HMS 아키텍처로는 불가능한 기능입니다.

지금 이것이 중요한 이유

이 마이그레이션 가이던스의 시점은 매우 중요합니다. 지난 몇 년간 Unity Catalog로 마이그레이션하는 데 필요한 사항에 대한 이해와 관련 도구가 발전해 왔습니다. 이 블로그는 다양한 기업 환경에서 수많은 Unity Catalog 마이그레이션을 통해 얻은, 현장에서 검증된 기술과 실제 교훈을 담은 최신 방법론과 모범 사례를 요약하여 소개합니다. 이제 조직은 구현 위험과 복잡성을 크게 줄이는 검증된 접근 방식을 활용할 수 있습니다.

이 블로그는 레거시 Databricks 작업 공간별 HMS(내부 HMS라고도 함) 및 외부 HMS(예: AWS Glue)에서 마이그레이션하기 위한 가이드를 제공하며 다음 주제를 포함합니다.

• 제어를 희생하지 않으면서 자율성을 지원하는 거버넌스 모델 평가
• 위험과 중단을 최소화하는 확장 가능한 아키텍처 설계 및 실행
• 거버넌스를 운영하여 데이터에 대한 안전한 셀프 서비스 액세스를 지원하세요.
• 데이터 자산 마이그레이션 전 Unity Catalog를 사용한 새 워크로드 구축
• 마이그레이션 및 전환 기간 동안 중단을 최소화합니다.

주요 아키텍처 고려 사항

HMS에서 Unity Catalog로 마이그레이션하는 것은 조직에 데이터 아키텍처를 현대화할 기회를 제공합니다. 하지만 Unity Catalog의 모든 가치를 실현하려면 처음부터 신중한 설계 선택이 필요합니다. 이러한 아키텍처 결정은 조직의 혁신 속도, 도메인 소유권 모델, 팀 간 데이터 액세스 요구 사항과 일치해야 합니다.

전반적인 원칙은 동일하지만, metastore 유형에 따라 특정 도구와 마이그레이션 접근 방식이 다르게 작동할 수 있습니다. 이러한 차이점으로 인해 현재 아키텍처의 맥락에서 도구 호환성 및 마이그레이션 요구 사항을 평가하는 것이 중요합니다. 이러한 이해를 바탕으로, Unity Catalog 거버넌스 모델의 기반이자 장기적인 확장성과 규정 준수를 위해 카탈로그, 스키마, 권한을 구성하는 방법을 구체화하는 중요한 첫 단계인 metastore 설계를 살펴볼 수 있습니다.

메타스토어 설계

Unity Catalog에서 메타데이터의 최상위 컨테이너인 metastore 는 거버넌스 모델의 기반입니다. 이는 catalogs 를 데이터 격리의 기본 단위이자 비즈니스 도메인 전반에 걸쳐 액세스 범위를 지정하는 중앙 메커니즘으로 정의하여 계정의 액세스 제어 프레임워크의 기반을 마련합니다. Unity Catalog metastore는 Databricks 제어 평면에서 다중 테넌트 서비스로 호스팅되며 카탈로그, 스키마, 테이블, 뷰 및 권한에 대한 권한 있는 레지스트리 역할을 합니다. 중심적인 역할 때문에 metastore 설계는 중요한 초기 단계이며, 데이터 거버넌스 요구 사항, 워크로드 격리, 장기적인 확장성을 고려해야 합니다.

이 섹션에서는 metastore 설계 원칙에 중점을 둡니다. Infrastructure as Code(IaC)를 사용하여 Unity Catalog metastore를 프로비저닝하는 것에 대한 기술적 세부 사항은 나중에 'Infrastructure as Code(IaC)를 사용한 자동화된 배포'에서 다룹니다.

metastore, 관리형 스토리지, 액세스 제어를 포함한 Unity Catalog 개념에 대한 배경 지식은 Unity Catalog란? (AWS | Azure | GCP)을 참조하세요.

Unity Catalog는 리전별로 하나의 metastore를 지원하지만 데이터 도메인 전반에 걸쳐 논리적 및 물리적 격리를 적용하기 위한 여러 메커니즘을 제공합니다. 이를 통해 복잡하거나 고도로 분할된 환경을 가진 조직에서도 대부분의 경우 단일 metastore 전략을 실행할 수 있습니다.

실제로 대부분의 팀은 엄격한 리전별 격리가 규제 또는 규정 준수 요구 사항이 아닌 한, 여러 metastore를 프로비저닝하는 대신 단일 metastore를 채택하고 카탈로그와 스키마를 사용하여 경계를 적용합니다.

리전 또는 클라우드 플랫폼 간 데이터 공유에 대한 지침은 리전 및 플랫폼 간 공유 (AWS | Azure | GCP)를 참조하세요.

주요 격리 메커니즘

Unity Catalog는 단일 메타스토어 아키텍처 내에서 함께 작동하여 데이터 경계를 적용하고 분산형 거버넌스를 활성화하는 네 가지 주요 격리 메커니즘을 제공합니다.

1. 관리 위임(관리자 격리)

   Unity Catalog의 객체 소유권 모델은 각 카탈로그, 스키마, 테이블에 단일 소유자를 할당하는 동시에 제어된 위임을 허용합니다. 객체 소유자 또는 metastore 관리자는 다른 보안 주체(예: 사용자, 서비스 주체 또는 계정 그룹)에게 MANAGE 권한을 부여할 수 있습니다. 이를 통해 SELECT 또는 MODIFY와 같은 데이터 액세스 권한을 부여하지 않고도 객체의 이름을 바꾸거나, 삭제하거나, 권한을 수정할 수 있습니다.

   이러한 직무 분리는 분산형 관리를 지원합니다. 팀은 자신의 데이터 자산을 관리할 수 있으며, metastore 관리자는 환경 전반에 걸쳐 소유권을 이전하고 액세스를 복구하며 거버넌스를 시행할 수 있는 권한을 유지합니다. 연속성을 보장하고 관리 오버헤드를 줄이려면 개인보다는 그룹에 소유권 또는 MANAGE를 할당하는 것이 좋습니다.

   객체 소유권 모델 및 UC 관리 자산에 대한 권한 관리에 대한 자세한 내용은 Unity Catalog 객체 소유권 관리 (AWS | Azure | GCP)를 참조하세요.

2. 작업 공간-카탈로그 바인딩

   Unity Catalog를 사용하면 작업 공간-카탈로그 바인딩 (AWS | Azure | GCP)을 통해 어떤 작업 공간이 어떤 카탈로그에 액세스할 수 있는지 정밀하게 제한할 수 있습니다. 예를 들어, 프로덕션 데이터 카탈로그는 특정 작업 공간에만 바인딩될 수 있으므로 사용자가 개발자 작업 공간에서 데이터를 변경하는 것을 방지할 수 있습니다. 이 예시에서 작업 공간-카탈로그 바인딩은 다른 작업 공간에서 특정 카탈로그로의 모든 액세스를 완전히 막지는 않습니다. 예를 들어, metastore 관리자 또는 카탈로그 소유자는 개발자 작업 공간의 사용자에게 프로덕션 데이터에 대한 읽기 전용 액세스를 지정하여 필요에 따라 테스트할 수 있도록 허용할 수 있습니다(단일 카탈로그는 여러 작업 공간에서 공유될 수 있습니다). 이 기능은 사용자 수준 권한에 관계없이 데이터 도메인에 대한 작업 공간 경계가 유지되도록 보장합니다.

3. Unity Catalog 액세스 제어

   Unity Catalog는 세분화되고 계층적인 역할 기반 액세스 제어(RBAC)를 지원하여 관리자가 사용자, 그룹 또는 서비스 주체에게 (metastore, 카탈로그, 스키마 또는 테이블 수준에서) 정확한 권한을 부여할 수 있도록 합니다. 액세스는 SQL 명령 또는 Databricks UI 및 CLI를 통해 관리되므로 데이터 액세스를 제한하고 강력한 데이터 거버넌스 및 개인정보 보호를 쉽게 시행할 수 있습니다.

   Unity Catalog의 액세스 제어는 함께 작동하는 4가지 상호 보완적인 모델을 기반으로 합니다:

   • 작업 공간 수준 제한: 객체를 특정 작업 공간에 바인딩하여 사용자가 데이터에 액세스할 수 있는 위치 를 제한합니다.
   • 권한 및 소유권: 보호 가능한 객체에 권한을 부여하고 객체 소유권을 관리하여 누가 무엇 에 액세스할 수 있는지를 정의합니다.
   • 속성 기반 액세스 제어(베타): 사용자, 리소스 또는 환경 속성을 동적으로 평가하는 태그와 유연한 중앙 집중식 정책을 사용하여 사용자가 액세스할 수 있는 데이터 를 제어합니다.
   • 테이블 수준 필터링 및 마스킹: 데이터에 직접 적용되는 행 수준 필터와 열 마스크를 사용하여 사용자가 테이블 내에서 볼 수 있는 *데이터를* 제어합니다.

   자세한 내용은 Unity Catalog의 액세스 제어 (AWS | Azure | GCP)를 참조하세요.

4. 스토리지 격리

   metastore가 리전별 격리를 제공하지만, 데이터 격리는 일반적으로 카탈로그 수준에서 이루어집니다. Databricks는 이를 적용하기 위해 각 카탈로그에 자체 관리형 스토리지 컨테이너(예: 전용 S3 버킷, ADLS 컨테이너 또는 GCS 버킷)를 할당할 것을 권장합니다. 해당 카탈로그의 모든 새 관리형 테이블 또는 볼륨은 기본적으로 할당된 컨테이너에 기록됩니다. 실제로 회사는 각 팀이나 환경에 별도의 클라우드 버킷과 함께 카탈로그(예: sales_prod, marketing_dev)를 제공할 수 있습니다. 이 접근 방식은 거버넌스를 간소화하면서 각 팀의 데이터가 물리적으로 격리되도록 보장합니다. 규정 준수 요구 사항을 충족하기 위해 암호화 및 데이터 수명 주기 관리를 통합하는 정책을 컨테이너 수준에서 적용할 수 있습니다.

   또한 Unity Catalog는 외부 데이터 액세스를 관리하기 위해 두 가지 주요 구성을 사용합니다.

   • 스토리지 자격 증명 은 개체 스토리지에 액세스하는 데 사용되는 클라우드 ID(예: IAM 역할, Azure 서비스 주체 또는 GCP 서비스 계정)를 캡슐화합니다.
   • 외부 위치 는 해당 자격 증명을 특정 클라우드 경로 또는 컨테이너에 연결합니다. 외부 위치에 대한 권한이 부여된 사용자만 해당 경로의 데이터를 읽거나 쓸 수 있습니다.

   이는 특정 작업 공간에도 바인딩되어 권한이 있는 사용자만 민감한 데이터 경로에 액세스할 수 있도록 보장합니다.

   자세한 내용은 Unity Catalog를 사용하여 클라우드 개체 스토리지에 연결 (AWS | Azure | GCP)을 참조하세요.

카탈로그 디자인

잘 계획된 메타스토어가 준비되면 관심은 카탈로그 설계로 옮겨가며, 이 단계에서 거버넌스 결정이 일상적인 데이터 사용과 만나기 시작합니다. 메타스토어는 전역 액세스 제어 평면을 설정하는 반면, 카탈로그는 데이터의 논리적 분리 및 도메인 기반 소유권을 위한 기본 메커니즘 역할을 합니다.

각 카탈로그는 일반적으로 비즈니스 단위(BU), 기능 도메인 또는 프로젝트 경계에 해당합니다. 이 매핑은 거버넌스 표준과의 일관성을 유지하면서 팀에 데이터에 대한 자율성을 부여합니다. 신중한 카탈로그 디자인은 액세스 복잡성을 줄이고 요구 사항이 변화함에 따라 안전하게 확장할 수 있도록 지원합니다.

효과적인 카탈로그 전략은 비즈니스 도메인 경계와 소프트웨어 수명 주기 단계를 반영합니다. 널리 채택되는 확장 가능한 패턴은 다음과 같습니다.

<business unit>_<environment> → finance_dev, sales_stg, datascience_prod

이 규칙은 다음을 가능하게 합니다.

• 명확한 소유권: 각 카탈로그는 전담팀에서 관리하는 BU 또는 도메인에 매핑됩니다.
• 환경 격리: 데이터 제품은 (개발 → 스테이징 → 프로덕션)의 제어된 단계를 통해 개발, 검증, 승격됩니다.
• 정책 세분성: 액세스 제어, 암호화, 보존 정책을 카탈로그 수준에서 적용할 수 있습니다.

이러한 구조를 통해 팀은 환경을 격리된 상태로 유지하면서 데이터 제품의 전체 라이프사이클을 관리할 수 있습니다. 개발자는 프로덕션 릴리스 전에 변경 사항을 테스트하고, 동료 검토를 수행하며, 자산을 점진적으로 승격할 수 있습니다.

엄격한 보안 또는 규정 준수 요구 사항이 있는 조직의 경우 환경 격리는 종종 논리적 경계를 넘어 확장됩니다. 이러한 경우 각 환경은 별도의 스토리지 컨테이너, 클라우드 네트워킹(VPC/VNet) 또는 별개의 Databricks 작업 공간으로 지원될 수 있습니다.

조직은 비즈니스 및 환경 세분화를 반영하도록 Unity Catalog를 조정함으로써 거버넌스의 일관성을 달성하고, 승인 및 배포 워크플로를 간소화하며, 확신을 갖고 데이터 이니셔티브를 확장할 수 있습니다. 이 접근 방식은 한편으로는 팀의 자율성과 안전한 혁신을, 다른 한편으로는 중앙 집중식 거버넌스 및 추적 가능성의 엄격함 사이에서 균형을 유지합니다.

추가 지침은 Unity Catalog 모범 사례 (AWS | Azure | GCP)를 참조하세요.

거버넌스 모델: 중앙 집중식 소유권 대 분산형 소유권

카탈로그 설계가 데이터 도메인 및 환경의 구조적 경계를 정의하는 반면, 거버넌스 모델은 해당 경계 내에서 의사 결정 권한을 가진 주체를 결정합니다. 중앙 집중식 거버넌스 모델과 분산형 (또는 연합형) 거버넌스 모델 중 어떤 것을 선택하느냐에 따라 정책 적용 방식, 팀의 변화 적응 방식, 데이터 이니셔티브의 조직 전체 확장 방식이 결정됩니다.

간단히 말해, 카탈로그는 데이터 소유권이 어디에 있는지를 정의하고, 거버넌스 모델은 해당 소유권을 어떻게 그리고 누가 관리하는지를 정의합니다.

중앙 집중식 모델

중앙 집중식 거버넌스 모델에서는 전담 플랫폼 또는 데이터 거버넌스 팀이 Unity Catalog 메타스토어를 관리하고 카탈로그를 통해 액세스 경계를 적용합니다. 팀은 카탈로그를 BU 또는 도메인에 맞춰진 컨테이너로 정의하고, 개발 및 프로덕션 사용을 분리하기 위해 워크스페이스-카탈로그 바인딩을 구성합니다. 또한 카탈로그, 스키마, 테이블 수준에서 세분화된 권한을 적용합니다.

이 중앙 팀은 또한 공유 데이터 세트를 큐레이팅하고 모든 도메인에서 규정 준수, 품질, 메타데이터 표준을 유지하여 조직 전체에 일관된 정책을 보장합니다. 이 모델은 특히 규제 산업에 속한 조직이나 엄격하게 통제되는 데이터 환경을 가진 조직의 규정 준수 및 감사를 간소화합니다.

예를 들어, 중앙 집중식 거버넌스 모델을 채택하는 일부 글로벌 제조 조직은 지역 간 커뮤니케이션을 간소화하고, 일관된 품질 표준을 적용하며, 공급망 전반에 걸쳐 운영 비용을 최적화할 수 있습니다.

분산 모델

반대로, 분산형(또는 연합형) 거버넌스 모델은 개별 BU가 카탈로그와 데이터 제품을 엔드투엔드로 소유하도록 권한을 부여하여 제어를 분산시킵니다. 중앙 플랫폼 팀이 인프라, 보안 가드레일, 규정을 준수하는 아키텍처를 관리할 수는 있지만, 각 도메인 팀은 카탈로그 권한, 데이터 품질, 게시 워크플로를 독립적으로 관리합니다. 이 모델은 도메인 책임과 민첩성을 촉진하며, 데이터를 제품으로 취급하고 공통 거버넌스 프레임워크 내에서 자율적인 팀 간에 협업이 이루어지는 Data Mesh 원칙과 일치합니다.

분산형 접근 방식은 소유권이 분산되어 있어 데이터 자산이 증가함에 따라 확장이 용이합니다. 각 팀은 데이터의 품질, 계보, 문서화를 직접 책임지며, 이는 더 강력한 책임감을 조성하고 신뢰할 수 있는 데이터 제품을 조직 전체에 더 빠르게 제공하도록 촉진합니다.

이 특정 모델은 현지화된 규정 준수가 필요하거나 규제 요구 사항이 다른 여러 지역에 걸쳐 운영되는 다양한 비즈니스 포트폴리오를 보유한 조직에 종종 적합합니다.

어떤 것을 선택해야 할까요?

대부분의 조직은 모든 데이터 자산에 걸쳐 일관된 정책, 간소화된 규정 준수, 통합된 감독을 제공하기 때문에 Unity Catalog를 사용하는 중앙 집중식 거버넌스 모델로 시작하는 것이 실용적이라고 생각합니다. 분산형 거버넌스 모델은 중앙 집중화가 비현실적인 특정 제약 조건이 있는 조직에서 고려해야 합니다. 예를 들어 자율성이 높은 BU, 특수 데이터 워크로드 또는 지역마다 다른 규제 요건이 있는 조직은 중앙 집중화가 너무 경직되어 있다고 생각할 수 있습니다.

궁극적으로 선택은 조직 구조, 규제 요구 사항, 데이터 성숙도, 협업 요구 사항과 같은 요소에 따라 달라집니다. 결정을 내리는 데 도움이 되도록 각 접근 방식의 강점과 절충안을 아래에 간략히 요약했습니다.

접근 방식에 관계없이 효과적인 거버넌스를 위해서는 카탈로그에 대한 소유권을 명확하게 매핑하고, 강력한 액세스 제어와 투명한 협업을 위한 메커니즘을 갖추어야 합니다. 이를 통해 Unity Catalog 환경이 확장됨에 따라 보안과 혁신이 함께 성장할 수 있습니다.

기술적 솔루션 분석

거버넌스 및 아키텍처의 개념적 기반이 확립되었으므로 이제 실제 데이터 자산을 UC로 마이그레이션하는 데 필요한 실질적인 엔지니어링 작업으로 초점을 전환합니다. 상위 수준의 단계(업그레이드 단계 개요 참조 [AWS | Azure | GCP])에서 수행해야 할 작업을 간략하게 설명하지만, 기술적 실행에는 복잡한 종속성 해결, 다운타임 최소화, 기존 워크플로 수용 등이 포함되는 경우가 많습니다. 실제 마이그레이션이 획일적인 경로를 따르는 경우는 드물기 때문에 팀은 현재 데이터 자산, 운영 제약 조건, 비즈니스 우선순위에 따라 접근 방식을 맞춤화해야 합니다.

이러한 복잡성을 해결하는 데 도움이 되도록 다음 섹션에서는 최신 데이터 조직을 위한 세 가지 중요한 기술적 고려 사항, 즉 현재 자산과 종속성을 파악하기 위한 사전 마이그레이션 데이터 검색, IaC(Infrastructure as Code)를 사용한 자동화된 배포, 증분 채택을 가능하게 하는 단계적 마이그레이션 전략에 대해 자세히 알아봅니다.

1. 사전 마이그레이션 데이터 검색

Hive 테이블을 마이그레이션하고 워크로드를 업데이트하기 전에 팀은 기존 데이터 환경을 이해해야 합니다. 이 검색 단계는 마이그레이션 범위를 정의하고, 위험 영역을 식별하며, 성능 저하 또는 서비스 중단을 방지하는 데 도움이 됩니다.

여기에는 HMS의 활성 테이블, 뷰, 작업, 권한, 팀을 매핑하여 Unity Catalog로 전환해야 하는 항목을 결정하는 작업이 포함됩니다. 여러 작업 공간과 방대한 데이터 볼륨을 보유한 대규모 조직의 경우 데이터 소유권, 액세스 제어, 작업 종속성을 수동으로 추적하는 것은 곧 지속 불가능한 방식이 됩니다.

UCX를 사용한 데이터 검색

이러한 우려를 해결하기 위해 Databricks Labs 는 데이터 검색, 준비 상태 평가, 마이그레이션 계획을 자동화하는 오픈 소스 도구인 UCX(AWS | Azure | GCP)를 개발했습니다. UCX는 배포 후 레거시 HMS 작업 영역을 스캔하고 관련 자산을 목록화하며 마이그레이션 작업을 안내하는 상세 보고서를 생성합니다. UCX의 평가 보고서는 스캔한 총 자산 수를 기반으로 “준비 상태” 메트릭을 제공하고, 결과를 분류하여 해결 작업의 우선순위를 정하는 데 도움을 줍니다.

UCX 결과물을 검토할 때 조직은 다음과 같이 정보에 입각한 결정을 내리기 위해 원시 개수와 준비 상태 점수 이상을 살펴봐야 합니다.

• 오래되거나 중복된 테이블을 식별하고 제외하여 마이그레이션 범위 축소
• 마지막 액세스 시간 또는 마지막 업데이트 시간과 같은 활동 신호를 확인 하여 중요한 워크로드를 사용하지 않는 데이터와 분리
• 마이그레이션 전에 중복되는 스키마를 통합하거나 명명 규칙을 표준화하여 자산 합리화
• 다운스트림 파이프라인, BI 대시보드 또는 규제 요건에 따라 먼저 이동해야 하는 것을 결정하여 종속성 우선순위 지정

이 자동화된 검색 프로세스를 통해 조직은 다음과 같은 가치를 얻을 수 있습니다.

• BU, 팀 및 해당 데이터 제품의 전체 범위 파악
• 사용자, 그룹 및 자산 간의 액세스 제어 및 종속성 매핑
• 활발하게 사용되는 테이블 및 뷰와 보관 대상 후보 식별
• 다른 워크플로는 단계적으로 중단하면서 중요한 레거시 워크플로 우선순위 지정

몇 개에서 수백 개에 이르는 Databricks 작업 영역을 관리하는 조직의 경우, UCX는 검색을 자동화하고 마이그레이션 범위를 명확히 함으로써 엔지니어링 노력을 줄여줍니다. 이는 인적 오류를 최소화하고 호환성 격차와 숨겨진 종속성을 식별하여 마이그레이션 전에 워크로드가 거버넌스 표준을 충족하도록 보장합니다.

UCX에 대한 소개는 UCX 유틸리티를 사용하여 작업 영역을 Unity Catalog로 업그레이드 (AWS | Azure | GCP)를 참조하세요.

2. 코드형 인프라(IaC)를 사용한 자동화된 배포

데이터 검색을 통해 기존 자산, 종속성, 액세스 패턴을 종합적으로 파악했다면, 다음 과제는 이를 지원하는 Unity Catalog 환경을 프로비저닝하는 것입니다. 이 환경 배포는 (적절한 관리자 권한이 있는 경우) 계정 콘솔을 통해 수동으로 수행할 수 있지만, 수동 구성 오류나 불일치를 방지하기 위해 Databricks Terraform provider 를 활용하는 것이 강력히 권장됩니다.

Terraform을 사용하면 팀은 지원되는 모든 클라우드 플랫폼에서 Unity Catalog 리소스의 생성 및 구성을 자동화하여 마이그레이션 프로세스의 재현성과 감사 가능성을 확보할 수 있습니다. 예를 들어 Databricks 계정 관리자는 계정 콘솔을 통해 Unity Catalog metastore(AWS | Azure | GCP)를 수동으로 생성할 수 있지만, 프로그래밍 방식으로 databricks_metastore 리소스를 프로비저닝하여 Terraform을 사용할 수도 있습니다. 마찬가지로 이를 사용하여 metastore 내에서 카탈로그와 스키마를 정의하고, 관리형 스토리지 구성을 적용하며, 액세스 권한을 설정할 수 있습니다. IaC의 이 더욱 강력한 접근 방식을 사용하면 일부 스크립팅(예: Terraform + REST APIs)을 통해 전체 Unity Catalog 설정을 완전히 자동화하고 템플릿화 하여 조직 내 모든 BU에서 복제할 수 있으므로 수동 프로비저닝이 전혀 필요하지 않습니다.

배포용 사용자 지정 Terraform 모듈 생성에 대한 전체 가이드는 Terraform을 사용하여 Unity Catalog 설정 자동화 (AWS | Azure | GCP)를 참조하세요.

Unity Catalog 마이그레이션에서 이 접근 방식은 팀이 다음을 수행할 수 있도록 필요한 인프라를 구축하는 데 특히 강력한 것으로 입증되었습니다.

• 환경 전반에 걸쳐 거버넌스 표준이 일관되게 적용되도록 보장
• 마이그레이션 중 잘못된 구성의 위험 최소화
• 향후 확장을 위한 거버넌스 인프라의 지속적인 제공 지원

3. 마이그레이션 전략

IaC를 통해 프로비저닝된 HMS 자산의 전체 인벤토리와 Unity Catalog 지원 작업 공간을 통해 이제 설정에서 통제되고 위험이 낮은 워크로드 마이그레이션으로 초점이 전환됩니다. 조직은 복잡성, 구조, 위험 허용 범위에 맞춰 간단한 파일럿 프로젝트부터 전사적 혁신에 이르기까지 다양한 전략을 선택할 수 있습니다.

대부분의 조직에서는 점진적인 도입 방식으로 시작하는 것이 유용하지만, 초기 파일럿 단계를 넘어 확장하려면 신중한 계획과 체계적인 실행이 필요합니다. 포괄적인 Unity Catalog 마이그레이션을 계획하고 실행하는 조직은 Databricks 계정 팀 및/또는 DSA(Delivery Solutions Architect)에 문의하여 마이그레이션 지원을 받고 전문 마이그레이션 방법론에 액세스할 수 있습니다.

파일럿 접근 방식을 통한 점진적 채택

대부분의 프로덕션 환경에서 '빅뱅' 방식의 마이그레이션은 거의 실용적이지 않습니다. 대신 Databricks는 파일럿 마이그레이션으로 시작할 것을 권장합니다. 즉, 워크로드가 일반적인 조직 패턴을 반영하고, 명확한 데이터 경계를 가지며, 참여도가 높은 이해관계자가 포함된 대표적인 BU 또는 팀을 대상으로 합니다. 이 파일럿 단계는 통제된 환경에서 도구, 프로세스 및 거버넌스 제어를 검증하여 팀이 엣지 케이스를 발견하고, 출시 순서를 구체화하며, 작업량 추정치를 개선하는 데 도움이 됩니다. 얻은 인사이트는 후속 마이그레이션의 불확실성과 위험을 줄여줍니다.

이를 통해 조직은 플랫폼 안정성을 유지하고, 이해관계자의 신뢰를 구축하며, 예측 가능한 진행을 지원하면서 단계적으로 전체 채택으로 확장할 수 있는데, 이는 전면적인 리프트 앤 시프트(lift-and-shift) 방식으로는 달성하기 어려운 이점입니다.

Databricks는 HMS에서 Unity Catalog로 워크로드를 이동하기 위한 두 가지 증분 접근 방식을 권장합니다.

옵션 A: 파이프라인별 마이그레이션

이 접근 방식은 다음 파이프라인으로 진행하기 전에 관련 테이블, 작업, 대시보드, 종속성을 포함하여 한 번에 하나의 파이프라인을 Unity Catalog로 마이그레이션하는 것입니다. 단일 파이프라인의 전체 데이터 계보와 생산자-소비자 경로를 캡슐화함으로써 이 방법은 위험을 국소화하고 후속 마이그레이션을 위해 학습한 교훈을 활용합니다. 팀은 각 Unity Catalog 전환을 개별적으로 테스트, 검증, 조정할 기회를 통해 플랫폼 전반에서 지속적인 개선과 중단 감소의 이점을 얻을 수 있습니다.

옵션 B: 계층별 마이그레이션(Gold → Silver → Bronze)

메달리온 아키텍처에 기반한 계층별 전략은 Gold(사용자 대상 분석 결과물), Silver(정제 및 중복 제거된 데이터 세트), Bronze(수집된 원시 데이터)와 같은 개별 계층을 통해 Unity Catalog 마이그레이션을 진행할 것을 권장합니다. 일부 데이터 엔지니어링 관행의 상향식 전통과는 달리, Databricks는 대시보드, BI 자산, 가시성이 높은 테이블을 포함하는 Gold 계층부터 시작하는 것을 권장하는 경우가 많습니다. 이를 통해 분석 소비자의 연속성을 유지하면서 비즈니스 영향을 줄이고 하위 계층 변경으로 인한 다운스트림 중단을 방지할 수 있습니다.

옵션 B의 마이그레이션 순서:

• 골드 레이어 우선: 먼저 골드 테이블을 Unity Catalog로 마이그레이션한 다음, 중요한 대시보드, BI 도구, 임시 쿼리를 Unity Catalog의 대체 테이블을 가리키도록 재조정합니다. 이러한 자산은 가시성이 가장 높은 경우가 많으며, 먼저 마이그레이션하면 비즈니스 운영에 대한 위험을 최소화합니다.
• 다음: 실버 레이어: Unity Catalog에서 골드 소비자가 검증되면, 이들에게 데이터를 공급하는 변환 작업과 테이블(일반적으로 실버 레이어)을 업데이트하세요. 이 단계는 더 광범위한 데이터 정제 및 적합성 프로세스를 포함합니다.
• 마지막으로 Bronze 계층: 외부 수집 작업과 원시 랜딩 테이블을 Unity Catalog로 마이그레이션하여 주기를 완료합니다. 업스트림 수집이 통합되면 전체 데이터 스택에 대한 계보가 Unity Catalog의 거버넌스 하에 놓이게 됩니다.

Databricks는 위의 마이그레이션 전략을 체계적인 운영 관행으로 보강할 것을 권장합니다. 예를 들어, 레거시 HMS 테이블에 해당하는 Unity Catalog 테이블을 참조하는 주석을 달아 사용자가 원활하게 전환하고 혼동을 피할 수 있도록 지원합니다. 레거시 테이블이나 작업을 폐기하기 전에 Unity Catalog의 모든 다운스트림 종속성을 철저히 테스트하여 워크플로가 중단되지 않도록 해야 합니다. 또한, 이제 Unity Catalog에서 관리하는 자산에 대한 작업 공간 액세스 제어를 업데이트하거나 역할을 재할당할 때 이해관계자와 지속적으로 소통하고 조율해야 합니다.

다음 섹션에서는 증분 접근 방식을 보완하는 두 가지 일반적인 마이그레이션 경로(소프트 대 하드)를 비교합니다.

마이그레이션 경로: “소프트” 대 “하드”

정의된 프레임워크 내에는 두 가지 고유한 마이그레이션 패턴이 있습니다. HMS 페더레이션을 통한 소프트 마이그레이션 은 HMS를 그대로 유지하면서(레거시 워크로드 중단 방지) 페더레이션된 자산에 대한 Unity Catalog의 고급 거버넌스 기능에 액세스할 수 있게 해주며, 하드 마이그레이션은 HMS에서 Unity Catalog로 전체 메타데이터 및 데이터 전송을 포함하지만 팀과 시스템 전반에 걸쳐 더 광범위한 계획과 조율이 필요합니다.

HMS 페더레이션을 통한 소프트 마이그레이션

소프트 마이그레이션은 '마이그레이션 브리지' 역할을 하는 하이브리드 접근 방식으로 간주되며, 팀이 레거시 HMS를 그대로 유지하면서 Unity Catalog 거버넌스 기능을 채택할 수 있도록 합니다. Hive metastore 페더레이션(AWS | Azure | GCP)을 사용하면 즉각적인 데이터 이동이나 코드 변경이 필요 없어 중단을 최소화하면서 증분 마이그레이션을 수행할 수 있습니다. Unity Catalog는 HMS 메타데이터를 미러링하는 외부 카탈로그를 생성하여 두 시스템 모두에서 워크로드를 실행할 수 있도록 합니다. 이러한 방식으로 이 페더레이션된 HMS의 외부 테이블은 일종의 하위 호환성을 제공하여 워크로드가 Hive 전용 시맨틱, 즉 레거시 2단계 네임스페이스(schema.table)를 계속 사용할 수 있게 합니다. 이를 통해 3단계 네임스페이스(catalog.schema.table)와의 호환성을 유지하면서 Unity Catalog의 거버넌스, 감사, 액세스 제어의 이점을 누릴 수 있습니다.

Unity Catalog에서 페더레이션된 데이터를 관리하고 상호 작용하는 방법은 HMS가 내부용인지 외부용인지에 따라 다릅니다. 페더레이션 커넥터는 Databricks 작업 공간 내의 내부 HMS 인스턴스에 있는 테이블에 대한 *읽기* 및 *쓰기* 액세스를 지원하는 반면,외부 HMS 및 AWS Glue 테이블은 *읽기 전용*입니다. 모든 경우에 전체 HMS 카탈로그(내부 또는 외부) 또는 AWS Glue를 Unity Catalog에 외부 카탈로그로 마운트할 수 있으며, 이들은 네이티브 객체로 표시됩니다. 테이블 메타데이터는 변경 사항이 발생할 때마다 HMS와 자동으로 동기화됩니다. 내부 HMS의 경우, 외부 카탈로그에서 생성된 모든 새 테이블이나 업데이트는 HMS에 다시 기록되어 두 환경 간의 원활한 상호 운용성을 유지합니다.

HMS 페더레이션을 통한 소프트 마이그레이션은 중단이 적은 Unity Catalog 채택 경로를 제공하지만, HMS를 완전히 폐기하려는 조직은 결국 페더레이션된 자산의 하드 마이그레이션을 수행해야 합니다. 페더레이션된 자산의 하드 마이그레이션을 자동화할 수는 있지만, 이러한 자산을 읽고/쓰는 코드는 새로운 Unity Catalog 자산을 가리키도록 해야 합니다.

또한 UCX는 (테이블 마이그레이션 프로세스의 대안으로) HMS 페더레이션을 활성화하는 CLI 도구를 제공합니다.

레거시 작업 공간 HMS, 외부 HMS 또는 AWS Glue metastore에 대한 HMS 페더레이션 설정 지침은 Unity Catalog로 마이그레이션하는 동안 Hive metastore 페더레이션을 어떻게 사용하나요? (AWS | Azure | GCP)를 참조하세요.

하드 마이그레이션

하드 마이그레이션은 HMS에서 Unity Catalog로의 포괄적인 업그레이드로, 테이블의 메타데이터(및 관리형 테이블의 데이터)를 새 metastore로 변환합니다. 이 접근 방식은 외부 테이블에는 SYNC(또는 업그레이드 마법사)와 같은 도구를, 관리형 테이블에는 CREATE TABLE CLONE(CTAS)을 결합합니다. 각 방법에는 고유한 요구 사항과 제한 사항이 있습니다.

마이그레이션해야 할 대량의 데이터가 HMS에 있는 조직의 경우, Databricks는 대부분의 테이블 마이그레이션 시나리오에 대해 UCX의 자동화된 테이블 마이그레이션 워크플로 (아래 나열된 수동 방법 대신)를 권장합니다. Hive metastore 데이터 개체 마이그레이션 을 참조하여 실행할 UCX 워크플로를 결정하고 테이블 마이그레이션에 대한 추가 컨텍스트를 얻으세요.

외부 테이블 업그레이드

외부 테이블은 SYNC 명령이나 업그레이드 마법사를 사용하여 업그레이드할 수 있습니다. 이는 메타데이터 전용 작업으로, 데이터가 복사되거나 이동되지 않습니다.

• SYNC: 테이블 메타데이터를 HMS에서 Unity Catalog로 전송하고 부기 속성을 HMS 테이블에 다시 추가하는 SQL 명령입니다. 테이블 또는 스키마 수준에서 적용할 수 있으므로 SQL 우선 팀이 마이그레이션할 대상과 시기를 세부적으로 제어할 수 있습니다.
• 업그레이드 마법사: SYNC 기능을 시각적 워크플로로 래핑하는 카탈로그 탐색기 인터페이스입니다. 포인트 앤 클릭의 단순성으로 채택을 가속화하는 대량 스키마 마이그레이션에 이상적입니다.

HMS와 Unity Catalog 테이블은 동일한 클라우드 스토리지를 참조하므로 전환 기간 동안 하이브리드 설정을 실행할 수 있습니다. 예약된 SYNC는 마이그레이션이 완료될 때까지 두 시스템에서 메타데이터를 일관되게 유지합니다.

관리형 테이블 업그레이드

관리형 테이블은 관리형 스토리지 위치에 있으므로 데이터 이동이 필요합니다(관리형 스토리지 위치란? 참조 [AWS | Azure | GCP]). 결과적으로 CREATE TABLE CLONE 또는 CREATE TABLE AS SELECT (CTAS)를 사용하여 업그레이드해야 합니다.

• CREATE TABLE CLONE (Deep Clone): 이 방법은 데이터와 메타데이터를 스토리지 계층에 직접 복사합니다. 파티셔닝, 형식, 불변성, Null 허용 여부 및 기타 메타데이터를 자동으로 보존합니다. 또한 컴퓨팅 집약적인 읽기/쓰기 주기를 피하기 때문에 CTAS보다 더 빠르게 실행됩니다.
• CREATE TABLE AS SELECT (CTAS): 관리형 Hive 테이블이 복제 요구 사항(예: Delta 형식)을 충족하지 않을 때 유용합니다. CTAS는 쿼리 결과로부터 테이블을 다시 빌드하여 프로세스 중에 선택적 마이그레이션 또는 변환을 가능하게 합니다.

관리형 테이블 마이그레이션에는 CLONE을 적극 권장하며, 소스 테이블에 조정이 필요한 경우 CTAS가 유연성을 제공합니다.

뷰 업그레이드

참조된 모든 테이블이 마이그레이션되면 뷰를 수동으로 다시 만들어야 합니다. 3단계 네임스페이스(catalog.schema.table)에 따라 테이블의 Unity Catalog 버전을 참조하는 CREATE VIEW 문을 사용합니다.

테이블 및 뷰 마이그레이션을 위한 다양한 옵션에 대한 자세한 내용은 Hive 테이블 및 뷰를 Unity Catalog로 업그레이드 (AWS | Azure | GCP)를 참조하세요.

HMS에 대한 액세스 비활성화

모든 HMS 자산이 Unity Catalog로 마이그레이션되거나 HMS가 Unity Catalog 아래의 페더레이션된 카탈로그로 페더레이션된 후에는 중앙 집중식 데이터 거버넌스의 전사적 채택을 보장하기 위해 레거시 HMS에 대한 직접 액세스를 비활성화하는 것이 중요합니다. 이 단계는 향후 쿼리, 워크로드, 데이터 검색이 Unity Catalog 액세스 제어의 적용을 받도록 하여 병렬 거버넌스 프레임워크의 필요성을 없애고 무단 사용을 방지합니다.

Databricks는 균일한 거버넌스를 시행하고 잠재적인 우회 경로를 차단하기 위해 모든 클러스터와 워크로드에 대한 직접 HMS 액세스를 한 번에 비활성화할 것을 권장합니다. 단계적 출시를 선호하는 조직의 경우, Spark 구성을 설정하여 개별 컴퓨팅 클러스터 기준으로 적용할 수도 있으며, 이를 통해 필요에 따라 증분 출시가 가능합니다(Databricks 작업 공간에서 사용하는 Hive metastore에 대한 액세스 비활성화 [AWS | Azure | GCP] 참조).

레거시 metastore를 비활성화할 경우의 영향을 이해하려면 레거시 metastore를 비활성화하면 어떻게 되나요? 를 참조하세요. (AWS | Azure | GCP).

실제 예시

Databricks를 사용하여 수천 개의 테이블과 노트북을 관리하는 대규모 글로벌 소매업체는 데이터 거버넌스 및 부서 간 협업에 있어 상당한 어려움을 겪고 있었습니다. 데이터가 여러 레거시 스토리지 환경에 걸쳐 사일로화되어 있어 권한 관리가 복잡해지고 액세스 가시성이 떨어졌으며 전사적 분석 실행이 어려웠습니다. BU는 데이터에 대한 신뢰가 부족한 경우가 많았고, 제한된 자산 가시성으로 인해 초기 마이그레이션 범위 설정이 특히 어려웠습니다.

이 블로그에 설명된 기본 원칙에 따라 이 조직은 중앙 집중식 거버넌스와 도메인 수준의 자율성 간의 균형을 맞추도록 설계된 연합형 Data Mesh라는 대상 아키텍처를 정의하는 것부터 시작했습니다(“거버넌스 모델: 중앙 집중식 대 분산형 소유권”). Databricks Labs UCX 마이그레이션 툴킷을 활용하여 포괄적인 자산 인벤토리를 수행하여 비활성 상태이거나 Unity Catalog 호환 컴퓨팅에서 실행되지 않는 워크로드를 식별했습니다(“1. 마이그레이션 전 데이터 검색”). 이러한 인사이트를 통해 가치가 높은 비즈니스 사용 사례의 우선순위를 정하고, 파일럿 후 확장(pilot-and-scale) 마이그레이션 접근 방식을 채택하고, 다운스트림 종속성 및 영향에 따라 워크플로의 순서를 정할 수 있었습니다(“3. 마이그레이션 전략”). 마이그레이션은 외부 테이블에는 SYNC를, 관리형 테이블에는 DEEP CLONE을 사용하여 단계적으로 실행되었습니다. 당시에는 사용할 수 없었던 HMS 페더레이션이 없는 상황에서, 운영 중단을 최소화하면서 점진적인 마이그레이션을 지원하기 위해 양방향 동기화 전략을 구현했습니다(“HMS 페더레이션을 통한 소프트 마이그레이션”).

마이그레이션 후 이 조직은 Unity Catalog를 통해 중앙 집중식 거버넌스를 구축하는 동시에, 비즈니스 도메인이 자체 데이터와 분석을 관리할 수 있도록 지원하는 연합형 아키텍처를 유지했습니다. 내장된 감사 및 데이터 리니지 기능은 투명성과 신뢰를 향상시켰고, 레거시 코드와 패턴을 폐기하여 기술 부채를 줄이고 운영을 간소화했습니다. 물리적 스토리지를 추상화하고 액세스를 단순화함으로써 이 조직은 비즈니스 팀이 신뢰할 수 있는 데이터를 검색, 액세스, 분석할 수 있는 문화를 조성하여 데이터 및 AI 기반 비즈니스로의 전환을 앞당겼습니다.

핵심 사항

• 확장 가능한 거버넌스는 필수적입니다: 데이터 기반 조직이 성장함에 따라 HMS와 같은 레거시 메타스토어는 최신 거버넌스 요구 사항을 지원하는 데 어려움을 겪습니다. Unity Catalog는 세분화된 액세스 제어, 리니지 추적, 다중 작업 공간 지원을 통해 통합된 거버넌스를 제공하며, 이는 복잡한 분석 및 AI 환경 전반에서 신뢰와 규정 준수를 유지하는 데 매우 중요합니다.
• 모듈식 거버넌스 아키텍처: Unity Catalog는 중앙 집중식 및 분산형(페더레이션) 거버넌스를 지원합니다. 중앙 집중식 모델은 규제 산업의 규정 준수 및 감사를 간소화하는 반면, 분산 모델은 BU에 데이터 소유권을 부여하여 가드레일을 희생하지 않고 혁신을 가속화합니다.
• 메타스토어 및 카탈로그 설계의 중요성: 신중한 메타스토어 및 카탈로그 설계는 확장 가능한 거버넌스의 기반을 형성합니다. 일관된 이름 지정 규칙 및 스토리지 경계와 결합된 카탈로그 기반 격리를 사용하는 단일 메타스토어 전략은 권한을 단순화하고 자율성을 높이며 안전한 협업을 가능하게 합니다.
• 자동화된, 위험 인식 마이그레이션: 사전 마이그레이션 검색과 Infrastructure as Code(IaC)를 결합하면 일관된 Unity Catalog 설정을 보장하고 수동 오류를 줄이며 배포를 가속화할 수 있습니다. 대표적인 파일럿으로 시작하여 점진적으로 도입하면 중단을 최소화하면서 신뢰를 쌓고 이해관계자의 동의를 얻을 수 있습니다.
• 유연한 마이그레이션 경로: HMS 페더레이션을 통한 소프트 마이그레이션은 즉각적인 코드 변경 없이 Unity Catalog 거버넌스를 단계적으로 도입할 수 있게 하는 반면, 하드 마이그레이션은 Unity Catalog의 모든 이점을 제공하고 HMS의 완전한 사용 중단을 용이하게 합니다. 올바른 경로를 선택하는 것은 운영 위험 허용 범위, 종속성 및 현대화 목표에 따라 달라집니다.

결론

Hive Metastore에서 Unity Catalog로의 마이그레이션은 진정한 데이터 인텔리전스를 실현하기 위해 통합되고 확장 가능한 거버넌스와 최적화된 데이터 운영을 추구하는 기업에게 필수적인 기본 단계입니다. 성공 여부는 규정 준수를 위한 중앙 집중식 제어든, 팀 수준의 민첩성을 위한 분산 소유권이든, 거버넌스 모델을 조직의 우선순위에 맞추는 데 달려 있습니다. 자동화된 배포, 철저한 사전 마이그레이션 검색, 단계적 도입을 결합함으로써 조직은 미션 크리티컬 워크로드의 연속성을 보장하면서 중단을 최소화할 수 있습니다. Unity Catalog의 유연하고 모듈식인 아키텍처는 안전한 협업, 셀프 서비스 분석, 포괄적인 규정 준수를 지원하여 지속적인 디지털 전환과 데이터 기반 경쟁 우위를 위한 기반을 마련합니다.

다음 단계 및 리소스

Unity Catalog 마이그레이션을 효과적으로 시작하려면 위에 설명된 전략을 적용하고 공식 Databricks 설명서를 참조하여 자세한 최신 지침을 확인하세요.

Unity Catalog 마이그레이션 추적기

이 추적기는 Unity Catalog 마이그레이션을 관리하기 위한 구조화된 템플릿을 제공하며, 문서 및 도구에 대한 기본 제공 링크와 마일스톤 완료를 추적하기 위한 상태 필드가 포함되어 있습니다.

마이그레이션 추적기: Github

Unity Catalog로 start하기

Unity Catalog에 대한 기본적인 전문 지식을 쌓으려면 다음 대화형 자율 학습 Databricks Academy 과정을 활용해 보세요(Databricks 계정 또는 이메일로 로그인해야 합니다).

• Unity Catalog 소개
• Databricks의 데이터 관리
• Unity Catalog의 데이터 액세스 제어
• 컴퓨팅 리소스 & Unity Catalog
• Unity Catalog 패턴 & 모범 사례

실제 시나리오에서 배우기

2025 Data + AI Summit에서 소개되는 고객 성공 사례와 심층 기술 세션에서 실용적인 인사이트를 얻으세요.

• Databricks 주도:
  • Unity Catalog 심층 분석: 전문가를 위한 모범 사례 및 패턴 가이드 - Data + AI Summit 2025 | Databricks
  • 쉬워진 Unity Catalog 업그레이드. Databricks Labs UCX를 위한 단계별 가이드 - Data + AI Summit 2025
  • Unity Catalog로의 업그레이드 완전 정복 — 과제, 설계 및 실행 - Data + AI Summit 2025 | Databricks (Celebal Technologies와 함께)
• 고객 사례 -
  • Schiphol Group의 Unity Catalog로의 전환 - Data + AI Summit 2025 | Databricks (Schiphol Group 및 Databricks)
  • Unity Catalog(UC) 마이그레이션 스토리: 7-Eleven에서 UCX를 사용하여 복잡한 UC 마이그레이션 방향 재설정하기 - Data + AI Summit 2025 | Databricks (7-Eleven 및 Databricks)
  • 엔터프라이즈 잠재력 발현: P&G의 대규모 Unity Catalog 배포에서 얻은 주요 인사이트 - Data + AI Summit 2025 | Databricks (P&G)

DSA: 전문가 마이그레이션 가이드

Databricks DSA(Delivery Solutions Architects) 는 조직이 Unity Catalog 마이그레이션을 성공적으로 수행하도록 안내하는 데 핵심적인 역할을 합니다. 전략적 자문 역할을 하는 DSA는 조직 고유의 실행 계획 설계를 지원하고, 마이그레이션 작업을 비즈니스 목표에 맞게 조정하며, 결과물 전달에 영향을 미치기 전에 잠재적 위험을 식별하도록 돕습니다. DSA는 데이터 엔지니어링 팀, 플랫폼 소유자, 경영진 이해관계자와 긴밀하게 협력하여, 범위 지정 및 작업 공간 평가부터 배포 및 검증에 이르기까지 마이그레이션의 각 단계가 맞춤형 솔루션을 중심으로 진행되고 더 빠른 가치 실현으로 이어지도록 합니다. DSA가 맞춤형 계획과 전문가의 감독을 통해 Unity Catalog 마이그레이션 여정을 어떻게 지원할 수 있는지 알아보려면 Databricks 계정 팀에 문의하세요.

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