Melhores práticas para usar o Azure Data Lake Storage

Este artigo fornece diretrizes de práticas recomendadas que ajudam a otimizar o desempenho, reduzir custos e proteger sua conta do Armazenamento do Microsoft Azure habilitada para o Data Lake Storage.

Encontrar documentação

O Azure Data Lake Storage não é um serviço dedicado ou um tipo de conta. Trata-se de um conjunto de recursos que dão suporte a cargas de trabalho analíticas com alta taxa de transferência. A documentação do Data Lake Storage fornece as melhores práticas e as diretrizes para usar essas funcionalidades. Para todos os outros aspectos do gerenciamento da conta, como configurar a segurança de rede, projetar soluções de alta disponibilidade e recuperação de desastres, consulte a documentação do Armazenamento de Blobs.

Avaliar o suporte a recursos e problemas conhecidos

Use o padrão a seguir ao configurar sua conta para usar os recursos de Armazenamento de Blobs.

1. Examine o artigo Suporte ao recurso de Armazenamento de Blobs em contas do Armazenamento do Azure para determinar se um recurso tem suporte total em sua conta. Alguns recursos ainda não têm suporte ou têm suporte parcial em contas habilitadas para o Data Lake Storage. O suporte ao recurso está sempre se expandindo, então lembre-se de examinar periodicamente este artigo para obter atualizações.

2. Examine o artigo Problemas conhecidos com Azure Data Lake Storage para ver se há alguma limitação ou diretriz especial para o recurso que você pretende usar.

3. Examine os artigos de recursos para obter diretrizes específicas para contas habilitadas para o Data Lake Storage.

Entender os termos usados na documentação

Conforme você passa pelos conteúdos, observará algumas pequenas diferenças na terminologia. Por exemplo, o conteúdo apresentado na documentação do Armazenamento de Blobs usa o termo blob em vez de arquivo. Tecnicamente, os arquivos ingeridos na sua conta de armazenamento se tornam blobs em sua conta. Portanto, o termo está correto. No entanto, o termo blob poderá causar confusão se você estiver habituado com o termo arquivo. Também se vê o termo contêiner usado para se referir a um sistema de arquivos. Considere esses termos como sinônimos.

Considere a versão premium

Se suas cargas de trabalho exigirem uma baixa latência consistente ou exigirem um alto número de IOPS (operações de saída de entrada por segundo), considere usar uma conta de armazenamento de blobs de blocos premium. Esse tipo de conta disponibiliza dados por meio de hardware de alto desempenho. Os dados são armazenados em SSDs (unidades de estado sólido) que são otimizadas para baixa latência. As SSDs fornecem maior taxa de transferência em comparação com os discos rígidos tradicionais. Os custos de armazenamento do desempenho premium são mais altos, mas os custos de transação são menores. Portanto, se suas cargas de trabalho executam um grande número de transações, uma conta de blob de blocos com desempenho premium pode ser econômica.

Se a sua conta de armazenamento for usada para análises, recomendamos fortemente que você use o Azure Data Lake Storage juntamente com uma conta de armazenamento de blobs de bloco premium. Essa combinação do uso de contas de armazenamento de blobs em blocos premium juntamente com uma conta com o Data Lake Storage habilitado é conhecida como a camada Premium do Azure Data Lake Storage.

Otimize para ingestão de dados

Ao ingerir dados de um sistema de origem, o hardware de origem, o hardware de rede de origem ou a conectividade de rede com sua conta de armazenamento podem criar gargalos.

Hardware de origem

Se você estiver usando máquinas locais ou VMs (máquinas virtuais) no Azure, selecione cuidadosamente o hardware apropriado. Para hardware de disco, considere usar SSD (unidades de estado sólido) e escolher hardware de disco que tenha eixos mais rápidos. Para o hardware de rede, use os controladores de interface de rede (NICs) mais rápidos possíveis. Em Azure, use Azure VMs D14, que têm o hardware de rede e disco apropriadamente poderosos.

Conectividade de rede com a conta de armazenamento

Às vezes, a conectividade de rede entre seus dados de origem e sua conta de armazenamento pode criar um gargalo. Quando os dados de origem estiverem no local, considere usar um link dedicado com Azure ExpressRoute. Quando os dados de origem estão no Azure, o desempenho é melhor se os dados estão na mesma região do Azure que a conta habilitada para Data Lake Storage.

Configurar ferramentas de ingestão de dados para paralelização máxima

Para obter o melhor desempenho, use toda a taxa de transferência disponível executando o máximo de leituras e gravações em paralelo possível.

