데이터 로딩 개요

이 항목에서는 Snowflake에 데이터를 로드하는 데 사용할 수 있는 기본 옵션에 대한 개요를 제공합니다.

데이터 파이프라인의 수집 대기 시간을 쉽고 정확하게 측정하려면 행 타임스탬프를 사용합니다. 자세한 내용은 행 타임스탬프를 사용하여 파이프라인의 대기 시간 측정 섹션을 참조하십시오.

지원되는 파일 위치

Snowflake에서는 클라우드 저장소의 데이터 파일 위치를 스테이지 라고 합니다. 대량 및 연속 데이터 로드(예: Snowpipe)에 사용되는 COPY INTO <테이블> 명령은 비즈니스 엔터티에서 관리하는 클라우드 저장소 계정(예: 외부 스테이지)과 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가 사용자 계정에서 관리하는 스테이지 타입은 다음과 같습니다.

사용자:

사용자 스테이지는 파일을 저장하기 위해 각 사용자에게 할당됩니다. 이 스테이지 타입은 단일 사용자가 스테이징 및 관리하지만 여러 테이블에 로드할 수 있는 파일을 저장하도록 설계되었습니다. 사용자 스테이지는 변경 또는 삭제가 불가능합니다.

테이블:

Snowflake에서 생성된 각 테이블에 대해 테이블 스테이지를 사용할 수 있습니다. 이 스테이지 타입은 한 명 이상의 사용자가 스테이징하고 관리하지만 단일 테이블에만 로드되는 파일을 저장하도록 설계되었습니다. 테이블 스테이지는 변경 또는 삭제가 불가능합니다.

테이블 스테이지는 별도의 데이터베이스 오브젝트가 아닌, 테이블 자체에 연결된 암시적 스테이지입니다. 테이블 스테이지에는 자체적으로 할당할 수 있는 권한이 없습니다. 파일을 테이블 스테이지로 스테이징하거나, 파일을 나열하거나, 스테이지에서 쿼리하거나, 삭제하려면 테이블 소유자여야 합니다(테이블에 대한 OWNERSHIP 권한이 있는 역할이 있어야 함).

명명된 스테이지:

명명된 내부 스테이지는 스키마에서 생성된 데이터베이스 오브젝트입니다. 이 스테이지 타입은 한 명 이상의 사용자가 스테이징 및 관리하고 하나 이상의 테이블에 로드되는 파일을 저장할 수 있습니다. 명명된 스테이지는 데이터베이스 오브젝트이기 때문에 보안 액세스 제어 권한을 사용하여 이를 생성, 수정, 사용 또는 삭제하는 기능을 관리할 수 있습니다. CREATE STAGE 명령을 사용하여 스테이지를 생성합니다.

PUT 명령을 사용하여 로컬 파일 시스템에서 내부 스테이지 타입으로 파일을 업로드합니다.

대량 vs 연속 로드

Snowflake가 제공하는 기본 데이터 로딩 방법은 다음과 같습니다. 가장 적합한 방법은 로드할 데이터의 양과 로드 빈도에 따라 달라질 수 있습니다.

COPY 명령을 사용한 대량 로드

이 옵션을 사용하면 COPY 명령을 사용하여 데이터를 테이블에 로드하기 전에 클라우드 저장소에서 이미 사용 가능한 파일에서 데이터 배치를 로드하거나 로컬 컴퓨터에서 내부(즉, Snowflake) 클라우드 저장소 위치로 데이터 파일을 복사(즉, 스테이징)할 수 있습니다.

컴퓨팅 리소스

대량 로드에서는 COPY 문에 지정된 사용자 제공 가상 웨어하우스가 사용됩니다. 사용자는 예상되는 로드를 수용할 수 있도록 웨어하우스의 크기를 적절하게 조정해야 합니다.

로드 중 단순 변환

Snowflake는 데이터를 테이블에 로드하는 동안 COPY 명령을 사용한 데이터 변환을 지원합니다. 지원되는 옵션은 다음과 같습니다.

  • 열 재정렬

  • 열 생략

  • 캐스트

  • 대상 열 길이를 초과하는 텍스트 문자열 자르기

데이터 파일의 열 개수 및 순서는 대상 테이블과 같지 않아도 됩니다.

Snowpipe를 사용한 연속 로드

이 옵션은 소량의 데이터(즉, 마이크로 배치)를 로드하고 증분식으로 분석에 사용할 수 있도록 설계되었습니다. Snowpipe는 파일이 스테이지에 추가되고 수집용으로 제출된 후 몇 분 이내에 데이터를 로딩합니다. 이를 통해 원시 데이터를 사용할 수 있게 되는 즉시 사용자에게 최신 결과가 제공됩니다.

컴퓨팅 리소스

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

로드 중 단순 변환

