Preparação de seus arquivos de dados¶

Este tópico fornece as práticas recomendadas, diretrizes gerais e considerações importantes para preparar seus arquivos de dados para carregamento.

Neste tópico:

Práticas recomendadas e limitações para o dimensionamento de arquivos¶

Para um melhor desempenho do carregamento e para evitar limitações de tamanho, considere as seguintes diretrizes para o dimensionamento de arquivos de dados. Observe que essas recomendações se aplicam a carregamentos de dados em massa, bem como a carregamentos contínuos usando o Snowpipe.

Recomendações gerais de dimensionamento de arquivos¶

O número de operações de carregamento executadas em paralelo não pode exceder o número de arquivos de dados a serem carregados. Para otimizar o número de operações paralelas de um carregamento, recomendamos que o objetivo seja produzir arquivos de dados de aproximadamente 100-250 MB (ou maiores) comprimidos.

Nota

O carregamento de arquivos muito grandes (por exemplo, 100 GB ou maiores) não é recomendado.

Se você precisar carregar um arquivo grande, considere cuidadosamente o valor da opção de cópia ON_ERROR. Abortar ou ignorar um arquivo devido a um pequeno número de erros pode resultar em atrasos e desperdício de créditos. Além disso, se uma operação de carregamento de dados continuar além da duração máxima permitida de 24 horas, ela poderá ser cancelada sem que nenhuma parte do arquivo seja comprometida.

Agregue arquivos menores para minimizar sobretaxas de processamento para cada arquivo. Divida arquivos maiores em um maior número de arquivos menores para distribuir a carga entre os recursos computacionais em um warehouse ativo. O número de arquivos de dados que são processados em paralelo é determinado pela quantidade de recursos computacionais em um warehouse. Recomendamos dividir arquivos grandes por linha para evitar registros que se estendam por partes.

Se seu banco de dados de origem não permitir a exportação de arquivos de dados em partes menores, você pode usar um utilitário de terceiros para dividir arquivos CSV grandes.

Linux ou macOS¶

O utilitário split permite dividir um arquivo CSV em vários arquivos menores.

Sintaxe:

split [-a suffix_length] [-b byte_count[k|m]] [-l line_count] [-p pattern] [file [name]]

Copy

Para obter mais informações, digite man split em uma janela de terminal.

Exemplo:

split -l 100000 pagecounts-20151201.csv pages

Copy

Este exemplo divide um arquivo chamado pagecounts-20151201.csv pelo comprimento da linha. Suponha que o arquivo único grande tenha 8 GB e contenha 10 milhões de linhas. Divididos por 100.000, cada um dos 100 arquivos menores tem 80 MB (10 milhões / 100.000 = 100). Os arquivos divididos são denominados pages<sufixo>.

Windows¶

O Windows não inclui um utilitário de divisão de arquivos nativo; entretanto, o Windows oferece suporte a muitas ferramentas e scripts de terceiros que podem dividir arquivos de dados grandes.

Limitações de tamanho de dados semiestruturados¶

Um VARIANT pode ter um tamanho máximo de até 16 MB de dados não comprimidos. Entretanto, na prática, o tamanho máximo geralmente é menor devido à sobrecarga interna. O tamanho máximo também depende do objeto que está sendo armazenado.

Para obter mais informações, consulte VARIANT.

Em geral, conjuntos de dados JSON são uma simples concatenação de vários documentos. A saída JSON de um software é composta de uma única grande matriz contendo vários registros. Não há necessidade de separar os documentos com quebras de linha ou vírgulas, embora ambas as formas sejam suportadas.

Se os dados excederem 16 MB, ative a opção de formato de arquivo STRIP_OUTER_ARRAY do comando COPY INTO <tabela> para remover a estrutura da matriz externa e carregar os registros em linhas de tabela separadas:

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

Copy

Carregamentos contínuos de dados (ou seja, Snowpipe) e dimensionamento de arquivos¶

O Snowpipe é projetado para carregar novos dados normalmente dentro de um minuto após o envio de uma notificação de arquivo; no entanto, o carregamento pode levar muito mais tempo para arquivos realmente grandes ou em casos onde uma quantidade incomum de recursos computacionais é necessária para descompactar, decodificar e transformar os novos dados.

Além do consumo de recursos, uma sobretaxa para gerenciar arquivos na fila de carga interna está incluída nos custos de utilização cobrados pelo Snowpipe. Essa sobretaxa aumenta em relação ao número de arquivos enfileirados para carregamento. Esta cobrança de sobretaxa aparece como cobranças do Snowpipe em sua fatura porque o Snowpipe é usado para notificações de eventos para a atualização automática da tabela externa.

Para uma experiência de carregamento mais eficiente e econômica com o Snowpipe, recomendamos seguir as recomendações de dimensionamento de arquivos em Práticas recomendadas e limitações para o dimensionamento de arquivos (neste tópico). O carregamento de arquivos de dados com tamanho aproximado de 100-250 MB ou maiores reduz a sobretaxa relativa à quantidade total de dados carregados até o ponto em que o custo de sobretaxa é irrelevante.

Se demorar mais de um minuto para acumular MBs de dados em seus aplicativo de origem, considere a criação de um novo arquivo de dados (potencialmente menor) uma vez por minuto. Esta abordagem normalmente leva a um bom equilíbrio entre o custo (ou seja, recursos gastos no gerenciamento da fila do Snowpipe e o carregamento real) e o desempenho (ou seja, a latência do carregamento).

A criação e preparação de arquivos de dados menores no armazenamento em nuvem com mais frequência do que uma vez por minuto tem as seguintes desvantagens:

Não é possível garantir uma redução na latência entre a preparação e o carregamento dos dados.
Uma sobretaxa para gerenciar arquivos na fila de carga interna está incluída nos custos de utilização cobrados pelo Snowpipe. Essa sobretaxa aumenta em relação ao número de arquivos enfileirados para carregamento.

Várias ferramentas podem agregar e agrupar arquivos de dados em lote. Uma opção conveniente é o Amazon Data Firehose. O Firehose permite definir tanto o tamanho do arquivo desejado, chamado de tamanho de buffer, quanto o intervalo de espera após o qual um novo arquivo é enviado (para armazenamento em nuvem neste caso), chamado de intervalo de buffer. Para obter mais informações, consulte a documentação do Amazon Data Firehose. Se seu aplicativo de origem normalmente acumula dados suficientes em um minuto para preencher arquivos maiores do que o máximo recomendado para um processamento paralelo ideal, você pode diminuir o tamanho do buffer para acionar a entrega de arquivos menores. Manter o ajuste do intervalo de buffer em 60 segundos (o valor mínimo) ajuda a evitar a criação de muitos arquivos ou o aumento da latência.

Preparação de arquivos de texto delimitados¶

Considere as seguintes diretrizes ao preparar seus arquivos de texto delimitados (CSV) para carregamento:

UTF-8 é o conjunto de caracteres padrão, porém codificações adicionais são suportadas. Use a opção de formato de arquivo ENCODING para especificar o conjunto de caracteres para os arquivos de dados. Para obter mais informações, consulte CREATE FILE FORMAT.
Os campos que contêm caracteres delimitadores devem ser delimitados entre aspas (simples ou duplas). Se os dados contiverem aspas simples ou duplas, então essas aspas devem ser evitadas.
Os retornos de carro são comumente introduzidos em sistemas Windows em conjunto com um caractere de alimentação de linha para marcar o final de uma linha (\r \n). Os campos que contêm retornos de carro também devem ser colocados entre aspas (simples ou duplas).
O número de colunas em cada linha deve ser consistente.

Arquivos de dados semiestruturados e colunarização¶

Quando dados semiestruturados são inseridos em uma coluna VARIANT, o Snowflake usa determinadas regras para extrair o máximo possível dos dados para uma forma de coluna. O restante dos dados é armazenado como uma única coluna em uma estrutura semiestruturada analisada.

Por padrão, o Snowflake extrai no máximo 200 elementos por partição, por tabela. Para aumentar este limite, entre em contato com o suporte Snowflake.

Elementos que não são extraídos¶

Elementos com as seguintes características não são extraídos em uma coluna:

Os elementos que contêm até mesmo um único valor “nulo” não são extraídos em uma coluna. Isso se aplica a elementos com valores “nulos” e não a elementos com valores ausentes, que são representados em forma de coluna.

Esta regra garante que nenhuma informação seja perdida (ou seja, que a diferença entre valores de VARIANT “nulos” e valores SQL NULL não seja perdida).
Elementos que contêm múltiplos tipos de dados. Por exemplo:

O elemento foo em uma linha contém um número:
```
{"foo":1}
```
Copy
O mesmo elemento em outra linha contém uma cadeia de caracteres:
```
{"foo":"1"}
```
Copy

Como a extração afeta as consultas¶

Quando você consulta um elemento semiestruturado, o mecanismo de execução do Snowflake se comporta de maneira diferente se um elemento tiver sido extraído.

Se o elemento tiver sido extraído em uma coluna, o mecanismo verificará apenas a coluna extraída.
Se o elemento não tiver sido extraído em uma coluna, o mecanismo deve examinar toda a estrutura JSON e então, para cada linha, percorrer a estrutura para emitir valores. Isso afeta o desempenho.

Para evitar o impacto no desempenho de elementos que não foram extraídos, faça o seguinte:

Extraia elementos de dados semiestruturados contendo valores “nulos” em colunas relacionais antes de carregá-los.

Como alternativa, se os valores “nulos” em seus arquivos indicarem valores ausentes e não tiverem nenhum outro significado especial, recomendamos definir a opção de formato do arquivo STRIP_NULL_VALUES como TRUE ao carregar os arquivos de dados semiestruturados. Essa opção remove elementos OBJECT ou ARRAY contendo valores “nulos”.
Certifique-se de que cada elemento único armazene valores de um único tipo de dados nativo no formato em questão (por exemplo, cadeia de caracteres ou número em JSON).

Diretrizes de dados numéricos¶

Evite caracteres embutidos, como vírgulas (por exemplo, 123,456).
Se um número inclui um componente fracionário, ele deve ser separado da parte do número inteiro por um ponto decimal (por exemplo, 123456.789).
Somente Oracle. Os tipos Oracle NUMBER ou NUMERIC permitem escala arbitrária, ou seja, aceitam valores com componentes decimais, mesmo que o tipo de dados não tenha sido definido com precisão ou escala. Enquanto no Snowflake, as colunas projetadas para valores com componentes decimais devem ser definidas com uma escala para preservar a porção decimal.

Diretrizes de dados de data e de carimbo de data/hora¶

Para obter mais informações sobre os formatos compatíveis para dados de data, hora e carimbo de data/hora, consulte Formatos de entrada e saída de data e hora.
Somente Oracle. O tipo de dados Oracle DATE pode conter informações de data ou de carimbo de data/hora. Se seu banco de dados Oracle incluir colunas DATE que também armazenam informações relacionadas ao tempo, mapeie essas colunas para um tipo de dados TIMESTAMP em vez de DATE no Snowflake.

Nota

O Snowflake verifica os valores dos dados temporais no momento do carregamento. Valores inválidos de data, hora e carimbo de data/hora (por exemplo, 0000-00-00) produzem um erro.