¿Qué es DirectQuery vs modo Import para tableros de SCADA?
Cuando usted construye un tablero sobre datos de SCADA o del historian en una herramienta como Power BI, una de las primeras decisiones es cómo se conectan los datos al modelo: DirectQuery o modo Import. Suena técnico, pero decide si su tablero muestra la última lectura o una instantánea, si responde al instante o tras una pausa, y si siquiera puede sostener el volumen de datos de series de tiempo con el que está lidiando. Import cachea los datos dentro del modelo por velocidad; DirectQuery los deja en la fuente y los consulta en vivo por frescura. Para datos de SCADA, donde los volúmenes pueden ser enormes, la elección muchas veces la fuerzan los datos mismos. Esta guía compara los dos y da una regla para elegir.
DirectQuery vs modo Import en una línea: DirectQuery y el modo Import son las dos formas en que una herramienta de BI como Power BI se conecta a una fuente de datos. En modo Import los datos se copian al modelo y se cachean, así que las consultas corren contra esa copia rápida en memoria pero los datos son sólo tan actuales como el último refresco, y el modelo está acotado por un límite de tamaño de dataset. En DirectQuery los datos se quedan en la fuente y la herramienta envía una consulta en vivo en cada interacción, así que el tablero siempre muestra datos actuales y no hay necesidad de que todo quepa en el modelo, pero cada interacción depende de la velocidad y la carga de la fuente. Para datos de series de tiempo de SCADA de alto volumen, el puro tamaño por lo general fuerza DirectQuery o la preagregación porque los datos crudos no cabrán en un modelo importado.
Cómo maneja los datos cada modo
El modo Import trae los datos al modelo. Cuando el dataset se refresca, la herramienta jala una copia de los datos de la fuente y la almacena en una estructura comprimida en memoria dentro del modelo, y de ahí en adelante cada consulta que el tablero hace corre contra esa copia local en lugar de tocar la fuente. La ventaja es la velocidad: un almacén columnar en memoria responde filtros, agregaciones y desgloses muy rápido, así que los tableros importados se sienten ágiles. Las desventajas son que los datos quedan congelados en el último refresco hasta que corra el siguiente, y que todo el dataset tiene que caber dentro del límite de tamaño del modelo, que acota cuántos datos puede importar.
DirectQuery deja los datos en la fuente. Nada se copia al modelo; en cambio, cada vez que el tablero necesita datos - al cargar, en cada filtro, en cada desglose - la herramienta genera una consulta y la envía a la fuente, luego muestra el resultado. La ventaja es la frescura y la escala: como la herramienta consulta la fuente en vivo, el tablero refleja el estado actual de los datos, y como nada se importa, no hay un techo de tamaño de dataset del que preocuparse, así que una fuente que sostiene miles de millones de renglones puede respaldar un tablero que sólo pide la rebanada que necesita. La desventaja es que cada interacción es un viaje de ida y vuelta a la fuente, así que la responsividad depende de qué tan rápido responde la fuente y cuánta carga puede aguantar.
El intercambio esencial es entonces velocidad y autonomía contra frescura y escala. Import da un desempeño rápido y consistente desde una copia cacheada pero a costa de datos rancios entre refrescos y un límite de tamaño. DirectQuery da datos actuales y sin límite de tamaño pero ata cada interacción del tablero al desempeño de la fuente. No hay una respuesta universalmente correcta; el modo correcto depende de qué tan frescos deben ser los datos, qué tan grandes son y cuánta carga de consulta puede absorber la fuente, y por eso la elección merece reflexión deliberada en lugar de tomar por defecto el modo que la herramienta sugiere primero.
Por qué los volúmenes de SCADA empujan hacia DirectQuery o la preagregación
Los datos de SCADA y del historian tienen una propiedad que domina esta decisión: el volumen. Miles de tags muestreados cada pocos segundos a lo largo de meses y años se acumulan en un historial de miles de millones de muestras, que es mucho más de lo que un modelo importado está diseñado para sostener. Tratar de importar el historial crudo de alta frecuencia choca de frente con el límite de tamaño de dataset, e incluso donde técnicamente cabe, el refresco se vuelve enormemente largo y el modelo inmanejable. Así que la característica misma que define a los datos de SCADA - series de tiempo de alta frecuencia, alta cardinalidad y de larga duración - es justo lo que hace impráctico el import ingenuo.
Esto deja dos caminos viables. Uno es DirectQuery, donde los datos crudos se quedan en el historian y el tablero consulta sólo los tags específicos y los rangos de tiempo que muestra, así que el total enorme nunca tiene que caber en un modelo. Esto preserva el acceso a datos de resolución completa bajo demanda, pero depende de que el historian pueda responder esas consultas rápido, y las consultas de series de tiempo de alta cardinalidad pueden ser lentas, así que DirectQuery sólo funciona bien si la fuente es genuinamente rápida en las consultas que hace el tablero. El otro camino es la preagregación, donde los datos de alta frecuencia se enrollan en resúmenes más gruesos - promedios, mínimos, máximos y totales por hora o por día - que son lo bastante pequeños para importar con soltura, dando tableros rápidos a costa de la granularidad más fina.
En la práctica muchos tableros de SCADA combinan los dos. Las tendencias rutinarias y los KPI se sirven de datos preagregados importados por velocidad, mientras que una vista en vivo o detallada usa DirectQuery para alcanzar el historian crudo cuando la resolución completa de verdad se necesita. Este híbrido da la responsividad del import para el caso común y la frescura y profundidad de DirectQuery para las excepciones, sin tratar de importar el historial crudo inimportable. El punto unificador es que el volumen crudo no puede simplemente importarse al por mayor, así que todo buen diseño de tablero de SCADA tiene que decidir, por vista, si está consultando en vivo o leyendo un caché preagregado.
Una regla de selección para tableros operativos y SCADA de nube
Una regla de selección práctica cae de los intercambios. Elija modo Import cuando los datos sean lo bastante pequeños para caber con soltura en el modelo y un refresco periódico sea lo bastante fresco, que es el caso de tendencias preagregadas, KPI y reportes gerenciales que no necesitan actualidad segundo a segundo. Elija DirectQuery cuando los datos deban ser actuales al momento, cuando el volumen sea demasiado grande para importar, o cuando necesite alcanzar detalle de resolución completa bajo demanda, aceptando que la responsividad dependerá de la fuente. Cuando ninguno embona limpio - la situación clásica de SCADA de datos enormes que también necesitan algo de frescura - preagregue para el caso común importado y reserve DirectQuery para las vistas en vivo o detalladas.
Para los tableros operativos en específico, vale la pena ser honesto sobre el requisito de actualidad. Una pantalla operativa verdadera que impulsa decisiones minuto a minuto quiere datos en vivo y se inclina hacia DirectQuery o una fuente en vivo rápida, mientras que un resumen operativo de turno o diario se sirve perfectamente bien de datos preagregados importados y refrescados en un calendario. Decidir qué tan fresco necesita ser de verdad cada tablero, en lugar de suponer que todo debe ser en vivo, evita poner carga de consulta continua innecesaria sobre el historian, porque DirectQuery en todos lados puede machacar una fuente que habría estado bien sirviendo refrescos periódicos. Ajustar el modo a la necesidad real de frescura es el meollo de diseñar tableros operativos que sean a la vez lo bastante actuales y con buen desempeño.
Una plataforma SCADA de nube como Merobix facilita esta elección al servir las consultas que un tablero necesita de forma eficiente, sea cual sea el modo usado. Como la plataforma puede exponer enrollamientos preagregados así como detalle crudo, un tablero puede importar los agregados para sus vistas rutinarias rápidas y usar DirectQuery contra el punto de la plataforma para las vistas en vivo o de alta resolución, sin que un equipo tenga que construir las capas de agregación y consulta por sí mismo. Para las operaciones de campo, eso significa que sus tableros pueden ser a la vez responsivos y frescos - leyendo resúmenes cacheados donde una instantánea basta y consultando en vivo donde el momento importa - con el problema de volumen manejado por la plataforma en lugar de forzado sobre el modelo de BI.
Preguntas frecuentes
¿Cuál es la diferencia principal entre DirectQuery y el modo Import?
El modo Import copia los datos al modelo y los cachea, así que las consultas corren rápido contra esa copia local pero los datos son sólo tan actuales como el último refresco y deben caber dentro de un límite de tamaño de dataset. DirectQuery deja los datos en la fuente y envía una consulta en vivo en cada interacción, así que el tablero siempre muestra datos actuales y no hay límite de tamaño, pero cada interacción depende de la velocidad y la carga de la fuente. Import cambia frescura y escala por velocidad; DirectQuery cambia velocidad por frescura y escala.
¿Por qué los datos de SCADA suelen forzar DirectQuery o la preagregación?
Porque el volumen crudo es demasiado grande para importar. Miles de tags muestreados cada pocos segundos a lo largo de años se vuelven miles de millones de muestras, que exceden lo que un modelo importado puede sostener y hacen los refrescos impracticablemente largos. Las opciones viables son DirectQuery, donde los datos crudos se quedan en el historian y el tablero consulta sólo la rebanada que muestra, o la preagregación, donde los datos de alta frecuencia se enrollan en resúmenes por hora o por día lo bastante pequeños para importar. Muchos tableros usan ambos, importando agregados por velocidad y usando DirectQuery para detalle de resolución completa bajo demanda.
¿Un tablero operativo debe usar DirectQuery o modo Import?
Depende de qué tan actual necesita ser de verdad el tablero. Una pantalla operativa verdadera que impulsa decisiones minuto a minuto quiere datos en vivo y se inclina hacia DirectQuery o una fuente en vivo rápida, mientras que un resumen de turno o diario se sirve bien de datos preagregados importados en un refresco calendarizado. Ser honesto sobre el requisito real de frescura importa, porque usar DirectQuery en todos lados pone carga de consulta continua sobre el historian que los imports periódicos habrían evitado, así que el modo debe ajustarse a la actualidad real que cada vista necesita.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.