본문으로 건너뛰기
snowflake검색
수집과 연동

Snowpipe 와 Snowpipe Streaming (파일 자동 수집, 행 단위 스트리밍)

클라우드 이벤트로 파일을 자동 적재하는 Snowpipe 와, SDK 로 행을 바로 밀어 넣는 Snowpipe Streaming 고성능 아키텍처의 구조, 채널, GB 당 과금으로 바뀐 비용, 모니터링과 흔한 문제를 정리합니다.

SnowpipeSnowpipe Streaming자동 수집PIPE채널과금2026-10 기준, 약 9분상태 표시 설명

무엇을 고르나

방식단위지연과금 (Service Consumption Table 2026-10-15)맞는 경우
COPY INTO파일 묶음실행할 때웨어하우스 크레딧하루 몇 번의 배치, 대량 백필
Snowpipe파일 하나하나보통 1분 안팎적재 GB 당 0.0037 크레딧버킷에 수시로 떨어지는 파일
Snowpipe Streaming (고성능)행최소 5초 수준압축 전 GB 당 0.0037 크레딧앱, IoT, CDC, Kafka
Snowpipe Streaming Classic행초 단위컴퓨트 배수 1 + 클라이언트 인스턴스 시간당 0.01 크레딧기존 SDK 를 쓰는 시스템

Snowpipe (파일 자동 수집)

Snowpipe 는 PIPE 객체 안에 COPY 문을 넣어 두고, 새 파일이 생기면 Snowflake 가 관리하는 컴퓨트로 그 COPY 를 실행합니다. 웨어하우스가 필요 없습니다.

CREATE PIPE raw.orders_pipe
  AUTO_INGEST = TRUE
  AS
  COPY INTO raw.orders
  FROM @raw.s3_stage/orders/
  FILE_FORMAT = (FORMAT_NAME = 'raw.csv_fmt');

SHOW PIPES LIKE 'ORDERS_PIPE';   -- notification_channel (SQS ARN) 을 S3 이벤트 알림에 등록
클라우드알림 경로
AWSS3 이벤트 알림을 Snowflake 가 준 SQS 큐로 (또는 SNS 경유)
Google CloudGCS Pub/Sub 알림과 알림 통합(Notification Integration)
AzureEvent Grid 와 저장소 큐, 알림 통합

자동 수집 대신 앱이 insertFiles REST API 로 파일 목록을 알려 줄 수도 있습니다.

과금이 단순해졌습니다

2025년 12월 8일부터 Standard 와 Enterprise 에디션도 적재 데이터 GB 당 0.0037 크레딧 으로 과금됩니다 (Business Critical 과 VPS 는 2025년 8월 1일부터). 예전의 "초 단위 컴퓨트 + 1,000 파일당 요금" 구조가 사라져 작은 파일이 많을 때의 불이익이 줄었습니다.

  • CSV, JSON 같은 텍스트 파일은 압축 전 크기, Parquet, Avro 같은 바이너리 파일은 관찰된 크기로 잽니다.
  • 예: 하루 압축 전 200 GB 의 JSON 이면 하루 0.74 크레딧, 한 달 약 22 크레딧입니다.

로드 기록은 14일

Snowpipe 의 파일 적재 기록(중복 방지용)은 파이프마다 14일 동안 유지됩니다. COPY 의 64일보다 짧으므로, 오래된 파일을 같은 경로에 다시 올리면 중복으로 들어갈 수 있습니다.

SELECT SYSTEM$PIPE_STATUS('raw.orders_pipe');   -- executionState, pendingFileCount

-- 최근 실패 파일
SELECT file_name, status, first_error_message, last_load_time
FROM TABLE(INFORMATION_SCHEMA.COPY_HISTORY(
  TABLE_NAME => 'RAW.ORDERS', START_TIME => DATEADD(hour, -24, CURRENT_TIMESTAMP())))
WHERE status <> 'Loaded';

-- 놓친 파일 다시 넣기 (최근 7일 안의 파일)
ALTER PIPE raw.orders_pipe REFRESH PREFIX = '2026/10/20/';

주의 파이프 정의(COPY 문)를 바꾸려면 CREATE OR REPLACE PIPE 를 해야 하고, 이때 로드 기록이 초기화됩니다. 교체 전에 파이프를 PIPE_EXECUTION_PAUSED = TRUE 로 멈추고, 교체 후 REFRESH 범위를 좁게 잡아 중복을 막습니다.

Snowpipe Streaming (고성능 아키텍처)

Snowpipe Streaming 은 파일을 거치지 않고 SDK 나 REST 로 행을 바로 테이블에 씁니다. 2025년 9월 AWS 에서 고성능 아키텍처가 GA 가 되었고, 11월에 Azure 와 GCP 도 GA 가 되었습니다.

