Snowpipe Streaming Classic 모범 사례

비용 최적화

모범 사례로, 초당 더 많은 데이터를 쓰는 소수의 Snowpipe Streaming 클라이언트로 API를 호출하는 것이 좋습니다. Java 또는 Scala 애플리케이션을 사용하여 IoT 디바이스 또는 센서와 같은 여러 소스에서 데이터를 집계한 다음, Snowflake Ingest SDK를 사용하여 더 빠르게 흐르는 속도에서 데이터를 로드하는 API를 호출합니다. API는 계정의 여러 대상 테이블에 걸쳐 데이터를 효율적으로 집계합니다.

단일 Snowpipe Streaming 클라이언트는 여러 채널을 열어 데이터를 보낼 수 있지만, 클라이언트 비용은 활성 클라이언트마다 청구될 뿐입니다. 채널 수는 클라이언트 비용에 영향을 미치지 않습니다. 따라서 성능 및 비용 최적화를 위해 클라이언트마다 여러 채널을 사용하는 것이 좋습니다.

배치 수집과 스트리밍 수집 모두에 대해 동일한 테이블을 사용하면 선점된 파일 마이그레이션 작업으로 인해 Snowpipe Streaming 컴퓨팅 비용이 절감될 수도 있습니다. 자동 클러스터링 이 Snowpipe Streaming이 삽입되는 동일한 테이블에서도 활성화되어 있으면 파일 마이그레이션을 위한 컴퓨팅 비용이 절감될 수 있습니다. 클러스터링 작업은 동일한 트랜잭션에서 데이터를 최적화하고 마이그레이션합니다.

성능 권장 사항

처리량이 많은 배포에서 최적의 성능을 얻으려면 다음 작업을 수행하는 것이 좋습니다.

  • 여러 행을 로딩하는 경우 insertRow 를 여러 번 호출하는 것보다 insertRows 를 사용하는 것이 잠금에 소요되는 시간이 적기 때문에 효율적이고 비용 효율적입니다.

    • insertRows 에 전달된 각 행 배치의 크기를 16MB 미만으로 압축하여 유지하십시오.

    • 최적의 행 배치 크기는 10~16MB입니다.

  • TIME, DATE 및 모든 TIMESTAMP 열의 값을 java.time 패키지에서 지원되는 유형 중 하나로 전달합니다.

  • OpenChannelRequest.builder 를 사용하여 채널을 생성할 때 OnErrorOption 을 OnErrorOption.CONTINUE 로 설정하고 insertRows 에서 반환 값을 수동으로 확인하여 수집 오류가 있는지 확인합니다. 이 접근 방식은 현재 OnErrorOption.ABORT 가 사용될 때 발생하는 예외에 의존하는 것보다 성능이 더 낫습니다.

  • 기본 로깅 수준을 DEBUG 로 설정하면 다음 로거가 INFO 에 계속 로깅하게 되는데, DEBUG 출력 내용이 매우 장황하여 성능이 크게 저하될 수 있습니다.

    • net.snowflake.ingest.internal.apache.parquet

    • org.apache.parquet

  • 채널은 클라이언트가 데이터를 능동적으로 삽입할 때 오랫동안 유지되어야 하며 오프셋 토큰 정보가 유지되므로 재사용되어야 합니다. MAX_CLIENT_LAG 에 구성된 시간에 따라 채널 내부의 데이터가 자동으로 플러시되므로 데이터를 삽입한 후 채널을 닫지 마십시오.

대기 시간 권장 사항

지연 시간은 Snowpipe Streaming을 사용할 때 채널에 기록된 데이터를 Snowflake에서 쿼리할 수 있게 되는 속도를 의미합니다. Snowpipe Streaming은 1초마다 채널 내의 데이터를 자동으로 플러시하므로 데이터를 플러시하기 위해 채널을 명시적으로 닫을 필요가 없습니다.

MAX_CLIENT_LAG 로 지연 시간 구성하기 Snowflake Ingest SDK 버전 2.0.4 이상에서는 MAX_CLIENT_LAG 옵션을 사용하여 데이터 플러시 지연 시간을 미세 조정할 수 있습니다.

  • 표준 Snowflake 테이블(비Iceberg): 기본 MAX_CLIENT_LAG 는 1초입니다. 이를 재정의하여 1초에서 최대 10분까지 원하는 플러시 대기 시간을 설정할 수 있습니다.

  • Snowflake 관리 Iceberg 테이블: Snowflake Ingest SDK 버전 3.0.0 이상에서 지원되며, 기본 MAX_CLIENT_LAG 는 30초입니다. 이 기본값은 쿼리 성능에 도움이 되는 최적화된 Parquet 파일을 생성하는 데 도움이 됩니다. 더 낮은 값을 설정할 수는 있지만, 처리량이 예외적으로 많은 경우가 아니라면 일반적으로 권장하지 않습니다.

성능 최적화를 위한 지연 시간 권장 사항 MAX_CLIENT_LAG 를 효과적으로 설정하면 쿼리 성능과 내부 마이그레이션 프로세스(Snowflake가 작은 파티션을 압축하는)에 큰 영향을 미칠 수 있습니다.

처리량이 적은 시나리오에서 소량의 데이터(예: 초당 1행 또는 1 KB)만 전송하는 경우 잦은 플러시는 수많은 작은 파티션을 생성할 수 있습니다. 특히 마이그레이션 프로세스가 파티션을 압축하기 전에 쿼리가 실행되는 경우, Snowflake가 많은 작은 파티션을 해결해야 하므로 쿼리 컴파일 시간이 늘어날 수 있습니다.

따라서 목표 지연 시간 요구 사항이 허용하는 한 MAX_CLIENT_LAG 를 높게 설정해야 합니다. 삽입된 행을 더 오래 버퍼링하면 Snowpipe Streaming이 더 큰 크기의 파티션을 생성하여 쿼리 성능을 개선하고 마이그레이션 오버헤드를 줄일 수 있습니다. 예를 들어, 스트림 데이터를 병합하거나 변환하기 위해 1분마다 실행되는 작업이 있는 경우, MAX_CLIENT_LAG 는 50초에서 55초 사이가 최적화될 수 있습니다. 이렇게 하면 다운스트림 프로세스가 실행되기 직전에 데이터를 더 큰 청크 단위로 플러시할 수 있습니다.

Snowpipe Streaming용 Kafka 커넥터 Snowpipe Streaming용 Kafka 커넥터에는 자체 내부 버퍼가 있다는 점에 유의하십시오. Kafka 버퍼 플러시 시간에 도달하면 표준 1초의 지연 시간으로 Snowpipe Streaming을 통해 데이터가 Snowflake로 전송됩니다. 자세한 내용은 buffer.flush.time 설정을 참조하십시오.

언어: 한국어