데이터 로드 개요

데이터 로드 개요

이 주제는 Snowflake로 데이터를 로드할 때 사용할 수 있는 주요 옵션에 대한 개요를 제공해요.

데이터 파이프라인의 수집 지연 시간을 쉽고 정확하게 측정하려면 행 타임스탬프를 사용해요. 자세한 내용은 파이프라인에서 행 타임스탬프로 지연 시간 측정을 참고해요.

출처: Documentation

본문

지원되는 파일 위치

Snowflake는 클라우드 스토리지의 데이터 파일 위치를 *스테이지(stage)*라고 부르지만, 대량 및 연속 데이터 로드(Snowpipe) 모두에 사용되는 COPY INTO <table> 명령은 비즈니스 엔터티가 관리하는 클라우드 스토리지 계정(외부 스테이지)과 Snowflake 계정에 포함된 클라우드 스토리지(내부 스테이지)를 모두 지원해요.

외부 스테이지

Snowflake 계정을 호스팅하는 클라우드 플랫폼과 관계없이 다음 클라우드 스토리지 서비스 중 하나에서 데이터 로드가 지원돼요.

  • Amazon S3
  • Google Cloud Storage
  • Microsoft Azure

검색하기 전에 복원이 필요한 아카이브 클라우드 스토리지 클래스에 보관된 데이터에는 접근할 수 없어요. 이러한 아카이브 스토리지 클래스에는 예를 들어 Amazon S3 Glacier Flexible Retrieval 또는 Glacier Deep Archive 스토리지 클래스, Microsoft Azure Archive Storage가 포함돼요.

클라우드 스토리지 서비스가 제공하는 도구를 사용해 파일을 클라우드 스토리지 계정에 업로드(즉, 스테이징)해요.

이름이 있는 외부 스테이지는 스키마에 만든 데이터베이스 객체예요. 이 객체는 클라우드 스토리지의 파일 URL, 클라우드 스토리지 계정에 접근하는 데 사용되는 설정, 스테이징된 파일의 형식을 설명하는 옵션 같은 편의 설정을 저장해요. CREATE STAGE 명령으로 스테이지를 만들어요.

참고 — Snowflake 계정과 다른 리전이나 클라우드 플랫폼에 있는 클라우드 스토리지 서비스의 파일에서 데이터를 로드할 때 일부 데이터 전송 청구 요금이 적용될 수 있어요. 자세한 내용은 데이터 전송 비용 이해를 참고해요.

내부 스테이지

Snowflake는 계정에서 다음 스테이지 유형을 유지 관리해요.

  • 사용자(User): 파일 저장을 위해 각 사용자에게 사용자 스테이지가 할당돼요. 이 스테이지 유형은 단일 사용자가 스테이징하고 관리하지만 여러 테이블에 로드할 수 있는 파일을 저장하도록 설계됐어요. 사용자 스테이지는 변경하거나 삭제할 수 없어요.
  • 테이블(Table): Snowflake에 생성된 각 테이블에 테이블 스테이지를 사용할 수 있어요. 이 스테이지 유형은 한 명 이상의 사용자가 스테이징하고 관리하지만 단일 테이블에만 로드되는 파일을 저장하도록 설계됐어요. 테이블 스테이지는 변경하거나 삭제할 수 없어요. 테이블 스테이지는 별도의 데이터베이스 객체가 아니라 테이블 자체에 묶인 암시적 스테이지라는 점에 주의해요. 테이블 스테이지에는 자체적으로 부여 가능한 권한이 없어요. 테이블 스테이지에 파일을 스테이징하거나, 파일을 나열하거나, 스테이지에서 파일을 조회하거나, 파일을 삭제하려면 테이블 소유자(테이블에 OWNERSHIP 권한이 있는 역할)여야 해요.
  • 이름이 있는(Named): 이름이 있는 내부 스테이지는 스키마에 만든 데이터베이스 객체예요. 이 스테이지 유형은 한 명 이상의 사용자가 스테이징하고 관리하며 하나 이상의 테이블에 로드되는 파일을 저장할 수 있어요. 이름이 있는 스테이지는 데이터베이스 객체이므로 만들기, 수정, 사용, 삭제 기능을 보안 액세스 제어 권한으로 제어할 수 있어요. CREATE STAGE 명령으로 스테이지를 만들어요.

