Beusa Energy es una fuerza disruptiva desde hace 30 años en el sector energético, con un grupo de empresas que abarcan la fracturación hidráulica eléctrica, la generación de energía móvil, la distribución eléctrica, el procesamiento de gas de campo y la fabricación industrial. Al operar en entornos exigentes de Norteamérica con telemetría de alta frecuencia desde miles de activos remotos, Beusa utilizó inicialmente una solución personalizada de MQTT y SQL para enviar datos al lakehouse de Databricks. Sin embargo, el costo por GB no podía escalar económicamente con el crecimiento explosivo de sus volúmenes de datos. Para evitar este obstáculo de forma proactiva, Beusa buscó un nuevo modelo de ingesta para escalar sin problemas, eliminar los gastos generales de TI y reducir los costos de los datos sin ralentizar su impulso operativo.
El crecimiento exponencial de los volúmenes de datos expone los límites de una canalización de SQL personalizada.
Cuando el equipo de Datos & IA de Beusa construyó por primera vez su puente de MQTT a lakehouse, Zerobus Ingest todavía no existía. Un servicio de trabajo de .NET 9 se suscribió a los brokers MQTT de toda la flota, analizó las cargas útiles (payloads) de JSON y Sparkplug B, y escribió en las tablas Delta a través de la API SQL Statement. Se implementó rápidamente, funcionó de forma fiable y le proporcionó al negocio su primera vista casi en tiempo real de las operaciones en el lakehouse. El problema no era operativo, sino económico. A medida que la cantidad de dispositivos y los volúmenes de datos crecían, el costo por GB en la ruta de la API SQL Statement era visiblemente insostenible, y el equipo pudo verlo en el gráfico antes de que se convirtiera en una crisis.
"La API SQL Statement es una gran herramienta, pero no fue diseñada para la telemetría operativa de alta frecuencia", dijo Nick Fornicola, director de Plataformas de Datos e IA en Beusa Energy. "Nos llevó a producción y nos dio meses de margen para demostrar el caso de uso. Pero una vez que conocimos la carga de trabajo, necesitábamos una ruta de ingesta creada específicamente para ella".
El equipo evaluó dos categorías de alternativas: brókers MQTT gestionados con interfaces compatibles con Kafka (siendo HiveMQ el más destacado) y brókers de streaming tradicionales como Kafka y Azure Event Hubs que alimentan Databricks a través de Structured Streaming. El precio de HiveMQ no se ajustaba a su escala y trayectoria. La ruta de Kafka y Event Hubs introduciría un nivel de bróker con estado para operar, proteger y pagar, además de la factura existente de Databricks. Zerobus Ingest era la única opción que permitía escrituras directas en las tablas Delta desde el worker existente sin agregar una capa de bróker. Una vez que hicieron los cálculos, la decisión fue clara. Beusa vio el muro que se aproximaba, hizo los cálculos y cambió de rumbo antes de chocar.
Una ruta directa al lakehouse, sin agregar una capa de bróker
Zerobus Ingest es una API de escritura directa diseñada especialmente para fuentes de datos operativos como IoT, telemetría y clickstreams, donde los datos deben llegar a las tablas Delta de forma continua, a escala y con segundos de latencia. La migración requirió un único cambio: reemplazar la llamada a la API de SQL Statement por el endpoint gRPC de Zerobus. Mismo worker de .NET 9. Mismas suscripciones MQTT. Mismo manejo de payloads de Sparkplug B y JSON. No se modificó la configuración de ningún dispositivo.
"No tuvimos que reescribir el worker, no cambiamos los brokers ascendentes y no tocamos ni una sola configuración de dispositivo", explicó Fornicola. "Cambiamos la ruta de escritura, volvimos a desplegar y vimos caer la curva de costos".
La ingesta que costaba aproximadamente 689 DBU por GB en la ruta de la API de sentencias SQL se redujo a aproximadamente 0.29 DBU por GB en Zerobus, lo que supuso una reducción de tres órdenes de magnitud para la misma carga de trabajo, las mismas cargas útiles y las mismas tablas Delta descendentes. Beusa también evitó por completo la implementación de una capa de intermediario de streaming independiente, lo que eliminó toda una clase de infraestructura con estado.
Hoy en día, más de 6000 dispositivos transmiten telemetría a 1 Hz a través de aproximadamente 250 activos remotos a un lakehouse central, con una latencia de extremo a extremo desde el sensor hasta la tabla Delta consultable de alrededor de tres segundos, gobernada por Unity Catalog y lista para su uso en el momento en que se escribe.
Del ahorro de costos al mantenimiento predictivo a escala
La reducción de costos justificó la migración, pero el mayor impacto fue permitir el escalamiento sin complicaciones operativas. Hoy, Zerobus Ingest procesa sin esfuerzo ~22 millones de filas de telemetría a diario y sin mantenimiento, lo que le brinda al equipo una pila simplificada y un camino rentable a seguir. La telemetría de alta frecuencia ahora alimenta los análisis multifuncionales del liderazgo de operaciones, la gestión de flotas, la ingeniería y los controles y la automatización; las decisiones que antes se tomaban por intuición o a partir de informes desactualizados ahora están impulsadas por datos unificados y casi en tiempo real.
"Nuestro historiador es un gran sistema de registro de lo que sucedió en un equipo", dijo Fornicola. "Pero para responder a las preguntas que el negocio realmente hace —en todas las flotas, cuencas y eventos de mantenimiento—, necesitamos esos datos en el lakehouse, unidos con todo lo demás. Zerobus es lo que hace que eso sea económicamente viable a nuestra escala".
La nueva arquitectura también le proporciona a Beusa un camino claro para avanzar en su estrategia de mantenimiento a través de una progresión de madurez definida:
Hoy — Mantenimiento basado en la condición: El mantenimiento se activa por las condiciones operativas actuales y el estado observado del equipo; es mejor que los intervalos fijos, pero sigue siendo reactivo a lo que sucede ahora mismo.
En curso — Mantenimiento predictivo: Con la telemetría de alta frecuencia ahora en el lakehouse, junto con el historial de mantenimiento, Beusa está entrenando modelos para pronosticar la vida útil restante de cada activo. En la fracturación hidráulica, los componentes de alto desgaste fallan según una curva influenciada por docenas de variables operativas: presión, caudal, propiedades del fluido, ciclos y más. Modelar esas relaciones le permite a la empresa asignar el tiempo de mantenimiento a la trayectoria de la condición real de cada activo en lugar de a un cronograma fijo.
A continuación — Mantenimiento prescriptivo: una vez que la capa predictiva madure, el objetivo es pasar de pronosticar fallas a recomendar acciones, conciliando automáticamente las fallas pronosticadas con los cronogramas de la flota, el inventario de piezas, la disponibilidad del personal, el clima y otras limitaciones operativas.
A medida que la flota se expande, la economía unitaria de la ingesta ya no establece un límite para los datos que se pueden capturar o para lo que el negocio puede solicitar a partir de ellos.
"La lección para nosotros es que no todas las migraciones tienen que ahorrar dinero para que valgan la pena; a veces es para reducir la carga operativa o para mejorar la latencia, a veces es por ambas cosas", señaló Fornicola. “Zerobus Ingest nos ahorró mucho dinero, simplificó nuestro stack y nos puso en un camino administrado hacia el futuro. Eso es poco común."
Para Beusa, Zerobus Ingest convirtió una difícil compensación arquitectónica en una obviedad. Los datos fluyen desde el sitio del pozo hasta el lakehouse en segundos, los ingenieros dejaron de preocuparse por el costo de cada registro escrito y el negocio obtuvo una vía más rápida desde la señal operativa hasta la acción operativa.
