데이터 파일 준비하기¶

이 항목에서는 데이터 파일의 로드를 준비하기 위한 모범 사례, 일반 지침 및 중요한 고려 사항을 제공합니다.

이 항목의 내용:

파일 크기 조정 모범 사례 및 제한 사항¶

최상의 로드 성능과 크기 제한을 방지하기 위해 고려해야 하는 데이터 파일 크기 조정 지침은 다음과 같습니다. 이러한 권장 사항은 대량 데이터 로드와 Snowpipe를 사용한 연속 로드에 적용됩니다.

일반 파일 크기 조정 권장 사항¶

병렬로 실행되는 로드 작업의 수는 로드할 데이터 파일의 수를 초과할 수 없습니다. 로드에 대한 병렬 작업 수를 최적화하려면 압축 크기의 데이터 파일을 대략 100~250 MB(또는 이상)의 크기로 생성하는 것이 좋습니다.

참고

매우 큰 파일(예: 100 GB 이상)은 로드하지 않는 것이 좋습니다.

대용량 파일을 로드해야 하는 경우 ON_ERROR 복사 옵션 값을 신중하게 설정해야 합니다. 적은 수의 오류로 인해 파일을 중단하거나 건너뛰면 지연이 발생하고 크레딧이 낭비될 수 있습니다. 또한, 데이터 로딩 작업이 최대 허용 기간인 24시간을 초과하여 계속 수행되면 파일이 전혀 커밋되지 않고 중단될 수 있습니다.

각 파일에 대한 처리 오버헤드를 최소화하기 위해 더 작은 파일을 집계합니다. 더 큰 파일을 더 많은 수의 더 작은 파일로 분할하여 활성 웨어하우스의 컴퓨팅 리소스 간에 로드를 분산합니다. 병렬로 처리할 수 있는 데이터 파일의 수는 웨어하우스의 컴퓨팅 리소스 양에 따라 결정됩니다. 레코드가 청크 사이에 걸쳐있는 것을 방지하기 위해 큰 파일을 라인별로 분할하는 것이 좋습니다.

소스 데이터베이스에서 데이터 파일을 더 작은 청크로 내보낼 수 없는 경우 서드 파티 유틸리티를 사용하여 큰 CSV 파일을 분할할 수 있습니다.

Linux 또는 macOS¶

split 유틸리티를 사용하면 CSV 파일을 크기가 작은 여러 파일로 분할할 수 있습니다.

구문:

split [-a suffix_length] [-b byte_count[k|m]] [-l line_count] [-p pattern] [file [name]]

Copy

자세한 내용을 살펴보려면 터미널 창에 man split 을 입력하면 됩니다.

예:

split -l 100000 pagecounts-20151201.csv pages

Copy

이 예에서는 이름이 pagecounts-20151201.csv 인 파일을 라인 길이를 기준으로 분할합니다. 큰 단일 파일의 크기가 8 GB이고 라인 수는 1천만 라인으로 가정해 보겠습니다. 100,000으로 나누면 100개의 작은 파일 각각은 크기가 80 MB입니다(10,000,000 / 100,000 = 100). 분할된 파일의 이름은 pages<suffix> 입니다.

Windows¶

Windows에는 기본 파일 분할 유틸리티가 포함되어 있지 않지만, Windows는 대용량 데이터 파일을 분할할 수 있는 많은 서드 파티 도구 및 스크립트를 지원합니다.

반정형 데이터 크기 제한 사항¶

VARIANT의 최대 크기는 압축되지 않은 데이터로 16MB일 수 있습니다. 하지만 실제로는 내부 오버헤드로 인해 최대 크기가 보통 더 작습니다. 최대 크기는 저장되는 오브젝트에 따라서도 달라집니다.

자세한 내용은 VARIANT 섹션을 참조하십시오.

일반적으로 JSON 데이터 세트는 여러 문서를 단순하게 연결한 것입니다. 일부 소프트웨어의 JSON 출력은 여러 레코드를 포함하는 하나의 커다란 배열로 구성됩니다. 둘 다 지원되지만 줄 바꿈이나 쉼표로 문서를 구분할 필요는 없습니다.

데이터의 크기가 16 MB를 초과하는 경우, COPY INTO <테이블> 명령에 대해 STRIP_OUTER_ARRAY 파일 형식 옵션을 활성화하여 외부 배열 구조를 제거하고 레코드를 별도의 테이블 행에 로딩하는 것이 좋습니다.