PUT 명령을 사용해 로컬 파일 시스템에서 내부 스테이지 유형 중 하나로 파일을 업로드해요.

대량 로드 대 연속 로드

Snowflake는 데이터 로드를 위한 다음과 같은 주요 솔루션을 제공해요. 어떤 솔루션이 가장 좋은지는 로드할 데이터의 양과 로드 빈도에 따라 달라질 수 있어요.

COPY 명령을 사용한 대량 로드

이 옵션은 클라우드 스토리지에 이미 있는 파일에서 데이터 배치를 로드하거나, COPY 명령을 사용해 테이블에 데이터를 로드하기 전에 로컬 머신의 데이터 파일을 내부(즉, Snowflake) 클라우드 스토리지 위치로 복사(즉, 스테이징)하는 것을 가능하게 해요.

컴퓨팅 리소스

대량 로드는 COPY 문에 지정된 사용자 제공 가상 웨어하우스에 의존해요. 사용자는 예상 로드를 수용하도록 웨어하우스를 적절히 크기 조정해야 해요.

로드 중 간단한 변환

Snowflake는 COPY 명령을 사용해 테이블에 데이터를 로드하면서 변환하는 것을 지원해요. 옵션은 다음과 같아요.

  • 컬럼 순서 변경
  • 컬럼 생략
  • 캐스트(Casts)
  • 대상 컬럼 길이를 초과하는 텍스트 문자열 잘라내기

데이터 파일이 대상 테이블과 같은 수와 순서의 컬럼을 가져야 한다는 요구 사항은 없어요.

Snowpipe를 사용한 연속 로드

이 옵션은 소량의 데이터(즉, 마이크로 배치)를 로드하고 분석에 사용할 수 있도록 점진적으로 제공하도록 설계됐어요. Snowpipe는 파일이 스테이지에 추가되어 수집용으로 제출된 후 몇 분 안에 데이터를 로드해요. 이를 통해 사용자는 원시 데이터가 사용 가능해지는 즉시 최신 결과를 얻을 수 있어요.

컴퓨팅 리소스

Snowpipe는 Snowflake가 제공하는 컴퓨팅 리소스(즉, 서버리스 컴퓨팅 모델)를 사용해요. 이러한 Snowflake 제공 리소스는 필요에 따라 자동으로 크기를 조정하고 확장/축소되며, 초당 요금으로 청구되고 항목별로 구분돼요. 데이터 수집은 실제 워크로드에 따라 청구돼요.

로드 중 간단한 변환

파이프 정의의 COPY 문은 대량 로드 시와 같은 COPY 변환 옵션을 지원해요.

또한 데이터 파이프라인은 자동화된 태스크와 스트림의 CDC(변경 데이터 캡처) 정보를 사용해 변환 및 최적화를 위해 마이크로 배치 데이터를 스테이징 테이블에 연속적으로 로드하도록 Snowpipe를 활용할 수 있어요.

Snowpipe Streaming을 사용한 연속 로드

Snowpipe Streaming API는 파일을 스테이징할 필요 없이 데이터 행을 Snowflake 테이블에 직접 기록해요. 이 아키텍처는 모든 양의 데이터를 로드할 때 더 낮은 로드 지연 시간과 그에 상응하는 더 낮은 비용을 제공하므로, 거의 실시간 데이터 스트림을 처리하는 강력한 도구예요.

Snowpipe Streaming은 또한 Kafka용 Snowflake 커넥터에서도 사용할 수 있어, 더 낮은 지연 시간과 비용의 로드를 활용하기 위한 쉬운 업그레이드 경로를 제공해요.

자세한 내용은 Snowpipe Streaming을 참고해요.

Apache Kafka 토픽에서 데이터 로드

Kafka용 Snowflake 커넥터를 사용하면 Apache Kafka 서버에 연결하고, 하나 이상의 토픽에서 데이터를 읽고, 그 데이터를 Snowflake 테이블에 로드할 수 있어요.

DML 오류 로깅

DML 문 집합을 실행할 때 문 중 하나가 오류로 실패하면 DML 작업이 끝나고 DML 문이 만든 변경 사항이 롤백돼요. 나머지 DML 문을 계속 실행하고 발생한 오류를 기록하려면 테이블에 대한 DML 오류 로깅을 켤 수 있어요. DML 오류 로깅이 켜진 테이블을 *기본 테이블(base table)*이라고 해요. 오류는 기본 테이블과 연결된 *오류 테이블(error table)*에 기록돼요.

