Escolher um armazenamento de dados analíticos no Azure

  • Artigo

Em uma arquitetura de big data , muitas vezes há a necessidade de um armazenamento de dados analíticos que sirva dados processados em um formato estruturado que possa ser consultado 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 serviço lida com dados processados do caminho quente e do caminho frio. Na arquitetura lambda, a camada de serviço é subdividida em uma camada de serviço de velocidade, que armazena dados que foram processados incrementalmente, e uma camada de serviço em lote, que contém a saída processada em lote. A camada de serviço requer forte suporte para leituras aleatórias com baixa latência. O armazenamento de dados para a camada de velocidade também deve suportar gravações aleatórias, porque o carregamento de dados em lote nesse armazenamento introduziria atrasos indesejados. Por outro lado, o armazenamento de dados para a camada em lote não precisa suportar gravações aleatórias, mas gravações em lote.

Não há uma única melhor opção de gerenciamento de dados para todas as tarefas de armazenamento de dados. Diferentes soluções de gerenciamento de dados são otimizadas para diferentes tarefas. A maioria dos aplicativos de nuvem do mundo real e processos de big data têm uma variedade de requisitos de armazenamento de dados e geralmente usam uma combinação de soluções de armazenamento de dados.

Quais são as suas opções ao escolher um armazenamento de dados analíticos?

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

Essas opções fornecem vários modelos de banco de dados otimizados para diferentes tipos de tarefas:

  • Os bancos de dados de chave/valor contêm um único objeto serializado para cada valor de chave. Eles são bons para armazenar grandes volumes de dados onde você deseja obter um item para um determinado valor de chave e não precisa consultar com base em outras propriedades do item.
  • As bases de dados documentais são bases de dados chave/valor em que os valores são documentos. Um "documento" neste contexto é uma coleção de campos nomeados e valores. O banco de dados normalmente armazena os dados em um formato como XML, YAML, JSON ou BSON, 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 tornar a consulta mais eficiente. Isso 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, você pode consultar campos como ID do produto, ID do cliente ou nome do cliente.
  • Os bancos de dados de armazenamento de colunas são armazenamentos de dados de chave/valor que armazenam cada coluna separadamente no disco. Um banco de dados de armazenamento de coluna ampla é um tipo de banco de dados de armazenamento de coluna que armazena famílias de colunas, não apenas colunas únicas. Por exemplo, um banco de dados de censo pode ter uma família de colunas para o nome de uma pessoa (primeiro, meio, último), uma família para o endereço da pessoa e uma família para as informações de perfil da pessoa (data de nascimento, sexo). O banco de dados pode armazenar cada família 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 ler todos os dados de uma entidade.
  • Os bancos de dados gráficos armazenam informações como uma coleção de objetos e relações. Um banco de dados gráfico 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 você pode querer 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 de objetos somente acréscimo. Os bancos de dados de telemetria indexam dados de forma eficiente em uma variedade de armazenamentos de colunas e estruturas na memória, tornando-os a escolha ideal para armazenar e analisar grandes quantidades de dados de telemetria e séries temporais.

Principais critérios de seleção

Para restringir as escolhas, comece por responder a estas perguntas:

  • Você precisa de armazenamento de serviço que possa servir como um caminho ativo para seus dados? Se sim, restrinja suas opções para aquelas que são otimizadas para uma camada de serviço de velocidade.

  • Você precisa de suporte a processamento paralelo maciço (MPP), 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? Em caso afirmativo, restrinja suas opções para aqueles com um modelo de banco de dados relacional. No entanto, observe que alguns armazenamentos não relacionais oferecem suporte à sintaxe SQL para consulta, e ferramentas como o PolyBase podem ser usadas para consultar armazenamentos de dados não relacionais.

  • Recolhem dados de séries cronológicas? Você usa dados somente de acréscimo?

Matriz de capacidades

As tabelas a seguir resumem as principais diferenças nos recursos.

Capacidades gerais

Capacidade Base de Dados SQL Azure Synapse SQL pool Azure Synapse Spark pool Azure Data Explorer HBase/Phoenix no HDInsight LLAP do Hive no HDInsight Azure Analysis Services BD do Cosmos para o Azure
É serviço gerenciado Sim Sim Sim Sim Sim 1 Sim 1 Sim Sim
Modelo de banco de dados primário Relacional (formato de armazenamento de colunas ao usar índices columnstore) Tabelas relacionais com armazenamento de colunas Armazenamento de coluna ampla Relational (armazenamento de coluna), telemetria e armazenamento de séries temporais Armazenamento de coluna ampla Colmeia/Na memória Modelos semânticos tabulares Armazenamento de documentos, gráfico, armazenamento de chave-valor, armazenamento de colunas amplas
Suporte à linguagem SQL Sim Sim Sim Sim Sim (usando o driver JDBC Phoenix ) Sim Não Sim
Otimizado para a camada de serviço de velocidade Sim 2 Sim 3 Sim Sim Sim Sim Não Sim

[1] Com configuração manual e dimensionamento.

[2] Com tabelas com otimização de memória e índices não em cluster ou hash.

[3] Com suporte como uma saída do Azure Stream Analytics.

Recursos de escalabilidade

Capacidade Base de Dados SQL Azure Synapse SQL pool Azure Synapse Spark pool Azure Data Explorer HBase/Phoenix no HDInsight LLAP do Hive no HDInsight Azure Analysis Services BD do Cosmos para o Azure
Servidores regionais redundantes para alta disponibilidade Sim No No Sim Sim Não Sim Sim
Suporta expansão de consulta Não Sim Sim Sim Sim Sim Sim Sim
Escalabilidade dinâmica (scale-up) Sim Sim Sim Sim No No Sim Sim
Suporta cache de dados na memória Sim Sim Sim Sim Não Sim Sim No

Funcionalidades de segurança

Capacidade Base de Dados SQL Azure Synapse Azure Data Explorer HBase/Phoenix no HDInsight LLAP do Hive no HDInsight Azure Analysis Services BD do Cosmos para o Azure
Autenticação SQL / Microsoft Entra ID SQL / Microsoft Entra ID Microsoft Entra ID local / Microsoft Entra ID 1 local / Microsoft Entra ID 1 Microsoft Entra ID usuários de banco de dados / Microsoft Entra ID via controle de acesso (IAM)
Encriptação de dados inativa Sim 2 Sim 2 Sim Sim 1 Sim 1 Sim Sim
Segurança ao nível da linha Sim Sim 3 Sim Sim 1 Sim 1 Sim No
Suporta firewalls Sim Sim Sim Sim 4 Sim 4 Sim Sim
Máscara de dados dinâmica Sim Sim Sim Sim 1 Sim No Não

[1] Requer a utilização de um cluster HDInsight associado a um domínio.

[2] Requer o uso de criptografia de dados transparente (TDE) para criptografar e descriptografar seus dados em repouso.

[3] Apenas predicados de filtro. Consulte Segurança em nível de linha

[4] Quando utilizado numa Rede Virtual do Azure. Consulte Estender o Azure HDInsight usando uma Rede Virtual do Azure.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Próximos passos