Optimizar el rendimiento de las apps
El rendimiento de las apps se puede mejorar con un tamaño reducido de app, unos modelos de datos simplificados y la utilización estratégica del análisis de conjuntos. Esta sección le ayudará a evitar problemas de rendimiento al señalar áreas en las que el rendimiento pueda verse afectado y cómo puede evaluar y supervisar el rendimiento de la app.
Complejidad de la app
Aquí se indican diferentes categorías para el diagnóstico de problemas. Las apps más complejas tienen el rendimiento más bajo.
Apps sencillas:
- No incluyen análisis de conjuntos complejos o sentencias If().
- No incluyen tablas extensas.
- Tienen un modelo de datos simple.
- Contienen cálculos simples.
- Pueden tener grandes volúmenes de datos.
Apps moderadas:
- Tienen un modelo de datos con muchas tablas, pero se respetan las mejores prácticas.
- Utilizan análisis de conjuntos y varias sentencias If().
- Tienen tablas grandes o anchas en hojas (de 15 columnas o más).
Apps complejas:
-
Tienen un modelo de datos muy complejo.
- Conectan con grandes volúmenes de datos.
- Contienen cálculos, gráficos y tablas complejos.
Evaluar el rendimiento de la app
Puede evaluar el rendimiento de una app cuando la está desarrollando en Qlik Sense Enterprise SaaS o Qlik Sense Business. Esto examina los tiempos de respuesta y el consumo de recursos para todos los objetos públicos en la app para identificar en qué objetos enfocarse al optimizar el rendimiento. También puede comparar el rendimiento de diferentes versiones de una app para ver los resultados de la evaluación y el efecto de una optimización. Tenga presente que los resultados se ofrecen a modo de orientación y no pueden garantizar el rendimiento real percibido por el usuario en entornos de producción.
Detalles de la app
Debe considerar el entorno de hardware en relación con el tamaño de la app, ya que afecta al rendimiento de su implementación de Qlik Sense. Por ejemplo, si no optimiza sus apps, puede que estas requieran más recursos de hardware.
Supervisar el tamaño de app le ayudará a lo siguiente:
- Comprender el rendimiento actual.
- Comprender el impacto que tiene en el rendimiento implementar una nueva app.
- Comprender el impacto que tiene en el rendimiento modificar una app.
- Resolver problemas de rendimiento.
- Planificar el crecimiento futuro.
Qlik proporciona herramientas que pueden ayudarlo a evaluar sus apps. Para más información, vea: Rendimiento y escalabilidad en Qlik Sense Enterprise (solo en inglés).
Estos son los elementos básicos de una app que pueden afectar al rendimiento:
Característica | Descripción |
---|---|
Tamaño en disco de la app (MB) | Puede ver el tamaño de la app en la consola QMC. Vaya a Apps y abra el Selector de columnas a la derecha de Acciones. Haga clic en el botón de opción situado junto a Tamaño de archivo (MB). Si está usando Qlik Sense Desktop, encontrará el tamaño de app en Windows Explorer. La carpeta predeterminada es %USERPROFILE%\Documentos\Qlik\Sense\Apps. La carpeta Apps enumera todos los nombres de apps y tamaños de archivo. |
Tamaño de la app en memoria RAM (GB) |
Puede determinar la huella RAM base de una app de la siguiente manera:
Puede usar el App Metadata Analyzer para hallar esta métrica si está usando Qlik Sense June 2018 o posterior. Para más información, vea App Metadata Analyzer (solo en inglés). |
Total de filas en la app (M) |
Puede usar los campos del sistema para calcular el total de filas. Cree un KPI con la medida Sum($Rows). Para más información, vea Campos de sistema. |
Total de campos de la app | Puede usar los campos del sistema para calcular el total de campos. Cree un KPI con la medida Sum($Fields). Para más información, vea Campos de sistema. |
Total de tablas de la app | Puede usar los campos del sistema para calcular el total de tablas. Cree un KPI con la medida Count(DISTINCT $Table). Para más información, vea Campos de sistema. |
Supervisar su app
Consola de gestión de Qlik (QMC) ofrece apps para supervisar el rendimiento del sistema y el uso de Qlik Sense Enterprise on Windows:
-
La app Operations Monitor proporciona información sobre la utilización del hardware, como la memoria del servidor y el uso de CPU, los usuarios activos y la actividad de las tareas de recarga. También ofrece información resumida y detallada sobre errores, advertencias y actividades de registro en el entorno del servidor de Qlik Sense.
-
La app License Monitor realiza un seguimiento del uso de licencias y facilita la supervisión de los cambios en la asignación de licencias.
- La app Log Monitor presenta casi todos los datos de registro disponibles y permite el análisis de tendencias y la resolución de problemas.
- La app Sessions Monitor muestra datos de registro sobre el uso de apps.
- La app Reloads Monitor presenta información detallada sobre los datos de recarga, tanto de QMC como de las apps abiertas en el centro de control.
- La app Sense System Performance Analyzer muestra el rendimiento de Qlik Sense en todos los nodos.
- La app Sense Connector Logs Analyzer proporciona información sobre el uso y los errores de conectores específicos de Qlik.
- La App Metadata Analyzer proporciona una vista holística de todas sus apps de Qlik Sense, incluidos los detalles a nivel granular de un modelo de datos de apps y su utilización de recursos.
Para más información, vea Supervisar un sitio Qlik Sense Enterprise on Windows (solo en inglés).
Grandes volúmenes de datos
Puede emplear estas estrategias de arquitectura cuando conecte con grandes volúmenes de datos.
Segmentación
Puede segmentar QVDs por dimensiones, como el periodo de tiempo o la región. Por ejemplo, puede tener:
- Un QVD que contenga datos de los dos años más recientes.
- Un QVD que contenga datos históricos de más de dos años.
-
Un QVD que contenga todos los datos agregados en un nivel superior. Por ejemplo, por mes en lugar de fecha, o por país en lugar de clientes individuales.
- Un gran QVD con todos los datos, que solo lo utilice un pequeño subconjunto de usuarios.
Puede segmentar las apps de forma similar. Las apps más pequeñas abordarán las necesidades analíticas de la mayoría de los usuarios. Esto ahorra memoria.
También puede tener varias apps enfocadas en diferentes regiones. De esta manera, los usuarios no abrirán una app con datos que no les interesen o para la que no tengan derechos de acceso. Los datos a los que no se puede acceder mediante la sección de acceso afectan también a la memoria.
Generación de apps a demandaODAG
Las apps a demanda de Qlik Sense proporcionan a los usuarios vistas agregadas de almacenes de macrodatos. Pueden identificar y cargar subconjuntos relevantes de datos para un análisis detallado.
Desde la perspectiva del usuario, hay dos apps:
- Un carrito de la compra con datos agregados.
- Una app de plantilla vacía que sirve para mostrar detalles.
El usuario realiza selecciones en la app del carrito de compras. Una vez que se alcanza un determinado umbral, se crea un script de carga LOAD personalizado que llena la aplicación de plantilla con los detalles solicitados. Para más información, vea Gestionar grandes fuentes de datos big data con apps bajo demanda.
Encadenar documentos
Encadenar documentos significa que hay una app agregada, que los usuarios consumen regularmente. Si un usuario necesita más detalles, se pueden pasar las selecciones de la app agregada a una app de detalles para que pueda visualizar un nivel de granularidad menor. Esto ahorra memoria, porque el usuario no carga detalles innecesarios. El encadenamiento de documentos es compatible a través de APIs.
Rendimiento del modelo de datos
Estos son indicadores que pueden afectar al rendimiento del modelo de datos. Cada uno de ellos es una práctica recomendada que mejorará la facilidad de uso de las apps.
Acción | Descripción |
---|---|
Eliminar las claves sintéticas |
Qlik Sense crea claves sintéticas cuando dos o más tablas de datos tienen dos o más campos en común. Esto puede significar que hay un error en el script o en el modelo de datos. Para diagnosticar claves sintéticas, vea Claves sintéticas. |
Eliminar las referencias circulares del modelo de datos |
Las referencias circulares se producen cuando dos campos tienen más de una asociación. Qlik Sense tratará de resolverlas cambiando la conexión con una de las tablas. A pesar de esto, todas las advertencias de referencias circulares deben resolverse, vea Entender y resolver las referencias circulares. |
Granularidad apropiada de los datos |
Solo debe cargar los datos que sean necesarios. Por ejemplo: un grupo de usuarios solo necesita datos divididos por semana, mes y año. Puede cargar los datos agregados o agregar los datos dentro del script de carga para ahorrar memoria. Si un usuario necesita visualizar datos con un nivel de granularidad inferior, puede usar ODAG o encadenar documentos. |
Utilizar los QVDs cuando sea posible |
Un archivo QVD es un archivo que contiene una tabla de datos exportados desde Qlik Sense. Este formato de archivo está optimizado para mejorar la velocidad de lectura de datos desde un script, siendo al mismo tiempo muy compacto. Leer datos desde un archivo QVD es por lo general 10-100 veces más rápido que leer de otras fuentes de datos. Para más información, vea: Trabajar con archivos QVD. |
Archivos QVD optimizados para la carga |
Los archivos QVD se puede leer en dos modos: estándar (rápido) y optimizado (más rápido). El modo que se utilice viene determinado de forma automática por el motor de script. Hay algunas limitaciones en cuanto a las cargas optimizadas. Es posible cambiar el nombre de los campos, pero cualquiera de las operaciones siguientes dará como resultado una carga estándar:
|
Aprovechar las cargas incrementales |
Si su app conecta con una gran cantidad de datos procedentes de bases de datos que están continuamente actualizándose, cargar el conjunto de datos completo puede llevar mucho tiempo. Para evitar esto debe usar la carga incremental, a fin de recuperar registros nuevos o modificados de la base de datos. Para más información, vea Cargar registros nuevos y actualizados mediante la carga incremental. |
Modelo Snowflake consolidado |
Si tiene un modelo de datos en copo de nieve, es posible que pueda reducir la cantidad de tablas de datos uniendo algunas de ellas mediante el prefijo Join u otra forma de asignación. Esto es especialmente importante para tablas grandes de hechos. Una buena regla general es tener solo una tabla grande. Para más información, vea Unir o no unir. |
Las tablas que tienen un número pequeño de campos no están normalizadas |
Si tiene dos tablas con pocos campos, unirlas puede mejorar el rendimiento. Para más información, vea Pasos siguientes en la elaboración de scripts. |
Tablas de búsqueda (hoja) no normalizadas con cargas de correspondencias |
No debería usar el prefijo Join si solo necesita agregar un campo de una tabla a otra. Debe usar la función de búsqueda ApplyMap , vea No unir - usar ApplyMap. |
Eliminar o desasociar marcas de tiempo del campo de fecha |
Los campos de fecha pueden ocupar demasiado espacio cuando la marca de fecha-hora está presente, ya que la representación de la cadena es más larga y el número de valores distintos es mayor. Si no necesita tanta precisión en su análisis, puede redondear la marca de fecha-hora por ej. a la hora más cercana usando Timestamp(Floor(YourTimestamp, 1/24)) o eliminar directamente el componente de hora por completo usando Date (Floor(YourTimestamp)). Si desea que aparezca la hora, puede desasociarla de la fecha. Puede usar la misma función Floor() y luego crear un nuevo campo con la hora extraída usando algo parecido a: Time(Frac(YourTimestamp)). |
Eliminar campos innecesarios del modelo de datos |
Solo debería cargar los campos que sean necesarios en su modelo de datos. Evite usar Load * y SELECT. Asegúrese de mantener:
|
Evitar las tablas de enlaces cuando se trata con grandes volúmenes de datos |
Debe usar tablas de enlaces cuando sea posible. No obstante, si se trata de grandes volúmenes de datos, las tablas concatenadas pueden superar en rendimiento a las tablas de enlaces. |
Dividir las dimensiones concatenadas en nuevos campos |
Debe separar las dimensiones concatenadas en campos aparte. Esto reduce el número de instancias únicas en que aparecen los valores en sus campos. Esto es similar a cómo se pueden optimizar las marcas de tiempo. |
Utilizar los AutoNumber cuando sea posible |
Puede crear una carga optimizada cargando primero los datos desde un archivo QVD y después usando la sentencia AutoNumber para convertir los valores en claves de símbolo. Para obtener más información, vea AutoNumber. |
Evitar las islas de datos |
Las islas de datos pueden ser útiles, pero por lo general afectan al rendimiento. Si está creando islas para los valores de selección, utilice variables. |
Los QVD se almacenan basándose en plazos incrementales |
Debe almacenar los QVD en segmentos, por ejemplo, mensualmente. Estos QVD mensuales más pequeños pueden admitir muchas apps diferentes que podrían no necesitar todos los datos. |
Rendimiento de las hojas
Aquí tiene las prácticas recomendadas que mejorarán el rendimiento de las hojas y visualizaciones.
Acción | Descripción |
---|---|
La función If() se ha de evitar en la medida de lo posible |
Si la función If() se usa dentro de una función de agregación, operará a nivel de registros y será evaluada muchas veces. Por ejemplo, si tiene 1000 registros en una agregación, una condición If() se evaluará 1000 veces. Esto podría aumentar en cascada rápidamente si anida sentencias. Debería usar el análisis de conjuntos en su lugar. Se aplica un filtro de análisis de conjuntos antes de la agregación, lo que ocasiona una respuesta más rápida. Estas respuestas también se pueden almacenar en la memoria caché mediante análisis de conjuntos, donde If() no puede. También podría considerar otras funciones y modificaciones al modelo de datos. |
Los campos de diferentes tablas dentro de una tabla de agregación se evitan siempre que sea posible. |
Cuando se evalúa una agregación, el cálculo se realiza en dos pasos:
La parte de un solo subproceso puede afectar considerablemente al rendimiento. Un ejemplo es si tiene varios campos dentro de la agregación, por ejemplo, Sum(Quantity*ListPrice). Si Quantity se encuentra en la tabla de hechos y ListPrice está en la tabla maestra de productos, el primer motor debe unir las dos tablas para encontrar las combinaciones antes de poder comenzar a sumar el producto. La unión es la parte de un solo hilo y la suma es de varios hilos. Si ambos campos se encuentran en la misma tabla, no es necesaria ninguna combinación y la agregación se evalúa considerablemente más rápido. |
Las funciones Aggr() y Aggr() anidadas se deben usar lo mínimo posible. |
La función Aggr() afecta enormemente al rendimiento. El uso incorrecto puede dar resultados inexactos. Por ejemplo, en una tabla con dimensiones que se diferencian de las dimensiones dentro de la función Aggr(). Para más información, vea ¿Cuándo no debe usarse AGGR? |
Usar análisis de conjuntos en la medida de lo posible. |
Puede utilizar el análisis de conjuntos para definir un conjunto de valores de datos que sea distinto del conjunto normal definido por las selecciones actuales. Para más información, vea Análisis de conjuntos. |
Evitar las comparaciones de cadenas en la medida de lo posible |
Las comparaciones de cadenas no son tan eficientes como el análisis de conjuntos. Por ejemplo, es mejor evitar Match(), MixMatch(), WildMatch() y Pick(). Cree indicadores en el script o utilice el análisis de conjuntos en su lugar. Para más información, vea Funciones condicionales y Rendimiento de agregaciones condicionales. |
Las condiciones de cálculo se utilizan en objetos que contienen cálculos intensivos. |
Puede tener visualizaciones con muchos registros cuando no haya selecciones. Como práctica recomendada, agregue condiciones de cálculo a los objetos para que solo se procesen después de haber realizado ciertas selecciones. Esto detiene la creación de hipercubos muy grandes. Por ejemplo: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. En este escenario, la visualización no se reproducirá a menos que el usuario seleccione un solo país o haga otras selecciones donde solo sea posible un único país. |
Calcular previamente las medidas en el script siempre que sea posible |
Cualquier medida que se encuentre en el nivel más bajo de granularidad del modelo de datos debe calcularse en el script. Por ejemplo, si en el mismo registro en una tabla tiene Sales y Cost, podría obtener el margen calculando Sales - Cost AS Margin. También puede agregar otros valores por adelantado si sabe que no variarán según la selección o que están vinculados a un nivel diferente de granularidad. |
Las tablas tienen menos de 15 columnas y tienen condiciones de cálculo. |
Una tabla con 15 columnas podría considerarse amplia. Si sus tablas constan de muchos registros, debe usar condiciones calculadas en el objeto de la tabla para que solo se muestre después de cumplirse determinadas selecciones o criterios. Si su tabla se extiende mucho a lo ancho, considere lo siguiente:
|
Las hojas no deben tener una cantidad excesiva de objetos. |
Los objetos se calculan cuando el usuario navega a la hoja. Cada vez que un usuario realiza una selección en esa hoja, cada objeto se volverá a calcular si ese estado actual no existe en la memoria caché. Si tiene una hoja con muchos gráficos, el usuario tendrá que esperar a que se calcule cada objeto en casi todas las selecciones. Esto supone una carga significativa para el motor. Como práctica recomendada, siga el concepto Dashboard/Analysis/Reporting (DAR) para desarrollar una app limpia y mínima. Para más información, consulte la metodología DAR. |
Los indicadores numéricos se deben aprovechar en el script para su uso en el análisis de conjuntos |
El análisis de conjuntos con indicadores puede ser más eficiente que usar comparaciones de cadenas o multiplicación. |
Utilizar elementos maestros o variables para las expresiones |
Los elementos maestros permiten arrastrar y soltar métricas gobernadas y garantizan que las expresiones se almacenarán en la memoria caché. Por ejemplo, Sum(Sales) es diferente de SUM(Sales). Las expresiones se almacenan en la memoria caché con su ortografía y mayúsculas, y deben coincidir literalmente para ser reutilizadas. |