Visão geral do carregamento de dados¶

Este tópico fornece uma visão geral das principais opções disponíveis para carregar dados no Snowflake.

Para medir com facilidade e precisão a latência de ingestão dos seus pipelines de dados, use carimbos de data/hora de linha. Para obter mais informações, consulte Usar carimbos de data/hora de linha para medir a latência em seus pipelines.

Locais de arquivos suportados¶

Snowflake refere-se ao local dos arquivos de dados no armazenamento em nuvem como um estágio. O comando COPY INTO <tabela> usado para cargas de dados em massa e contínuas (Snowpipe) oferece suporte a contas de armazenamento em nuvem gerenciadas por sua entidade comercial (estágios externos), bem como ao armazenamento em nuvem contido em sua conta Snowflake (estágios internos).

Estágios externos¶

O carregamento de dados de qualquer um dos seguintes serviços de armazenamento em nuvem é suportado independentemente da plataforma de nuvem que hospeda sua conta Snowflake:

Amazon S3
Google Cloud Storage
Microsoft Azure

Não é possível acessar dados mantidos em classes de armazenamento em nuvem que exigem restauração antes que possam ser recuperados. Estas classes de armazenamento de arquivos incluem, por exemplo, a Amazon S3 Glacier Flexible Retrieval ou Glacier Deep Archive, o ainda o Microsoft Azure Archive Storage.

Faça o upload (ou seja, preparo) de arquivos para sua conta de armazenamento em nuvem usando as ferramentas fornecidas pelo serviço de armazenamento em nuvem.

Um estágio externo nomeado é um objeto de banco de dados criado em um esquema. Esse objeto armazena o URL para arquivos no armazenamento em nuvem, as configurações usadas para acessar a conta de armazenamento em nuvem e as configurações de conveniência, tais como as opções que descrevem o formato dos arquivos preparados. Crie estágios usando o comando CREATE STAGE.

Nota

Algumas cobranças por transferência de dados podem ser aplicadas ao carregar dados de arquivos em um serviço de armazenamento em nuvem em uma região ou plataforma de nuvem diferente de sua conta Snowflake. Para obter mais informações, consulte Explicação do custo de transferência de dados.

Estágios internos¶

O Snowflake mantém os seguintes tipos de estágios em sua conta:

Usuário:

Um estágio do usuário é alocado a cada usuário para o armazenamento de arquivos. Este tipo de estágio é projetado para armazenar arquivos que são preparados e gerenciados por um único usuário, mas que podem ser carregados em várias tabelas. Os estágios do usuário não podem ser alterados ou descartados.

Tabela:

Para cada tabela criada no Snowflake está disponível um estágio de tabela. Este tipo de estágio é projetado para armazenar arquivos que são preparados e gerenciados por um ou mais usuários, mas apenas carregados em uma única tabela. Os estágios da tabela não podem ser alterados ou descartados.

Note que um estágio da tabela não é um objeto separado do banco de dados; ao contrário, ele é um estágio implícito ligado à própria tabela. Um estágio da tabela não tem privilégios próprios. Para o preparo de arquivos em um estágio de tabela, listar os arquivos, consultá-los no estágio ou descartá-los, você deve ser o proprietário da tabela (ter a função com o privilégio OWNERSHIP sobre a tabela).

Nomeado:

Um estágio interno nomeado é um objeto de banco de dados criado em um esquema. Este tipo de estágio pode armazenar arquivos que são preparados e gerenciados por um ou mais usuários e carregados em uma ou mais tabelas. Como os estágios nomeados são objetos de banco de dados, a capacidade de criá-los, modificá-los, usá-los ou descartá-los pode ser controlada por meio de privilégios de controle de acesso de segurança. Crie estágios usando o comando CREATE STAGE.

Faça o upload de arquivos para qualquer um dos tipos de estágio interno a partir de seu sistema local de arquivos usando o comando PUT.

Carregamento em massa vs. carregamento contínuo¶

