Retenção de Dados Configurável no Microsoft Fabric Warehouse: O que muda para a sua operação
Este artigo analisa a nova funcionalidade de retenção de dados configurável no Microsoft Fabric Warehouse, que permite definir entre 1 e 120 dias de histórico para mecanismos de time travel e recuperação. A conclusão principal é que essa mudança descentraliza a política de armazenamento, permitindo que times de engenharia ajustem janelas de recuperação conforme a criticidade do ambiente (dev/test vs. produção/compliance), otimizando custos e aumentando a resiliência operacional sem a necessidade de migrações complexas.
Por que a rigidez de retenção era um problema?
Historicamente, o Microsoft Fabric Warehouse impunha uma janela fixa de 30 dias para o histórico de dados. Na prática, essa política "tamanho único" criava atritos operacionais claros: times de desenvolvimento pagavam por um histórico de 30 dias em ambientes descartáveis, enquanto setores regulados, como Finanças e Saúde, sofriam com limitações que forçavam o uso de ferramentas de arquivamento externas para cumprir requisitos de auditoria mais longos.
O impacto técnico do Delta no versionamento
O motor por trás dessa novidade é o formato Delta Lake. O Fabric Warehouse utiliza o log de transações do Delta para manter versões históricas das tabelas sem duplicar dados fisicamente (ou seja, sem desperdício de storage desnecessário). O que a Microsoft liberou agora não é uma mudança no formato, mas o controle sobre a política de limpeza deste log através de comandos T-SQL simples.
Como essa flexibilidade altera a estratégia de engenharia?
Com a capacidade de configurar a retenção de 1 a 120 dias, a estratégia de SRE e Data Engineering deve ser revista:
- Ambientes de Teste (Dev/Staging): Reduza o tempo de retenção para o mínimo necessário. Como ambientes de QA são frequentemente recriados, armazenar 30 dias de logs de transação é um desperdício de recursos.
- Produção e Compliance: Para setores regulados, a expansão para 120 dias elimina a necessidade de pipelines complexos de dumping para storage de longo prazo apenas para fins de auditoria, centralizando tudo dentro do ecossistema Fabric.
- Deployments com Rollback Seguros: A retenção alinhada ao ciclo de release permite que, em caso de um deploy corrompido, a equipe de engenharia tenha uma janela de recuperação garantida, baseada no seu tempo de resposta real, e não em uma métrica estática imposta pelo provedor.
Pontos de atenção para tomadores de decisão
A redução da retenção de dados é uma via de mão única. Uma vez diminuída a janela, o Garbage Collector do sistema deleta os dados excedentes de forma irreversível. É fundamental realizar um mapeamento de RPO (Recovery Point Objective) antes de alterar essas configurações em produção.
Perguntas Frequentes
-
Como a nova funcionalidade de retenção de dados impacta os custos de armazenamento?
Ao permitir o ajuste fino da janela de retenção (1 a 120 dias), times podem reduzir significativamente os logs de histórico em ambientes de desenvolvimento ou teste, evitando o pagamento desnecessário por dados que não precisam ser auditados ou recuperáveis. -
A redução da janela de retenção é reversível?
Não. Reduzir a retenção dispara o Garbage Collector do Fabric para remover dados antigos permanentemente. Aumentar a janela posteriormente apenas permitirá o acúmulo de histórico a partir daquela data, sem recuperar o que foi descartado. -
A retenção de dados configurável afeta a funcionalidade de 'Dropped Retention'?
Não. São capacidades distintas. A retenção de dados rege snapshots e time travel em warehouses ativos, enquanto o 'Dropped Retention' atua como uma rede de segurança de 7 a 90 dias após a exclusão do recurso, protegendo contra deleções acidentais.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