A tabela a seguir resume as configurações essenciais de várias ferramentas comuns de ingestão.

Para obter uma lista mais abrangente de ferramentas de ingestão, consulte Selecionar ferramentas de migração.

Sua conta pode ser dimensionada para fornecer a taxa de transferência necessária para todos os cenários de análise. Por padrão, uma conta habilitada para Data Lake Storage fornece taxa de transferência suficiente em sua configuração padrão para atender às necessidades de uma ampla gama de casos de uso. Se você atingir o limite padrão, entre em contato com o Suporte do Azure para configurar sua conta para disponibilizar maior taxa de transferência.

Estruture conjuntos de dados

Considere planejar com antecedência a estrutura dos seus dados. O formato de arquivo, o tamanho do arquivo e a estrutura de diretórios podem impactar o desempenho e o custo.

Formatos de arquivo

Você pode ingerir dados em vários formatos. Os dados podem aparecer em formatos legíveis por humanos, como JSON, CSV ou XML, ou como formatos binários compactados, como .tar.gz. Os dados podem vir em vários tamanhos. Os dados podem ser compostos por arquivos grandes (de alguns terabytes), como dados de uma exportação de uma tabela de SQL de seus sistemas locais. Os dados também podem vir na forma de um grande número de arquivos minúsculos (alguns quilobytes), como dados de eventos em tempo real de uma solução de IoT (Internet das coisas). Você pode otimizar a eficiência e os custos escolhendo um formato de arquivo e um tamanho do arquivo apropriados.

O Hadoop dá suporte a um conjunto de formatos de arquivo que são otimizados para armazenar e processar dados estruturados. Alguns formatos comuns são Avro, Parquet e o formato ORC (formato colunar otimizado por linhas). Todos esses formatos são formatos de arquivo binário legíveis por computador. Eles são compactados para ajudar você a gerenciar o tamanho do arquivo. Eles têm um esquema inserido em cada arquivo, o que os torna autodescritivos. A diferença entre esses formatos é a forma como os dados são armazenados. O Avro armazena dados em um formato com base em linha e os formatos Parquet e ORC armazenam dados em um formato de coluna.

Use o formato de arquivo Avro quando os padrões de E/S forem mais pesados de gravação ou os padrões de consulta favorecerem a recuperação de várias linhas de registros em sua totalidade. Por exemplo, o formato Avro funciona bem com um barramento de mensagens como Event Hubs ou Kafka, que grava vários eventos ou mensagens em sucessão.

Use os formatos de arquivo Parquet e ORC quando os padrões de E/S forem mais voltados para leitura ou quando os padrões de consulta forem focados em um subconjunto de colunas dos registros. As transações de leitura podem ser otimizadas para recuperar colunas específicas em vez de ler o registro inteiro.

O Apache Parquet é um formato de arquivo de código aberto otimizado para pipelines analíticos com predominância de leitura. A estrutura de armazenamento em coluna do Parquet permite ignorar dados não relevantes. As consultas são muito mais eficientes porque podem limitar o escopo dos dados a serem enviados do armazenamento para o mecanismo de análise. Além disso, como os tipos de dados semelhantes (para uma coluna) são armazenados juntos, o Parquet dá suporte a esquemas eficientes de codificação e compactação de dados que podem reduzir os custos de armazenamento de dados. Serviços como Azure Synapse Analytics, Azure Databricks e Azure Data Factory têm funcionalidade nativa que aproveita os formatos de arquivo Parquet.

Tamanho do arquivo

Arquivos maiores resultam em um melhor desempenho e custos reduzidos.

Normalmente, mecanismos de análise, como o HDInsight, têm uma sobrecarga por arquivo que envolve tarefas como listagem, verificação de acesso e execução de várias operações de metadados. Se você armazenar seus dados como muitos arquivos pequenos, essa opção poderá afetar negativamente o desempenho. Em geral, se você organizar seus dados em arquivos de tamanho maior (256 MB a 100 GB), obterá um melhor desempenho. Alguns mecanismos e aplicativos podem ter problemas para processar com eficiência arquivos maiores que 100 GB.

O aumento do tamanho do arquivo também pode reduzir os custos de transação. As operações de leitura e gravação são cobradas em incrementos de 4 MB, portanto você é cobrado pela operação, independentemente de o arquivo conter 4 megabytes ou apenas alguns quilobytes. Para obter informações sobre preços, confira Preços do Azure Data Lake Storage.