O Snowflake fornece as seguintes soluções principais para o carregamento de dados. A melhor solução pode depender do volume de dados a serem carregados e da frequência do carregamento.

Carregamento em massa usando o comando COPY¶

Esta opção permite carregar lotes de dados de arquivos já disponíveis no armazenamento em nuvem ou copiar (ou seja, preparação) arquivos de dados de uma máquina local para um local de armazenamento em nuvem interno (ou seja, o Snowflake) antes de carregar os dados em tabelas usando o comando COPY.

Recursos de computação¶

O carregamento em massa depende de warehouses virtuais fornecidos pelo usuário, que são especificados na instrução COPY. Os usuários são obrigados a dimensionar o warehouse adequadamente para acomodar os carregamentos previstos.

Transformações simples durante um carregamento¶

O Snowflake oferece suporte à transformação de dados ao carregá-los em uma tabela usando o comando COPY. As opções incluem:

Reordenação de colunas
Omissão de coluna
Conversões
Truncamento de cadeias de caracteres de texto que excedam o comprimento da coluna de destino

Não há exigência de que seus arquivos de dados tenham o mesmo número e ordenação de colunas que sua tabela de destino.

Carregamento contínuo usando o Snowpipe¶

Esta opção é projetada para carregar pequenos volumes de dados (ou seja, microlotes) e disponibilizá-los incrementalmente para análise. O Snowpipe carrega os dados em minutos após os arquivos serem adicionados a um estágio e enviados para ingestão. Isso garante que os usuários tenham os resultados mais recentes, assim que os dados brutos estiverem disponíveis.

Recursos de computação¶

O Snowpipe utiliza recursos computacionais fornecidos pelo Snowflake (ou seja, um modelo computacional sem servidor). Esses recursos fornecidos pelo Snowflake são automaticamente redimensionados e escalonados para cima ou para baixo, conforme necessário, e são cobrados e discriminados usando o faturamento por segundo. A ingestão de dados é cobrada com base nas cargas de trabalho reais.

Transformações simples durante um carregamento¶

A instrução COPY em uma definição de canal é compatível com as mesmas opções de transformação COPY que durante o carregamento de dados em massa.

Além disso, os pipelines de dados podem aproveitar o Snowpipe para carregar continuamente microlotes de dados em tabelas de estágio, para transformação e otimização usando tarefas automatizadas, e as informações de captura de dados de alteração (CDC) em fluxos.

Carregamento contínuo usando o Snowpipe Streaming¶

O API Snowpipe Streaming escreve linhas de dados diretamente nas tabelas Snowflake sem a exigência de arquivos de preparação. Esta arquitetura resulta em latências de carga mais baixas, com custos correspondentes mais baixos para carregar qualquer volume de dados, o que a torna uma ferramenta poderosa para lidar com fluxos de dados quase em tempo real.

O Snowpipe Streaming também está disponível para o conector Snowflake para Kafka, que oferece um caminho fácil de atualização para aproveitar a menor latência e as cargas de menor custo.

Para obter mais informações, consulte Snowpipe Streaming.

Carregamento de dados de tópicos do Apache Kafka¶

O Conector Snowflake para Kafka permite que os usuários se conectem a um servidor Apache Kafka, leiam dados de um ou mais tópicos e carreguem esses dados nas tabelas do Snowflake.

Registro de erros de DML¶

Quando você executa um conjunto de instruções DML e uma das instruções falha com um erro, a operação DML é encerrada, e as alterações feitas pela instrução DML são revertidas. Se você quiser continuar a executar o restante das instruções DML e registrar o erro ocorrido, pode ativar o registro de erros de DML na tabela. A tabela em que o registro de erros de DML está ativado é chamada de tabela base. Os erros são registrados em uma tabela de erros associada à tabela base.

O registro de erros de DML é ativado em uma tabela somente quando as duas condições abaixo são atendidas:

A propriedade ERROR_LOGGING está definida como TRUE na tabela.
O parâmetro OPT_OUT_ERROR_LOGGING está definido como FALSE na sessão atual.

O registro de erros de DML é desativado em uma tabela somente quando qualquer uma das condições abaixo é atendida:

A propriedade ERROR_LOGGING está definida como FALSE na tabela.
O parâmetro OPT_OUT_ERROR_LOGGING está definido como TRUE na sessão atual.

As seguintes seções apresentam mais informações sobre o registro de erros de DML:

Casos de uso para registro de erros de DML¶

Você pode usar o registro de erros de DML para evitar falhas em caso de erros nos seguintes casos de uso:

Migração de dados de terceiros que depende do registro de erros de DML, como dados de um banco de dados Oracle.
Aplicação de algumas restrições de tabela, como NOT NULL, durante a ingestão de dados.

Configurar o registro de erros de DML em uma tabela¶

Você pode ativar ou desativar o registro de erros de DML em uma tabela padrão do Snowflake ou uma tabela Iceberg gerenciada pelo Snowflake quando cria ou altera a tabela.

Para ativar ou desativar o registro de erros em uma tabela, use os seguintes comandos SQL para definir a propriedade ERROR_LOGGING na tabela:

CREATE TABLE
ALTER TABLE
CREATE ICEBERG TABLE (somente gerenciada pelo Snowflake)
ALTER ICEBERG TABLE (somente gerenciada pelo Snowflake)

Os exemplos a seguir configuram o registro de erros de DML nas tabelas e mostra como os erros são registrados em tabelas de erros:

Registrar erros ao inserir linhas diretamente
Registrar erros ao inserir linhas de uma tabela em outra

Os exemplos a seguir configuram o registro de erros de DML nas tabelas e mostra como os erros são registrados em tabelas de erros:

Registrar erros ao inserir linhas diretamente¶

O seguinte exemplo registra os erros ao inserir as linhas diretamente em uma tabela:

Crie uma tabela e ative o registro de erros de DML nela:

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

Execute uma instrução INSERT que tenta inserir várias linhas, incluindo valores válidos e inválidos:

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

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

Consulte a tabela para confirmar que uma linha válida foi inserida:
```
SELECT * FROM test_dml_error_logging;
```
```
+----+-------+
|  N | T     |
|----+-------|
| 10 | valid |
+----+-------+
```

Consulte a tabela de erros da tabela base test_dml_error_logging para ver os erros que foram registrados:

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

Desative o registro de erros de DML da tabela test_dml_error_logging:
```
ALTER TABLE test_dml_error_logging
  SET ERROR_LOGGING = false;
```

Tente a mesma instrução INSERT que você já executou. Um erro é retornado e nenhum erro é registrado em uma tabela de erros:

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

Registrar erros ao inserir linhas de uma tabela em outra¶

O seguinte exemplo registra erros ao inserir linhas de uma tabela em outra:

Crie uma tabela de origem e insira os valores:

CREATE TABLE dml_error_logging_source(col1 INT);

INSERT INTO dml_error_logging_source VALUES (1), (0), (-1);

Crie uma tabela de destino com a mesma definição da tabela de origem:
```
CREATE TABLE dml_error_logging_target(col1 INT);
```
Ative o registro de erros de DML na tabela dml_error_logging_target:
```
ALTER TABLE dml_error_logging_target
  SET ERROR_LOGGING = true;
```

Insira os valores na tabela de destino consultando a tabela de origem para que uma das inserções resulte em um erro de divisão por zero:

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

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

Consulte a tabela para confirmar que duas linhas válidas foram inseridas:
```
SELECT * FROM dml_error_logging_target;
```
```
+------+
| COL1 |
|------|
|    1 |
|   -1 |
+------+
```

Consulte a tabela de erros da tabela base dml_error_logging_target para ver os erros que foram registrados:

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

Registro e tabelas de erros¶

