Atalhos do OneLake

Os atalhos no Microsoft OneLake permitem unificar seus dados entre domínios, nuvens e contas, criando um único data lake virtual para toda a empresa. Todas as experiências e mecanismos analíticos do Fabric podem se conectar 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, portanto, 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 desnecessárias de dados e reduzir a latência do processo associada a cópias de dados e armazenamento temporário.

O que são atalhos?

Os atalhos são objetos no OneLake que apontam para outros locais de armazenamento. A localização pode ser interna ou externa ao OneLake. O local para o qual um atalho aponta é conhecido como o caminho de destino do atalho. A localização onde o atalho aparece é conhecida como caminho de atalho. Os atalhos aparecem como pastas no OneLake e qualquer carga de trabalho ou serviço que tenha acesso ao OneLake pode usá-los. Os atalhos funcionam como ligações simbólicas. 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 quebrado.

Onde posso criar atalhos?

Você pode criar atalhos nos Lakehouses e em bancos de dados da Kusto Query Language (KQL). Além disso, os atalhos criados 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 locais no local ou restritos à rede com o uso do gateway de dados local do Fabric (OPDG).

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

Casa do Lago

Ao criar atalhos num lakehouse, deve compreender a estrutura de pastas do item. Lakehouses são compostos por duas pastas de nível superior: a pasta Tables e a pasta Files. A pasta Tables representa a parte gerida da data lakehouse para conjuntos de dados estruturados. A pasta Files é a parte não gerida do lakehouse para dados não estruturados ou semiestruturados.

Na pasta Tabelas, você só pode criar atalhos no nível superior. Os atalhos não são suportados em subdiretórios da pasta Tabelas. Os atalhos na seção de 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 de tabelas podem ser vinculados a uma única tabela ou a um esquema, que é uma pasta pai para várias tabelas.

Nota

O formato Delta não suporta tabelas com caracteres de espaço no nome. Qualquer atalho contendo um espaço no nome não será reconhecido como uma tabela Delta no lakehouse.

Na pasta Arquivos, não há restrições sobre onde você pode criar atalhos. Você pode criá-los em qualquer nível da hierarquia de pastas. A descoberta de tabela não acontece na pasta Arquivos . Os atalhos aqui podem apontar para sistemas de armazenamento internos (OneLake) e externos com dados em qualquer formato.

Base de dados KQL

Quando você cria um atalho em um banco de dados KQL, ele aparece 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 do Kusto Query Language.

Onde posso aceder aos atalhos?

Qualquer serviço Fabric ou não-Fabric que possa aceder a dados no OneLake pode usar atalhos. Os atalhos são transparentes para qualquer serviço que acesse dados por meio da API do OneLake. Os atalhos aparecem apenas como outra pasta no lago. Apache Spark, SQL, Real-Time Intelligence e Analysis Services podem usar atalhos ao consultar dados.

Apache Spark

Os notebooks do Apache Spark e os trabalhos do Apache Spark podem usar atalhos que são criados no OneLake. Os caminhos de arquivo relativos podem ser usados para ler dados diretamente dos atalhos. Além disso, se criares um atalho na seção Tabelas do lakehouse e ele estiver no formato Delta, podes lê-lo como uma tabela gerida usando a sintaxe 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 aceder aos dados na secção Tabelas de um lakehouse através do endpoint de análises SQL para o lakehouse. Pode aceder ao terminal de análises SQL através do selector de modo da lakehouse ou através do SQL Server Management Studio (SSMS).

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

Informação 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 do Kusto Query Language.

external_table('MyShortcut')
| take 100

Serviços de Análise

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

não tecido

Aplicativos e serviços fora da malha também podem acessar atalhos por meio da API OneLake. O OneLake suporta um subconjunto das APIs de armazenamento ADLS Gen2 e Blob. Para saber mais sobre a API do OneLake, consulte Acesso do OneLake com APIs.

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

Tipos de atalhos

Os atalhos do OneLake suportam várias fontes de dados do sistema de arquivos. Isso inclui locais internos do OneLake, Azure Data Lake Storage (ADLS) Gen2, Amazon S3, sistemas compatíveis com S3, Google Cloud Storage (GCS) e Dataverse.

Atalhos internos do OneLake

Os atalhos internos do OneLake permitem que você faça referência a dados em itens de malha existentes, incluindo:

• Bases de dados KQL
• Casas dos lagos
• Catálogos espelhados do Azure Databricks
• Bancos de dados espelhados
• Modelos semânticos
• Bases de dados SQL
• Armazéns

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

Quando um usuário acessa dados por meio de um atalho para outro local do OneLake, o OneLake usa a identidade do usuário chamador 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 chamador não é passada para o destino de atalho. Em vez disso, a identidade do proprietário do item de chamada é passada, delegando o acesso ao utilizador que faz a chamada.

