Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve problemas e limitações conhecidos do Azure Data Lake Storage para contas que têm ativada a funcionalidade hierárquica de espaço de nomes. Use esta informação para gerir os seus fluxos de trabalho de dados e evitar potenciais armadilhas ao utilizar várias APIs e integrações.
Nota
Alguns dos recursos descritos neste artigo podem não ser suportados em contas com suporte a NFS (Network File System) 3.0 habilitado. Para exibir uma tabela que mostra o impacto do suporte a recursos quando vários recursos são habilitados, consulte Suporte a recursos de Armazenamento de Blob em contas de Armazenamento do Azure.
Suporte a funcionalidades, serviço e plataforma
A maioria das funcionalidades de armazenamento Blob, integrações de serviços Azure e plataformas open-source são suportadas em contas que têm um namespace hierárquico. Para listas completas, veja:
- Funcionalidades do Armazenamento de Blobs disponíveis no Azure Data Lake Storage
- Serviços do Azure que suportam o Armazenamento Azure Data Lake
- Plataformas open-source que suportam o Azure Data Lake Storage
APIs de armazenamento Blob
As APIs de armazenamento Data Lake, NFS 3.0 e Blob podem operar nos mesmos dados.
Esta secção descreve problemas e limitações ao utilizar APIs de blob, NFS 3.0 e APIs de armazenamento Data Lake para operar nos mesmos dados.
Não é possível usar APIs de blob, NFS 3.0 e APIs de armazenamento Data Lake para gravar na mesma instância de um arquivo. Se escrever num ficheiro utilizando as APIs do Data Lake Storage ou o NFS 3.0, os blocos desse ficheiro não ficam visíveis nas chamadas à API de blobs Get Block List. A única exceção é quando se está a substituir. Pode sobrescrever um ficheiro ou blob utilizando quer a API quer o NFS 3.0 com a opção zero-truncate (uma operação ao estilo POSIX que trunca o ficheiro para zero bytes antes da escrita).
Não é possível sobrescrever blobs criados através de uma operação do Data Lake Storage, como, por exemplo, a operação Path - Create, utilizando as operações PutBlock ou PutBlockList. No entanto, pode sobrescrever estes blobs usando uma operação PutBlob , sujeito ao tamanho máximo permitido do blob imposto pela versão API correspondente que o PutBlob utiliza.
Quando você usa a operação Listar Blobs sem especificar um delimitador, os resultados incluem diretórios e blobs. Se você optar por usar um delimitador, use apenas uma barra (
/). Este é o único delimitador suportado.Se usares a API Delete Blob para eliminar um diretório, o diretório só é eliminado se estiver vazio. Esta condição significa que não pode usar a API Blob para eliminar diretórios recursivamente.
Estas APIs REST de Blob não são suportadas:
- Colocar Blob (Página)
- Colocar página
- Obter intervalos de páginas
- Blob Incremental de Cópia
- Colocar página a partir do URL
- Anexar selo de Blob
Não há suporte para discos de VM não gerenciados em contas que têm um namespace hierárquico. Se você quiser habilitar um namespace hierárquico em uma conta de armazenamento, coloque discos de VM não gerenciados em uma conta de armazenamento que não tenha o recurso de namespace hierárquico habilitado.
Suporte para definir listas de controlo de acesso (ACLs) recursivamente no Azure Data Lake Storage
A capacidade de aplicar alterações de ACL recursivamente do diretório pai para itens filho está geralmente disponível. Na versão atual desta funcionalidade, pode aplicar alterações de ACL usando Explorador de Armazenamento do Azure, PowerShell, CLI do Azure e os SDKs .NET, Java, Python e Node.js. O suporte ainda não está disponível para o portal do Azure.
Listas de controle de acesso (ACL) e acesso de leitura anônimo
Se for concedido acesso anónimo de leitura a um contentor, então as ACLs não têm efeito sobre esse contentor nem sobre os ficheiros desse contentor. Esta restrição afeta apenas pedidos de leitura. Os pedidos de escrita continuam a respeitar os ACLs. Exigir autorização para todos os pedidos a dados em blob.
Pontos finais privados para Azure Data Lake Storage
Se estiveres a usar endpoints privados para aceder ao Azure Data Lake Storage (uma conta de armazenamento com namespace hierárquico ativado), precisas de criar uma para os sub-recursos do blob e do dfs. Operações que visam o endpoint Data Lake Storage (dfs) podem ser redirecionadas para o endpoint Blob, e algumas operações (como gerir ACLs, criar diretórios e eliminar diretórios) requerem um endpoint privado DFS. Criar endpoints privados para ambos os sub-recursos garante que todas as operações são concluídas com sucesso. Para obter mais informações, consulte Utilização de pontos finais privados para o Armazenamento do Azure.
AzCopy com Azure Data Lake Storage
Quando usas o AzCopy com contas que têm um namespace hierárquico ativado, só o AzCopy v10 suporta as APIs obrigatórias do Data Lake Storage. Use apenas a versão mais recente do AzCopy (AzCopy v10). Versões anteriores, como o AzCopy v8.1, não são suportadas.
Explorador de Armazenamento do Azure com Azure Data Lake Storage
Quando usar o Explorador de Armazenamento do Azure com contas de armazenamento que tenham um namespace hierárquico ativado, use apenas versões 1.6.0 ou superiores. Versões anteriores não suportam as APIs hierárquicas de namespace necessárias para gerir ficheiros e diretórios.
Navegador de armazenamento no portal do Azure
No navegador de armazenamento que aparece no portal do Azure, você não pode acessar um arquivo ou pasta especificando um caminho. Em vez disso, você deve navegar pelas pastas para chegar a um arquivo. Portanto, se uma ACL concede a um utilizador acesso de leitura a um ficheiro mas não de leitura a todas as pastas que conduzem ao ficheiro, esse utilizador não pode visualizar o ficheiro no navegador de armazenamento.
Aplicações de terceiros
Aplicações de terceiros que usam APIs REST continuam a funcionar se as utilizar com o Data Lake Storage. Aplicações que chamam APIs Blob têm probabilidade de funcionar.
Driver de Blob de Armazenamento do Windows Azure (WASB)
Atualmente, o driver WASB, que foi projetado para funcionar apenas com a API de Blob, encontra problemas em alguns cenários comuns. Especificamente, quando é um cliente de uma conta de armazenamento habilitada para namespace hierárquico. O acesso multi-protocolo no Data Lake Storage não mitiga estes problemas.
Não é suportado usar o driver WASB como cliente de uma conta de armazenamento com namespace hierárquico habilitado. Em vez disso, use o driver Azure Blob File System (ABFS) no seu ambiente Hadoop. Se está a tentar migrar para fora de um ambiente Hadoop local com uma versão anterior ao Hadoop branch-3, abra um ticket de Suporte Azure para ajudar a determinar o caminho certo para a sua organização.
Eliminação recuperável de blobs no Azure Data Lake Storage
Em contas de armazenamento que têm um namespace hierárquico, se renomear diretórios pais para ficheiros ou diretórios apagados suavemente, o portal Azure pode não mostrar corretamente os itens apagados suavemente. Nesses casos, use PowerShell ou CLI do Azure para listar e restaurar os itens que foram apagados de forma suave.
Subscrições de eventos no Azure Data Lake Storage
Em contas de armazenamento que têm um espaço de nomes hierárquico, se a sua conta tiver uma subscrição de eventos, as operações de leitura no ponto final secundário (a réplica só de leitura em contas de armazenamento com redundância geográfica) resultam em erro. Para resolver esse problema, remova as assinaturas de eventos. Usar o endpoint de Data Lake Storage (abfss://URI) para contas habilitadas com namespace não hierárquico não gera eventos, mas o endpoint do blob (wasb:// URI) gera eventos.
Gorjeta
O acesso de leitura ao endpoint secundário está apenas disponível quando o utilizador ativa o armazenamento redundante geográfico de acesso apenas leitura (RA-GRS) ou o armazenamento redundante de zona geográfica de acesso apenas leitura (RA-GZRS).