Arquiteturas de macrodados

Uma arquitetura de big data gerencia a ingestão, o processamento e a análise de dados muito grandes ou complexos para sistemas de banco de dados tradicionais. O limite para entrar no domínio do big data varia entre as organizações, dependendo de suas ferramentas e recursos do usuário. Algumas organizações gerenciam centenas de gigabytes de dados e outras organizações gerenciam centenas de terabytes. À medida que as ferramentas para trabalhar com grandes conjuntos de dados evoluem, a definição de big data deixa de se concentrar apenas no tamanho dos dados para enfatizar o valor derivado da análise avançada. Embora esses tipos de cenários tendam a ter grandes quantidades de dados.

Ao longo dos anos, o panorama dos dados mudou. O que pode fazer com os dados, ou o que é esperado que faça, mudou. O custo do armazenamento caiu drasticamente, enquanto os métodos de recolha de dados continuam a expandir-se. Alguns dados chegam a um ritmo acelerado e requerem recolha e observação contínuas. Outros dados chegam mais lentamente, mas em grandes pedaços e, muitas vezes, na forma de décadas de dados históricos. Você pode encontrar um problema de análise avançada ou um problema que requer aprendizado de máquina para resolver. As arquiteturas de Big Data se esforçam para resolver esses desafios.

As soluções de Big Data normalmente envolvem um ou mais dos seguintes tipos de cargas de trabalho:

Processamento em lote de grandes volumes de dados em descanso
Processamento em tempo real de big data em movimento
Exploração interativa de big data
Análise preditiva e aprendizagem automática

Considere arquiteturas de big data quando precisar executar as seguintes tarefas:

Armazenar e processar dados em volumes muito grandes para um banco de dados tradicional
Transforme dados não estruturados para análise e emissão de relatórios
Capture, processe e analise fluxos ilimitados de dados em tempo real ou com baixa latência

Componentes de uma arquitetura de macrodados

O diagrama a seguir mostra os componentes lógicos de uma arquitetura de big data. As soluções individuais podem não conter todos os itens neste diagrama.

A maioria das arquiteturas de big data inclui alguns ou todos os seguintes componentes:

Fontes de dados: Todas as soluções de big data começam com uma ou mais fontes de dados. Os exemplos incluem:
- Armazenamentos de dados de aplicativos, como bancos de dados relacionais.
- Arquivos estáticos que os aplicativos produzem, como arquivos de log do servidor Web.
- Fontes de dados em tempo real, como dispositivos de Internet das Coisas (IoT).
Armazenamento de dados: Os dados para operações de processamento em lote são normalmente armazenados em um armazenamento de arquivos distribuído que pode armazenar grandes volumes de arquivos grandes em vários formatos. Esse tipo de armazenamento é frequentemente chamado de data lake. As opções para implementar esse armazenamento incluem o Azure Data Lake Store, contêineres de blob no Armazenamento do Azure ou OneLake no Microsoft Fabric.
Processamento em lote: Os conjuntos de dados são grandes, portanto, uma solução de big data geralmente processa arquivos de dados usando trabalhos em lote de longa duração para filtrar, agregar e preparar dados para análise. Normalmente, esses trabalhos envolvem a leitura de arquivos de origem, o processamento deles e a gravação da saída em novos arquivos. Você pode usar as seguintes opções:
- Use a linguagem Python, Scala ou SQL em blocos de anotações do Azure Databricks.
- Use a linguagem Python, Scala ou SQL em notebooks do Fabric.
Ingestão de mensagens em tempo real: Se a solução incluir fontes em tempo real, a arquitetura deverá capturar e armazenar mensagens em tempo real para processamento de fluxo. Por exemplo, você pode ter um armazenamento de dados simples que coleta mensagens de entrada para processamento. No entanto, muitas soluções precisam de um armazenamento de ingestão de mensagens para servir como um buffer para mensagens e para oferecer suporte ao processamento em expansão, entrega confiável e outras semânticas de enfileiramento de mensagens. Essa parte de uma arquitetura de streaming é frequentemente chamada de buffer de fluxo. As opções incluem os Hubs de Eventos do Azure, o Hub IoT do Azure e o Kafka.
Processamento de fluxo: Depois que a solução captura mensagens em tempo real, ela deve processá-las filtrando, agregando e preparando os dados para análise. Os dados de fluxo processados são gravados em um coletor de saída.
- Você pode usar tecnologias de streaming Apache de código aberto, como Spark Streaming, tecnologias de streaming no Azure Databricks.
- O Azure Functions é um serviço de computação sem servidor que pode executar código controlado por eventos, o que é ideal para tarefas leves de processamento de fluxo.
- O Fabric oferece suporte ao processamento de dados em tempo real usando fluxos de eventos e processamento do Spark.
Armazenamento de dados analíticos: Muitas soluções de big data preparam os dados para análise e, em seguida, fornecem os dados processados em um formato estruturado que as ferramentas analíticas podem consultar. O armazenamento de dados analíticos que atende a essas consultas pode ser um data warehouse relacional no estilo Kimball. A maioria das soluções tradicionais de business intelligence (BI) utiliza este tipo de armazém de dados. Como alternativa, você pode apresentar os dados por meio de uma tecnologia NoSQL de baixa latência, como o HBase, ou um banco de dados Hive interativo que fornece uma abstração de metadados sobre arquivos de dados no armazenamento de dados distribuído.
- O Fabric fornece vários armazenamentos de dados, incluindo bancos de dados SQL, data warehouses, lakehouses e eventhouses. Essas ferramentas podem servir dados para análise.
- O Azure fornece outros armazenamentos de dados analíticos, como o Azure Databricks, o Azure Data Explorer, o Banco de Dados SQL do Azure e o Azure Cosmos DB.
Análises e relatórios: A maioria das soluções de big data se esforça para fornecer insights sobre os dados por meio de análises e relatórios. Para permitir que os usuários analisem os dados, a arquitetura pode incluir uma camada de modelagem de dados, como um cubo de processamento analítico online multidimensional ou um modelo de dados tabular no Azure Analysis Services. Ele também pode oferecer suporte a BI de autoatendimento usando as tecnologias de modelagem e visualização no Power BI ou Excel.

Cientistas de dados ou analistas de dados também podem analisar e gerar relatórios por meio da exploração interativa de dados. Para esses cenários, muitos serviços do Azure oferecem suporte a blocos de anotações analíticos, como o Jupyter, para permitir que esses usuários usem suas habilidades existentes com Python ou Microsoft R. Para exploração de dados em grande escala, você pode usar o Microsoft R Server, autônomo ou com o Spark. Você também pode usar o Fabric para editar modelos de dados, o que fornece flexibilidade e eficiência para modelagem e análise de dados.
Orquestração: A maioria das soluções de big data consiste em operações repetidas de processamento de dados que são encapsuladas em fluxos de trabalho. As operações executam as seguintes tarefas:
- Transformar dados de origem
- Mover dados entre várias fontes e coletores
- Carregue os dados processados em um armazenamento de dados analíticos
- Envie os resultados diretamente para um relatório ou painel
Para automatizar esses fluxos de trabalho, use uma tecnologia de orquestração, como o Azure Data Factory, o Fabric ou o Apache Oozie e o Apache Sqoop.

Arquitetura Lambda

Quando você trabalha com grandes conjuntos de dados, pode levar muito tempo para executar o tipo de consultas que os clientes precisam. Essas consultas não podem ser realizadas em tempo real e geralmente exigem algoritmos de processamento distribuído, como o MapReduce , que operam em paralelo em todo o conjunto de dados. Os resultados da consulta são armazenados separadamente dos dados brutos e usados para consultas adicionais.

Uma desvantagem dessa abordagem é que ela introduz latência. Se o processamento demorar algumas horas, uma consulta poderá retornar resultados de várias horas atrás. Idealmente, você deve obter alguns resultados em tempo real, potencialmente com uma perda de precisão, e combinar esses resultados com os resultados da análise em lote.

A arquitetura do Lambda resolve esse problema criando dois caminhos para o fluxo de dados. Todos os dados que entram no sistema passam pelos seguintes dois caminhos:

Uma camada de lote (caminho frio) armazena todos os dados recebidos em seu formato bruto e realiza o processamento dos dados em lote. O resultado desse processamento é armazenado como uma exibição em lote.
Uma camada de velocidade (caminho rápido) analisa os dados em tempo real. Esta camada foi concebida para baixa latência, em detrimento da precisão.

A camada de lotes alimenta uma camada de serviço, que indexa a visão de lotes para uma consulta eficiente. A camada de velocidade atualiza a camada de entrega com atualizações incrementais, com base nos dados mais recentes.

Os dados que fluem para o caminho ativo devem ser processados rapidamente devido aos requisitos de latência que a camada de velocidade impõe. O processamento rápido garante que os dados estejam prontos para uso imediato, mas pode introduzir imprecisão. Por exemplo, considere um cenário de IoT em que vários sensores de temperatura enviam dados de telemetria. A camada de velocidade pode processar uma janela de tempo deslizante dos dados recebidos.

Os dados que fluem para o caminho frio não estão sujeitos aos mesmos requisitos de baixa latência. O caminho frio fornece computação de alta precisão em grandes conjuntos de dados, mas pode levar muito tempo.

Eventualmente, os caminhos quentes e frios convergem na aplicação cliente de análises. Se o cliente precisa exibir dados em tempo útil, mas potencialmente menos precisos em tempo real, ele adquire seu resultado da via rápida. Caso contrário, o cliente seleciona os resultados do caminho frio para exibir dados menos oportunos, mas mais precisos. Por outras palavras, o caminho rápido dispõe de dados para um curto período de tempo, após o qual os resultados podem ser atualizados com dados mais precisos do caminho frio.

Os dados brutos armazenados na camada de lote são imutáveis. Os dados de entrada são anexados aos dados existentes e os dados anteriores não são substituídos. As alterações no valor de um dado específico são armazenadas como um novo registro de evento com carimbo de data/hora. Os registros de eventos com carimbo de data/hora permitem o recálculo a qualquer momento ao longo do histórico dos dados coletados. A capacidade de recalcular a visualização em lote a partir dos dados brutos originais é importante porque permite a criação de novas visualizações à medida que o sistema evolui.

Aprendizado de máquina na arquitetura do Lambda

As arquiteturas Lambda suportam cargas de trabalho de aprendizado de máquina fornecendo dados históricos para treinamento de modelos e dados em tempo real para inferência. A camada em lote permite o treinamento em conjuntos de dados históricos abrangentes usando cargas de trabalho do Azure Machine Learning ou do Fabric Data Science. A camada de velocidade facilita a inferência e a pontuação do modelo em tempo real. Essa abordagem dupla permite modelos treinados em dados históricos completos, ao mesmo tempo em que fornece previsões imediatas sobre fluxos de dados recebidos.

Arquitetura Kappa

Uma desvantagem da arquitetura Lambda é a sua complexidade. A lógica de processamento aparece em dois lugares diferentes, os caminhos frio e quente, através de estruturas diferentes. Esse processo leva à lógica de computação duplicada e ao gerenciamento complexo da arquitetura para ambos os caminhos.

A arquitetura Kappa é uma alternativa à arquitetura Lambda. Ele tem os mesmos objetivos básicos da arquitetura do Lambda, mas todos os dados fluem através de um único caminho por meio de um sistema de processamento de fluxo.

Semelhante à camada em lote da arquitetura do Lambda, os dados de evento são imutáveis e todos eles são coletados, em vez de um subconjunto de dados. Os dados são ingeridos como um fluxo de eventos em um log unificado distribuído e tolerante a falhas. Estes eventos são ordenados e o estado atual de cada evento é alterado apenas por um novo evento que seja anexado. Semelhante à camada de velocidade da arquitetura Lambda, todo o processamento de eventos é realizado no fluxo de entrada e persiste como uma visualização em tempo real.

Se você precisar recalcular todo o conjunto de dados (equivalente ao que a camada de lote faz na arquitetura do Lambda), poderá reproduzir o fluxo. Esse processo normalmente usa paralelismo para concluir o cálculo em tempo hábil.

Machine learning na arquitetura Kappa

As arquiteturas Kappa permitem fluxos de trabalho unificados de aprendizado de máquina processando todos os dados por meio de um único pipeline de streaming. Essa abordagem simplifica a implantação e a manutenção do modelo, uma vez que a mesma lógica de processamento se aplica a dados históricos e em tempo real. Você pode usar cargas de trabalho do Azure Machine Learning ou do Fabric Data Science para criar modelos que processam dados de streaming, permitindo a aprendizagem contínua e a adaptação em tempo real. A arquitetura suporta algoritmos de aprendizagem on-line que atualizam modelos incrementalmente à medida que novos dados chegam.

Arquitetura Lakehouse

Um data lake é um repositório de dados centralizado que armazena dados estruturados (tabelas de banco de dados), dados semiestruturados (arquivos XML) e dados não estruturados (imagens e arquivos de áudio). Esses dados estão em seu formato bruto e original e não exigem esquema predefinido. Um data lake pode lidar com grandes volumes de dados, por isso é adequado para processamento e análise de big data. Os data lakes usam soluções de armazenamento de baixo custo, que fornecem uma maneira econômica de armazenar grandes quantidades de dados.

Um data warehouse é um repositório centralizado que armazena dados estruturados e semiestruturados para fins de relatórios, análises e BI. Os armazéns de dados podem ajudá-lo a tomar decisões informadas, fornecendo uma visão consistente e abrangente de seus dados.

A arquitetura Lakehouse combina os melhores elementos de data lakes e data warehouses. O padrão visa fornecer uma plataforma unificada que suporte dados estruturados e não estruturados, o que permite gerenciamento e análise de dados eficientes. Esses sistemas normalmente usam armazenamento em nuvem de baixo custo em formatos abertos, como Parquet ou Optimized Row Columnar, para armazenar dados brutos e processados.

