Shortcuts no OneLake: integrar dados sem mover

O problema não é ter os dados, é ter cinco cópias deles#

Toda empresa que começa a montar analytics em cima do Microsoft Fabric esbarra na mesma pergunta chata: para usar um dado que já existe em outro lugar, eu preciso copiar ele para dentro do Fabric? A resposta padrão, por anos, foi sim. E cada sim gerou um pipeline de cópia, uma janela de atualização, um custo de armazenamento duplicado e, principalmente, uma nova versão do dado que pode divergir da original. É aqui que os Shortcuts no OneLake entram para mudar a conta.

Um shortcut, ou atalho, é um ponteiro. Ele faz com que um dado que mora em outro lugar apareça dentro do seu Lakehouse como se estivesse ali, mas sem copiar um único byte. O arquivo continua na origem. O Fabric só sabe o caminho para chegar até ele e o expõe na sua estrutura de pastas como se fosse local. Parece detalhe técnico, mas muda a arquitetura inteira: em vez de mover dados o tempo todo, você referencia onde eles já estão.

Neste artigo eu explico o que são os shortcuts, como funcionam, onde eles brilham, onde eles machucam e o que ninguém te conta sobre governança e desempenho.

O que é um shortcut, sem enrolação#

O OneLake é o data lake único do Fabric, construído sobre o Azure Data Lake Storage Gen2 e organizado em torno do formato Delta Lake e do padrão Parquet. Se você ainda não tem clareza sobre esse alicerce, vale ler antes o nosso texto sobre o que é o Microsoft Fabric e se vale a pena em 2026, porque o shortcut só faz sentido depois que você entende que o OneLake é o chão comum de todos os itens.

O shortcut vive dentro de um Lakehouse (ou de um Warehouse, ou de um KQL Database, dependendo do tipo), na seção de Tables ou de Files. Você aponta esse atalho para um destino, e o Fabric passa a listar aquele destino como se fosse conteúdo próprio. Quando alguém consulta esse caminho, o motor vai buscar o dado na origem, em tempo de leitura. Não existe processo de sincronização rodando por trás. Não existe cópia agendada. O que você vê é sempre o que está lá na fonte naquele momento, respeitada a latência da própria fonte e de eventuais camadas de cache.

Existem dois grandes tipos de destino, e a diferença entre eles define quase tudo sobre governança e desempenho:

• Shortcut interno: aponta para outro item dentro do próprio Fabric. Pode ser uma tabela de outro Lakehouse, dados de outro workspace, ou o mesmo tenant OneLake. Tudo continua dentro do ecossistema Microsoft.
• Shortcut externo: aponta para armazenamento fora do Fabric. Os destinos suportados incluem Azure Data Lake Storage Gen2, Amazon S3 e Google Cloud Storage, além de conectores para Dataverse e outras fontes que a plataforma vem ampliando.

Interno e externo resolvem problemas diferentes#

Na prática, a decisão de usar shortcut interno ou externo não é técnica, é de arquitetura de dados. Um serve para acabar com a cópia entre times dentro da sua própria casa. O outro serve para trazer dados de fora sem ter que ingerir tudo primeiro. A tabela abaixo separa as duas famílias.

Aspecto	Shortcut interno	Shortcut externo
Destino típico	Outro Lakehouse ou workspace no Fabric	ADLS Gen2, Amazon S3, Google Cloud Storage
Autenticação	Identidade do próprio Fabric e permissões do OneLake	Credencial ou identidade gerenciada da fonte externa
Latência de leitura	Muito baixa, dado já no OneLake	Depende da rede e da região da nuvem de origem
Custo de saída	Não gera egress externo	Pode gerar custo de egress na nuvem de origem
Caso de uso principal	Reuso entre times sem duplicar	Integrar multicloud sem projeto de ingestão
Risco de governança	Herança de permissões entre workspaces	Controle de acesso fica parcialmente na fonte

Repare na última linha, porque ela é a que mais gera dor de cabeça depois. Shortcut não é só encanamento, é uma decisão de quem enxerga o quê.

Como o shortcut se comporta com quem consome o dado#

Um ponto que confunde muita gente: uma vez criado o atalho, quem consome não precisa saber que aquilo é um shortcut. Um relatório de Power BI em modo Direct Lake, uma consulta SQL no endpoint do Lakehouse, um notebook em Spark, todos leem o caminho como se fosse uma tabela local. Isso é ótimo para produtividade e péssimo para quem não pensou em governança antes, porque o dado remoto herda a sensação de ser interno sem herdar necessariamente os mesmos controles.

