Os dados de uma empresa nunca estão parados. O negócio muda, e com ele mudam os dados que o descrevem: acrescenta-se um novo tipo de informação sobre os clientes, deixa de se usar um campo que já não faz sentido, muda-se a forma como se regista uma transação. Cada uma destas mudanças na estrutura dos dados — a que se chama esquema — é natural e inevitável. O problema é que, se não for bem gerida, uma mudança aparentemente inocente na estrutura de uma tabela pode partir tudo o que depende dela a jusante: pipelines que deixam de correr, relatórios que ficam vazios, análises que falham. Gerir estas mudanças de forma controlada — a chamada schema evolution, ou evolução de esquema — é uma das competências que distinguem uma operação de dados robusta de uma frágil.
A tensão está no coração do problema: os dados precisam de evoluir para acompanhar o negócio, mas essa evolução ameaça a estabilidade de tudo o que os consome. Uma estrutura de dados congelada, que nunca muda, seria estável mas rapidamente ficaria desalinhada da realidade. Uma estrutura que muda sem cuidado seria flexível mas partiria constantemente o que dela depende. A evolução de esquema é a arte de permitir que os dados mudem sem que essas mudanças causem estragos — de conciliar a necessidade de evoluir com a necessidade de não partir nada.
Este artigo explica porque as mudanças de esquema são tão perigosas, que tipos de mudança existem, e como as gerir de forma a que os dados possam evoluir com segurança.
Porque uma mudança inocente parte tudo
Uma tabela de dados raramente vive isolada. Tipicamente, é consumida por muitas coisas a jusante: pipelines que a lêem e transformam, relatórios que a mostram, modelos que a usam, outras tabelas que dela derivam. Cada um destes consumidores foi construído assumindo que a tabela tem uma determinada estrutura — determinados campos, com determinados tipos. Quando essa estrutura muda, esses consumidores podem partir, porque a suposição em que assentavam deixou de ser verdade.
O que torna isto particularmente perigoso é a invisibilidade da dependência. Quem faz uma mudança numa tabela raramente conhece tudo o que depende dela — todos os pipelines, relatórios e análises que a consomem, muitas vezes construídos por outras pessoas, ao longo do tempo. Assim, uma mudança feita com a melhor das intenções, para melhorar a estrutura dos dados, pode partir silenciosamente um relatório crítico do outro lado da empresa, e quem fez a mudança nem se apercebe. É esta cadeia de dependências invisíveis que transforma uma alteração aparentemente simples num risco real.
Nem todas as mudanças são iguais
Uma distinção fundamental na evolução de esquema é entre mudanças seguras e mudanças perigosas. Algumas mudanças são compatíveis — não partem o que já existe. Acrescentar um novo campo a uma tabela, por exemplo, é geralmente seguro: os consumidores que não conhecem o novo campo simplesmente ignoram-no e continuam a funcionar como antes. Estas mudanças aditivas podem fazer-se com relativa tranquilidade, porque não retiram nada em que alguém pudesse estar a confiar.
Outras mudanças são incompatíveis — partem o que depende delas. Remover um campo, mudar o seu tipo, ou mudar o seu significado são mudanças perigosas, porque qualquer consumidor que dependesse daquele campo, tal como era, deixa de funcionar. Distinguir estes dois tipos de mudança é o primeiro passo para gerir a evolução de esquema: as mudanças compatíveis podem fazer-se com cuidado ligeiro; as incompatíveis exigem um processo muito mais cuidadoso, porque vão, por definição, partir alguma coisa se não forem geridas.
Os princípios de uma evolução segura
- Preferir mudanças aditivas: acrescentar em vez de alterar ou remover sempre que possível, porque acrescentar raramente parte o que existe.
- Deprecar antes de remover: marcar um campo como obsoleto e dar tempo aos consumidores para se adaptarem antes de o remover de facto.
- Comunicar as mudanças: avisar com antecedência quem depende dos dados, para que possa preparar-se em vez de ser apanhado de surpresa.
- Validar automaticamente: ter verificações que detetam mudanças de esquema perigosas antes de elas chegarem a produção e partirem coisas.
A técnica de deprecar antes de remover
Uma das técnicas mais valiosas na evolução de esquema é a de nunca remover algo abruptamente, mas sim deprecá-lo primeiro. Quando um campo já não é necessário e se quer removê-lo, em vez de o apagar de imediato — o que partiria tudo o que dele dependesse — marca-se como obsoleto e comunica-se que vai ser removido dentro de um determinado prazo. Durante esse período, o campo continua a existir, mas todos sabem que devem deixar de o usar. Só depois de dado tempo suficiente para todos se adaptarem é que o campo é efetivamente removido.
Esta abordagem transforma uma mudança perigosa e abrupta numa transição controlada e previsível. Em vez de partir tudo de uma vez e obrigar a correções de emergência, dá-se aos consumidores a oportunidade de se adaptarem no seu tempo, com aviso prévio. É a diferença entre demolir um edifício com pessoas lá dentro e dar-lhes tempo para saírem primeiro. Esta paciência tem um custo — manter o campo obsoleto durante mais algum tempo — mas evita o caos e os incidentes que uma remoção abrupta causaria.
Um caso concreto
Uma empresa tinha uma tabela central de clientes que era consumida por uma quantidade impressionante de coisas — dezenas de relatórios, vários pipelines, alguns modelos, e outras tabelas que dela derivavam, muitas construídas por diferentes equipas ao longo de anos. A certa altura, o negócio mudou, e um dos campos dessa tabela deixou de fazer sentido, enquanto era preciso mudar o formato de outro. Uma primeira tentativa de fazer estas mudanças correu mal: uma equipa, para arrumar a tabela, removeu o campo obsoleto e alterou o formato do outro diretamente, sem perceber a extensão das dependências. O resultado foi um dia de caos — vários relatórios de outras áreas ficaram vazios ou com erros, pipelines falharam, e ninguém percebeu imediatamente porquê, porque a mudança tinha sido feita numa tabela e os efeitos manifestaram-se noutro lado completamente diferente. Depois deste susto, a empresa adotou uma abordagem disciplinada de evolução de esquema. Para futuras mudanças, passaram a seguir princípios claros. As mudanças aditivas — acrescentar campos novos — faziam-se com relativa tranquilidade. Mas para as mudanças perigosas, como remover um campo ou mudar o seu formato, adotaram a técnica de deprecar antes de remover: marcavam o campo como obsoleto, comunicavam a mudança a todas as equipas com bastante antecedência, davam tempo para todos se adaptarem, e só depois removiam. Adicionaram também validações automáticas que detetavam mudanças de esquema perigosas antes de chegarem a produção. Da vez seguinte que foi preciso remover um campo, o processo correu sem incidentes: o campo foi deprecado, as equipas foram avisadas, tiveram semanas para se adaptar, e quando o campo foi finalmente removido, nada partiu, porque já ninguém dependia dele. A mesma mudança que antes causara um dia de caos passou a ser uma transição tranquila e previsível. A diferença não esteve em evitar a mudança — os dados têm de evoluir —, mas em geri-la de forma controlada em vez de a fazer abruptamente.
Evoluir sem medo
O objetivo último da evolução de esquema é permitir que os dados de uma empresa continuem a acompanhar o negócio sem que essa necessária evolução se torne uma fonte de medo e de incidentes. Uma operação de dados que gere bem as mudanças de esquema pode evoluir a sua estrutura de dados com confiança, sabendo que tem os processos para o fazer sem partir nada. Uma que as gere mal fica presa num dilema: ou congela os dados e fica desalinhada da realidade, ou muda-os e vive em constante crise. A boa evolução de esquema remove este dilema, permitindo a mudança segura.
Esta capacidade liga-se diretamente a outras práticas de dados maduros — os contratos de dados, que formalizam as promessas sobre a estrutura dos dados, e a observabilidade, que deteta quando algo muda inesperadamente. Todas partilham o mesmo objetivo: tornar os dados robustos e fiáveis mesmo num mundo em constante mudança. A evolução de esquema é a peça que garante que a inevitável mudança da estrutura dos dados acontece de forma controlada, e não como uma série de surpresas desagradáveis.
Na prática
Se na tua empresa as mudanças na estrutura dos dados são feitas de forma ad hoc, e de tempos a tempos uma alteração numa tabela parte relatórios ou pipelines do outro lado da organização, precisas de uma abordagem disciplinada à evolução de esquema. Adota princípios simples: prefere acrescentar a alterar, depreca antes de remover dando tempo às pessoas para se adaptarem, comunica as mudanças com antecedência, e valida automaticamente as mudanças perigosas. As mudanças na estrutura dos teus dados são geridas de forma controlada, ou vives com o receio de que a próxima alteração parta algo importante do outro lado da empresa?
