Usar particionamento de ID dinâmico

Quando os dados são particionados por uma propriedade com alta cardinalidade ou quando os valores não podem ser conhecidos antecipadamente, é possível usar o tipo de projeção injected. Exemplos dessas propriedades são os nomes de usuário e os IDs de dispositivos ou de produtos. Quando você usa o tipo de projeção injected para configurar uma chave de partição, o Athena usa valores da própria consulta para calcular o conjunto de partições que serão lidas.

Para que o Athena possa executar uma consulta em uma tabela que tem uma chave de partição configurada com o tipo de projeção injected, o seguinte deve ser verdadeiro:

• A consulta deve incluir, no mínimo, um valor para a chave de partição.

• Os valores devem ser literais ou expressões que possam ser avaliadas sem a necessidade de leitura de dados.

Se algum desses critérios não for atendido, a consulta falhará e apresentará o seguinte erro:

CONSTRAINT_VIOLATION: para a coluna de partição projetada injetada column_name, a cláusula WHERE deve conter somente condições de igualdade estática e pelo menos uma dessas condições deve estar presente.

Quando usar o tipo de projeção injected

Imagine que você tem um conjunto de dados que consiste em eventos de dispositivos de IoT, os quais são particionados nos IDs dos dispositivos. Esse conjunto de dados tem as seguintes características:

• Os IDs dos dispositivos são gerados de forma aleatória.

• Novos dispositivos são provisionados com frequência.

• Atualmente, existem centenas de milhares de dispositivos e, no futuro, haverá milhões.

Esse conjunto de dados é complexo de gerenciar usando metastores tradicionais. É difícil manter as partições sincronizadas entre o armazenamento de dados e o metastore, e a filtragem de partições pode ser lenta durante o planejamento da consulta. Entretanto, se você configurar uma tabela para usar a projeção de partição e usar o tipo de projeção injected, obterá duas vantagens: não precisará gerenciar partições no metastore e as consultas não precisarão procurar metadados de partições.

O exemplo CREATE TABLE, apresentado a seguir, cria uma tabela para o conjunto de dados de eventos do dispositivo que acabamos de descrever. A tabela usa o tipo de projeção “injected”.

CREATE EXTERNAL TABLE device_events (
  event_time TIMESTAMP,
  data STRING,
  battery_level INT
)
PARTITIONED BY (
  device_id STRING
)
LOCATION "s3://amzn-s3-demo-bucket/prefix/"
TBLPROPERTIES (
  "projection.enabled" = "true",
  "projection.device_id.type" = "injected",
  "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}"
)

O exemplo de consulta apresentado a seguir pesquisa o número de eventos recebidos de três dispositivos específicos ao longo de 12 horas.

SELECT device_id, COUNT(*) AS events
FROM device_events
WHERE device_id IN (
  '4a770164-0392-4a41-8565-40ed8cec737e',
  'f71d12cf-f01f-4877-875d-128c23cbde17',
  '763421d8-b005-47c3-ba32-cc747ab32f9a'
)
AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00'
GROUP BY device_id

Quando você executa essa consulta, o Athena visualiza os três valores para a chave de partição device_id e os usa para calcular os locais das partições. O Athena usa os valores com a propriedade storage.location.template para gerar os seguintes locais:

• s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e

• s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17

• s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a

Se você omitir a propriedade storage.location.template da configuração da projeção de partição, o Athena usará o particionamento no estilo Hive para projetar os locais de partições com base no valor em LOCATION (por exemplo, s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e).