DML 오류 로깅은 다음 조건이 모두 충족될 때만 테이블에 대해 켜져요.

  • 테이블에 대해 ERROR_LOGGING 속성이 TRUE로 설정됨.
  • 현재 세션에 대해 OPT_OUT_ERROR_LOGGING 매개 변수가 FALSE로 설정됨.

DML 오류 로깅은 다음 조건 중 하나가 충족될 때만 테이블에 대해 꺼져요.

  • 테이블에 대해 ERROR_LOGGING 속성이 FALSE로 설정됨.
  • 현재 세션에 대해 OPT_OUT_ERROR_LOGGING 매개 변수가 TRUE로 설정됨.

다음 섹션은 DML 오류 로깅에 대한 더 많은 정보를 제공해요.

DML 오류 로깅의 사용 사례

다음 사용 사례에서는 오류 시 실패를 피하기 위해 DML 오류 로깅을 사용할 수 있어요.

  • Oracle 데이터베이스의 데이터 같은 DML 오류 로깅에 의존하는 타사 데이터의 마이그레이션.
  • 데이터 수집 중 NOT NULL 제약 조건 같은 일부 테이블 제약 조건의 시행.

테이블에 대한 DML 오류 로깅 구성

표준 Snowflake 테이블 또는 Snowflake 관리 Iceberg 테이블을 만들거나 변경할 때 해당 테이블에 대한 DML 오류 로깅을 켜거나 끌 수 있어요.

테이블에 대한 오류 로깅을 켜거나 끄려면 다음 SQL 명령을 사용해 테이블의 ERROR_LOGGING 속성을 설정해요.

다음 예제는 테이블에 대한 DML 오류 로깅을 구성하고 오류가 오류 테이블에 기록되는 방법을 보여줘요.

행을 직접 삽입할 때 오류 기록

다음 예제는 테이블에 행을 직접 삽입할 때 오류를 기록해요.

  1. 테이블을 만들고 DML 오류 로깅을 켜요.
CREATE TABLE test_dml_error_logging(
  n NUMBER(4, 0) NOT NULL,
  t VARCHAR(5)
  )
  ERROR_LOGGING = true;
  1. 유효한 값과 유효하지 않은 값을 모두 포함한 여러 행을 삽입하려는 INSERT 문을 실행해요.
INSERT INTO test_dml_error_logging
  VALUES
 ('invalid_cast', '1'),
 (10, 'valid'),
 (NULL, 'toolong');

+-------------------------+
| number of rows inserted |
|-------------------------|
|                       1 |
+-------------------------+
  1. 테이블을 조회해 유효한 행 하나가 삽입되었는지 확인해요.
SELECT * FROM test_dml_error_logging;

+----+-------+
|  N | T     |
|----+-------|
| 10 | valid |
+----+-------+
  1. test_dml_error_logging 기본 테이블의 오류 테이블을 조회해 기록된 오류를 확인해요.
SELECT * FROM ERROR_TABLE(test_dml_error_logging);

+-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------+
| TIMESTAMP                     | QUERY_ID                             | ERROR_CODE | ERROR_METADATA                                                       | ERROR_DATA         |
|-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------|
| 2026-03-12 12:18:39.470 -0700 | 01c2fc06-000e-6668-0000-76b90170a28e |     100038 | {                                                                    | {                  |
|                               |                                      |            |   "error_code": 100038,                                              |   "N": [           |
|                               |                                      |            |   "error_message": "Numeric value 'invalid_cast' is not recognized", |     "invalid_cast" |
|                               |                                      |            |   "error_source": "N",                                               |   ],               |
|                               |                                      |            |   "sql_state": "22018"                                               |   "T": "1"         |
|                               |                                      |            | }                                                                    | }                  |
| 2026-03-12 12:18:39.470 -0700 | 01c2fc06-000e-6668-0000-76b90170a28e |     100072 | {                                                                    | {                  |
|                               |                                      |            |   "error_code": 100072,                                              |   "N": [           |
|                               |                                      |            |   "error_message": "NULL result in a non-nullable column",           |     null           |
|                               |                                      |            |   "error_source": "N",                                               |   ],               |
|                               |                                      |            |   "sql_state": "22000"                                               |   "T": [           |
|                               |                                      |            | }                                                                    |     "toolong"      |
|                               |                                      |            |                                                                      |   ]                |
|                               |                                      |            |                                                                      | }                  |
+-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------+
  1. test_dml_error_logging 테이블에 대한 DML 오류 로깅을 꺼요.