Sobre permissões, a regra prática é a seguinte. Para shortcut interno, o acesso é avaliado na leitura contra as permissões da fonte, então quem não pode ver a tabela original não passa a poder só porque existe um atalho. Para shortcut externo, o Fabric usa a credencial configurada no próprio atalho para chegar na fonte, o que significa que o controle fino precisa ser desenhado dos dois lados: no OneLake e no storage de origem.

Onde o shortcut realmente vale a pena#

Vou ser direto sobre os cenários em que a gente recomenda shortcut sem pestanejar, porque a tecnologia é boa mas não é bala de prata.

• Arquitetura medalhão entre times: a camada bronze fica em um Lakehouse governado pela engenharia, e os times de negócio criam shortcuts internos para ler a camada silver ou gold sem copiar. Uma fonte, muitos consumidores.
• Multicloud sem projeto de migração: a empresa tem dados críticos no Amazon S3 ou no Google Cloud Storage e não quer, ou não pode, migrar tudo para o Azure agora. O shortcut externo expõe esses dados no Fabric para análise, enquanto a origem permanece onde está.
• Data mesh e domínios: cada domínio publica seus dados como produto no seu próprio workspace, e os consumidores montam shortcuts para os produtos que precisam, sem pedir cópia para o time dono.
• Prototipagem rápida: antes de investir em um pipeline de ingestão de verdade, um shortcut deixa você validar se o dado presta e se o caso de uso fecha, com custo de setup quase zero.

Em todos esses casos o ganho é o mesmo: você elimina a duplicação, reduz o número de pipelines para manter e garante que todo mundo lê a mesma verdade. Se o seu gargalo hoje é ter engenharia de dados sobrecarregada mantendo cópias, esse é exatamente o tipo de simplificação que a gente ataca em projetos de engenharia de dados.

Onde o shortcut machuca: latência, custo e governança#

Agora a parte honesta, que raramente aparece nos slides de marketing. Shortcut não move dado, e isso é uma faca de dois gumes. Como a leitura acontece na origem, o desempenho da consulta fica refém da fonte. Se o S3 na outra região responde devagar, seu relatório responde devagar, e nenhum truque do Fabric salva uma tabela externa mal particionada.

A tabela abaixo resume os principais pontos de atenção que a gente sempre levanta antes de aprovar um shortcut em produção.

Cuidado	O que acontece se ignorar	Como mitigar
Latência da fonte	Consultas lentas e experiência ruim no relatório	Preferir fontes na mesma região e usar cache quando disponível
Custo de egress	Fatura da nuvem de origem sobe sem aviso	Medir volume de leitura e avaliar ingestão para dados muito acessados
Formato do dado	Parquet e Delta rendem bem, arquivos brutos nem sempre	Padronizar em Delta ou Parquet particionado na origem
Permissões duplas	Dado sensível exposto por credencial ampla demais	Aplicar menor privilégio no OneLake e na fonte externa
Dependência da origem	Fonte cai ou muda o caminho e o atalho quebra	Monitorar disponibilidade e documentar contratos de dados
Otimização Delta	Sem OPTIMIZE e VACUUM o desempenho degrada	Manter manutenção Delta na origem, não no atalho

O ponto que mais surpreende gestor é o custo de egress. O shortcut não copia o dado uma vez, ele lê o dado toda vez que alguém consulta. Se um dashboard popular fica lendo um bucket no S3 o dia inteiro, você pode pagar mais de saída de dados do que pagaria para simplesmente ter ingerido aquela tabela uma vez por dia. Nesses casos, a resposta certa não é shortcut, é um pipeline de ingestão. A regra que usamos é simples: dado muito lido e pouco alterado tende a compensar cópia, dado pouco lido ou que precisa estar sempre fresquíssimo tende a compensar atalho.

Shortcut não substitui modelagem nem governança#

Aqui vai a opinião que separa quem entende de quem só assistiu ao vídeo de demonstração. O shortcut resolve o problema de acesso ao dado, não o problema de qualidade do dado. Ele não limpa, não conforma, não aplica regra de negócio. Se a origem tem dado sujo, o atalho traz dado sujo com uma velocidade admirável.

Por isso, na maioria das arquiteturas sérias, o shortcut entra na camada bronze, para acessar a fonte sem copiar, e a transformação acontece em cima disso, gerando as camadas silver e gold já dentro do OneLake, com dado tratado e materializado. Servir relatório de diretoria direto de um shortcut externo cru é pedir para ter número errado em reunião importante. Se o objetivo é análise avançada e modelos confiáveis, o trabalho pesado continua sendo de modelagem, e é isso que cobrimos em projetos de analytics avançado.