COPY INTO <table>
  FROM @~/<file>.json
  FILE_FORMAT = (TYPE = 'JSON' STRIP_OUTER_ARRAY = true);

Copy

연속 데이터 로드(즉, Snowpipe) 및 파일 크기 조정¶

Snowpipe는 일반적으로 파일 알림이 전송된 후 1분 이내에 새 데이터를 로드하도록 설계되었습니다. 그러나 실제로 큰 파일의 경우 또는 새 데이터의 압축을 풀고 암호를 해독하며 변환하는 데 비정상적인 양의 컴퓨팅 리소스가 필요한 경우 로드하는 데 훨씬 더 오래 걸릴 수 있습니다.

Snowpipe에 부과되는 사용 비용에는 리소스 소비뿐만 아니라 내부 로드 큐에서 파일을 관리하기 위한 오버헤드가 포함됩니다. 이 오버헤드는 로드를 위해 큐에서 대기 중인 파일 수와 관련하여 증가합니다. Snowpipe는 자동 외부 테이블 새로 고침을 위한 이벤트 알림에 사용되므로 이 간접비는 청구서에 Snowpipe 요금으로 나타납니다.

Snowpipe에서 가장 효율적이고 비용 효율적인 로드 경험을 위해 이 항목의 파일 크기 조정 모범 사례 및 제한 사항 의 파일 크기 권장 사항을 따르는 것이 좋습니다. 크기가 대략 100~250 MB 이상인 데이터 파일을 로드하면 오버헤드 비용이 중요하지 않은 지점까지 로드된 총 데이터 양에 비해 오버헤드 비용이 감소합니다.

소스 애플리케이션에 데이터 MBs를 누적하는 데 1분 이상이 걸리면 분당 한 번씩 새(더 작은) 데이터 파일을 생성하는 것이 좋습니다. 이러한 방식을 통해 일반적으로 비용(예: Snowpipe 큐 관리 및 실제 로드에 사용되는 리소스)과 성능(예: 로드 지연 시간) 간의 균형을 유지할 수 있습니다.

더 작은 데이터 파일을 생성하고 이를 1분에 한 번 이상 클라우드 저장소에 스테이징하면 다음과 같은 단점이 유발됩니다.

데이터 스테이징과 로드 사이의 대기 시간 감소를 보장할 수 없습니다.
내부 로드 큐에서 파일을 관리하기 위한 오버헤드가 Snowpipe에 부과되는 사용 비용에 포함됩니다. 이 오버헤드는 로드를 위해 큐에서 대기 중인 파일 수와 관련하여 증가합니다.

다양한 도구가 데이터 파일을 집계하고 배치할 수 있습니다. 편리한 옵션 중 하나는 Amazon Data Firehose입니다. Firehose를 사용하면 버퍼 크기 라고 하는 원하는 파일 크기와 버퍼 간격 이라고 하는 새 파일 전송 후(이 경우 클라우드 저장소로) 대기 간격을 모두 정의할 수 있습니다. 자세한 내용은 Amazon Data Firehose 설명서 를 참조하십시오. 소스 애플리케이션이 일반적으로 최적의 병렬 처리를 위해 권장되는 최대값보다 큰 파일을 채울 만큼 충분한 데이터를 1분 이내에 누적하는 경우 버퍼 크기를 줄여 더 작은 파일 전달을 트리거할 수 있습니다. 버퍼 간격 설정을 60초(최소값)로 유지하면 파일이 너무 많이 생성되거나 대기 시간이 늘어나는 것을 방지하는 데 도움이 됩니다.

구분 기호로 분리된 텍스트 파일 준비하기¶

로드할 구분 기호로 분리된 텍스트(CSV) 파일을 준비할 때 고려해야 하는 지침은 다음과 같습니다.

UTF-8이 기본 문자 세트이지만 추가 인코딩이 지원됩니다. ENCODING 파일 형식 옵션을 사용하여 데이터 파일의 문자 세트를 지정합니다. 자세한 내용은 CREATE FILE FORMAT 섹션을 참조하십시오.
구분 문자가 포함된 필드는 따옴표(작은따옴표 또는 큰따옴표)로 묶어야 합니다. 데이터에 작은따옴표나 큰따옴표가 포함된 경우 해당 따옴표를 이스케이프해야 합니다.
Windows 시스템에서는 일반적으로 캐리지 리턴과 라인의 끝(\r \n)을 표시하는 줄 바꿈 문자가 함께 사용됩니다. 캐리지 리턴이 포함된 필드도 따옴표(작은따옴표 또는 큰따옴표)로 묶어야 합니다.
각 행의 열 수는 일정해야 합니다.