ALTER TABLE test_dml_error_logging
  SET ERROR_LOGGING = false;
  1. 이전에 실행한 것과 같은 INSERT 문을 시도해요. 오류가 반환되고 오류 테이블에 기록된 오류가 없어요.
INSERT INTO test_dml_error_logging
  VALUES
 ('invalid_cast', '1'),
 (10, 'valid'),
 (NULL, 'toolong');

100038 (22018): DML operation to table TEST_DML_ERROR_LOGGING failed on column N with error: Numeric value 'invalid_cast' is not recognized
한 테이블에서 다른 테이블로 행을 삽입할 때 오류 기록

다음 예제는 한 테이블에서 다른 테이블로 행을 삽입할 때 오류를 기록해요.

  1. 원본 테이블을 만들고 값을 삽입해요.
CREATE TABLE dml_error_logging_source(col1 INT);

INSERT INTO dml_error_logging_source VALUES (1), (0), (-1);
  1. 원본 테이블과 같은 정의로 대상 테이블을 만들어요.
CREATE TABLE dml_error_logging_target(col1 INT);
  1. dml_error_logging_target 테이블에서 DML 오류 로깅을 켜요.
ALTER TABLE dml_error_logging_target
  SET ERROR_LOGGING = true;
  1. 삽입 중 하나가 0으로 나누기 오류가 되도록 원본 테이블을 조회해 대상 테이블에 값을 삽입해요.
INSERT INTO dml_error_logging_target(col1)
  SELECT 1/col1 FROM dml_error_logging_source;

+-------------------------+
| number of rows inserted |
|-------------------------|
|                       2 |
+-------------------------+
  1. 테이블을 조회해 유효한 행 두 개가 삽입되었는지 확인해요.
SELECT * FROM dml_error_logging_target;

+------+
| COL1 |
|------|
|    1 |
|   -1 |
+------+
  1. dml_error_logging_target 기본 테이블의 오류 테이블을 조회해 기록된 오류를 확인해요.
SELECT * FROM ERROR_TABLE(dml_error_logging_target);

+-------------------------------+--------------------------------------+------------+----------------------------------------+-------------+
| TIMESTAMP                     | QUERY_ID                             | ERROR_CODE | ERROR_METADATA                         | ERROR_DATA  |
|-------------------------------+--------------------------------------+------------+----------------------------------------+-------------|
| 2026-03-12 12:25:56.297 -0700 | 01c2fc0d-000e-6696-0000-76b90170b64a |     100051 | {                                      | {           |
|                               |                                      |            |   "error_code": 100051,                |   "COL1": [ |
|                               |                                      |            |   "error_message": "Division by zero", |     1,      |
|                               |                                      |            |   "error_source": "COL1",              |     0       |
|                               |                                      |            |   "sql_state": "22012"                 |   ]         |
|                               |                                      |            | }                                      | }           |
+-------------------------------+--------------------------------------+------------+----------------------------------------+-------------+

오류 로깅과 오류 테이블

테이블에 대해 오류 로깅을 켜면 Snowflake는 기본 테이블과 연결된 오류 테이블을 자동으로 만들어요. 지원되는 오류를 만난 DML 작업은 실패하는 대신 오류를 오류 테이블에 기록해요.

테이블에 대해 DML 오류 로깅을 켜면 다음 유형의 DML 문이 기록돼요.

  • INSERT
  • UPDATE
  • MERGE

오류 테이블은 고정된 정의를 가지며 기본 테이블의 소유자 또는 기본 테이블에 SELECT ERROR TABLE 권한이 부여된 역할을 가진 사용자만 접근할 수 있어요. 오류 테이블에 대해 지원되는 직접 작업은 SELECT와 TRUNCATE 문뿐이에요. 오류 테이블에 대해 다른 유형의 문을 직접 실행할 수 없어요. 오류 테이블은 구체화된 뷰나 동적 테이블에서 간접적으로 사용할 수 없어요.

