¿Qué es un conjunto de datos push de Power BI para SCADA en tiempo real?

El endpoint REST de filas y los mosaicos de streaming

Un conjunto de datos push invierte el flujo habitual de Power BI. En lugar de que Power BI alcance un origen para jalar datos, el origen envía datos a Power BI haciendo solicitudes HTTP POST al endpoint de filas del conjunto, y cada solicitud lleva una o más filas que coinciden con el esquema definido del conjunto. Para el SCADA, esto significa que un gateway de borde o un servicio de integración que ya ve los cambios de tags puede publicar esas lecturas directamente en el conjunto conforme ocurren, y el tablero las refleja sin ningún ciclo de actualización. El conjunto se crea con un esquema fijo de columnas, y las filas empujadas deben conformarse a él, así que la forma de la telemetría, como una estampa de tiempo, un nombre de tag y un valor, se decide cuando se define el conjunto.

Hay una distinción importante entre un conjunto push y un conjunto de streaming, aunque ambos usen un endpoint de push. Un conjunto push almacena las filas que recibe, así que puede respaldar visuales de reporte normales y conserva datos según su política, mientras que un conjunto puramente de streaming solo mantiene un búfer transitorio para los mosaicos de streaming y no persiste las filas para reportes estándar. La elección depende de si los valores solo deben parpadear en vivo en un mosaico o también almacenarse para un reporte, y una opción intermedia común es un conjunto que a la vez transmite para mosaicos en vivo y almacena filas para tener disponible la historia reciente en los visuales.

Los mosaicos de streaming son los visuales construidos para consumir estos datos en vivo, y están diseñados para actualizarse automáticamente conforme llegan filas nuevas en vez de en la actualización estándar del visual. Un mosaico de línea que muestra el valor de un tag en los últimos minutos avanza a medida que se empuja cada lectura nueva, dando la sensación viva y en movimiento que una planta quiere en un tablero de operaciones. Como estos mosaicos se hicieron a propósito para el flujo de push, se actualizan mucho más rápido que un visual de reporte que espera una actualización programada del conjunto, que es la razón entera para usar un conjunto push en una pantalla genuinamente en tiempo real.

Límites de retención y control de la tasa de filas

Los conjuntos push no sustituyen a un historiador, y su comportamiento de retención lo deja claro. Un conjunto push conserva filas hasta un límite, y existe una opción para habilitar una política de retención primero en entrar, primero en salir, de modo que cuando el conjunto se llena, las filas más viejas se descartan conforme llegan nuevas, manteniendo una ventana móvil de datos recientes en vez de crecer sin límite. Esto está bien para un tablero que muestra valores y tendencias recientes, pero significa que el conjunto no es el lugar para guardar el registro permanente. La historia duradera de largo plazo tiene que vivir en un historiador o almacén de datos apropiado, con el conjunto push sirviendo solo la vista en vivo y reciente.

Los límites de tasa de filas son la otra restricción que da forma al diseño, porque Power BI impone límites sobre cuántas filas pueden empujarse en un periodo y qué tan grandes pueden ser las solicitudes. Una integración ingenua que publica una solicitud aparte por cada cambio de tag de una planta ocupada puede toparse con estos límites rápido, así que el lado emisor por lo general agrupa varias lecturas en cada solicitud y regula su tasa de envío para mantenerse dentro de lo permitido. El reporte por excepción también ayuda aquí: empujar una lectura solo cuando un valor cambió de manera significativa, en lugar de en cada tick, recorta drásticamente el volumen de filas sin dejar de mantener el tablero en vivo para los valores que de verdad se están moviendo.

Diseñar en torno a estos límites significa, sobre todo, ser selectivo con lo que va al conjunto push. Un tablero en tiempo real rara vez necesita cada tag de la planta; necesita el puñado de valores que los operadores están vigilando ahora mismo. Enviar solo esos tags, a una cadencia basada en cambios, agrupados con sensatez en solicitudes, mantiene la integración bien dentro de los límites de tasa de filas y al conjunto dentro de su ventana de retención, sin dejar de entregar la experiencia en vivo. Intentar empujar toda la telemetría de la planta a plena frecuencia hacia un conjunto push es la forma de topar con todos los límites a la vez, así que la disciplina es empujar lo que necesita estar en vivo y dejar el resto al historiador.

Dónde el push le gana a la actualización programada en SCADA

El caso más claro para un conjunto push es una vista de operaciones en vivo donde los segundos importan. Un tablero de sala de control que muestra flujos, presiones o estados de marcha actuales quiere que los números se muevan conforme se mueve la planta, y una actualización programada, que recarga por temporizador, siempre va detrás de la realidad por lo que dure el intervalo. Los conjuntos push eliminan ese retraso para los valores específicos del mosaico, porque el dato llega en el momento en que el origen lo envía. Para cualquier cosa pensada para transmitir el estado presente de la planta de un vistazo, esa inmediatez es exactamente lo que la actualización programada no puede dar, y es la razón por la que existen los conjuntos push.

Es igual de importante reconocer dónde el push es la herramienta equivocada. El análisis histórico, las comparaciones de tendencias sobre periodos largos y cualquier reporte que necesite el registro completo se sirven mejor con un conjunto almacenado sobre un historiador o almacén, ya sea en modo import o DirectQuery, porque el conjunto push solo mantiene su ventana móvil reciente. La arquitectura sensata usa cada uno para lo que hace mejor: un conjunto push para los mosaicos operativos en vivo, y un conjunto convencional sobre historia duradera para los reportes y el análisis. Intentar que un solo conjunto haga los dos trabajos lo fuerza en las dos direcciones.

Este es un ajuste natural junto a una plataforma de monitoreo en la nube que ya está manejando telemetría SCADA en vivo. Una plataforma como Merobix recolecta los cambios de tags conforme ocurren y conserva la historia duradera, lo que la coloca en una posición ideal para empujar un conjunto curado de valores en vivo hacia un conjunto push de Power BI para un tablero en tiempo real, sin dejar de retener el registro completo para reportes. Esa separación permite que los mosaicos en vivo se mantengan genuinamente actuales desde el stream de la capa de monitoreo, y que los reportes históricos tomen de la historia almacenada, así que los operadores obtienen tanto la vista inmediata como el análisis profundo sin pedirle a un solo conjunto que sirva dos necesidades muy distintas.

Preguntas frecuentes