Aplicando Change Data Feed para auditoria em tabelas Delta
O que é o Change Data Feed? Change Data Feed é uma feature do Delta Lake a partir da versão 2.0.0 que permite rastrear a níveis de linhas em tabelas Delta, mudanças como operações de DML (Merge, Delete ou Update), versões do dados e o timestamp de quando aconteceu a mudança. O processo mapeia operações de Merge, Delete e Update mantendo o histórico de alterações a nível de linha, ou seja, cada evento efetuado em um registro, o Delta através do Change Data Feed consegue registrar como uma espécie de auditoria . É claro que é possível utilizar para diferentes casos de uso, é extenso as possibilidades. Como funciona na prática Iremos simular uma pipe aplicando Change Data Feed para tabelas Delta, pois não é um recurso default. Após a criação da tabela Delta, iremos executar algumas operações visando explorar mais sobre o poder do Change Data Feed. Iremos trabalhar com seguinte Dataset: Criando a Sessão Spark e configurando alguns parâmetros do Delta A partir de agora, criaremos o código em partes para um fácil entendimento. O código abaixo estamos criando o método responsável por manter a sessão do Spark e configurando alguns parâmetros para o funcionamento do Delta. Carregando o Dataset Vamos carregar o Dataset e criar uma view temporário para ser usada na nossa pipeline mais adiante. Criando a tabela Delta Agora faremos a criação da tabela Delta já configurando Change Data Feed nas propriedades da tabela e toda a parte de metadata será baseada no Dataset anteriormente apresentado. Perceba que estamos usando na propriedade o seguinte parâmetro delta.enableChangeDataFeed = true para a ativação do Change Data Feed. Executando Merge dos dados Agora executaremos uma simples operação Merge para que o Change Data Feed possa registrar como mudança na nossa tabela. Veja que o Merge utiliza na nossa view global_temp.raw_product anteriormente criada para o upsert dos dados. Auditando a tabela Agora que o Merge foi executado, vamos executar uma leitura na nossa tabela para entender o que aconteceu e como o Change Data Feed atuou. Perceba que estamos passando os seguinte parâmetros: 1. readChangeFeed em que é necessário para o uso do Change Data Feed. 2. startingVersion é o parâmetro responsável por restringir a partir de qual versão inicial queremos que seja apresentada. Resultado após execução: Veja que além da colunas definidas na criação da tabela, temos 3 novas colunas gerenciadas pelo Change Data Feed. 1. _change_type: Coluna contendo valores de acordo com cada operação efetuada como insert , update_preimage , update_postimage , delete 2. _commit_version : Versão da mudança 3. _commit_timestamp : Timestamp representando a data da mudança No resultado acima, o resultado do upsert foi um simples insert , por não conter todas as condições possíveis de um update. Deletando um registro Nessa etapa faremos um simples delete em um registro da tabela, apenas para validarmos como o Change Data Feed irá se comportar. Auditando a tabela (novamente) Perceba abaixo que após a deleção do registro 6, agora temos um novo registro criado como delete na tabela e seu incremento de versão para 2. Outro ponto é que o registro original foi mantido, porém com a versão antiga. Atualizando um registro Agora como último teste, iremos atualizar um registro para entender novamente o comportamento do Change Data Feed. Auditando a tabela (última vez) Agora como último teste, executamos um simples update em um registro para entender como será o comportamento. Perceba que 2 novos valores foram adicionados/atualizados na coluna _change_type . O valor update_postimage é o valor após o update executado e dessa vez, para o registro antigo, foi mantido a mesma versão do novo na coluna _commit_version , pois este mesmo registro foi atualizado de acordo com coluna _change_type para update_preimage , ou seja, valor antes da mudança. Conclusão O Change Data Feed é um ótimo recurso para entender o comportamento da sua pipeline de dados e também uma forma de auditar registros visando um melhor entendimento das operações ali executadas. Segundo o próprio time do Delta, é um recurso que mantido não gera nenhum overhead significativo, ou seja, talvez seja uma feature que pode ser adotada de forma integral em sua estratégia de dados pois possui vários benefícios como foi mostrado neste post. Repositório GitHub Espero que tenha curtido!