O Delta Lake é uma tecnologia emergente que tem ganhado destaque na área de engenharia e gestão de dados. Com o crescente volume e variedade de dados gerados pelas empresas, a necessidade de soluções avançadas para armazenamento, gerenciamento e processamento de dados tornou- se mais importante do que nunca.
Neste artigo, vamos explorar o que é o Delta Lake e como essa tecnologia está revolucionando a forma como os dados são gerenciados e processados.
O que é o Delta Lake:
Delta Lake é um framework de armazenamento de dados desenvolvido inicialmente em 2017 pela Databricks, empresa líder em tecnologias de análise de dados e machine learning, e agora mantido como projeto open-source desde 2019.
É este framework ou camada de armazenamento que viabiliza a construção de arquiteturas Lakehouse, uma junção do melhor dos mundos entre Data Warehouse e Data Lake.
O Delta Lake é uma camada de armazenamento open-source, para tabelas ACID. A camada Delta Lake foi projetada para ficar sobre a camada de armazenamento de objetos na nuvem (Data Lake), por exemplo:
- – Amazon S3 (Simple Storage Service)
- – ADLS (Azure Data Lake Storage)
- – HDFS (Hadoop Distributed File System
seu uso entrega ao Data Lake recursos avançados e essenciais para a confiabilidade, integridade e escalabilidade dos dados.
A camada Delta Lake possibilita, por exemplo, a execução de transações ACID no Data Lake, o que era muitas vezes uma característica exclusiva de ambientes relacionais como em um Data Warehouse. A sigla ACID nomeia o conceito de de:
- – Atomicidade
- – Consistência
- – Isolamento
- – Durabilidade
É através destes conceitos de integridade transacional que podemos realizar transações como UPSERT, UPDATE, DELETE e MERGE, mesmo em um ambiente de armazenamento distribuído com dados nem sempre estruturados, como são os Data Lakes.
Resumindo, a camada Delta Lake proporciona o armazenamento de tabelas de forma ACID de modo otimizado gerando alto desempenho em ambientes de armazenamento na nuvem.
A seguir vamos explorar mais alguns recursos desta camada.
Formato de Armazenamento
O conteúdo de uma tabela no Delta Lake é armazenado em objetos do Apache Parquet, sendo organizados em diretórios usando a convenção de nomenclatura do Hive, podendo ser particionado ou não.
Um arquivo Delta é feito pelos seguintes componentes:
- – Arquivos Parquet contendo os dados
- – Arquivos Json contendo todo o log transacional
- – Arquivos de Checkpoint
A escolha em usar Parquet baseou-se nas características deste tipo de arquivo como:
- – Estrutura “orientada a colunas”.
- – Diversas otimizações de compressão de dados.
- – Integração performática com muitos motores como Apache Spark.
O fato deste tipo de arquivo também ser open-source garante uma série de otimizações ao longo do tempo.
Outros tipos de arquivo como ORC também iriam funcionar nesta lógica, entretanto o formato Parquet é o mais maduro para suportar Spark.
Layout de Dados Otimizado
O formato Delta contém features que automaticamente otimizam o tamanho dos objetos em uma tabela e segmentam registros para realizar o “Data Skipping”.
O data skipping é um recurso de otimização!
O Motor ao realizar alguma consulta consegue, através de metadados, pular/saltar/skip algumas partes da tabela indo direto ao dado solicitado.
Tabelas Delta armazenam informações estatísticas (metadados) sobre a base de dados de forma a otimizar o processo de consulta, como por exemplo valores mínimos e máximos.
Suponha que você deseja selecionar algum contrato onde:
-- O Valor de Faturamento seja maior do que 5.000
SELECT contrato FROM db_business WHERE vlr_faturamento > 5.000;
Ao saber os mínimos e máximos de algumas colunas a consulta, ao invés de testar todos os valores da tabela, salta para a parte mais próxima do valor informado, reduzindo o custo computacional.
No Databricks, por padrão, o Delta Lake coleta informações estatísticas das primeiras 32 colunas definidas no seu schema.
Você pode configurar este limite adicionando mais colunas, entretanto quanto mais colunas maior o custo computacional.
Para configurar este limite no databricks utilize a propriedade de tabela:
delta.dataSkippingNumIndexedColsAlém desta otimização automática feita pelo Delta Lake você pode, de forma explícita, indicar 1 ou mais colunas que:
- – São utilizadas com maior frequência
- – Que tenham alta cardinalidade
- – Que não tenha sido utilizadas como partição
para ser utilizada como referência para realização de “Data Skippings”. O comando para realização desta técnica de otimização é o tão famoso “Z-ordering”.
Ainda não conhece o Z-Order? Quer entender melhor o seu funcionamento e como utilizar este recurso? Nós preparamos um artigo/tutorial específico sobre esta técnica que você poderá ler bem aqui.
Schema Evolution e Garantia de Schema
Ao longo do tempo o schema do seu conjunto de dados pode ser atualizado, com a exclusão de colunas ou inclusão de novas por exemplo.
O Delta Lake consegue realizar mudanças no schema de uma tabela de forma transacional, mantendo um histórico das atualizações de schema no Log Transacional, isto permite o uso de Parquet’s antigos sem precisar reescrevê-los.
Ou seja, um schema de dados será armazenado no Log transacional fazendo com que arquivos antigos sejam lidos seguindo este novo schema e também forçando que novas cargas, inserts, sigam e respeitem este no schema estabelecido.
Em um “Data Lake” tradicional seguimos o conceito de gravar primeiro e estabelecer o schema apenas no momento da leitura (Schema on Read). Isto causa uma série de problemas de confiabilidade no nosso conjunto de dados, já que uma carga de dados poderia ter sido executada considerando os tipos de dados de uma forma e outra carga poderia ter sido executada considerando os tipos dos dados de outra forma.
O Delta Lake resolve este problema de confiabilidade forçando cargas de dados a respeitarem um schema estabelecido no momento de escrita, assim como ocorrem em bancos relacionais. Se o novo insert não respeitar o schema pré definido ( colunas, nomes e tipos) será lançado um erro.
Operações UPSERT, DELETE e MERGE
Como comentado no último subtítulo, através do Delta Lake conseguimos evoluir ou atualizar o schema de nossas tabelas, entretanto, no dia a dia estamos interessados não somente em poder modificar e atualizar o schema de nossas tabelas, mas também em atualizar os registros dela.
Em bancos de dados comuns conseguimos através de SQL executar transações como UPSERT ( update or insert ), DELETE e MERGE, no entanto quando lidamos com sistemas de arquivos distribuídos, utilizando Parquet por exemplo, este tipo de transação se torna um pouco mais difícil de gerenciar.
Vários processos escrevendo ou sobrescrevendo uma tabela ao mesmo tempo podem ocasionar diversas falhas e problemas de integridade, como por exemplo resultados de consultas estarem incompletas, quando executadas ao mesmo tempo do processo de escrita
No Delta Lake todas estas operações conseguem ser realizadas de forma transacional garantindo a atomicidade e resistência a falhas esperadas, assim como em SQL.
Time Travel
Permite aos usuários viajar entre diferentes versões (snapshots) da tabela, seja apenas para verificar alguma versão histórica da tabela ou simplesmente voltar ao último estado íntegro da tabela depois de realizar algum update ou insert errado.
Os objetos em um Data Lake geralmente são imutáveis, ou seja, se algo foi subscrito não será possível retornar ao estado anterior sem um backup ou redundância. Utilizando a camada Delta cada novo estado da tabela é armazenado em um log transacional, gerando uma nova versão.
Imagine que você acabou de criar e carregar uma tabela no Delta Lake. No log transacional será registrado este processo como versão 1, por exemplo.
Agora imagine que você precisou realizar um UPDATE nesta mesma tabela, no arquivo de log será registrado esta transação e a nova tabela será registrada como versão 2.
Ao constatar que o update foi realizado de forma incorreta, ou que houve alguma corrupção nos novos dados bastaria recuperar a última versão estável, retornando a versão da tabela antes do update.
-- Listando versões da tabela
DESCRIBE HISTORY my_table
-- Perform time travel: voltando a um estado anterior da tabela
SELECT * FROM delta.`/my_location/my_folder/my_table` VERSION AS OF 1Quer saber tudo sobre como performar “Time travels” em tabelas Delta?
Preparamos um tutorial completo sobre bem aqui.
Manipulação eficiente de processos Batch e Streaming
Um processo Batch é aquele que geralmente você agenda para ser executado sobre demanda ou de tempos em tempos, por exemplo uma nova carga de dados em algum Data Warehouse, a geração de uma nova fatura para a área de faturamento, envio de relatórios mensais, semanais etc.
Já um processo Streaming é aquele que você deseja que seja executado quase em tempo real, por exemplo: um processo de pedidos em um e-commerce – Um novo pedido pode ser realizado a qualquer hora do dia, ou em horário comercial, nestes casos seu processo poderia ficar ligado online, recebendo e tratando novos pedidos a medida que forem sendo realizados.
É muito natural que sua empresa precise dos dois tipos de processo, e para isso deveria-se criar dois diferentes pipelines.
Talvez para o processo de Streaming você precise utilizar algum serviço de mensageria como o Apache Kafka ou Rabit MQ, e talvez para o seu processo Batch você precise utilizar alguma ferramenta de schedulagem (agendamento) como Control-M ou Apache Airflow.
Tabelas Delta são otimizadas e preparadas para suportar este dois tipos de processo em um único fluxo porque:
- – De forma nativa, sua forma de escrita já é otimizada para compactação em pequenos objetos, algo peculiar aos processos de Streaming.
- – Escrever uma única vez – através do log transacional as tabelas Delta garantem uma única key, tratando cada carga de forma independente.
- – O log transacional também torna fácil a tarefa de cada Consumer em ler e encontrar novos registros na tabela.
Ou seja, a camada Delta possibilita que você execute os dois tipos de processo em um único pipeline.
Log de Auditoria
O log transacional do Delta Lake pode ser utilizado para auditoria dos diferentes estados e versões que sua tabela já assumiu.
No Databricks somente o motor de execução pode escrever neste Log garantindo assim a confiabilidade das informações para auditoria nos logs.
Seguindo as melhores práticas do mercado, o log transacional ou de auditoria tem evoluído constantemente se adaptando a diferentes tipos de regulações.
Conclusão:
Neste arquivo você pode ter uma breve e completa introdução ao conceitos do Delta Lake. Estamos desenvolvendo uma série de outros artigos se aprofundando um pouco mais em tópicos como Databricks, Delta Lake e suas funcionalidades, por isso esperamos que você possa sempre estar recebendo nossas atualizações.
Cloud computing assim como qualquer área do nicho de tecnologia está sempre em constante mudança e aperfeiçoamento, por isso nossa motivação é poder compartilhar através deste blog conteúdo que possa lhe ajudar a se manter atualizado sobre o mundo de Ciência de dados
Referencias:
Paper: Delta Lake: Hight-Performance ACID Table Storage over Cloud Object Stores
Blog: Diving Into Delta Lake: Unpacking the transation Log