Do lado da governança, a recomendação é tratar cada shortcut como um contrato. Quem é o dono da fonte? Qual a expectativa de disponibilidade? Quem pode ler? O que acontece se o caminho mudar? Sem essas respostas documentadas, você troca o problema da cópia pelo problema da dependência invisível, e o segundo é bem mais difícil de rastrear quando algo quebra às sete da manhã.

Um roteiro curto para começar sem se enrolar#

Se você vai testar shortcuts, esse é o caminho que evita a maior parte das ciladas:

1. Escolha um caso de leitura, não de escrita. Shortcut é para consumir dado que já existe, comece por aí.
2. Prefira um shortcut interno na primeira vez, para entender o comportamento sem lidar com credencial externa e egress.
3. Meça a latência de uma consulta real, não de um SELECT de dez linhas. Rode o relatório que vai de fato existir.
4. Só então avalie um shortcut externo, e comece por uma fonte pequena e na mesma região da sua capacidade Fabric.
5. Documente o dono, o caminho e as permissões de cada atalho antes de colocar qualquer coisa em produção.

Esse roteiro parece óbvio, mas é o que separa o piloto que virou produção estável do que virou fonte de incidente. Para ver onde isso se encaixa numa plataforma completa, o nosso conjunto de soluções mostra o lugar do OneLake e dos shortcuts em arquiteturas maiores.

Perguntas frequentes#

O shortcut copia o dado para o Fabric?

Não. Essa é a característica central. O shortcut é um ponteiro para o local onde o dado já vive. O arquivo permanece na origem, e o Fabric apenas o exibe dentro do Lakehouse como se fosse local. A leitura acontece na fonte, em tempo de consulta, o que evita duplicação de armazenamento mas cria dependência da disponibilidade e da latência da origem.

Posso escrever dados através de um shortcut?

Depende do tipo e das permissões da fonte. A maioria dos cenários usa shortcut para leitura, especialmente os externos. Para escrita, a credencial e as permissões do destino precisam permitir a operação, e mesmo assim recomendamos cautela. Para transformação, o padrão saudável é ler pelo shortcut e materializar o resultado dentro do OneLake.

Quais fontes externas são suportadas?

Hoje os destinos externos mais usados são o Azure Data Lake Storage Gen2, o Amazon S3 e o Google Cloud Storage, além de conectores para fontes como Dataverse. A Microsoft vem ampliando essa lista, então vale sempre conferir a documentação oficial antes de assumir que uma fonte específica está disponível na sua região e no seu tipo de capacidade.

Shortcut resolve o problema de latência entre nuvens?

Não, ele expõe esse problema em vez de escondê-lo. Como a leitura ocorre na origem, uma fonte em outra nuvem ou região responde na velocidade dela. Para dados muito acessados, isso significa consultas lentas e custo de egress relevante, e aí ingerir o dado de forma agendada costuma sair mais barato do que manter um atalho lido o tempo todo.

Como fica a segurança de um dado acessado por shortcut?

O controle precisa existir dos dois lados. Para shortcuts internos, as permissões do OneLake e da fonte original continuam valendo na leitura. Para shortcuts externos, o Fabric usa a credencial configurada no atalho para chegar na origem, então quem desenha o acesso precisa aplicar o menor privilégio tanto no storage externo quanto no workspace do Fabric. Tratar o atalho como se fosse dado interno, sem revisar quem vê o quê, é o erro clássico.

Vale a pena usar shortcut em vez de um pipeline de ingestão?

Vale quando o dado é pouco alterado em relação ao volume de leitura, quando você quer evitar cópia entre times ou quando precisa integrar multicloud sem um projeto de migração. Não vale quando o dado é lido intensamente, quando a fonte é lenta ou instável, ou quando o custo de egress supera o de copiar. A decisão é caso a caso.

Em resumo#

Os shortcuts no OneLake são uma das ideias mais elegantes do Fabric: integrar dados sem mover, acabar com cópias redundantes e deixar cada time ler a mesma verdade. Mas elegância não dispensa engenharia. Latência da fonte, custo de egress e governança de acesso continuam sendo problemas seus, não da ferramenta. Usados com critério, os atalhos simplificam a plataforma. Sem critério, viram dependência invisível e conta de nuvem surpresa.

Se a sua empresa está desenhando a arquitetura de dados no Fabric e quer decidir com clareza onde usar shortcut, onde ingerir e onde modelar, fale com a gente. A gente olha o seu cenário real antes de recomendar qualquer caminho.