Escolher um armazenamento de dados analíticos no Azure

A arquitetura de big data frequentemente necessita de um armazenamento analítico de dados que sirva dados processados num formato estruturado. Pode consultar esses dados usando ferramentas analíticas. Os armazenamentos de dados analíticos que suportam a consulta de dados de caminho quente e de caminho frio são coletivamente chamados de camada de serviço ou armazenamento de serviço de dados.

A camada de distribuição lida com dados processados tanto do caminho quente quanto do caminho frio. Na arquitetura Lambda, a camada de serviço é subdividida em duas camadas. A camada de serviço de velocidade contém os dados processados incrementalmente. A camada de serviço em lote contém a saída processada em lote.

Embora a camada global de serviço exija forte suporte para leituras aleatórias com baixa latência, o armazenamento de dados para a camada de velocidade também deve suportar escritas aleatórias, pois o carregamento em lote de dados neste armazenamento introduz atrasos indesejados. Por outro lado, o armazenamento de dados para a camada batch precisa de suportar escritas em lote, não escritas aleatórias.

Nenhuma solução única de gestão de dados se adequa a todas as tarefas de armazenamento de dados. Soluções diferentes são ótimas para tarefas específicas. A maioria das aplicações reais na cloud e dos processos de big data tem vários requisitos de armazenamento de dados e frequentemente utiliza uma combinação de soluções de armazenamento.

Soluções analíticas modernas, como o Microsoft Fabric, fornecem uma plataforma abrangente que integra vários serviços e ferramentas de dados para atender a diversas necessidades analíticas. O Fabric inclui o OneLake, que é um data lake lógico único e unificado 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 atenda a uma ampla gama de requisitos de armazenamento e processamento de dados.

Escolha um armazenamento de dados analíticos

A Microsoft oferece várias opções para armazenamento de dados, dependendo das suas necessidades:

Diferentes modelos de bases de dados adaptam-se a diferentes tipos de tarefas:

Os armazenamentos de dados-chave-valor contêm um único objeto serializado para cada valor-chave. Podem gerir grandes volumes de dados quando a recuperação é baseada numa chave específica, sem necessidade de consultar outras propriedades do item.
Os armazenamentos de dados de documentos são armazenamentos de dados-chave-valor nos quais os valores são documentos. Neste contexto, um documento é uma coleção de campos nomeados e valores. O armazenamento de dados normalmente armazena os dados num formato como XML, YAML, JSON ou JSON binário, mas pode usar texto simples. Os repositórios de dados de documentos podem consultar campos não-chave e definir índices secundários para melhorar a eficiência das consultas. Esse recurso torna um banco de dados de documentos 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, pode consultar campos como ID do produto, ID do cliente ou nome do cliente.
Os armazenamentos de dados da família de colunas são armazenamentos de dados-chave-valor que mantêm cada coluna separadamente no disco. Um armazenamento de colunas largas armazena famílias de colunas, não apenas colunas individuais. Por exemplo, uma base de dados censitária pode ter uma família de colunas separada para cada um dos atributos de um indivíduo:
- Primeiro nome, nome do meio e apelido
- Endereço para correspondência
- Informação do perfil, como data de nascimento ou género
O armazenamento de dados pode armazenar cada família de colunas numa partição separada, mantendo todos os dados de uma pessoa relacionados com a mesma chave. Uma aplicação pode ler uma única família de colunas sem examinar todos os dados de uma entidade.
Os repositórios de dados de grafos armazenam informação como uma coleção de objetos e relações. Um armazenamento de dados em grafos pode realizar eficientemente consultas que percorrem 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 você pode querer facilitar consultas como "encontrar todos os funcionários que trabalham direta ou indiretamente para Scott".
Telemetria e bases de dados de séries temporais são uma coleção de objetos de apenas acréscimo. As bases de dados de telemetria indexam dados de forma eficiente em várias estruturas de colunas e na memória. Essa capacidade os torna a escolha ideal para armazenar e analisar grandes quantidades de dados de telemetria e séries temporais.

O Fabric suporta vários modelos de bases de dados, incluindo bases de dados-chave-valor, documentos, armazenamento de colunas, grafos e telemetria. Essa flexibilidade garante escalabilidade para uma ampla gama de tarefas analíticas. Para escolher o armazenamento de dados Fabric certo para as suas cargas de trabalho analíticas, consulte o guia de decisão 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 armazenamento de acesso rápido que possa servir como um canal rápido para os seus dados? Se sim, escolha opções que sejam ótimas para uma camada de serviço rápido.
Você precisa de suporte de processamento paralelo massivo, onde as consultas são distribuídas automaticamente em vários processos ou nós? Em caso afirmativo, selecione uma opção que ofereça suporte à expansão da consulta.
Você prefere usar um armazenamento de dados relacional? Se sim, escolha opções que tenham um modelo de base de dados relacional. No entanto, alguns armazenamentos não relacionais suportam sintaxe SQL para consultas, e pode usar ferramentas como endpoints de análise SQL para consultar armazenamentos de dados não relacionais, como o OneLake.
Recolhem dados de séries cronológicas? Você utiliza dados de adição apenas? O OneLake suporta múltiplos motores analíticos, incluindo Analysis Services, T-SQL e Apache Spark. A Eventhouse é bem adequada para diversas necessidades de processamento e consulta de dados em séries temporais.

