Atalhos do OneLake

Os atalhos no Microsoft OneLake permitem que você unifique seus dados entre domínios, nuvens e contas, criando um único data lake virtual para toda a sua empresa. Todas as experiências Fabric e os mecanismos analíticos podem conectar-se diretamente às suas fontes de dados existentes, como Azure, Amazon Web Services (AWS) e OneLake, por meio de um namespace unificado. O OneLake gerencia todas as permissões e credenciais, de modo que você não precisa configurar separadamente cada carga de trabalho do Fabric para se conectar a cada fonte de dados. Além disso, você pode usar atalhos para eliminar cópias de borda de dados e reduzir a latência do processo associada a cópias de dados e preparo.

O que são atalhos?

Atalhos são objetos no OneLake que apontam para outras localizações de armazenamento. O local pode ser interno ou externo ao OneLake. O local para o qual um atalho aponta é conhecido como o caminho de destino do atalho. O local em que o atalho aparece é conhecido como o caminho do atalho. Os atalhos aparecem como pastas no OneLake e qualquer carga de trabalho ou serviço que tenha acesso ao OneLake pode utilizar esses atalhos. Os atalhos se comportam como links simbólicos. Eles são um objeto independente do alvo. Se você excluir um atalho, o destino não será afetado. Se você mover, renomear ou excluir um caminho de destino, o atalho poderá ser interrompido.

Onde posso criar atalhos?

Você pode criar atalhos em lakehouses e bancos de dados da Linguagem de Consulta Kusto (KQL). Além disso, os atalhos que você cria nesses itens podem apontar para outros locais do OneLake, Azure Data Lake Storage (ADLS) Gen2, contas de armazenamento do Amazon S3 ou Dataverse. Você pode até mesmo criar atalhos para localizações locais ou restritas à rede com o uso do gateway de dados local do Fabric (OPDG).

Você pode usar a interface do usuário do Fabric para criar atalhos interativamente e pode usar a API REST para criar atalhos programaticamente.

Lakehouse

Ao criar atalhos em uma lakehouse, você deve entender a estrutura de pastas do item. Os lakehouses são compostos por duas pastas de nível superior: a pasta Tabelas e a pasta Arquivos. A pasta Tabelas representa a parte gerenciada do lakehouse para conjuntos de dados estruturados. Enquanto a pasta Arquivos é a parte não gerenciada do lakehouse para dados não estruturados ou semiestruturados.

Na pasta Tabelas, você só pode criar atalhos no nível superior. Não há suporte para atalhos em subdiretórios da pasta Tabelas. Os atalhos na seção tabelas normalmente apontam para fontes internas no OneLake ou vinculam a outros ativos de dados que estão em conformidade com o formato de tabela Delta. Se o destino do atalho contiver dados no formato Delta\Parquet, o lakehouse sincronizará automaticamente os metadados e reconhecerá a pasta como uma tabela. Os atalhos na seção tabelas podem ser vinculados a uma única tabela ou um esquema, que é uma pasta pai para várias tabelas.

Observação

O formato Delta não dá suporte a tabelas com caracteres de espaço no nome. Qualquer atalho que contenha um espaço no nome não será descoberto como uma tabela Delta no lakehouse.

Na pasta Arquivos, não existem restrições quanto ao local em que você pode criar atalhos. Você pode criá-las em qualquer nível da hierarquia de pastas. A descoberta da tabela não ocorre na pasta Arquivos. Os atalhos aqui podem apontar para sistemas de armazenamento interno (OneLake) e externos com dados em qualquer formato.

Banco de dados KQL

Quando você criar um atalho em um banco de dados KQL, ele aparecerá na pasta Atalhos do banco de dados. O banco de dados KQL trata atalhos como tabelas externas. Para consultar o atalho, utilize a função external_table da linguagem de Consulta Kusto.

Onde posso acessar atalhos?

