Fala dataholics, hoje vamos falar de um tema intrigante, como vim da área de DBA (Database Administrator) falar sobre rotinas de backups bem elaboradas e redundantes era algo trivial, era o arroz com feijão, mas acredite, muitas empresas não tinham e muitas continuam não tendo uma rotina de backup e restore descente. Trazendo um pouco desse contexto para o nosso mundo de Data LakeHouses irei te mostrar algumas técnicas que podem salvar vidas e empregos rs.
Antes de mais nada, esse comando que você esta vendo na imagem acima não existe ok? Foi apenas uma ilustração para chamar sua atenção rsrs, esse post não é clickbait leia até o final e você irá entender se existe ou não backup.
Nesse post veremos:
Qual a importância de um Backup
Caso de uso para Backup (Transacional vs Analítico)
Como funciona as rotinas de backup
Data Lake e Delta Lake - Lakehouse
Restore com Delta Lake - Exemplo prático - Recuperando um UPDATE SEM WHERE
Azure SOFT Delete
Restore de tabela SOFT DELETE - Exemplo prático - Recuperando tabela
Restore de Conteiner com SOFT DELETE e Storage Account
Resumo e considerações finais - Existe almoço grátis?
Por que o backup é tão importante para sua operação?
Para bancos de dados transacionais, ou seja, aqueles bancos de dados que atendem a linha de frente e recebem os dados das aplicações, ter backup é questão de sobrevivência, tem até um ditado que diz “Backup, quem tem 1, não tem nenhum”.
Vou dar um exemplo bem clássico, imagine uma empresa com 10 anos de operação e seu software ERP entre outros softwares que sua empresa tem, estão rodando lindo e maravilhoso, todos os dados são armazenados em um banco de dados, darei como exemplo um SQL Server da Microsoft, a sua empresa não tem DBA porque acha que não tem necessidade e eles são muito "caros", um belo dia, o disco do seu servidor da um crash e todo seu banco de dados é perdido, me diz o que vai acontecer com essa empresa se ela não tiver nenhum backup? Possivelmente ela pode ir à falência, sua operação vai parar por um bom tempo, vai perder a credibilidade no mercado, pode levar multas e por aí vai, acredite em mim, é um cenário catastrófico quando isso acontece.
Por isso, ter backup redundante não é luxo, é sobrevivência, esse caso que comentei acontece muito por aí, lembro que no meu primeiro ano de Dataside, peguei um caso parecido, o desespero da empresa era tanta, que me enviaram o disco do servidor pelos correios para ver se conseguíamos recuperar usando técnicas avançadas (existiam alguns jeitinhos rs), infelizmente não foi possível recuperar nada, muitos blocos onde estavam os arquivos de dados foram perdidos e sobrescritos, mesmo enviando para empresas especializadas em recuperação de HD não foi possível, essa empresa não tinha DBA e claro, não tinha backup, não sei o que aconteceu com ela, mas, nunca mais ouvi falar dela, pode ser um sinal.
Claro que não desejo isso para nenhuma empresa e meu papel como DBA era dar essa tranquilidade para elas, que os seus bancos de dados estavam seguros.
Isso é só uma breve história sobre backup para você ter noção do quanto é importante!
Estou sendo simplista em alguns pontos para ser mais direto, o papel de um DBA não é só cuidar de Backup, e ter rotinas de backup não valem de nada se eles não forem uteis quando precisarem, então tão importante quanto fazer backup é ter uma rotina de testar os backups, ter redundância, lembre-se, backup, quem tem 1 não tem nenhum.
Mas Reginaldo, por que nunca ouvi falar de Backup para Data lake? Isso existe?
Backup para ambientes transacionais já vimos que é extremamente importante, é onde o dado nasce, então precisa de uma atenção maior, mas e para ambientes analíticos que geralmente são dados replicados do ambiente transacional? Será que é tão importante assim?
Quem vai nos dizer o quão importante é, são as áreas de negócio, o nosso papel é deixar mapeado um plano de desastre, faça as seguintes perguntas, se seu Data Lake for apagado por inteiro, quanto tempo você levara para refazer todas as cargas? Talvez 1 semana, 1 mês? Suas áreas de negócio podem ficar 1 mês no escuro, sem dados? Todos os dados são recuperáveis? As fontes ainda existem?
Meu papel aqui não é montar um plano de recuperação de desastre, e sim falar especificamente de Backup, para falar de backup de data lake, deixa eu contextualizar como funciona um backup de um banco de dados transacional.
Quase todas as engines de bancos de dados relacionais e NoSQL possuem suas próprias ferramentas de backup, pois, cada banco de dados trabalha e armazena os dados de maneiras diferentes, vou dar o exemplo do SQL Server.
O Microsoft SQL Server armazena seus dados em arquivos no sistema operacional, geralmente com tipo de dados .MDF, ali dentro estão todos os seus dados, todas suas tabelas, quando você for realizar um backup do seu banco de dados, tem 3 opções, elas são bem parecidas para outras engines e até mesmo ferramentas tradicionais de backup:
FULL - Cópia completa do banco, é como se fosse uma foto dos seus arquivos .MDF
Diferencial - Copia tudo que mudou desde o último FULL - Não é a mesma coisa do que backup Incremental
LOG - Tudo que aconteceu desde o último backup de LOG
Esse backup de Log (em qualquer engine de banco de dados) é extremamente importante, é o que da possibilidade de fazer um RESTORE POINT IN TIME, ou seja, voltar para um ponto no tempo, um momento exato, temos essa mesma opção com o TIME TRAVEL usando DELTA, mostrarei mais a frente.
Em resumo, tendo esses 3 backups funcionando, você consegue desfazer um incidente no seu banco de dados, já ouviu falar daquele famosos UPDATE SEM WHERE? Com backup de LOG você consegue voltar nesse exato momento e desfazer essa cagada rs.
Sobre backup é isso, espero que tenha entendido o conceito e a importância.
Uai, Reginaldo, você ainda não falou sobre Data lake!
Pronto, Data lake backupeado!
Brincadeiras a parte, esse comando não existe rs, para contextualizar um pouco mais sobre o famoso Data lake, ele é apenas um conceito para armazenamento de dados brutos de vários tipos de dados, geralmente em grande quantidade de dados, estamos falando na casa de TB (TeraByte) para cima, chegando facilmente na casa de PB (PetaByte) para cenários mais robustos. A tecnologia utilizada para o Data Lake nas clouds são os Storages como Azure (Azure Blob Storage ou ADLS), AWS (S3) e GCP (GCS), isso mesmo no final das contas o Data Lake não passa de um storage com pastas organizadas (é o que esperamos).
Recentemente entramos num novo conceito, o Lakehouse que une características de um Data Warehouse (Geralmente um banco de dados relacional), mas operando sobre um Data Lake (Storage).
Bom, não quero estender nesse assunto, só entrei para falarmos do Delta, o Lakehouse com Databricks só possível devido a Delta Engine que traz features de um banco de dados, então passamos a trabalhar com Delta tables, um dos recursos sensacionais da Delta Table é o TIME TRAVEL, eis a primeira forma de "Backup" que temos.
De forma bem resumida, as tabelas Delta sempre que sofrem uma modificação, exemplo INSERT, UPDATE ou DELETE, elas geram novas versões do dado, mantendo a versão anterior disponível para ser acessada, na prática, o Delta vai gerando novos arquivos PARQUET e mantendo os arquivos antigos até que alguém rode uma operação VACUUM.
DELTA - TIME TRAVEL
Veremos um exemplo, na prática, de um caso de Restore utilizando tabelas DELTA.
Abaixo tenho três comandos, um que lê um CSV em seguida um que grava esse CSV em uma tabela Delta e por fim dando um describe detail.
Repare na coluna numFiles, ela indica a quantidade de arquivos na versão atual da tabela, não rastreia os arquivos já marcados para ser removido, que sã os arquivos que usamos para Time Travel.
Essa é a nossa tabela Delta no storage, apenas 1 arquivo de dados.
Esses são os dados da tabela:
Vamos ao incidente rs, então um belo dia o engenheiro precisava fazer algumas correções nessa tabela, executar 1 UPDATE para corrigir a idade de um paciente e depois um UPDATE para corrigir o sexo de outro registro, eram para ser atualizados apenas 2 registros.
MAS, eis que ele esquece o WHERE comentado (É raro, mas acontece sempre), OPS!
(Famoso UPDATE SEM WHERE, na prática)
E agora, alteramos todo mundo para sexo masculino, vai dar ruim para esse engenheiro?
Como temos o versionamento pelo DELTA nossos dados ainda estão lá, vamos consultar as versões do DELTA, note que temos 2 versões novas uma para cada UPDATE.
É possível fazer query nas versões antes de realizar o RESTORE, note que na versão 1 o registro estava com sexo feminino e o mesmo registro na versão 2 está com sexo masculino.
Esse é o famoso TIME TRAVEL na prática.
Bora desfazer essa caca, restaurar a tabela para a versão desejada.
Veja que utilizamos um comando de RESTORE similar ao que usamos em outros bancos de dados.
E pronto, salvos pelo gongo:
Para efeitos de curiosidade:
Se você olhar no DESCRIBE DETAIL da tabela continua com numFiles = 1, mas no Storage agora temos 3 arquivos, sendo 2 deles marcados como removidos da tabela, são eles que proporcionam o TIME TRAVEL, até que seja executado um VACUUM e ai são excluídos definitivamente.
Primeiro arquivo - Criação da tabela
Segundo arquivo - Update no registro 1000000001
Terceiro arquivo - Update SEM WHERE
Note para cada comando ele criou um arquivo, esse exemplo está bem simples, pois, toda nossa tabela cabe dentro de 1 único arquivo, em tabelas maiores ele só irá manipular os arquivos referente aos registros alterados.
Azure Storage SOFT DELETE
Maravilha Reginaldo, mas e se minha tabela não for Delta? E se ela for DELTA e alguém for la no Storage e apagar ela?
Para esses cenários (acreditem eles acontecem), não temos uma ferramenta de BACKUP igual os bancos transacionais como falamos anteriormente, inclusive seria bem pesado fazer um BACKUP de um Data Lake de TeraBytes ou até mesmo PetaBytes, concorda?
Imagina criar uma política de backup FULL de um Data lake com 50 TeraBytes mensal, quanto custaria isso? Não da pra aplicarmos o mesmo conceito dos bancos transacionais aqui.
Mas as Clouds são nossas amigas, no Azure Storage temos um recurso chamado SOFT DELETE para arquivos e containers, justamente para nos proteger desses incidentes indesejados onde alguém apaga indevidamente uma pasta,, um arquivo ou um container.
No Azure Storage ele possui tanto o Soft Delete quanto um versionamento, que pode pegar arquivos sobrescritos, como no Delta Lake nada é sobrescrito (sempre são gerados arquivos novos) apenas o SOFT DELETE nos interessa para esse post.
Basicamente o SOFT DELETE funciona similar ao DELTA, quando você excluir um arquivo que está em uma Storage que possui esse recurso habilitado, ele apenas marca o arquivo como excluído, mas nesse caso você configura um período de retenção, o padrão é 7 dias, depois desses dias aí o arquivo é excluído definitivamente e não tem volta.
Vejamos um caso prático:
Imagine que alguém sem querer, querendo, foi direto no Storage e excluiu a pasta da tabela Delta:
(Um delete SEM WHERE rs)
Você passa a tomar erros na tabela, pois, ela não existe mais no storage, continua existindo no seu catalogo HIVE ou Unity Catalog, mas os dados se foram.
Vamos recorrer ao DELTA TIME Travel? Ops, ele foi apagado junto.
Agora deu ruim? Se seu Storage tiver SOFT DELETE habilitado, basta restaurar a pasta!
Marque a opção para ver objetos deletados:
Selecione a pasta e Undelete.
Pronto tabela recuperada:
Essa mesma dica serve para nível do Container (Bucket), caso ele seja excluído.
E se o estrago for maior, apagando a Storage Account toda, é possível restaura um Storage account?
Apenas para quem não conhece a hierarquia do Azure, vou simplificar:
->Azure Account
-> Azure Subscription
-> Resource Group
-> Azure Storage Account - Recuperável até 14 dias
-> Storage Container - Recuperável com SOFT DELETE - periodo de retenção
-> Folders - Recuperável com SOFT DELETE - periodo de retenção
-> Files - Recuperável com SOFT DELETE - periodo de retenção
Então, sim, da para recuperar uma Storage Account, mas para evitar esse risco e estresse, utilize LOCK nos seus Recursos importantes, impedindo exclusão indevida.
Um ponto de atenção bem importante, você achou que existia almoço gratis?
Em ambos os cenários tanto do DELTA como SOFT DELETE existe um aumento de custo $ para o seu bolso.
No Delta: Esse é o mais perigoso, pois, para tabelas DELTAs normais (que não sejam Delta Live Tables) a operação de Vacuum não é executada automaticamente, então a retenção é eterna, alguém precisa ir la e limpar, isso pode aumentar muito o custo de armazenamento, ja peguei casos de tabelas DELTA com poucos GB de dados, mas no Storage ter TB de versões.
SOFT DELETE: Também aumenta o seu custo, pois, o arquivo não é excluído imediatamente, para storage account com muitas exclusões tome cuidado, seu custo pode aumentar retendo muito arquivo excluído e versões.
Defina o período de retenção com cuidado, ele pode ser alterado a qualquer momento também, utilize políticas de LifeCycle para expurgar arquivos antigos.
As outras Clouds como AWS e GCP também fornecem opções parecidas utilizando versionamento com o AWS S3 e GCP Google Cloud Storage, explore o melhor para o seu ambiente.
Em resumo:
Não existem ferramentas especificas para Backup de Data lake \ Lakehouse igual temos para ambientes transacionais em ferramentas como SQL Server.
Mas, existem maneiras de se recuperar de um incidente de exclusão de dados indesejada, seja restaurando os dados via tabela Delta ou via Storage com os recursos disponibilizados pelas Clouds.
Espero que tenha ajudado e você tenha conseguido consolidar todos os conceitos explicados, se ficar duvidas deixa um comentário ou me chama no Linkedin, esses recursos podem salvar empregos, acredite já ajudei muita gente utilizando eles.
Fiquem bem e até a próxima.
Excelente conteúdo!