BOOM and Babamul: a real-time, multi-survey, optical alert broker system operating at scale

Resumo Técnico: BOOM e o Sistema de Corretor de Alertas Babamul

Declaração do Problema
O advento de levantamentos ópticos de grande campo de alto rendimento, culminando no Levantamento de Espaço e Tempo (LSST) do Observatório Vera C. Rubin, apresenta um desafio de processamento de dados que excede a capacidade dos sistemas de corretor de alertas atuais. Enquanto o Zwicky Transient Facility (ZTF) gera ~10^5–10^6 alertas por noite, o LSST deve produzir ~2 × 10^7 alertas diariamente. Corretores existentes, majoritariamente construídos sobre pilhas baseadas em Python (por exemplo, Kowalski), lutam para escalar eficientemente para esses volumes enquanto mantêm os requisitos de baixa latência necessários para o acompanhamento em tempo real de transientes rápidos. Além disso, a comunidade científica exige a capacidade de realizar filtragem conjunta em múltiplos levantamentos sobrepostos (por exemplo, ZTF, LSST e outros) para caracterizar a evolução de fenômenos rápidos, uma capacidade não suportada nativamente por arquiteturas de levantamento único.

Metodologia e Arquitetura do Sistema
Os autores apresentam o BOOM (Monitor de Observações de Explosões e Erupções), um corretor de alertas em tempo real e multi-levantamento projetado para escalabilidade horizontal e alto rendimento. O sistema representa uma mudança arquitetônica fundamental em relação ao seu predecessor, Kowalski, ao afastar-se de um design monolítico baseado em Python para uma pilha de software baseada em Rust compilada.

Componentes arquitetônicos chave incluem:

• Ingestão e Mensageria: O sistema utiliza Apache Kafka para ingerir fluxos de alertas no formato Avro de vários levantamentos. Para lidar com a comunicação entre processos sem os gargalos de E/S de tópicos baseados em disco, o BOOM emprega o Valkey (um armazenamento de dados em memória de alto desempenho) como uma fila de trabalhos. Isso permite que múltiplos processos trabalhadores consumam alertas concorrentemente de listas residentes em memória.
• Armazenamento de Dados: O MongoDB serve como banco de dados primário, escolhido por sua flexibilidade, suporte multi-linguagem e indexação nativa GeoJSON para consultas espaciais (buscas em cone). O modelo de dados separa os dados em três coleções:
  • Alerta: Contém metadados de candidatos e a detecção mais recente.
  • Objeto: Agrega dados de séries temporais (curvas de luz) e cruzamentos para objetos astronômicos únicos, evitando duplicação entre alertas.
  • Recorte: Armazena recortes de imagens científicas, de referência e de diferença.
• Pipeline de Processamento Paralelizado: O BOOM decompõe o fluxo de trabalho de processamento de alertas em tipos de trabalhadores dedicados e paralelizáveis:
  1. Trabalhador de Ingestão de Alertas: Desserializa pacotes Avro, realiza cruzamentos contra catálogos arquivais estáticos e coleções de objetos dinâmicas de outros levantamentos suportados, e popula o banco de dados.
  2. Trabalhador de Enriquecimento: Processa lotes de alertas para calcular pontuações de aprendizado de máquina (ML) e características pré-calculadas. Utiliza ONNX (Open Neural Network eXchange) para executar modelos treinados em Python (por exemplo, ACAI, BTSbot) dentro do pipeline Rust. O sistema também suporta aceleração opcional por GPU para inferência em lote e ajuste de curvas de luz (usando Processos Gaussianos e Otimização por Enxame de Partículas).
  3. Trabalhador de Filtro: Executa filtros definidos pelo usuário (definidos como pipelines de agregação do MongoDB) em lotes de alertas enriquecidos. Constrói dinamicamente estágios de pesquisa para recuperar dados necessários da coleção de Objetos, garantindo uso eficiente de recursos.
• Interface de Usuário e API: Uma API RESTful permite buscas arquivais e a reexecução de filtros em dados históricos. Para reduzir a barreira de entrada para astrônomos, um Construtor de Filtros Visual e Baseado em Blocos (integrado ao SkyPortal) permite a criação de consultas complexas sem exigir conhecimento da linguagem de consulta subjacente do banco de dados.

Contribuições Principais

1. Filtragem Conjunta Multi-Levantamento: O BOOM foi projetado para ingerir e filtrar conjuntamente múltiplos fluxos de alertas simultaneamente. Ao cruzar alertas de diferentes levantamentos (por exemplo, ZTF e DECam/LSST) em tempo real, permite a construção de curvas de luz conjuntas, abordando as limitações de cadência e profundidade de levantamentos únicos.
2. Desempenho e Escalabilidade: A migração para Rust e a adoção de uma fila de trabalhos em memória (Valkey) acoplada ao processamento em lote melhoram significativamente o rendimento. O sistema demonstra paridade de recursos com corretores ZTF existentes, enquanto alcança um rendimento aproximadamente 7 vezes maior.
3. Design Modular e Extensível: A separação de preocupações (Ingestão, Enriquecimento, Filtragem) permite a escalabilidade independente de etapas específicas de processamento com base em gargalos de carga de trabalho.
4. Babamul: Os autores apresentam o Babamul, um corretor de alertas LSST de acesso público construído sobre o BOOM. Fornece fluxos Kafka disjuntos e categorizados (por exemplo, separando correspondências estelares de candidatos a transientes) e inclui um cliente Python para integração fácil.

Resultados

• Testes de Rendimento: Em testes de referência usando uma noite de dados do ZTF (29.142 alertas), o BOOM demonstrou escalabilidade superior em comparação ao Kowalski. Com 8 processos trabalhadores, o BOOM processou alertas a uma taxa suficiente para lidar com a taxa de alertas projetada do Observatório Rubin (~333 alertas/s) com uma pegada de memória de ~1 GB, comparado aos 13 GB do Kowalski para a mesma configuração.
• Validação de Levantamento Conjunto: Um experimento conjunto envolvendo o ZTF e o Levantamento de Transientes DECam (DTS) validou com sucesso a capacidade do sistema de cruzar alertas entre levantamentos com diferentes profundidades e cadências. O sistema identificou 207 candidatos multi-levantamento, incluindo a SN 2025kwy, demonstrando a capacidade de restringir a evolução de tempo inicial de transientes usando dados combinados.
• Estimativas de Armazenamento: Os autores estimam que, para um levantamento LSST de 10 anos, o requisito total de armazenamento para o BOOM (incluindo alertas, objetos e uma retenção de 7 dias de recortes) seria de aproximadamente 75 TB, uma figura derivada de uma escala conservadora dos dados existentes do ZTF.

Significado
O artigo posiciona o BOOM como um componente crítico de infraestrutura para a "era Rubin", permitindo que a comunidade gerencie o aumento exponencial no volume de alertas enquanto desbloqueia novos casos científicos através da sinergia multi-levantamento. Ao fornecer um framework escalável e de alto rendimento que suporta filtragem conjunta e oferece ferramentas amigáveis ao usuário para criação de filtros, o BOOM visa facilitar a descoberta de transientes raros e de rápida evolução (como supernovas jovens e kilonovas) que, de outra forma, seriam perdidos pela análise de levantamento único. O sistema já está operacional no ZTF e está sendo implantado para lidar com alertas públicos do LSST, servindo como base para a interface pública do Babamul.