Snowpipe Streaming 모범 사례

비용 최적화

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

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

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

성능 권장 사항

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

  • 여러 행을 로드하는 경우 insertRows 를 사용하면 insertRow 를 여러 번 호출하는 것보다 잠금에 소요되는 시간이 단축되므로 효율과 비용 효율성이 더 뛰어납니다.

    • 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 에서 설정한 시간에 따라 채널 내부의 데이터가 자동으로 플러시되므로 데이터를 삽입한 후에는 채널을 닫지 마십시오.

대기 시간 권장 사항

Snowflake 수집 SDK 버전 2.0.4 이상에서는 MAX_CLIENT_LAG 를 사용하여 데이터 플러시 대기 시간을 구성할 수 있습니다. 기본적으로, Snowpipe Streaming은 1초마다 데이터를 플러시합니다. MAX_CLIENT_LAG 구성을 사용하면 이를 재정의하고 1초에서 10분까지 원하는 플러시 대기 시간으로 설정할 수 있습니다.

데이터가 많이 생성되지 않는 저처리량 시나리오의 경우, 초당 1개 행 또는 1 KB의 데이터만 전송할 수 있습니다. 이로 인해 쿼리 결과를 반환하기 위해 많은 작은 파티션을 확인해야 하므로 쿼리 컴파일 시간이 길어질 수 있습니다. 특히, 마이그레이션 프로세스가 파티션을 압축하기 전에 쿼리가 트리거되는 경우 더욱 그렇습니다. MAX_CLIENT_LAG 를 더 높게 설정하면 설정된 시간 동안 Snowpipe Streaming이 삽입된 행을 버퍼링하고 더 나은 크기의 파티션을 생성할 수 있습니다. 이는 쿼리 성능과 마이그레이션에 상당한 도움이 됩니다.

따라서 목표 대기 시간이 허용하는 만큼 MAX_CLIENT_LAG 를 높게 설정합니다. 예를 들어, 스트리밍 데이터를 병합하거나 변환하기 위해 1분마다 실행되는 작업이 있는 경우 MAX_CLIENT_LAG 를 50초 또는 55초로 설정하는 것이 가장 좋습니다.

언어: 한국어