Qualquer serviço Fabric ou não Fabric que possa acessar os dados no OneLake pode utilizar atalhos. Os atalhos são transparentes para qualquer serviço que acessa dados por meio da API Do OneLake. Os atalhos aparecem apenas como outra pasta no lake. O Apache Spark, o SQL, a inteligência em tempo real e o Analysis Services podem utilizar atalhos ao consultar dados.

Apache Spark

Notebooks e tarefas do Apache Spark podem usar atalhos que você cria no OneLake. Caminhos de arquivo relativos podem ser usados para ler dados diretamente de atalhos. Além disso, se você criar um atalho na seção Tabelas do lakehouse e estiver no formato Delta, poderá lê-lo como uma tabela gerenciada usando a sintaxe do Apache Spark SQL.

df = spark.read.format("delta").load("Tables/MyShortcut")
display(df)

df = spark.sql("SELECT * FROM MyLakehouse.MyShortcut LIMIT 1000")
display(df)

SQL

Você pode ler os atalhos na seção Tabelas de um lakehouse pelo ponto de extremidade da análise do SQL do lakehouse. Você pode acessar o endpoint de análises SQL pelo seletor de modo do lakehouse ou pelo SQL Server Management Studio (SSMS).

SELECT TOP (100) *
FROM [MyLakehouse].[dbo].[MyShortcut]

Inteligência em tempo real

Os atalhos em bancos de dados KQL são reconhecidos como tabelas externas. Para consultar o atalho, utilize a função external_table da linguagem de Consulta Kusto.

external_table('MyShortcut')
| take 100

Serviços de análise

Você pode criar modelos semânticos para lakehouses contendo atalhos na seção Tabelas do lakehouse. Quando o modelo semântico é executado no modo Direct Lake, o Analysis Services pode ler dados diretamente do atalho.

Não Fabric

Aplicativos e serviços fora do Fabric também podem acessar atalhos por meio da API Do OneLake. O OneLake dá suporte a um subconjunto das APIs de Armazenamento de Blobs e ADLS Gen2. Para saber mais sobre a API do OneLake, confira Acesso do OneLake com APIs.

https://onelake.dfs.fabric.microsoft.com/MyWorkspace/MyLakhouse/Tables/MyShortcut/MyFile.csv

Tipos de atalhos

Os atalhos do OneLake dão suporte a várias fontes de dados do sistema de arquivos. Isso inclui locais internos do OneLake, ADLS (Azure Data Lake Storage) Gen2, Amazon S3, S3 Compatible, GCS (Google Cloud Storage) e Dataverse.

Atalhos internos do OneLake

Os atalhos internos do OneLake permitem referenciar dados em itens existentes do Fabric, incluindo:

• Bancos de dados KQL
• Casas de lago
• Catálogo espelhado do Azure Databricks
• Bancos de dados espelhados
• Modelos semânticos
• Bancos de dados SQL
• Depósitos

O atalho pode apontar para um local da pasta dentro do mesmo item, entre itens dentro do mesmo workspace ou até mesmo entre itens em workspaces diferentes. Quando você cria um atalho entre itens, os tipos de item não precisam corresponder. Por exemplo, você pode criar um atalho em um lakehouse que aponte para os dados em um data warehouse.

Quando um usuário acessa os dados por meio de um atalho para outro local do OneLake, o OneLake usa a identidade do usuário chamado para autorizar o acesso aos dados no caminho de destino do atalho. Esse usuário deve ter permissões no local de destino para ler os dados.

Importante

Quando os usuários acessam atalhos por meio de modelos semânticos do Power BI ou T-SQL, a identidade do usuário de chamada não é passada para o destino de atalho. Em vez disso, a identidade do proprietário do item da chamada é passada, delegando o acesso ao usuário da chamada.

Atalhos do Azure Data Lake Storage

Quando você cria atalhos para contas de armazenamento do AdLS (Azure Data Lake Storage) Gen2, o caminho de destino pode apontar para qualquer pasta dentro do namespace hierárquico. No mínimo, o caminho de destino deve incluir um nome de contêiner.

Observação

Você deve ter namespaces hierárquicos habilitados em sua conta de armazenamento ADLS Gen 2.