Os casos de uso comuns para uma arquitetura lakehouse incluem:

Análise unificada: Ideal para organizações que precisam de uma única plataforma para análise de dados históricos e em tempo real
Governança de dados: Garante conformidade e qualidade de dados em grandes conjuntos de dados

Aprendizado de máquina na arquitetura Lakehouse

As arquiteturas Lakehouse se destacam no suporte a fluxos de trabalho de aprendizado de máquina de ponta a ponta, fornecendo acesso unificado a dados estruturados e não estruturados. Os cientistas de dados podem usar cargas de trabalho do Fabric Data Science para acessar dados brutos para análise exploratória, engenharia de recursos e treinamento de modelos sem movimentação complexa de dados. A arquitetura suporta o ciclo de vida completo do aprendizado de máquina, desde a preparação de dados e o desenvolvimento de modelos usando o Azure Machine Learning ou blocos de anotações Fabric, até a implantação e o monitoramento de modelos. A camada de armazenamento unificada permite a colaboração eficiente entre engenheiros de dados e cientistas de dados, mantendo a linhagem e a governança dos dados.

IoT

A IoT representa qualquer dispositivo que se conecta à internet e envia ou recebe dados. Os dispositivos IoT incluem PCs, telefones celulares, relógios inteligentes, termostatos inteligentes, geladeiras inteligentes, automóveis conectados e implantes de monitoramento cardíaco.

O número de dispositivos conectados cresce a cada dia, assim como a quantidade de dados que eles geram. Esses dados geralmente são coletados em ambientes que têm restrições significativas e, às vezes, alta latência. Em outros casos, milhares ou milhões de dispositivos enviam dados de ambientes de baixa latência, o que requer ingestão e processamento rápidos. Você deve planejar adequadamente para lidar com essas restrições e requisitos exclusivos.

As arquiteturas condicionadas por eventos estão no centro das soluções de IoT. O diagrama a seguir mostra uma arquitetura lógica para IoT. O diagrama enfatiza os componentes de streaming de eventos da arquitetura.

O gateway de nuvem ingere eventos do dispositivo no limite da nuvem por meio de um sistema de mensagens confiável e de baixa latência.

Os dispositivos podem enviar eventos diretamente para o gateway de nuvem ou por meio de um gateway de campo. Um gateway de campo é um dispositivo ou software especializado, normalmente na mesma localização dos dispositivos, que recebe eventos e os reencaminha para o gateway da nuvem. O gateway de campo também pode pré-processar os eventos brutos do dispositivo, o que inclui a execução de funções de filtragem, agregação ou transformação de protocolo.

Após a ingestão, os eventos passam por um ou mais processadores de fluxo que podem rotear os dados para destinos, como armazenamento, ou executar análises e outros processamentos.

Os tipos comuns de tratamento incluem:

Gravação de dados de eventos em armazenamento a frio para arquivamento ou análise em lote.
Análise de caminho crítico. Analise o fluxo de eventos quase em tempo real para detetar anomalias, reconhecer padrões em janelas de tempo de rolagem ou disparar alertas quando uma condição específica ocorrer no fluxo.
Processamento de tipos especiais de mensagens não relacionadas à telemetria provenientes de dispositivos, como notificações e alarmes.
Aprendizagem automática para manutenção preditiva, deteção de anomalias e tomada de decisões inteligentes.

No diagrama anterior, as caixas cinzas são componentes de um sistema IoT que não estão diretamente relacionados ao streaming de eventos. Eles estão incluídos no diagrama para completude.

O registo de dispositivos é um banco de dados dos dispositivos provisionados, incluindo as IDs dos dispositivos e, geralmente, os metadados dos dispositivos, como a localização.
A API de provisionamento de é uma interface externa comum para provisionamento e registro de novos dispositivos.
Algumas soluções de IoT permitem que mensagens de comando e controle sejam enviadas para dispositivos.

Aprendizado de máquina na arquitetura IoT

As arquiteturas de IoT usam aprendizado de máquina para computação de borda inteligente e análise baseada em nuvem. Os dispositivos de borda podem executar modelos leves para tomada de decisões em tempo real, enquanto modelos abrangentes processam dados agregados na nuvem usando cargas de trabalho do Azure Machine Learning ou do Fabric Data Science. As aplicações comuns incluem manutenção preditiva, deteção de anomalias e sistemas de resposta automatizados. A arquitetura suporta análise de streaming para insights imediatos e processamento em lote para treinamento e refinamento de modelos usando dados históricos de IoT.

Próximos passos

Feedback

Esta página foi útil?

Last updated on 2025-10-30