Exportação de Parquet no Snowflake Pode Corromper Dados INT32

A questão da corrupção de dados na exportação Parquet do Snowflake não é um mero erro de digitação. É um comportamento do sistema. O Snowflake, para otimização de armazenamento, guarda valores internos usando o menor tipo inteiro possível. Para colunas como BYTES_SCANNED na tabela QUERY_HISTORY, que o catálogo informa ser NUMBER(38,0), o sistema decide armazená-lo como um inteiro de 4 bytes, o equivalente a um INT32.

Quando você exporta essa coluna sem transformações, o escritor Parquet apenas replica a representação interna de INT32. Se o valor real excede o limite de um INT32 (2.147.483.647), ocorre um overflow. Isso gera números negativos ou valores positivos que não correspondem ao original. Nove colunas na QUERY_HISTORY estão sujeitas a isso: bytes_scanned, rows_produced, rows_updated, rows_deleted, rows_unloaded, bytes_deleted, transaction_id, session_id e authn_event_id. A solução é simples: aplicar um CAST explícito para NUMBER(38,0) nas colunas afetadas durante a exportação para Parquet.

Integridade dos dados é fundamental para qualquer pipeline, e este cenário mostra um perigo silencioso. Os valores corrompidos em métricas como bytes_scanned podem distorcer completamente a análise de custos de uso do Snowflake. Um transaction_id ou session_id alterado, por exemplo, pode levar a joins incorretos e prejudicar a rastreabilidade. Em última instância, a falta de atenção a esses detalhes pode minar a confiança nos dados, gerando decisões de negócio equivocadas. É um lembrete forte de que a validação de tipos de dados entre sistemas é uma etapa crucial na engenharia de dados.