Motor de almacenamiento: su función en la optimización de consultas DAX en LuckyTemplates

En este tutorial, vamos a echar un vistazo al segundo motor dentro de los servicios de análisis: el motor de almacenamiento.

Hablamos del motor de nivel superior, el motor de fórmulas , en un tutorial anterior. Cuando los usuarios entienden cómo funcionan estos dos motores, es más fácil optimizar y mejorar el rendimiento de sus consultas DAX.

El objetivo principal del motor de almacenamiento es trabajar directamente con la base de datos.

El motor de fórmulas no tiene acceso directo a la base de datos, por lo que normalmente pasa por el motor de almacenamiento para este fin.

El motor de almacenamiento viene en dos tipos: modo de importación y DirectQuery . Puede mezclar y combinar ambos tipos en el mismo modelo de datos para crear un modelo compuesto.

Tabla de contenido

• Trabajar con el modo de importación en el motor de almacenamiento
• Trabajar con DirectQuery en el motor de almacenamiento
• Trabajar con modelos compuestos
• Otros puntos críticos sobre el motor de almacenamiento
• Trabajar en consultas complicadas
• Conclusión

Trabajar con el modo de importación en el motor de almacenamiento

Primero, hablemos del modo de importación. Esto también se conoce más comúnmente como Vertipaq, pero también se llama xVelocity o In Memory Columnar Database.

Hay cuatro aspectos críticos que debe comprender acerca de cómo funciona el modo de importación.

Primero, Vertipaq crea una copia de los datos directamente desde la fuente de datos y la almacena en la memoria RAM en formato comprimido .

En segundo lugar, los datos procesados ​​en el modo de importación se basan en la última operación de actualización . Esto significa que si actualizó sus datos por última vez la semana pasada, entonces los datos con los que está tratando siguen siendo los mismos datos de la semana pasada. Esto es especialmente importante si usa una configuración compuesta donde una tabla está en el modo de importación y la otra tabla está en el modo DirectQuery.

Supongamos que tiene la tabla Productos, que se actualizó la semana pasada, en el modo de importación. En cuanto a la tabla Ventas, decidió pasarla a través de DirectQuery debido a su tamaño. Supongamos también que está creando su informe basado en ambas tablas donde está incorporando la columna Marca y está creando una medida de Ventas totales sobre la misma tabla de Ventas. También desea visualizar el monto de las ventas en función de la marca.

Primero tendría que actualizar los datos provenientes del modo de importación porque podría terminar con datos nuevos y actualizados de DirectQuery y datos obsoletos de Vertipaq. Esto dejará algunas filas en blanco en su matriz y su visualización.

Lo siguiente que debe saber sobre Vertipaq es que solo las operaciones básicas como , , , o están disponibles de forma nativa . Esto significa que si hay otras operaciones más complicadas incluidas en el plan de consulta, el motor de almacenamiento tendría que llamar al motor de fórmulas para resolver esta parte del código.

Finalmente, el motor de almacenamiento es una base de datos altamente optimizada debido a la estructura en columnas de Vertipaq . Esto significa que todos los datos se almacenan columna por columna y no fila por fila. Debido a esta estructura, Vertipaq siempre será más rápido que una conexión DirectQuery incluso si crea índices en su modelo de datos relacionales.

Trabajar con DirectQuery en el motor de almacenamiento

La siguiente opción que tenemos dentro de los servicios de análisis de LuckyTemplates es DirectQuery. Si usa la conexión DirectQuery, los servicios de análisis solo actúan como un paso para las consultas que envía el motor de fórmulas.

Entonces, digamos que escribes una consulta. El motor de fórmulas generará un plan de consulta. Luego reenviará la consulta al motor de almacenamiento, ya traducida al idioma nativo de la base de datos. La mayoría de las veces, estas consultas vienen en SQL.

Si la consulta usa DirectQuery, espere que esté actualizada todo el tiempo. No hay necesidad de preocuparse por la última vez que actualizó los datos.

El proceso de optimización del código DAX y el modelo de datos también dependerá de cómo se haya creado la base de datos relacional. Si tiene índices en sus columnas, sus consultas siempre estarán optimizadas. Pero si su base de datos no está optimizada en términos de creación de informes utilizando servicios de análisis o LuckyTemplates, entonces podría enfrentar algunos desafíos de rendimiento. Así que sea intencional al crear sus bases de datos para el desarrollo de informes.

Trabajar con modelos compuestos

La tercera opción es crear un modelo compuesto para que pueda tener una tabla en modo de importación y otra tabla en DirectQuery.

Cuando usa dos tablas de fuentes diferentes, el motor de fórmulas enviará una solicitud a Vertipaq y otra solicitud a la fuente de datos de DirectQuery. En ambos casos, los servicios de análisis también recuperarán la caché de datos tanto de Vertipaq como de DirectQuery. El motor de fórmulas utilizará JOIN, o cualquier iteración en ambas cachés de datos antes de proporcionar los resultados al usuario final.

