TL;DR – Este artigo analisa o anúncio da Microsoft que permite ao Azure Databricks armazenar tabelas gerenciadas do Unity Catalog diretamente no OneLake, eliminando a necessidade de duplicação de dados entre plataformas. Para empresas brasileiras, isso significa redução de custos com storage, simplificação de pipelines e governança unificada, sem abrir mão das ferramentas preferidas de engenharia de dados e IA. A conclusão principal: a interoperabilidade bidirecional entre Fabric e Databricks se torna viável, abrindo caminho para arquiteturas data lakehouse mais eficientes.
À medida que organizações escalam seus investimentos em dados e IA, a adoção de múltiplas plataformas se tornou a regra, não a exceção. O desafio sempre foi fazer essas plataformas trabalharem a partir de uma única cópia de dados, sem duplicar storage ou construir pipelines complexos. Com as atualizações mais recentes do ecossistema Microsoft, Azure Databricks e Microsoft Fabric dão um passo concreto rumo à interoperabilidade bidirecional via OneLake.
Até então, a leitura de dados entre plataformas já era possível: a federação de catálogos do OneLake (agora GA) permite que o Azure Databricks consulte dados do OneLake diretamente, e o Mirrored Azure Databricks Catalog tornava tabelas do Unity Catalog armazenadas em ADLS Gen2 acessíveis no Fabric. Agora, a integração avança: o Azure Databricks pode armazenar tabelas gerenciadas do Unity Catalog diretamente no OneLake.
Por que essa interoperabilidade é um marco para empresas brasileiras?
O principal ganho prático é a eliminação da duplicação de dados. Com suporte tanto para leitura quanto para escrita direta no OneLake, clientes do Azure Databricks podem usar o OneLake como camada de armazenamento nativa para suas tabelas Delta, sem precisar gerenciar sistemas de storage separados. Isso oferece flexibilidade para armazenar dados no OneLake enquanto utilizam as ferramentas preferidas de cada projeto — seja no Microsoft Fabric ou no Azure Databricks.
Como as tabelas permanecem totalmente gerenciadas pelo Unity Catalog, todas as políticas de governança e otimização existentes se estendem aos dados armazenados no OneLake. E, como há uma única cópia dos dados, alterações feitas em um ambiente são refletidas imediatamente no outro. Isso elimina a necessidade de movimentação de dados, reduz a duplicação e simplifica a gestão do data estate.
Para empresas brasileiras que enfrentam desafios de compliance e custos com armazenamento em múltiplos provedores, essa abordagem representa uma oportunidade real de consolidar a estratégia de dados em torno de um data lakehouse unificado, sem perder a flexibilidade de escolha de ferramentas.
Quais são as capacidades-chave?
Store Unity Catalog managed tables directly in OneLake (Beta)
Este é o núcleo do anúncio. Com o suporte a external locations no OneLake, você pode criar tabelas gerenciadas do Unity Catalog armazenadas no Microsoft OneLake. Basta mapear um external location para um caminho do OneLake e, a partir desse ponto, todos os tipos de assets do Unity Catalog — tabelas gerenciadas, views, materialized views e streaming tables — são armazenados diretamente no OneLake.
Diferente do padrão anterior, onde as tabelas ficavam no ADLS Gen2 e eram espelhadas no Fabric, essa abordagem faz do OneLake o destino primário de storage. Os dados escritos pelo Azure Databricks passam a viver diretamente no OneLake desde o início, sem cópias intermediárias.
Publish to Fabric: Surface OneLake backed tables in Fabric (Preview)
Uma vez que as tabelas do Unity Catalog estão no OneLake, é preciso torná-las visíveis e consultáveis no Fabric. O Publish to Fabric oferece um workflow nativo do Azure Databricks para criar mirrored catalog items diretamente a partir do Catalog Explorer. Isso funciona para tabelas do Unity Catalog independentemente de onde estejam armazenadas — no OneLake ou no ADLS Gen2.
Uma vez publicado, o Fabric consulta os metadados do Unity Catalog para manter o catálogo espelhado sincronizado. Alterações de DDL feitas no Azure Databricks (novas tabelas, exclusões, modificações de schema) são refletidas no Fabric no próximo intervalo de sincronização. Também é possível forçar uma sincronização imediata usando a ação Refresh no item espelhado. As tabelas são somente leitura no Fabric, já que a fonte de verdade permanece no Azure Databricks, e você pode publicar o mesmo catálogo em múltiplos workspaces do Fabric de forma independente.
Como configurar na prática?
Parte 1: Configurar o OneLake como storage do Unity Catalog
- Configure identidade e acesso – Crie ou identifique uma Managed Identity ou Service Principal no Azure e atribua a ela uma função de workspace (Admin, Member ou Contributor) no workspace Fabric de destino.
- Provisione storage no Fabric – Crie um Azure Databricks Storage item no workspace Fabric.
- Crie um storage credential e external location – No Azure Databricks, crie um storage credential do Unity Catalog e um external location apontando para o OneLake.
- Crie catálogos e tabelas – Crie assets do Unity Catalog no external location do OneLake. Os dados escritos para essas tabelas vão diretamente para o OneLake, sem cópia ou pipeline.
Parte 2: Publicar o catálogo no Fabric
- Conceda permissões – Atribua as permissões necessárias do Unity Catalog para sua Service Principal ou identidade de usuário, para que o Fabric possa acessar os metadados do catálogo.
- Crie uma conexão no Fabric – No Fabric, configure uma cloud connection para seu workspace do Azure Databricks.
- Publique a partir do Catalog Explorer – No Azure Databricks, selecione seu catálogo e use o workflow Publish to Fabric para enviá-lo ao workspace Fabric escolhido.
- Consulte no Fabric – Uma vez publicado, as tabelas estarão imediatamente disponíveis para consulta em todos os workloads do Fabric, incluindo SQL analytics, notebooks e Power BI.
Recursos adicionais
- Mirroring Azure Databricks Unity Catalog
- Configuring OneLake external locations
- Publish a Unity Catalog catalog to Microsoft Fabric
- Microsoft OneLake documentation
Perguntas Frequentes
-
Como funciona o armazenamento de tabelas do Unity Catalog no OneLake?
Cria-se um external location no Unity Catalog apontando para um caminho do OneLake. A partir daí, todos os assets gerenciados (tabelas, views, materialized views, streaming tables) são armazenados diretamente no OneLake, sem necessidade de pipelines de cópia. -
Quais são as diferenças entre essa nova abordagem e o mirroring anterior?
Antes, as tabelas ficavam no ADLS Gen2 e eram espelhadas no Fabric via mirroring. Agora, o OneLake passa a ser o storage primário, eliminando a camada adicional de mirroring para dados nativos do Databricks. O mirroring ainda é útil para tabelas em ADLS Gen2. -
O que é o 'Publish to Fabric' e como ele acelera o uso dos dados no Fabric?
É um workflow nativo do Azure Databricks Catalog Explorer que cria itens de mirrored catalog no Fabric com um clique. As tabelas ficam imediatamente disponíveis para consulta em qualquer workload do Fabric (SQL analytics, notebooks, Power BI), com sincronização automática de metadados. -
Essa integração gera custos adicionais de armazenamento ou transferência?
Não. Como os dados são armazenados uma única vez no OneLake, não há duplicação. As mudanças feitas em uma plataforma são refletidas instantaneamente na outra, eliminando custos de movimentação entre ambientes. A governança permanece centralizada no Unity Catalog. -
Quais pré-requisitos são necessários para começar a usar OneLake como storage do Unity Catalog?
É preciso ter uma Managed Identity ou Service Principal com permissão de workspace no Fabric, criar um Azure Databricks Storage item no workspace, configurar um storage credential e external location no Unity Catalog, e depois publicar o catálogo via Publish to Fabric.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