반정형 데이터 파일 및 세로 행 배치¶

반정형 데이터가 VARIANT 열에 삽입되면 Snowflake는 특정 규칙을 사용하여 최대한 많은 데이터를 열 형식으로 추출합니다. 나머지 데이터는 구문 분석된 반정형 구조의 단일 열로 저장됩니다.

기본적으로 Snowflake는 테이블마다 파티션당 최대 200개의 요소를 추출합니다. 이 한도를 늘리려면 Snowflake 지원 에 문의하십시오.

추출되지 않는 요소¶

다음과 같은 특성을 가진 요소는 열로 추출되지 않습니다.

단일 “null” 값을 포함하는 요소는 열로 추출되지 않습니다. 이 규칙은 열 형식으로 표시되는 누락 값이 있는 요소가 아닌 “null” 값을 가진 요소에 적용됩니다.

이 규칙을 통해 정보의 손실이 방지됩니다(즉, VARIANT “null” 값과 SQL NULL 값의 차이가 손실되지 않음).
여러 데이터 타입을 포함하는 요소입니다. 예:

한 행의 foo 요소에는 숫자가 포함됩니다.
```
{"foo":1}
```
Copy
다른 행의 동일한 요소에 문자열이 포함되어 있습니다.
```
{"foo":"1"}
```
Copy

추출이 쿼리에 미치는 영향¶

반정형 요소를 쿼리할 때 Snowflake의 실행 엔진은 요소의 추출 여부에 따라 다르게 동작합니다.

요소가 열로 추출된 경우 엔진은 추출된 열만 검색합니다.
요소가 열로 추출되지 않은 경우 엔진은 전체 JSON 구조를 스캔한 후 각 행에 대해 구조를 트래버스하여 값을 출력합니다. 이는 성능에 영향을 미칩니다.

추출되지 않은 요소에 대한 성능 영향을 방지하려면 다음을 수행하십시오.

“null” 값을 포함하는 반정형 데이터 요소를 관계형 열로 추출한 후 로드합니다.

또는 파일의 “null” 값이 누락된 값을 나타내고 다른 특별한 의미가 없는 경우 반정형 데이터 파일을 로드할 때 파일 형식 옵션 STRIP_NULL_VALUES를 TRUE로 설정하는 것이 좋습니다. 이 옵션은 “null” 값을 포함하는 OBJECT 요소 또는 ARRAY 요소를 제거합니다.
각 고유 요소가 해당 형식에 고유한 단일 데이터 타입의 값을 저장하는지 확인합니다(예: JSON의 경우 문자열 또는 숫자).

숫자 데이터 지침¶

쉼표와 같은 포함된 문자(예: 123,456)를 사용하지 마십시오.
숫자에 분수 구성 요소가 포함된 경우 소수점으로 정수 부분과 구분해야 합니다(예: 123456.789).
Oracle만 해당. Oracle NUMBER 또는 NUMERIC 타입은 임의의 스케일을 허용합니다. 즉, 데이터 타입이 정밀도 또는 스케일로 정의되지 않은 경우에도 소수 구성 요소가 있는 값을 허용합니다. 반면에 Snowflake에서는 소수 구성 요소가 있는 값에 대해 설계된 열을 소수 부분을 유지하기 위한 스케일로 정의해야 합니다.

날짜 및 타임스탬프 데이터 지침¶

날짜, 시간 및 타임스탬프 데이터에 대해 지원되는 형식에 관한 자세한 내용은 날짜 및 시간 입력 및 출력 형식 섹션을 참조하십시오.
Oracle만 해당. Oracle DATE 데이터 타입에는 날짜 또는 타임스탬프 정보를 포함할 수 있습니다. Oracle 데이터베이스에 시간 관련 정보도 저장하는 DATE 열이 포함된 경우 이러한 열은 DATE가 아닌 Snowflake의 TIMESTAMP 데이터 타입에 매핑합니다.

참고

Snowflake는 로드 시 임시 데이터 값을 확인합니다. 유효하지 않은 날짜, 시간 및 타임스탬프 값(예: 0000-00-00)을 사용하면 오류가 발생합니다.