Quando o registro de erros é ativado em uma tabela, o Snowflake cria automaticamente uma tabela de erros associada à tabela base. As operações DML que encontram erros compatíveis os registram na tabela de erros em vez de falhar.

Quando o registro de erros de DML está ativado em uma tabela, os seguintes tipos de instruções DML são registrados:

INSERT de tabela única
UPDATE
MERGE

As tabelas de erros têm uma definição fixa e só podem ser acessadas pelo proprietário da tabela base ou por um usuário com uma função que tenha recebido o privilégio SELECT ERROR TABLE na tabela base. As únicas operações diretas compatíveis com uma tabela de erros são as instruções SELECT e TRUNCATE. Não é possível executar outros tipos de instruções diretamente em tabelas de erros. As tabelas de erros não podem ser usadas indiretamente em exibições materializadas ou tabelas dinâmicas.

Você pode copiar os dados da tabela de erros para outras tabelas. Você pode remover os dados de uma tabela de erros executando o comando TRUNCATE.

As seguintes seções apresentam mais informações sobre registro e tabelas de erros:

Definição das tabelas de erros¶

O Snowflake cria tabelas de erros com uma definição padrão que não pode ser modificada.

Quando você desativa o registro de erros de DML de uma tabela base ou descarta uma tabela base que tem uma tabela de erros, a tabela de erros associada à tabela base é descartada automaticamente.

Uma tabela de erros tem as seguintes colunas:


Nome	Tipo	Descrição
`timestamp`	TIMESTAMP	O carimbo de data/hora da instrução que acionou o erro.
`query_id`	VARCHAR	O ID exclusivo da instrução que acionou o erro.
`error_code`	NUMBER	O código de erro. Quando várias colunas em uma linha contêm erros, esta coluna captura apenas o primeiro erro encontrado.
`error_metadata`	OBJECT	Os metadados do erro. Os valores OBJECT têm a seguinte estrutura: { "error_code": <value>, "error_message": "<value>", "error_source": "<value>", "sql_state": "<value>" } Os valores OBJECT contêm os seguintes pares chave-valor: `error_code`: O código de erro. `error_message`: a mensagem de erro. `error_source`: a origem do erro, como um nome de coluna. `sql_state`: um código de cinco caracteres que usa como modelo o padrão SQL ANSI `SQLSTATE<https://en.wikipedia.org/wiki/SQLSTATE>`_. O Snowflake usa valores adicionais além daqueles do padrão ANSI SQL. Quando várias colunas em uma linha contêm erros, esta coluna captura apenas o primeiro erro encontrado.
`error_data`	OBJECT	Os dados que causaram o erro. Os valores OBJECT têm a seguinte estrutura: { "<column_name>": [ <invalid_column_values> ] "<column_name>": <valid_column_values> ... } Os valores OBJECT contêm os pares chave-valor que representam cada coluna na tabela base. A chave é o nome da coluna. Para os valores de coluna inválidos que causaram a falha na operação DML, o valor no par chave-valor é uma matriz que contém os valores. Os valores válidos são mostrados diretamente; ou seja, não são mostrados em matrizes. Se os dados não puderem ser representados em um valor OBJECT, o valor será NULL.

Interagir com tabelas de erros¶

Você pode executar instruções SELECT e TRUNCATE em tabelas de erros usando a seguinte sintaxe:

SELECT ... FROM ERROR_TABLE( <base_table_name> )

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

Onde:

base_table_name: O nome da tabela para a qual a tabela de erros foi criada.

Por exemplo, se o nome da tabela base é my_table, a seguinte instrução consulta a tabela de erros desta tabela base:

SELECT * FROM ERROR_TABLE(my_table);

A seguinte instrução trunca a tabela de erros:

TRUNCATE ERROR_TABLE(my_table);

Requisitos de controle de acesso para tabelas de erros¶

Qualquer função que possa inserir em uma tabela base pode acionar inserções na respectiva tabela de erros. Independentemente da função atual, inserções diretas em uma tabela de erros não são permitidas.

