Snowflake Snowpipe Streaming으로 Apache Iceberg 실시간 적재하는 법

AS-IS: 스트리밍 성능 검증이 오래 걸렸던 이유

원문에 따르면 대규모 스트리밍 워크로드를 검증하려면 보통 S3 버킷, EKS 클러스터, Kafka 토픽, IAM 정책을 구성하고 보안 리뷰까지 거쳐야 했습니다. 각자 백로그가 있는 세 개 플랫폼 팀의 승인을 받아야 테스트를 시작할 수 있는 구조였다고 해요. 그러다 보니 파이프라인이 실제 운영 규모의 트래픽을 감당하는지 증명하는 일 자체가 별도 프로젝트처럼 다뤄졌습니다.

이번 내용: SPCS 하나로 끝내는 전 과정

Snowflake는 데모 환경에서 이 평가 작업을 오후 한나절 만에 세팅, 테스트, 정리까지 마쳤다고 밝혔습니다. SPCS에서 실행되는 컨테이너가 부하를 생성하고 SDK로 스트리밍해 Snowflake 관리형 Iceberg 테이블에 데이터를 적재하는 방식인데요, 데이터가 도착하는 즉시 RBAC(역할 기반 접근 제어), 리니지, 마스킹이 함께 적용돼 바로 쿼리할 수 있는 상태가 됩니다. SPCS는 컨테이너에 단기 OAuth 토큰을 자동으로 주입하기 때문에 별도 비밀키 관리가 필요 없다는 점도 설명하고 있어요. Snowpipe Streaming SDK 자체는 SPCS 없이도 노트북이나 EC2, 쿠버네티스 파드 어디서든 돌아가지만, SPCS를 쓰면 이미 Snowflake가 관리하는 인프라 위에서 돌기 때문에 별도 프로비저닝이나 승인 절차 없이 테스트를 더 빨리 시작할 수 있다고 합니다. Python, Java, Node, REST SDK 옵션을 GitHub 저장소 코드와 함께 제공하고요.

실무 적용 포인트: 배치와 채널 관리 팁

원문이 소개하는 실무 팁을 정리하면 이렇습니다. Snowpipe Streaming은 한 행씩 파일을 쓰지 않고 서버 사이드 버퍼링 계층이 커밋 타이밍을 알아서 결정하며 배치 처리를 해요. 여기에 더해 Snowflake가 유일한 쓰기 주체인 관리형 Iceberg 테이블에서는 작은 Parquet 파일과 매니페스트를 자동으로 병합하는 압축 작업이 백그라운드에서 별도 스케줄 없이 상시 돌아갑니다. 그래도 클라이언트 쪽에서 할 수 있는 최적화가 있는데요, appendRows를 호출하기 전 행을 클라이언트 단에서 배치로 묶어 왕복 횟수를 줄이는 것, 채널을 소스 파티션당 한 번만 열어 작업이 끝날 때까지 유지하는 것(마이크로 배치마다 열고 닫지 않는 것), 테이블에 TARGET_FILE_SIZE를 설정해 신규 쓰기와 백그라운드 압축이 목표로 할 파일 크기를 지정하는 것입니다. 지속 TPS가 높을수록 서버 사이드 버퍼가 더 빨리 차고 플러시되기 때문에, 결국 특정 파일 크기 기준으로 처리량과 지연 시간 사이의 트레이드오프가 생긴다는 설명도 있어요. 실무에서 스트리밍 파이프라인을 설계할 때 이 세 가지 체크리스트(클라이언트 배치, 채널 유지, TARGET_FILE_SIZE)를 먼저 확인하면 됩니다.

앞으로: Iceberg v4의 메타데이터 개선

Snowpipe Streaming과 자동 압축이 작은 파일 문제는 해결하지만, 몇 초 단위로 자주 커밋하는 워크로드에서는 Iceberg의 메타데이터 트리 자체가 병목이 될 수 있다고 합니다. 커밋 한 번마다 파일이 하나만 있어도 새 메타데이터 JSON, 매니페스트 리스트, 매니페스트를 매번 새로 쓰기 때문이에요. Iceberg v4에서 제안된 Adaptive Metadata Tree 구조는 작은 커밋마다 새 매니페스트를 만드는 대신 루트 매니페스트가 해당 커밋들을 인라인으로 포함하도록 해서, 하나의 Parquet 쓰기와 원자적 포인터 스왑으로 대체합니다. 이렇게 되면 커밋당 메타데이터 I/O가 매니페스트 개수에 비례해 늘어나지 않고 일정하게 유지되는데요, 원문은 스트리밍이 v4의 대표 활용 시나리오 중 하나라고 설명하면서도 v4 스펙이 아직 확정되지 않았다고 밝히고 있습니다.

자주 묻는 질문

Snowpipe Streaming으로 Iceberg에 데이터를 스트리밍하려면 뭐가 필요한가요

기본적으로는 Snowflake 관리형 Iceberg 테이블과 스트리밍 파이프, 그리고 Python, Java, Node, REST 중 하나의 SDK만 있으면 됩니다. SPCS를 쓰면 컨테이너, 인증, 인프라를 Snowflake가 대신 관리해줘서 별도 프로비저닝 없이 더 빠르게 테스트할 수 있어요. 단 Streaming SDK는 별도 ingest 엔드포인트를 HTTPS로 쓰기 때문에 *.snowflakecomputing.com로 나가는 외부 접근 통합(external access integration)은 따로 허용해줘야 합니다.

Snowflake 관리형 Iceberg와 외부 볼륨 방식 중 뭘 골라야 하나요

원문은 세 가지 경로를 제시합니다. 외부 볼륨을 쓰는 Snowflake 관리형 Iceberg는 Parquet 파일이 자체 S3 버킷에 저장되고 외부 엔진이 Horizon REST Catalog로 메타데이터를 읽으며 직접 접근할 수 있습니다. Snowflake 스토리지 위의 관리형 Iceberg는 외부 볼륨과 클라우드 스토리지 설정을 건너뛸 수 있고 Iceberg 호환 기능은 그대로 활용합니다. 네이티브 Snowflake 테이블은 별도 관리 스토리지 인프라 자체가 필요 없습니다. 평가 단계에서는 관리형 Iceberg가 설정이 가장 적고, 운영 전환 시점에 필요에 따라 경로를 바꾸면 됩니다.

초당 100만 TPS 스트리밍 테스트는 왜 SPCS로 하는 게 유리한가요

Snowpipe Streaming SDK 자체는 SPCS가 없어도 노트북, EC2, 쿠버네티스 파드 어디서든 돌아갑니다. 다만 SPCS를 쓰면 Snowflake가 이미 관리하는 인프라 위에서 서비스가 돌기 때문에 테스트 자체를 위해 새로 프로비저닝하거나 추가 승인을 받을 필요가 없어져서 더 빨리 결과를 볼 수 있어요. 원문에서는 이 방식으로 데모 구축부터 종단 테스트, 처리량 측정, 정리까지 오후 한나절 만에 끝냈다고 설명합니다.

Iceberg v4는 지금 스트리밍 워크로드에 어떤 영향을 주나요

아직 v4 스펙은 확정되지 않았습니다. 다만 Adaptive Metadata Tree 구조가 도입되면 몇 초마다 커밋하는 스트리밍 워크로드에서 커밋당 메타데이터 쓰기 부담이 매니페스트 개수와 무관하게 일정해질 것으로 기대된다고 원문은 설명하고 있어요.