Microsoft Fabric: OneLake shortcuts vs cópia de dados na prática

Toda arquitetura de dados no Microsoft Fabric esbarra cedo em uma decisão que parece pequena, mas define custo e governança do ambiente inteiro: quando referenciar dados com um shortcut no OneLake e quando de fato copiar os dados para dentro do seu Lakehouse ou Warehouse. Escolher errado gera duplicação desnecessária, storage inflado e pipelines de ingestão que só existem porque ninguém confiou no shortcut — ou o oposto: latência inaceitável em relatórios que dependem de uma fonte externa lenta.

O que um shortcut realmente é

Um OneLake shortcut é um ponteiro. Ele expõe dados que fisicamente moram em outro lugar — outro Lakehouse, outro workspace, uma conta ADLS Gen2, um bucket Amazon S3, Google Cloud Storage ou Dataverse — como se fossem tabelas ou arquivos dentro do seu Lakehouse, sem mover um byte. O engine do Fabric lê o dado no local de origem no momento da query.

Isso muda três coisas na prática:

• Não há cópia, então não há custo de storage adicional no OneLake para o dado referenciado e não há job de ingestão para manter.
• Não há defasagem de sincronização — o shortcut sempre enxerga a versão atual da origem, porque lê direto de lá.
• A performance fica refém da origem e da rede até ela. Um shortcut para uma conta S3 em outra região não vai ter o mesmo throughput de um delta table local.

Existem dois tipos que confundem quem está começando: o internal shortcut, que aponta para outro item dentro do próprio OneLake (útil para compartilhar uma tabela gold entre workspaces sem replicar), e o external shortcut, que aponta para ADLS, S3, GCS ou Dataverse.

Onde o shortcut brilha

O caso mais forte é evitar a proliferação de cópias de uma mesma tabela dourada. Se o time de engenharia consolidou uma dimensão de clientes num Lakehouse central, os workspaces de finanças, vendas e operação não precisam cada um ingerir a própria cópia — um internal shortcut dá acesso à mesma tabela física, e qualquer atualização aparece para todos ao mesmo tempo. Isso elimina a clássica situação de três dashboards mostrando três totais diferentes porque cada área rodou o ETL num horário diferente.

O segundo caso é o data lake que já existe fora do Fabric. Se a empresa já mantém um ADLS Gen2 ou um S3 com dados históricos em Delta ou Parquet, um shortcut integra esse acervo ao Fabric sem um projeto de migração. O dado continua governado onde sempre esteve, e o Fabric passa a consultá-lo.

O terceiro é o Direct Lake sobre dados referenciados: um modelo semântico do Power BI em Direct Lake consegue ler tabelas expostas por shortcut, desde que estejam em formato Delta com o layout esperado. Isso permite relatórios de altíssimo desempenho sobre dados que você nunca copiou para dentro do Fabric.

Quando copiar mesmo assim

Shortcut não é sempre a resposta. Copie os dados quando:

• A origem é lenta ou instável e você não pode aceitar que a performance do relatório dependa dela. Trazer o dado para um Lakehouse local (via Dataflow Gen2, pipeline ou Fast Copy) coloca a leitura sob a Capacity do Fabric, com throughput previsível.
• Você precisa transformar, limpar ou reestruturar o dado. Shortcut expõe a origem como ela é; se o consumo exige um star schema, tipos ajustados e granularidade reduzida, isso é uma camada de transformação que produz uma tabela nova — ou seja, uma cópia.
• A origem está em formato não otimizado para Direct Lake. CSV, JSON aninhado ou Parquet mal particionado forçam fallback para DirectQuery ou performance ruim; converter para Delta bem estruturado exige materializar.
• Requisitos de retenção ou auditoria exigem uma cópia congelada, independente do que acontece na origem. Um shortcut segue a origem — se alguém apagar lá, some do seu Lakehouse também.

A camada de governança que quase todo mundo esquece

Shortcuts têm implicações de segurança que precisam entrar na conta. Para shortcuts internos, o acesso ao dado referenciado respeita as permissões do OneLake do item de origem — mas a forma como isso se combina com as permissões do item que hospeda o shortcut precisa ser validada por workspace, porque um shortcut mal exposto vira um caminho lateral para dados sensíveis.

Para shortcuts externos (ADLS, S3), a autenticação usa credenciais ou connections configuradas no nível do shortcut — organization account, service principal ou SAS/chave. Isso significa que uma credencial mal escopada num shortcut dá a todo consumidor do Lakehouse acesso ao que aquela credencial enxerga na origem. Trate a connection do shortcut com o mesmo rigor de um connection reference em produção.

E há o efeito em custo de Capacity: a leitura via shortcut consome Capacity Units na hora da query, e um shortcut para origem lenta consome mais CU (query mais demorada) do que ler um Delta local otimizado. Referenciar não é gratuito em CPU só porque é gratuito em storage.

Um roteiro de decisão

1. O dado já existe em outro lugar governado (outro Lakehouse, ADLS, S3, Dataverse) e você só quer consultá-lo? Comece por shortcut.
2. A origem é rápida, estável e já está em Delta bem estruturado? Shortcut resolve, inclusive com Direct Lake.
3. Você precisa transformar, limpar, reduzir granularidade ou garantir performance previsível independente da origem? Copie via Dataflow Gen2 ou pipeline.
4. Requisito de retenção/auditoria exige uma versão imutável e desacoplada da origem? Copie.
5. Em dúvida com uma fonte externa lenta em cenário crítico de BI? Copie a camada de consumo e mantenha o shortcut só para a camada bruta de exploração.

