Refresh directory tables automatically for Azure Blob Storage

Refresh directory tables automatically for Azure Blob Storage (Azure Blob Storage용 디렉터리 테이블 자동 새로 고침)

이 주제는 Microsoft Azure Event Grid 알림을 사용해 Azure 컨테이너용 디렉터리 테이블을 만들고 디렉터리 테이블 메타데이터를 자동으로 새로 고치는 지침을 제공해요. 이 작업은 외부 스테이지·경로의 최신 관련 파일 집합과 메타데이터를 동기화해요.

출처: Snowflake Documentation

본문

• 경로의 새 파일이 테이블 메타데이터에 추가돼요.
• 경로의 파일 변경이 테이블 메타데이터에서 업데이트돼요.
• 경로에 더 이상 없는 파일이 테이블 메타데이터에서 제거돼요.

Snowflake는 다음 유형의 blob 저장소 계정을 지원해요.

• Blob 저장소
• Data Lake Storage Gen2
• 범용 v2(General-purpose v2)

Microsoft Fabric OneLake에는 자동 새로 고침이 지원되지 않아요.

Note

Microsoft.Storage.BlobCreated와 Microsoft.Storage.BlobDeleted 이벤트만 디렉터리 테이블 새로 고침을 트리거해요. blob 저장소에 새 객체를 추가하면 이 이벤트가 트리거돼요. 디렉터리나 객체의 이름을 바꾸는 것은 이 이벤트를 트리거하지 않아요. Snowflake는 비용, 이벤트 노이즈, 지연 시간을 줄이기 위해 디렉터리 테이블에 지원되는 이벤트만 보낼 것을 권장해요.

Snowflake는 다음 Microsoft.Storage.BlobCreated API를 지원해요.

• CopyBlob
• PutBlob
• PutBlockList
• FlushWithClose
• SftpCommit

Snowflake는 다음 Microsoft.Storage.BlobDeleted API를 지원해요.

• DeleteBlob
• DeleteFile
• SftpRemove

Data Lake Storage Gen2 저장소 계정의 경우 클라이언트가 CreateFile과 FlushWithClose 작업을 사용할 때 Microsoft.Storage.BlobCreated 이벤트가 트리거돼요. SSH 파일 전송 프로토콜(SFTP)을 사용하면 Microsoft.Storage.BlobCreated 이벤트가 SftpCreate와 SftpCommit 작업으로 트리거돼요. CreateFile 또는 SftpCreate API만으로는 저장소 계정에서 파일이 커밋되었음을 나타내지 않아요. FlushWithClose 또는 SftpCommit 메시지가 전송되지 않으면 Snowflake는 디렉터리 테이블을 새로 고치지 않아요.

Note

이 주제의 작업을 수행하려면 스키마에 대한 CREATE STAGE 권한이 있는 역할을 사용해야 해요.

또한 Microsoft Azure에 대한 관리자 접근이 있어야 해요. Azure 관리자가 아니라면 Step 1: Event Grid 구독 구성의 단계를 완료하도록 Azure 관리자에게 요청해요.

Snowflake는 Azure Event Grid 이벤트 스키마만 지원해요. Azure Event Grid와 함께 사용하는 CloudEvents 스키마는 지원하지 않아요.

클라우드 플랫폼 지원

Azure Event Grid 메시지를 사용한 자동 새로 고침 트리거는 지원 클라우드 플랫폼 중 어느 곳에 호스팅된 Snowflake 계정에서도 지원돼요.

클라우드 저장소에 대한 안전한 접근 구성

Note

데이터 파일을 저장하는 Azure blob 저장소 컨테이너에 대한 안전한 접근을 이미 구성했다면 이 섹션을 건너뛸 수 있어요.

이 섹션은 클라우드 저장소에 대한 인증 책임을 Snowflake 신원 및 접근 관리(IAM) 엔티티로 위임하도록 Snowflake 저장 통합 객체를 구성하는 방법을 설명해요.

Note