Às vezes, os pipelines de dados têm controle limitado sobre os dados brutos, compostos por muitos arquivos pequenos. Em geral, seu sistema deve ter algum tipo de processo para agregar arquivos pequenos em arquivos maiores para uso por aplicativos downstream. Se você estiver processando dados em tempo real, poderá usar um mecanismo de streaming em tempo real (como Azure Stream Analytics ou Spark Streaming) junto com um agente de mensagens (como Hubs de Eventos ou Apache Kafka) para armazenar seus dados como arquivos maiores. À medida que você agrega arquivos pequenos em arquivos maiores, considere salvá-los em um formato otimizado para leitura, como Apache Parquet, para processamento downstream.

Estrutura do diretório

Cada carga de trabalho tem requisitos diferentes de como consome dados. No entanto, ao trabalhar com ioT (Internet das Coisas), cenários em lotes ou ao otimizar dados de série temporal, considere esses layouts comuns.

Estrutura de IoT

Em cargas de trabalho de IoT, você pode ingerir uma grande quantidade de dados que abrange vários produtos, dispositivos, organizações e clientes. Planeje previamente a estrutura de diretórios para garantir a organização, a segurança e o processamento eficiente dos dados pelos consumidores downstream. Um modelo geral a considerar pode ser o layout a seguir:

• {Region}/{SubjectMatter(s)}/{yyyyy}/{mm}/{dd}/{hh}/

Por exemplo, a telemetria de pouso de um motor de avião no Reino Unido pode ter a seguinte estrutura:

• UK/Planes/BA1293/Engine1/2017/08/11/12/

Neste exemplo, ao colocar a data no final da estrutura de diretórios, você pode usar ACLs para proteger regiões e assuntos com mais facilidade para usuários e grupos específicos. Se você colocar a estrutura de data no início, será muito mais difícil proteger essas regiões e assuntos. Por exemplo, se você quisesse fornecer acesso somente a dados do Reino Unido ou a determinados planos, precisaria aplicar uma permissão separada para vários diretórios em cada diretório de hora. Essa estrutura também aumentaria exponencialmente o número de diretórios com o passar do tempo.

Estrutura de trabalhos em lotes

Uma abordagem comumente usada no processamento em lotes é colocar dados em um diretório "in". Depois, quando os dados forem processados, coloque os novos dados em um diretório "out" para que os processos subsequentes os consumam. Essa estrutura de diretório é usada às vezes para trabalhos que requerem processamento em arquivos individuais e talvez não exigiam um processamento massivamente paralelo em conjuntos de dados grandes. Como a estrutura de IoT recomendada acima, uma boa estrutura de diretório tem os diretórios de nível pai para elementos como região e assuntos (por exemplo, organização, produto ou produtor). Considere a data e hora na estrutura para permitir uma melhor organização, pesquisas filtradas, segurança e automação no processamento. O nível de granularidade para a estrutura da data é determinado pelo intervalo, no qual os dados são carregados ou processados, como por hora, diariamente ou mesmo mensalmente.

Às vezes, o processamento de arquivos não tem êxito devido dados corrompidos ou formatos inesperados. Nesses casos, a estrutura de um diretório pode beneficiar-se de uma pasta /bad para mover os arquivos para uma inspeção adicional. O trabalho em lotes também pode manipular o relatório ou a notificação desses arquivos incorretos para intervenção manual. Considere a estrutura de modelo a seguir:

