Snowpipe 관리

Snowpipe 관리

이 주제는 Snowpipe 관리와 관련된 관리 작업을 설명해요.

출처: Documentation

본문

Snowpipe가 데이터를 로드한 후 스테이징된 파일 삭제

파이프 객체는 PURGE 복사 옵션을 지원하지 않아요. Snowpipe는 데이터가 테이블에 성공적으로 로드될 때 스테이징된 파일을 자동으로 삭제할 수 없어요.

더 이상 필요하지 않은 스테이징된 파일을 제거하려면 주기적으로 REMOVE 명령을 실행해 파일을 삭제하는 것을 권장해요.

또는 클라우드 스토리지 서비스 제공업체가 제공하는 수명 주기 관리 기능을 구성해요.

이력 데이터 로드

참고 — 이 섹션의 내용은 이벤트 알림을 사용한 자동 데이터 로드에 관한 것이에요. Snowpipe REST API 호출은 추가 단계 없이 이력 데이터를 로드할 수 있어요.

ALTER PIPE … REFRESH 문은 이전 7일 내에 스테이징된 데이터 파일 집합을 대상 테이블에 로드하기 위해 Snowpipe 수집 큐로 복사해요. 더 일찍 스테이징된 파일의 데이터를 로드하려면 다음 단계를 권장해요.

  1. COPY INTO <table> 문을 실행해 이력 데이터를 대상 테이블에 로드해요.
  2. 이벤트 알림과 함께 Snowpipe를 사용해 자동 데이터 로드를 구성해요. 새로 스테이징되는 파일은 대상 테이블 수집을 위한 이벤트 알림을 트리거해요. 이력 데이터 파일은 이벤트 알림을 트리거하지 않으므로 두 번 로드되지 않아요.

지침은 다음을 참고해요.

  1. ALTER PIPE … REFRESH 문을 실행해 1단계와 2단계 사이에 스테이징된 파일을 큐에 넣어요. 이 문은 대상 테이블과 파이프 모두의 로드 기록을 확인해 같은 파일이 두 번 로드되지 않도록 해요.

파이프 다시 만들기

대부분의 파이프 속성을 수정하려면 (CREATE OR REPLACE PIPE 문을 사용해) 파이프를 다시 만들어야 해요.

이 섹션은 파이프를 다시 만들 때 따라야 할 고려 사항과 모범 사례를 설명해요.

자동 데이터 로드를 위한 파이프 다시 만들기

이벤트 알림을 사용해 데이터 로드를 자동화하는 파이프를 다시 만들 때는 다음 단계를 완료할 것을 권장해요.

  1. (ALTER PIPE … SET PIPE_EXECUTION_PAUSED = true를 사용해) 파이프를 일시 중지해요.
  2. SYSTEM$PIPE_STATUS 함수를 조회해 파이프 실행 상태가 PAUSED인지 확인해요.
  3. (CREATE OR REPLACE PIPE를 사용해) 파이프를 다시 만들어요.
  4. 파이프를 다시 일시 중지해요.
  5. 설정이 여전히 정확한지 클라우드 메시징 서비스의 구성 단계를 검토해요.
  6. (ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false를 사용해) 파이프를 재개해요.
  7. SYSTEM$PIPE_STATUS 함수를 다시 조회해 파이프 실행 상태가 RUNNING인지 확인해요.

로드 기록

Snowpipe 작업의 로드 기록은 파이프 객체의 메타데이터에 저장돼요. 파이프가 다시 만들어지면 로드 기록은 삭제돼요. 일반적으로 이 상태는 사용자가 이후에 파이프에 대해 ALTER PIPE … REFRESH 문을 실행할 때만 영향을 줘요. 데이터가 이미 성공적으로 로드되었고 파일이 이후에 삭제되지 않았다면, 이렇게 하면 파이프의 스토리지 위치에 있는 스테이징된 파일에서 중복 데이터가 로드될 수 있어요.

참조된 스테이지의 클라우드 매개 변수 변경

외부 스테이지의 클라우드 매개 변수에는 다음이 포함돼요.

  • URL
  • STORAGE_INTEGRATION
  • ENCRYPTION

Snowpipe가 성공적으로 구성된 후 참조된 스테이지의 클라우드 매개 변수를 수정해야 한다면 파이프를 다시 만들어야 해요.

경고 — 스테이지의 URL 매개 변수를 수정하면 클라우드 메시징을 사용해 데이터 로드를 트리거하는 의존 파이프(즉, AUTO_INGEST = TRUE인 파이프)가 작동을 멈출 수 있어요.

파이프 소유권 이전