Acesso

Os atalhos do ADLS devem apontar para o endpoint DFS da conta de armazenamento.

Exemplo: https://accountname.dfs.core.windows.net/

Se sua conta de armazenamento for protegida por um firewall de armazenamento, você poderá configurar o acesso a serviços confiáveis. Para obter mais informações, consulte acesso confiável à área de trabalho

Autorização

Os atalhos do ADLS utilizam um modelo de autorização delegada. Nesse modelo, o criador do atalho especifica uma credencial para o atalho do ADLS e todo o acesso a esse atalho é autorizado utilizando essa credencial. Os atalhos do ADLS dão suporte aos seguintes tipos de autorização delegados:

• Conta organizacional – deve ter a função Leitor de Dados de Blob de Armazenamento, Colaborador de Dados de Blob de Armazenamento ou Proprietário de Dados de Blob de Armazenamento na conta de armazenamento; ou a função Delegador na conta de armazenamento mais acesso de arquivo ou diretório concedidos na conta de armazenamento.
• Entidade de serviço – deve ter a função Leitor de Dados de Blob de Armazenamento, Colaborador de Dados de Blob de Armazenamento ou Proprietário de Dados de Blob de Armazenamento na conta de armazenamento; ou a função Delegador na conta de armazenamento mais acesso de arquivo ou diretório concedidos na conta de armazenamento.
• Identidade do workspace – deve ter a função Leitor de Dados do Blob de Armazenamento, Colaborador de Dados de Blobs de Armazenamento ou Proprietário de Dados de Blob de Armazenamento na conta de armazenamento; ou a função Delegador na conta de armazenamento mais acesso de arquivo ou diretório concedidos na conta de armazenamento.
• SAS (Assinatura de Acesso Compartilhado) – deve incluir pelo menos as seguintes permissões: Leitura, Lista e Execução.

Os tipos de autorização delegada do Microsoft Entra ID (conta organizacional, entidade de serviço ou identidade de workspace) exigem a ação Gerar uma chave de delegação de usuário no nível da conta de armazenamento. Esta ação é incluída como parte das funções Leitor de Dados do Blob de Armazenamento, Colaborador de Dados de Blobs de Armazenamento, Proprietário de Dados de Blobs de Armazenamento e Delegador. Caso não queira conceder permissões de leitor, colaborador ou proprietário para toda a conta de armazenamento a um usuário, atribua a ele a função de Delegador. Em seguida, defina direitos detalhados de acesso a dados usando ACLs (listas de controle de acesso) no Azure Data Lake Storage.

Importante

O requisito gerar uma chave de delegação de usuário não é imposto no momento quando uma identidade de workspace é configurada para o workspace e o tipo de autenticação de atalho do ADLS é Conta Organizacional, Entidade de Serviço ou Identidade do Workspace. No entanto, esse comportamento será restrito no futuro. Recomendamos garantir que todas as identidades delegadas tenham a ação Gerar uma chave de delegação de usuário para garantir que o acesso dos usuários não seja afetado quando esse comportamento for alterado.

Atalhos do Armazenamento de Blobs do Azure

Acesso

O atalho do Armazenamento de Blobs do Azure pode apontar para o nome da conta ou a URL da conta de Armazenamento.

Por exemplo: accountname ou https://accountname.blob.core.windows.net/

Autorização

Os atalhos de armazenamento de blobs usam um modelo de autorização delegado. Nesse modelo, o criador de atalho especifica uma credencial para o atalho e todo o acesso a esse atalho é autorizado usando essa credencial. Os atalhos de blob oferecem suporte aos seguintes tipos de autorização delegados:

