Um time upstream renomeia uma coluna sem avisar e o seu pipeline quebra. O que você faz, e o que você muda depois?

No curto prazo, restaure o serviço: mapeie o nome novo na camada de staging, reexecute as partições afetadas e confirme que os números seguintes reconciliam. No longo prazo, pare de depender de boa vontade. Estabeleça um contrato de dados com o time de origem, valide o schema na ingestão para que as falhas sejam pegas na fronteira com uma mensagem clara, e aterrisse os payloads brutos sem tipagem, para que um rename não destrua o próprio caminho de ingestão.

Imediatamente é um ajuste pequeno: crie um alias para a nova coluna no modelo de staging, reexecute as partições afetadas e reconcilie alguns agregados confiáveis para eu saber que nada mudou de significado além do nome. Eu também checo no catálogo quem mais consome aquela tabela, porque se quebrou para nós provavelmente quebrou para outra pessoa que ainda não percebeu. Depois vem a parte sistêmica. Eu prefiro que a falha aconteça na ingestão com uma mensagem dizendo esperava a coluna customer_id, encontrei customer_identifier, em vez de três modelos adiante com uma coluna nula. Então a validação de schema vai para a fronteira, e a camada raw guarda o payload como está, o que significa que a ingestão continua funcionando e só a camada tipada reclama. E eu iria conversar com o time da origem, não para reclamar, mas para montar um contrato: estes são os campos dos quais dependemos, este é o alerta, por favor nos avise antes de um release. Nós fizemos isso no meu último lugar e transformamos um problema recorrente das 6 da manhã em uma mensagem no Slack com uma semana de antecedência.