Escolher um armazenamento de dados analíticos no Azure

Em uma arquitetura de Big Data , geralmente há a necessidade de um armazenamento de dados analíticos que atenda dados processados em um formato estruturado que possa ser consultado usando ferramentas analíticas. Os armazenamentos de dados analíticos que dão suporte à consulta de dados de caminho quente e de caminho frio são coletivamente conhecidos como a camada de serviço ou o armazenamento de serviço de dados.

A camada de serviço manipula dados processados do caminho quente e do caminho frio. Na arquitetura Lambda, a camada de serviço é subdividida em duas camadas. A camada de fornecimento rápido contém os dados processados incrementalmente. A camada de serviço em lote contém a saída processada em lote. A camada de serviço requer suporte forte para leituras aleatórias que têm baixa latência. O armazenamento de dados para a camada de velocidade também deve dar suporte a gravações aleatórias porque o carregamento em lote de dados nesse repositório apresenta atrasos indesejados. Como alternativa, o armazenamento de dados para a camada de lote precisa dar suporte a gravações em lote, não gravações aleatórias.

Não há nenhuma opção de gerenciamento de dados recomendada para todas as tarefas de armazenamento de dados. Soluções de gerenciamento de dados diferentes são otimizadas para tarefas diferentes. A maioria dos aplicativos de nuvem do mundo real e os processos de Big Data têm vários requisitos de armazenamento de dados e geralmente usam uma combinação de soluções de armazenamento de dados.

Soluções analíticas modernas, como Microsoft Fabric, fornecem uma plataforma abrangente que integra vários serviços de dados e ferramentas para atender às diversas necessidades analíticas. O Fabric inclui o OneLake, que é um data lake único, unificado e lógico para toda a sua organização. O OneLake foi projetado para armazenar, gerenciar e proteger todos os dados organizacionais em um único local. Essa flexibilidade permite que sua organização resolva uma ampla gama de requisitos de armazenamento e processamento de dados.

Escolha um armazenamento de dados analíticos

Há várias opções de armazenamento de serviço de dados no Azure, dependendo de suas necessidades:

• Tecido, especificamente:
  • Fabric Lakehouse
  • Fabric Warehouse
  • Fabric Eventhouse
  • Bancos de Dados SQL do Fabric
• Azure Databricks
• Banco de Dados SQL do Azure
• SQL Server em VM do Azure
• Azure Analysis Services
• Azure Cosmos DB

Os seguintes modelos de banco de dados são otimizados para diferentes tipos de tarefas:

• Os bancos de dados chave-valor armazenam um único objeto serializado para cada valor de chave. Eles são adequados para gerenciar grandes volumes de dados quando a recuperação é baseada em uma chave específica, sem a necessidade de consultar outras propriedades de item.

• Bancos de dados de documento são bancos de dados chave-valor nos quais os valores são documentos. Nesse contexto, um documento é uma coleção de campos e valores nomeados. O banco de dados normalmente armazena os dados em um formato como XML, YAML, JSON ou JSON binário, mas pode usar texto sem formatação. Os bancos de dados de documentos podem consultar campos não chave e definir índices secundários para melhorar a eficiência da consulta. Essa funcionalidade torna um banco de dados de documento mais adequado para aplicativos que precisam recuperar dados com base em critérios mais complexos do que o valor da chave do documento. Por exemplo, você pode consultar em campos como ID do produto (product ID), ID do cliente ou nome do cliente.

• Os bancos de dados de armazenamento em colunas são lojas de dados chave-valor que armazenam cada coluna separadamente no disco. Um banco de dados de armazenamento de colunas amplo é um tipo de banco de dados de armazenamento de colunas que guarda famílias de colunas, não apenas colunas únicas. Por exemplo, um banco de dados censitário pode ter uma família de colunas separada para cada um dos seguintes itens:

  • O nome, o meio e o sobrenome de uma pessoa

  • O endereço dessa pessoa

  • Informações de perfil dessa pessoa, como sua data de nascimento ou sexo

  O banco de dados pode armazenar as famílias de colunas em uma partição separada, mantendo todos os dados de uma pessoa relacionados à mesma chave. Um aplicativo pode ler uma única família de colunas sem verificar todos os dados de uma entidade.

• Os bancos de dados do Graph armazenam informações como uma coleção de objetos e relações. Um banco de dados de gráficos pode executar com eficiência consultas que atravessam a rede de objetos e as relações entre eles. Por exemplo, os objetos podem ser funcionários em um banco de dados de recursos humanos e talvez você deseje facilitar consultas como "encontrar todos os funcionários que trabalham direta ou indiretamente para Scott".