파이프 정의의 COPY 문은 데이터를 대량으로 로드할 때와 동일한 COPY 변환 옵션을 지원합니다.

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

Snowpipe Streaming을 사용하여 연속 로드하기

Snowpipe Streaming API는 파일 스테이징 요구 사항 없이 Snowflake 테이블에 직접 데이터 행을 기록합니다. 이 아키텍처에서는 그 양에 관계없이 데이터를 로딩하는 데 드는 비용이 낮아지는 것과 함께, 로드 지연 시간이 짧아지므로, 거의 실시간으로 데이터 스트림을 처리하는 강력한 도구가 됩니다.

Snowpipe Streaming을 Kafka용 Snowflake 커넥터에도 사용할 수 있는데, 이 커넥터는 짧은 지연 시간 단축과 로딩 비용 절감의 이점을 활용하는 손쉬운 업그레이드 경로를 제공합니다.

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

Apache Kafka 항목에서 데이터 로드하기

Kafka용 Snowflake 커넥터 를 사용하면 사용자는 Apache Kafka 서버에 연결하고 1개 이상의 항목에서 데이터를 읽은 후 해당 데이터를 Snowflake 테이블에 로드할 수 있습니다.

DML 오류 로깅

DML 문 세트를 실행하고 문 중 하나가 오류와 함께 실패하는 경우, DML 작업이 종료되며 DML 문에 의해 변경된 사항이 롤백됩니다. 나머지 DML 문을 계속 실행하고 발생한 오류를 기록하려면 테이블에 대한 DML 오류 로깅을 켭니다. DML 오류 로깅이 켜져 있는 테이블을 *기본 테이블*이라고 합니다. 오류는 기본 테이블과 연결된 *오류 테이블*에 기록됩니다.

다음 조건이 둘 다 충족되는 경우에만 테이블에 대한 DML 오류 로깅이 켜집니다.

  • 테이블에 대해 ERROR_LOGGING 속성이 ``TRUE``로 설정되어 있습니다.

  • 현재 세션에 대해 OPT_OUT_ERROR_LOGGING 매개 변수가 ``FALSE``로 설정되어 있습니다.

다음 조건 중 *하나*가 충족되는 경우에만 테이블에 대한 DML 오류 로깅이 꺼집니다.

  • 테이블에 대해 ERROR_LOGGING 속성이 ``FALSE``로 설정되어 있습니다.

  • 현재 세션에 대해 OPT_OUT_ERROR_LOGGING 매개 변수가 ``TRUE``로 설정되어 있습니다.

다음 섹션에서는 DML 오류 로깅에 대한 자세한 정보를 제공합니다.

DML 오류 로깅의 사용 사례

DML 오류 로깅을 사용하여 다음 사용 사례에 대한 오류 실패를 방지할 수 있습니다.

  • DML 오류 로깅을 사용하는 서드 파티 데이터(예:Oracle 데이터베이스의 데이터) 마이그레이션.

  • 데이터 수집 중 NOT NULL 제약 조건과 같은 일부 테이블 제약 조건의 적용.

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

테이블을 생성하거나 변경할 때 표준 Snowflake 테이블 또는 Snowflake 관리 Iceberg 테이블에 대한 DML 오류 로깅을 켜거나 끌 수 있습니다.

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

  • CREATE TABLE

  • ALTER TABLE

  • :doc:`/sql-reference/sql/create-iceberg-table`(Snowflake 관리 키)

  • :doc:`/sql-reference/sql/alter-iceberg-table`(Snowflake 관리 키)

다음 예제에서는 테이블에 대한 DML 오류 로깅 구성 및 오류가 오류 테이블에 기록되는 방식을 보여줍니다.

다음 예제에서는 테이블에 대한 DML 오류 로깅 구성 및 오류가 오류 테이블에 기록되는 방식을 보여줍니다.

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

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

  1. 테이블을 생성하고 해당 테이블에 대한 DML 오류 로깅을 켭니다.

    CREATE TABLE test_dml_error_logging(
  n NUMBER(4, 0) NOT NULL,
  t VARCHAR(5)
  )
  ERROR_LOGGING = true;

  2. 유효한 값과 유효하지 않은 값을 모두 포함하여 여러 행을 삽입하려고 시도하는 INSERT 문을 실행합니다.

    INSERT INTO test_dml_error_logging
  VALUES
    ('invalid_cast', '1'),
    (10, 'valid'),
    (NULL, 'toolong');

    +-------------------------+
| number of rows inserted |
|-------------------------|
|                       1 |
+-------------------------+

  3. 테이블을 쿼리하여 하나의 유효한 행이 삽입되었는지 확인합니다.

    SELECT * FROM test_dml_error_logging;

    +----+-------+
|  N | T     |
|----+-------|
| 10 | valid |
+----+-------+

  4. 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"      |