• Conta organizacional – deve ter a função Leitor de Dados de Blob de Armazenamento, Colaborador de Dados de Blob de Armazenamento ou Proprietário de Dados de Blob de Armazenamento na conta de armazenamento; ou a função Delegador na conta de armazenamento mais acesso de arquivo ou diretório concedidos na conta de armazenamento.
• Entidade de serviço – deve ter a função Leitor de Dados de Blob de Armazenamento, Colaborador de Dados de Blob de Armazenamento ou Proprietário de Dados de Blob de Armazenamento na conta de armazenamento; ou a função Delegador na conta de armazenamento mais acesso de arquivo ou diretório concedidos na conta de armazenamento.
• Identidade do workspace – deve ter a função Leitor de Dados do Blob de Armazenamento, Colaborador de Dados de Blobs de Armazenamento ou Proprietário de Dados de Blob de Armazenamento na conta de armazenamento; ou a função Delegador na conta de armazenamento mais acesso de arquivo ou diretório concedidos na conta de armazenamento.
• SAS (Assinatura de Acesso Compartilhado) – deve incluir pelo menos as seguintes permissões: Leitura, Lista e Execução.

Atalhos do S3

Quando você cria atalhos para as contas do Amazon S3, o caminho de destino deve conter, no mínimo, um nome de bucket. O S3 não dá suporte nativo a namespaces hierárquicos, mas você pode utilizar prefixos para imitar uma estrutura de diretório. Você pode incluir prefixos no caminho de atalho para restringir ainda mais o escopo dos dados acessíveis por meio do atalho. Quando você acessa dados por meio de um atalho do S3, os prefixos são representados como pastas.

Observação

Os atalhos S3 são somente leitura. Eles não dão suporte a operações de gravação, independentemente das permissões do usuário.

Acesso

Os atalhos do S3 devem apontar para o ponto de extremidade https do bucket S3.

Exemplo: https://bucketname.s3.region.amazonaws.com/

Observação

Você não precisa desabilitar a configuração de Acesso Público do Bloco S3 para sua conta S3 para que o atalho S3 funcione.

O acesso ao ponto de extremidade do S3 não deve ser bloqueado por um firewall de armazenamento ou Nuvem Privada Virtual.

Autorização

Os atalhos do S3 utilizam um modelo de autorização delegado. Nesse modelo, o criador do atalho especifica uma credencial para o atalho S3 e todo o acesso a esse atalho é autorizado utilizando essa credencial. A credencial delegada suportada é uma chave e um segredo para um usuário do IAM.

O usuário do IAM deve ter as seguintes permissões no bucket para o qual o atalho está apontando:

• S3:GetObject
• S3:GetBucketLocation
• S3:ListBucket

Os atalhos do S3 dão suporte a buckets S3 que usam chaves de bucket S3 para a criptografia SSE-KMS. Para acessar dados criptografados com criptografia SSE-KMS, o usuário deve ter permissões de criptografar/descriptografar para a chave bucket, caso contrário, receberá um erro "Proibido" (403). Para obter mais informações, consulte Configurando o bucket para usar uma Chave de Bucket S3 com SSE-KMS para novos objetos.

Atalhos do Google Cloud Storage

A API XML para Google Cloud Storage (GCS) pode ser usada para criar atalhos para o GCS. Quando você cria atalhos para o Google Cloud Storage, o caminho de destino deve conter no mínimo um nome de bucket. Você também pode restringir o escopo do atalho especificando ainda mais o prefixo ou a pasta para o qual deseja apontar dentro da hierarquia de armazenamento.

Observação

Os atalhos do GCS são somente leitura. Eles não dão suporte a operações de gravação, independentemente das permissões do usuário.

Acesso

Ao configurar a conexão para um atalho do GCS, é possível especificar o ponto de extremidade global do serviço de armazenamento ou usar um ponto de extremidade específico do bucket.

• Exemplo de ponto de extremidade global: https://storage.googleapis.com
• Exemplo de ponto de extremidade específico do bucket: https://<BucketName>.storage.googleapis.com

Autorização

Os atalhos do GCS usam um modelo de autorização delegada. Nesse modelo, o criador do atalho especifica uma credencial para o atalho do GCS e todo o acesso a esse atalho é autorizado utilizando essa credencial. A credencial delegada suportada é uma chave HMAC e um segredo para uma conta de serviço ou uma conta de usuário.