이 옵션을 적극 권장해요. 클라우드 저장소 접근 시 IAM 자격 증명을 제공할 필요가 없어져요. 추가 저장소 접근 옵션은 데이터 로드용 Azure 컨테이너 구성을 참고해요.

이 섹션은 저장 통합을 사용해 Snowflake가 외부(Azure) 스테이지에서 참조되는 Azure 컨테이너에서 데이터를 읽고 쓰게 하는 방법을 설명해요. 통합은 시크릿 키나 접근 토큰 같은 명시적 클라우드 공급자 자격 증명을 전달할 필요가 없게 하는 명명된 일급(first-class) Snowflake 객체예요. 통합 객체는 앱 등록(app registration) 이라고 하는 Azure 신원 및 접근 관리(IAM) 사용자 ID를 저장해요. 조직의 관리자가 Azure 계정에서 이 앱에 필요한 권한을 부여해요.

통합은 또한 사용자가 통합을 사용하는 외부 스테이지를 만들 때 지정할 수 있는 위치를 제한하는 컨테이너(및 선택적 경로)를 지정해야 해요.

Note

이 섹션의 지침을 완료하려면 저장소 계정을 관리할 Azure 권한이 필요해요. Azure 관리자가 아니라면 Azure 관리자에게 이 작업을 수행하도록 요청해요.

Step 1: Snowflake에서 클라우드 저장 통합 생성

CREATE STORAGE INTEGRATION 명령으로 저장 통합을 만들어요. 저장 통합은 Azure 클라우드 저장소용으로 생성된 서비스 주체와 함께 선택적 허용·차단 저장 위치(즉, 컨테이너) 집합을 저장하는 Snowflake 객체예요. 조직의 클라우드 공급자 관리자가 생성된 서비스 주체에 저장 위치에 대한 권한을 부여해요. 이 옵션은 사용자가 스테이지를 만들거나 데이터를 로드할 때 자격 증명을 제공하지 않게 해줘요.

단일 저장 통합은 여러 외부(즉, Azure) 스테이지를 지원할 수 있어요. 스테이지 정의의 URL은 STORAGE_ALLOWED_LOCATIONS 파라미터에 지정된 Azure 컨테이너(및 선택적 경로)와 일치해야 해요.

Note

계정 관리자(ACCOUNTADMIN 역할을 가진 사용자) 또는 전역 CREATE INTEGRATION 권한이 있는 역할만 이 SQL 명령을 실행할 수 있어요.

CREATE STORAGE INTEGRATION <integration_name>
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'AZURE'
  ENABLED = TRUE
  AZURE_TENANT_ID = '<tenant_id>'
  STORAGE_ALLOWED_LOCATIONS = ('azure://<account>.blob.core.windows.net/<container>/<path>/', 'azure://<account>.blob.core.windows.net/<container>/<path>/')
  [ STORAGE_BLOCKED_LOCATIONS = ('azure://<account>.blob.core.windows.net/<container>/<path>/', 'azure://<account>.blob.core.windows.net/<container>/<path>/') ]

여기서:

• *integration_name*은 새 통합의 이름이에요.
• *tenant_id*는 허용·차단 저장소 계정이 속한 Office 365 테넌트의 ID예요. 저장 통합은 하나의 테넌트에만 인증할 수 있으므로 허용·차단 저장 위치는 모두 이 테넌트에 속한 저장소 계정을 가리켜야 해요.

테넌트 ID를 찾으려면 Azure 포털에 로그인하고 Azure Active Directory » Properties를 클릭해요. 테넌트 ID는 Tenant ID 필드에 표시돼요.

• *container*는 데이터 파일을 저장하는 Azure 컨테이너의 이름(예: mycontainer)이에요. STORAGE_ALLOWED_LOCATIONS와 STORAGE_BLOCKED_LOCATIONS 파라미터는 이 통합을 참조하는 스테이지가 생성되거나 수정될 때 각각 이러한 컨테이너에 대한 접근을 허용하거나 차단해요.
• *path*는 컨테이너의 논리적 디렉터리에 대한 세밀한 제어를 제공하는 데 사용할 수 있는 선택적 경로예요.

