fix(python-package): valida colunas ao adicionar dados em tabela existente - #1793
Open
aspeddro wants to merge 1 commit into
Open
fix(python-package): valida colunas ao adicionar dados em tabela existente#1793aspeddro wants to merge 1 commit into
aspeddro wants to merge 1 commit into
Conversation
…tente no Table.create Bug: Ao usar `Table.create` para atualizar os dados de uma tabela que já existe (por exemplo, enviando uma nova partição como `ano=2010`), o arquivo era enviado ao Storage sem nenhuma verificação de schema. Quando o usuário enviava um arquivo com número de colunas ou ordem diferente dos arquivos já existentes, a tabela externa quebrava: o BigQuery lê todos os arquivos sob o mesmo prefixo assumindo um único schema, então um arquivo divergente tornava a tabela inconsistente/inutilizável. O problema acontecia inclusive com `if_table_exists="replace"`, pois em tabelas particionadas o usuário pode atualizar apenas uma partição, e o upload para o Storage ocorre antes da tabela ser recriada. Solução: Adiciona uma camada de verificação em `Table.create`, executada ANTES do upload para o Storage, sempre que a tabela de staging já existe. O novo método `_validate_columns_against_staging` compara as colunas do arquivo recebido (`_get_columns_from_data`) com as colunas atuais da tabela no BigQuery (`_get_columns_from_bq`), exigindo o mesmo número e a mesma ordem de colunas. Em caso de divergência, levanta `BaseDosDadosException` com uma mensagem que mostra as colunas esperadas e as recebidas, orientando a apagar e recriar a tabela caso a intenção seja mudar o schema. Assim, um arquivo com schema incompatível nunca chega ao Storage e a tabela não é mais corrompida. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
Tick the box to add this pull request to the merge queue (same as
|
Collaborator
Author
|
O erro ao materializar a tabela com o dbt |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resumo
Ao usar
Table.createpara atualizar os dados de uma tabela que já existe (por exemplo, enviando uma nova partição comoano=2010), o arquivo era enviado ao Storage sem nenhuma verificação de schema. Quando o usuário enviava um arquivo com número de colunas ou ordem diferente dos arquivos já existentes, a tabela externa quebrava: o BigQuery lê todos os arquivos sob o mesmo prefixo assumindo um único schema, então um arquivo divergente tornava a tabela inconsistente/inutilizável.O problema acontecia inclusive com
if_table_exists="replace", pois em tabelas particionadas o usuário pode atualizar apenas uma partição, e o upload para o Storage ocorre antes da tabela ser recriada.Solução
Adiciona uma camada de verificação em
Table.create, executada ANTES do upload para o Storage, sempre que a tabela de staging já existe. O novo método_validate_columns_against_stagingcompara as colunas do arquivo recebido (_get_columns_from_data) com as colunas atuais da tabela no BigQuery (_get_columns_from_bq), exigindo o mesmo número e a mesma ordem de colunas. Em caso de divergência, levantaBaseDosDadosExceptioncom uma mensagem que mostra as colunas esperadas e as recebidas, orientando a apagar e recriar a tabela caso a intenção seja mudar o schema.Assim, um arquivo com schema incompatível nunca chega ao Storage e a tabela não é mais corrompida.
Esse problema apareceu ao subir a PNADC Educação com a @laribritto. Reportei para a @arteweyl em uma daily. O principal problema é que a pessoa deve fazer a verificação. Com esse alteração um erro é lançado