A conta deve ter permissão para acessar os dados dentro do bucket do GCS. Se o endpoint específico do bucket foi usado na conexão para o atalho, a conta deve ter as seguintes permissões:

• storage.objects.get
• stoage.objects.list

Se o endpoint global foi usado na conexão para o atalho, a conta também deve ter a seguinte permissão:

• storage.buckets.list

Atalhos do Dataverse

A integração direta do Dataverse com o Microsoft Fabric permite que as organizações estendam seus aplicativos empresariais e processos de negócios do Dynamics 365 para o Fabric. Essa integração é realizada por meio de atalhos, que podem ser criados de duas maneiras: por meio do portal do fabricante do PowerApps ou por meio do Fabric diretamente.

Observação

Os atalhos do Dataverse são somente leitura. Eles não dão suporte a operações de gravação, independentemente das permissões do usuário.

Criando atalhos no portal para criadores do PowerApps

Os usuários autorizados do PowerApps podem acessar o portal do criador do PowerApps e usar o recurso Vincular ao Microsoft Fabric . A partir dessa única ação, um lakehouse é criado no Fabric e os atalhos são gerados automaticamente para cada tabela no ambiente do Dataverse.

Para obter mais informações, consulte Integração direta do Dataverse com o Microsoft Fabric.

Criar atalhos usando o Fabric

Os usuários do Fabric também podem criar atalhos para o Dataverse. Quando os usuários criam atalhos, eles podem selecionar o Dataverse, fornecer a URL do ambiente e procurar as tabelas disponíveis. Essa experiência permite que os usuários escolham quais tabelas trazer para o Fabric em vez de trazer todas as tabelas.

Observação

As tabelas do Dataverse devem primeiro estar disponíveis no Dataverse Managed Lake antes de ficarem visíveis na interface de criação de atalhos do Fabric. Se as tabelas não estiverem visíveis do Fabric, use o recurso Link para o Microsoft Fabric no portal do fabricante do PowerApps.

Autorização

Os atalhos do Dataverse utilizam um modelo de autorização delegado. Nesse modelo, o criador do atalho especifica uma credencial para o atalho do Dataverse e todo o acesso a esse atalho é autorizado usando essa credencial. O tipo de credencial delegada com suporte é a conta organizacional (OAuth2). A conta institucional deve ter permissões de administrador do sistema para acessar dados no Lake gerenciado pelo Dataverse.

Observação

Atualmente, os atalhos do Dataverse não oferecem suporte a Princípios de Serviço como tipo de autenticação.

Cache

O cache de atalho pode reduzir os custos de saída associados ao acesso aos dados entre nuvens. À medida que os arquivos são lidos por meio de um atalho externo, eles são armazenados em um cache para o espaço de trabalho do Fabric. As solicitações de leitura subsequentes são atendidas do cache e não do provedor de armazenamento remoto. O período de retenção para arquivos armazenados em cache pode ser definido de 1 a 28 dias. Cada vez que o arquivo é acessado, o período de retenção é redefinido. Se o arquivo no provedor de armazenamento remoto for mais recente do que o arquivo no cache, a solicitação será atendida do provedor de armazenamento remoto e então, o arquivo atualizado será armazenado no cache. Se um arquivo não tiver sido acessado por mais do que o período de retenção selecionado, ele será limpo do cache. Arquivos individuais com mais de 1 GB de tamanho não são armazenados em cache.

Observação

No momento, há suporte para o cache de atalho para atalhos de gateway de dados locais, compatíveis com GCS, S3, S3.

Para habilitar o cache para atalhos, abra o painel Configurações do espaço de trabalho. Escolha a guia OneLake. Alterne a configuração de cache para Ativar e selecione o Período de Retenção.

Também é possível limpar o cache a qualquer momento. Na mesma página de configurações, clique no botão Redefinir cache. Essa ação remove todos os arquivos do cache de atalho nesta área de trabalho.

Como os atalhos utilizam conexões de nuvem