다음 단계를 완료해 파이프의 소유권을 이전해요.

  1. PIPE_EXECUTION_PAUSED 매개 변수를 TRUE로 설정해요. 이 매개 변수는 파이프를 일시 중지하거나 재개할 수 있게 해줘요. 이 매개 변수는 다음 수준에서 지원돼요.

    • 계정
    • 스키마
    • 파이프

    파이프 수준에서 객체 소유자(또는 역할 계층의 상위 역할)는 개별 파이프를 일시 중지하거나 재개하도록 매개 변수를 설정할 수 있어요.

    계정 관리자(ACCOUNTADMIN 역할을 가진 사용자)는 계정 수준에서 이 매개 변수를 설정해 계정의 모든 파이프를 일시 중지하거나 재개할 수 있어요. 마찬가지로 스키마에 MODIFY 권한이 있는 사용자는 스키마 수준에서 파이프를 일시 중지하거나 재개할 수 있어요. 이 더 큰 도메인 제어는 매개 변수가 더 낮은 수준(예: 객체 수준에서 소유자가)에서 아직 설정되지 않은 파이프에만 영향을 준다는 점에 주의해요.

  2. GRANT OWNERSHIP을 사용해 파이프의 소유권을 이전해요.

  3. (SYSTEM$PIPE_FORCE_RESUME를 사용해) 파이프가 재개되도록 강제해요. 이 단계를 통해 새 소유자가 SYSTEM$PIPE_STATUS를 사용해 파이프 상태를 평가하고 로드 대기 중인 데이터 파일이 몇 개인지 확인할 수 있어요. 대상 테이블에 로드하도록 승인된 파일만 큐에 있는지 확인하는 것을 권장해요.

파이프 정의의 COPY 문 수정

파이프 정의의 COPY 문을 수정하려면 다음 단계를 완료해요. 예를 들어 대상 테이블에 컬럼이 추가되는 경우가 있어요.

이 섹션의 명령을 실행하려면 사용자의 현재 역할이 파이프에 OWNERSHIP 권한이 있어야 해요.

  1. (ALTER PIPE … SET PIPE_EXECUTION_PAUSED=true를 사용해) 파이프를 일시 중지해요.
  2. SYSTEM$PIPE_STATUS 함수를 조회해 파이프 실행 상태가 PAUSED이고 대기 중인 파일 수가 0인지 확인해요.
  3. 정의의 COPY 문을 변경하려면 파이프를 다시 만들어요. 다음 옵션 중 하나를 선택해요.
    • (DROP PIPE로) 파이프를 삭제하고 (CREATE PIPE로) 다시 만들어요.
    • (CREATE OR REPLACE PIPE 문법을 사용해) 파이프를 다시 만들어요. 내부적으로 파이프가 삭제되고 다시 생성돼요.
  4. 파이프를 다시 일시 중지해요.
  5. 설정이 여전히 정확한지 클라우드 메시징 서비스의 구성 단계를 검토해요.
  6. (ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false를 사용해) 파이프를 재개해요.
  7. SYSTEM$PIPE_STATUS 함수를 다시 조회해 파이프 실행 상태가 RUNNING인지 확인해요.

참고 — 파일 로드 메타데이터는 테이블이 아니라 파이프 객체와 연결돼요. 파이프를 다시 만들면 로드된 파일의 기록이 제거돼요. Snowpipe가 이미 로드한 파일이 실수로 파이프에 다시 제출되어 대상 테이블에 다시 로드되지 않도록 해요. 테이블의 쿼리 기록을 보려면 COPY_HISTORY 함수를 조회해요.

스테일 파이프 재개

참고 — 이 섹션은 클라우드 메시징을 사용해 데이터 로드를 트리거하는 파이프 객체(즉, 파이프 정의에 AUTO_INGEST = TRUE인 파이프)에만 해당해요.

파이프가 일시 중지되면 파이프에 대해 수신된 이벤트 메시지는 제한된 보존 기간에 들어가요. 기간은 기본적으로 14일이에요. 파이프가 14일보다 길게 일시 중지되면 스테일(stale)로 간주돼요.

스테일 파이프를 재개하려면 자격 있는 역할이 SYSTEM$PIPE_FORCE_RESUME 함수를 호출하고 STALENESS_CHECK_OVERRIDE 인자를 입력해야 해요. 이 인자는 역할이 스테일 파이프를 재개한다는 것을 이해하고 있음을 나타내요.

예를 들어 mydb.myschema 데이터베이스와 스키마의 스테일 stalepipe1 파이프를 재개해요.

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1','staleness_check_override');

스테일 파이프가 일시 중지된 동안 파이프 소유권이 다른 역할로 이전되었다면, 파이프를 재개하려면 추가로 OWNERSHIP_TRANSFER_CHECK_OVERRIDE 인자가 필요해요. 예를 들어 mydb.myschema 데이터베이스와 스키마에서 새 역할로 이전된 스테일 stalepipe2 파이프를 재개해요.

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1','staleness_check_override, ownership_transfer_check_override');

파이프가 일시 중지된 동안 수신된 이벤트 알림이 제한된 보존 기간의 끝에 도달하면 Snowflake는 내부 메타데이터에서 삭제하도록 예약해요. 파이프가 나중에 재개되면 Snowpipe는 이렇게 오래된 알림을 최선의 노력(best effort)으로 처리해요. Snowflake는 그들이 처리된다고 보장할 수 없어요.

예를 들어 파이프가 일시 중지된 지 15일 후에 재개되면, Snowpipe는 일반적으로 파이프가 일시 중지된 첫 날(즉, 이제 14일보다 오래된)에 수신된 이벤트 알림을 건너뛰어요. 파이프가 일시 중지된 후 16일 후에 재개되면, Snowpipe는 일반적으로 파이프가 일시 중지된 후 첫째 날과 둘째 날에 수신된 이벤트 알림을 건너뛰어요. 이런 식으로 계속돼요.

더 알아보기