29 de mai. de 20239 min de leitura

Databricks - Delta Lake - Versões, Protocolos, Features, Upgrade e mais

Fala dataholics, hoje falaremos sobre Delta Lake e algumas particularidades importantes para o nosso dia a dia, seja você um engenheiro de dados ou entusiasta por Delta Lake.

Estou falando desse tema, pois, vários dos meus posts fazem referências a versão do Delta, protocolo de leitura e escrita (MinReaderVersion\MinWriterVersion), acho interessante entendermos esses pontos, tentarei ser objetivo e dar exemplos práticos, por ser um tema relativamente complexo em alguns trechos.

O que veremos nesse post:

Delta Lakehouse
Versões (Databricks Runtime, Spark e Delta Lake) e Upgrade (Downgrade?)
Delta lake protocolos e comportamentos (Readers e Writers)
Table features - Vamos ver na prática
Microsoft Fabric Onelake?
Considerações finais
Referências, muitas referências pra voce se aprofundar

Delta Lakehouse

O termo Lakehouse se popularizou em 2020, mas suas engines já estavam em desenvolvimento alguns anos antes.

O Apache Hudi teve sua primeira release publicada no Github em junho de 2017.

O Delta Lake com sua primeira release no Github em abril de 2019.

O Apache Iceberg chega em outubro de 2019.

Cada uma delas com suas características e com seus próprios criadores, o Apache Hudi criado dentro da Uber, Delta Lake criado pela Databricks e o Iceberg criado pela Netflix.

Mas todos com algo em comum, trazer características de SGBDs e features dos tradicionais Data Warehouses (DW) para dentro do Data Lake, unificando assim o Data Lake com features de um Data Warehouse, nascendo então o termo Lakehouse.

O Delta Lake é open source e você pode usá-lo com qualquer engine que consiga interpretá-lo, a engine nativa é o Apache Spark.

Como ele foi criado pela Databricks, muitas features nascem dentro da própria Databricks, exclusiva para clientes no primeiro momento, mas algumas delas são disponibilizadas para a comunidade, isso acelera muito a evolução do Delta Lake.

Desde 2019 já tivemos mais de 20 releases do Delta Lake com melhorias e novas features, então você precisa ficar olho para acompanhar essa rápida evolução.

https://github.com/delta-io/delta/releases

Bom, contado essa história, nosso foco aqui é falar mais sobre o Delta Lake, não em detalhes técnicos do funcionamento (ainda não), mas sim do comportamento das suas versões, features, modos de compatibilidade e como fazer upgrade das nossas tabelas Delta.

Versões (Databricks Runtime, Spark e Delta Lake)

Precisamos separar algumas coisas aqui, pois, quando estamos no Databricks pode gerar uma certa confusão, para cada Cluster temos a versão do Databricks Runtime, ela engloba praticamente tudo, exemplo, versão do python, Delta Engine, Spark, Scala e outros. Logo a versão do Databricks Runtime é muito importante para saber qual versão do Spark e Delta engine você esta rodando.

Essa imagem abaixo mostra a evolução da engine Delta com a versão do Apache Spark, logo se você utiliza Spark no seu ambiente deve seguir essa tabela de referência. Significa que se você utiliza Spark 3.2, a versão da sua Delta Engine será 2.0 ou inferior.

Observação: Já temos a 2.4 lançada em maio de 2023 (vulgo esse mês rs)!

https://docs.delta.io/latest/releases.html

Ah Reginaldo, mas uso Databricks, como posso saber a versão da Delta Engine?

Pela versão do Databricks Runtime configurada no seu Cluster é possível saber qual versão do Apache Spark você esta trabalhando.

https://learn.microsoft.com/en-us/azure/databricks/release-notes/runtime/releases

Você pode consultar essa informação na interface gráfica do cluster ou via linha de comando:

Consultando na tela grafica do cluster:

Você pode abrir a pagina de documentação da versão do Databricks Runtime que seu cluster está operando e olhar na sessão "System Environment".

Exemplo Databricks Runtime 12.2, temos a versão do Delta 2.2.0.

https://docs.databricks.com/release-notes/runtime/12.2.html#system-environment

Resumindo, a versão do Delta lake esta atrelada a versão do Apache Spark que está atrelada ao Databricks Runtime, logo se você quiser atualizar a versão do Delta do seu ambiente Databricks, basta fazer o Upgrade do seu Databricks Runtime.

Evolução do Delta

Mas o que muda em cada versão do Delta Lake?

Muda muita coisa, muitas melhorias e correções são aplicadas, você pode acompanhar com mais detalhes na página do Github.

Em geral, essa tabela abaixo mostra a evolução das features do Delta lake para cada Runtime do Databricks.

Isso quer dizer que se você estiver no Databricks Runtime inferior a 12.1, você não consegue utilizar TimestampNTZ, a qual é uma feature do Databricks Runtime 13.0.

Essa tabela abaixo mostrei em uma palestra que realizei sobre Delta Lake, tentei resumir o máximo possível com alguns highlights, pode ter faltado algo importante em alguma Release.

Contudo, ela reflete bem que de 2019 até o momento, estamos acelerados, com várias releases por ano, em 2022 tivemos muitas melhorias e novidades na engine.

Se olhar a linha do tempo, são mais de 20 releases com melhorias, correções de bugs e novas features todos os anos, é uma evolução muito rápida comparado a um SGBD tradicional, que geralmente solta apenas patches para fix, mas releases com novas features são em tempos maiores, geralmente em anos, exemplo o SQL Server.

A "minha" recomendação sobre implementação de novas versões e features é: Espere um tempo antes de aplicar em todo seu ambiente, aplique em ambientes de Dev e teste bastante, se você aplicar logo que a versão sair, esta sempre sujeito a sofrer com novos Bugs, é algo que faço com qualquer ferramenta, estudo o impacto, aguardo pelo menos 1 ou 2 meses, aplico em Dev, espero mais um pouco, aí planejo a subida para produção.

Como você pode ver, existem releases com intervalo de 1 mês de diferença, mas siga a estratégia que achar melhor e conforme a necessidade.

Delta lake protocolos e comportamentos (Readers e Writers)

Você já deve ter visto por aí sobre os protocolos e versões de leitura e escrita, inclusive nos meus posts, citado como MinReaderVersion e MinWriterVersion, mas o que de fato isso significa?

Quando você roda um Describe Extended ou um Describe Detail na sua tabela Delta, você consegue ver esses marcadores minReaderVersion e minWriterVersion.

Existe um pouco de complexidade por detrás dessas versões e protocolos, mas minha ideia aqui é simplificar e deixar referências para você se aprofundar se quiser.

Basicamente o protocolo é dividido em dois, Leitura (Reader) e escrita (Writer), para definir quais features aquela tabela possui (ou pode vir a ter, não necessariamente está implementada) e qual é a versão mínima que o client (aplicação\ferramenta) que esta lendo a tabela precisa ter.

Ou seja, o protocolo define o comportamento da leitura ou da escrita em uma Delta Table, exemplo, se uma tabela com a feature Deletion Vector aplicado o MinReaderVersion será 3, isso é para indicar ao leitor (aplicação, seja spark ou outros) dessa tabela que ele precisa saber interpretar todas as features da versão de leitura 3, caso contrario eles poderão não entender os dados, pois, ele não saberá que existe um arquivo bitmap para ler nesse caso do Deletion Vector.

Logo uma ferramenta que esta lendo as tabelas Delta, precisa respeitar o minReaderVersion, assim como uma ferramenta que esta gravando em uma tabela Delta precisa respeitar o minWriterVersion.

