O Domínio 3 do conteúdo oficial do DP-900 inclui "Descrever os recursos do Azure Storage", com Blob Storage, Azure Files e Table Storage como itens. As perguntas não param nos nomes, como "imagens vão para o Blob". Muitas vezes descem um nível e perguntam sobre os períodos mínimos de retenção de cada camada, políticas de ciclo de vida, PartitionKey e RowKey ou os protocolos dos compartilhamentos de arquivos.
Este post é um complemento de Fundamentos de dados não relacionais da nossa série de estudos do DP-900. Partindo do básico sobre tipos de blob, camadas de acesso e redundância visto lá, ele percorre as regras detalhadas que a prova cobra: a estrutura da conta de armazenamento, o gerenciamento do ciclo de vida do Blob, o namespace hierárquico do Data Lake Storage Gen2, os protocolos e a capacidade do Azure Files e o design de chaves no Table Storage.
---
Contas de armazenamento: o ponto de partida de todo o Azure Storage
Imagine um condomínio. Dentro dele há um depósito para guardar pertences, um escritório compartilhado usado por vários moradores e um livro de registros na portaria. No Azure Storage, a conta de armazenamento faz o papel do condomínio, e dentro dela ficam os contêineres de blobs, os compartilhamentos de arquivos, as tabelas e as filas.
| Serviço | Hierarquia | Como é acessado | |------|------|------| | Blob Storage | Conta de armazenamento → contêiner → blob | API do Blob sobre HTTP(S) | | Data Lake Storage Gen2 | Conta de armazenamento (namespace hierárquico ativado) → sistema de arquivos → diretório → arquivo | API do Blob mais um driver de sistema de arquivos para análise | | Azure Files | Conta de armazenamento → compartilhamento → diretório → arquivo | Montagem SMB e NFS | | Table Storage | Conta de armazenamento → tabela → entidade | API REST baseada em chaves |
A redundância, que define como os dados são replicados, é configurada por conta de armazenamento. O LRS mantém três cópias em um único datacenter, e o ZRS mantém cópias em três zonas de disponibilidade da mesma região. O GRS e o GZRS replicam de forma assíncrona para uma região secundária a centenas de quilômetros, e escolhendo RA-GRS ou RA-GZRS (RA de acesso de leitura) você pode ler da região secundária mesmo antes de um failover. O Azure Files, porém, não suporta leitura a partir da região secundária.
Dica de prova: "Proteger-se contra uma queda regional e ler da região secundária mesmo antes do failover" → RA-GRS ou RA-GZRS. "Os dados precisam continuar aceitando gravações mesmo que um datacenter da região caia" → ZRS.
---
Blob Storage: camadas de acesso e gerenciamento do ciclo de vida
Tipos de blob e tamanhos máximos
Os blobs ficam em contêineres, e o acesso é controlado no nível do contêiner. As pastas dentro de um contêiner são pastas virtuais criadas com o caractere "/" no nome do blob, então não é possível definir permissões nem executar operações em massa no nível da pasta.
| Tipo | Estrutura | Tamanho máximo | Uso | |------|------|------|------| | Blob de blocos | Até 50.000 blocos de até 4.000 MiB cada | Cerca de 190,7 TiB | Arquivos grandes que mudam pouco, como imagens, vídeos e documentos | | Blob de páginas | Páginas fixas de 512 bytes | 8 TiB | Discos de máquinas virtuais, leituras e gravações aleatórias | | Blob de acréscimo | Blocos só podem ser adicionados ao final | Cerca de 195 GiB | Dados que só crescem no final, como logs |
Camadas de acesso e cobrança por exclusão antecipada
As quatro camadas, Hot, Cool, Cold e Archive, equilibram de forma diferente o custo de armazenamento e o custo de acesso. A Hot é a padrão e, quanto mais para baixo, mais barato fica armazenar e mais caro fica ler os dados. Os dados precisam ficar pelo menos 30 dias na Cool, 90 na Cold e 180 na Archive. Se você os excluir ou movê-los para outra camada antes disso, é aplicada uma cobrança proporcional por exclusão antecipada dos dias restantes. Por exemplo, se você excluir um blob 21 dias depois de movê-lo para a Cool, paga os nove dias de armazenamento que faltavam.
!Camadas de acesso do Blob e ciclo de vida
A Archive é uma camada offline, então não dá para ler nem modificar um blob diretamente nela. Primeiro é preciso reidratá-lo, mudando a camada para Hot, Cool ou Cold. A prioridade padrão pode levar até 15 horas para objetos com menos de 10 GB, enquanto a prioridade alta, mais cara, pode terminar em menos de uma hora e é indicada para restaurações urgentes.
Políticas de gerenciamento do ciclo de vida
Dados recém-criados são muito usados e, com o tempo, quase nada. Uma política de gerenciamento do ciclo de vida usa regras escritas em JSON para mover blobs para camadas mais baratas ou excluí-los automaticamente.
Condições: dias desde a criação, a última modificação ou o último acesso (quando o rastreamento de acesso está ativado) Ações: mudar a camada para Cool, Cold ou Archive; excluir versões atuais, versões anteriores ou snapshots Filtros: selecionar blobs por prefixo do nome ou por tags de índice de blob Custo: a política em si é gratuita e você paga só as operações de mudança de camada. Depois de alterar as regras, pode levar até 24 horas para que entrem em vigor.
Dica de prova: "Mover automaticamente os blobs para a Cool 30 dias após o upload, para a Archive após 180 dias e excluí-los após sete anos" → política de gerenciamento do ciclo de vida. "Um blob na Archive não pode ser lido imediatamente" → primeiro é preciso reidratá-lo.
---
Data Lake Storage Gen2: o que o namespace hierárquico muda
O Data Lake Storage Gen2 não é um serviço separado. Ele é o Blob Storage com a opção de namespace hierárquico ativada na conta de armazenamento. Você pode ativá-la ao criar a conta ou atualizar uma conta existente, mas a atualização é de mão única: depois não dá para voltar a um namespace plano.
Quando as pastas que só eram imitadas com "/" nos nomes viram diretórios de verdade, duas coisas mudam.
Operações atômicas de diretório: renomear, mover ou excluir um diretório vira uma única atualização da entrada do diretório pai. Com um namespace plano, era preciso processar milhões de blobs um a um. Spark e Hive renomeiam pastas temporárias de saída no fim de cada trabalho, então os trabalhos de análise terminam muito mais rápido. ACLs compatíveis com POSIX: além do RBAC do Azure, você pode definir permissões detalhadas de leitura, gravação e execução para cada arquivo e pasta.
| Aspecto | Blob Storage (namespace plano) | Data Lake Storage Gen2 (namespace hierárquico) | |------|------|------| | Pastas | Pastas virtuais criadas com "/" nos nomes | Diretórios reais | | Renomear um diretório | Blobs processados um a um | Uma única operação atômica | | Permissões detalhadas | Principalmente no nível do contêiner | ACLs POSIX por arquivo e pasta | | Uso principal | Armazenamento de objetos lidos e gravados por aplicativos | Análise em larga escala com Databricks, Spark e ferramentas semelhantes |
As camadas de acesso e o gerenciamento do ciclo de vida do Blob continuam valendo, e o OneLake do Microsoft Fabric é construído sobre o Data Lake Storage Gen2.
Dica de prova: "Armazenamento para análise de big data que precisa de permissões por pasta e operações de diretório" → Data Lake Storage Gen2 com o namespace hierárquico ativado.
---
Azure Files: compartilhamentos de arquivos na nuvem
O Azure Files é o servidor de arquivos do escritório levado para a nuvem. Vários computadores montam o mesmo compartilhamento como unidade de rede e trabalham nele juntos.
| Protocolo | Clientes suportados | Requisitos | |------|------|------| | SMB | Windows, Linux, macOS | Disponível em HDD e em SSD | | NFS | Linux | Só na camada de mídia SSD, com acesso por endpoint privado ou endpoint de serviço em uma rede virtual |
Há duas camadas de mídia, SSD e HDD. Use SSD quando precisar de latência na casa de um dígito de milissegundos e HDD quando o custo pesar mais. Os compartilhamentos HDD de pagamento conforme o uso ainda se dividem em três camadas de acesso: otimizada para transações, hot e cool; quanto mais fria a camada, menor o preço de armazenamento e maior o preço das transações.
Capacidade: um único arquivo pode ter até 4 TiB, e um compartilhamento de pagamento conforme o uso pode crescer até 100 TiB. Azure File Sync: mantém em cache, em um Windows Server local, os arquivos mais usados e os sincroniza com o compartilhamento do Azure, dando às filiais acesso local rápido enquanto os dados ficam na nuvem. Snapshots: você pode criar até 200 cópias somente leitura de um ponto no tempo por compartilhamento.
Dica de prova: "Um compartilhamento que servidores Linux montam via NFS" → Azure Files na camada SSD. "Manter localmente os arquivos mais usados no servidor de uma filial enquanto a cópia principal fica no Azure" → Azure File Sync.
---
Table Storage: PartitionKey e RowKey
Uma tabela do Table Storage só compartilha o nome com uma tabela relacional. Ela é um armazenamento chave-valor sem esquema em que cada linha (entidade) pode ter colunas diferentes, e não tem chaves estrangeiras, relacionamentos, procedimentos armazenados nem views. Por isso os dados costumam ser guardados de forma desnormalizada, com todos os telefones e endereços de um cliente em uma única linha.
Uma entidade pode ter até 255 propriedades, incluindo as três propriedades do sistema (PartitionKey, RowKey e Timestamp), e até 1 MiB de dados no total. O Timestamp registra o horário da última modificação; ele é gerenciado pelo servidor e o usuário não pode alterá-lo.
Design de chaves e desempenho das consultas
A PartitionKey agrupa linhas relacionadas na mesma partição, e a RowKey identifica cada linha de forma única dentro da partição. Juntas, elas formam a chave única da tabela inteira, e as linhas de uma partição são armazenadas na ordem da RowKey.
| Tipo de consulta | Condição | Velocidade | |------|------|------| | Consulta pontual | PartitionKey e RowKey informadas | A mais rápida; uma única linha | | Consulta d