Trabalhar com dados de timestamp

Esta seção descreve algumas considerações para trabalhar com dados de timestamp no Athena.

Formato para gravar dados de timestamp em objetos do Amazon S3

O formato no qual os dados de timestamp devem ser gravados em objetos do Amazon S3 depende do tipo de dados da coluna e da biblioteca SerDe utilizada.

Garantir que os dados particionados por tempo correspondam ao campo de timestamp em um registro

O produtor dos dados deve garantir que os valores da partição estejam alinhados com os dados na partição. Por exemplo, se os dados tiverem uma propriedade timestamp e você usar o Firehose para carregá-los no Amazon S3, será necessário usar o particionamento dinâmico porque o particionamento padrão do Firehose é baseado em hora real do relógio.

Usar string como o tipo de dados para chaves de partição

Por motivos de performance, é preferível usar STRING como tipo de dados para chaves de partição. Embora o Athena reconheça valores de partição no formato YYYY-MM-DD como datas quando você usa o tipo DATE, isso pode levar a uma performance ruim. Por isso, recomenda-se usar o tipo de dados STRING para chaves de partição.

Como gravar consultas em campos de timestamp que também são particionados por tempo

A forma como você grava consultas em campos de timestamp que são particionados por hora depende do tipo de tabela que você deseja consultar.

Tabelas Hive

Com as tabelas Hive mais usadas no Athena, o mecanismo de consulta não tem conhecimento das relações entre as colunas e as chaves de partição. Por isso, você sempre deve adicionar predicados às consultas tanto para a coluna como para a chave de partição.

Por exemplo, suponha que você tenha uma coluna event_time e uma chave de partição event_date e queira consultar eventos entre 23:00 e 03:00. Nesse caso, é necessário incluir predicados em sua consulta para a coluna e a chave de partição, como no exemplo a seguir.

WHERE event_time BETWEEN start_time AND end_time 
  AND event_date BETWEEN start_time_date AND end_time_date

Tabelas Iceberg

Com as tabelas Iceberg, é possível usar valores de partição computados, o que simplifica suas consultas. Por exemplo, suponha que sua tabela do Iceberg tenha sido criada com uma cláusula PARTITIONED BY como esta:

PARTITIONED BY (event_date month(event_time))

Nesse caso, o mecanismo de consulta remove automaticamente as partições com base nos valores dos predicados event_time. Por isso, sua consulta só precisa especificar um predicado para event_time, como no exemplo a seguir.

WHERE event_time BETWEEN start_time AND end_time

Para ter mais informações, consulte Criar tabelas do Iceberg.

Ao usar o particionamento oculto do Iceberg para uma coluna de timestamp, o Iceberg pode criar uma partição em uma coluna de tabela construída derivada de uma coluna de timestamp e transformada em uma data para proporcionar um particionamento mais eficaz. Por exemplo, ele pode criar event_date a partir da coluna de timestamp event_time e particionar automaticamente em event_date. Nesse caso, o tipo da partição é uma data.

Para usufruir da performance ideal da consulta ao usar a partição, filtre por intervalos de dias inteiros para habilitar o pushdown de predicados. Por exemplo, a consulta a seguir não seria submetida a pushdown porque o intervalo não pode ser convertido em uma única partição de data, mesmo que esteja dentro de um único dia:

WHERE event_time >= TIMESTAMP '2024-04-18 00:00:00' AND event_time < TIMESTAMP '2024-04-18 12:00:00'

Em vez disso, use um intervalo de dias inteiros para permitir o pushdown de predicados e melhorar a performance da consulta, como no exemplo a seguir.

WHERE event_time >= TIMESTAMP '2024-04-18 00:00:00' AND event_time < TIMESTAMP '2024-04-19 00:00:00'

Você também pode usar a sintaxe BETWEEN start_time AND end_time ou usar os intervalos de vários dias, desde que as partes dos timestamps sejam 00:00:00.

Para obter mais informações, consulte a postagem do blog do Trino.