Un dashboard Qlik rápido indica con qué rapidez puede responder a una pregunta, no cuánto tiempo ha pasado desde que recibió la actividad de negocio subyacente. Un pedido puede quedar confirmado en el sistema operativo mientras el dashboard sigue mostrando el estado anterior. Mejorar el tiempo de respuesta de los gráficos no cierra, por sí solo, esa brecha.
Para establecer una expectativa útil de actualidad de los datos, siga el evento hasta la vista del usuario: confirmación en origen, captura o extracción, llegada al almacenamiento, transformación, disponibilidad para el análisis y visualización. Mantenga separados la velocidad de respuesta y la antigüedad máxima aceptable de los datos al diagnosticar el rendimiento de los dashboards. Ambos forman parte de la misma decisión de aceptación, pero miden cosas distintas.
Empiece por el modo de acceso de Qlik
En el modo habitual en memoria de Qlik Sense, una recarga de la aplicación obtiene datos y actualiza la instantánea que analizan los usuarios. Las recargas pueden programarse o activarse mediante desencadenadores externos. Los usuarios consultan esa instantánea de la aplicación en lugar de consultar directamente el origen, como describe la documentación de aplicaciones analíticas de Qlik.
Esto convierte la captura de cambios y las recargas de aplicaciones en etapas distintas. La captura previa puede haber entregado un cambio al almacén de datos, pero la aplicación en memoria todavía necesita cargar los datos que contienen ese cambio. Del mismo modo, recargar una aplicación con mayor frecuencia no puede hacer que un conjunto de datos previo esté más actualizado.
Direct Query de Qlik Cloud lee bases de datos SQL sin importar sus datos a la memoria. En ese modo, siga el recorrido desde la base de datos consultada y la solicitud que produjo el resultado mostrado, en lugar de suponer que una recarga en memoria es la última etapa que determina la disponibilidad. Incluya en la evaluación de actualidad de su despliegue cualquier comportamiento aplicable de caché y actualización de vistas.
La distinción es práctica: pregunte qué recorrido de datos utiliza cada visualización relevante. No trate «conectado a la base de datos», «CDC habilitado» o «recarga programada» como descripciones equivalentes de la actualidad de los datos.
La ingesta en streaming es solo una parte del recorrido
La presentación de IBM Cloud sobre lakehouse describe la llegada continua de datos de temas de Kafka a archivos Parquet en almacenamiento de objetos. También relaciona la llegada en pequeños flujos con la acumulación de archivos pequeños y describe un posprocesamiento para mejorar el rendimiento y preparar los datos para su consumo semántico.
Esa arquitectura pone de manifiesto una etapa importante. Que un registro esté presente en un archivo de destino no establece cuándo pasa a formar parte del conjunto de datos preparado que utiliza la analítica. Si su dashboard consume una tabla preparada, siga la publicación de esa tabla, no solo la llegada al almacenamiento. Si el posprocesamiento queda fuera del recorrido necesario para que los datos sean visibles, no lo cuente como una espera obligatoria. La dependencia real determina dónde se acumula la antigüedad.
Decidir dónde deben realizarse las transformaciones en una arquitectura Qlik y lakehouse es una cuestión de diseño distinta. Para evaluar la actualidad de los datos, la tarea inmediata es identificar qué transformaciones deben terminar antes de que un evento de negocio pueda representarse correctamente.
Un enfoque diferente aparece en la propuesta LTAP de la presentación principal de Databricks. Databricks propuso unificar el almacenamiento operativo y analítico en lugar de mantener un proceso convencional de copia de datos. La presentación describía el despliegue como algo próximo. La idea arquitectónica consiste en eliminar una etapa de transferencia. No establece un requisito de integración para Qlik ni elimina la necesidad de medir cuándo un cambio confirmado se hace visible para un usuario.
Siga un evento de negocio y compruebe después la completitud
Considere, como ejemplo, un pedido que recorre una aplicación en memoria. Utilice marcas de tiempo de relojes sincronizados y conserve el identificador estable del pedido para que cada observación se refiera al mismo evento. La traza debe contener:
source_commit_at: cuándo se confirmó la transacción operativa, no cuándo alguien introdujo originalmente el pedido.captured_at: cuándo la captura o extracción detectó el cambio confirmado.landed_at: cuándo quedó disponible en el destino de ingesta.prepared_at: cuándo la preparación necesaria publicó la representación analítica correcta.analytics_available_at: cuándo quedó disponible la instantánea de la aplicación que contenía el pedido.visible_at: cuándo el resultado mostrado al usuario incluyó realmente el pedido.
El tiempo transcurrido entre source_commit_at y visible_at mide el recorrido de este evento. Las diferencias entre marcas de tiempo consecutivas localizan las esperas y el procesamiento a lo largo del recorrido. Para Direct Query, sustituya la etapa de la instantánea por la ejecución de la consulta y el recorrido del resultado correspondientes. Observe el resultado mostrado en lugar de dar por hecho que una vista ya abierta ha cambiado.
Suponga ahora que el pedido no llega al conjunto de datos preparado que consume una recarga. La recarga puede terminar correctamente sobre ese conjunto de datos sin incluir el pedido. Una marca de tiempo de finalización reciente describe la operación de recarga; no puede demostrar que hayan llegado todos los eventos previos esperados. Que aparezca un pedido más reciente en otra parte de los datos tampoco demuestra que este pedido esté presente.
Esta es la diferencia entre datos recientes y datos completos. Siga la visibilidad de los eventos, pero también concilie los registros y estados esperados a ambos lados de la etapa que importa. Utilice registros de prueba autorizados y compare la representación de negocio resultante con el origen. Cuando el conector y el diseño del destino lo permitan, incluya registros modificados y eliminados en las comprobaciones de aceptación, no solo registros nuevos.
Interprete literalmente las etiquetas de las marcas de tiempo. La documentación de Qlik sobre la actualidad de los conjuntos de datos utiliza el último evento del origen para CDC y la última ejecución del pipeline para Reload and compare. Son puntos de referencia distintos, y ninguno debe reinterpretarse sin más como el momento hasta el cual un dashboard contiene todos los datos.
Establezca una expectativa de actualidad que resista las interrupciones
Defina la expectativa en torno a la decisión de negocio: qué eventos deben ser visibles, cuánto retraso es aceptable y qué comprobaciones de completitud deben superarse. Distinga el funcionamiento normal de la recuperación. Decida también qué deben ver los usuarios cuando no se pueda establecer la actualidad de los datos: una advertencia, un último estado conocido claramente etiquetado o una restricción para utilizar el resultado en una decisión operativa.
Una programación por sí sola no basta. Qlik Cloud documenta límites de duración de las recargas y de permanencia en la cola por concurrencia que pueden provocar fallos de recarga. Supervise la finalización real y los datos representados, en lugar de tratar la frecuencia configurada como la actualidad efectivamente entregada.
Organice la monitorización en torno a las etapas de la traza. Registre el avance de la captura, la disponibilidad en destino, la publicación de los datos preparados, la disponibilidad de la aplicación y el estado observado en pantalla mediante las interfaces disponibles en su despliegue. Asigne un responsable a cada retraso. Mantenga separado el estado operativo de un punto verificado de «datos completos hasta», entendido como el punto del origen hasta el cual se ha superado la conciliación.
Los objetivos más exigentes deben evaluarse frente al trabajo que requieren. Una extracción o unas recargas más frecuentes pueden implicar más lecturas en origen y más procesamiento. Los lotes de publicación más pequeños pueden reducir la espera y, a la vez, aumentar la sobrecarga de procesamiento. Para el acceso directo a la base de datos, evalúe la carga analítica que se impone a esa base de datos. Compare estas opciones con el mismo requisito de visibilidad y completitud, no solo con el intervalo configurado más corto.
Por último, interrumpa y reanude el recorrido en un entorno de pruebas autorizado. Compruebe si la recuperación restablece el estado de negocio esperado, cuánto tarda en ponerse al día y si el dashboard permanece claramente etiquetado mientras lleva retraso. Que un proceso vuelva a estar en marcha no significa necesariamente que se haya puesto al día.
Si su dashboard Qlik parece rápido, pero no está claro hasta qué punto está actualizado, revise el recorrido de los datos de Qlik con Digiventi. Empiece por el evento de negocio que debe ser visible y siga las etapas entre su confirmación y la pantalla.