Snowpipe Streaming 모범 사례¶
비용 최적화¶
모범 사례로, 초당 더 많은 데이터를 쓰는 소수의 Snowpipe Streaming 클라이언트로 API를 호출하는 것이 좋습니다. Java 또는 Scala 애플리케이션을 사용하여 IoT 디바이스 또는 센서와 같은 여러 소스에서 데이터를 집계한 다음, Snowflake Ingest SDK를 사용하여 더 빠르게 흐르는 속도에서 데이터를 로드하는 API를 호출합니다. API는 계정의 여러 대상 테이블에 걸쳐 데이터를 효율적으로 집계합니다.
단일 Snowpipe Streaming 클라이언트는 여러 채널을 열어 데이터를 보낼 수 있지만, 클라이언트 비용은 활성 클라이언트마다 청구될 뿐입니다. 채널 수는 클라이언트 비용에 영향을 미치지 않습니다. 따라서 성능 및 비용 최적화를 위해 클라이언트마다 여러 채널을 사용하는 것이 좋습니다.
배치 수집과 스트리밍 수집 모두에 대해 동일한 테이블을 사용하면 선점된 파일 마이그레이션 작업으로 인해 Snowpipe Streaming 컴퓨팅 비용이 절감될 수도 있습니다. Snowpipe Streaming이 삽입되는 동일한 테이블에서 자동 클러스터링 도 활성화되면 파일 마이그레이션을 위한 컴퓨팅 비용이 절감될 수 있습니다. 클러스터링 작업은 동일한 트랜잭션에서 데이터를 최적화하고 마이그레이션합니다.
성능 권장 사항¶
처리량이 많은 배포에서 최적의 성능을 얻으려면 다음 작업을 수행하는 것이 좋습니다.
TIME, DATE 및 모든 TIMESTAMP 열의 값을
java.time패키지에서 지원되는 유형 중 하나로 전달합니다.OpenChannelRequest.builder를 사용하여 채널을 생성할 때OnErrorOption을OnErrorOption.CONTINUE로 설정하고insertRows의 반환 값에 잠재적 수집 오류가 있는지 수동으로 확인하십시오. 이 접근 방식은 현재OnErrorOption.ABORT가 사용될 때 발생하는 예외에 의존하는 것보다 성능이 더 낫습니다.insertRows에 전달된 각 행 배치의 크기를 16MB 미만으로 유지하십시오.여러 행을 로드하는 경우
insertRows를 사용하면insertRow를 여러 번 호출하는 것보다 잠금에 소요되는 시간이 단축되므로 성능과 비용 효율성이 더 뛰어납니다.기본 로그 수준을 DEBUG로 설정하는 경우 INFO에서 다음 로거가 계속 로깅하는지 확인하십시오. 로거의 DEBUG 출력이 매우 장황하여 상당한 성능 저하로 이어질 수 있습니다.
net.snowflake.ingest.internal.apache.parquetorg.apache.parquet