Cómo le ayuda Actian Vector a eliminar los cubos OLAP

Los cubos OLAPtraitement analytique en ligne) se utilizan mucho hoy en día porque muchas plataformas de bases de datos no pueden analizar grandes volúmenes de datos con rapidez. Esto se debe a que la mayoría del software de bases de datos no aprovecha al máximo la potencia de cálculo y la memoria para ofrecer un rendimiento óptimo. Algunos de los síntomas de esto son:

1. Las consultas grandes acaban acaparando los recursos del servidor.
2. La respuesta se vuelve más lenta a medida que aumenta el tamaño de los datos y el número de usuarios.
3. El soporte de consultas concurrentes se hace difícil o imposible.
4. Las tablas adicionales agregadas/materializadas, los índices y a veces incluso los data marts individuales no consiguen ofrecer el rendimiento y la simultanéité requeridos.

Los almacenes cube OLAP se crearon para resolver la necesidad de un usuario de BI de agregar, cortar y dividir rápidamente grandes cantidades de datos para un conjunto de preguntas predeterminadas. Ahora veremos cómo podemos utilizar Actian Vectornuestra base de données analytique columnar de alta velocidad, para eliminar el uso de cubos OLAP.

¿Cuáles son los inconvenientes de utilizar almacenes cube OLAP ?

1. Inversión adicional en hardware/software y costes de mantenimiento continuo.
2. Se requieren habilidades completamente nuevas en Expresiones Multidimensionales (MDX) para consultar los Cubos OLAP.
3. Impone un esquema estricto (estrella o copo de nieve), mientras que algunos de los almacenes Cube de nueva generación admiten tablas 3NF (o modelos ROLAP). Pero el mejor rendimiento se obtiene siempre con un esquema en estrella.
4. Limitan la libertad de consulta ad hoc. El diseño del cube OLAP requiere mucha reflexión. Una vez construido, sólo las filas y columnas incluidas estarán disponibles para la consulta. A menudo, se requiere un nuevo cubo para cada nueva consulta.
5. Añade una cantidad significativa de tiempo de procesamiento y crea nuevos cuellos de botella en el ciclo de vida de BI. El usuario de BI tendría que pagar mucho en tiempo perdido si el cube OLAP OLAP se construyera incorrectamente. La frescura de los datos se ve comprometida ya que los datos tienen que pasar de los sistemas operativos al almacén de datos al cube OLAP AP y luego a outils bi.

Mirando bajo el capó

Veamos a qué se renuncia con un cube OLAP. He aquí un ejemplo sencillo en el que los datos brutos de la base de datos relacional subyacente tienen el siguiente aspecto:

Si un usuario está interesado en crear un cube OLAP simple para ventas a partir de los datos anteriores y las métricas de interés agregadas sales_amounts para cada década, año, por producto y región, el cube OLAP tendría los siguientes datos en él:

Los datos se agregan por Década, Año, Nombre_región, Nombre_producto. Se pierde el detalle del nivel transaccional. Por esta razón, algunos de los almacenes cube OLAP más maduros ofrecen una función de desglose que permite al usuario ver los datos detallados. Sin embargo, el rendimiento podría degradarse si la cantidad de datos detrás de la agregación es grande.

Una consulta MDX típica para obtener estos datos del cubo tendría este aspecto en función de lo que el usuario quisiera ver en filas y columnas y puntos de datos.

CON 
MIEMBRO[medidas].[precio medio] AS 
medidas].[ventas_amt] / [medidas].[ventas_num]' 
SELECT 
{[medidas].[suma_ventas],[medidas].[precio_medio]} ON COLUMNS, 
{[producto].miembros, [año].miembros} EN FILAS 
FROM CUBO_VENTAS

El Avg_price es una medida calculada. Note que las medidas calculadas pueden ser especificadas en la definición cube OLAP del cube OLAP o pueden ser definidas en la consulta MDX. Uno de los beneficios de las medidas calculadas definidas en los cubos OLAP es que si la consulta se cambia para tener un filtro o se agrega una dimensión adicional, la medida calculada se recalcula automáticamente con los nuevos parámetros.

Y así, el cube OLAP AP acaba siendo una solución parcial a un problema: que las bases de datos relacionales orientadas a filas simplemente no son lo suficientemente rápidas para las consultas analíticas. ¿Qué pedirían los usuarios de OLAP si pudieran tener lo que quisieran? Lo que escuchamos de los usuarios son estos requisitos:

• Velocidad similar a OLAP o superior con soporte completo para consultas ad hoc
• La posibilidad de utilizar cualquier modelo de datos
• Todos sus outils bi favoritos
• Los datos más actuales disponibles
• Acceso a todos los datos detallados en la misma consulta, sin sacrificar el rendimiento.

¿Parece imposible? No lo es. Actian Vector puede ofrecer todo esto y mucho más. ¿Cómo es posible? Siga leyendo.

Sustitución de cubos OLAP por vectores 

