Partilhar via

Considerações principais sobre o Armazenamento do Azure Data Lake

  • Artigo

Saiba mais sobre as principais considerações de armazenamento para seus data lakes do Azure.

Gestão do ciclo de vida

O Armazenamento do Azure oferece diferentes camadas de acesso, o que permite armazenar dados de objeto de blob da maneira mais econômica possível. As camadas de acesso disponíveis incluem:

  • Quente: otimizado para armazenar dados acessados com frequência.
  • Cool: otimizado para armazenar dados acessados com pouca frequência. Os dados são armazenados por pelo menos 30 dias.
  • Nível frio: otimizado para armazenar dados acessados ou modificados com pouca frequência. Os dados são armazenados por pelo menos 90 dias. A camada de acesso infrequente tem custos de armazenamento inferiores e custos de acesso superiores em comparação com a camada de acesso esporádico.
  • Arquivo: otimizado para armazenar dados raramente acessados. Os dados são armazenados por pelo menos 180 dias com requisitos de latência flexíveis, na ordem das horas.

Importante

Não há compensações de confiabilidade, segurança, excelência operacional ou eficiência de desempenho entre as várias camadas de acesso on-line, o que deixa a escolha de uma camada online como uma decisão financeira, por blob, com base no tamanho dos dados de acesso à carga de trabalho, interações operacionais e tempo antes que o blob seja excluído. Selecione a camada correta, por blob, com base em um cálculo dos fatores anteriores. Para obter mais informações, consulte Planejar e gerenciar custos para o Armazenamento de Blobs do Azure .

Considere as seguintes informações ao usar camadas de acesso:

  • Apenas os níveis de acesso Hot and Cool podem ser definidos no nível da conta. A camada de acesso Arquivo morto não está disponível no nível da conta.

  • As camadas Hot, Cool e Archive podem ser definidas no nível de blob durante o upload ou após o upload.

  • Os dados nas camadas Cool e Cold têm uma disponibilidade ligeiramente menor, mas oferecem as mesmas características de alta durabilidade, latência de recuperação e taxa de transferência que os dados da camada Quente. Para dados nos níveis Cool ou Cold, uma disponibilidade ligeiramente menor e custos de acesso mais altos podem ser compensações aceitáveis para custos gerais de armazenamento mais baixos em comparação com o nível Hot.

  • O armazenamento de arquivo armazena dados off-line e oferece os menores custos de armazenamento. No entanto, ele também carrega os mais altos custos de reidratação de dados e acesso.

Para obter mais informações, consulte Camadas de acesso para dados de blob.

Atenção

Para análises em escala de nuvem, recomendamos que você implemente o gerenciamento do ciclo de vida usando um microsserviço personalizado e considere cuidadosamente o impacto de mover dados detetáveis do usuário para o armazenamento refrigerado.

Você só deve mover seções do seu data lake para a camada legal para cargas de trabalho bem compreendidas.

Conectividade de data lakes

Cada um dos seus data lakes deve usar pontos de extremidade privados injetados na rede virtual da sua zona de aterrissagem de dados. Para fornecer acesso entre zonas de aterrissagem, conecte suas zonas de aterrissagem de dados por meio de emparelhamento de rede virtual. Essa conexão fornece uma solução ideal do ponto de vista de custo e controle de acesso.

Para obter mais informações, consulte Pontos de extremidade privados e Zona de aterrissagem de gerenciamento de dados para zona de aterrissagem de dados.

Importante

Os dados de uma zona de aterrissagem de dados podem ser acessados de outra zona de aterrissagem de dados por meio do emparelhamento de rede virtual entre as zonas. Isso é feito usando os pontos de extremidade privados associados a cada conta data lake. Recomendamos desativar todo o acesso público aos seus lagos e usar terminais privados. Sua equipe de operações de plataforma deve controlar a conectividade de rede em suas zonas de aterrissagem de dados.

Eliminação recuperável para contentores

A exclusão suave para contêineres protege seus dados contra exclusão acidental ou maliciosa. Se você habilitar a exclusão suave de contêiner para sua conta de armazenamento, os contêineres excluídos e seu conteúdo serão retidos no Armazenamento do Azure por um período de tempo que você escolher. Durante o período de retenção de dados, você pode restaurar contêineres excluídos anteriormente. A restauração de um contêiner também restaura todos os blobs que estavam dentro desse contêiner quando ele foi excluído.

Habilite os seguintes recursos de proteção de dados para obter proteção de dados de blob de ponta a ponta:

Aviso

A exclusão de uma conta de armazenamento não pode ser desfeita. A exclusão suave de contêiner não protege contra a exclusão de conta de armazenamento, apenas contra a exclusão de contêineres dentro de uma conta. Para proteger uma conta de armazenamento contra exclusão, configure um bloqueio no recurso da conta de armazenamento. Para obter mais informações sobre como bloquear recursos do Azure Resource Manager, consulte Bloquear recursos para evitar alterações inesperadas.

Monitorização

Em uma zona de aterrissagem de dados, todo o monitoramento deve ser enviado para sua assinatura de gerenciamento em escala empresarial para análise.

Para saber mais sobre os dados de monitoramento que o Armazenamento do Azure usa, consulte Monitorando recursos do Azure com o Azure Monitor. Para obter mais informações sobre os logs e métricas que o Armazenamento do Azure cria, consulte Monitorando o Armazenamento de Blobs do Azure.

As entradas de log só são criadas se as solicitações forem feitas no ponto de extremidade do serviço. Os tipos de solicitações autenticadas registradas são:

  • Pedidos com êxito
  • Pedidos falhados, incluindo tempo limite, limitação, rede, autorização e outros erros
  • Solicitações que usam uma assinatura de acesso compartilhado (SAS) ou OAuth, incluindo solicitações com falha e bem-sucedidas
  • Solicitações para dados de análise, como dados de log clássicos no $logs contêiner e dados de métrica de classe nas $metric tabelas

As solicitações feitas pelo próprio serviço de armazenamento, como criação ou exclusão de log, não são registradas. Os tipos de pedidos anónimos registados são:

  • Pedidos com êxito
  • Erros de servidor
  • Erros de tempo limite para o cliente e o servidor
  • Solicitações HTTP GET com falha com o código de erro 304 (Not Modified)

Todas as outras solicitações anônimas com falha não são registradas.

Importante

Defina sua política de monitoramento padrão para auditar o armazenamento e enviar logs para sua assinatura de gerenciamento em escala empresarial.

Próximos passos