Snowflake는 비용, 이벤트 노이즈, 지연 시간을 줄이기 위해 Snowpipe용 클라우드 이벤트 필터링을 활성화할 것을 권장해요. 클라우드 공급자의 이벤트 필터링 기능만으로 충분하지 않을 때만 PATTERN 옵션을 사용해요. 각 클라우드 공급자의 이벤트 필터링 구성에 대한 자세한 내용은 다음 페이지를 참고해요.
COPY 문이 실행되면 Snowflake가 문에서 참조된 데이터 파일에 대해 테이블 메타데이터에 로드 상태를 설정해요. 이는 병렬 COPY 문이 같은 파일을 테이블로 로드하는 것을 방지해 데이터 중복을 피해요.
COPY 문 처리가 완료되면 Snowflake가 데이터 파일에 대한 로드 상태를 적절히 조정해요. 하나 이상의 데이터 파일이 로드에 실패하면 Snowflake가 해당 파일의 로드 상태를 로드 실패로 설정해요. 이 파일들은 후속 COPY 문이 로드할 수 있어요.
워크로드가 같은 테이블에 데이터를 로드하는 고도의 동시 COPY 문으로 구성되어 있다면 Snowpipe를 사용해요. Snowpipe는 동시 COPY 문을 처리하도록 설계되었고 테이블 메타데이터 관리를 포함한 병렬 작업을 더 잘 활용할 수 있기 때문이에요. 시간이 지나면서 데이터 볼륨과 실행된 로드 빈도의 변화 가능성 때문에 기존 COPY 문 워크로드를 Snowpipe로 마이그레이션하는 것을 고려할 수도 있어요. 그동안 COPY 문을 간격을 두고 실행해 동시성을 줄이면 더 나은 성능을 얻을 수 있어요.
명령이 파일의 로드 상태가 알려졌는지 알려지지 않았는지에 따라 데이터 중복을 다르게 방지하는 방법을 설명해요. 경로별 데이터 조직에서 권장한 대로 스테이지의 데이터를 날짜로 논리적·세분화된 경로로 파티셔닝하고 스테이징 후 짧은 시간 안에 데이터를 로드한다면 이 섹션은 대부분 적용되지 않아요. 그러나 COPY 명령이 데이터 로드에서 이전 파일(즉, 과거 데이터 파일)을 건너뛴다면 이 섹션은 기본 동작을 우회하는 방법을 설명해요.
로드 메타데이터
Snowflake는 데이터가 로드된 각 테이블에 대해 상세한 메타데이터를 유지하며 다음을 포함해요.
- 데이터가 로드된 각 파일의 이름
- 파일 크기
- 파일의 ETag
- 파일에서 파싱된 행 수
- 파일의 마지막 로드 타임스탬프
- 로딩 중 파일에서 만난 오류에 대한 정보
이 로드 메타데이터는 64일 후에 만료돼요. 스테이징된 데이터 파일의 LAST_MODIFIED 날짜가 64일 이하이면 COPY 명령이 주어진 테이블에 대한 로드 상태를 결정하고 다시 로드(및 데이터 중복)를 방지할 수 있어요. LAST_MODIFIED 날짜는 파일이 처음 스테이징된 시각 또는 마지막으로 수정된 시각 중 나중 것의 타임스탬프예요.
LAST_MODIFIED 날짜가 64일보다 오래된 경우에도 다음 이벤트 중 하나가 현재 날짜로부터 64일 이하에 발생했다면 로드 상태가 여전히 알려져 있어요.
- 파일이 성공적으로 로드되었음.
- 테이블의 초기 데이터 집합(즉, 테이블 생성 후 첫 배치)이 로드되었음.
그러나 LAST_MODIFIED 날짜가 64일보다 오래되고 초기 데이터 집합이 64일보다 일찍 테이블에 로드된 경우(파일이 테이블에 로드되었다면 그것도 64일보다 일찍 발생했다면) COPY 명령은 파일이 이미 로드되었는지 확정적으로 결정할 수 없어요. 이 경우 우발적인 재로드를 방지하기 위해 명령이 기본적으로 파일을 건너뜁니다.
우회 방법
메타데이터가 만료된 파일을 로드하려면 LOAD_UNCERTAIN_FILES 복사 옵션을 true로 설정해요. 이 복사 옵션은 가능하면 로드 메타데이터를 참조해 데이터 중복을 피하지만 만료된 로드 메타데이터가 있는 파일도 로드하려 시도해요.
또는 FORCE 옵션을 설정해 존재한다면 로드 메타데이터를 무시하고 모든 파일을 로드해요. 이 옵션은 파일을 다시 로드해 테이블의 데이터를 중복시킬 수 있다는 점에 주의해요.
예
이 예에서:
- 3월 1일에 테이블이 생성되고 같은 날 초기 테이블 로드가 발생해요.
- 64일이 지나 5월 4일에 로드 메타데이터가 만료돼요.
- 파일이 각각 7월 1일과 2일에 스테이징되고 테이블에 로드돼요. 파일이 로드되기 하루 전에 스테이징되었으므로 LAST_MODIFIED 날짜는 64일 이내였어요. 로드 상태가 알려져 있었어요. 파일에 데이터·형식 문제가 없었고 COPY 명령이 성공적으로 로드해요.
- 64일이 지나 9월 3일에 스테이징된 파일의 LAST_MODIFIED 날짜가 64일을 초과해요. 9월 4일에 성공적인 파일 로드의 로드 메타데이터가 만료돼요.
- 11월 1일에 같은 테이블에 파일을 다시 로드하려는 시도가 이루어져요. COPY 명령이 파일이 이미 로드되었는지 결정할 수 없으므로 파일이 건너뛰어져요. 파일을 로드하려면 LOAD_UNCERTAIN_FILES 복사 옵션(또는 FORCE 복사 옵션)이 필요해요.
이 예에서:
- 파일이 3월 1일에 스테이징돼요.
- 64일이 지나 5월 4일에 스테이징된 파일의 LAST_MODIFIED 날짜가 64일을 초과해요.
- 9월 29일에 새 테이블이 생성되고 스테이징된 파일이 테이블에 로드돼요. 초기 테이블 로드가 64일 미만 전에 발생했으므로 COPY 명령이 파일이 이미 로드되지 않았음을 결정할 수 있어요. 파일에 데이터·형식 문제가 없었고 COPY 명령이 성공적으로 로드해요.
JSON 데이터: "null" 값 제거
VARIANT 컬럼에서 NULL 값은 SQL NULL 값이 아니라 "null"이라는 단어를 포함하는 문자열로 저장돼요. JSON 문서의 "null" 값이 누락된 값을 나타내고 다른 특별한 의미가 없다면 JSON 파일을 로드할 때 COPY INTO
명령에 대해 파일 형식 옵션 STRIP_NULL_VALUES를 TRUE로 설정할 것을 권장해요. "null" 값을 유지하면 종종 저장 공간을 낭비하고 쿼리 처리를 느리게 해요.
CSV 데이터: 앞 공백 자르기
외부 소프트웨어가 따옴표로 묶인 필드를 내보내지만 각 필드의 여는 따옴표 문자 앞에 앞 공백을 삽입한다면, Snowflake는 여는 따옴표 문자 대신 앞 공백을 필드의 시작으로 읽어요. 따옴표 문자는 문자열 데이터로 해석돼요.
데이터 로드 중에 원하지 않는 공백을 제거하려면 TRIM_SPACE 파일 형식 옵션을 사용해요.
예를 들어 예시 CSV 파일의 각 필드는 앞 공백을 포함해요:
"value1", "value2", "value3"
다음 COPY 명령은 앞 공백을 자르고 각 필드를 묶는 따옴표를 제거해요:
COPY INTO mytable
FROM @%mytable
FILE_FORMAT = (TYPE = CSV TRIM_SPACE=true FIELD_OPTIONALLY_ENCLOSED_BY = '0x22');
SELECT * FROM mytable;
+--------+--------+--------+
| col1 | col2 | col3 |
+--------+--------+--------+
| value1 | value2 | value3 |
+--------+--------+--------+
더 알아보기 (Learn more)