|                               |                                      |            |                                                                      |   ]                |
|                               |                                      |            |                                                                      | }                  |
+-------------------------------+--------------------------------------+------------+----------------------------------------------------------------------+--------------------+

  5. test_dml_error_logging 테이블에 대한 DML 오류 로깅을 끕니다.

    ALTER TABLE test_dml_error_logging
  SET ERROR_LOGGING = false;

  6. 이전에 실행한 동일한 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);

  2. 소스 테이블과 동일한 정의로 대상 테이블을 생성합니다.

    CREATE TABLE dml_error_logging_target(col1 INT);

  3. dml_error_logging_target 테이블에 대한 DML 오류 로깅을 켭니다.

    ALTER TABLE dml_error_logging_target
  SET ERROR_LOGGING = true;

  4. 삽입 중 하나에 0으로 나누기 오류가 발생하도록 소스 테이블을 쿼리하여 대상 테이블에 값을 삽입합니다.

    INSERT INTO dml_error_logging_target(col1)
  SELECT 1/col1 FROM dml_error_logging_source;

    +-------------------------+
| number of rows inserted |
|-------------------------|
|                       2 |
+-------------------------+

  5. 테이블을 쿼리하여 두 개의 유효한 행이 삽입되었는지 확인합니다.

    SELECT * FROM dml_error_logging_target;

    +------+
| COL1 |
|------|
|    1 |
|   -1 |
+------+

  6. 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 <https://en.wikipedia.org/wiki/SQLSTATE>`_에서 모델링된 5자 코드입니다. 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                           |
| ;                                                |
+--------------------------------------------------+

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

오류 테이블의 스트림

:doc:`스트림 </user-guide/streams-intro>`은 오류 테이블에서 직접 지원되지 않습니다. 오류 테이블에서 변경 내용 추적을 활성화하려면 먼저 오류 테이블에서 뷰를 생성한 다음, 뷰에서 스트림을 생성합니다.

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

  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);

  2. CREATE STREAM 명령을 실행하여 뷰에 스트림을 생성합니다.

    CREATE STREAM my_error_stream ON VIEW my_error_view;

DML 오류 로깅 사용법 노트

다음 사용법 노트는 테이블에 대해 오류 로깅이 켜져 있을 때 적용됩니다.

  • 기본 테이블과 직접 관련된 오류만 기록됩니다.

  • 다음 유형의 오류가 기록됩니다.

    • NOT NULL 테이블 제약 조건 위반.

    • 값을 기본 테이블 열로 변환하려고 할 때 발생하는 형식 변환 오류.

    • 호환되지 않는 전체 자릿수 및 소수 자릿수 값.

    • 문자열 및 이진 유형에 대해 호환되지 않는 길이.

    • 0으로 나누기 또는 PARSE_JSON 함수 실패와 같은 일부 식 평가 실패.

  • 다중 테이블 INSERT 및 CREATE TABLE … ASSELECT(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 함수를 호출하여 파일의 열 정의를 감지하는 식을 허용합니다. 테이블이 생성된 후에는 COPY 문에서 MATCH_BY_COLUMN_NAME 옵션을 사용하여 파일을 정형 테이블에 직접 로드할 수 있습니다.

스키마 감지는 데이터 원본에서 받은 새로운 데이터의 구조를 지원하기 위해 테이블의 정형이 자동으로 진화하는 테이블 스키마 진화 와 함께 사용할 수도 있습니다.

데이터 로드의 대안

다음 옵션을 사용하여 클라우드 저장소에 있는 데이터를 Snowflake 테이블에 로딩하지 않고 쿼리할 수 있습니다.

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

:doc:`외부 테이블</user-guide/tables-external-intro>`을 사용하면 Snowflake에 먼저 로드하지 않고도 분석을 위해 외부 클라우드 저장소에 저장된 기존 데이터를 쿼리할 수 있습니다. 데이터의 정보 소스는 외부 클라우드 저장소에 유지됩니다. 구체화된 뷰를 통해 Snowflake에서 구체화된 데이터 세트는 읽기 전용입니다.

이 방법은 외부 클라우드 저장소에 많은 양의 데이터가 저장되어 있고 데이터의 일부만 쿼리(예: 가장 최근 데이터)하는 계정에 특히 유용합니다. 사용자는 이러한 데이터의 하위 세트에 대한 구체화된 뷰를 생성하여 쿼리 성능 향상할 수 있습니다.

Amazon S3 호환 저장소 사용하기

Snowflake에서 외부 스테이지와 테이블을 생성하여 Amazon S3와 호환되는 애플리케이션이나 디바이스의 저장소에 액세스할 수 있습니다. 이 기능을 사용하면 데이터 저장 위치에 관계없이 데이터를 관리, 제어, 분석할 수 있습니다. 자세한 내용은 Work with Amazon S3-compatible storage 섹션을 참조하십시오.