데이터 파일 준비하기¶

파일 크기 조정 모범 사례¶

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

데이터베이스 오브젝트의 크기 제한¶

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2025_03');

사용 가능한 메서드를 사용하여 Snowflake에 데이터를 로드 할 때 이제 16 MB 보다 큰 크기의 오브젝트를 열에 저장할 수 있습니다. 특정 데이터 타입에는 다음과 같은 제한이 적용됩니다.

VARCHAR 열의 기본 크기는 16 MB (이진의 경우 8 MB)입니다. 16 MB 보다 큰 열이 있는 테이블을 생성할 때는, 크기를 명시적으로 지정하십시오. 예:

CREATE OR REPLACE TABLE my_table (
  c1 VARCHAR(134217728),
  c2 BINARY(67108864));

VARCHAR 열에 대한 새로운 제한을 사용하려면 테이블을 변경하여 열 크기를 변경하면 됩니다. 예:

ALTER TABLE my_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

이러한 테이블에서 BINARY 유형의 열에 새 크기를 적용하려면 테이블을 다시 생성합니다. 기존 테이블에서 BINARY 열의 길이는 변경할 수 없습니다.

ARRAY, GEOGRAPHY, GEOMETRY, OBJECT, VARIANT 유형의 열의 경우 기본적으로 길이를 지정하지 않고도 기존 테이블과 새 테이블에 16 MB 보다 큰 오브젝트를 저장할 수 있습니다. 예:

CREATE OR REPLACE TABLE my_table (c1 VARIANT);

이러한 변경 사항은 Unistore 워크로드에는 영향을 미치지 않습니다. 하이브리드 테이블의 경우 모든 현재 제한은 변경되지 않습니다.

새로운 크기 제한이 도입되기 전에 생성된 VARIANT, VARCHAR 또는 BINARY 값을 입력 또는 출력으로 사용하는 프로시저와 함수도 16 MB 보다 큰 오브젝트를 지원하도록 (지정된 길이 제외) 다시 생성해야 합니다. 예:

CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
  RETURNS VARCHAR
  AS $$
    'Hello' || g1
  $$;

관리되지 않는 Iceberg 테이블 의 경우 VARCHAR 및 BINARY 열의 기본 길이는 128 MB 입니다. 이 기본 길이는 새로 생성할거나 새로 고친 테이블에 적용됩니다. 새 크기 제한이 활성화되기 전에 생성되고 새로 고치지 않은 테이블은 여전히 이전 기본 길이를 유지합니다.

관리되는 Iceberg 테이블의 경우 VARCHAR 및 BINARY 열의 기본 길이는 128 MB 입니다. 새로운 크기 제한이 활성화되기 전에 생성된 테이블은 여전히 이전의 기본 길이를 유지합니다. 이러한 테이블에서 VARCHAR 유형의 열에 새 크기를 적용하려면 테이블을 다시 만들거나 열을 변경합니다. 다음 예는 새로운 크기 제한을 사용하도록 열을 변경하는 예제입니다.

ALTER ICEBERG TABLE my_iceberg_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

이러한 테이블에서 BINARY 유형의 열에 새 크기를 적용하려면 테이블을 다시 생성합니다. 기존 테이블에서 BINARY 열의 길이는 변경할 수 없습니다.

100067 (54000): The data length in result column <column_name> is not supported by this version of the client.
Actual length <actual_size> exceeds supported length of 16777216.

Max LOB size (16777216) exceeded

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

{
  "ID": 1,
  "CustomerDetails": {
    "RegistrationDate": 158415500,
    "FirstName": "John",
    "LastName": "Doe",
    "Events": [
      {
        "Type": "LOGIN",
        "Time": 1584158401,
        "EventID": "NZ0000000001"
      },
      /* ... */
      /* this array contains thousands of elements */
      /* with total size exceeding 16 MB */
      /* ... */
      {
        "Type": "LOGOUT",
        "Time": 1584158402,
        "EventID": "NZ0000000002"
      }
    ]
  }
}

CREATE OR REPLACE TABLE mytable AS
  SELECT
    t1.$1:ID AS id,
    t1.$1:CustomerDetails:RegistrationDate::VARCHAR AS RegistrationDate,
    t1.$1:CustomerDetails:FirstName::VARCHAR AS First_Name,
    t1.$1:CustomerDetails:LastName::VARCHAR AS as Last_Name,
    t2.value AS Event
  FROM @json t1,
    TABLE(FLATTEN(INPUT => $1:CustomerDetails:Events)) t2;

