Skip to content

Explorando a Lakehouse Federation: Acesso Unificado a Dados

E se os dados não puderem se mover — mas a análise não puder esperar?

Essa foi a pergunta que abriu nossa sessão de maio na Comunidade de Usuários Databricks do Espírito Santo. Um cenário que qualquer arquiteto de dados já enfrentou: dados espalhados em SQL Server, Snowflake, PostgreSQL, BigQuery — cada um com sua governança, cada um com seu time — e uma demanda de análise que precisa cruzar tudo isso.

A resposta do Databricks para esse problema chama-se Lakehouse Federation.

O problema real: dados espalhados, governança fragmentada

Antes de entrar na solução, é importante nomear o problema. Em organizações maduras, os dados raramente vivem em um único lugar. É comum ter:

  • Sistemas transacionais em SQL Server ou Oracle
  • Analytics em Snowflake ou Google BigQuery
  • Data Lakes em OneLake (Microsoft Fabric) ou Amazon S3
  • Dados históricos ainda no Hive Metastore

Quando alguém precisa cruzar essas fontes, a resposta tradicional é copiar dados — criar pipelines ETL que movem tudo para um único repositório. Isso funciona, mas tem um custo: latência, infraestrutura duplicada, e o pior de todos — governança duplicada.

O Lakehouse Federation propõe uma abordagem diferente: a query vai até os dados, não o contrário.

O que é Lakehouse Federation?

Lakehouse Federation é a plataforma de federação de consultas do Databricks. Em vez de mover ou replicar dados, ela permite executar queries em fontes externas diretamente, com o Unity Catalog como ponto único de governança.

Existem dois mecanismos distintos, cada um com características próprias:

Federação de Consultas

Unity Catalog → JDBC → fonte externa

A query é enviada via JDBC para o banco de dados externo. A execução acontece tanto na computação do Databricks quanto na computação remota da fonte. Ideal para:

  • Acesso ad hoc a dados operacionais
  • Provas de conceito em sistemas transacionais
  • Relatórios que precisam de dados ao vivo
Unity Catalog → acesso direto ao storage

Sem intermediário JDBC. A computação Databricks acessa diretamente o armazenamento de objetos. É mais eficiente em custo e performance, e a execução fica totalmente sob controle do Databricks. Ideal para:

  • Migração incremental de Hive Metastore para Unity Catalog
  • Modelos híbridos de longo prazo
  • Dados no OneLake, Snowflake ou AWS Glue

Comparação direta: quando usar cada abordagem

Federação de Consultas Federação de Catálogo
Caminho Unity Catalog → JDBC → banco externo Unity Catalog → storage direto
Execução Databricks + computação remota Apenas computação Databricks
Custo relativo Maior Menor e mais performático
Performance Dependente da fonte remota Controlada pelo Databricks
Casos de uso Relatórios ad hoc, PoC, sistemas transacionais Migração incremental, modelo híbrido de longo prazo

Fontes suportadas

Federação de Consultas (via JDBC)

MySQL, PostgreSQL, Teradata, Oracle, Amazon Redshift, Snowflake, SQL Server, Azure Synapse, Google BigQuery, Databricks e Salesforce Data Cloud.

Federação de Catálogo (acesso direto ao storage)

  • Databricks — Hive Metastore legado e metastores externos
  • Salesforce Data Cloud — federação via file sharing (arquivos Parquet)
  • Snowflake — navegação de tabelas Snowflake dentro do Unity Catalog
  • Microsoft Fabric / OneLake — acesso ao Fabric Lakehouse e Fabric Warehouse (Preview Público)

Destaque do evento: OneLake Federation em Preview Público

O tema que gerou mais discussão na sessão foi justamente o suporte ao Microsoft Fabric OneLake como catálogo federado — uma novidade ainda em preview público que posiciona o Databricks como plataforma multi-cloud de primeira classe.

O que é possível hoje:

  • Fabric Lakehouse e Fabric Warehouse: ambos os tipos de itens de dados do Fabric são suportados
  • Acesso somente leitura: governança preservada — dados do Fabric não podem ser modificados via Databricks
  • Dados não estruturados via Volumes: arquivos da pasta /Files do Lakehouse ficam acessíveis como Unity Catalog Volumes
  • Requisito de runtime: Databricks Runtime 18.0+ ou SQL Warehouses 2025.40+

Como configurar: OneLake Federation em 5 etapas

-- Etapa 1: Autenticação
-- Use Azure Managed Identity (Access Connector) ou Service Principal

-- Etapa 2: Permissões no Fabric
-- Role "Member" no workspace do Fabric é obrigatória

-- Etapa 3: Storage Credential
-- Registrar identidade no Unity Catalog

-- Etapa 4: Criar a conexão OneLake
CREATE CONNECTION onelake_conn
TYPE onelake
OPTIONS (
  workspace '<workspace-id>',
  credential 'onelake_storage_cred'
);

-- Etapa 5: Criar o catálogo estrangeiro
CREATE FOREIGN CATALOG fabric_sales
USING CONNECTION onelake_conn
OPTIONS (data_item '<data-item-id>');

Uma vez configurado, as queries usam a notação de 3 partes padrão do Unity Catalog:

-- Consulta a tabelas Delta do Fabric
SELECT customer_id, customer_name, total_purchases
FROM fabric_sales.silver.customer_details
WHERE total_purchases > 1000
ORDER BY total_purchases DESC;

-- Acesso a dados não estruturados via /Files
LIST '/Volumes/fabric_sales/onelake-folders/files/';

-- Leitura direta de Parquet
SELECT *
FROM parquet.`/Volumes/fabric_sales/onelake-folders/files/data.parquet`;

Governança via Unity Catalog. Sem replicação. Sem pipeline extra.

Limitações que todo arquiteto precisa conhecer

Trabalhar com tecnologia em preview exige honestidade sobre o que ainda não é possível:

  • Somente leitura — apenas SELECT, sem escrita, update ou delete em fontes federadas
  • Tipos complexos não suportados — arrays, maps e structs não funcionam em federação de catálogo
  • Views não expostas — views e materialized views não aparecem como tabelas federadas
  • Modo de acesso Standard — não funciona em clusters no modo dedicado (single-user)
  • Fabric requer 3 configurações de tenant — o admin do Fabric precisa habilitar permissões específicas antes de ativar a OneLake Federation

"Conhecer os limites é parte do design de solução."

Guia de decisão: qual abordagem usar?

Cenário Abordagem Recomendada
Acesso ad hoc a banco operacional (SQL Server, Oracle, PostgreSQL) Federação de Consultas via JDBC
Migração incremental de Hive Metastore ou Snowflake para Unity Catalog Federação de Catálogo
Dados no Microsoft Fabric / OneLake com análise no Databricks OneLake Federation (Preview)
Alta performance com grandes volumes e SLA rigoroso Considere Lakeflow Connect (ingestão completa + ETL gerenciado)

"A escolha certa depende do padrão de acesso, não da tecnologia disponível."

Sobre o evento

O evento "Explorando a Lakehouse Federation: Acesso Unificado a Dados" aconteceu em 8 de maio de 2026, das 10h30 às 12h, com diversos participantes confirmados. Faz parte da série de encontros mensais do Databricks User Group Espírito Santo, organizado em parceria com a Datasource Expert.

Se você perdeu ao vivo, a gravação completa está disponível no link acima.

Próximos passos

E você? Já usa federação de dados na sua arquitetura? Compartilhe nos comentários como resolve o problema de dados distribuídos no seu contexto.

Comments