Atalhos do Azure Data Lake Storage

Quando você cria atalhos para contas de armazenamento Gen2 do Azure Data Lake Storage (ADLS), 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.

Nota

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

Acesso

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

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

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

Autorização

Os atalhos do ADLS usam um modelo de autorização delegada. Neste modelo, o criador do atalho especifica uma credencial para o atalho ADLS e todo o acesso a esse atalho é autorizado usando essa credencial. Os atalhos ADLS suportam os seguintes tipos de autorização delegada:

• Conta organizacional - deve ter a função de 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 função de Delegador na conta de armazenamento, além de acesso a arquivos ou diretórios concedido na conta de armazenamento.
• Entidade de serviço - deve ter a função de 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 Função de delegante na conta de armazenamento mais acesso a arquivos ou diretórios concedido na conta de armazenamento.
• Identidade do espaço de trabalho - deve ter a função de 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 Função de delegante na conta de armazenamento mais acesso a arquivos ou diretórios concedido na conta de armazenamento.
• Assinatura de Acesso Compartilhado (SAS) - deve incluir pelo menos as seguintes permissões: Ler, Listar e Executar.

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

Importante

O requisito Gerar uma chave de delegação de usuário não é imposto atualmente quando uma identidade de espaço de trabalho é configurada para o espaço de trabalho e o tipo de autenticação de atalho ADLS é Conta Organizacional, Principal de Serviço ou Identidade de Espaço de Trabalho. No entanto, esse comportamento será restrito no futuro. Recomendamos certificar-se de 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 URL da conta de Armazenamento.

Exemplo: accountname ou https://accountname.blob.core.windows.net/

Autorização

Os atalhos de armazenamento Blob utilizam um modelo de autorização delegada. Neste modelo, o criador do atalho especifica uma credencial para o atalho e todo o acesso a esse atalho é autorizado usando essa credencial. Os atalhos de Blob suportam os seguintes tipos de autorização delegada:

• Conta organizacional - deve ter a função de 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 função de Delegador na conta de armazenamento, além de acesso a arquivos ou diretórios concedido na conta de armazenamento.
• Entidade de serviço - deve ter a função de 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 Função de delegante na conta de armazenamento mais acesso a arquivos ou diretórios concedido na conta de armazenamento.
• Identidade do espaço de trabalho - deve ter a função de 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 Função de delegante na conta de armazenamento mais acesso a arquivos ou diretórios concedido na conta de armazenamento.
• Assinatura de Acesso Compartilhado (SAS) - deve incluir pelo menos as seguintes permissões: Ler, Listar e Executar.

Atalhos do S3

Ao criar atalhos para contas do Amazon S3, o caminho de destino deve conter, pelo menos, um nome de bucket. O S3 não suporta nativamente namespaces hierárquicos, mas você pode usar prefixos para imitar uma estrutura de diretório. Você pode incluir prefixos no caminho de atalho para restringir ainda mais o escopo de dados acessíveis através do atalho. Quando você acessa dados por meio de um atalho do S3, os prefixos são representados como pastas.

Nota

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

Acesso

Os atalhos S3 devem apontar para o endpoint HTTPS do bucket S3.

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

Nota

Não é necessário desativar a configuração Bloquear Acesso Público do S3 para sua conta do S3 para que o atalho do S3 funcione.

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

Autorização

Os atalhos do S3 usam um modelo de autorização delegada. Neste modelo, o criador do atalho especifica uma credencial para o atalho do S3 e todo o acesso a esse atalho é autorizado usando 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 suportam buckets do S3 que usam chaves de bucket do S3 para criptografia SSE-KMS. Para acessar dados criptografados com criptografia SSE-KMS, o usuário deve ter permissões de criptografia/descriptografia para a chave do bucket, caso contrário, receberá um erro "Proibido" (403). Para obter mais informações, consulte para configurar o seu bucket para usar uma Chave de Bucket S3 com SSE-KMS para novos objetos.

Atalhos do Google Cloud Storage

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

Nota

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

Acesso

Ao configurar a ligação para um atalho GCS, podes especificar o endpoint global para o serviço de armazenamento ou utilizar um endpoint específico do bucket.

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

Autorização

Os atalhos do Google Cloud Storage (GCS) utilizam um modelo de autorização delegada. Neste modelo, o criador do atalho especifica uma credencial para o atalho GCS e todo o acesso a esse atalho é autorizado usando essa credencial. A credencial delegada suportada é uma chave HMAC e um segredo para uma conta de Serviço ou conta de Utilizador.

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

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