• Os bancos de dados de telemetria e séries temporais são uma coleção que permite somente acréscimos de objetos. Os bancos de dados de telemetria indexam dados com eficiência em vários repositórios de colunas e estruturas na memória. Essa funcionalidade os torna a opção ideal para armazenar e analisar grandes quantidades de dados de telemetria e série temporal.

O Fabric dá suporte a vários modelos de banco de dados, incluindo bancos de dados chave-valor, documento, repositório de colunas, grafo e telemetria. Essa flexibilidade garante a escalabilidade de uma ampla gama de tarefas analíticas. Para escolher o armazenamento de dados do Fabric correto para suas cargas de trabalho analíticas, consulte o guia de decisão do Fabric: escolha um armazenamento de dados.

Principais critérios de seleção

Para refinar o processo de seleção, considere os seguintes critérios:

• Você precisa de um armazenamento de serviço que pode atuar como um caminho quente para os dados? Em caso afirmativo, restrinja as opções àquelas que são otimizadas para uma camada de entrega rápida.

• Você precisa de suporte de processamento paralelo maciço, em que as consultas são distribuídas automaticamente em vários processos ou nós? Em caso afirmativo, selecione uma opção que dê suporte à expansão da consulta.

• Você prefere usar um armazenamento de dados relacionais? Se você fizer isso, restrinja suas opções àqueles que têm um modelo de banco de dados relacional. No entanto, alguns repositórios não relacionais dão suporte à sintaxe SQL para consulta e ferramentas como o Ponto de Extremidade do SQL podem ser usadas para consultar armazenamentos de dados não relacionais, como o OneLake.

• Você coleta dados de série temporal? Você usa dados somente de anexação? O Fabric OneLake dá suporte a vários mecanismos analíticos, incluindo Analysis Services, T-SQL e Apache Spark. O Fabric Eventhouse o torna adequado para várias necessidades de processamento e consulta de dados de série temporal.

Matriz de funcionalidades

As tabelas a seguir resumem as principais diferenças de recursos nesses serviços gerenciados.

Funcionalidades gerais

[1] T-SQL via Endpoint de Análise SQL.

[2] O KQL tem suporte parcial à linguagem T-SQL.

[3] Suporta ingestão em fila e ingestão de streaming.

[4] Dá suporte à precisão transacional com acesso de baixa latência e atualizações em tempo real.

[5] Usando tabelas com otimização de memória e índices hash ou não clusterizados.

Funcionalidades de escalabilidade

Os endpoints SQL são roteados por meio de gerenciadores de tráfego globais, mas os dados são sempre processados na região de capacidade atribuída do Fabric.

[2] O Lakehouse e o Warehouse armazenam dados no OneLake usando o formato Delta Parquet, que dá suporte à consulta e à replicação entre mecanismos.

[3] O Lakehouse dá suporte à expansão baseada em Spark para dados não estruturados e estruturados.

[4] O Warehouse usa T-SQL e dá suporte a transações de várias tabelas, gerenciamento de carga de trabalho autônoma e DQP (processamento de consulta distribuída). O DQP atua como um gerenciador de clusters, alocando dinamicamente recursos de computação com base na complexidade da consulta.

[5] O Eventhouse dá suporte à federação KQL e SQL, permitindo análise em tempo real em várias fontes, bem como aumentar os recursos de computação se o uso de cache frequente exceder cerca de 95%.

[6] Cache inteligente para tarefas do Spark, cache na memória, cache de conjunto de resultados para endpoints de análise SQL.

[7] Os dados acessados com frequência são armazenados em um cache quente que inclui armazenamento em memória e SSD.

Funcionalidades de segurança

[1] Requer que você use criptografia de dados transparente para criptografar e descriptografar seus dados em repouso.

[2] Links Privados e Acesso Condicional do Entra podem ser usados para restringir o acesso aos recursos do Fabric.

[3] As cargas de trabalho do Fabric Eventhouse e do Real-Time Intelligence podem ingerir dados de fontes seguras, como Kafka, Hubs de Eventos do Azure e AMQP, com roteamento por meio de pontos de extremidade seguros.

[4] Ele pode ser aplicado no nível do endpoint SQL do Fabric

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

• Mohit Agarwal | Arquiteto principal de soluções de nuvem

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas

• Traga seus dados para o OneLake com o Lakehouse
• Criar um Armazém de Tecido
• Criar um Eventhouse
• Analisar os dados em um data warehouse relacional
• Criar um banco de dados individual no Banco de Dados SQL
• Crie um espaço de trabalho do Azure Databricks
• Explorar os serviços de banco de dados e análise do Azure
• Consultar o Azure Cosmos DB usando a API para NoSQL

Recursos relacionados

• Guia de decisão do fabric: escolha um armazenamento de dados
• Consultar o ponto de extremidade de análise do SQL ou Warehouse no Microsoft Fabric
• Opções de tecnologia para soluções do Azure
• Dados não relacionais e NoSQL