Matriz de capacidades

As tabelas seguintes resumem as principais diferenças de capacidades entre estes serviços geridos.

Capacidades gerais

Capacidade	Lakehouse	Armazém de Dados	Eventhouse	Banco de dados SQL Fabric	Base de Dados SQL do Azure	Azure Cosmos DB	Analysis Services
Modelo de banco de dados primário	Formato delta lake unificado de data lake, relacional, gerido pelos utilizadores usando Apache Parquet	Formato Delta Lake de data lake unificado, relacional e gerido pelo sistema, utilizando Apache Parquet	Armazenamento de dados de séries temporais orientado para anexação, grafo, vetor	Relacional (formato de armazenamento em colunas quando se usam índices columnstore)	Relacional (formato de armazenamento em colunas quando se usam índices columnstore)	Armazenamento de documentos, gráfico, armazenamento de chave-valor, armazenamento de colunas amplas	Modelos semânticos tabulares
Suporte à linguagem SQL	Sim¹	Sim	Sim²	Sim	Sim	Sim	Não
Otimizado para a camada de fornecimento rápido	Sim	Sim	Sim³	Sim⁴	Sim⁵	Sim	Não

[1] T-SQL via endpoint de análise SQL.

[2] A Linguagem de Consulta Kusto (KQL) tem suporte parcial para linguagens T-SQL.

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

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

[5] Utilizando tabelas e índices de hash otimizados para memória ou não clusterizados.

Recursos de escalabilidade

Capacidade	Lakehouse	Armazém de Dados	Eventhouse	Banco de dados SQL Fabric	Base de Dados SQL do Azure	Azure Cosmos DB	Analysis Services
Servidores regionais redundantes para alta disponibilidade	Sim^1,2	Sim^1,2	Sim	Sim	Sim	Sim	Sim
Suporta expansão de consulta	Sim³	Sim⁴	Sim⁵	Sim	Não	Sim	Sim
Escalabilidade dinâmica (escalar verticalmente)	Sim³	Sim⁴	Sim⁵	Sim	Sim	Sim	Sim
Suporta cache de dados na memória	Sim⁶	Sim⁶	Sim⁷	Sim	Sim	Sim	Não

Os endpoints SQL são encaminhados através de gestores globais de tráfego, mas a região de capacidade do Fabric atribuída processa sempre os dados.

[2] O Lakehouse e o Warehouse armazenam dados no OneLake no formato Delta Parquet, que suporta consulta e replicação entre motores.

[3] A Lakehouse suporta expansão baseada no Spark para dados estruturados e não estruturados.

[4] O Warehouse utiliza T-SQL e suporta transações multitable, gestão autónoma de cargas de trabalho e processamento distribuído de consultas (DQP). O DQP atua como um gerenciador de cluster, alocando dinamicamente recursos de computação com base na complexidade da consulta.

[5] O Eventhouse suporta federação KQL e SQL para análises em tempo real em múltiplas fontes e para escalar recursos de computação se o uso de cache quente exceder ~95%.

[6] Cache inteligente para trabalhos Spark, cache na memória, cache de conjunto de resultados para pontos finais de análise SQL.

[7] Os dados frequentemente acedidos são armazenados numa cache quente que inclui armazenamento em memória e SSD.

Funcionalidades de segurança

Capacidade	Lakehouse	Armazém de Dados	Eventhouse	Banco de dados SQL Fabric	Base de Dados SQL do Azure	Azure Cosmos DB	Analysis Services
Autenticação	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	SQL ou Microsoft Entra ID	Usuários de banco de dados ou Microsoft Entra ID via controle de acesso (gerenciamento de identidade e acesso)	Microsoft Entra ID
Encriptação de dados em repouso	Sim	Sim	Sim	Sim	Sim¹	Sim	Sim
Segurança ao nível da linha	Sim	Sim	Sim	Sim	Sim	Não	Sim
Suporta firewalls	Sim²	Sim²	Sim³	Sim	Sim	Sim	Sim
Máscara de dados dinâmica	Sim⁴	Sim⁴	Não	Sim	Sim	Não	Não

[1] Requer que utilize encriptação transparente de dados para encriptar e desencriptar os seus dados em repouso.

[2] Utilizar Links Privados e Acesso Condicional do Microsoft Entra para restringir o acesso aos recursos 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] Aplique-o ao nível do endpoint Fabric SQL.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

Mohit Agarwal | Arquiteto Principal de Soluções em Nuvem

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

Comentários

Esta página foi útil?

Last updated on 2026-08-29