Se o ponto de extremidade global foi usado na conexão para o atalho, a conta deve também 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 corporativos 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 criador do PowerApps ou diretamente por meio do Fabric.

Nota

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

Criando atalhos através do portal PowerApps Maker

Os utilizadores autorizados do PowerApps podem aceder ao portal do fabricante do PowerApps e usar o recurso Link to Microsoft Fabric. A partir desta única ação, cria-se um lakehouse no Fabric e geram-se automaticamente atalhos para cada tabela no ambiente do Dataverse.

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

Criando atalhos através do Fabric

Os utilizadores da plataforma Fabric também podem criar atalhos para o Dataverse. Quando os usuários criam atalhos, eles podem selecionar Dataverse, fornecer a URL do ambiente e navegar nas 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.

Nota

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

Autorização

Os atalhos do Dataverse usam um modelo de autorização delegada. Neste modelo, o criador do atalho especifica uma credencial para o atalho 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 organizacional deve ter a permissão de administrador do sistema para acessar dados no Dataverse Managed Lake.

Nota

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

Armazenamento em cache

O cache de atalho pode reduzir os custos de saída associados ao acesso a dados entre nuvens. À medida que os ficheiros são lidos através de um atalho externo, os ficheiros são armazenados numa cache para o espaço de trabalho Fabric. As solicitações de leitura subsequentes são atendidas a partir do cache em vez 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 pelo provedor de armazenamento remoto e o arquivo atualizado será armazenado em cache. Se um arquivo não tiver sido acessado por mais do que o período de retenção selecionado, ele será removido do cache. Arquivos individuais com mais de 1 GB de tamanho não são armazenados em cache.

Nota

Atualmente, há suporte para cache de atalhos para GCS, S3, S3 compatível e atalhos de passarelas de dados locais.

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 Ativado e selecione o Período de Retenção.

O cache também pode ser limpo a qualquer momento. Na mesma página de definições, selecione o botão Limpar cache. Esta ação remove todos os arquivos do cache de atalho neste espaço de trabalho.

Como os atalhos utilizam conexões na nuvem

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

Segurança de atalho

Os atalhos requerem determinadas permissões para gerir e utilizar. A segurança de atalhos do OneLake examina as permissões necessárias para criar atalhos e acessar dados usando-os.

Como os atalhos lidam com eliminações?

Os atalhos não executam deleçõ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 uma casa no lago com o seguinte caminho: MyLakehouse\Files\MyShortcut\Foo\Bar. MyShortcut é um atalho que aponta para uma conta ADLS Gen2 que contém os diretórios Foo\Bar.

Você pode executar uma operação de eliminação no seguinte caminho: MyLakehouse\Files\MyShortcut. Nesse caso, o atalho MyShortcut é eliminado da lakehouse, mas os ficheiros e diretórios na conta 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 forem escritas permissões na conta ADLS Gen2, o diretório Bar será excluído da conta ADLS Gen2.

Vista de linhagem do espaço de trabalho

Ao criar atalhos entre vários itens do Fabric num espaço de trabalho, pode visualizar as relações de atalho através da visão de linhagem do espaço de trabalho. Selecione o botão vista de linhagem ( ) no canto superior direito do explorador de espaços de trabalho.

Nota

A vista de linhagem tem como escopo um único espaço de trabalho. Os atalhos para locais fora do espaço de trabalho selecionado não aparecem.

Limitações e considerações

• O número máximo de atalhos por item do Fabric é 100.000. Neste contexto, o termo item refere-se a: aplicativos, lakehouses, armazéns, relatórios e muito mais.
• O número máximo de atalhos em um só caminho do OneLake é 10.
• O número máximo de atalhos diretos para links de atalho é 5.
• Os caminhos de destino de atalho ADLS e S3 não podem conter caracteres reservados da seção 2.2 do RFC 3986. Para caracteres permitidos, consulte RFC 3968 seção 2.3.
• Atalhos do OneLake, caminhos de origem e caminhos de destino não podem conter os caracteres "%" ou "+".
• Os atalhos não suportam caracteres de alfabetos não latinos.
• A API Copy Blob não é suportada para atalhos ADLS ou S3.
• A função de cópia não funciona em atalhos que apontam diretamente para contentores ADLS. É recomendável criar atalhos ADLS para um diretório que esteja pelo menos um nível abaixo de um contêiner.
• Não é possível criar mais atalhos 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 sincroniza com a fonte quase instantaneamente, mas o tempo de propagação pode variar devido ao desempenho da fonte de dados, vistas 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 utilizam pontos de extremidade privados geridos. Para obter mais informações, consulte pontos de extremidade privados geridos para o Fabric.

Conteúdos relacionados

• Criar um atalho para o OneLake
• Utilizar atalhos de APIs REST do OneLake