Exemplo de ferramenta, Azure Synapse Serveless, ele pode ler tabelas Delta, mas se sua tabela estiver na minReaderVersion 3 com Deletion Vector ele não conseguirá interpretar, pois ele está preparado apenas para a funcionalidades básicas do minReaderVersion=1.

Esse é um cuidado que você precisa ter ao fazer upgrade das suas tabelas ou aplicar alguma feature nova, pois, a versão do protocolo de leitura e escrita serão atualizados, e alguma aplicação pode parar de funcionar.

Em geral, quem usa só Spark (Databricks ou outras plataformas) não precisa se preocupar tanto com isso, pois, o Spark esta preparado para tratar esses casos, caso esteja com a versão equivalente, agora se você usa outras ferramentas como Synapse, Dremio, Power BI entre outras ferramentas que podem ler e escrever na sua tabela, você precisa fazer uma análise delicada antes de aplicar Upgrade em uma tabela Delta, pois, o upgrade é irreversível, ou seja, não existe Downgrade.

Essa é a tabela de features por protocolo de leitura e escrita:

O protoco de leitura e escrita pode ser atualizado automaticamente ao implementar uma nova feature, exemplo o Deletion Vetor irá atualizar sua tabela para Writer 7 e Reader 3.

Ou voce pode planejar atualizar manualmente, lembrando que precisa seguir essa tabela, uma versão que voce subiu seu WriterVersion para 7, o ReaderVersion precisa ser 3, isso é um problema que será resolvido com o Table Features mais abaixo.

Quer um exemplo prático, o melhor caso é com o Deletion Vector, se você notou no meu último post, o Deletion Vector adiciona novos atributos ao Transacion Log, logo se a versão do Delta que você esta utilizando para ler não souber interpretar que existe um bitmap marcando quais linhas foram excluídas do Parquet, sua aplicação lerá dados errados, por isso, a minReaderVersion é atualizada para 3, fazendo com que aplicações que utilizam protocolos inferiores tomem erros, para não ler dados incorretos.

Veja nessa imagem, imagine que você esta lendo essa tabela com o Synapse Serveless, ele não está preparado para entender que existe esse novo atributo, para isso o procolo de leitura indica que apenas ferramentas que suportam o minReaderVersion = 3 podem ler essa tabela.

Estou tentando ser simplista, espero que esteja fazendo sentido pra voce, se não fizer sentido agora, tenha calma, em algum momento vai fazer.

Resumo do protocolo, ele serve para indicar quais features aquela tabela pode ter e qual a versão mínima do Delta uma ferramenta deve ter para poder ler ou escrever na tabela.

Basicamente ele é um agrupamento das features de leitura e escrita, para atualizar a versão do protocolo e utilizar novas features, exemplo usar o Change Data Feed, você precisa fazer upgrade para versão de escrita 4.

-- Upgrades the reader protocol version to 1 and the writer protocol version to 4.
ALTER TABLE tb_teste SET TBLPROPERTIES('delta.minReaderVersion' = '1', 'delta.minWriterVersion' = '4')

A partir desse momento, só podem escrever nessa tabela, ferramentas que estão no minWriterVersion=4 e sua respectiva versão da Delta Engine atualiza, de acordo com a tabela de Databricks Runtime e features por versão.

Protocolo vs Table Features

Se tava difícil entender o comportamento dos protocolos, agora vamos bagunçar ainda mais sua mente rsrs.

A partir do Databricks Runtime 12.1 e Delta 2.3.0 temos a chamada Table Features, ela veio para facilitar a nossa vida e esquecer tudo que expliquei sobre protocolos rs.

Até as versões anteriores quando precisamos fazer o Upgrade de uma tabela, precisamos fazer por protocolo, elevando o minReaderVersion e minWriterVersion para suportar um grupo de features.

Exemplo que dei do CDC, precisei dar upgrade da minWriterVersion para 4, nessa versão temos tambem a feature Generated Columns, embora eu não vá utilizar essa feature, ela esta disponivel, ja que a versão do protocolo é a mesma e as ferramentas que forem ler essa tabela precisam estar preparadas para entender o Generated Columns, mesmo que não vá usar.