Os seguintes usuários podem executar instruções SELECT em uma tabela de erros:

O proprietário da tabela base da tabela de erros.
Os usuários que receberam o privilégio SELECT ERROR TABLE na tabela base, seja por meio de uma função ou diretamente.

Para conceder o privilégio SELECT ERROR TABLE em uma tabela base, execute a instrução GRANT <privilégios> … TO ROLE ou GRANT <privilégios> … TO USER.

Essas instruções usam a seguinte sintaxe:
```
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>
```
Por exemplo, para conceder o privilégio SELECT ERROR TABLE em uma tabela base chamada mybasetable a uma função chamada myrole, execute a seguinte instrução:
```
GRANT SELECT ERROR TABLE ON TABLE mybasetable TO ROLE myrole;
```

Alternativamente, para conceder a outras funções acesso a uma tabela de erros, o proprietário da tabela base também pode criar uma exibição baseada na tabela de erros e conceder acesso a essa exibição.

Metadados para registro de erros¶

Para determinar se o registro de erros está ativado em uma tabela, você pode executar a função GET_DDL e passar o nome da tabela base:

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

Por exemplo, para uma tabela base chamada test_dml_error_logging no esquema atual, execute a seguinte instrução:

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

As métricas das tabelas de erros são registradas nas seguintes exibições:

Fluxos em tabelas de erros¶

Fluxos não são diretamente compatíveis com tabelas de erros. Para habilitar o rastreamento de alterações em tabelas de erros, primeiro crie uma exibição na tabela de erros e, em seguida, crie um fluxo na exibição.

O seguinte exemplo mostra como habilitar o rastreamento de alterações em tabelas de erros:

Execute o comando CREATE VIEW para criar uma exibição na tabela de erros:

CREATE VIEW my_error_view AS
  SELECT timestamp,
         query_id,
         error_code,
         error_metadata,
         error_data
    FROM ERROR_TABLE(test_dml_error_logging);

Execute o comando CREATE STREAM para criar um fluxo na exibição:
```
CREATE STREAM my_error_stream ON VIEW my_error_view;
```

Notas de uso do registro de erros de DML¶

As seguintes notas de uso se aplicam quando o registro de erros está ativado em uma tabela:

Somente os erros diretamente relacionados à tabela base são registrados.
Os seguintes tipos de erros são registrados:
- Violações de restrição de tabela NOT NULL.
- Erros de conversão de tipo que ocorrem ao tentar converter um valor de ou na coluna da tabela base.
- Valores de precisão e escala incompatíveis.
- Comprimento incompatível com tipos de cadeia de caracteres e binários.
- Algumas falhas na avaliação de expressão, como divisão por zero ou falhas na função PARSE_JSON.
As instruções INSERT e CREATE TABLE … AS SELECT (CTAS) de várias tabelas são executadas normalmente. Elas falham em caso de erros de DML e não os registra.
Se você tentar executar uma instrução COPY INTO em uma tabela com o registro de erros habilitado, o erro Error logging is not supported in statement 'COPY INTO' será retornado no momento da compilação.
Erros que não são compatíveis com o registro de erros de DML provocam uma falha diretamente na operação DML.
Se uma instrução SQL resultar em um erro de compilação, a operação será encerrada, e nenhum erro será registrado na tabela de erros.
Falhas que ocorrem em outros caminhos de ingestão, como COPY e Snowpipe, não são registradas em tabelas de erros. Para registro de erros de alto desempenho do Snowpipe Streaming, consulte Registro de erros no Snowpipe Streaming com arquitetura de alto desempenho.
Veja a seguir considerações relacionadas ao registro de erros e ao desempenho de DML:
- Quando o registro de erros de DML está habilitado em uma tabela base, e não há erros em uma instrução DML executada na tabela base, nenhuma ou muito pouca diferença de desempenho é esperada.
- Quando o registro de erros de DML está habilitado em uma tabela base e há erros em uma instrução DML executada na tabela base, é necessário um tempo adicional para concluir a instrução DML porque as informações do erro são inseridas na tabela de erros.
Quando uma tabela base com uma tabela de erros associada é clonada, o comportamento é o seguinte:
- O esquema e o conteúdo da tabela base são clonados.
- O conteúdo da tabela de erros não é clonado.
- A tabela base clonada tem a propriedade ERROR_LOGGING ativada, o que implicitamente cria uma tabela de erros vazia para ela.

