Data Export: entrega de hora em hora a partir de 03/11/2026

Resumo

A partir de 3 de novembro de 2026 (terça-feira), o Data Export passa a entregar os dados da sua operação de hora em hora, e não mais uma vez por dia. As entregas horárias chegam em uma pasta nova dentro do mesmo bucket: v2/. A pasta atual, v1/, continua disponível para leitura, mas não recebe mais nada depois de 2 de novembro.

Se o seu time de dados consome o Data Export, ele precisa ajustar a ingestão. O ajuste pode ser publicado antes de 3 de novembro e passa a valer sozinho na primeira entrega horária. Os ajustes estão listados abaixo.

Quando

Não há entrega entre as duas. A primeira entrega horária traz tudo o que a última diária ainda não tinha entregado, incluindo o dia 2, então nenhum dado se perde na troca.

Depois disso, cada entrega traz os dados de cerca do início da hora e costuma ficar disponível em até 40 minutos.

O que continua igual

• O bucket e a forma de acesso, pela sua conta AWS ou Google.
• O formato dos arquivos (Parquet), as 19 tabelas e todas as colunas.
• Tudo o que já está em v1/. Nada é movido nem apagado.
• As regras de armazenamento: arquivos com mais de 180 dias continuam indo para o armazenamento de longo prazo.

O que muda

• Pasta nova. As entregas passam a chegar em v2/, com as mesmas tabelas que existem hoje em v1/.
• Uma pasta por hora. Dentro de cada data, cada entrega ganha uma pasta própria com a hora (snapshot_hour= ou etl_hour=). As horas seguem o horário UTC, 3 horas à frente de Brasília: 03 é meia-noite e 15 é meio-dia.
• Tabelas completas (16 tabelas). A cada hora chega uma cópia inteira da tabela. Para ter os dados mais recentes, basta ler a última hora.
• Tabelas de mensagens (claudia_messages, claudia_prompt_revision e cloud_chat_messages). A cada hora chega só o que é novo desde a entrega anterior. O histórico até 2 de novembro fica em v1/, e o que chega a partir do dia 3 fica em v2/.
• Alterações chegam de novo. Em claudia_messages e claudia_prompt_revision, quando um registro muda depois de entregue, a versão nova chega numa pasta de hora seguinte. Vale sempre a versão mais recente de cada registro.

O que o time de dados precisa ajustar

1. Trocar v1/ por v2/ em todos os caminhos lidos.
2. Nas tabelas completas, ler só a última hora de cada data. Ler a data inteira traz até 24 cópias da mesma tabela.
3. Incluir a hora no catálogo (Athena ou Glue), se o seu time declara as partições.
4. Nas tabelas de mensagens, juntar o histórico de v1/ com o que chega em v2/, ficando com a versão mais recente de cada registro (por message_id em claudia_messages e por prompt_revision_id em claudia_prompt_revision). O histórico de v1/ não muda mais, então basta lê-lo uma vez.
5. Definir a frequência de leitura. Dá para ler a cada hora, usando o arquivo de controle (manifest) de cada hora como gatilho. Quem continuar lendo uma vez por dia também recebe tudo, desde que os passos acima estejam feitos.

Dá para deixar o ajuste publicado antes

Não é preciso mexer na ingestão no dia 3. O time de dados pode publicar o ajuste antes, com uma regra simples: a cada execução, verificar se já chegou alguma entrega em v2/ e, se sim, ler de lá; se não, continuar lendo v1/. Assim a troca acontece sozinha na primeira entrega horária, mesmo que ela atrase alguns minutos. A documentação técnica traz um exemplo pronto em AWS Glue, na seção Prepare the switch ahead of time.

O acesso que vocês já têm vale para o bucket inteiro, v2/ incluída. Não é preciso pedir nenhuma liberação.

Observações

• Documentação técnica para o time de dados: Hourly delivery in v2, com exemplos de caminhos, o arquivo de controle de cada hora, como juntar v1/ e v2/ e como deixar o ajuste pronto antes da troca.
• Dúvidas sobre a troca: fale com o seu ponto de contato na Cloud Humans (CSM) ou com o nosso suporte.
• Veja também: Como acessar os dados brutos da sua operação (Data Export).