+----+-------------------+------------+------------+------------------------------+
| ID | REGISTRATION_DATE | FIRST_NAME | LAST_NAME  | EVENT                        |
|----+-------------------+------------+------------+------------------------------|
| 1  | 158415500         | John       | Doe        | {                            |
|    |                   |            |            |   "EventID": "NZ0000000001", |
|    |                   |            |            |   "Time": 1584158401,        |
|    |                   |            |            |   "Type": "LOGIN"            |
|    |                   |            |            | }                            |
|                     ... thousands of rows ...                                   |
| 1  | 158415500         | John       | Doe        | {                            |
|    |                   |            |            |   "EventID": "NZ0000000002", |
|    |                   |            |            |   "Time": 1584158402,        |
|    |                   |            |            |   "Type": "LOGOUT"           |
|    |                   |            |            | }                            |
+----+-------------------+------------+------------+------------------------------+

CREATE OR REPLACE TABLE mytable (
  id VARCHAR,
  registration_date VARCHAR(16777216),
  first_name VARCHAR(16777216),
  last_name VARCHAR(16777216),
  event VARCHAR(16777216));

INSERT INTO mytable
  SELECT
    t1.$1:ID,
    t1.$1:CustomerDetails:RegistrationDate::VARCHAR,
    t1.$1:CustomerDetails:FirstName::VARCHAR,
    t1.$1:CustomerDetails:LastName::VARCHAR,
    t2.value
  FROM @json t1,
    TABLE(FLATTEN(INPUT => $1:CustomerDetails:Events)) t2;

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmium/1.14.0">
  <node id="197798" version="17" timestamp="2021-09-06T17:01:27Z" />
  <node id="197824" version="7" timestamp="2021-08-04T23:17:18Z" >
    <tag k="highway" v="traffic_signals"/>
  </node>
  <!--  thousands of node elements with total size exceeding 16 MB -->
  <node id="197826" version="4" timestamp="2021-08-04T16:43:28Z" />
</osm>

CREATE OR REPLACE TABLE mytable AS
  SELECT
    value:"@id" AS id,
    value:"@version" AS version,
    value:"@timestamp"::datetime AS TIMESTAMP,
    value:"$" AS tags
  FROM @mystage,
    LATERAL FLATTEN(INPUT => $1:"$")
  WHERE value:"@" = 'node';

+--------+---------+-------------------------+---------------------------------------------+
| ID     | VERSION | TIMESTAMP               | TAGS                                        |
|--------+---------+-------------------------+---------------------------------------------|
| 197798 | 17      | 2021-09-06 17:01:27.000 | ""                                          |
| 197824 | 7       | 2021-08-04 23:17:18.000 | <tag k="highway" v="traffic_signals"></tag> |
|                   ... thousands of rows ...                                              |
| 197826 | 4       | 2021-08-04 16:43:28.000 | ""                                          |
+--------+---------+-------------------------+---------------------------------------------+

CREATE OR REPLACE TABLE mytable AS
  SELECT
    ST_SIMPLIFY($1:geo, 10) AS geo
  FROM @mystage;

CREATE OR REPLACE TABLE mytable (
  id VARCHAR,
  registration_date VARCHAR,
  first_name VARCHAR,
  last_name VARCHAR);

COPY INTO mytable (
  id,
  registration_date,
  first_name,
  last_name
) FROM (
    SELECT
      $1:ID,
      $1:CustomerDetails::OBJECT:RegistrationDate::VARCHAR,
      $1:CustomerDetails::OBJECT:FirstName::VARCHAR,
      $1:CustomerDetails::OBJECT:LastName::VARCHAR
    FROM @mystage
);

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

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

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

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

소스 애플리케이션에 데이터 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 지원 에 문의하십시오.

숫자 데이터 지침¶

• 쉼표와 같은 포함된 문자(예: 123,456)를 사용하지 마십시오.

• 숫자에 분수 구성 요소가 포함된 경우 소수점으로 정수 부분과 구분해야 합니다(예: 123456.789).

• Oracle만 해당. Oracle NUMBER 또는 NUMERIC 타입은 임의의 스케일을 허용합니다. 즉, 데이터 타입이 정밀도 또는 스케일로 정의되지 않은 경우에도 소수 구성 요소가 있는 값을 허용합니다. 반면에 Snowflake에서는 소수 구성 요소가 있는 값에 대해 설계된 열을 소수 부분을 유지하기 위한 스케일로 정의해야 합니다.

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

• 날짜, 시간 및 타임스탬프 데이터에 대해 지원되는 형식에 관한 자세한 내용은 날짜 및 시간 입력 및 출력 형식 섹션을 참조하십시오.

• Oracle만 해당. Oracle DATE 데이터 타입에는 날짜 또는 타임스탬프 정보를 포함할 수 있습니다. Oracle 데이터베이스에 시간 관련 정보도 저장하는 DATE 열이 포함된 경우 이러한 열은 DATE가 아닌 Snowflake의 TIMESTAMP 데이터 타입에 매핑합니다.