A Beusa Energy é uma força de interrupção há 30 anos no setor de energia, com um grupo de empresas que abrange fraturamento hidráulico elétrico, geração de energia móvel, distribuição elétrica, processamento de gás de campo e manufatura industrial. Operando em ambientes exigentes da América do Norte com telemetria de alta frequência de milhares de ativos remotos, a Beusa usou inicialmente uma solução personalizada de MQTT e SQL para enviar dados para o lakehouse da Databricks. No entanto, o custo por GB não podia ser dimensionado economicamente com seus volumes de dados em rápida expansão. Para evitar proativamente esse obstáculo, a Beusa buscou um novo modelo de ingestão para escala perfeitamente, eliminar a sobrecarga de TI e reduzir os custos de dados sem desacelerar seu ritmo operacional.
O aumento explosivo no volume de dados expõe os limites de um pipeline de SQL personalizado.
Quando a equipe de Dados & AI da Beusa construiu sua ponte MQTT para o lakehouse pela primeira vez, o Zerobus Ingest ainda não existia. Um serviço de worker do .NET 9 se inscreveu em brokers MQTT em toda a frota, analisou cargas úteis JSON e Sparkplug B e escreveu em tabelas Delta através da API de Instrução SQL. Ele foi lançado rapidamente, funcionou de forma confiável e deu à empresa sua primeira view quase em tempo real das operações no lakehouse. O problema não era operacional, era econômico. À medida que o número de dispositivos e os volumes de dados aumentavam, o custo por GB no caminho da SQL Statement API era visivelmente insustentável, e a equipe pôde ver isso no gráfico antes que se tornasse uma crise.
"A API SQL Statement é uma ótima ferramenta, mas não foi projetada para telemetria operacional de alta frequência", disse Nick Fornicola, Diretor de Plataformas de Dados e IA da Beusa Energy. "Ela nos levou à produção e nos deu meses de fôlego para provar o caso de uso. Mas quando conhecemos a carga de trabalho, precisávamos de um caminho de ingestão criado especificamente para ela."
A equipe avaliou duas categorias de alternativas: brokers MQTT gerenciados com interfaces compatíveis com Kafka (sendo o HiveMQ o mais proeminente) e brokers de transmissão tradicionais, como Kafka e Azure Event Hub, alimentando o Databricks via Structured Streaming. O preço do HiveMQ não se adequava à sua escala e trajetória. O caminho com Kafka e Event Hubs introduziria uma camada de broker stateful para operar, proteger e pagar, além da fatura existente do Databricks. O Zerobus Ingest era a única opção que permitia a gravação direta em tabelas Delta a partir do worker existente, sem adicionar uma camada de broker. Depois que fizeram as contas, a escolha não foi difícil. A Beusa viu o obstáculo, fez as contas e mudou de caminho antes de colidir com ele.
Um caminho direto para o lakehouse, sem adicionar uma camada de broker
O Zerobus Ingest é uma API de escrita direta criada especificamente para fontes de dados operacionais, como IoT, telemetria e fluxos de cliques, onde os dados precisam chegar às tabelas Delta continuamente, em escala e com latência de segundos. A migração exigiu uma única alteração: swap a chamada da API SQL Statement pelo Endpoint gRPC do Zerobus. Mesmo worker .NET 9. Mesmas inscrições MQTT. Mesmo tratamento de payload Sparkplug B e JSON. Nenhuma configuração de dispositivo foi alterada.
"Não tivemos que reescrever o worker, não alteramos os brokers upstream e não mexemos em uma única configuração de dispositivo", explicou Fornicola. "Trocamos o caminho de escrita, reimplantamos e vimos a curva de custo cair."
A ingestão que custava cerca de 689 DBUs por GB no caminho da API de instrução SQL caiu para aproximadamente 0,29 DBU por GB no Zerobus — uma redução de três ordens de magnitude na mesma carga de trabalho, mesmos payloads e mesmas tabelas Delta downstream. A Beusa também evitou completamente a implementação de uma camada de broker de transmissão separada, eliminando toda uma classe de infraestrutura stateful.
Hoje, mais de 6.000 dispositivos fazem transmissão de telemetria a 1 Hz em aproximadamente 250 ativos remotos para um lakehouse central, com latência de ponta a ponta do sensor à tabela Delta consultável em torno de três segundos, governada pelo Unity Catalog e pronta para uso no momento em que é gravada.
Da economia de custos à manutenção preditiva em escala
A redução de custos justificou a migração, mas o impacto mais amplo foi permitir a escala sem dores de cabeça operacionais. Hoje, o Zerobus Ingest processa sem esforço aproximadamente 22 milhões de linhas de telemetria por dia com manutenção zero, proporcionando à equipe um stack simplificado e um caminho econômico para o futuro. A telemetria de alta frequência agora alimenta analítica multifuncional para liderança de operações, gerenciamento de frotas, engenharia e controles e automação — decisões que antes eram tomadas com base na intuição ou em relatórios defasados agora são orientadas por dados unificados e quase em tempo-real.
"Nosso historian é um ótimo sistema de registro do que aconteceu em um equipamento", disse Fornicola. "Mas para responder às perguntas que a empresa realmente faz — entre frotas, bacias e eventos de manutenção — precisamos desses dados no lakehouse, unidos a todo o resto. O Zerobus é o que torna isso economicamente viável na nossa escala."
A nova arquitetura também oferece à Beusa um caminho claro para avançar em sua estratégia de manutenção por meio de uma progressão de maturidade definida:
Hoje — Manutenção baseada em condição: A manutenção é acionada pelas condições operacionais atuais e pelo estado observado do equipamento — melhor que em intervalos fixos, mas ainda reativa ao que está acontecendo no momento.
Em andamento — Manutenção preditiva: com a telemetria de alta frequência agora no lakehouse junto com a história de manutenção, a Beusa está em treinamento de modelos para prever a vida útil restante de cada ativo. No fraturamento hidráulico, componentes de alto desgaste falham em uma curva influenciada por dezenas de variáveis operacionais — pressão, vazão, propriedades do fluido, ciclos e muito mais. A modelagem dessas relações permite que a empresa aloque o tempo de manutenção de acordo com a trajetória da condição real de cada ativo, em vez de programar de forma fixa.
A seguir — Manutenção Prescritiva: Assim que a camada preditiva amadurecer, o objetivo é passar da previsão de falhas para a recomendação de ações, reconciliando automaticamente as falhas previstas com as programações da frota, o inventário de peças, a disponibilidade da equipe, o clima e outras restrições operacionais.
À medida que a frota se expande, a economia unitária da ingestão não impõe mais um teto sobre os dados que podem ser capturados ou o que a empresa pode fazer com eles.
"A lição que aprendemos é que nem toda migração precisa gerar economia para valer a pena; às vezes, o objetivo é reduzir a carga operacional ou melhorar a latência, e às vezes, ambos", observou Fornicola. “O Zerobus Ingest nos economizou muito dinheiro, simplificou nossa stack e nos colocou em um caminho gerenciado para o futuro. Isso é raro."
Para a Beusa, o Zerobus Ingest transformou um difícil tradeoff de arquitetura em uma decisão óbvia. Os dados fluem do local do poço para o lakehouse em segundos, os engenheiros pararam de se preocupar com o custo de cada registro gravado e a empresa obteve um caminho mais rápido do sinal operacional para a ação operacional.
