주요 컨텐츠로 이동

Unity Catalog 테이블을 Snowflake에서 읽는 방법, 3단계

Unity Catalog가 이제 Snowflake, Dremio, Starburst, EMR 등과 함께 작동하여 데이터와 AI를 통합하는 데 도움을 드립니다.

How to Read Unity Catalog Tables in Snowflake, in 4 Easy Steps

발행일: 2024년 12월 9일

데이터 엔지니어링2 min read

Summary

Snowflake에서 Unity Catalog의 Iceberg REST API에 연결하여 단일 소스 데이터 파일을 Iceberg로 읽는 방법을 알아보세요.

업데이트: 이 블로그는 Snowflake가 카탈로그에서 발급한 자격 증명을 지원하도록 업데이트되었습니다.

Databricks는 개방형 데이터 레이크하우스 아키텍처를 개척했으며 형식 상호 운용성 분야를 선도해 왔습니다. 더 많은 플랫폼이 레이크하우스 아키텍처를 채택하고 상호 운용 가능한 형식 및 표준을 수용하기 시작하는 것을 보게 되어 기쁩니다. 상호 운용성을 통해 고객은 분석 및 AI 도구를 선택하여 워크로드를 처리할 때 단일 데이터 복사본을 사용하여 값비싼 데이터 중복을 줄일 수 있습니다. 특히, 저희 고객의 일반적인 패턴은 Databricks의 최고 수준의 ETL 가격/성능을 사용하여 업스트림 데이터를 처리하고 Snowflake와 같은 BI 및 분석 도구에서 액세스하는 것입니다.

Unity Catalog는 데이터 및 AI 에셋을 위한 통합되고 개방형 거버넌스 솔루션입니다. Unity Catalog의 핵심 기능은 Iceberg REST Catalog API를 구현한 것입니다. 이를 통해 메타데이터 위치를 수동으로 새로 고치지 않고도 Iceberg 호환 리더를 쉽게 사용할 수 있습니다. 

이 블로그 게시물에서는 Iceberg REST Catalog가 유용한 이유를 살펴보고 Unity Catalog 테이블을 Snowflake에서 읽는 방법에 대한 예제를 살펴보겠습니다.

 

참고: 이 기능은 클라우드 공급자 전반에 걸쳐 사용할 수 있습니다. 다음 지침은 AWS S3에 특화되어 있지만 Azure Data Lake Storage(ADLS) 또는 Google Cloud Storage(GCS)와 같은 다른 객체 스토리지 플랫폼을 사용할 수도 있습니다.

 

이미지는 1. Unity Catalog에서 Delta 테이블을 작성하고, 2. Snowflake에서 카탈로그 통합으로 Iceberg 테이블을 생성하고, 3. Snowflake에서 Iceberg로 Unity Catalog 관리 테이블을 읽을 수 있는 아키텍처를 보여줍니다.

 

Iceberg REST API 카탈로그 통합

Apache Iceberg™는 각 테이블 변경 시 새 메타데이터 파일을 생성하여 원자성과 일관성을 유지합니다. 이를 통해 불완전한 쓰기가 기존 메타데이터 파일을 손상시키지 않도록 합니다. Iceberg 카탈로그는 쓰기당 새 메타데이터를 추적합니다. 그러나 모든 엔진이 모든 Iceberg 카탈로그에 연결할 수 있는 것은 아니므로 고객은 새 메타데이터 파일 위치를 수동으로 추적해야 합니다.

Iceberg는 Iceberg REST Catalog API를 통해 엔진 및 카탈로그 간의 상호 운용성을 해결합니다. Iceberg REST 카탈로그는 표준화된 개방형 API 사양으로, Iceberg 카탈로그를 위한 통합 인터페이스이며 카탈로그 구현과 클라이언트를 분리합니다.

Unity Catalog는 2023년 Universal Format(UniForm) 출시 이후 Iceberg REST Catalog API를 구현했습니다. Unity Catalog는 최신 테이블 메타데이터를 노출하여 Apache Spark™, Apache Trino 및 Snowflake와 호환되는 모든 Iceberg 클라이언트와의 상호 운용성을 보장합니다. Unity Catalog의 Iceberg REST Catalog 엔드포인트는 외부 시스템이 테이블에 액세스하고 Liquid Clustering예측 최적화와 같은 성능 향상의 이점을 누릴 수 있도록 하는 동시에 Databricks 워크로드는 변경 데이터 피드와 같은 고급 Unity Catalog 기능을 계속 활용할 수 있습니다. 또한 Unity Catalog Iceberg REST Catalog 엔드포인트는 발급된 자격 증명을 통해 거버넌스를 확장합니다.

