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 fornece diretrizes de práticas recomendadas que ajudam a otimizar o desempenho, reduzir custos e proteger sua conta de Armazenamento do Azure habilitada para Armazenamento Data Lake.
Localizar documentação
O Armazenamento Azure Data Lake não é um serviço dedicado ou um tipo de conta. É um conjunto de recursos que suportam cargas de trabalho analíticas de alto rendimento. A documentação do Armazenamento Data Lake fornece práticas recomendadas e orientações para o uso desses recursos. Para todos os outros aspetos do gerenciamento de contas, como configuração de segurança de rede, design para alta disponibilidade e recuperação de desastres, consulte o conteúdo da documentação de armazenamento de Blob.
Avalie o suporte a recursos e problemas conhecidos
Use o padrão a seguir ao configurar sua conta para usar os recursos de armazenamento de Blob.
Analise o artigo Suporte ao recurso de Armazenamento de Blob nas contas de Armazenamento do Azure para determinar se um recurso é totalmente suportado na sua conta. Alguns recursos ainda não são suportados ou têm suporte parcial em contas habilitadas para Armazenamento Data Lake. O suporte a recursos está sempre em expansão, portanto, certifique-se de revisar periodicamente este artigo para atualizações.
Analise o artigo Problemas conhecidos com o Armazenamento do Azure Data Lake para ver se há limitações ou orientações especiais sobre o recurso que você pretende usar.
Analise os artigos de destaque para obter qualquer orientação específica para contas habilitadas para o Armazenamento de Data Lake.
Compreender os termos utilizados na documentação
À medida que você se move entre conjuntos de conteúdo, você percebe algumas pequenas diferenças terminológicas. Por exemplo, o conteúdo apresentado na documentação de armazenamento Blob utiliza o termo blob em vez de ficheiro. Tecnicamente, os ficheiros que carrega para a sua conta de armazenamento tornam-se blobs na sua conta. Portanto, o termo está correto. No entanto, o termo blob pode causar confusão se estiveres habituado ao termo ficheiro. Também pode ver o termo contentor utilizado para se referir a sistema de ficheiros. Considere estes termos como sinónimos.
Considere a opção premium
Se as suas cargas de trabalho requerem uma latência baixa e consistente ou um elevado número de operações de entrada e saída por segundo (IOPS), considere usar uma conta premium de armazenamento blob em blocos. Este tipo de conta disponibiliza dados através de hardware de alto desempenho. Os dados são armazenados em unidades de estado sólido (SSDs) que são otimizadas para baixa latência. Os SSDs proporcionam um débito mais elevado em comparação com os discos rígidos tradicionais. Os custos de armazenamento de desempenho premium são mais altos, mas os custos de transação são menores. Portanto, se as suas cargas de trabalho executarem um grande número de transações, uma conta de desempenho premium de bloco de blobs pode ser económica.
Caso a sua conta de armazenamento vá ser utilizada para análises, é altamente recomendável que utilize o Azure Data Lake Storage juntamente com uma conta de armazenamento premium para blobs de bloco. Essa combinação de usar contas de armazenamento premium de blobs de bloco junto com uma conta com Armazenamento Data Lake ativado é conhecida como a camada premium do Armazenamento Azure Data Lake.
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 à sua conta de armazenamento podem criar gargalos.
Hardware de origem
Quer esteja a usar máquinas on-premises ou máquinas virtuais (VMs) no Azure, selecione cuidadosamente o hardware apropriado. Para hardware de disco, considere usar unidades de estado sólido (SSD) e escolha hardware de disco que tenha spindles mais rápidos. Para hardware de rede, utilize os controladores de interface de rede (NIC) mais rápidos possíveis. No Azure, utilize VMs Azure D14, que têm o hardware de disco e rede suficientemente potentes.
Conectividade de rede com a conta de armazenamento
A conectividade de rede entre os seus dados de origem e a sua conta de armazenamento pode, por vezes, criar um gargalo. Quando os seus dados de origem estiverem on-premises, considere usar um link dedicado com o Azure ExpressRoute. Se os dados de origem estiverem no Azure, o desempenho será melhor quando os dados estiverem na mesma região do Azure que sua conta habilitada para Armazenamento Data Lake.
Configurar ferramentas de ingestão de dados para paralelização máxima
Para obter o melhor desempenho, use todo o throughput disponível realizando o maior número possível de leituras e escritas em paralelo.
A tabela a seguir resume as principais configurações de várias ferramentas populares de ingestão.
| Ferramenta | Definições |
|---|---|
| DistCp | -m (mapeador) |
| Fábrica de Dados do Azure | cópias paralelas |
| Sqoop | fs.azure.block.size, -m (mapeador) |
| AzCopy | AZCOPY_CONCURRENCY_VALUE |
Para uma lista mais abrangente de ferramentas de ingestão, consulte Selecionar ferramentas de migração.
Nota
O desempenho global das suas operações de ingestão depende de outros fatores específicos da ferramenta que está a usar para ingerir dados. Para obter as melhores orientações atualizadas, consulte a documentação de cada ferramenta que você pretende usar.
A sua conta pode ser dimensionada para fornecer a capacidade necessária para todos os cenários analíticos. Por padrão, uma conta habilitada para Armazenamento Data Lake fornece taxa de transferência suficiente em sua configuração padrão para atender às necessidades de uma ampla categoria de casos de uso. Se atingir o limite predefinido, contacte o Suporte do Azure para configurar a sua conta e fornecer maior rendimento.
Estruturar conjuntos de dados
Considere planear previamente a estrutura dos seus dados. O formato de arquivo, o tamanho do arquivo e a estrutura de diretórios podem afetar o desempenho e o custo.
Formatos de ficheiro
Pode ingerir dados em vários formatos. Os dados podem aparecer em formatos legíveis por humanos como JSON, CSV ou XML, ou em formatos binários comprimidos como .tar.gz. Os dados podem existir em vários tamanhos. Os dados podem ser compostos por arquivos grandes (alguns terabytes), como dados de uma exportação de uma tabela SQL de seus sistemas locais. Os dados também podem vir na forma de um grande número de arquivos minúsculos (alguns kilobytes), como dados de eventos em tempo real de uma solução de Internet das Coisas (IoT). Você pode otimizar a eficiência e os custos escolhendo um formato de arquivo e tamanho de arquivo apropriados.
O Hadoop suporta um conjunto de formatos de arquivo otimizados para armazenar e processar dados estruturados. Alguns formatos comuns são Avro, Parquet e Optimized Row Columnar (ORC). Todos estes formatos são formatos de ficheiro binário legíveis por máquina. Eles são compactados para ajudá-lo a gerenciar o tamanho do arquivo. Eles têm um esquema incorporado em cada arquivo, o que os torna autodescritos. A diferença entre esses formatos está em como os dados são armazenados. O Avro armazena dados em um formato baseado em linha e os formatos Parquet e ORC armazenam dados em um formato colunar.
Utilize o formato de ficheiro Avro quando os seus padrões de E/S privilegiarem mais a escrita ou quando os padrões de consulta favorecerem a recuperação de várias linhas de registos completas. Por exemplo, o formato Avro funciona bem com um barramento de mensagens, como o Event Hubs ou o Kafka, utilizado para escrever vários eventos ou mensagens em sequência.
Utilize os formatos de ficheiro Parquet e ORC quando os padrões de I/O forem predominantemente de leitura ou quando os padrões de consulta se centrarem num subconjunto de colunas dos registos. As transações de leitura podem ser otimizadas para recuperar colunas específicas em vez de ler o registro inteiro.
Apache Parquet é um formato de ficheiro de código aberto que está otimizado para pipelines de análise intensivas em leitura. A estrutura de armazenamento colunar do Parquet permite ignorar dados não relevantes. Suas consultas são muito mais eficientes porque podem restringir o escopo de quais dados enviar do armazenamento para o mecanismo de análise. Além disso, como tipos de dados semelhantes (para uma coluna) são armazenados juntos, o Parquet suporta esquemas eficientes de compactação e codificaçã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 funcionalidades nativas que aproveitam os formatos de ficheiro Parquet.
Tamanho do ficheiro
Arquivos maiores levam a um melhor desempenho e custos reduzidos.
Normalmente, os 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 armazenar os seus dados como muitos ficheiros pequenos, esta escolha pode afetar negativamente o desempenho. Em geral, organize seus dados em arquivos de tamanho maior para um melhor desempenho (256 MB a 100 GB de tamanho). Alguns mecanismos e aplicativos podem ter problemas para processar com eficiência arquivos com mais de 100 GB de tamanho.
Aumentar o tamanho do arquivo também pode reduzir os custos de transação. As operações de leitura e escrita são faturadas em incrementos de 4 megabytes, pelo que lhe é cobrado o valor da operação, independentemente de o ficheiro conter 4 megabytes ou apenas alguns quilobytes. Para obter informações sobre preços, consulte Preços do Armazenamento do Azure Data Lake.
Às vezes, os pipelines de dados têm controle limitado sobre os dados brutos, que têm muitos arquivos pequenos. Em geral, o seu sistema deve ter algum tipo de processo para agregar ficheiros pequenos em ficheiros maiores para uso por aplicações a jusante. Se estiver a processar dados em tempo real, pode usar um motor de streaming em tempo real (como Azure Stream Analytics ou Spark Streaming) juntamente com um broker de mensagens (como Event Hubs ou Apache Kafka) para armazenar os seus dados como ficheiros maiores. Ao agregar arquivos pequenos em arquivos maiores, considere salvá-los em um formato otimizado para leitura, como o Apache Parquet , para processamento downstream.
Estrutura do diretório
Cada carga de trabalho tem requisitos diferentes quanto à forma como consome dados. No entanto, ao trabalhar com Internet das Coisas (IoT), cenários em lote ou ao otimizar para dados de séries temporais, considere estes layouts comuns.
Estrutura da IoT
Em cargas de trabalho IoT, pode ingerir uma grande quantidade de dados que abrange inúmeros produtos, dispositivos, organizações e clientes. Planeia previamente o layout dos diretórios para organização, segurança e processamento eficiente dos dados para os consumidores a jusante. Um modelo geral a considerar pode ser o seguinte layout:
- {Região}/{Assunto(s)}/{aaaa}/{mm}/{dd}/{hh}/
Por exemplo, a telemetria de aterragem para um motor de avião no Reino Unido pode ter a seguinte estrutura:
- Reino Unido/Aviões/BA1293/Motor1/2017/08/11/12/
Neste exemplo, colocando a data no final da estrutura de diretórios, você pode usar ACLs para proteger mais facilmente regiões e assuntos para usuários e grupos específicos. Se você colocar a estrutura de data no início, seria muito mais difícil proteger essas regiões e assuntos. Por exemplo, se você quisesse fornecer acesso apenas a dados do Reino Unido ou certos aviões, precisaria aplicar uma permissão separada para vários diretórios em cada diretório de horas. Esta estrutura também aumentaria exponencialmente o número de diretórios com o passar do tempo.
Estrutura de trabalhos em lote
Uma abordagem comumente usada no processamento em lote é colocar os dados em um diretório "in". Em seguida, uma vez que os dados sejam processados, coloque os novos dados num diretório "out" para serem utilizados pelos processos subsequentes. Essa estrutura de diretórios às vezes é usada para trabalhos que exigem processamento em arquivos individuais e podem não exigir processamento paralelo maciço em grandes conjuntos de dados. Como a estrutura de IoT recomendada acima, uma boa estrutura de diretórios tem os diretórios de nível pai para coisas como região e assunto (por exemplo, organização, produto ou produtor). Considere data e hora na estrutura para permitir melhor organização, pesquisas filtradas, segurança e automação no processamento. O nível de granularidade para a estrutura de data é determinado pelo intervalo no qual os dados são carregados ou processados, como horário, diário ou até mensal.
Às vezes, o processamento de arquivos não é bem-sucedido devido à corrupção de dados ou formatos inesperados. Nesses casos, uma estrutura de diretórios pode se beneficiar de uma pasta /bad para mover os arquivos para inspeção adicional. O trabalho em lote também pode tratar do relatório ou notificação desses arquivos problemáticos para intervenção manual. Considere a seguinte estrutura de modelo:
- {Região}/{Assunto(s)}/In/{aaaa}/{mm}/{dd}/{hh}/
- {Região}/{Assunto(s)}/out/{aaaa}/{mm}/{dd}/{hh}/
- {Região}/{Assunto(s)}/Mau/{aaaa}/{mm}/{dd}/{hh}/
Por exemplo, uma empresa de marketing recebe extrações diárias de dados de atualizações de clientes de seus clientes na América do Norte. Pode se parecer com o seguinte trecho antes e depois de ser processado:
- NA/Extratos/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
- NA/Extratos/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv
No caso comum de dados em lote serem processados diretamente em bases de dados como Hive ou bases de dados SQL tradicionais, não há necessidade de um diretório in ou out porque a saída já vai para uma pasta separada para a tabela Hive ou base de dados externa. Por exemplo, extratos diários dos clientes aparecem nos respetivos diretórios. Depois, um serviço como Azure Data Factory, Apache Oozie ou Apache Airflow desencadeia um trabalho diário do Hive ou Spark para processar e escrever os dados numa tabela Hive.
Estrutura de dados de séries cronológicas
Para cargas de trabalho do Hive, a poda de partições de dados cronológicos pode ajudar algumas consultas a ler apenas um subconjunto dos dados, o que melhora o desempenho.
Os pipelines que ingerem dados de séries temporais organizam frequentemente os seus ficheiros segundo uma nomenclatura estruturada para ficheiros e pastas. Segue-se um exemplo comum para dados estruturados por data:
/DataSet/AAAA/MM/DD/datafile_YYYY_MM_DD.tsv
Observe que as informações de data/hora aparecem como pastas e no nome do arquivo.
Para data e hora, o seguinte é um padrão comum
/DataSet/AAAA/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv
Novamente, a escolha que você faz com a pasta e organização de arquivos deve otimizar para os tamanhos de arquivo maiores e um número razoável de arquivos em cada pasta.
Configurar a segurança
Comece por rever as recomendações no artigo Recomendações de segurança para armazenamento Blob. Encontra orientações de boas práticas sobre como proteger os seus dados contra eliminações acidentais ou maliciosas, proteger os dados atrás de um firewall e usar o Microsoft Entra ID como base para a gestão de identidades.
Em seguida, revise o artigo Modelo de controle de acesso no Armazenamento do Azure Data Lake para obter orientações específicas para contas habilitadas para o Armazenamento Data Lake. Este artigo ajuda você a entender como usar funções de controle de acesso baseado em função do Azure (Azure RBAC) junto com listas de controle de acesso (ACLs) para impor permissões de segurança em diretórios e arquivos em seu sistema de arquivos hierárquico.
Ingerir, processar e analisar
Pode ingerir dados numa conta com Data Lake Storage habilitada a partir de várias fontes e de várias formas.
Por exemplo, pode-se ingerir grandes conjuntos de dados de clusters HDInsight e Hadoop ou conjuntos menores de dados ad hoc para prototipagem de aplicativos. Pode ingerir dados transmitidos que várias fontes geram, como aplicações, dispositivos e sensores. Para este tipo de dados, utilize ferramentas para capturar e processar os dados evento a evento em tempo real, e depois escreva 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 os dados de registo, considere escrever scripts ou aplicações personalizados para os carregar, de modo a ter a flexibilidade de incluir o seu componente de carregamento de dados como parte da sua aplicação maior de big data.
Depois que os dados estiverem disponíveis em sua conta, você poderá executar análises nesses dados, criar visualizações e até mesmo baixar dados para sua máquina 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 ingerir, analisar, visualizar e baixar dados. Use os links nesta tabela para encontrar orientações sobre como configurar e usar cada ferramenta.
Nota
Esta tabela não reflete a lista completa de serviços do Azure que dão suporte ao Armazenamento Data Lake. Para ver uma lista dos serviços Azure suportados e o seu nível de suporte, consulte os serviços Azure que suportam o Azure Data Lake Storage.
Monitorar telemetria
Monitorizar a utilização e o desempenho do seu serviço é uma parte importante da operacionalização do seu serviço. Exemplos de telemetria incluem operações frequentes, operações com latência elevada ou operações que causam limitação imposta pelo serviço.
Pode aceder a toda a telemetria da sua conta de armazenamento através dos registos do Armazenamento do Azure no Azure Monitor. Esse recurso integra sua conta de armazenamento com o Log Analytics e 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 registos de recursos e os seus esquemas associados, consulte a referência de dados de monitorização do Armazenamento do Azure.
O local onde você escolhe armazenar seus logs depende de como você planeja acessá-los. Por exemplo, se quiser aceder aos seus logs quase em tempo real e conseguir correlacionar eventos nos logs com outras métricas do Azure Monitor, armazene os seus logs num espaço de trabalho Log Analytics. Em seguida, consulte seus logs usando KQL e consultas de autor, que enumeram a StorageBlobLogs tabela em seu espaço de trabalho.
Se quiser armazenar os seus registos tanto para consultas quase em tempo real como para retenção a longo prazo, configure as suas definições de diagnóstico para enviar registos tanto para um espaço de trabalho do Log Analytics como para uma conta de armazenamento.
Se quiser aceder aos seus registos através de outro motor de consultas como o Splunk, configure as suas definições de diagnóstico para enviar registos para um hub de eventos e ingerir os registos desse hub para o destino escolhido.
Pode ativar os logs do Armazenamento do Azure no Azure Monitor através do portal Azure, PowerShell, CLI do Azure e templates do Azure Resource Manager. Para implementações em escala, utilize o Azure Policy com suporte total para tarefas de remediação. Para obter mais informações, consulte ciphertxt/AzureStoragePolicy.