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¶

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2025_03');

Ao usar qualquer um dos métodos disponíveis para carregar dados no Snowflake, agora é possível armazenar objetos com tamanhos maiores que 16 MB em colunas. Os limites a seguir se aplicam a tipos de dados específicos:

O tamanho padrão das colunas VARCHAR continua sendo 16 MB (8 MB para binário). Ao criar tabelas com colunas 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);

Essas alterações não afetam as cargas de trabalho Unistore. Para tabelas híbridas, todos os limites atuais permanecem inalterados.

Os procedimentos e as funções que usam os valores VARIANT, VARCHAR ou BINARY como entrada ou saída e que foram criados antes da introdução de novos limites de tamanho também devem ser recriados (sem comprimento especificado) para oferecer suporte a objetos maiores que 16 MB. Por exemplo:

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

Para tabelas Iceberg não gerenciadas, o comprimento padrão das colunas VARCHAR e BINARY é de 128 MB. Esse comprimento padrão se aplica a tabelas recém-criadas ou atualizadas. As tabelas que foram criadas antes da ativação dos novos limites de tamanho e não foram atualizadas ainda têm os comprimentos padrão anteriores.

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.

Max LOB size (16777216) exceeded

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

{
  "ID": 1,
  "CustomerDetails": {
    "RegistrationDate": 158415500,
    "FirstName": "John",
    "LastName": "Doe",
    "Events": [
      {
        "Type": "LOGIN",
        "Time": 1584158401,
        "EventID": "NZ0000000001"
      },
      /* ... */
      /* this array contains thousands of elements */
      /* with total size exceeding 16 MB */
      /* ... */
      {
        "Type": "LOGOUT",
        "Time": 1584158402,
        "EventID": "NZ0000000002"
      }
    ]
  }
}

CREATE OR REPLACE TABLE mytable AS
  SELECT
    t1.$1:ID AS id,
    t1.$1:CustomerDetails:RegistrationDate::VARCHAR AS RegistrationDate,
    t1.$1:CustomerDetails:FirstName::VARCHAR AS First_Name,
    t1.$1:CustomerDetails:LastName::VARCHAR AS as Last_Name,
    t2.value AS Event
  FROM @json t1,
    TABLE(FLATTEN(INPUT => $1:CustomerDetails:Events)) t2;

+----+-------------------+------------+------------+------------------------------+
| ID | REGISTRATION_DATE | FIRST_NAME | LAST_NAME  | EVENT                        |
|----+-------------------+------------+------------+------------------------------|
| 1  | 158415500         | John       | Doe        | {                            |
|    |                   |            |            |   "EventID": "NZ0000000001", |
|    |                   |            |            |   "Time": 1584158401,        |
|    |                   |            |            |   "Type": "LOGIN"            |
|    |                   |            |            | }                            |
|                     ... thousands of rows ...                                   |
| 1  | 158415500         | John       | Doe        | {                            |
|    |                   |            |            |   "EventID": "NZ0000000002", |
|    |                   |            |            |   "Time": 1584158402,        |
|    |                   |            |            |   "Type": "LOGOUT"           |
|    |                   |            |            | }                            |
+----+-------------------+------------+------------+------------------------------+

CREATE OR REPLACE TABLE mytable (
  id VARCHAR,
  registration_date VARCHAR(16777216),
  first_name VARCHAR(16777216),
  last_name VARCHAR(16777216),
  event VARCHAR(16777216));

INSERT INTO mytable
  SELECT
    t1.$1:ID,
    t1.$1:CustomerDetails:RegistrationDate::VARCHAR,
    t1.$1:CustomerDetails:FirstName::VARCHAR,
    t1.$1:CustomerDetails:LastName::VARCHAR,
    t2.value
  FROM @json t1,
    TABLE(FLATTEN(INPUT => $1:CustomerDetails:Events)) t2;

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmium/1.14.0">
  <node id="197798" version="17" timestamp="2021-09-06T17:01:27Z" />
  <node id="197824" version="7" timestamp="2021-08-04T23:17:18Z" >
    <tag k="highway" v="traffic_signals"/>
  </node>
  <!--  thousands of node elements with total size exceeding 16 MB -->
  <node id="197826" version="4" timestamp="2021-08-04T16:43:28Z" />
</osm>

CREATE OR REPLACE TABLE mytable AS
  SELECT
    value:"@id" AS id,
    value:"@version" AS version,
    value:"@timestamp"::datetime AS TIMESTAMP,
    value:"$" AS tags
  FROM @mystage,
    LATERAL FLATTEN(INPUT => $1:"$")
  WHERE value:"@" = 'node';

+--------+---------+-------------------------+---------------------------------------------+
| ID     | VERSION | TIMESTAMP               | TAGS                                        |
|--------+---------+-------------------------+---------------------------------------------|
| 197798 | 17      | 2021-09-06 17:01:27.000 | ""                                          |
| 197824 | 7       | 2021-08-04 23:17:18.000 | <tag k="highway" v="traffic_signals"></tag> |
|                   ... thousands of rows ...                                              |
| 197826 | 4       | 2021-08-04 16:43:28.000 | ""                                          |
+--------+---------+-------------------------+---------------------------------------------+

CREATE OR REPLACE TABLE mytable AS
  SELECT
    ST_SIMPLIFY($1:geo, 10) AS geo
  FROM @mystage;

CREATE OR REPLACE TABLE mytable (
  id VARCHAR,
  registration_date VARCHAR,
  first_name VARCHAR,
  last_name VARCHAR);

COPY INTO mytable (
  id,
  registration_date,
  first_name,
  last_name
) FROM (
    SELECT
      $1:ID,
      $1:CustomerDetails::OBJECT:RegistrationDate::VARCHAR,
      $1:CustomerDetails::OBJECT:FirstName::VARCHAR,
      $1:CustomerDetails::OBJECT:LastName::VARCHAR
    FROM @mystage
);

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 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. 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 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 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.