Snowflake의 REST API 카탈로그 통합을 사용하면 Unity Catalog의 Iceberg REST API에 연결하여 최신 메타데이터 파일 위치를 검색할 수 있습니다. 즉, Unity Catalog를 사용하면 Snowflake에서 테이블을 직접 읽을 수 있습니다. 

 

참고: 작성 시점 기준으로 Snowflake의 Iceberg REST Catalog 지원은 공개 미리 보기 상태입니다. 그러나 Unity Catalog의 Iceberg REST API는 일반적으로 사용 가능합니다.

Snowflake에서 REST 카탈로그 통합을 생성하는 데는 3단계가 있습니다.

  1. Databricks에서 Delta Lake 테이블에 UniForm을 활성화하여 Iceberg 메타데이터 생성
  2. Snowflake에 Unity Catalog를 카탈로그로 등록
  3. 데이터를 쿼할 수 있도록 Snowflake에 Iceberg 테이블 생성

시작하기

Databricks의 Unity Catalog 관리 테이블부터 시작하여 Iceberg로 읽을 수 있는지 확인하겠습니다. 그런 다음 Snowflake로 이동하여 나머지 단계를 완료합니다.

시작하기 전에 몇 가지 구성 요소가 필요합니다.

  • Unity Catalog가 포함된 Databricks 계정(새 워크스페이스의 경우 기본적으로 활성화됨)
  • AWS S3 버킷 및 IAM 권한
  • Databricks 인스턴스 및 S3에 액세스할 수 있는 Snowflake 계정

Unity Catalog 네임스페이스는 catalog_name.schema_name.table_name 형식을 따릅니다. 아래 예에서는 Databricks 테이블에 대해 uc_catalog_name.uc_schema_name.uc_table_name을 사용합니다. 

1단계: Databricks의 Delta 테이블에 UniForm 활성화

Databricks에서는 Delta Lake 테이블에 UniForm을 활성화할 수 있습니다. 기본적으로 새 테이블은 Unity Catalog에서 관리됩니다. 전체 지침은 UniForm 설명서에서 확인할 수 있지만 아래에도 포함되어 있습니다.

새 테이블의 경우 워크스페이스에서 테이블을 생성하는 동안 UniForm을 활성화할 수 있습니다.

기존 테이블이 있는 경우 ALTER TABLE 명령을 통해 이 작업을 수행할 수 있습니다.

카탈로그 탐색기의 세부 정보 탭에서 메타데이터 위치를 통해 Delta 테이블에 UniForm이 활성화되었는지 확인할 수 있습니다. 다음과 유사해야 합니다.

이미지는 카탈로그 탐색기 UI의 스크린샷을 보여줍니다.

기술 가이드 eBook

ETL 시작하기

2단계: Snowflake에 Unity Catalog 등록

Databricks에서 서비스 주체 만들기를 사용하여 워크스페이스 관리자 설정에서 해당 비밀 및 클라이언트 ID를 생성합니다. 서비스 주체 대신 디버깅 및 테스트 목적으로 개인용 토큰으로 인증할 수도 있습니다. 개발 및 프로덕션 워크로드에는 서비스 주체를 사용하는 것이 좋습니다. 이 단계에서는 <deployment-name>과 OAuth <client-id> 및 <secret> 값을 사용하여 Snowflake에서 통합을 인증해야 합니다.

이제 Snowflake 계정으로 전환합니다.

참고: Databricks와 Snowflake 간에는 혼동을 줄 수 있는 몇 가지 명명 규칙 차이가 있습니다.

  • Databricks의 “카탈로그”는 Snowflake Iceberg 카탈로그 통합 구성의 “웨어하우스”입니다.
  • Databricks의 “스키마”는 Snowflake Iceberg 카탈로그 통합의 “catalog_namespace”입니다.

아래 예에서 CATALOG_NAMESPACE 값은 Unity Catalog 테이블의 uc_schema_name임을 알 수 있습니다.

Snowflake에서 Iceberg REST 카탈로그에 대한 카탈로그 통합 만들기를 수행합니다. 이 프로세스를 따르면 다음과 같은 카탈로그 통합을 생성하게 됩니다.

REST API 카탈로그 통합은 vended credentials와 시간 기반 자동 새로고침 기능도 제공합니다.

Vended credentials에는 테이블의 스토리지 위치와 해당 위치에 액세스하기 위한 임시 액세스 자격 증명이 모두 포함됩니다. 이를 통해 클라이언트는 클라이언트의 테이블 스토리지 위치에 대한 직접 액세스를 구성하지 않고도 카탈로그를 통해 테이블에 액세스할 수 있습니다. 카탈로그에서 거버넌스를 단순화하고 중앙 집중화하기 위해 vended credentials 사용을 권장합니다. 위의 예시에서는 Snowflake가 Unity Catalog의 vended credentials를 사용하도록 REST_CONFIG 객체의 ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS 매개변수를 사용하여 구성합니다.

현재 Snowflake는 AWS S3의 테이블에 대해서만 vended credentials를 지원합니다. Azure Data Lake Storage(ADLS) 또는 Google Cloud Storage(GCS)의 테이블의 경우 Snowflake는 external volume을 사용하여 테이블 스토리지 위치에 직접 액세스해야 합니다.

자동 새로고침을 사용하면 Snowflake는 카탈로그 통합에 대해 정의된 시간 간격으로 Unity Catalog의 최신 메타데이터 위치를 폴링합니다. 그러나 자동 새로고침은 수동 새로고침과 호환되지 않으므로 사용자는 테이블 업데이트 후 시간 간격까지 기다려야 합니다. 카탈로그 통합에 구성된 REFRESH_INTERVAL_SECONDS 매개변수는 이 통합으로 생성된 모든 Snowflake Iceberg 테이블에 적용됩니다. 테이블별로 사용자 지정할 수 없습니다.

 

3단계: Snowflake에서 Apache Iceberg™ 테이블 생성

Snowflake에서 이전에 생성한 카탈로그 통합을 사용하여 Iceberg 테이블을 생성하여 Delta Lake 테이블에 연결합니다. Snowflake에서 Iceberg 테이블의 이름을 선택할 수 있으며, Databricks의 Delta Lake 테이블과 일치할 필요는 없습니다.

참고: Snowflake의 CATALOG_TABLE_NAME에 대한 올바른 매핑은 Databricks 테이블 이름입니다. 이 예시에서는 uc_table_name입니다. 카탈로그 통합에서 이미 지정했으므로 이 단계에서 카탈로그나 스키마를 지정할 필요가 없습니다.

선택적으로, 명령에 AUTO_REFRESH = TRUE를 추가하여 카탈로그 통합 시간 간격을 사용하여 자동 새로고침을 활성화할 수 있습니다. 자동 새로고침이 활성화된 경우 수동 새로고침은 비활성화된다는 점에 유의하세요.

이제 Snowflake에서 Delta Lake 테이블을 성공적으로 읽었습니다.

마무리: 연결 테스트

Databricks에서 새 행을 삽입하여 Delta 테이블 데이터를 업데이트합니다.

이전에 자동 새로고침을 활성화했다면 지정된 시간 간격에 따라 테이블이 자동으로 업데이트됩니다. 그렇지 않은 경우 ALTER ICEBERG TABLE <snowflake_table_name> REFRESH를 실행하여 수동으로 새로고침할 수 있습니다.

참고: 이전에 자동 새로고침을 활성화한 경우 수동 새로고침 명령을 실행할 수 없으며 테이블을 새로고침하려면 자동 새로고침 간격이 완료될 때까지 기다려야 합니다.

Lakehouse 아키텍처에 대한 지속적인 지원에 매우 기쁩니다. 고객은 더 이상 데이터를 복제할 필요가 없어 비용과 복잡성이 줄어듭니다. 이 아키텍처를 통해 고객은 각 워크로드에 맞는 적절한 도구를 선택할 수 있습니다.

개방형 Lakehouse의 핵심은 Delta Lake 또는 Iceberg와 같은 개방형 형식으로 데이터를 저장하는 것입니다. 독점 형식은 고객을 특정 엔진에 종속시키지만, 개방형 형식은 유연성과 이식성을 제공합니다. 플랫폼에 관계없이 상호 운용성을 위한 첫 단계로 항상 자체 데이터를 소유할 것을 권장합니다. 앞으로 몇 달 안에 Unity Catalog를 사용하여 개방형 데이터 Lakehouse를 더 쉽게 관리할 수 있는 기능을 계속 구축할 것입니다.

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

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요