Snowpipe 문제 해결¶

오류 알림¶

Snowpipe에 대한 오류 알림을 구성합니다. Snowpipe에서 로딩 중에 오류가 발생하면 이 기능은 구성된 클라우드 메시징 서비스로 알림을 푸시하여 데이터 파일을 분석할 수 있게 해줍니다. 자세한 내용은 Snowpipe 오류 알림 섹션을 참조하십시오.

일반 문제 해결 단계¶

다음 단계를 완료하면 파일 자동 로드 실패를 유발하는 대부분의 문제를 확인할 수 있습니다.

Microsoft Azure Data Lake Storage Gen2 Storage에서 생성된 파일은 로드되지 않습니다.¶

현재, 일부 서드 파티 클라이언트는 ADLS Gen 2 REST API에서 FlushWithClose 를 호출하지 않습니다. 이 단계는 Snowpipe에 파일을 로드하도록 알리는 이벤트를 트리거하기 위해 필요합니다. REST API를 수동으로 호출하여 Snowpipe가 이러한 파일을 로드하도록 트리거합니다.

close 인자가 포함된 Flush 메서드에 대한 자세한 내용은 https://docs.microsoft.com/en-us/dotnet/api/azure.storage.files.datalake.datalakefileclient.flush를 참조하십시오. REST 매개 변수와 관련한 로드에 대한 자세한 API close 참조 정보는 https://docs.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/update를 참조하십시오.

Amazon SNS 항목에 대한 구독이 삭제된 이후에는 Snowpipe가 파일 로드를 중지합니다.¶

사용자가 처음으로 특정 Amazon Simple Notification Service(SNS) 항목을 참조하는 파이프 오브젝트를 생성할 때 Snowflake는 Snowflake 소유 Amazon Simple Queue Service(SQS) 큐가 해당 항목을 구독하도록 합니다. AWS 관리자가 SQS 항목에 대한 SNS 구독을 삭제하면 해당 항목을 참조하는 모든 파이프가 더 이상 Amazon S3에서 이벤트 메시지를 수신하지 않습니다.

이 문제를 해결하려면 다음을 수행합니다.

1. SNS 항목 구독이 삭제된 시점부터 72시간을 기다립니다.

   72시간 후, Amazon SNS는 삭제된 구독을 지웁니다. 자세한 내용은 Amazon SNS 설명서 를 참조하십시오.

2. (CREATE OR REPLACE PIPE를 사용하여) 항목을 참조하는 모든 파이프를 다시 만듭니다. 파이프 정의에서 동일한 SNS 항목을 참조하십시오. 자세한 지침은 3단계: 자동 수집이 활성화된 파이프 만들기 섹션을 참조하십시오.

SNS 항목에 대한 구독을 삭제하기 전에 작동했던 모든 파이프는 이제 S3에서 다시 이벤트 메시지를 수신하기 시작해야 합니다.

SNS 항목을 다른 이름으로 만들면 72시간의 지연을 피할 수 있습니다. CREATE OR REPLACE PIPE 명령을 사용하여 이 항목을 참조하는 파이프를 모두 다시 만들고 새 항목 이름을 지정합니다.

지연된 Google Cloud Storage 또는 누락된 파일에서 로드¶

Pub/Sub 메시지를 사용하여 Google Cloud Storage(GCS)에서 자동 데이터 로딩이 구성되어 있는 경우 1개의 스테이징된 파일에 대한 이벤트 메시지만 읽을 수 있습니다. 또는, GCS로부터의 데이터 로드가 몇 분에서 하루 이상 지연될 수 있습니다. 일반적으로 이러한 두 가지 문제는 GCS 관리자가 Snowflake 서비스 계정에 Monitoring Viewer 역할을 부여하지 않은 경우에 발생합니다.

자세한 지침은 클라우드 저장소에 대한 보안 액세스 구성하기 의 “2단계: Pub/Sub 구독에 Snowflake 액세스 권한 부여”를 참조하십시오.

오류 알림¶

AWS(Amazon Web Services)에 호스팅된 Snowflake 계정에 Snowpipe 오류 알림에 대한 지원이 제공됩니다. 데이터 로딩 중에 오류가 발생하면 알림이 트리거되며, 이를 통해 데이터 파일을 분석할 수 있습니다. 자세한 내용은 Snowpipe 오류 알림 섹션을 참조하십시오.

일반 문제 해결 단계¶

다음 단계를 완료하면 파일 로딩 실패를 유발하는 대부분의 문제를 확인할 수 있습니다.

snowflake.ingest.error.IngestResponseError: Http Error: 401, Vender Code: 390144, Message: JWT token is invalid.

로드되지 않은 파일 세트¶

대상 테이블의 중복 데이터¶

SHOW PIPES 를 실행하거나 Account Usage에서 PIPES 뷰 또는 Information Schema에서 PIPES 뷰를 쿼리하여 계정의 모든 파이프 정의에 있는 COPY INTO <테이블> 문을 비교합니다. 여러 파이프가 COPY INTO <테이블> 문에서 동일한 클라우드 저장소 위치를 참조하는 경우 디렉터리 경로가 중첩되지 않는지 확인합니다. 그렇지 않으면 여러 파이프가 동일한 데이터 파일 세트를 대상 테이블로 로드할 수 있습니다. 예를 들어, 여러 파이프 정의가 <저장소_위치>/path1/ 및 <저장소_위치>/path1/path2/ 과 같이 세분화 수준이 다른 동일한 저장소 위치를 참조할 때 이러한 상황이 발생할 수 있습니다. 이 예에서, 파일이 <저장소_위치>/path1/path2/ 에서 스테이징된 경우 두 파이프 모두 파일의 복사본을 로드합니다.