A autorização de atalhos do ADLS e S3 é delegada utilizando conexões de nuvem. Ao criar um novo atalho do ADLS ou S3, você deve criar uma nova conexão ou selecionar uma conexão existente para a fonte de dados. Definir uma conexão para um atalho é uma operação de associação. Somente usuários com permissão na conexão podem executar a operação de associação. Se você não tiver permissões na conexão, não poderá criar novos atalhos utilizando essa conexão.

Segurança de atalho

Os atalhos exigem determinadas permissões para gerenciar e usar. A segurança dos atalhos do OneLake analisa as permissões necessárias para criar atalhos e acessar dados através deles.

Como os atalhos lidam com exclusões?

Os atalhos não executam exclusões em cascata. Ao excluir um atalho, você exclui apenas o objeto de atalho. Os dados no destino de atalho permanecem inalterados. No entanto, se você excluir um arquivo ou pasta dentro de um atalho e tiver permissões no destino de atalho para executar a operação de exclusão, os arquivos ou pastas serão excluídos no destino.

Por exemplo, considere um lakehouse com o caminho a seguir: MyLakehouse\Files\MyShortcut\Foo\Bar. MyShortcut é um atalho que aponta para uma conta do ADLS Gen2 que contém os diretórios Foo\Bar.

Você pode executar uma operação de exclusão no seguinte caminho: MyLakehouse\Files\MyShortcut. Nesse caso, o atalho MyShortcut é excluído do lakehouse, mas os arquivos e diretórios na conta do ADLS Gen2 Foo\Bar permanecem inalterados.

Você também pode executar uma operação de exclusão no seguinte caminho: MyLakehouse\Files\MyShortcut\Foo\Bar. Nesse caso, se você tiver permissões de gravação na conta do ADLS Gen2, o diretório Bar será excluído da conta do ADLS Gen2.

Exibição de linhagem do workspace

Ao criar atalhos entre vários itens do Fabric em um workspace, você pode visualizar as relações de atalho por meio da exibição de linhagem do workspace. Selecione o botão Exibição de linhagem ( ) no canto superior direito do Navegador de espaços de trabalho.

Observação

A exibição de linhagem tem como escopo um único workspace. Os atalhos para locais fora do workspace selecionado não são exibidos.

Limitações e considerações

• O número máximo de atalhos por item Fabric é 100.000. Nesse contexto, o termo item se refere a: aplicativos, lakehouses, warehouses, relatórios e muito mais.
• O número máximo de atalhos em um único caminho OneLake é 10.
• O número máximo de atalhos diretos para os links de atalho é 5.
• Os caminhos de destino de atalho ADLS e S3 não podem conter caracteres reservados da Seção 2.2 da RFC 3986. Para caracteres permitidos, consulte RFC 3968 seção 2.3.
• Os nomes de atalho, os caminhos pai e os caminhos de destino do OneLake não podem conter os caracteres “%” ou “+”.
• Os atalhos não dão suporte a caracteres não latinos.
• Não há suporte para a API de Cópia de Blob em atalhos do ADLS ou do S3.
• A função Copy não funciona em atalhos que apontam diretamente para contêineres do ADLS. É recomendável criar atalhos do ADLS para um diretório que esteja pelo menos um nível abaixo de um contêiner.
• Não é possível criar atalhos adicionais dentro dos atalhos do ADLS ou do S3.
• A linhagem de atalhos para Data Warehouses e Modelos Semânticos não está disponível no momento.
• Um atalho do Fabric é sincronizado com a origem quase instantaneamente, mas o tempo de propagação pode variar devido ao desempenho da fonte de dados, exibições armazenadas em cache ou problemas de conectividade de rede.
• Pode levar até um minuto para que a API de Tabela reconheça novos atalhos.
• Os atalhos do OneLake não suportam conexões com contas de armazenamento ADLS Gen2 que usam pontos de extremidade privados gerenciados. Para obter mais informações, consulte Pontos de extremidade privados gerenciados para o Fabric.

Conteúdo relacionado

• Criar um atalho para o OneLake
• Usar as APIs REST dos atalhos do OneLake