Se você trabalha com dados na plataforma Azure, provavelmente já notou que o nome Databricks aparece em quase todo lugar. Não é coincidência. Por quase uma década, Microsoft e Databricks construíram uma das parcerias mais relevantes do ecossistema de dados em nuvem — e em 2025 e 2026, essa relação deu um salto qualitativo significativo.
Neste artigo, vou explorar em profundidade o que essa parceria significa na prática: o que mudou, o que ficou igual, os pontos positivos, os pontos de atenção, e principalmente — como funciona tecnicamente a integração entre o OneLake (coração do Microsoft Fabric) e o Databricks. Esse último ponto costuma gerar bastante confusão, e merece uma explicação detalhada.
1. Um Pouco de História
A Microsoft e o Databricks são parceiros desde 2017, quando o Azure Databricks foi lançado como um serviço de primeira linha dentro do Azure — não um produto de terceiros integrado por API, mas algo construído conjuntamente e nativo à plataforma. Essa posição privilegiada rendeu frutos: hoje, o Azure Databricks é amplamente utilizado por empresas que processam grandes volumes de dados no Azure.
A base técnica dessa parceria sempre foi o Delta Lake, o formato de armazenamento aberto criado pelo Databricks. O Microsoft Fabric, lançado em disponibilidade geral em novembro de 2023, adotou o Delta Parquet como formato nativo do OneLake — uma escolha que não foi acidental. Ela criou a fundação técnica para a interoperabilidade que vemos hoje.
Em novembro de 2025, no Microsoft Ignite, as duas empresas anunciaram um aprofundamento formal da parceria, com foco em interoperabilidade bidirecional entre o Azure Databricks e o Microsoft OneLake. Em março de 2026, no FabCon — a maior conferência do ecossistema Fabric — os anúncios foram detalhados e alguns já chegaram em preview público.
2. O OneLake Explicado — Shortcut vs. Storage Nativa
Antes de entrar nos detalhes da parceria, preciso destrinchar o OneLake, porque é aí que mora a confusão mais comum. O OneLake é descrito no marketing da Microsoft como uma “data lake lógica unificada” — e essa descrição, embora correta, omite um detalhe importante que muda tudo.
2.1 O OneLake tem dois modos de operação
Modo 1 — Shortcuts (Atalhos Virtuais)
Um Shortcut é um ponteiro para dados que vivem em outro lugar. Você tem arquivos Delta num bucket do GCP? Numa conta S3 da AWS? Num ADLS Gen2 dedicado? O OneLake cria um atalho que aponta para esse local — o dado físico continua onde está, sem cópia, sem movimento, sem ETL.
Isso é especialmente útil para quem já tem dados em outras clouds ou storages e quer enxergá-los dentro do Fabric sem refatorar toda a arquitetura. É o que o marketing da Microsoft mais destaca, e por isso muita gente acaba achando que o OneLake é só isso.
Modo 2 — Storage Nativa (o que muita gente não sabe)
O OneLake também possui uma storage física real. Quando você cria um Lakehouse dentro do Microsoft Fabric, os arquivos são gravados de verdade — em formato Delta Parquet — dentro dessa storage, que roda sobre Azure Data Lake Storage Gen2 (ADLS Gen2). Ela existe fisicamente, tem um endpoint de acesso, e é gerenciada pelo próprio Fabric.
O endereço dessa storage segue o padrão:
onelake.dfs.fabric.microsoft.com/<workspace>/<item>.Lakehouse/Tables
É Azure por baixo, mas abstraído e gerenciado como OneLake. O Fabric cuida de provisionamento, redundância e segurança — você não precisa configurar nada disso manualmente.
| Resumo da distinção Shortcut = ponteiro para dado externo (GCP, S3, ADLS). Storage Nativa = dado gravado de verdade dentro do OneLake, em Azure. Os dois coexistem no mesmo Lakehouse e parecem idênticos para quem consome os dados. |
2.2 Por que isso importa para a parceria com o Databricks?
Porque a pergunta “o Databricks pode gravar no OneLake?” tem respostas diferentes dependendo de qual modo você está falando.
No caso dos Shortcuts, o Databricks continua gravando no seu storage de origem (bucket GCP, S3 etc.), e o OneLake apenas enxerga esse dado via ponteiro. Não há gravação no OneLake em si.
No caso da storage nativa, sim — o Databricks consegue gravar diretamente na storage do OneLake. E é aqui que entra o avanço técnico da parceria.
3. Como Funciona a Integração Técnica
O ponto central da parceria de 2025/2026 é a compatibilidade de APIs. O OneLake expõe endpoints que são compatíveis com a API do ADLS Gen2. Para o Databricks, isso significa que o OneLake parece um ADLS Gen2 qualquer — ele não precisa saber que está acessando o Fabric.
3.1 O Protocolo ABFS
O Databricks usa o driver ABFS (Azure Blob File System) para se comunicar com storages Azure. Esse driver fala o protocolo do ADLS Gen2. Como o OneLake expõe a mesma interface, o Databricks simplesmente o trata como mais uma storage Azure.
Na prática, a leitura e escrita acontece assim:
# Leitura de dados do OneLake via Databricks
df = spark.read.format(‘parquet’).load(
f’abfss://{workspace_id}@onelake.dfs.fabric.microsoft.com/{lakehouse_id}/Files/data’
)
# Escrita de dados diretamente no OneLake
df.write.format(‘delta’).mode(‘overwrite’).save(
f’abfss://{workspace_name}@onelake.dfs.fabric.microsoft.com/{lakehouse_name}.Lakehouse/Tables/minha_tabela’
)
Repare: o endpoint começa com abfss:// (Azure Blob File System Secure), exatamente igual ao que você usaria para um ADLS Gen2 convencional. A única diferença é que o domínio aponta para onelake.dfs.fabric.microsoft.com ao invés de <storage>.dfs.core.windows.net.
3.2 Opções de Autenticação
Existem três formas principais de autenticar o Databricks para acessar o OneLake:
- Credential Passthrough: o Databricks usa a identidade do usuário logado. Simples para dev/testes, mas não recomendado para produção.
- Service Principal (OAuth 2.0): recomendado para produção. Você cria um app no Azure AD, concede permissão de Contributor no workspace do Fabric, e configura as credenciais no Databricks via Spark config ou Databricks Secrets.
- dbutils.fs.mount: monta o OneLake como um caminho local (/mnt/…) dentro do Databricks, simplificando o acesso em notebooks.
# Configuração com Service Principal
spark.conf.set(‘fs.azure.account.auth.type’, ‘OAuth’)
spark.conf.set(‘fs.azure.account.oauth.provider.type’,
‘org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider’)
spark.conf.set(‘fs.azure.account.oauth2.client.id’, service_principal_id)
spark.conf.set(‘fs.azure.account.oauth2.client.secret’, service_principal_password)
spark.conf.set(‘fs.azure.account.oauth2.client.endpoint’,
f’https://login.microsoftonline.com/{tenant_id}/oauth2/token’)
3.3 Unity Catalog + OneLake Catalog API
Em março de 2026, no FabCon, a Microsoft anunciou que a leitura nativa do OneLake via Unity Catalog do Databricks entrou em preview público. Isso significa que tabelas criadas em um Fabric Lakehouse podem ser registradas no Unity Catalog do Databricks como external locations — sem mover dados, sem ETL, sem duplicação.
A arquitetura resultante é poderosa:
- O dado vive no OneLake (storage nativa do Fabric)
- O Fabric Lakehouse o governa pelo lado Microsoft (Purview, Direct Lake mode, Power BI)
- O Unity Catalog do Databricks o enxerga como external table
- Times de engenharia usam Databricks; times de BI usam Power BI — todos lendo o mesmo dado físico
| Detalhe Técnico Importante O OneLake usa o protocolo ABFS do ADLS Gen2. Qualquer ferramenta que já sabe falar com ADLS Gen2 — Databricks, Synapse, SDKs customizados — consegue se conectar ao OneLake sem modificação de código, apenas mudando o endpoint. |
4. O Que Mudou na Prática com a Parceria 2025/2026
4.1 Mirroring do Databricks para o OneLake
Já disponível antes da parceria formal: o Fabric consegue fazer mirroring de tabelas do Databricks para dentro do OneLake. É uma replicação gerenciada — o dado original fica no Databricks, e uma cópia sincronizada aparece no OneLake para consumo pelo Fabric.
Útil para quem quer começar a usar Power BI Direct Lake sobre dados que ainda estão no Databricks, sem refatorar pipelines.
4.2 Leitura Nativa do OneLake via Unity Catalog (Preview — 2026)
A novidade de março de 2026: o Databricks consegue registrar tabelas do OneLake no Unity Catalog como external locations. Isso inverte o fluxo — antes era Databricks → OneLake; agora o OneLake vira fonte de verdade que o Databricks lê nativamente, sem cópia.
4.3 Escrita Direta do Databricks no OneLake
Disponível via API ADLS Gen2: o Databricks já consegue gravar diretamente no OneLake usando o endpoint ABFS. Isso está em uso produtivo por diversas organizações. O plano anunciado no FabCon 2026 é tornar essa integração ainda mais nativa — com suporte de escrita diretamente via Unity Catalog, sem precisar configurar manualmente o endpoint.
4.4 Integração com Microsoft 365
Uma das novidades mais interessantes do FabCon 2026: dados governados pelo Unity Catalog do Databricks podem ser acessados dentro do Microsoft Teams, Excel e Copilot Studio através do OneLake Catalog. Isso leva dados de engenharia para usuários de negócio sem exigir que eles abram o Databricks ou o Fabric — eles simplesmente trabalham dentro do Teams ou Excel como sempre fizeram.
O add-in do Databricks para Excel conecta planilhas diretamente a tabelas do lakehouse, substituindo a prática problemática de exportar CSVs e importar manualmente.
5. O Que Há de Bom Nessa Parceria
| Benefício | Detalhe |
| Zero duplicação de dados | Shortcuts e integração via API eliminam a necessidade de copiar dados entre plataformas |
| Engines diferentes, dado único | Times podem usar Databricks Spark, Fabric Spark, SQL Analytics ou Power BI sobre o mesmo dado físico |
| Formatos abertos | Delta Lake e Parquet garantem portabilidade — ninguém fica preso em formato proprietário |
| Governança unificada | Unity Catalog e Microsoft Purview estão convergindo em visibilidade cruzada |
| BI sem ETL | Direct Lake mode do Power BI lê Delta tables diretamente, sem import, sem DirectQuery lento |
| Integração M365 | Dados do lakehouse acessíveis dentro do Teams e Excel nativamente |
| Multi-cloud por natureza | O Databricks no GCP ou AWS pode acessar o OneLake no Azure sem bloqueio de vendor |
6. Os Pontos de Atenção (Que Ninguém Fala)
6.1 Governança Dupla Não É Governança Automática
Esse é o maior ponto de atenção da arquitetura híbrida. O Unity Catalog do Databricks e o Microsoft Purview operam como camadas de governança separadas — e em 2026 elas ainda não se sincronizam automaticamente.
Uma tabela governada no Unity Catalog não herda automaticamente as políticas do Purview quando acessada via Shortcut no Fabric, e vice-versa. Isso significa que acessos, classificações de dados e linhagem precisam ser desenhados explicitamente para os dois lados — não é algo que acontece por padrão.
| ⚠️ Cuidado com dados sensíveis em Shortcuts Até o início de 2026, Shortcuts no OneLake não forçam completamente as políticas de segurança do sistema de origem. Para dados regulados (LGPD, PCI, etc.), essa lacuna precisa ser endereçada explicitamente na arquitetura. |
6.2 Custo de Dual Adoption Pode Surpreender
Rodar Databricks e Fabric ao mesmo tempo tem custo. O Fabric começa em capacidades F2 (cerca de $260/mês), mas workloads sérios geralmente precisam de F64 ou mais (~$8.000/mês). Somado ao custo do workspace Databricks, o TCO de uma arquitetura híbrida precisa ser calculado com cuidado.
O ponto positivo é que a integração via API elimina a necessidade de ETL intermediário — o que reduz custo de pipeline. Mas a conta do compute dos dois lados é real.
6.3 Escrita Concorrente Exige Cuidado
Quando múltiplos engines (Databricks e Fabric Spark, por exemplo) escrevem na mesma tabela Delta ao mesmo tempo, conflitos de transação podem ocorrer. O Delta Lake tem ACID transactions, mas a coordenação entre engines diferentes sobre o mesmo arquivo exige atenção ao design — especialmente sobre quem é o ‘dono’ da escrita de cada tabela.
6.4 Features em Preview Não São Features em GA
A leitura nativa via Unity Catalog e algumas das integrações anunciadas no FabCon 2026 ainda estão em preview público. Preview significa que o comportamento pode mudar, SLAs não são garantidos e bugs são esperados. Para produção crítica, é importante acompanhar o roadmap antes de comprometer arquiteturas.
7. Como Fica a Arquitetura na Prática
Para quem está desenhando uma solução com Databricks e Microsoft Fabric, a tabela abaixo resume onde o dado vive e como cada camada o acessa:
| Dado | Onde fica fisicamente | Como o OneLake acessa | Como o Databricks acessa |
| Tabelas Delta do Databricks (GCP/AWS) | Bucket GCP ou S3 | Shortcut (virtual, sem cópia) | Nativo — é a storage dele |
| Itens nativos do Fabric Lakehouse | Storage nativa do OneLake (Azure/ADLS) | Direto — é a home dele | Via API ABFS ou Unity Catalog (preview) |
| Databricks gravando no Fabric | Storage nativa do OneLake (Azure/ADLS) | Direto — vira dado nativo | Escreve via endpoint ABFS |
| Mirror de tabela Databricks | Réplica na storage do OneLake | Direto — dado já está no OneLake | Lê do original; replica automaticamente |
O fluxo mais comum em arquiteturas híbridas modernas é:
- Databricks processa dados pesados (ETL, ML, streaming) e grava resultados no OneLake via API ABFS
- O OneLake expõe esses dados para Power BI via Direct Lake mode — sem import, sem latência de DirectQuery
- Dados de sistemas externos (GCP, S3) são expostos via Shortcuts para que o Fabric os enxergue sem mover nada
- O Unity Catalog governa o catálogo pelo lado Databricks; o Purview pelo lado Microsoft
Conclusão
A parceria Microsoft-Databricks evoluiu de uma convivência de conveniência para uma integração técnica real. O que antes exigia pipelines de ETL para mover dados entre as plataformas hoje pode ser feito sem cópia, sem duplicação, e sem lock-in de formato — graças à compatibilidade de API entre o OneLake e o ADLS Gen2.
O ponto que mais surpreende quem conhece apenas o lado de marketing: o OneLake não é só uma camada virtual de ponteiros. Ele tem uma storage física real, e é exatamente aí que a integração com o Databricks se torna mais poderosa — um engine processando dados que o outro pode ler e vice-versa, tudo sobre o mesmo arquivo físico.
Os desafios ainda existem — governança dual, custo de adoção combinada e features em preview. Mas a direção é clara: a Microsoft e o Databricks estão apostando que o futuro dos dados em Azure não é “um ou outro”, mas sim “os dois, integrados, sem duplicação”.
Para arquitetos e engenheiros de dados que precisam navegar entre os dois mundos, entender essa integração em profundidade já deixou de ser um diferencial e virou necessidade.
Referências e Leitura Adicional
- Microsoft Fabric Blog — Advancing Openness and Interoperability with OneLake (Nov 2025)
- Databricks Blog — What’s New at FabCon 2026: Lakebase, Lakeflow, and Genie (Mar 2026)
- Microsoft Azure Blog — FabCon and SQLCon 2026: Unifying databases and Fabric (Mar 2026)
- Microsoft Learn — Integrate OneLake with Azure Databricks
- Synapx — Microsoft Fabric vs Databricks: The 2026 Head-to-Head (Mar 2026)
Escrito por Fabio Leandro Ribeiro — Customer Engineer Data/AI na Microsoft. Criador do canal Opus Data no YouTube.