오류 테이블의 데이터를 다른 테이블로 복사할 수 있어요. TRUNCATE 명령을 실행해 오류 테이블의 데이터를 제거할 수 있어요.

다음 섹션은 오류 로깅과 오류 테이블에 대한 더 많은 정보를 제공해요.

오류 테이블 정의

Snowflake는 수정할 수 없는 표준 정의로 오류 테이블을 만들어요.

기본 테이블에 대한 DML 오류 로깅을 끄거나 오류 테이블이 있는 기본 테이블을 삭제하면 기본 테이블과 연결된 오류 테이블이 자동으로 삭제돼요.

오류 테이블에는 다음 컬럼이 있어요.

이름 유형 설명
timestamp TIMESTAMP 오류를 트리거한 문의 타임스탬프.
query_id VARCHAR 오류를 트리거한 문의 고유 ID.
error_code NUMBER 오류 코드. 한 행의 여러 컬럼에 오류가 있으면 이 컬럼은 만난 첫 번째 오류만 캡처해요.
error_metadata OBJECT 오류 메타데이터. OBJECT 값의 구조는 {"error_code": <value>, "error_message": "<value>", "error_source": "<value>", "sql_state": "<value>"}이에요. OBJECT 값은 다음 키-값 쌍을 포함해요. error_code: 오류 코드. error_message: 오류 메시지. error_source: 컬럼 이름 같은 오류의 원본. sql_state: ANSI SQL 표준 SQLSTATE를 모델로 한 다섯 문자 코드. Snowflake는 ANSI SQL 표준의 값 외에 추가 값을 사용해요. 한 행의 여러 컬럼에 오류가 있으면 이 컬럼은 만난 첫 번째 오류만 캡처해요.
error_data OBJECT 오류를 일으킨 데이터. OBJECT 값의 구조는 {"<column_name>": [<invalid_column_values>], "<column_name>": <valid_column_values>, ...}이에요. OBJECT 값은 기본 테이블의 각 컬럼을 나타내는 키-값 쌍을 포함해요. 키는 컬럼 이름이에요. DML 작업을 실패하게 한 유효하지 않은 컬럼 값의 경우 키-값 쌍의 값은 그 값을 포함하는 배열이에요. 유효한 값은 직접 표시되며, 즉 배열로 표시되지 않아요. 데이터가 OBJECT 값으로 나타낼 수 없으면 값은 NULL이에요.
오류 테이블과 상호작용

다음 문법을 사용해 오류 테이블에 대해 SELECT 문과 TRUNCATE 문을 실행할 수 있어요.

SELECT ... FROM ERROR_TABLE( <base_table_name> )

TRUNCATE [ TABLE ] [ IF EXISTS ] ERROR_TABLE( <base_table_name> )

여기서:

  • *base_table_name* — 오류 테이블이 생성된 테이블의 이름.

예를 들어 기본 테이블의 이름이 my_table이라면 다음 문은 이 기본 테이블의 오류 테이블을 조회해요.

SELECT * FROM ERROR_TABLE(my_table);

다음 문은 오류 테이블을 잘라내요.

TRUNCATE ERROR_TABLE(my_table);
오류 테이블의 액세스 제어 요구 사항

기본 테이블에 삽입할 수 있는 모든 역할은 그 오류 테이블에 대한 삽입을 트리거할 수 있어요. 현재 역할과 관계없이 오류 테이블에 대한 직접 삽입은 허용되지 않아요.

다음 사용자는 오류 테이블에 대해 SELECT 문을 실행할 수 있어요.

  • 오류 테이블의 기본 테이블 소유자.
  • 역할을 통하거나 직접 기본 테이블에 SELECT ERROR TABLE 권한이 부여된 사용자.

기본 테이블에 SELECT ERROR TABLE 권한을 부여하려면 GRANT <privileges> … TO ROLE 문 또는 GRANT <privileges> … TO USER 문을 실행해요.

이 문들은 다음 문법을 사용해요.

GRANT SELECT ERROR TABLE ON TABLE <base_table_name> TO ROLE <role_name>

GRANT SELECT ERROR TABLE ON TABLE <base_table_name> TO USER <user_name>

예를 들어 mybasetable이라는 기본 테이블에 대한 SELECT ERROR TABLE 권한을 myrole이라는 역할에 부여하려면 다음 문을 실행해요.

GRANT SELECT ERROR TABLE ON TABLE mybasetable TO ROLE myrole;

