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.
Para sugestões gerais sobre a estruturação de um lago de dados, consulte estes artigos:
- Visão geral do Azure Data Lake Armazenamento para o cenário de gerenciamento de dados e análise
- Provisionar três contas do Azure Data Lake Storage para cada zona de destino de dados
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 de conta, como configurar a segurança de rede, projetar para alta disponibilidade e recuperação de desastre, consulte o conteúdo da 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.
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.
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.
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 usará 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. Você também verá o termo contêiner usado para se referir a um sistema de arquivos. Considere esses termos como sinônimos.
Considere premium
Se suas cargas de trabalho exigirem uma baixa latência consistente e/ou exigirem um alto número de IOP (operações de saída de entrada por segundo), considere usar uma conta de armazenamento de blob 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 executarem um grande número de transações, uma conta de blob de bloco de desempenho premium pode ser econômica.
Se sua conta de armazenamento for usada para análise, é altamente recomendável usar o Azure Data Lake Storage juntamente com uma conta de armazenamento de blob de blocos Premium. Essa combinação de usar contas de armazenamento de blob de blocos premium juntamente com uma conta do Data Lake Storage habilitada é conhecida como a camada premium para o Azure Data Lake Armazenamento.
Otimizar 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 a sua conta de armazenamento pode provocar um gargalo.
Hardware de origem
Quer você esteja usando computadores locais ou VMs (máquinas virtuais) no Azure, escolha cuidadosamente o hardware apropriado. Para hardware de disco, considere o uso de um SSD (Unidades de Estado Sólido) e escolha o hardware de disco que tenha eixos mais rápidos. Para hardware de rede, use o NIC (Controlador de Interface de Rede) mais rápido possível. No Azure, recomendamos VMs Azure D14, que têm o hardware de rede e de disco avançado ideal.
Conectividade de rede com a conta de armazenamento
Algumas vezes, a conectividade de rede entre os dados de origem e a conta de armazenamento pode apresentar um gargalo. Quando os dados de origem são locais, considere o uso de uma conexão dedicada com o 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 alcançar 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.
| Ferramenta | Configurações |
|---|---|
| DistCp | -m (mapper) |
| Azure Data Factory | parallelCopies |
| Sqoop | fs.azure.block.size, -m (mapper) |
Observação
O desempenho geral de suas operações de ingestão depende de outros fatores específicos da ferramenta que você está usando para ingerir dados. Para obter as melhores diretrizes atualizadas, confira a documentação de cada ferramenta que você pretende usar.
A sua conta pode ser dimensionada para fornecer a taxa de transferência necessária para qualquer cenário 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. Caso você use o limite padrão, pode entrar em contato com o Suporte do Azure para configurar a conta para fornecer mais taxa de transferência.
Conjuntos de dados de estrutura
Considere planejar previamente a estrutura de 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
Dados podem ser ingeridos em vários formatos. Os dados podem ser exibidos em formatos legíveis, como JSON, CSV ou XML, ou em formatos binários compactados, como .tar.gz. Os dados também podem ser fornecidos 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 o Avro, o Parquet e o ORC (colunar de linha otimizado). 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.
Considere usar o formato de arquivo Avro nos casos em que os padrões de E/S realizam gravação de modo mais intenso ou em que os padrões de consulta favorecem a recuperação de várias linhas inteiras de registros. Por exemplo, o formato Avro funciona bem com um barramento de mensagem, como o Hubs de Eventos ou Kafka, que grava vários eventos/mensagens sucessivamente.
Considere os formatos de arquivo Parquet e ORC quando os padrões de E/S realizam leitura de modo mais intenso ou quando os padrões de consulta se concentram em um subconjunto de colunas nos 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 de análise intensa 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 aproveitam 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 os dados como vários arquivos pequenos, isso 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 quatro megabytes para que você seja cobrado pela operação, independentemente de o arquivo conter quatro 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, que têm muitos arquivos pequenos. Em geral, recomendamos que seu sistema tenha algum tipo de processo para agregar arquivos pequenos em arquivos maiores para uso por aplicativos downstream. Se você está processando dados em tempo real, pode usar um mecanismo de transmissão em tempo real (como o Azure Stream Analytics ou o Spark Streaming) junto com um agente de mensagens (como o Hubs de Eventos ou o 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
Toda carga de trabalho tem requisitos diferentes sobre como os dados são consumidos, mas, a seguir, estão alguns layouts comuns a serem considerados ao trabalhar com cenários de lote, Internet das Coisas (IoT) ou ao otimizar dados de série temporal.
Estrutura de IoT
Nas cargas de trabalho de IoT, pode haver uma grande quantidade de dados sendo ingeridos que abrange diversos produtos, dispositivos, organizações e clientes. É importante planejar previamente o layout do diretório para organização, segurança e processamento eficiente dos dados para consumidores de downstream. Um modelo geral a considerar pode ser o layout a seguir:
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
Por exemplo, a telemetria de descarregamento para um motor de avião no Reino Unido pode parecer com 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 de "out" para processos downstream consumir. 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/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/
Por exemplo, uma empresa de marketing que recebe extratos de dados diários de atualizações de cliente dos seus clientes na América do Norte. Ele pode parecer com o seguinte snippet 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 lotes que estão sendo processados diretamente em bancos de dados, como Hive ou Bancos de Dados SQL tradicionais, não há necessidade de um diretório /in ou /out, uma vez que a saída já entra em uma pasta separada para a tabela de Hive ou banco de dados externo. Por exemplo, as extrações diárias dos clientes seriam atribuídas a seus respectivos diretórios. Em seguida, um serviço como Azure Data Factory,Apache Oozie ou Apache Airflow dispararia um trabalho diário do Hive ou do 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 remoção de partições de dados de série temporal pode ajudar algumas consultas a ler apenas um subconjunto dos dados, o que melhora o desempenho.
Esses pipelines que ingerem dados de série temporal muitas vezes colocam seus arquivos com uma nomenclatura muito estruturada para arquivos e pastas. Abaixo está um exemplo comum para 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ê encontrará diretrizes de melhores práticas sobre como proteger seus dados contra exclusão acidental ou mal-intencionada, proteger os dados por trás de um firewall e usar o Microsoft Entra ID como a base do gerenciamento de identidade.
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
Há muitas fontes de dados diferentes e maneiras diferentes em que os dados podem ser ingeridos em uma conta habilitada para o Data Lake Storage.
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 incluir dados transmitidos que são gerados por várias fontes, como aplicativos, dispositivos e sensores. Para esse tipo de dado, você pode usar ferramentas para capturar e processar os dados evento por evento em tempo real, depois gravar os eventos em lotes em 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 carregar esses dados, de modo que você tenha a flexibilidade de incluir o componente de upload 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.
| Finalidade | Ferramentas e diretrizes de ferramenta |
|---|---|
| Ingerir dados ad hoc | Azure portal, Azure PowerShell, CLI do Azure, REST, Gerenciador de Armazenamento do Azure, Apache DistCp, AzCopy |
| Ingerir dados relacionais | Azure Data Factory |
| Ingerir logs de servidor Web | Azure PowerShell, CLI do Azure, REST, SDKs do Azure (.NET, Java, Python e Node.js), Azure Data Factory |
| Ingestão por meio de clusters HDInsight | Azure Data Factory, Apache DistCp, AzCopy |
| Ingestão por meio de clusters Hadoop | Azure Data Factory, Apache DistCp, WANdisco LiveData Migrator para Azure, Azure Data Box |
| Ingerir grandes conjuntos de dados (vários terabytes) | Azure ExpressRoute |
| Processar e analisar dados | Azure Synapse Analytics, Azure HDInsight, Databricks |
| Visualizar dados | Power BI, aceleração de consulta do Azure Data Lake Storage |
| Baixar dados | portal do Azure, PowerShell, CLI do Azure, REST, SDKs do Azure (.NET, Java, Python e Node.js), Gerenciador de Armazenamento do Azure, AzCopy, Azure Data Factory, Apache DistCp |
Observação
Esta tabela não reflete a lista completa de serviços do Azure que dão suporte ao Data Lake Storage. Para ver uma lista dos serviços do Azure com suporte, o seu nível de suporte, confira Serviços do Azure que dão suporte ao Azure Data Lake Storage.
Monitorar a telemetria
Monitorar o uso e o desempenho é uma parte importante da operacionalização do serviço. Exemplos incluem operações frequentes, operações com alta latência ou operações que causam a limitação do lado do serviço.
Toda a telemetria para sua conta de armazenamento está disponível por meio de logs Armazenamento 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 logs de métricas e recursos e o esquema associado a eles, confira Referência de dados de monitoramento do Armazenamento do Azure.
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 ser capaz de correlacionar eventos em logs com outras métricas do Azure Monitor, poderá armazenar seus logs em um workspace do Log Analytics. Em seguida, consulte seus logs usando a KQL e crie consultas, que enumeram a tabela StorageBlobLogs em seu workspace.
Se você quiser armazenar seus logs para consulta quase em tempo real e retenção de longo prazo, poderá definir as configurações de diagnóstico para enviar logs para um workspace do Log Analytics e uma conta de armazenamento.
Se você quiser acessar seus logs por meio de outro mecanismo de consulta, como o Splunk, poderá definir 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.
Os logs do Armazenamento Azure no Azure Monitor podem ser habilitados por meio do portal do Azure, do PowerShell, da CLI do Azure e dos modelos do Azure Resource Manager. Para implantações em escala, o Azure Policy pode ser usado com suporte completo para tarefas de correção. Para obter mais informações, confira ciphertxt/AzureStoragePolicy.