データのロードの概要

このトピックでは、Snowflakeにデータをロードするために使用できる、主なオプションの概要を説明します。

データパイプラインのインジェスションレイテンシを簡単かつ正確に測定するには、行タイムスタンプを使用します。詳細については、 行タイムスタンプを使用してパイプラインのレイテンシを測定する をご参照ください。

サポートされているファイルの場所

Snowflakeでは、クラウドストレージ内のデータファイルの場所を ステージ と呼びます。一括データロードと継続的データロードの両方に使用される COPY INTO <テーブル> コマンド（Snowpipe）は、ビジネスエンティティが管理するクラウドストレージアカウント（外部ステージ）だけでなく、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で作成されたテーブルごとに、テーブルステージを使用できます。このステージ型は、1人以上のユーザーによってステージングおよび管理されるが、単一のテーブルのみにロードされるファイルを保存するように設計されています。テーブルステージは、変更またはドロップできません。

テーブルステージは独立したデータベースオブジェクトではなく、テーブル自体に結び付けられた暗黙的なステージです。テーブルステージには、独自の付与可能な権限はありません。ファイルをテーブルステージにステージングする、ファイルを一覧表示する、ステージ上でクエリを実行する、またはドロップするには、テーブル所有者（テーブルに対する OWNERSHIP 権限を持つロール）である必要があります。

名前付き:

名前付き内部ステージは、スキーマで作成されたデータベースオブジェクトです。このステージ型は、1人以上のユーザーによってステージングおよび管理され、1つ以上のテーブルにロードされるファイルを保存できます。名前付きステージはデータベースオブジェクトであるため、それらを作成、変更、使用、またはドロップする機能は、セキュリティのアクセス制御権限を使用して制御できます。CREATE STAGE コマンドを使用してステージを作成します。

PUT コマンドを使用して、ローカルファイルシステムから任意の内部ステージ型にファイルをアップロードします。

一括ロード対連続ロード

Snowflakeは、データをロードするための以下の主要なソリューションを提供します。最適なソリューションは、ロードするデータの量とロードの頻度に依存する場合があります。

COPY コマンドを使用した一括ロード

このオプションを使用すると、クラウドストレージで既に使用可能なファイルからデータのバッチをロードしたり、ローカルマシンから内部（つまり、Snowflake）クラウドストレージの場所にデータファイルをコピー（つまり、 ステージング）したりすることが、データをテーブルにロードする前に COPY コマンドを使用してできるようになります。

コンピューティングリソース

一括ロードは、 COPY ステートメントで指定されたユーザー提供の仮想ウェアハウスに依存します。ユーザーは、予想されるロードに対応するために、ウェアハウスのサイズを適切に調整する必要があります。

ロード中の単純な変換

Snowflakeは、 COPY コマンドを使用してテーブルにデータをロードする際のデータの変換をサポートしています。オプションには次が含まれます。

  • 列の並べ替え

  • 列の省略

  • キャスト

  • ターゲット列の長さを超えるテキスト文字列の切り捨て

データファイルは、ターゲットテーブルと同数および同順序の列にする必要はありません。

Snowpipeを使用した連続ロード

このオプションは、少量のデータ（つまり、マイクロバッチ）をロードし、段階的に分析に使用できるように設計されています。Snowpipeは、ファイルがステージに追加され、インジェスションのために送信されてから数分以内にデータをロードします。これにより、生データが利用可能になり次第、ユーザーは最新の結果を得ることができます。

コンピューティングリソース

Snowpipeは、Snowflakeが提供するコンピューティングリソース（サーバーレスコンピューティングモデル）を使用します。これらのSnowflakeが提供するリソースは、必要に応じて自動的にサイズ変更および拡大/縮小され、1秒ごとの請求で課金および明細化します。データのインジェストは、実際のワークロードに基づいて課金されます。

ロード中の単純な変換

パイプ定義の COPY ステートメントは、データのバルクロード時と同じ COPY 変換オプションをサポートします。