또는 다른 역할에 오류 테이블에 대한 액세스를 부여하려면 기본 테이블 소유자가 오류 테이블을 기반으로 뷰를 만들고 그 뷰에 액세스 권한을 부여할 수도 있어요.

오류 로깅에 대한 메타데이터

테이블에 대해 오류 로깅이 켜져 있는지 확인하려면 GET_DDL 함수를 실행하고 기본 테이블의 이름을 전달해요.

SELECT GET_DDL('TABLE', '[<namespace>.]<base_table_name>');

예를 들어 현재 스키마의 test_dml_error_logging이라는 기본 테이블에 대해 다음 문을 실행해요.

SELECT GET_DDL('TABLE', 'test_dml_error_logging');

+--------------------------------------------------+
| GET_DDL('TABLE', 'TEST_DML_ERROR_LOGGING')       |
|--------------------------------------------------|
| create or replace TABLE TEST_DML_ERROR_LOGGING ( |
|     N NUMBER(4,0) NOT NULL,                      |
|     T VARCHAR(5)                                 |
| ) ERROR_LOGGING = true                           |
| ;                                                |
+--------------------------------------------------+

오류 테이블에 대한 메트릭은 다음 뷰에 기록돼요.

오류 테이블의 스트림

스트림은 오류 테이블에서 직접 지원되지 않아요. 오류 테이블에서 변경 추적을 활성화하려면 먼저 오류 테이블에 뷰를 만든 다음 뷰에 스트림을 만들어요.

다음 예제는 오류 테이블에서 변경 추적을 활성화하는 방법을 보여줘요.

  1. CREATE VIEW 명령을 실행해 오류 테이블에 뷰를 만들어요.
CREATE VIEW my_error_view AS
  SELECT timestamp,
      query_id,
      error_code,
      error_metadata,
      error_data
 FROM ERROR_TABLE(test_dml_error_logging);
  1. CREATE STREAM 명령을 실행해 뷰에 스트림을 만들어요.
CREATE STREAM my_error_stream ON VIEW my_error_view;

DML 오류 로깅 사용 참고 사항

테이블에 대해 오류 로깅을 켤 때 다음 사용 참고 사항이 적용돼요.

  • 기본 테이블과 직접 관련된 오류만 기록돼요.
  • 다음 유형의 오류가 기록돼요.
    • NOT NULL 테이블 제약 조건 위반.
    • 값을 기본 테이블 컬럼으로 변환하려고 할 때 발생하는 형식 변환 오류.
    • 호환되지 않는 정밀도 및 스케일 값.
    • 문자열 및 이진 유형에 대한 호환되지 않는 길이.
    • 0으로 나누기 또는 PARSE_JSON 함수 실패 같은 일부 표현식 평가 실패.
  • CREATE TABLE … AS SELECT(CTAS) 문은 정상적으로 실행돼요. DML 오류 시 실패하고 오류를 기록하지 않아요.
  • 오류 로깅이 활성화된 테이블에 COPY INTO 문을 실행하려고 하면 컴파일 시간에 Error logging is not supported in statement 'COPY INTO' 오류가 반환돼요.
  • DML 오류 로깅이 지원하지 않는 오류는 DML 작업이 직접 실패하게 해요.
  • SQL 문이 컴파일 오류를 초래하면 작업이 끝나고 오류 테이블에 기록되는 오류가 없어요.
  • COPY와 Snowpipe 같은 다른 수집 경로에서 발생하는 실패는 오류 테이블에 기록되지 않아요. Snowpipe Streaming 고성능 오류 로깅은 고성능 아키텍처의 Snowpipe Streaming 오류 로깅을 참고해요.
  • DML 오류 로깅과 성능에 관한 고려 사항은 다음과 같아요.
    • 기본 테이블에 대해 DML 오류 로깅이 활성화되고 기본 테이블에 대해 실행된 DML 문에 오류가 없으면 성능 차이가 없거나 매우 적은 성능 차이가 예상돼요.
    • 기본 테이블에 대해 DML 오류 로깅이 활성화되고 기본 테이블에 대해 실행된 DML 문에 오류가 있으면 오류 정보가 오류 테이블에 삽입되므로 DML 문을 완료하는 데 추가 시간이 필요해요.
  • 연결된 오류 테이블이 있는 기본 테이블을 복제하면 동작은 다음과 같아요.
    • 기본 테이블의 스키마와 내용이 복제돼요.
    • 오류 테이블의 내용은 복제되지 않아요.
    • 복제된 기본 테이블은 ERROR_LOGGING 속성이 켜져 있어, 암시적으로 빈 오류 테이블을 만들어줘요.

스테이징된 반구조적 데이터 파일에서 컬럼 정의의 스키마 감지

반구조적 데이터는 수천 개의 컬럼을 포함할 수 있어요. Snowflake는 이 데이터를 처리하기 위한 강력한 솔루션을 제공해요. 옵션에는 외부 테이블을 사용해 클라우드 스토리지의 데이터를 직접 참조하기, 데이터를 VARIANT 유형의 단일 컬럼에 로드하기, 또는 표준 관계형 테이블의 별도 컬럼으로 데이터를 변환해 로드하기가 포함돼요. 이 모든 옵션은 데이터의 컬럼 정의에 대한 어느 정도의 지식이 필요해요.

다른 솔루션은 스테이징된 반구조적 데이터 파일 집합의 스키마를 자동으로 감지하고 컬럼 정의를 검색하는 것이에요. 컬럼 정의에는 파일의 컬럼 이름, 데이터 유형, 순서가 포함돼요. Snowflake 표준 테이블, 외부 테이블 또는 뷰를 만드는 데 적합한 형식으로 문법을 생성해요.

참고 — 이 기능은 Apache Parquet, Apache Avro, ORC, JSON, CSV 파일을 지원해요.

이 지원은 다음 SQL 함수를 통해 구현돼요.

  • INFER_SCHEMA — 스테이징된 데이터 파일 집합의 컬럼 정의를 감지하고 Snowflake 객체를 만드는 데 적합한 형식으로 메타데이터를 검색.
  • GENERATE_COLUMN_DESCRIPTION — INFER_SCHEMA 함수 출력을 사용해 스테이징된 파일 집합에서 컬럼 목록을 생성.

이 SQL 함수들은 내부 및 외부 스테이지를 모두 지원해요.

CREATE TABLE … USING TEMPLATE 또는 CREATE EXTERNAL TABLE … USING TEMPLATE 문법을 사용해 스테이징된 파일 집합에서 파생된 컬럼 정의로 테이블 또는 외부 테이블을 만들어요. USING TEMPLATE 절은 파일의 컬럼 정의를 감지하기 위해 INFER_SCHEMA SQL 함수를 호출하는 표현식을 받아요. 테이블을 만든 후에는 MATCH_BY_COLUMN_NAME 옵션과 함께 COPY 문을 사용해 파일을 구조적 테이블에 직접 로드할 수 있어요.

스키마 감지는 테이블 스키마 진화와 함께 사용할 수도 있으며, 이 경우 테이블 구조가 데이터 소스에서 받은 새 데이터의 구조를 지원하도록 자동으로 진화해요.

데이터 로드의 대안

데이터를 Snowflake 테이블에 로드하지 않고 클라우드 스토리지의 데이터를 조회하는 옵션을 사용할 수 있어요.

외부 테이블(데이터 레이크)

외부 테이블은 먼저 Snowflake에 로드하지 않고 외부 클라우드 스토리지에 저장된 기존 데이터를 분석을 위해 조회할 수 있게 해줘요. 데이터의 소스 진실(source of truth)은 외부 클라우드 스토리지에 그대로 유지돼요. 구체화된 뷰를 통해 Snowflake에서 구체화된 데이터 세트는 읽기 전용이에요.

이 솔루션은 외부 클라우드 스토리지에 많은 양의 데이터를 저장하고 그 일부만(예: 가장 최근 데이터) 조회하려는 계정에 특히 유용해요. 사용자는 이 데이터의 부분집합에 구체화된 뷰를 만들어 쿼리 성능을 개선할 수 있어요.

Amazon S3 호환 스토리지 사용

Snowflake에 외부 스테이지와 테이블을 만들어 Amazon S3 호환인 애플리케이션 또는 장치의 스토리지에 접근할 수 있어요. 이 기능을 사용하면 데이터가 어디에 저장되어 있든 데이터를 관리, 거버넌스, 분석할 수 있어요. 자세한 내용은 Amazon S3 호환 스토리지 사용을 참고해요.

더 알아보기