Beusa Energy è da 30 anni una forza di interruzione nel settore energetico, con un gruppo di aziende che operano in diversi ambiti: fratturazione idraulica elettrica, generazione di energia mobile, distribuzione elettrica, trattamento del gas sul campo e produzione industriale. Operando in ambienti nordamericani impegnativi con telemetria ad alta frequenza da migliaia di asset remoti, Beusa ha inizialmente utilizzato una soluzione personalizzata MQTT e SQL per inviare i dati al lakehouse di Databricks. Tuttavia, il costo per GB non era economicamente scalabile con i loro volumi di dati in crescita esponenziale. Per evitare in modo proattivo questo ostacolo, Beusa ha cercato un nuovo modello di ingestione per Scale senza soluzione di continuità, eliminare l'overhead IT e ridurre i costi dei dati senza rallentare il proprio slancio operativo.
L'esplosione dei volumi di dati rivela i limiti di una pipeline SQL personalizzata
Quando il team Data & AI di Beusa ha creato per la prima volta il suo bridge da MQTT a lakehouse, Zerobus Ingest non esisteva ancora. Un servizio worker .NET 9 sottoscritto ai broker MQTT in tutta la flotta ha analizzato i payload JSON e Sparkplug B e ha scritto nelle tabelle Delta tramite l'API SQL Statement. È stato distribuito rapidamente, ha funzionato in modo affidabile e ha fornito all'azienda la sua prima visione quasi in tempo reale delle attività operative nel lakehouse. Il problema non era operativo, ma economico. Con l'aumento del numero di dispositivi e dei volumi di dati, il costo per GB sul percorso dell'API SQL Statement era palesemente insostenibile e il team poteva vederlo sul grafico prima che diventasse una crisi.
"L'API SQL Statement è un ottimo strumento, ma non è stata progettata per la telemetria operativa ad alta frequenza", ha affermato Nick Fornicola, Director of Data & AI Platforms presso Beusa Energy. "Ci ha permesso di andare in produzione e ci ha dato mesi di tempo per comprovare il caso d'uso. Ma una volta compreso il carico di lavoro, avevamo bisogno di un percorso di ingestion sviluppato appositamente."
Il team ha valutato due categorie di alternative: broker MQTT gestiti con interfacce compatibili con Kafka (di cui HiveMQ è il più importante) e broker di streaming tradizionali come Kafka e Azure Event Hubs che alimentano Databricks tramite Structured Streaming. I prezzi di HiveMQ non si adattavano alla loro Scale e alla loro traiettoria. Il percorso con Kafka e Event Hubs avrebbe introdotto un livello di broker stateful da gestire, proteggere e pagare, in aggiunta alla fattura esistente di Databricks. Zerobus Ingest era l'unica opzione che consentiva scritture dirette nelle tabelle Delta dal worker esistente senza aggiungere un livello di broker. Una volta fatti i conti, la scelta è stata palese. Beusa ha visto il muro all'orizzonte, ha fatto i conti e ha cambiato strada prima di sbatterci contro.
Un percorso diretto al lakehouse, senza aggiungere un livello di broker
Zerobus Ingest è un'API di scrittura diretta creata appositamente per sorgenti di dati operativi come IoT, telemetria e clickstream, in cui i dati devono confluire nelle tabelle Delta in modo continuo, su larga scala e con una latenza di pochi secondi. La migrazione ha richiesto una sola modifica: sostituire la chiamata API SQL Statement con l'endpoint gRPC di Zerobus. Stesso worker .NET 9. Stesse sottoscrizioni MQTT. Stessa gestione dei payload Sparkplug B e JSON. Nessuna modifica alla configurazione dei dispositivi.
"Non abbiamo dovuto riscrivere il worker, non abbiamo modificato i broker upstream e non abbiamo toccato una singola configurazione dei dispositivi", ha spiegato Fornicola. "Abbiamo scambiato il percorso di scrittura, eseguito nuovamente il deployment e visto scendere la curva dei costi."
L'ingestione che costava circa 689 DBU per GB sul percorso dell'API SQL Statement è scesa a circa 0,29 DBU per GB su Zerobus, una riduzione di tre ordini di grandezza per lo stesso carico di lavoro, gli stessi payload e le stesse tabelle Delta downstream. Beusa ha anche evitato di implementare un livello di broker di streaming completamente separato, eliminando un'intera classe di infrastruttura stateful.
Oggi, più di 6.000 dispositivi eseguono lo Stream di dati di telemetria a 1 Hz da circa 250 asset remoti in un lakehouse centrale, con una latenza end-to-end dal sensore alla tabella Delta interrogabile di circa tre secondi, gestita da Unity Catalog e pronta per l'uso non appena viene scritta.
Dal risparmio sui costi alla manutenzione predittiva su larga scala
La riduzione dei costi ha giustificato la migrazione, ma l'impatto più ampio è stato quello di sbloccare la Scale senza complicazioni operative. Oggi, Zerobus Ingest elabora senza sforzo circa 22 milioni di righe di telemetria al giorno con manutenzione zero, offrendo al team uno stack semplificato e un percorso futuro economicamente vantaggioso. La telemetria ad alta frequenza ora alimenta le analitiche interfunzionali per la leadership delle attività operative, la gestione della flotta, l'ingegneria, i controlli e l'automazione: decisioni che prima venivano prese in base all'intuito o a report obsoleti, ora sono guidate da dati unificati quasi in tempo reale.
"Il nostro historian è un ottimo sistema di registrazione di ciò che è accaduto su un'apparecchiatura", ha detto Fornicola. "Ma per rispondere alle domande che l'azienda si pone effettivamente, su intere flotte, su interi bacini, attraverso gli eventi di manutenzione, abbiamo bisogno di quei dati nel lakehouse, uniti a tutto il resto. Zerobus è ciò che lo rende economicamente sostenibile sulla nostra scala."
La nuova architettura fornisce inoltre a Beusa un percorso chiaro per far progredire la sua strategia di manutenzione attraverso una progressione di maturità definita:
Oggi — Manutenzione basata sulle condizioni: la manutenzione è Trigger dalle condizioni operative attuali e dallo stato osservato delle apparecchiature, meglio che a intervalli fissi, ma ancora reattiva a ciò che sta accadendo in questo momento.
In corso — Manutenzione predittiva: con la telemetria ad alta frequenza ora disponibile nel lakehouse insieme alla cronologia della manutenzione, Beusa sta addestrando modelli per prevedere la vita utile residua di ciascun asset. Nella fratturazione idraulica, i componenti ad alta usura si guastano secondo una curva influenzata da decine di variabili operative: pressione, portata, proprietà dei fluidi, cicli e altro ancora. La modellazione di queste relazioni consente all'azienda di allocare il tempo di manutenzione in base alla traiettoria delle condizioni effettive di ciascun asset, anziché a una pianificazione fissa.
Prossimo passo — Manutenzione prescrittiva: una volta che il livello predittivo sarà maturo, l'obiettivo è passare dalla previsione dei guasti alla raccomandazione di azioni, riconciliando automaticamente i guasti previsti con le pianificazioni della flotta, l'inventario dei ricambi, la disponibilità del personale, le condizioni meteorologiche e altri vincoli operativi.
Con l'espansione della flotta, l'economia unitaria dell'ingestione non impone più un limite a quali dati possono essere acquisiti o a ciò che l'azienda può chiedere.
"La lezione per noi è che non tutte le migrazioni devono far risparmiare denaro per valerne la pena; a volte si tratta di ridurre il carico operativo o migliorare la latenza, a volte di entrambi", ha osservato Fornicola. "Zerobus Ingest ci ha fatto risparmiare un sacco di soldi, ha semplificato il nostro stack e ci ha indirizzato verso un percorso gestito. È una cosa rara."
Per Beusa, Zerobus Ingest ha trasformato un difficile compromesso architetturale in una scelta ovvia. I dati fluiscono dal sito del pozzo al lakehouse in pochi secondi, gli ingegneri hanno smesso di preoccuparsi del costo di ogni record scritto e l'azienda ha ottenuto un percorso più rapido dal segnale all'azione operativa.
