Fala dataholics, nesse último post do ano de 2023 falaremos um pouco sobre o Lakehouse federation e como podemos nos beneficiar dessa incrível funcionalidade.
O Lakehouse Federation é uma feature que está em Public Preview, mas que tem um potencial enorme, no artigo de hoje trarei algumas visões bem legais, como, cruzamento de informações entre Databricks, Bigquery, SQL Server e PostgreSQL na mesma consulta SQL, sensacional não é?!
O que veremos nesse post:
O que é
Como funciona
Outras ferramentas similares (Drêmio)
Pontos fortes e fracos
Conceito de Zero ETL
Diferença entre Lakehouse Federation vs Query Federation vs External Table
Limitações
Bora pra prática
Fazendo JOIN com PostgreSQL, SQL Server, Bigquery e Databricks
Resumo e caso de uso
O que é?
Databricks lakehouse federation é uma feature de federação de consultas que permite aos usuários e sistemas executar consultas contra várias fontes de dados sem a necessidade de migrar todos os dados para um sistema unificado.
Aqui você elimina a necessidade de criar ETLs complexos, aplicar CDC, SCD, entre outras técnicas, e ainda correr o risco dos dados ficarem diferentes da origem, isso pode ser muito útil para vários cenários.
Podemos traduzir federation ou federação na tradução literal como uma forma de democratizar o acesso dos dados de diversas fontes utilizando uma única plataforma, delegando o trabalho de processamento para as origens, nesse contexto a federação de proporciona a possibilidade de agilizar a exploração de dados, evitar duplicação de storage entre outros benefícios.
Como funciona?
O Databricks lakehouse federation usa o Unity Catalog para gerenciar a federação de consultas. Para usar o Databricks lakehouse federation, você precisa configurar conexões de leitura usando os drivers incluídos nativamente nos Clusters do tipo Pro SQL Warehouses, Serverless SQL Warehouses e Databricks Runtime >=13.1, as fontes atuais são:
MySQL
PostgreSQL
Amazon RedShift
Snowflake
SQL Server
Azure Synapse
Google Bigquery
Databricks (Com outros workspaces)
Basicamente o Databricks utilizando os drivers nativos como o JDBC envia as consultas para execução banco de dados origem e retorna os dados (resultados) para o Databricks em tempo real.
Outras ferramentas similares
O Databricks lakehouse federation é semelhante a outras ferramentas de federação de consultas, como Snowflake Data Sharing, Google BigQuery External Data e Amazon Redshift Spectrum. No entanto, cada ferramenta tem seus próprios pontos fortes e fracos, o Lakehouse federation tem um grande benefício de estar integrado ao Databricks e ao Unity Catalog, então você pode ter todo controle e governança das fontes de dados conectadas.
Outra ferramenta que faz muito bem esse papel e possui diversas vantagens e features de performance é o Dremio, essa ferramenta ganhou o mercado de federação de consultas pelas suas features de performance avançada com diversas fontes de dados.
Pontos fortes do lakehouse federation:
Agilidade: permite que você execute consultas contra dados de várias fontes (citadas acima) sem a necessidade de migrar os dados, o que pode economizar tempo e recursos.
Escalabilidade: pode ser usado para conectar-se a fontes de dados de qualquer tamanho, um ponto aqui é que você pode delegar o processamento para a origem.
Governança: usa o Unity Catalog para gerenciar a governança de dados, o que ajuda a garantir que seus dados sejam seguros e confiáveis.
Pontos fracos:
Pode ter um desempenho inferior aos métodos tradicionais de ETL, pois os dados não são movidos para um sistema unificado, logo, você precisa pagar o preço da latência de rede e pode ter problema de performance, pois, nem todos os filtros e funções conseguem ser enviados para a origem, o famoso pushdowns.
Se você estiver apontando para seus ambientes OLTP de produção, também tem o risco de onerar a performance das suas origens, diferente de ETLs mais pontuais ou o uso de CDC para coleta dos dados.
Conceito de Zero ETL
A federação de consultas correlaciona com o tema de Zero ETL, que é a ideia de que você não precisar migrar dados para um sistema de dados unificado (Data Lake) para poder analisá-los, com a ideia de não precisar mais do famoso ETL (Extract, Transform e Load) ou ELT(Extract, Load e Transform), ao invés de extrair os dados das fontes, você faz a consulta direto nelas. O Lakehouse Federation permite que você execute consultas contra dados de várias fontes sem a necessidade de copiar os dados para um Data Lake, o que pode auxiliar as organizações a alcançar o Zero ETL e mais agilidade nas entregas de dados para o negócio.
Um cara que faz isso bem legal é o Azure Synapse Analytics que pode conectar em fontes como Azure SQL Server e Azure Cosmos DB diretamente sem necessidade de ETL, usando o Synapse Link, ele consegue fazer consultas direto no Cosmos DB sem concorrer com os processos de produção e consultando os dados em formato colunar, vale a pena dar uma olhada.
Diferença entre Lakehouse Federation vs Query Federation vs External Table
Você pode estar se perguntando, mas Reginaldo, isso já não existia?
As External tables você continuara usando para apontar para dados em arquivos no Storage, como CSV, JSON, PARQUET, DELTA etc.
Nesse caso as External Tables não servem para conectar em SGBDs como SQL Server e PostgreSQL.
O Query Federation é o antecessor do Lakehouse federation, inclusive ele esta sendo considerado Legado, isso mesmo, a recomendação a partir de agora será utilizar o Lakehouse federation.
A grande diferença entre eles é que o Query Federation você precisava criar e configurar a conexão para cada tabela, já o Lakehouse federation você cria uma conexão com o banco de dados todo e pode consultar todas as tabelas, totalmente integrado ao Unity Catalog.
Limitações
É bom ficar de olho nas limitações, algumas coisas importantes:
As conexões são apenas leitura
Pushdowns - Nem todos os pushdowns são suportados, isso varia de cada origem
Data Types, fique de olho nas tabelas de DEPARA entre a origem e o Databricks
Não suporta nomes com case-sensitive, ou seja, tudo ficara como Lower Case, aqui você pode encontrar alguns problemas dependendo da origem
Fique de olho nas limitações de cada origem, pois, tem limitações diferentes
Feito todo esse resumão, vamos para a prática agora né, melhor do que falar é fazer.
Antes de criarmos o ambiente, temos 2 componentes principais:
Connection (Conexão): Uma conexão com o banco de dados, utilizando um usuário e senha ou service account
Foreign Catalog (Catalogo Estrangeiro): Um catálogo no Unity Catalog que aponta para o banco de dados de origem, ele conterá todos os schemas e tabelas da sua origem
O nosso ambiente será composto por 4 conexões diferentes, na mesma query SQL cruzaremos informações de diversas fontes de dados em tempo real.
Criaremos nossas conexões, vá à aba de gestão de conexões no seu ambiente.
Aqui as minhas conexões já estão criadas, mas para criar uma nova, basta clicar em Create Connection:
De um nome para sua conexão e escolha entre as fontes de dados disponíveis:
Cada tipo de conexão tem suas particularidades, então se atente as configurações de cada ambiente.
Após criado a conexão, criaremos o foreign catalog, basta ir na tela inicial de catálogos e clicar em Create catalog.
Na criação selecione o tipo Foreign, irá aparecer uma lista com as suas conexões já criadas, importante o campo Database precisa ser o mesmo nome do seu Database na origem.
Após criado, você já pode navegar pelo seu catalogo e ver as tabelas na origem como se elas estivessem dentro do Databricks, mas lembre, qualquer query executada contra elas, será disparado para as origens em tempo real, tome cuidado para não onerar as suas origens.
Note que na navegação no catálogo, cada tipo de origem tem uma navegação a nivel de schema ou databases, nesse caso do PostgreSQL, temos o nível de schemas e após selecionar os schemas temos as tabelas.
Essas são as tabelas do nosso exemplo.
Vejamos o mesmo no SQL Server, Bigquery e Databricks.
SQL Server:
SQL Server tabelas:
Bigquery: Lista de Datasets
Bigquery tabelas:
Databricks: Apontando para workspaces externos (isso é diferente de Delta Sharing)
Note que aqui vejo todos os schemas dentro desse catalogo referenciado na conexão.
Databricks tabelas:
Pronto, já navegamos pelas 4 fontes de dados diferentes, temos 3 tabelas em comum nessas fontes que é Autor, Editora e Livro, faremos algumas queries cruzando dados dessas fontes.
Aqui em um exemplo bem simples, consultei a tabela livro nas 4 origens diferentes, sem precisar copiar dados de um lugar para o outro, sem precisar aplicar regras de transformações ou CDC para replicar alterações na origem.
Agora cruzaremos as 4 fontes na mesma query:
Me diz se isso não é sensacional?
Na mesma query consultamos origens diferentes, com schemas diferentes, sem precisar copiar nada para o nosso Lake, sem todas aquelas complexidades de ETL e CDC, SCD e por aí vai.
E JOINs, funciona? Vamos comparar todos os livros para ver se os títulos estão iguais em todas as origens?
Obvio que cada caso é um caso, não vamos generalizar, estude sobre suas necessidades, estude sobre Zero ETL e veja se faz sentido para o seu cenário, sempre se preocupe com as suas origens, se você esta consultado uma réplica para não onerar o ambiente produtivo entre outros pontos importantes.
O uso de JOINs pode prejudicar a performance e evitar os Pushdonws, então use com moderação.
Resumo
O Databricks lakehouse federation é interessante para casos de uso como:
Você não deseja ingerir dados no Databricks.
Você deseja que suas consultas aproveitem o processamento de computação no sistema de banco de dados externo.
Você quer utilizar as vantagens de governança de dados do Unity Catalog, incluindo controle de acesso granular, linhagem de dados e pesquisa e centralizar tudo num único lugar, mas economizando com storage e processamento.
Como já citado nos pontos fortes e fracos, embora você economize com Storage (duplicação de dados entre origem e Lake) e economize com processamento de clusters, pois acaba delegando trabalho pesado pra origem, você precisa estudar cada caso de uso, sempre considerando o ponto de não prejudicar suas origens com queries frequentes e pesadas, em alguns casos não otimizadas devido às limitações de pushdown.
Estou testando em um caso de uso para validação de indicadores, exemplo, temos todo nosso ETL\ELT para o Lakehouse, com suas modelagens e transformações, e para validar se os dados estão íntegros com a origem, estou usando o Lakehouse Federation para consultar a origem pontualmente e validar se os dados estão batendo.
Está sendo bastante útil e eficiente para esses cenários, inclusive para exploração de dados antes de começar os processos de ELT para o Lake.
Bom é isso, quer saber mais sobre, leia todas as documentações disponíveis e teste bastante, entenda o caso de uso e avalie se é interessante para o seu cenário.
Fique bem e até a próxima.
Um Feliz Natal e próspero ano novo, que 2024 estejamos juntos aqui novamente aprendendo coisas novas.