다음 예는 이 통합을 사용하는 외부 스테이지를 두 컨테이너·경로 중 하나만 참조하도록 명시적으로 제한하는 통합을 만들어요. 이후 단계에서 이러한 컨테이너·경로 중 하나를 참조하는 외부 스테이지를 만들 거예요. 이 통합을 사용하는 여러 외부 스테이지가 허용된 컨테이너·경로를 참조할 수 있어요:

CREATE STORAGE INTEGRATION azure_int
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'AZURE'
  ENABLED = TRUE
  AZURE_TENANT_ID = 'a123b4c5-1234-123a-a12b-1a23b45678c9'
  STORAGE_ALLOWED_LOCATIONS = ('azure://myaccount.blob.core.windows.net/mycontainer1/mypath1/', 'azure://myaccount.blob.core.windows.net/mycontainer2/mypath2/')
  STORAGE_BLOCKED_LOCATIONS = ('azure://myaccount.blob.core.windows.net/mycontainer1/mypath1/sensitivedata/', 'azure://myaccount.blob.core.windows.net/mycontainer2/mypath2/sensitivedata/');

Step 2: Snowflake에 저장 위치 접근 부여

1. DESCRIBE INTEGRATION 명령을 실행해 동의 URL을 검색해요:

DESC STORAGE INTEGRATION <integration_name>;

여기서:

• *integration_name*은 Step 1: Snowflake에서 클라우드 저장 통합 생성에서 만든 통합의 이름이에요.

다음 컬럼의 값을 기록해요.

AZURE_CONSENT_URL:

Microsoft 권한 요청 페이지에 대한 URL.

AZURE_MULTI_TENANT_APP_NAME:

계정용으로 만들어진 Snowflake 클라이언트 애플리케이션의 이름. 이 섹션의 이후 단계에서 이 애플리케이션에 허용된 저장 위치에서 접근 토큰을 얻는 데 필요한 권한을 부여해야 해요.

1. 웹 브라우저에서 AZURE_CONSENT_URL 컬럼의 URL로 이동해요. 페이지에 Microsoft 권한 요청 페이지가 표시돼요.
2. Accept 버튼을 클릭해요. 이 작업은 Snowflake 계정용으로 만들어진 Azure 서비스 주체가 테넌트 내 지정된 리소스에 대한 접근 토큰을 부여받게 해요. 접근 토큰 획득은 컨테이너에 서비스 주체에게 적절한 권한을 부여한 경우에만 성공해요(다음 단계 참고). Microsoft 권한 요청 페이지는 Snowflake 기업 사이트(snowflake.com)로 리디렉션해요.
3. Microsoft Azure 포털에 로그인해요.
4. Azure Services » Storage Accounts로 이동해요. Snowflake 서비스 주체에 접근을 부여하는 저장소 계정의 이름을 클릭해요.
5. Access Control (IAM) » Add role assignment을 클릭해요.
6. Snowflake 서비스 주체에 부여할 원하는 역할을 선택해요.
   • Storage Blob Data Reader는 읽기 접근만 부여해요. 저장소 계정에 스테이징된 파일에서 데이터를 로드할 수 있게 해요.
   • Storage Blob Data Contributor는 읽기·쓰기 접근을 부여해요. 저장소 계정에 스테이징된 파일에서 데이터를 로드하거나 그 파일로 데이터를 언로드할 수 있게 해요. 또한 REMOVE 명령을 실행해 저장소 계정에 스테이징된 파일을 제거할 수도 있게 해요.
7. Snowflake 서비스 주체를 검색해요. 이것은 DESC STORAGE INTEGRATION 출력(Step 1에서)의 AZURE_MULTI_TENANT_APP_NAME 속성의 신원이에요. AZURE_MULTI_TENANT_APP_NAME 속성에서 밑줄 앞의 문자열을 검색해요.

Important

• Azure가 이 섹션의 Microsoft 요청 페이지를 통해 요청된 Snowflake 서비스 주체를 만드는 데 한 시간 이상 걸릴 수 있어요. 서비스 주체를 즉시 사용할 수 없으면 한두 시간 기다렸다가 다시 검색할 것을 권장해요.
• 서비스 주체를 삭제하면 저장 통합이 작동을 멈춰요.

