Arquiteturas de Big Data

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 na área de Big Data varia entre as organizações, dependendo de suas ferramentas e competências dos usuários. Algumas organizações gerenciam centenas de gigabytes de dados e outras organizações gerenciam centenas de terabytes. À medida que as ferramentas para trabalhar com conjuntos de Big Data evoluem, a definição de Big Data muda de foco apenas no tamanho dos dados para enfatizar o valor derivado da análise avançada. Embora esses tipos de cenários tendem a ter grandes quantidades de dados.

Ao longo dos anos, o cenário dos dados vem mudando. Houve uma mudança no que você pode fazer ou o que deve fazer, com os dados. O custo do armazenamento caiu drasticamente, enquanto os métodos de coleta de dados continuam a ser expandidos. Alguns dados chegam em um ritmo rápido e exigem coleta e observação contínuas. Outros dados chegam mais lentamente, mas em grandes partes, 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 fontes de big data em repouso
• Processamento em tempo real de Big Data em movimento
• Exploração interativa de Big Data
• Análise preditiva e aprendizado de máquina

Considere as arquiteturas de Big Data quando você precisar realizar as seguintes tarefas:

• Armazenar e processar dados em volumes muito grandes para um banco de dados tradicional
• Transformar dados não estruturados para análise e relatórios
• Capturar, processar e analisar fluxos não associados de dados em tempo real ou com baixa latência

Componentes de uma arquitetura de Big Data

O diagrama a seguir mostra os componentes lógicos de uma arquitetura de Big Data. Soluções individuais podem não conter todos os itens neste diagrama.

O processo começa em fontes de dados. Os dados são enviados para o armazenamento de dados e para a ingestão de mensagens em tempo real, que estão interconectados. Os dados no armazenamento de dados vão para processamento em lote e depois vão para o armazenamento de dados analíticos e depois para análise e relatórios ou diretamente para análise e relatórios. Os dados na ingestão de mensagens em tempo real vão para o processamento de fluxo. Em seguida, ele vai para o armazenamento de dados analíticos e depois para análise e relatórios, ou diretamente para análise e relatórios. O aprendizado de máquina aponta para processamento em lote e processamento de fluxo.

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 IoT (Internet das Coisas).

• Armazenamento de dados: Os dados para operações de processamento em lotes normalmente são armazenados em um repositório de arquivos distribuído que pode conter grandes volumes de arquivos grandes em vários formatos. Esse tipo de repositório geralmente é 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 lotes de execução longa para filtrar, agregar e preparar dados para análise. Normalmente, esses trabalhos envolvem ler arquivos de origem, processá-los e gravar a saída em novos arquivos. Você pode usar as seguintes opções:

  • Execute trabalhos U-SQL no Azure Data Lake Analytics.

  • Use trabalhos Hive, Pig ou MapReduce personalizados em um cluster Azure HDInsight Hadoop.

  • Use programas Java, Scala ou Python em um cluster HDInsight Spark.

  • Use a linguagem Python, Scala ou SQL nos notebooks do Azure Databricks.

  • Use a linguagem Python, Scala ou SQL em blocos de anotações 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 repositório de ingestão de mensagens para servir como um buffer para mensagens e para dar suporte ao processamento de expansão, à entrega confiável e a outra semântica de enfileiramento de mensagens. Essa parte de uma arquitetura de streaming geralmente é conhecida como buffer de fluxo. Entre as opções estão 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 então gravados em um coletor de saída.

  • O Azure Stream Analytics é um serviço de processamento de fluxo gerenciado que usa consultas SQL em execução contínua que operam em fluxos não associados.

  • Você pode usar tecnologias de streaming do Apache de software livre, como o Spark Streaming, em um cluster HDInsight ou 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 dá suporte ao processamento de dados em tempo real usando fluxos de eventos e processamento do Spark.

• Machine learning: Para analisar dados preparados do processamento em lote ou de fluxo, você pode usar algoritmos de machine learning para criar modelos que prevejam resultados ou classifiquem dados. Esses modelos podem ser treinados em grandes conjuntos de dados. Você pode usar os modelos resultantes para analisar novos dados e fazer previsões.

  Use o Azure Machine Learning para realizar essas tarefas. O Machine Learning fornece ferramentas para criar, treinar e implantar modelos. Como alternativa, você pode usar APIs pré-criadas dos serviços de IA do Azure para tarefas comuns de aprendizado de máquina, como visão, fala, linguagem e tarefas de tomada de decisão.

• Armazenamento de dados analíticos: Muitas soluções de Big Data preparam dados para análise e servem 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 BI (business intelligence) usa esse tipo de data warehouse. 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 interativo do Hive que fornece uma abstração de metadados sobre arquivos de dados no armazenamento de dados distribuído.

  • O Azure Synapse Analytics é um serviço gerenciado para armazenamento de dados baseado em nuvem em larga escala.

  • O HDInsight dá suporte a Hive Interativo, HBase e Spark SQL. Essas ferramentas podem fornecer dados para análise.

  • O Fabric fornece vários armazenamentos de dados, incluindo bancos de dados SQL, data warehouses, lakehouses e eventhouses. Essas ferramentas podem fornecer 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álise e relatórios: A maioria das soluções de Big Data se esforça para fornecer insights sobre os dados por meio de análise e relatórios. Para capacitar os usuários a analisar 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 tabulares no Azure Analysis Services. Ele também pode dar suporte ao 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 relatar por meio da exploração interativa de dados. Para esses cenários, muitos serviços do Azure dão suporte a notebooks 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 larga 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 de processamento de dados repetidas encapsuladas em fluxos de trabalho. As operações fazem as seguintes tarefas:

  • Transformar dados de origem
  • Mover dados entre várias fontes e coletores
  • Carregar os dados processados em um armazenamento de dados analíticos
  • Enviar 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 de que os clientes precisam. Essas consultas não podem ser executadas em tempo real. E eles geralmente exigem algoritmos como 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 levar 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 Lambda resolve esse problema criando dois caminhos para o fluxo de dados. Todos os dados que entram no sistema passam pelos dois caminhos a seguir:

• Uma camada de lote (caminho frio) armazena todos os dados recebidos em sua forma bruta e executa o processamento em lote nos dados. O resultado desse processamento é armazenado como uma exibição em lote.

• Uma camada de velocidade (caminho ativo) analisa dados em tempo real. Essa camada foi projetada para baixa latência, em detrimento da precisão.

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

A fonte de fluxo de dados é um log unificado de dados de eventos. Os dados vão para a camada de velocidade ou para a camada de lote. Na camada de velocidade, uma linha sólida aponta para o cliente de análise e uma linha pontilhada aponta para a camada de serviço. Na camada de lote, os dados vão para a camada de serviço e, em seguida, para o cliente de análise. A camada de velocidade é rotulada como um caminho ativo. A camada de lote e a camada de serviço são rotuladas como caminho frio.

Os dados que fluem para o caminho quente 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 podem 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 de entrada.

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.

Por fim, os caminhos quentes e frios convergem no aplicativo cliente de análise. Se o cliente precisar exibir dados oportunos, mas potencialmente menos precisos, em tempo real, ele adquire o resultado do caminho ativo. Caso contrário, o cliente seleciona os resultados do caminho frio para exibir dados menos oportunos, mas mais precisos. Em outras palavras, o caminho quente contém dados para uma janela relativamente pequena de tempo, após o qual os resultados podem ser atualizados com os dados mais precisos do caminho frio.

Os dados brutos armazenados na camada de lote são imutáveis. Os dados de entrada são acrescentados aos dados existentes e os dados anteriores não são substituídos. As alterações no valor de um determinado datum são armazenadas como um novo registro de evento com carimbo de data/hora. Os registros de evento com carimbo de data/hora permitem a recompilação a qualquer momento no 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 conforme o sistema evolui.

Arquitetura Kappa

Uma desvantagem para a arquitetura Lambda é sua complexidade. A lógica de processamento aparece em dois locais diferentes, os caminhos frios e quentes, por meio 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 as mesmas metas básicas que a arquitetura lambda, mas todos os dados fluem por meio de um único caminho por meio de um sistema de processamento de fluxo.

A fonte de fluxo de dados é um log unificado de dados de eventos. Os dados vão para a camada de velocidade ou para o armazenamento de longo prazo. A linha dos dados de origem para o armazenamento de longo prazo diz "eventos de espelho para armazenamento de longo prazo." O armazenamento de longo prazo aponta para a camada de velocidade. Essa linha diz "recalcular eventos de log a partir do armazenamento, se necessário". A camada de velocidade aponta para o cliente de análise e é descrita em verde.

Semelhante à camada de lote da arquitetura Lambda, os dados do evento são imutáveis e todos 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. Esses eventos são ordenados e o estado atual de um evento é alterado apenas por um novo evento acrescentado. Semelhante à camada de velocidade da arquitetura Lambda, todo o processamento de eventos é executado no fluxo de entrada e persistido como uma visualização em tempo real.

Se você precisar recompor todo o conjunto de dados (equivalente ao que a camada de lote faz na arquitetura lambda), poderá reproduzir o fluxo. Esse processo normalmente usa paralelismo para concluir a computação em tempo hábil.

Arquitetura do 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 (arquivos de áudio e imagens). 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, portanto, é 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álise e BI. Os data warehouses podem ajudá-lo a tomar decisões informadas fornecendo uma exibiçã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 dê suporte a dados estruturados e não estruturados, o que permite o gerenciamento e análise de dados eficientes. Esses sistemas normalmente usam o armazenamento em nuvem de baixo custo em formatos abertos, como Parquet ou Optimized Row Columnar, para armazenar dados brutos e processados.

Casos de uso comuns para uma arquitetura de casa no lago incluem:

• Análise unificada: Ideal para organizações que precisam de uma única plataforma para análise de dados histórico e em tempo real

• Machine learning: Dá suporte a cargas de trabalho avançadas de análise e machine learning integrando recursos de gerenciamento de dados

• Governança de dados: Garante a conformidade e a qualidade dos dados em grandes conjuntos de dados

IoT

O IoT representa qualquer dispositivo que se conecta à Internet e envia ou recebe dados. Os dispositivos IoT incluem computadores, 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 corretamente para lidar com essas restrições e requisitos exclusivos.

Arquiteturas orientadas por eventos são essenciais para 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 fluxo de dados começa com os dispositivos à esquerda, que estão conectados a um gateway de campo, o qual, por sua vez, se conecta a um gateway de nuvem. O gateway de nuvem se conecta a várias tarefas por meio de processamento de fluxo. As tarefas incluem armazenamento a frio, análise de caminho quente, notificações e aprendizado de máquina. A análise em lote aponta para o armazenamento a frio. O processamento de fluxo aponta para o back-end do aplicativo, que aponta para o comando e controle, a API de provisionamento e o registro do dispositivo. A API de provisionamento aponta para o registro do dispositivo. Pontos de comando e controle para o gateway de campo original e para outros dispositivos, não para os dispositivos originais no fluxo de dados.

O gateway de nuvem ingere eventos de dispositivos 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 software ou dispositivo especializado, geralmente colocado com os dispositivos, que recebe eventos e os encaminha para o gateway de 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 processamento incluem:

• Gravação de dados de evento em armazenamento frio para arquivamento ou análise em lote.

• Análise de caminho ativo. Analise o fluxo de eventos quase em tempo real para detectar anomalias, reconhecer padrões em janelas de tempo sem interrupção ou disparar alertas quando uma condição específica ocorrer no fluxo.

• Tratamento de tipos especiais de mensagens que não são de telemetria de dispositivos, como notificações e alarmes.

• Aprendizado de máquina.

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

• O registro de dispositivo é um banco de dados dos dispositivos provisionados, incluindo as IDs do dispositivo e, geralmente, os metadados do dispositivo, como localização.

• A API de provisionamento é uma interface externa comum para provisionar e registrar novos dispositivos.

• Algumas soluções de IoT permitem que mensagens de comando e controle sejam enviadas para dispositivos.

Próximas etapas

• Hub IoT
• Hubs de Eventos
• Stream Analytics
• Azure Data Explorer
• Tecido
• Azure Databricks

Recursos relacionados

• arquiteturas de IoT
• Estilo de arquitetura de Big Data
• Arquitetura de análise moderna com o Azure Databricks
• Arquiteturas de Big Data com o Fabric