Microsoft Azure Blob Storage용 Snowpipe 자동화

이 주제는 Microsoft Azure Event Grid 메시지를 Blob 스토리지 이벤트에 사용해 Azure Blob Storage의 외부 스테이지에서 Snowpipe 데이터 로드를 자동으로 트리거하는 지침을 제공해요. 지침은 데이터 파일이 저장된 Blob 스토리지의 대상 경로에 대한 이벤트 메시지를 만드는 방법을 설명해요.

참고 — 보안 태세를 강화하려면 네트워크 트래픽에 공용 인터넷 대신 프라이빗 연결을 사용하도록 Snowpipe 자동화를 구성할 수 있어요. 자세한 내용은 Microsoft Azure용 외부 스테이지 및 Snowpipe 자동화에 대한 프라이빗 연결을 참고해요.

Snowflake는 다음 유형의 blob 스토리지 계정을 지원해요.

Blob 스토리지
Data Lake Storage Gen2
범용 v2(General-purpose v2)

참고

Microsoft Fabric OneLake에는 자동 Snowpipe가 지원되지 않아요.

Microsoft.Storage.BlobCreated 이벤트만 Snowpipe가 파일을 로드하도록 트리거해요. blob 스토리지에 새 객체를 추가하면 이러한 이벤트가 트리거돼요. 디렉터리나 객체 이름을 바꾸는 것은 이러한 이벤트를 트리거하지 않아요.

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

CopyBlob
PutBlob
PutBlockList
FlushWithClose
SftpCommit

Snowflake는 비용, 이벤트 노이즈, 지연 시간을 줄이기 위해 Snowpipe에 지원되는 이벤트만 보낼 것을 권장해요.

Data Lake Storage Gen2 스토리지 계정의 경우 클라이언트가 CreateFile 및 FlushWithClose 작업을 사용하면 Microsoft.Storage.BlobCreated 이벤트가 트리거돼요. SSH 파일 전송 프로토콜(SFTP)을 사용하면 SftpCreate 및 SftpCommit 작업으로 Microsoft.Storage.BlobCreated 이벤트가 트리거돼요. CreateFile 또는 SftpCreate API만으로는 스토리지 계정에서 파일의 커밋을 나타내지 않아요. FlushWithClose 또는 SftpCommit 메시지가 Snowflake 큐로 전송되지 않으면 Snowpipe는 파일을 수집하지 않아요.

참고 — Snowflake는 Azure Event Grid 이벤트 스키마만 지원하며, Azure Event Grid와 함께하는 CloudEvents 스키마는 지원하지 않아요.

출처: Documentation

본문

클라우드 플랫폼 지원

Azure Event Grid 메시지를 사용한 자동 Snowpipe 데이터 로드 트리거는 모든 지원되는 클라우드 플랫폼에 호스팅된 Snowflake 계정에서 지원돼요.

프로세스 흐름

Azure 컨테이너에 대한 Microsoft Azure Event Grid 알림이 Snowpipe 데이터 로드를 자동으로 트리거해요.

Snowpipe 자동 수집 프로세스 흐름:

데이터 파일이 스테이지에 로드됐어요.
blob 스토리지 이벤트 메시지가 Event Grid를 통해 파일을 로드할 준비가 되었음을 Snowpipe에 알려줘요. Snowpipe는 파일을 큐에 복사해요.
Snowflake가 제공하는 가상 웨어하우스가 지정된 파이프에 정의된 매개 변수에 따라 큐에 있는 파일의 데이터를 대상 테이블에 로드해요.

클라우드 스토리지에 대한 보안 액세스 구성

참고 — 데이터 파일을 저장하는 Azure blob 스토리지 컨테이너에 대한 보안 액세스를 이미 구성했다면 이 섹션을 건너뛸 수 있어요.

이 섹션은 클라우드 스토리지의 인증 책임을 Snowflake IAM(Identity and Access Management) 엔터티에 위임하도록 Snowflake 스토리지 통합 객체를 구성하는 방법을 설명해요.

참고 — 이 옵션을 매우 권장해요. 클라우드 스토리지에 접근할 때 IAM 자격 증명을 제공할 필요가 없어져요. 추가 스토리지 액세스 옵션은 데이터 로드를 위한 Azure 컨테이너 구성을 참고해요.

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

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

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

1단계: Snowflake에서 클라우드 스토리지 통합 만들기

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

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

참고 — 계정 관리자(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를 클릭해요. Tenant ID 필드에 테넌트 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/');

2단계: Snowflake에 스토리지 위치 액세스 부여

DESCRIBE INTEGRATION 명령을 실행해 동의(consent) URL을 검색해요.

DESC STORAGE INTEGRATION <integration_name>;

여기서:

*integration_name*은 (이 주제의) 1단계: Snowflake에서 클라우드 스토리지 통합 만들기에서 만든 통합의 이름.

다음 열의 값을 기록해요.

AZURE_CONSENT_URL: Microsoft 권한 요청 페이지의 URL.
AZURE_MULTI_TENANT_APP_NAME: 계정을 위해 만들어진 Snowflake 클라이언트 애플리케이션의 이름. 이 섹션의 이후 단계에서 이 애플리케이션에 허용된 스토리지 위치에서 액세스 토큰을 얻는 데 필요한 권한을 부여해야 해요.

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

중요

Azure가 이 섹션의 Microsoft 요청 페이지를 통해 요청된 Snowflake 서비스 주체를 만드는 데 1시간 이상 걸릴 수 있어요. 서비스 주체가 즉시 사용할 수 없으면 한두 시간 기다린 다음 다시 검색할 것을 권장해요.

서비스 주체를 삭제하면 스토리지 통합이 작동을 멈춰요.

Review + assign 버튼을 클릭해요.

참고

Microsoft Azure 문서에 따르면 역할 할당이 전파되는 데 최대 5분이 걸릴 수 있어요.

Snowflake는 60분 만료 시간을 초과할 수 없는 기간 동안 임시 자격 증명을 캐시해요. Snowflake에서 액세스를 취소하면 사용자는 캐시가 만료될 때까지 클라우드 스토리지 위치에서 파일을 나열하고 데이터를 로드할 수 있을 수 있어요.

참고 — SYSTEM$VALIDATE_STORAGE_INTEGRATION 함수를 사용해 스토리지 통합의 구성을 검증할 수 있어요.

Azure Event Grid로 자동화 구성

1단계: Event Grid 구독 구성

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

리소스 그룹 만들기

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 종류) 계정이어야 해요. 이 두 계정 유형만 이벤트 메시지를 지원하기 때문이에요.

참고 — 이미 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 계정이어야 해요. 이 유형의 계정만 스토리지 큐에 이벤트 메시지를 지원하기 때문이에요.

참고 — 이미 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

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

여기서:

*storageid*와 *queueid*는 참조용 스토리지 계정 및 큐 ID 내보내기에서 설정한 스토리지 계정 및 큐 ID 환경 변수.
*subscription_name*은 새 Event Grid 구독의 이름.

2단계: 알림 통합 만들기

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

참고 — 단일 알림 통합은 단일 Azure Storage 큐를 지원해요. 여러 알림 통합에서 같은 스토리지 큐를 참조하면 이벤트 알림이 알림 통합들 사이에 분할되므로 대상 테이블에서 데이터가 누락될 수 있어요. 따라서 파이프가 기존 파이프와 같은 스토리지 큐를 참조하면 파이프 생성이 차단돼요.

스토리지 큐 URL과 테넌트 ID 검색

Microsoft Azure 포털에 로그인해요.
Storage account » Queue service » Queues로 이동해요. 스토리지 큐 만들기에서 만든 큐의 URL을 기록해요. URL 형식은 다음과 같아요.
```
https://<storage_account_name>.queue.core.windows.net/<storage_queue_name>
```
Azure Active Directory » Properties로 이동해요. Tenant ID 값을 기록해요. 디렉터리 ID(또는 테넌트 ID)는 Snowflake에 Event Grid 구독에 대한 액세스를 부여하는 동의 URL을 생성하는 데 필요해요.

알림 통합 만들기

CREATE NOTIFICATION INTEGRATION 명령을 사용해 알림 통합을 만들어요.

참고

계정 관리자(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의 로컬 설치가 필요하다는 점에 주의해요.

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

DESC NOTIFICATION INTEGRATION <integration_name>;

여기서:

*integration_name*은 알림 통합 만들기에서 만든 통합의 이름.

다음 열의 값을 기록해요.

AZURE_CONSENT_URL: Microsoft 권한 요청 페이지의 URL.
AZURE_MULTI_TENANT_APP_NAME: 계정을 위해 만들어진 Snowflake 클라이언트 애플리케이션의 이름. 이 섹션의 이후 단계에서 이 애플리케이션에 허용된 토픽에서 액세스 토큰을 얻는 데 필요한 권한을 부여해야 해요.

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

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

Queues » *storage_queue_name*으로 이동해요. 여기서 *storage_queue_name*은 스토리지 큐 만들기에서 만든 스토리지 큐의 이름이에요.
Access Control (IAM) » Add role assignment을 클릭해요.
Snowflake 서비스 주체를 검색해요. 이것은 (1단계의) DESC NOTIFICATION INTEGRATION 출력의 AZURE_MULTI_TENANT_APP_NAME 속성에 있는 ID예요. AZURE_MULTI_TENANT_APP_NAME 속성에서 밑줄 앞의 문자열을 검색해요.

중요

Azure가 이 섹션의 Microsoft 요청 페이지를 통해 요청된 Snowflake 서비스 주체를 만드는 데 1시간 이상 걸릴 수 있어요. 서비스 주체가 즉시 사용할 수 없으면 한두 시간 기다린 다음 다시 검색할 것을 권장해요.

서비스 주체를 삭제하면 알림 통합이 작동을 멈춰요.

Snowflake 앱에 다음 권한을 부여해요.
- 역할: Storage Queue Data Contributor
- 액세스 할당 대상: Azure AD 사용자, 그룹 또는 서비스 주체
- 선택: appDisplayName 값

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

3단계: (필요하면) 스테이지 만들기

CREATE STAGE 명령을 사용해 Azure 컨테이너를 참조하는 외부 스테이지를 만들어요. Snowpipe는 스테이지에서 데이터 파일을 가져와 대상 테이블에 로드하기 전에 임시로 큐에 넣어요.

또는 기존 외부 스테이지를 사용할 수 있어요.

참고

클라우드 스토리지 위치에 대한 보안 액세스를 구성하려면 (이 주제의) 클라우드 스토리지에 대한 보안 액세스 구성을 참고해요.

CREATE STAGE 문에서 스토리지 통합을 참조하려면 역할이 스토리지 통합 객체에 USAGE 권한이 있어야 해요.

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

USE SCHEMA snowpipe_db.public;

CREATE STAGE mystage
  URL = 'azure://myaccount.blob.core.windows.net/mycontainer/load/files/'
  STORAGE_INTEGRATION = my_storage_int;

참고 — Data Lake Storage Gen2를 포함한 모든 지원되는 유형의 Azure blob 스토리지 계정에 blob.core.windows.net 엔드포인트를 사용해요.

4단계: 자동 수집이 활성화된 파이프 만들기

CREATE PIPE 명령을 사용해 파이프를 만들어요. 파이프는 Snowpipe가 수집 큐에서 대상 테이블로 데이터를 로드하는 데 사용하는 COPY INTO <table> 문을 정의해요.

예를 들어 snowpipe_db.public 스키마에 mystage 스테이지에 스테이징된 파일의 데이터를 mytable 테이블에 로드하는 파이프를 만들어요.

CREATE PIPE snowpipe_db.public.mypipe
  AUTO_INGEST = true
  INTEGRATION = 'MY_NOTIFICATION_INT'
  AS
    COPY INTO snowpipe_db.public.mytable
      FROM @snowpipe_db.public.mystage
      FILE_FORMAT = (type = 'JSON');

여기서:

MY_NOTIFICATION_INT는 2단계: 알림 통합 만들기에서 만든 알림 통합의 이름.

중요

통합 이름은 모두 대문자로 입력해야 해요.

COPY INTO <table> 문의 스토리지 위치 참조가 계정의 기존 파이프의 참조와 겹치지 않는지 확인해요. 그렇지 않으면 여러 파이프가 같은 데이터 파일 집합을 대상 테이블에 로드할 수 있어요. 예를 들어 여러 파이프 정의가 <storage_location>/path1/과 <storage_location>/path1/path2/ 같은 서로 다른 세분화 수준으로 같은 스토리지 위치를 참조하면 이 상황이 발생할 수 있어요. 이 예제에서 파일이 <storage_location>/path1/path2/에 스테이징되면 두 파이프 모두 파일 복사본을 로드하게 돼요.

SHOW PIPES를 실행하거나 Account Usage의 PIPES 뷰 또는 정보 스키마의 PIPES 뷰를 조회해 계정의 모든 파이프 정의에서 COPY INTO <table> 문을 확인할 수 있어요.

자동 수집 Snowpipe가 이제 구성됐어요!

새 데이터 파일이 Azure 컨테이너에 추가될 때 이벤트 메시지가 Snowpipe에 파이프에 정의된 대상 테이블로 로드하라고 알려줘요.

5단계: 이력 파일 로드

Event Grid 메시지가 구성되기 전에 외부 스테이지에 존재했던 데이터 파일의 백로그를 로드하려면 ALTER PIPE … REFRESH 문을 실행해요.

6단계: 스테이징된 파일 삭제

데이터를 성공적으로 로드하고 더 이상 파일이 필요하지 않으면 스테이징된 파일을 삭제해요. 지침은 Snowpipe가 데이터를 로드한 후 스테이징된 파일 삭제를 참고해요.

SYSTEM$PIPE_STATUS 출력

SYSTEM$PIPE_STATUS 함수는 파이프의 현재 상태에 대한 JSON 표현을 검색해요.

AUTO_INGEST가 TRUE로 설정된 파이프의 경우 이 함수는 (현재 파이프 상태에 해당된다면) 다음 이름/값 쌍을 포함하는 JSON 객체를 반환해요.

{"executionState":"<value>","oldestFileTimestamp":<value>,"pendingFileCount":<value>,"notificationChannelName":"<value>","numOutstandingMessagesOnChannel":<value>,"lastReceivedMessageTimestamp":"<value>","lastForwardedMessageTimestamp":"<value>","error":<value>,"fault":<value>}

출력 값에 대한 설명은 SQL 함수의 참조 주제를 참고해요.

Microsoft Azure Blob Storage용 Snowpipe 자동화