고성능 아키텍처를 갖춘 Snowpipe Streaming 모범 사례:

이 가이드에서는 고성능 아키텍처를 갖춘 Snowpipe Streaming을 사용하여 강력한 데이터 수집 파이프라인을 설계하고 구현하기 위한 주요 모범 사례를 간략하게 설명합니다. 이러한 모범 사례를 따르면 파이프라인의 내구성, 신뢰성, 오류 처리 효율성을 보장할 수 있습니다.

전략적으로 채널 관리

성능과 장기적인 안정성을 위해 다음 채널 관리 전략을 적용합니다.

  • 장기 채널 사용: 오버헤드를 최소화하려면 채널을 한 번 연 다음, 수집 작업 기간 동안 활성 상태로 유지합니다. 채널을 반복적으로 열고 닫지 마세요.

  • 결정적 채널 이름 사용: 문제 해결을 간소화하고 자동화된 복구 프로세스를 촉진하기 위해 일관되고 예측 가능한 명명 규칙을 적용합니다(예: source-env-region-client-id).

  • ** 여러 채널로 확장**: 처리량을 늘리려면 여러 채널을 엽니다. 이러한 채널은 서비스 제한과 처리량 요구 사항에 따라 단일 대상 파이프 또는 여러 파이프를 가리킬 수 있습니다.

  • 채널 상태 모니터링: 주기적으로 getChannelStatus 메서드를 사용하여 수집 채널의 상태를 모니터링합니다.

    • ``last_committed_offset_token``을 추적하여 데이터가 성공적으로 수집되고 파이프라인이 진행 중인지 확인합니다.

    • ``row_error_count``를 모니터링하여 불량 레코드 또는 기타 수집 문제를 조기에 감지합니다.

일관되게 스키마 유효성 검사

수집 실패를 방지하고 데이터 무결성을 유지하기 위해 수신 데이터가 예상되는 테이블 스키마를 준수하는지 확인합니다.

  • 클라이언트 측 유효성 검사: 클라이언트 측에서 스키마 유효성 검사를 구현하여 즉각적인 피드백을 제공하고 서버 측 오류를 줄입니다. 전체 행별 유효성 검사가 최대한의 안전성을 제공하지만, 더 나은 성능을 위해서는 배치 경계 또는 행 샘플링 등을 활용하여 선택적 유효성 검사를 수행하는 것이 좋습니다.

  • 서버 측 유효성 검사: 고성능 아키텍처는 스키마 유효성 검사를 서버로 오프로드할 수 있습니다. 대상 파이프와 테이블로 수집하는 동안 스키마 불일치가 발생하는 경우 오류 및 해당 개수는 ``getChannelStatus``를 통해 보고됩니다.

안정적인 복구를 위한 상태 유지

데이터 손실이나 중복을 방지하려면 애플리케이션이 다시 시작 및 실패를 정상적으로 처리할 수 있도록 상태를 유지해야 합니다.

  • 오프셋 토큰 유지: API 호출이 성공할 때마다 ``last_committed_offset_token``을 영구 저장소에 보관합니다.

  • 마지막 지점에서 재개: 애플리케이션이 다시 시작되면 Snowflake에서 마지막으로 커밋된 토큰을 가져오고 정확한 지점에서 수집을 재개합니다. 그러면 정확히 한 번 처리되고 연속성이 보장됩니다.

클라이언트 측 메타데이터 열 추가

강력한 오류 감지 및 복구를 활성화하려면 수집 메타데이터를 행 페이로드의 일부로 전달해야 합니다. 이를 위해서는 데이터 형태 및 PIPE 정의를 사전에 계획합니다.

수집하기 전에 행 페이로드에 다음 열을 추가합니다.

  • ``CHANNEL_ID``(예: 압축된 INTEGER.)

  • STREAM_OFFSET``(채널마다 단조적으로 증가하는 Kafka 파티션 오프셋과 같은 ``BIGINT)

이러한 열을 통해 채널당 레코드를 고유하게 식별하고 데이터의 원본을 추적할 수 있습니다.

선택 사항: 여러 파이프가 동일한 대상 테이블로 수집되는 경우 PIPE_ID 열을 추가합니다. 그러면 수집 파이프라인까지 행을 다시 쉽게 추적할 수 있습니다. 설명이 포함된 파이프 이름을 별도의 조회 테이블에 저장하고 컴팩트 정수로 매핑하여 저장소 비용을 줄일 수 있습니다.

메타데이터 오프셋을 사용하여 오류 감지 및 복구

채널 모니터링을 메타데이터 열과 결합하여 문제를 감지하고 복구합니다.

  • 모니터 상태: ``getChannelStatus``를 정기적으로 확인합니다. ``row_error_count``가 증가하면 잠재적인 문제가 있을 가능성이 높습니다.

  • 누락된 레코드 감지: 오류가 감지되면 SQL 쿼리를 통해 STREAM_OFFSET 시퀀스에서 공백을 확인하여 누락되거나 순서가 잘못된 레코드를 식별합니다.

SELECT
  PIPE_ID,
  CHANNEL_ID,
  STREAM_OFFSET,
  LAG(STREAM_OFFSET) OVER (
    PARTITION BY PIPE_ID, CHANNEL_ID
    ORDER BY STREAM_OFFSET
  ) AS previous_offset,
  (LAG(STREAM_OFFSET) OVER (
    PARTITION BY PIPE_ID, CHANNEL_ID
    ORDER BY STREAM_OFFSET
  ) + 1) AS expected_next
FROM my_table
QUALIFY STREAM_OFFSET != previous_offset + 1;
Copy

MATCH_BY_COLUMN_NAME을 사용한 수집 성능 및 비용 최적화

모든 데이터를 단일 VARIANT 열로 수집하는 대신, 소스 데이터에서 필요한 열을 매핑하도록 파이프를 구성합니다. 이렇게 하려면 :code:`MATCH_BY_COLUMN_NAME = CASE_SENSITIVE`를 사용하거나 파이프 정의에 변환을 적용합니다. 이 모범 사례는 수집 비용을 최적화할 뿐만 아니라 스트리밍 데이터 파이프라인의 전반적인 성능도 향상시킵니다.

이 모범 사례에는 다음과 같은 중요한 이점이 있습니다.

  • :code:`MATCH_BY_COLUMN_NAME = CASE_SENSITIVE`를 사용하여 대상 테이블에 수집된 데이터 값에 대해서만 요금이 청구됩니다. 반대로 데이터를 단일 VARIANT 열로 수집하면 키와 값을 모두 포함한 모든 JSON 바이트에 대해 요금을 청구합니다. 자세하거나 많은 JSON 키를 사용하는 데이터의 경우 이 경우 수집 비용이 불필요하게 크게 증가할 수 있습니다.

  • Snowflake의 처리 엔진은 계산 효율성이 더 높습니다. 전체 JSON 오브젝트를 VARIANT로 구문 분석한 다음, 필요한 열을 추출하는 대신, 이 메서드는 필요한 값을 직접 추출합니다.

언어: 한국어