항목내용
처리량테이블당 최대 20 GB/s (행 크기, 테이블 폭, 변환에 따라 다름)
지연적재 후 조회까지 최소 5초 수준, 외부 엔진이 Iceberg 로 읽으면 30초 수준
SDKJava (11 이상), Python (3.9 이상), Node.js (20 이상), REST API. SDK 는 공통 Rust 코어
대상표준 테이블, Snowflake 관리 Iceberg v2, v3 테이블 (파티션된 Iceberg 테이블은 2026-09 GA)
변환PIPE 객체 안에서 COPY 문법으로 가벼운 변환과 사전 클러스터링

채널

채널은 클라이언트에서 PIPE 를 거쳐 테이블로 가는 논리 경로입니다.

채널순서와 중복맞는 경우
Elastic Channels (2026-09 GA, 새 앱 권장)최소 한 번, 순서 보장 없음생산자가 많은 이벤트, 로그
Named Channels채널 안에서 순서 보장, 오프셋 토큰으로 정확히 한 번Kafka 파티션, CDC
# 개념 예시: 이름 있는 채널을 열고, 오프셋 토큰과 함께 행을 보냄
client = StreamingIngestClient(account=..., user=..., private_key=..., db="RAW", schema="IOT", pipe="SENSOR_PIPE")
ch = client.open_channel("partition-0")
ch.append_rows(rows, end_offset_token="1048576")
print(ch.get_latest_committed_offset_token())   # 재시작할 때 여기서부터

SDK 클래스와 메서드 이름은 버전마다 다를 수 있으니 공식 SDK 문서의 예제를 기준으로 합니다. 키 페어 인증을 쓰며, 고성능 SDK 는 3DES 로 암호화한 개인 키를 받지 않습니다.

기본 파이프와 스키마 진화

2025년 12월부터 테이블마다 기본 파이프가 있어 PIPE 를 따로 만들지 않고도 바로 스트리밍할 수 있고, 고성능 아키텍처에서도 스키마 진화를 지원합니다. 2026년 4월에는 오류 기록(Error logging)이 GA 가 되어 잘못된 행을 오류 테이블로 따로 받을 수 있습니다.

Classic 에서 옮기기

Classic SDK 는 클라이언트가 켜져 있는 시간만큼 크레딧이 들기 때문에, 트래픽이 적은 시간에도 요금이 나옵니다. 고성능 아키텍처는 들어온 데이터 양에만 과금되므로 대부분 저렴해집니다. Kafka 를 쓴다면 Kafka 커넥터 v4 가 고성능 아키텍처 위에서 돌고 v3 에서 옮기는 방법을 제공합니다.

모니터링

-- 서비스 종류별 일별 크레딧 (Snowpipe, Snowpipe Streaming 확인)
SELECT usage_date, service_type, SUM(credits_used) AS credits
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(day, -30, CURRENT_DATE())
  AND service_type ILIKE '%PIPE%'
GROUP BY 1, 2 ORDER BY 1 DESC;

2026년 2월에는 행이 실제로 적재된 시각을 남기는 행 타임스탬프(row timestamps)가 GA 가 되어 파이프라인 지연을 행 단위로 잴 수 있고, 9월에는 Snowpipe Streaming 을 이벤트 테이블로 모니터링하는 기능이 추가되었습니다.

트러블슈팅

  • 증상: S3 에 파일이 생기는데 Snowpipe 가 아무것도 넣지 않습니다.

  • 원인: S3 이벤트 알림이 파이프의 SQS 로 연결되지 않았거나, 접두사(prefix)와 접미사 필터가 경로와 다릅니다. 스테이지 경로와 파이프 COPY 경로가 어긋난 경우도 많습니다.

  • 해결: SYSTEM$PIPE_STATUS 의 pendingFileCount 와 lastReceivedMessageTimestamp 를 봅니다. 메시지가 안 오면 버킷 알림 설정을, 오는데 적재가 안 되면 COPY_HISTORY 의 오류를 봅니다.

  • 증상: 스트리밍 클라이언트를 재시작했더니 데이터가 중복되었습니다.

  • 원인: 재시작 시 마지막 커밋 오프셋 토큰부터 다시 보내지 않았거나, 순서 보장이 없는 Elastic Channel 을 정확히 한 번이 필요한 곳에 썼습니다.

  • 해결: Named Channel 과 오프셋 토큰을 쓰고, 재시작할 때 get_latest_committed_offset_token 이후부터 보냅니다.

공식 문서

이 문서에서