O Table Features resolve esse problema, ele vai indicar quais features de fato estão em uso naquela tabela, então as ferramentas que leem ou escrevem, só validam se elas entendem aquelas features que estão flegadas.

Vamos pra prática pois, esta ficando chato ne? rs

O meu Databricks Runtime esta na versão 12.1

Vamos criar uma tabela básica e consultar sua versão.

Agora vamos criar uma tabela para aplicar o CDF (Change Data Feed).

Note que o CDF ainda não esta habilitado, mas qualquer ferramenta que for escrever precisa entender que todas as features do minWriterVersion 4 estão aplicadas nessa tabela, mesmo que não estejam.

Agora criando uma tabela com CDF já habilitado, note que agora já flegou o CDF.

Agora vamos criar uma tabela para usar o Deletion Vector, nada de novo aqui.

Habilitando de fato o Deletion Vector, ele ja marca um flag na tabela.

'delta.feature.deletionVectors' = 'supported'

Só para curiosidade, tentando usar uma feature do Databricks Runtime 13.0, no meu cluster com Runtime 12.1:

Tomamos erro, pois a versão do Delta dentro do Runtime 12.1 ainda não tem essa feature.

Tentando fazer um Downgrade, como vimos, é sem volta.

Troquei a versão do Databricks Runtime para 11.3 e vou tentar ler a tabela com Deletion Vector:

Não da! Então tome cuidado ao implementar novas features ou fazer upgrade das suas tabelas Delta, garanta que todos os leitores e escritores suportem aquela versão.

Por fim, habilitando uma feature ja no modelo de Table Features:

Note que estou informando que ela é suportada, não necessariamente esta em uso.

Em resumo, o Table Feature nos permite informar quais features de Leitura e Escrita aquela tabela possui, facilitando a vida das ferramentas que utilizam delta table, melhorando a flexibilidade.

Note que agora vamos trabalhar com flags e não mais com protocolo, apesar dele ainda ser importante nesse momento.

Fabric Onelake?

Com o lançamento do Microsoft Fabric o Linkedin foi a loucura (inclusive eu rs).

Uma das features apresentadas pelo Fabric foi o OneLake, que vem com a promessa de unificar tudo em um unico local, a ideia é brilhante.

https://blog.fabric.microsoft.com/en-us/blog/microsoft-onelake-in-fabric-the-onedrive-for-data/

Muitas dúvidas ainda estão precisando de respostas, mas, uma coisa é fato, o Databricks e Delta Lake tem seu lugar nesse novo mundo.

O Databricks ja tem um conector para OneLake, então você poderá continuar utilizando seu Databricks e com todas as vantagens que o OneLake tras pra gente.

Outro ponto muito importante, o OneLake utilizara Delta Lake por padrão, citado como Delta parquet format, o que causou bastante intriga no Linkedin também rs, pois, o Delta armazena os dados em arquivos Parquet, mas mágica está na sua Engine de processamento.

Uma doc interessante com mais detalhes no Github:

https://github.com/MicrosoftDocs/fabric-docs/blob/main/docs/onelake/onelake-open-access-quickstart.md

Escrevi esse post para ficar como referência de outros que ainda irei escrever, como sempre estou falando de novas features, referenciando questões sobre Upgrade, versões e protocolos, usarei esse post como referencia, sei que ele ficou um pouco massivo, mas tenho certeza que quem leu tudo, vai sair com muitos insights e sabendo um pouquinho mais de quando iniciou o post.

Meu objetivo é que você sempre saia sabendo um pouquinho mais, voce pode ter certeza que ao final do ano lendo todos os meus posts voce será um profissional fera em Delta Lake e Databricks.

Espero que tenha gostado.

Fique bem e até a próxima

Link dos scripts: