Named Channels와 exactly-once 전달

Named Channels는 Snowflake 커밋을 소스 오프셋과 조정하는 애플리케이션에 순서 있는 exactly-once 수집을 제공해요. Kafka나 CDC(변경 데이터 캡처)처럼 각 소스 파티션이 채널에 매핑되는 파티션 기반 소스에 사용하세요.

출처: Snowflake 문서

본문

Named Channels 동작 방식

Named Channel은 테이블에 데이터를 로드하기 위한 Snowflake로의 논리적 스트리밍 연결이에요. Named Channels는 두 가지 보장을 제공합니다:

순서 있는 수집: 행과 해당 offset token의 순서가 채널 내에서 보존됩니다.
Exactly-once 전달: offset token 덕분에 클라이언트가 커밋된 진행 상황을 추적하고, 복구 시 마지막 커밋 위치부터 재생할 수 있습니다.

순서는 Named Channel 내부에서 보존되지만, 같은 테이블을 가리키는 Named Channel들 사이에서는 보존되지 않아요. Named Channels는 pipe에 대해 열립니다. 클라이언트 SDK는 여러 pipe에 여러 채널을 열 수 있지만, 계정에 걸쳐 채널을 열 수는 없어요. Named Channels는 클라이언트가 활발히 데이터를 삽입할 때 오래 살아 있는 것을 의도하며, offset token 정보가 보존되므로 클라이언트 프로세스 재시작 간에 재사용되어야 합니다.

채널과 관련 offset 메타데이터가 더 이상 필요 없으면 DropChannelRequest API로 채널을 영구히 삭제할 수 있어요. 채널은 두 가지 방법으로 삭제할 수 있습니다:

닫을 때 채널 삭제: 채널이 삭제되기 전에 채널 안의 데이터가 자동으로 플러시됩니다.
채널을 맹목적으로 삭제: 보류 중인 데이터를 버리므로 권장하지 않아요.

SHOW CHANNELS 명령을 실행해 액세스 권한이 있는 채널 목록을 볼 수 있어요. 자세한 내용은 SHOW CHANNELS를 참고하세요.

참고 비활성 채널은 offset token과 함께 30일간 활동이 없으면 자동으로 삭제됩니다.

Offset token과 exactly-once 전달

팁 Snowpipe Streaming에서 exactly-once가 동작하는 방식: 애플리케이션이 offset token(예: Kafka 파티션 오프셋)과 함께 행을 제출합니다. Snowflake는 데이터가 커밋될 때 token을 영속화합니다. 복구 시 재오픈된 채널의 마지막 커밋된 offset을 검색하고 그 오프셋 이후의 보존된 레코드를 재생합니다. 레코드는 소스 또는 내구성 있는 애플리케이션 관리 스토리지에 보관할 수 있어요. 원래 오프셋과 순서를 보존하고 그 오프셋이 커밋될 때까지 보관하세요. offset token은 프로듀서의 메모리를 영속화시키지 않아요.

Offset token은 클라이언트가 행 제출 요청에 포함시켜 채널별 수집 진행 상황을 추적하는 문자열이에요. 사용되는 구체적인 메서드는 SDK의 appendRow 또는 appendRows, REST API의 Append Rows 엔드포인트입니다.

token은 채널 생성 시 NULL로 초기화되고, 제공된 offset token이 있는 행이 Snowflake에 커밋될 때 업데이트됩니다. 클라이언트는 주기적으로 getLatestCommittedOffsetToken을 호출해 채널의 최신 커밋된 offset token을 얻고, 이것으로 수집 진행 상황을 판단할 수 있어요.

클라이언트가 채널을 다시 열면 최신 영속화된 offset token이 반환됩니다. 클라이언트는 그 token으로 데이터 소스에서 자신의 위치를 리셋해 같은 데이터를 두 번 보내지 않을 수 있어요. 채널 재오픈 이벤트가 발생하면 Snowflake에 버퍼링된 미커밋 데이터를 버려 커밋되지 않게 합니다.

최신 커밋된 offset token으로 다음을 수행할 수 있어요:

수집 진행 상황 추적
최신 커밋된 offset token과 비교해 특정 offset이 커밋됐는지 확인
소스 offset을 전진시키고 이미 커밋된 데이터 정리
중복 제거 활성화 및 exactly-once 데이터 전달 보장

예: Kafka 커넥터 크래시 복구

Kafka 커넥터는 Kafka 파티션 offset을 offset token(예: 20)으로 저장합니다. 커넥터가 재시작하면 재오픈된 채널에서 getLatestCommittedOffsetToken을 호출하고 마지막 커밋된 offset을 검색한 뒤 Kafka 읽기 커서를 다음 레코드(21)로 리셋합니다. 중복 데이터가 수집되지 않아요.

예: 크래시 복구가 있는 로그 파일 수집

애플리케이션이 로그 파일 이름과 줄 번호를 offset token(예: messages_1.log:20)으로 저장합니다. 재시작 시 getLatestCommittedOffsetToken을 호출해 그 token을 검색하고 messages_1.log의 21번 줄부터 읽기를 재개해 커밋된 데이터를 재수집하지 않습니다.

참고 offset token 정보는 유실될 수 있어요. offset token은 채널 객체에 연결되어 있고, 30일 동안 해당 채널로 새 수집이 수행되지 않으면 채널이 자동으로 정리됩니다. offset token 유실을 막으려면 별도의 offset을 유지하고 필요시 채널의 offset token을 리셋하는 것을 고려하세요.

`offsetToken`과 `continuationToken`의 역할

offsetToken과 continuationToken 모두 exactly-once 데이터 전달을 보장하는 데 쓰이지만, 용도가 다르고 다른 하위 시스템에서 관리됩니다. 주된 차이는 token 값의 제어 주체와 사용 범위예요.

continuationToken (직접 REST API 사용자만 사용): Snowflake는 Named Channel을 열거나 REST로 행을 append할 때 next_continuation_token을 반환합니다. 그 값을 다음 append 요청의 continuationToken으로 전달하세요. 이렇게 하면 Snowflake가 채널 내 요청 순서를 검증할 수 있어요. SDK 사용자는 continuation token을 직접 관리하지 않습니다.
offsetToken: 이 token은 외부 소스에서 exactly-once 전달을 가능하게 하는 사용자 정의 식별자예요. Snowflake는 이 값을 저장하지만 자체 내부 작업이나 재수입 방지에 사용하지는 않습니다. 외부 시스템(예: Kafka 커넥터)이 Snowflake에서 offsetToken을 읽어 자신의 수집 진행 상황을 추적하고, 외부 스트림을 재생해야 할 때 중복 데이터를 보내지 않는 책임을 져요.

Named Channels와 exactly-once 전달