Maria, analista de mercado da CVM, precisa analisar milhares de negociações financeiras para obter insights e tomar decisões ao longo do dia. Maria apresentou a demanda para Tiago, o arquiteto de big data da CVM.Para processar as negociações financeiras como uma sequência de eventos no tempo, agrupando e filtrando os dados à medida que são capturados, o componente da arquitetura de big data que Tiago deve desenvolver é o:
AOrquestrator;
BBatch Processor;
CAnalytical Data Store;
DStreaming Processor;
EReal-timing Message Ingestion.
Revelar gabarito e comentário▾
GabaritoD — Streaming Processor;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Arquitetura de Big Data – Processamento de Fluxo (Streaming)
Gabarito: letra D – Streaming Processor. O cenário descreve a necessidade de processar negociações financeiras como uma sequência contínua de eventos, agrupando e filtrando dados em tempo real, no momento da captura. Isso é exatamente a função de um Streaming Processor, que lida com fluxos contínuos de dados (streaming) e executa transformações quase em tempo real.
A banca testa o conhecimento dos componentes típicos de uma arquitetura de Big Data, em especial a diferença entre processamento em lote (batch) e em fluxo (streaming). É essencial associar os requisitos do enunciado à ferramenta ou componente correto.
Componente
Função Principal
Adequação ao Cenário (processar fluxo contínuo de eventos, agrupando/filtrando em tempo real)
Orquestrator
Coordenar e agendar workflows (geralmente em lote)
❌ Não processa dados em tempo real
Batch Processor
Processar dados em blocos agendados (lotes)
❌ Não atende fluxo contínuo
Analytical Data Store
Repositório para dados já processados (consultas analíticas)
❌ Não processa fluxo de entrada
Streaming Processor
Consumir e processar dados em fluxo contínuo (agrupamento, filtragem, agregações)
✅ Ideal para o cenário
Real-timing Message Ingestion
Capturar e transportar mensagens (ingestão)
❌ Apenas transporta, não processa
Alternativa A – ❌ Incorreta
Orquestrator (ex.: Apache Oozie, Airflow) é responsável por coordenar e agendar fluxos de trabalho (workflows) compostos por múltiplas tarefas, geralmente em lote. Não realiza o processamento direto dos dados em tempo real.
Alternativa B – ❌ Incorreta
Batch Processor (ex.: MapReduce, Spark Batch) processa dados em blocos agendados (lotes), não em fluxo contínuo. O enunciado pede processamento "à medida que são capturados", o que inviabiliza o uso de lotes.
Alternativa C – ❌ Incorreta
Analytical Data Store (ex.: Amazon Redshift, Google BigQuery) é um repositório para dados já processados, voltado a consultas analíticas. Não realiza processamento em tempo real sobre o fluxo de entrada.
Alternativa D – ✅ Correta ⟵ GABARITO
Streaming Processor (ex.: Apache Flink, Spark Streaming, Kafka Streams) é projetado para consumir e processar dados em fluxo contínuo, permitindo agrupamento, filtragem e agregações em tempo real. Exatamente o que Maria precisa.
Alternativa E – ❌ Incorreta
Real-timing Message Ingestion (ex.: Apache Kafka, Amazon Kinesis) é o componente de ingestão de mensagens – ele captura e transporta os dados, mas não os processa (não agrupa, filtra ou transforma). O processamento em si é feito pelo Streaming Processor.
PEGA ESSA DICA!
Na hora da prova, associe palavras-chave. "Sequência de eventos no tempo", "à medida que são capturados" → streaming. "Agrupar e filtrar" → processamento, não apenas ingestão. O componente que processa é o Streaming Processor; a ingestão é etapa anterior.