1. Review + assign 버튼을 클릭해요.

Note

• Microsoft Azure 문서에 따르면 역할 할당은 전파에 최대 5분이 걸릴 수 있어요.
• Snowflake는 임시 자격 증명을 60분 만료 시간을 초과할 수 없는 기간 동안 캐시해요. Snowflake에서 접근을 회수하면 캐시가 만료될 때까지 사용자가 클라우드 저장 위치의 파일을 나열하고 데이터를 로드할 수 있을 수 있어요.

Note

SYSTEM$VALIDATE_STORAGE_INTEGRATION 함수를 사용해 저장 통합 구성을 검증할 수 있어요.

Azure Event Grid로 자동화 구성

Step 1: Event Grid 구독 구성

이 섹션은 Azure CLI를 사용해 Azure Storage 이벤트용 Event Grid 구독을 설정하는 방법을 설명해요. 이 섹션에 설명된 단계에 대한 자세한 내용은 Azure 문서의 다음 문서를 참고해요.

• https://docs.microsoft.com/en-us/azure/event-grid/custom-event-to-queue-storage
• https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-event-quickstart

리소스 그룹 생성

Event Grid 토픽은 소스(즉, Azure Storage)가 이벤트를 보내는 엔드포인트를 제공해요. 토픽은 관련 이벤트 집합에 사용돼요. Event Grid 토픽은 Azure 리소스이며 Azure 리소스 그룹에 배치되어야 해요.

리소스 그룹을 만들려면 다음 명령을 실행해요:

az group create --name <resource_group_name> --location <location>

여기서:

• *resource_group_name*은 새 리소스 그룹의 이름이에요.
• *location*은 Azure Storage 계정의 위치, 즉 Snowflake 용어로 리전이에요.

Event Grid 리소스 공급자 활성화

Event Grid 리소스 공급자를 등록하려면 다음 명령을 실행해요. 이 단계는 Azure 계정에서 Event Grid를 이전에 사용한 적이 없는 경우에만 필요하다는 점을 주목해요:

az provider register --namespace Microsoft.EventGrid
az provider show --namespace Microsoft.EventGrid --query "registrationState"

데이터 파일용 저장소 계정 생성

데이터 파일을 저장할 저장소 계정을 만들려면 다음 명령을 실행해요. 이 계정은 Blob 저장소(즉, BlobStorage 종류) 또는 GPv2(즉, StorageV2 종류) 계정이어야 해요. 이 두 계정 유형만 이벤트 메시지를 지원하기 때문이에요.

Note

이미 Blob 저장소나 GPv2 계정이 있다면 대신 그 계정을 사용할 수 있어요.

예를 들어 Blob 저장소 계정을 만들어요:

az storage account create --resource-group <resource_group_name> --name <storage_account_name> --sku Standard_LRS --location <location> --kind BlobStorage --access-tier Hot

여기서:

• *resource_group_name*은 리소스 그룹 생성에서 만든 리소스 그룹의 이름이에요.
• *storage_account_name*은 새 저장소 계정의 이름이에요.
• *location*은 Azure Storage 계정의 위치에요.

저장소 큐용 저장소 계정 생성

저장소 큐를 호스팅할 저장소 계정을 만들려면 다음 명령을 실행해요. 이 계정은 GPv2 계정이어야 해요. 이 종류의 계정만 저장소 큐에 이벤트 메시지를 지원하기 때문이에요.

Note

이미 GPv2 계정이 있다면 그 계정으로 데이터 파일과 저장소 큐 둘 다 호스팅할 수 있어요.

예를 들어 GPv2 계정을 만들어요:

az storage account create --resource-group <resource_group_name> --name <storage_account_name> --sku Standard_LRS --location <location> --kind StorageV2

여기서:

• *resource_group_name*은 리소스 그룹 생성에서 만든 리소스 그룹의 이름이에요.
• *storage_account_name*은 새 저장소 계정의 이름이에요.
• *location*은 Azure Storage 계정의 위치에요.