Actian Vector se encuentra en una posición única para sustituir a los cubos OLAP. Lo hemos construido desde cero con una serie de optimizaciones para aumentar drásticamente el rendimiento de las consultas analíticas. He aquí un rápido resumen de lo que hemos construido:

• Procesamiento vectorial: La vectorización lleva la paralelización al siguiente nivel enviando una única instrucción a múltiples puntos de datos ofreciendo una respuesta casi en tiempo real.
• stockage en colonnes: Columnar reduce en gran medida la IO al cargar en memoria únicamente las columnas necesarias en una consulta, en lugar de cargar todas las columnas en memoria y, a continuación, seleccionar las columnas necesarias para satisfacer la consulta.
• Optimización in-memory: El uso avanzado de la caché del procesador y la memoria principal, y la compresión y descompresión in-memory memoria aceleran el proceso.
• Flexibilidad: Vector trabaja con cualquier modelo de datos - estrella, copo de nieve, 3NF y desnormalizado eliminando la necesidad de crear cualquier tipo de materialización de datos. Dado que el usuario de BI trabaja a partir de la fuente de datos, no se pierde la libertad de consulta.
• Riqueza funcional: Las funciones avanzadas de OLAP/Windows permiten al usuario formular una amplia gama de preguntas sofisticadas.

De los cubos al vector Actian

Para migrar informes BI desde Cubos OLAP, es importante entender las características del Cubo que necesitan ser migradas. Estas incluyen:

• cube OLAP Modelo cube OLAP - Entender el modelo de datos del cubo mismo y mapearlo de vuelta al modelo de datos RDBMS.
• Consultas MDX, medidas calculadas y filtros utilizados.
• KPI - Indicadores Clave de Rendimiento.
• Análisis de hipótesis para diferentes escenarios.

cube OLAP Modelo cube OLAP

Examine el cube OLAP e identifique en qué tipo de modelo de datos se basa: ROLAP, HOLAP o MOLAP. Los modelos ROLAP se basan en modelos de datos de tercera forma normal (3NF) en los que los datos están muy normalizados. Normalmente, hay una penalización de rendimiento cuando se utilizan modelos ROLAP en Cubos.

HOLAP es un modelo híbrido en el que se utiliza una combinación de modelos estrella o copo de nieve, desnormalizados y 3NF. Esto también tiene penalizaciones de rendimiento.

MOLAP es el modelo subyacente más deseado cuando se utiliza un modelo de datos en estrella o copo de nieve y ofrece el mejor rendimiento. Normalmente, en un ciclo de vida de BI, los datos de origen están en 3NF y deben pasar por un largo proceso de transformación para convertirse a un modelo de esquema en estrella. La penalización se paga por adelantado para obtener un mejor rendimiento más adelante.

Si se utiliza una consulta en la fuente de datos, deben examinarse los siguientes factores:

1. Dimensiones: Cómo se llega a esto en el Cubo. Especial para los modelos ROLAP y HOLAP.
2. Medidas: Medidas calculadas y normales.
3. Hechos: ¿Es una sola tabla, una combinación de tablas?

Es importante examinar los factores anteriores para comprender el modelo RDBMS subyacente y ver de dónde se pueden obtener estos elementos. Típicamente, los almacenes de datos tienen implementados modelos de estrella o de copo de nieve, pero algunos almacenes de datos tienden a tener un modelo altamente normalizado. Para el cubo anterior, un modelo típico de copo de nieve se vería como sigue:

Conversión de consultas MDX a SQL

Examine la consulta MDX e identifique los siguientes elementos del cube OLAP y de la consulta MDX. Consulte un tutorial básico de MDX si lo necesita. Esto es lo que necesitará saber:

1. Dimensiones
2. Medidas
3. Medidas calculadas
4. Porciones de datos o Filtros (Ejemplo: Si el usuario quisiera conocer las ventas sólo de "Pernos" o sólo del mes de enero).

Tomando como ejemplo la consulta MDX de la sección anterior:

CON 
MIEMBRO[medidas].[precio medio] AS 
medidas].[ventas_amt] / [medidas].[ventas_num]' 
SELECT 
{[medidas].[suma_ventas],[medidas].[precio_medio]} ON COLUMNS, 
{[producto].miembros, [año].miembros} EN FILAS 
FROM CUBO_VENTAS

Dónde:

• El precio medio es una medida calculada
• Sales_amt es una medida que se define en el cubo
• [producto].miembros es el producto Dimensión
• [Año].miembros es el año Dimensión

Ahora desea convertir las consultas MDX en consultas SQL basadas en el modelo anterior. La consulta MDX se puede reescribir en SQL como se indica a continuación:

