¿Sus recargas de Qlik fallan cada vez más a medida que crecen los datos?

El motor asociativo es rápido porque todo el modelo de datos vive en memoria. Por eso mismo una aplicación llena de detalle en bruto acaba quedándose sin espacio.

Por qué la aplicación no deja de crecer

• Se carga el detalle a nivel de fila, decenas de millones de filas, porque no existe ningún agregado en el origen.
• Las transformaciones se ejecutan durante la recarga. Joins, búsquedas y limpieza consumen memoria antes de que se almacene una sola fila.
• Las recargas completas son más lentas cada mes. La lógica incremental con QVD es posible, pero se escribe a mano y es frágil.
• Las recargas y los usuarios comparten la misma RAM. Una recarga pesada compite con las personas que usan las aplicaciones.

Más memoria da tiempo. No cambia la curva.

Por qué le toca a usted

• El detalle se cargó porque era la única tabla disponible, no porque alguien lo necesitara.
• La capacidad del servidor, o los límites de tamaño de aplicación de su tenant de Qlik Cloud, no dependen de usted.
• Puede quitar campos y optimizar el script. No puede crear los agregados en el origen.

El trabajo está en el lugar equivocado

• Hacer joins, agregar y cargar de forma incremental es trabajo del data warehouse. En Qlik se repite en cada recarga de cada aplicación.
• Debe hacerse en un único lugar central: un data warehouse o un data hub, construido una vez y leído por todas las aplicaciones.
• Si eso le parece caro, probablemente la estimación parte de pipelines construidos a mano. Una plataforma de automatización especializada los genera a partir de un modelo, lo que cambia tanto el coste como el tiempo necesario.

Qué cambia cuando el modelo llega terminado

Datavault Builder genera el vault y los information marts de forma nativa en la base de datos que la empresa ya tiene, como Snowflake, Databricks, Synapse, Fabric o Exasol.

• Marts agregados con la granularidad que necesita la aplicación, así que llegan muchas menos filas a la memoria.
• La carga incremental ocurre en el origen, generada en lugar de escrita a mano en un script.
• La recarga copia, no calcula. Se convierte en un simple LOAD desde tablas terminadas.
• El tamaño de la aplicación sigue a la pregunta, no al tamaño del sistema de origen.
• El detalle se queda en el warehouse, accesible cuando alguien realmente necesita profundizar en él.

Qué pedir

No “la recarga sigue fallando”, sino:

“Nuestra aplicación carga cada fila de transacciones y hace los joins durante la recarga, por eso se queda sin memoria. ¿Podemos tener un mart agregado en el warehouse, cargado de forma incremental, para que la aplicación lo lea?”

Si la respuesta es que construir bien los marts llevaría un trimestre, esa es la objeción que Datavault Builder se creó para eliminar.