저장소 큐 생성

단일 Azure Queue Storage 큐가 많은 Event Grid 구독의 이벤트 메시지를 수집할 수 있어요. 최상의 성능을 위해 Snowflake는 Snowflake와 관련된 모든 구독을 수용할 단일 저장소 큐를 만들 것을 권장해요.

저장소 큐를 만들려면 다음 명령을 실행해요. 저장소 큐는 메시지 집합을 저장하며, 이 경우 Event Grid의 이벤트 메시지예요:

az storage queue create --name <storage_queue_name> --account-name <storage_account_name>

여기서:

• *storage_queue_name*은 새 저장소 큐의 이름이에요.
• *storage_account_name*은 저장소 큐용 저장소 계정 생성에서 만든 저장소 계정의 이름이에요.

참조용으로 저장소 계정과 큐 ID 내보내기

이후 이 지침에서 요청될 저장소 계정·큐 ID에 대한 환경 변수를 설정하려면 다음 명령을 실행해요.

• Linux 또는 macOS:

export storageid=$(az storage account show --name <data_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
export queuestorageid=$(az storage account show --name <queue_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
export queueid="$queuestorageid/queueservices/default/queues/<storage_queue_name>"

• Windows:

set storageid=$(az storage account show --name <data_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
set queuestorageid=$(az storage account show --name <queue_storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
set queueid="%queuestorageid%/queueservices/default/queues/<storage_queue_name>"

여기서:

• *data_storage_account_name*은 데이터 파일용 저장소 계정 생성에서 만든 저장소 계정의 이름이에요.
• *queue_storage_account_name*은 저장소 큐용 저장소 계정 생성에서 만든 저장소 계정의 이름이에요.
• *resource_group_name*은 리소스 그룹 생성에서 만든 리소스 그룹의 이름이에요.
• *storage_queue_name*은 저장소 큐 생성에서 만든 저장소 큐의 이름이에요.

Event Grid 확장 설치

Azure CLI용 Event Grid 확장을 설치하려면 다음 명령을 실행해요:

az extension add --name eventgrid

Event Grid 구독 생성

Event Grid 구독을 만들려면 다음 명령을 실행해요. 토픽 구독은 Event Grid에 어떤 이벤트를 추적할지 알려 줘요:

• Linux 또는 macOS:

az eventgrid event-subscription create \
--source-resource-id $storageid \
--name <subscription_name> --endpoint-type storagequeue \
--endpoint $queueid \
--advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose SftpCommit DeleteBlob DeleteFile SftpRemove

• Windows:

az eventgrid event-subscription create \
--source-resource-id %storageid% \
--name <subscription_name> --endpoint-type storagequeue \
--endpoint %queueid% \
-advanced-filter data.api stringin CopyBlob PutBlob PutBlockList FlushWithClose SftpCommit DeleteBlob DeleteFile SftpRemove

여기서:

• *storageid*와 *queueid*는 참조용으로 저장소 계정과 큐 ID 내보내기에서 설정한 저장소 계정·큐 ID 환경 변수예요.
• *subscription_name*은 새 Event Grid 구독의 이름이에요.

Step 2: 알림 통합 생성

알림 통합은 Snowflake와 Azure Event Grid 같은 타사 클라우드 메시지 큐 서비스 사이의 인터페이스를 제공하는 Snowflake 객체예요.

Note

단일 알림 통합은 단일 Azure Storage 큐를 지원해요. 여러 알림 통합에서 같은 저장소 큐를 참조하면 이벤트 알림이 알림 통합 간에 분할되므로 대상 테이블의 데이터가 누락될 수 있어요.

저장소 큐 URL과 테넌트 ID 검색

1. Microsoft Azure 포털에 로그인해요.
2. Storage account » Queue service » Queues로 이동해요. 저장소 큐 생성에서 만든 큐의 URL을 나중에 참조하기 위해 기록해요. URL 형식은 다음과 같아요:

https://<storage_account_name>.queue.core.windows.net/<storage_queue_name>

1. Azure Active Directory » Properties로 이동해요. 나중에 참조하기 위해 Tenant ID 값을 기록해요. 디렉터리 ID, 즉 테넌트 ID는 Snowflake에 Event Grid 구독 접근을 부여하는 동의 URL을 생성하는 데 필요해요.

알림 통합 생성

CREATE NOTIFICATION INTEGRATION 명령으로 알림 통합을 만들어요.

Note

• 계정 관리자(ACCOUNTADMIN 역할을 가진 사용자) 또는 전역 CREATE INTEGRATION 권한이 있는 역할만 이 SQL 명령을 실행할 수 있어요.
• 알림 통합용 Azure 서비스 주체는 저장 통합용으로 만든 서비스 주체와 달라요.

CREATE NOTIFICATION INTEGRATION <integration_name>
  ENABLED = true
  TYPE = QUEUE
  NOTIFICATION_PROVIDER = AZURE_STORAGE_QUEUE
  AZURE_STORAGE_QUEUE_PRIMARY_URI = '<queue_URL>'
  AZURE_TENANT_ID = '<directory_ID>';

여기서:

• *integration_name*은 새 통합의 이름이에요.
• *queue_URL*과 *directory_ID*는 저장소 큐 URL과 테넌트 ID 검색에서 기록한 큐 URL과 테넌트 ID예요.

예:

CREATE NOTIFICATION INTEGRATION my_notification_int
  ENABLED = true
  TYPE = QUEUE
  NOTIFICATION_PROVIDER = AZURE_STORAGE_QUEUE
  AZURE_STORAGE_QUEUE_PRIMARY_URI = 'https://myqueue.queue.core.windows.net/mystoragequeue'
  AZURE_TENANT_ID = 'a123bcde-1234-5678-abc1-9abc12345678';

Snowflake에 저장소 큐 접근 부여

이 섹션의 특정 단계에는 Azure CLI의 로컬 설치가 필요하다는 점을 주목해요.

1. DESCRIBE INTEGRATION 명령을 실행해 동의 URL을 검색해요:

DESC NOTIFICATION INTEGRATION <integration_name>;

여기서:

• *integration_name*은 알림 통합 생성에서 만든 통합의 이름이에요.

다음 컬럼의 값을 기록해요.

AZURE_CONSENT_URL:

Microsoft 권한 요청 페이지에 대한 URL.

AZURE_MULTI_TENANT_APP_NAME:

계정용으로 만들어진 Snowflake 클라이언트 애플리케이션의 이름. 이 섹션의 이후 단계에서 이 애플리케이션에 허용된 토픽에서 접근 토큰을 얻는 데 필요한 권한을 부여해야 해요.

1. 웹 브라우저에서 AZURE_CONSENT_URL 컬럼의 URL로 이동해요. 페이지에 Microsoft 권한 요청 페이지가 표시돼요.
2. Accept 버튼을 클릭해요. 이 작업은 Snowflake 계정용으로 만들어진 Azure 서비스 주체가 테넌트 내 어떤 리소스에서든 접근 토큰을 얻을 수 있게 해요. 접근 토큰 획득은 컨테이너에 서비스 주체에게 적절한 권한을 부여한 경우에만 성공해요(다음 단계 참고). Microsoft 권한 요청 페이지는 Snowflake 기업 사이트(snowflake.com)로 리디렉션해요.
3. Microsoft Azure 포털에 로그인해요.
4. Azure Active Directory » Enterprise applications로 이동해요. 이 섹션의 Step 2에서 기록한 Snowflake 애플리케이션 식별자가 나열되어 있는지 확인해요.

Important

나중에 Azure Active Directory에서 Snowflake 애플리케이션을 삭제하면 알림 통합이 작동을 멈춰요.

1. Queues » *storage_queue_name*으로 이동해요. 여기서 *storage_queue_name*은 저장소 큐 생성에서 만든 저장소 큐의 이름이에요.
2. Access Control (IAM) » Add role assignment을 클릭해요.
3. Snowflake 서비스 주체를 검색해요. 이것은 DESC NOTIFICATION INTEGRATION 출력(Step 1에서)의 AZURE_MULTI_TENANT_APP_NAME 속성의 신원이에요. AZURE_MULTI_TENANT_APP_NAME 속성에서 밑줄 앞의 문자열을 검색해요.

Important

• Azure가 이 섹션의 Microsoft 요청 페이지를 통해 요청된 Snowflake 서비스 주체를 만드는 데 한 시간 이상 걸릴 수 있어요. 서비스 주체를 즉시 사용할 수 없으면 한두 시간 기다렸다가 다시 검색할 것을 권장해요.
• 서비스 주체를 삭제하면 알림 통합이 작동을 멈춰요.

1. Snowflake 앱에 다음 권한을 부여해요.

   • Role: Storage Queue Data Message Processor(최소 필요 역할) 또는 Storage Queue Data Contributor.
   • Assign access to: Azure AD 사용자, 그룹 또는 서비스 주체.
   • Select: appDisplayName 값.

   Snowflake 애플리케이션 식별자가 이제 Storage Queue Data Message Processor 또는 Storage Queue Data Contributor 아래(같은 대화 상자에서) 나열되어야 해요.

Step 3: 디렉터리 테이블이 포함된 스테이지 생성

CREATE STAGE 명령으로 Azure 컨테이너를 참조하는 외부 스테이지를 만들어요. Snowflake가 스테이징된 데이터 파일을 디렉터리 테이블 메타데이터로 읽어요. 또는 기존 외부 스테이지를 사용할 수 있어요.

Note

• 클라우드 저장소 위치에 대한 안전한 접근을 구성하려면 클라우드 저장소에 대한 안전한 접근 구성을 참고해요(이 주제에서).
• CREATE STAGE 문에서 저장 통합을 참조하려면 역할이 저장 통합 객체에 대한 USAGE 권한이 있어야 해요.

-- External stage
CREATE [ OR REPLACE ] [ TEMPORARY ] STAGE [ IF NOT EXISTS ] <external_stage_name>
      <cloud_storage_access_settings>
    [ FILE_FORMAT = ( { FORMAT_NAME = '<file_format_name>' | TYPE = { CSV | JSON | AVRO | ORC | PARQUET | XML } [ formatTypeOptions ] } ) ]
    [ directoryTable ]
    [ COPY_OPTIONS = ( copyOptions ) ]
    [ COMMENT = '<string_literal>' ]

여기서:

directoryTable (for Microsoft Azure) ::=
  [ DIRECTORY = ( ENABLE = { TRUE | FALSE }
                  [ AUTO_REFRESH = { TRUE | FALSE } ]
                  [ NOTIFICATION_INTEGRATION = '<notification_integration_name>' ] ) ]

디렉터리 테이블 파라미터(directoryTable)

ENABLE = { TRUE | FALSE }

스테이지에 디렉터리 테이블을 추가할지 여부를 지정해요. 값이 TRUE이면 스테이지와 함께 디렉터리 테이블이 생성돼요.

기본값: FALSE

AUTO_REFRESH = { TRUE | FALSE }

URL 값에 지정된 명명된 외부 스테이지에 새 데이터 파일이나 업데이트된 데이터 파일이 있을 때 Snowflake가 디렉터리 테이블 메타데이터의 자동 새로 고침 트리거를 활성화할지 여부를 지정해요.

TRUE

Snowflake가 디렉터리 테이블 메타데이터의 자동 새로 고침 트리거를 활성화해요.

FALSE

Snowflake가 디렉터리 테이블 메타데이터의 자동 새로 고침 트리거를 활성화하지 않아요. ALTER STAGE … REFRESH로 디렉터리 테이블 메타데이터를 주기적으로 수동으로 새로 고쳐 스테이지 경로의 현재 파일 목록과 동기화해야 해요.

기본값: FALSE

Microsoft Azure

NOTIFICATION_INTEGRATION = '<notification_integration_name>'

Azure Event Grid 알림으로 디렉터리 테이블 메타데이터를 자동으로 새로 고치는 데 사용되는 알림 통합의 이름을 지정해요. 알림 통합은 Snowflake와 타사 클라우드 메시지 큐 서비스 사이의 인터페이스를 제공하는 Snowflake 객체예요.

다음 예는 사용자 세션의 활성 스키마에 mystage라는 스테이지를 만들어요. 클라우드 저장소 URL에는 files 경로가 포함돼요. 스테이지는 my_storage_int라는 저장 통합을 참조해요.

USE SCHEMA mydb.public;

CREATE STAGE mystage
  URL='azure://myaccount.blob.core.windows.net/load/files/'
  STORAGE_INTEGRATION = my_storage_int
  DIRECTORY = (
    ENABLE = true
    AUTO_REFRESH = true
    NOTIFICATION_INTEGRATION = 'MY_NOTIFICATION_INT'
  );

Note

• Data Lake Storage Gen2를 포함한 모든 지원 유형의 Azure blob 저장소 계정에 대해 blob.core.windows.net 엔드포인트를 사용해요.
• URL 값의 저장 위치는 앞 슬래시(/)로 끝나야 해요.

NOTIFICATION_INTEGRATION 파라미터는 Step 2: 알림 통합 생성에서 만든 my_notification_int 통합을 참조해요. 통합 이름은 모두 대문자로 제공해야 해요.

새 데이터 파일이나 업데이트된 데이터 파일이 클라우드 저장소 위치에 추가되면 이벤트 알림이 Snowflake에 그것들을 디렉터리 테이블 메타데이터로 스캔하도록 알려요.

Step 4: 디렉터리 테이블 메타데이터를 수동으로 새로 고침

디렉터리 테이블의 메타데이터를 ALTER STAGE 명령으로 수동으로 새로 고쳐요.

구문

ALTER STAGE [ IF EXISTS ] <name> REFRESH [ SUBPATH = '<relative-path>' ]

여기서:

REFRESH

디렉터리 테이블 정의에서 참조된 스테이징된 데이터 파일에 접근하고 테이블 메타데이터를 업데이트해요.

• 경로의 새 파일이 테이블 메타데이터에 추가돼요.
• 경로의 파일 변경이 테이블 메타데이터에서 업데이트돼요.
• 경로에 더 이상 없는 파일이 테이블 메타데이터에서 제거돼요.

현재 이 명령은 파일이 스테이지에 추가, 업데이트, 삭제될 때마다 실행해야 해요. 이 단계는 디렉터리 테이블의 스테이지 정의에서 메타데이터를 최신 관련 파일 집합과 동기화해요.

SUBPATH = '<relative-path>'

선택적으로 상대 경로를 지정해 데이터 파일의 특정 부분집합에 대한 메타데이터를 새로 고쳐요.

예

mystage라는 스테이지의 디렉터리 테이블 메타데이터를 수동으로 새로 고쳐요:

ALTER STAGE mystage REFRESH;

Important

디렉터리 테이블이 생성된 후 이 단계가 적어도 한 번 성공적으로 완료되지 않으면, 알림 이벤트가 디렉터리 테이블 메타데이터를 처음으로 자동 새로 고침을 트리거할 때까지 디렉터리 테이블을 쿼리해도 결과가 반환되지 않아요.

Step 5: 보안 구성

디렉터리 테이블을 쿼리하는 데 사용될 각 추가 역할에 대해 GRANT … TO ROLE을 사용해 다양한 객체(즉, 데이터베이스(들), 스키마(들), 스테이지, 테이블)에 충분한 접근 제어 권한을 부여해요.

객체	권한	참고
데이터베이스	USAGE
스키마	USAGE
명명된 스테이지	USAGE, READ
명명된 파일 형식	USAGE	선택 사항; 만든 스테이지가 명명된 파일 형식을 참조하는 경우에만 필요.

더 알아보기 (Learn more)

• Automated directory table metadata refreshes — 자동 새로 고침
• Directory tables — 디렉터리 테이블
• CREATE NOTIFICATION INTEGRATION — 알림 통합 생성
• CREATE STAGE — 스테이지 생성