Entonces, supongamos que está tratando de visualizar el monto de las ventas por marca del producto en su informe. El motor de fórmulas enviará una solicitud a Vertipaq, donde recuperará el producto, la marca y la clave del producto. Luego, desde DirectQuery, intentará recuperar las ventas, el precio neto, la cantidad de ventas y la clave de producto de ventas.

Una vez que tenga los dos cachés de datos basados ​​en la clave del producto, unirá los dos cachés de datos y calculará el monto total de las ventas. Luego presentará los resultados al usuario final.

Otros puntos críticos sobre el motor de almacenamiento

Ahora que hemos cubierto sus diferentes tipos, hay algunos otros factores críticos que debe conocer sobre el motor de almacenamiento para ayudarlo a optimizar sus consultas DAX.

Como mencioné anteriormente, el motor de almacenamiento proporciona la memoria caché de datos al motor de fórmulas en forma de una memoria caché de datos sin comprimir. Cuando está en modo de importación, la solicitud que se envía de vuelta a Vertipaq en el proceso se ejecuta en un lenguaje xmSQL.

El lenguaje xmSQL es algo similar a SQL pero no es completamente igual. Hablaremos de xmSWL en detalle cuando hablemos de planes de consulta en otro tutorial.

También es importante recordar que el motor de almacenamiento usa todos los núcleos disponibles en su CPU. La capacidad de usar múltiples núcleos es beneficiosa en caso de que tenga múltiples segmentos dentro de su modelo de datos.

Supongamos que tiene una tabla en LuckyTemplates con 12 millones de filas. Luego, esta tabla se dividirá en 12 segmentos porque, tanto en Power Pivot como en LuckyTemplates, cada segmento se ajusta a 1 millón de filas. Esto es diferente a los servicios de análisis en general, donde un segmento acomoda 8 millones de filas.

Entonces, si tengo seis núcleos en mi CPU, los seis núcleos escanearán los primeros seis de los 12 segmentos al mismo tiempo. Una vez que hayan terminado, pasarán a los siguientes seis segmentos.

Pero si estoy trabajando con servicios de análisis en los que el segmento predeterminado contiene 8 millones de filas, solo se usarán dos de mis seis núcleos: un segmento procesará 8 millones de filas mientras que el otro procesará 4 millones.

Trabajar en consultas complicadas

Anteriormente, mencioné que el modo de importación solo admite operaciones básicas como MIN, MAX, SUM, COUNT y GROUPBY. Entonces, ¿qué sucede si trabaja en consultas más complicadas?

Supongamos que decide usar una instrucción IF en el contexto de la fila o una iteración anidada como SUMX sobre las tablas Productos y Ventas.

En este caso, el motor de almacenamiento no podrá resolver la consulta por sí solo. Luego llamará al motor de fórmulas, que comenzará a resolver el complejo cálculo fila por fila dentro del motor de almacenamiento. Algunos pueden pensar que este es un escenario favorable, con ambos motores trabajando juntos, pero esto está lejos de la verdad.

Verá, cuando esto sucede, el caché de datos producido por el motor de almacenamiento no se puede almacenar en caché en caso de que haya un ID de datos de devolución de llamada en esa consulta en particular. Por lo tanto, si actualiza el objeto visual, el motor de fórmulas y el motor de almacenamiento deberán realizar el mismo cálculo, aunque haya ejecutado la misma consulta hace unos segundos. Esto provocará retrasos en el rendimiento y una mala experiencia del usuario.

Tenga en cuenta también que el motor de almacenamiento no sabe si las consultas se ejecutaron mediante DAX o MDX. Como mencionamos anteriormente, el trabajo del motor de fórmulas es convertir las consultas al idioma correcto antes de pasar el plan de consulta.

Por último, el motor de fórmulas envía consultas al motor de almacenamiento una por una. Esto significa que tener múltiples segmentos realmente es mejor para que el tiempo total de escaneo dentro de Vertipaq se pueda reducir, con múltiples segmentos siendo escaneados al mismo tiempo.

DAX para LuckyTemplates: Optimización mediante motores de fórmulas en DAX Studio Lecciones
y técnicas de optimización de consultas de DAX
Rendimiento de consultas y configuración de DAX Studio

Conclusión

Comprender los entresijos del motor de almacenamiento realmente ayuda a optimizar sus consultas DAX, especialmente si está utilizando DAX Studio. Si también ha seguido el tutorial que explica el motor de fórmulas, puede tomar mejores decisiones sobre cómo crear consultas de mejor rendimiento.

Aunque el motor de fórmula sirve como el motor de nivel superior, no hay duda de que no puede funcionar tan bien como puede si no maximizamos ambos motores.

Mis mejores deseos,