さらに、データパイプラインはSnowpipeを活用して、データのマイクロバッチをステージングテーブルに継続的にロードし、自動タスクとストリーム内の変更データキャプチャ（CDC）情報を使用して変換と最適化を行います。

Snowpipe Streamingを使用した連続ロード

Snowpipe Streaming API は、ステージングファイルを必要とせずに、データ行をSnowflakeテーブルに直接書き込みます。このアーキテクチャにより、ロード遅延が短縮され、任意の量のデータをロードするためのコストが削減されます。これは、ほぼリアルタイムでデータストリームを処理するための強力なツールになります。

Snowpipe Streamingは、Kafka用Snowflakeコネクタでも利用できます。これにより、低遅延と低コストのロードを利用するための簡単なアップグレードパスが提供されます。

詳細については、 Snowpipe Streaming をご参照ください。

Apache Kafkaトピックからのデータのロード

The Snowflake Connector for Kafka enables users to connect to an Apache Kafka server, read data from one or more topics, and load that data into Snowflake tables.

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 エラーのログ記録を使用できます。

  • Oracleデータベースからのデータなど、DML エラーのログ記録に依存するサードパーティデータの移行。

  • データインジェスション中における、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. テーブルをクエリして、1つの有効な行が挿入されたことを確認します。

    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. 挿入の1つがゼロ除算エラーになるようにソーステーブルをクエリしてターゲットテーブルに値を挿入します。

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

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

  5. テーブルをクエリして、2つの有効な行が挿入されたことを確認します。

    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

エラーコード。1つの行の複数列にエラーが含まれる場合、この列は発生した最初のエラーのみをキャプチャします。

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 をモデルにした5文字コード。Snowflakeは、 ANSI SQL 標準にある値以外の追加の値を使用します。

1つの行の複数列にエラーが含まれる場合、この列は発生した最初のエラーのみをキャプチャします。

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 <権限> ... TO ROLE ステートメントまたは GRANT <権限> ... 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 テーブル制約の違反。

    • ベーステーブルの列からの値を変換しようとしたときに発生する型変換エラー。

    • 互換性のない精度とスケールの値。

    • 文字列型とバイナリ型の互換性のない長さ。

    • ゼロ除算や PARSE_JSON 関数の失敗などの一部の式評価の失敗。

  • マルチテーブルの INSERT および 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 EXTERNALTABLE ... USING TEMPLATE 構文を使用して、ステージングされたファイルのセットから派生した列定義でテーブルを作成します。USING TEMPLATE 句は、 INFER_SCHEMA SQL 関数を呼び出してファイル内の列定義を検出する式を受け入れます。テーブルが作成されたら、COPY ステートメントで MATCH_BY_COLUMN_NAME オプションを使用して、ファイルを構造化テーブルに直接ロードできます。

スキーマ検出は、 テーブルスキーマの進化 と組み合わせて使用することもできます。この場合テーブルの構造は、データソースから受け取った新しいデータの構造をサポートするために、自動的に進化します。

データのロードの代替

次のオプションを使用して、Snowflakeテーブルにデータをロードせずにクラウドストレージ内のデータをクエリできます。

外部テーブル（データレイク）

外部テーブル により、外部クラウドストレージに保存されている既存のデータをSnowflakeに最初にロードすることなく、分析のためにクエリできます。データの信頼できる情報源は、外部のクラウドストレージに残ります。マテリアライズドビューを介してSnowflakeでマテリアライズされたデータセットは、読み取り専用です。

このソリューションは、外部のクラウドストレージに大量のデータが保存されており、データの一部のみをクエリしたいアカウントに特に役立ちます。例：最新のデータ。ユーザーは、クエリのパフォーマンスを向上させるために、このデータのサブセットでマテリアライズドビューを作成できます。

Amazon S3互換ストレージの操作

Snowflakeで外部ステージとテーブルを作成して、Amazon S3互換のアプリケーションやデバイスのストレージにアクセスすることができます。この機能により、データの保存場所に関係なく、データを管理、ガバナンス、分析することができます。詳細については、 Work with Amazon S3-compatible storage をご参照ください。