Detecção de esquema de definições de coluna a partir de arquivos de dados semiestruturados preparados¶

Os dados semiestruturados podem incluir milhares de colunas. O Snowflake fornece soluções robustas para o tratamento desses dados. As opções incluem fazer referência aos dados diretamente no armazenamento em nuvem usando tabelas externas, carregar os dados em uma única coluna do tipo VARIANT ou transformar e carregar os dados em colunas separadas em uma tabela relacional padrão. Todas essas opções exigem algum conhecimento das definições das colunas nos dados.

Uma solução diferente envolve a detecção automática do esquema em um conjunto de arquivos de dados semiestruturados preparados e a recuperação das definições das colunas. As definições das colunas incluem os nomes, tipos de dados e ordenação das colunas nos arquivos. Gere sintaxe em um formato adequado para criar tabelas, tabelas externas ou exibições padrão do Snowflake.

Nota

Este recurso oferece suporte aos arquivos Apache Parquet, Apache Avro, ORC, JSON e CSV.

Esse suporte é implementado por meio das seguintes funções SQL:

INFER_SCHEMA: Detecta as definições de coluna em um conjunto de arquivos de dados preparados e recupera os metadados em um formato adequado para a criação de objetos Snowflake.
GENERATE_COLUMN_DESCRIPTION: Gera uma lista de colunas a partir de um conjunto de arquivos preparados usando a saída da função INFER_SCHEMA.

Estas funções SQL oferecem suporte tanto aos estágios internos quanto aos externos.

Crie tabelas ou tabelas externas com as definições das colunas derivadas de um conjunto de arquivos preparados usando a sintaxe CREATE TABLE … USING TEMPLATE ou CREATE EXTERNAL TABLE … USING TEMPLATE A cláusula USING TEMPLATE aceita uma expressão que chama a função INFER_SCHEMA SQL para detectar as definições de coluna nos arquivos. Ao concluir a criação da tabela, você poderá então usar uma instrução COPY com a opção MATCH_BY_COLUMN_NAME para carregar os arquivos diretamente na tabela estruturada.

A detecção de esquema também pode ser usada em conjunto com a evolução do esquema de tabela, onde a estrutura das tabelas evolui automaticamente para oferecer suporte à estrutura de novos dados recebidos das fontes de dados.

Alternativas ao carregamento de dados¶

Você pode usar a seguinte opção para consultar seus dados no armazenamento em nuvem sem carregá-los nas tabelas do Snowflake.

Tabelas externas (data lake)¶

As tabelas externas permitem consultar os dados existentes armazenados no armazenamento externo em nuvem para análise sem primeiro carregá-los no Snowflake. A fonte confiável para os dados permanece no armazenamento externo em nuvem. Os conjuntos de dados materializados no Snowflake por meio de exibições materializadas são somente leitura.

Esta solução é especialmente benéfica para contas que têm uma grande quantidade de dados armazenados em armazenamento externo em nuvem e só querem consultar uma parte dos dados, por exemplo, os dados mais recentes. Os usuários podem criar exibições materializadas sobre subconjuntos destes dados para melhorar o desempenho das consultas.

Como trabalhar com armazenamento compatível com Amazon S3¶

Você pode criar estágios e tabelas externas no Snowflake para acessar o armazenamento em um aplicativo ou dispositivo compatível com o Amazon S3. Esse recurso permite que você gerencie, controle e analise seus dados, independentemente de onde dados estejam armazenados. Para obter mais informações, consulte Work with Amazon S3-compatible storage.