Select año_nombre, producto_nombre, suma(ventas_amt) como ventas, avg(ventas_amt) como avg_ventas 
from Ventas FT 
join Time_Dimension TD on FT.fecha = TD.fecha 
join Dimensión_mes MD on mes(fecha_TD) = mes_MD 
join Año_Dimension YD on año(fecha) = YD.año 
join Dimensión_ciudad RD on FT.ciudad_id = RD.ciudad_id 
join Dimensión_Estado SD on FT.estado_id= RD.estado_id 
join Producto PD on FT.product_id = PD.Product_id 
group by nombre_año, nombre_producto

o, simplificar aún más la consulta eliminando las tablas de dimensiones si se introdujeron sólo para construir el Cubo:

Seleccione 
fecha_parte(año, fecha_venta) como nombre_año, nombre_producto, 
sum(ventas_amt) como ventas , 
avg(ventas_amt). como avg_ventas 
from Ventas FT 
join Producto PD on FT.product_id = PD.Product_id 
group by década,nombre_año, nombre_región, nombre_producto

Nota: No se está dando a entender que las uniones con otras tablas puedan eliminarse por completo. Sólo pueden eliminarse las tablas que se introdujeron simplemente para adherirse al estricto esquema de estrella/ copo de nieve.

Si la herramienta BI no proporciona funciones analíticas de ventana, remítase a las funciones analíticas y funciones de ventana proporcionadas por Vector para poder ejecutarlas en la base de datos.

Si el usuario desea profundizar en un conjunto específico de filas, puede eliminar la agregación y ejecutar la consulta en la base de datos. Por ejemplo, si el usuario está interesado en las cifras de ventas de enero de 1993 del producto Pernos, podría utilizar la siguiente consulta SQL:

Seleccione 
Fecha_parte(año, fecha_venta) como nombre_año, 
nombre_producto, importe_ventas como ventas 
from Ventas FT 
join Producto PD on FT.product_id = PD.Product_id 
where Nombre_producto = "Pernos 
y Fecha_parte(año, fecha_venta) = "1993" 
y Fecha_parte(mes, fecha_venta) = "Enero".

Indicadores clave de rendimiento

En la terminología empresarial, un indicador clave de rendimiento (KPI) es una medida cuantificable para calibrar el éxito empresarial.

Un objeto KPI simple se compone de: información básica, el objetivo, el valor real alcanzado, un valor de estado, un valor de tendencia y una carpeta donde se visualiza el KPI. La información básica incluye el nombre y la descripción del KPI. En un cubo de Microsoft SQL Server Analysis Services, el objetivo es una expresión MDX que se evalúa como un número. El valor real es una expresión MDX que se evalúa como un número. El estado y el valor de tendencia son expresiones MDX que se evalúan como un número. La carpeta es una ubicación sugerida para que el KPI se presente al cliente.

Aunque algunos almacenes cube OLAP proporcionan interfaces elegantes y fáciles de usar para almacenar e implementar KPI y acciones, éstas pueden implementarse fácilmente utilizando una combinación de características de bases de datos más convencionales y código de aplicación.

Análisis de hipótesis para diferentes escenarios

Algunos almacenes de cubos ofrecen funciones de análisis de suposición Y si... con interfaces fáciles de usar. Esto también puede implementarse utilizando funciones de base de datos y código de aplicación con cierto esfuerzo.

Este tipo de análisis requiere almacenar varios escenarios y analizar el impacto del estado actual del negocio frente a estos diferentes escenarios. Este tipo de análisis se utiliza habitualmente en los servicios financieros y las empresas comerciales para evaluar constantemente el riesgo y el impacto de las operaciones.

Sería necesario un análisis detallado de los requisitos, lo que queda un poco fuera del alcance de este artículo.

Resumen

Para los usuarios de OLAP que buscan simplificar el ciclo de vida de BI, la base de datos analítica Actian Vector proporciona una alternativa viable a los cubos OLAP con su tecnología innovadora, rendimiento superior y capacidades analíticas en la base de datos. La avantage de la migración es la reducción de costes y una mejor experiencia del usuario de BI gracias a la libertad de consulta.

No se conforme con mi palabra. Pruébelo usted mismo. Hemos preparado una guía y una copia de evaluación de Vector, junto con todo el material de apoyo que necesitará para probar Vector en aproximadamente una hora. Puedes hacer preguntas a nuestra activa comunidad de Vector aquí.

Acerca de Actian Corporation

Actian hace que los datos sean fáciles. Nuestra plataforma de datos simplifica el modo en que las personas conectan, gestionan y analizan los datos en entornos en la nube, híbridos y locales. Con décadas de experiencia en gestión de datos y análisis, Actian ofrece soluciones de alto rendimiento que permiten a las empresas tomar decisiones basadas en datos. Actian cuenta con el reconocimiento de los principales analistas y ha recibido premios del sector por su rendimiento e innovación. Nuestros equipos comparten casos de uso probados en conferencias (por ejemplo, Strata Data) y contribuyen a proyectos de código abierto. En el blog de Actian, cubrimos temas que van desde la ingestión de datos en tiempo real hasta el análisis impulsado por IA.