O padrão maduro raramente é "tudo shortcut" ou "tudo cópia": é bronze por shortcut para não replicar o data lake existente, e silver/gold materializados no Lakehouse do Fabric, onde a transformação e a performance do relatório ficam sob seu controle.

Arquitetar isso bem — decidir o que virtualizar, o que copiar, como escopar credenciais de shortcut e como não estourar a Capacity — é exatamente o tipo de decisão que define o custo mensal do seu ambiente Fabric. Se sua empresa está montando ou revisando essa arquitetura, a Dynamic Soluções pode ajudar a desenhar a estratégia de OneLake, governança e otimização de Capacity com quem já fez isso em produção.

Every data architecture in Microsoft Fabric runs early into a decision that looks small but shapes the cost and governance of the whole environment: when to reference data with a shortcut in OneLake and when to actually copy the data into your Lakehouse or Warehouse. Getting it wrong produces needless duplication, inflated storage and ingestion pipelines that only exist because nobody trusted the shortcut — or the opposite: unacceptable latency in reports that depend on a slow external source.

What a shortcut actually is

A OneLake shortcut is a pointer. It exposes data that physically lives elsewhere — another Lakehouse, another workspace, an ADLS Gen2 account, an Amazon S3 bucket, Google Cloud Storage or Dataverse — as if it were tables or files inside your Lakehouse, without moving a single byte. The Fabric engine reads the data at its origin at query time.

That changes three things in practice:

• There is no copy, so no additional OneLake storage cost for the referenced data and no ingestion job to maintain.
• There is no sync lag — the shortcut always sees the current version of the source, because it reads straight from it.
• Performance is hostage to the source and the network to it. A shortcut to an S3 account in another region won't have the throughput of a local delta table.

There are two types that confuse newcomers: the internal shortcut, pointing to another item within OneLake itself (useful for sharing a gold table across workspaces without replicating), and the external shortcut, pointing to ADLS, S3, GCS or Dataverse.

Where the shortcut shines

The strongest case is avoiding the proliferation of copies of the same golden table. If the engineering team consolidated a customer dimension in a central Lakehouse, the finance, sales and operations workspaces don't each need to ingest their own copy — an internal shortcut grants access to the same physical table, and any update appears for everyone at once. This kills the classic situation of three dashboards showing three different totals because each area ran its ETL at a different time.

The second case is the data lake that already exists outside Fabric. If the company already keeps an ADLS Gen2 or an S3 with historical data in Delta or Parquet, a shortcut integrates that catalog into Fabric without a migration project. The data stays governed where it always was, and Fabric starts querying it.

The third is Direct Lake over referenced data: a Power BI semantic model in Direct Lake can read tables exposed via shortcut, as long as they're in Delta format with the expected layout. This enables very high performance reports over data you never copied into Fabric.

When to copy anyway

A shortcut isn't always the answer. Copy the data when:

• The source is slow or unstable and you can't accept report performance depending on it. Bringing the data into a local Lakehouse (via Dataflow Gen2, pipeline or Fast Copy) puts the read under Fabric's Capacity, with predictable throughput.
• You need to transform, clean or restructure the data. A shortcut exposes the source as it is; if consumption requires a star schema, adjusted types and reduced granularity, that's a transformation layer producing a new table — that is, a copy.
• The source is in a format not optimized for Direct Lake. CSV, nested JSON or poorly partitioned Parquet force a fallback to DirectQuery or bad performance; converting to well-structured Delta requires materializing.
• Retention or audit requirements demand a frozen copy, independent of what happens at the source. A shortcut follows the source — if someone deletes it there, it vanishes from your Lakehouse too.

The governance layer almost everyone forgets

Shortcuts have security implications that must enter the equation. For internal shortcuts, access to the referenced data respects the OneLake permissions of the source item — but how that combines with the permissions of the item hosting the shortcut must be validated per workspace, because a poorly exposed shortcut becomes a side path to sensitive data.

For external shortcuts (ADLS, S3), authentication uses credentials or connections configured at the shortcut level — organization account, service principal or SAS/key. That means a poorly scoped credential on a shortcut gives every consumer of the Lakehouse access to whatever that credential sees at the source. Treat the shortcut's connection with the same rigor as a connection reference in production.

And there's the Capacity cost effect: reading via shortcut consumes Capacity Units at query time, and a shortcut to a slow source consumes more CU (longer query) than reading an optimized local Delta. Referencing isn't free on CPU just because it's free on storage.

A decision roadmap

1. Does the data already exist somewhere governed (another Lakehouse, ADLS, S3, Dataverse) and you just want to query it? Start with a shortcut.
2. Is the source fast, stable and already in well-structured Delta? A shortcut solves it, including with Direct Lake.
3. Do you need to transform, clean, reduce granularity or guarantee predictable performance independent of the source? Copy via Dataflow Gen2 or pipeline.
4. Does a retention/audit requirement demand an immutable version decoupled from the source? Copy.
5. In doubt with a slow external source in a critical BI scenario? Copy the consumption layer and keep the shortcut only for the raw exploration layer.

The mature pattern is rarely "all shortcut" or "all copy": it's bronze via shortcut to avoid replicating the existing data lake, and silver/gold materialized in the Fabric Lakehouse, where transformation and report performance stay under your control.

Architecting this well — deciding what to virtualize, what to copy, how to scope shortcut credentials and how not to blow the Capacity — is exactly the kind of decision that defines the monthly cost of your Fabric environment. If your company is building or reviewing this architecture, Dynamic Soluções can help design the OneLake strategy, governance and Capacity optimization with people who have done it in production.