수정된 데이터를 다시 로드할 수 없음, 의도하지 않게 로드된 수정된 데이터¶

Snowflake는 파일 로드 메타데이터를 사용하여 테이블에서 동일한 파일(및 데이터 복제)이 다시 로드되는 것을 방지합니다. Snowpipe는 나중에 수정된 경우에도(즉, eTag가 다른) 이름이 동일한 파일이 로드되는 것을 방지합니다.

파일 로드 메타데이터는 테이블이 아닌 파이프 오브젝트 와 연결됩니다. 그 결과,

• 이미 로드된 파일과 이름이 동일한 스테이징된 파일은 수정된 경우에도 무시되며, 그러한 예는 새 행이 추가되거나 파일의 오류가 수정된 경우입니다.

• TRUNCATE TABLE 명령을 사용하여 테이블을 자르면 메타데이터를 로드하는 Snowpipe 파일이 삭제되지 않습니다.

그러나 파이프는 14일 동안만 로드 내역 메타데이터를 유지합니다. 그러므로,

파일은 14일 이내에 다시 수정 및 스테이징됩니다.:

Snowpipe는 다시 스테이징된 수정된 파일을 무시합니다. 수정된 데이터 파일을 다시 로드하려면 현재 CREATE OR REPLACE PIPE 구문을 사용하여 파이프 오브젝트를 다시 생성해야 합니다.

다음 예에서는 Snowpipe REST API를 사용하여 데이터 로드 준비하기 의 1단계 예시에 따라 mypipe 파이프를 다시 생성합니다.

create or replace pipe mypipe as copy into mytable from @mystage;

Copy

14일 후에 다시 수정 및 스테이징된 파일:

Snowpipe가 데이터를 다시 로드하여 대상 테이블에 중복 레코드가 생성될 가능성이 있습니다.

또한, 활성 Snowpipe 로드에서와 동일한 버킷/컨테이너, 경로 및 대상 테이블을 참조하는 COPY INTO <테이블> 문이 실행되는 경우 중복 레코드가 대상 테이블에 로드될 수 있습니다. COPY 명령과 Snowpipe에 대한 로드 내역은 Snowflake에 별도로 저장됩니다. 내역 스테이징된 데이터를 로드한 후 파이프 구성을 사용하여 수동으로 데이터를 로드해야 하는 경우에는 ALTER PIPE … REFRESH 문을 실행합니다. 자세한 내용은 이 항목의 로드되지 않은 파일 세트 섹션을 참조하십시오.

COPY_HISTORY 뷰에서 LOAD_TIME 값 이전에 CURRENT_TIMESTAMP를 사용하여 삽입된 로드 시간¶

테이블 디자이너는 레코드가 테이블에 로드될 때 현재 타임스탬프를 기본값으로 삽입하는 타임스탬프 열을 추가할 수 있습니다. 목적은 테이블에 각 레코드가 로드되는 시간을 캡처하는 것이지만, 타임스탬프가 COPY_HISTORY 함수 (Information Schema) 또는 COPY_HISTORY 뷰 (Account Usage)에서 반환된 LOAD_TIME 열의 값보다 이전입니다. 그 이유는 레코드가 테이블에 삽입될 때(즉, 로드 작업에 대한 트랜잭션이 커밋될 때)가 아닌 클라우드 서비스에서 로드 작업이 컴파일될 때 CURRENT_TIMESTAMP 가 평가되기 때문입니다.

오류: {1} 스테이지와 연결된 {0} 통합을 찾을 수 없습니다.¶

003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.

이 오류는 외부 스테이지와 스테이지에 연결된 저장소 통합 간의 연결이 끊어진 경우 발생할 수 있습니다. 이 오류는 저장소 통합 오브젝트가 다시 생성(CREATE OR REPLACE STORAGE INTEGRATION 사용)되었을 때 발생합니다. 스테이지는 저장소 통합 이름 대신 숨겨진 ID를 사용하여 저장소 통합에 연결됩니다. CREATE OR REPLACE 구문이 오브젝트를 삭제하고 다른 숨겨진 ID로 저장소 통합을 다시 만드는 작업이 백그라운드로 수행됩니다.

저장소 통합을 하나 이상의 스테이지에 연결한 후에 다시 만들어야 하는 경우 ALTER STAGE stage_name SET STORAGE_INTEGRATION = storage_integration_name 을 실행하여 각 스테이지와 저장소 통합 사이의 연결을 다시 설정해야 합니다.

• 여기서 stage_name 은 스테이지의 이름입니다.

• storage_integration_name 은 저장소 통합의 이름입니다.

정부 리전을 참조하는 Snowpipe의 오류¶

계정이 상업 리전에 있는 동안 Snowpipe가 정부 리전의 버킷을 참조하면 오류가 발생할 수 있습니다. 클라우드 공급자의 정부 리전에서는 이벤트 알림이 다른 상업 리전으로 전송되거나 다른 상업 리전에서 전송되는 것을 허용하지 않습니다. 자세한 내용은 AWS GovCloud(US) 및 Azure Government 섹션을 참조하십시오.