• {Region}/{SubjectMatter(s)}/In/{yyyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Out/{yyyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/

Por exemplo, uma empresa de marketing recebe extrações diárias de dados com atualizações de clientes de seus clientes na América do Norte. Isso pode se parecer com o seguinte trecho de código antes e depois de ser processado:

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

No caso comum de dados em lote sendo processados diretamente em bancos de dados como o Hive ou bancos de dados SQL tradicionais, não há necessidade de um diretório in ou out, porque a saída já é gravada em uma pasta separada para a tabela do Hive ou o banco de dados externo. Por exemplo, extratos diários dos clientes são enviados para seus respectivos diretórios. Em seguida, um serviço como Azure Data Factory, Apache Oozie ou Apache Airflow dispara um trabalho diário do Hive ou spark para processar e gravar os dados em uma tabela do Hive.

Estrutura de dados de série temporal

Para cargas de trabalho do Hive, a eliminação de partições de dados de séries temporais pode permitir que algumas consultas leiam apenas um subconjunto dos dados, o que melhora o desempenho.

Esses pipelines que ingerem dados de séries temporais geralmente armazenam seus arquivos em arquivos e pastas com uma nomenclatura estruturada. Veja abaixo um exemplo comum de dados estruturados por data:

/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv

Observe que as informações de data e hora são exibidas tanto como pastas quanto no nome de arquivo.

Para data e hora, o padrão a seguir é comum

/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

Novamente, a escolha que você fizer com a pasta e organização do arquivo deverá otimizar para os maiores tamanhos de arquivo e um número razoável de arquivos em cada pasta.

Configurar a segurança

Comece revisando as recomendações no artigo recomendações de segurança para o Armazenamento de Blobs. Você encontra diretrizes de prática recomendada sobre como proteger seus dados contra exclusão acidental ou mal-intencionada, proteger dados por trás de um firewall e usar Microsoft Entra ID como base do gerenciamento de identidades.

Em seguida, examine o artigo modelo de controle de acesso no Azure Data Lake Storage para obter diretrizes específicas para contas habilitadas para o Data Lake Storage. Este artigo ajuda você a entender como usar as funções do Azure RBAC (controle de acesso baseado em função) do Azure junto com ACLs (listas de controle de acesso) para impor permissões de segurança em diretórios e arquivos em seu sistema de arquivos hierárquico.

Ingerir, processar e analisar

Você pode ingerir dados em uma conta habilitada Data Lake Storage de várias fontes diferentes e de várias maneiras diferentes.

Por exemplo, você pode ingerir grandes conjuntos de dados de clusters HDInsight e Hadoop ou conjuntos menores de dados ad hoc para criação de aplicativos de protótipo. Você pode ingerir dados transmitidos que várias fontes geram, como aplicativos, dispositivos e sensores. Para esse tipo de dado, use ferramentas para capturar e processar os dados evento por evento em tempo real e, em seguida, gravar os eventos em lotes na sua conta. Você também pode ingerir logs do servidor Web que contêm informações como o histórico de solicitações de página. Para dados de log, considere escrever scripts ou aplicativos personalizados para carregá-los para que você tenha a flexibilidade de incluir o componente de carregamento de dados como parte do seu aplicativo de Big Data maior.

Depois que os dados estiverem disponíveis em sua conta, você poderá executar análise desses dados, criar visualizações e até mesmo baixar dados para seu computador local ou para outros repositórios, como um banco de dados SQL do Azure ou uma instância do SQL Server.

A tabela a seguir recomenda ferramentas que você pode usar para analisar, ingerir, visualizar e baixar dados. Use os links nesta tabela para encontrar diretrizes sobre como configurar e usar cada ferramenta.

Monitorar a telemetria

Monitorar o uso e o desempenho do serviço é uma parte importante da operacionalização do serviço. Exemplos de telemetria incluem operações frequentes, operações com alta latência ou operações que causam limitação imposta pelo serviço.

Você pode acessar toda a telemetria da sua conta de armazenamento por meio de logs Armazenamento do Azure no Azure Monitor. Esse recurso integra sua conta de armazenamento ao Log Analytics e aos Hubs de Eventos, além de permitir que você arquive logs em outra conta de armazenamento. Para ver a lista completa de métricas e logs de recursos e seu esquema associado, consulte Armazenamento do Azure referência de dados de monitoramento.

O local em que você opta por armazenar seus logs depende de como você planeja acessá-los. Por exemplo, se você quiser acessar seus logs quase em tempo real e conseguir correlacionar eventos em logs com outras métricas de Azure Monitor, armazene seus logs em um workspace Log Analytics. Em seguida, consulte seus logs usando KQL e redija consultas para enumerar a tabela StorageBlobLogs no seu espaço de trabalho.

Se você quiser armazenar seus logs para consulta quase em tempo real e retenção de longo prazo, defina suas configurações de diagnóstico para enviar logs para um workspace Log Analytics e uma conta de armazenamento.

Se você quiser acessar seus logs por meio de outro mecanismo de consulta, como o Splunk, defina as configurações de diagnóstico para enviar logs para um hub de eventos e ingerir logs do hub de eventos para o destino escolhido.

Você pode habilitar Armazenamento do Azure logs em Azure Monitor por meio do portal Azure, do PowerShell, do CLI do Azure e dos modelos de Azure Resource Manager. Para implantações em escala, use Azure Policy com suporte total para tarefas de correção. Para obter mais informações, confira ciphertxt/AzureStoragePolicy.

Confira também

• Estratégia executiva para unificar seus dados
• Modelo de controle de acesso no Azure Data Lake Storage
• O guia do mochileiro do Data Lake
• Visão geral do Azure Data Lake Storage