Preparação de seus arquivos de dados¶

Práticas recomendadas de 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.

Limites de tamanho para objetos de banco de dados¶

Quando você usa qualquer um dos métodos disponíveis para carregar dados no Snowflake, pode armazenar objetos com tamanhos até os seguintes limites:

O tamanho padrão para colunas VARCHAR é 16 MB (8 MB para binário). Para criar tabelas com tamanhos de coluna maiores que 16 MB, especifique o tamanho explicitamente. Por exemplo:

CREATE OR REPLACE TABLE my_table (
  c1 VARCHAR(134217728),
  c2 BINARY(67108864));

Para usar os novos limites das colunas VARCHAR, você pode alterar as tabelas para mudar o tamanho da coluna. Por exemplo:

ALTER TABLE my_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

Para aplicar o novo tamanho às colunas do tipo BINARY nessas tabelas, recrie as tabelas. Você não pode alterar o comprimento de uma coluna BINARY em uma tabela existente.

Para colunas do tipo ARRAY, GEOGRAPHY, GEOMETRY, OBJECT e VARIANT, você pode armazenar objetos maiores que 16 MB em tabelas existentes e novas tabelas, por padrão, sem especificar o comprimento. Por exemplo:

CREATE OR REPLACE TABLE my_table (c1 VARIANT);

Se você tiver procedimentos e funções criados no passado e que usam valores VARIANT, VARCHAR ou BINARY como entrada, talvez seja necessário recriá-los (sem tamanho especificado) para suportar objetos maiores que 16 MB. Por exemplo:

CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
  RETURNS VARCHAR
  AS $$
    'Hello' || g1
  $$;

Para tabelas Iceberg gerenciadas externamente, o tamanho padrão para as colunas VARCHAR e BINARY é 128 MB. Esse tamanho padrão se aplica a tabelas recém-criadas ou atualizadas. Se você tiver tabelas criadas no passado, limites menores poderão se aplicar a elas. Você pode atualizar essas tabelas para que suportem limites de tamanho maiores.

Nas tabelas Iceberg gerenciadas, o comprimento padrão das colunas VARCHAR e BINARY é de 128 MB. As tabelas que foram criadas antes da ativação dos novos limites de tamanho ainda têm os comprimentos padrão anteriores. Para aplicar o novo tamanho às colunas do tipo VARCHAR nessas tabelas, recrie as tabelas ou altere as colunas. O exemplo a seguir altera uma coluna para usar o novo limite de tamanho:

ALTER ICEBERG TABLE my_iceberg_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);

Para aplicar o novo tamanho às colunas do tipo BINARY nessas tabelas, recrie as tabelas. Você não pode alterar o comprimento de uma coluna BINARY em uma tabela existente.

100067 (54000): The data length in result column <column_name> is not supported by this version of the client.
Actual length <actual_size> exceeds supported length of 16777216.

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

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 obter a experiência de carga mais eficiente e econômica com o Snowpipe, recomendamos seguir as recomendações de dimensionamento de arquivos em Práticas recomendadas de dimensionamento de arquivos (neste tópico). Carregar arquivos de dados de aproximadamente 100 a 250 MB ou maiores reduz o custo adicional em relação à quantidade total de dados carregados a ponto de o custo adicional ser 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. Essa abordagem normalmente leva a um bom equilíbrio entre custo (ou seja, recursos gastos no gerenciamento de filas do Snowpipe e a carga real) e desempenho (ou seja, latência de carga).

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 subcolunarizaçã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.

Diretrizes de dados numéricos¶

• Evite caracteres incorporados, como vírgulas (por exemplo, 123,456).

• Se um número incluir um componente fracionário, ele deverá 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.