Acerca de los cubos OLAP

Publicado: julio de 2016

Se aplica a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

La ilustración siguiente muestra una imagen desde SQL Server Business Intelligence Development Studio (BIDS) que representa las partes principales que son necesarias para los cubos de procesamiento analítico en línea (OLAP). Estas partes son el origen de datos, las vista de origen de los datos, los cubos y las dimensiones. En las secciones siguientes se describen las partes del cubo OLAP y las acciones que los usuarios pueden realizar con ellos.

Un origen de datos es el origen de todos los datos contenidos dentro de un cubo OLAP. Un cubo OLAP se conecta a un origen de datos para leer y procesar los datos sin procesar para llevar a cabo cálculos y agregaciones para sus medidas asociadas. El origen de datos de todos los cubos OLAP de Service Manager es el data marts, que incluye los data marts de Operations Manager y Configuration Manager. La información de autenticación sobre el origen de datos se debe almacenar en SQL Server Analysis Services (SSAS) para establecer el nivel correcto de permisos.

Vista de origen de datos

La vista de origen de datos (DSV) es una colección de vistas que representa las tablas de dimensiones, hechos y subdimensiones desde el origen de datos, como los data marts de Service Manager . La DSV contiene todas las relaciones entre tablas, tales como las claves principales y externas. En otras palabras, la DSV especifica cómo se asignará la base de datos de SSAS al esquema relacional, y proporciona una capa de abstracción sobre la base de datos relacional. Con esta capa de abstracción se pueden definir relaciones entre las tablas de hechos y dimensiones, incluso si no existen relaciones dentro de la base de datos relacional de origen. En la DSV también se pueden definir los cálculos con nombre, las medidas personalizadas y los nuevos atributos que podrían no existir de forma nativa en el esquema dimensional del almacenamiento de datos. Por ejemplo, un cálculo con nombre que defina un valor booleano para Incidents Resolved calcula el valor como verdadero si el estado de un incidente es resuelto o cerrado. Mediante el cálculo con nombre, Service Manager puede definir una medida para mostrar información útil, como el porcentaje de incidentes resueltos, el número total de incidentes resueltos y el número total de incidentes no resueltos.

Otro ejemplo rápido de un cálculo con nombre es ReleasesImplementedOnSchedule. Este cálculo con nombre proporciona una comprobación rápida del estado de mantenimiento en el número de registros de versión donde la fecha de finalización real es inferior o igual a la fecha de finalización programada.

Cubos OLAP

Un cubo OLAP es una estructura de datos que supera las limitaciones de las bases de datos relacionales y proporciona un análisis rápido de datos. Los cubos OLAP pueden mostrar y sumar grandes cantidades de datos, a la vez que proporcionan a los usuarios acceso mediante búsqueda a los puntos de datos, de modo que se puedan resumir o reorganizar según sea necesario, para procesar la variedad más amplia de preguntas pertinentes al área de interés de un usuario.

Dimensiones

Una dimensión en SSAS hace referencia a una dimensión del almacenamiento de datos de Service Manager . En System Center 2012 – Service Manager, una dimensión es prácticamente equivalente a una clase de módulo de administración. Cada clase de módulo de administración tiene una lista de propiedades, mientras que cada dimensión contiene una lista de atributos, con cada atributo asignado a una propiedad en una clase. Las dimensiones permiten el filtrado, la agrupación y el etiquetado de datos. Por ejemplo, puede filtrar los equipos por el sistema operativo instalado y agrupar a los usuarios en categorías por sexo o edad. A continuación, los datos se presentan en un formato donde se clasifican de forma natural en estas jerarquías y categorías para permitir un análisis más exhaustivo. Las dimensiones también pueden tener jerarquías naturales para permitir a los usuarios "profundizar" hasta niveles más precisos de detalle. Por ejemplo, la dimensión Fecha tiene una jerarquía de la que se pueden obtener más detalles por Año, a continuación Trimestre, a continuación, Mes, a continuación, Semana y a continuación Día.

La ilustración siguiente muestra un cubo OLAP que contiene las dimensiones Fecha, Región y Producto.

Por ejemplo, los miembros del equipo de Microsoft podrían desear un resumen rápido y sencillo de las ventas de la consola de juegos Xbox 360 en 2010. Pueden desglosarlo más para obtener cifras de ventas de un período de tiempo más específico. Es posible que los analistas de negocios deseen examinar cómo las ventas de las consolas Xbox 360 se vieron afectadas por el lanzamiento del nuevo diseño de consola y la experiencia de juego sin controlador de Kinect para Xbox 360. Esto les ayuda a determinar las tendencias de ventas que se están produciendo y qué revisiones potenciales de estrategia de negocio son necesarias. Al filtrar en la dimensión de fecha, esta información se puede distribuir y consumir rápidamente. Esta reorganización de los datos solo está habilitada porque las dimensiones se han diseñado con atributos y datos que el cliente puede filtrar y agrupar fácilmente.

En System Center 2012 – Service Manager, todos los cubos OLAP comparten un conjunto común de dimensiones. Todas las dimensiones utilizan el data mart principal del almacenamiento de datos como su origen, incluso en escenarios de varios data mart. En escenarios de varios data mart, es posible que esto pueda conducir a errores de claves de dimensión durante el procesamiento del cubo.

Grupo de medida

Un grupo de medida es el mismo concepto que un hecho en la terminología de almacenamiento de datos. Del mismo modo que los hechos contienen medidas numéricas en un almacenamiento de datos, un grupo de medida contiene medidas para un cubo OLAP. Todas las medidas de un cubo OLAP que se derivan de una sola tabla de hechos en una vista de origen de datos también se pueden considerar un grupo de medida. Sin embargo, en algunos casos, puede haber varias tablas de hechos de las que derivan las medidas de un cubo OLAP. Las medidas del mismo nivel de detalle se unen en un grupo de medida. Los grupos de medida definen qué datos se cargarán en el sistema, cómo se cargarán los datos y cómo se enlazarán los datos al cubo multidimensional.

Cada grupo de medida también contiene una lista de particiones, que contiene los datos reales en secciones independientes y no superpuestas. Los grupos de medida también contienen diseño de agregación, que define los conjuntos de datos previamente resumidos que se calculan para que cada grupo de medida mejore el rendimiento de las consultas de usuario.

Medidas

Las medidas son los valores numéricos que los usuarios desean reorganizar, agregar y analizar; son uno de los motivos fundamentales por los que desearía crear cubos OPAL mediante la infraestructura de almacenamiento de datos. Mediante el uso de SSAS, puede crear cubos OLAP que aplicarán reglas de negocio y cálculos para aplicar formato a las medidas y mostrarlas en un formato personalizable. Gran parte del tiempo empleado en el desarrollo de un cubo OLAP sirve para la determinación y la definición de las medidas que se mostrarán y de cómo se deben calcular.

Las medidas son valores que normalmente se asignan a columnas numéricas en una tabla de hechos del almacenamiento de datos, pero también se pueden crear en atributos de dimensión y de dimensión degenerada. Estas medidas son los valores más importantes de un cubo OLAP que se analizan y el interés principal de los usuarios finales que exploran el cubo OLAP. Un ejemplo de una medida que existe en el almacenamiento de datos es ActivityTotalTimeMeasure. ActivityTotalTimeMeasure es una medida de ActivityStatusDurationFact que representa el tiempo en que cada actividad se encuentra en un estado concreto. El nivel de detalle de una medida está formado por todas las dimensiones a las que se hace referencia. Por ejemplo, el nivel de detalle del hecho de relación ComputerHostsOperatingSystem consta de las dimensiones del equipo y del sistema operativo.

Las funciones de agregación se calculan en medidas para habilitar el análisis más profundo de los datos. La función de agregación más común es Suma. Una consulta común de cubo OLAP, por ejemplo, resume el tiempo total para todas las actividades In Progress. Otras funciones comunes de agregación son Mín, Máx y Cuenta.

Una vez procesados los datos sin procesar en un cubo OLAP, los usuarios pueden realizar cálculos y consultas más complejos mediante expresiones multidimensionales (MDX) para definir sus expresiones de medida o miembros calculados propios. MDX es el estándar de la industria para consultar y obtener acceso a datos almacenados en sistemas OLAP. SQL Server no se diseñó para funcionar con el modelo de datos compatible con bases de datos multidimensionales.

Obtención de detalle

Cuando un usuario profundiza en los datos en un cubo OLAP para obtener detalles, está analizando los datos a otro nivel de resumen. El nivel de detalle de los datos cambia en función de la obtención de detalle aplicada por el usuario para examinar los datos a distintos niveles en la jerarquía. A medida que el usuario aumenta el nivel de obtención de detalle, pasa de la información de resumen a los datos con un enfoque más reducido. Los siguientes son ejemplos de obtención de detalles:

• Obtención de detalles de la información demográfica sobre la población de EE.UU. y, a continuación, del Estado de Washington y, a continuación, del área metropolitana de Seattle y, a continuación, de la ciudad de Redmond y, finalmente, de la población de Microsoft.

• Obtención de detalles de las cifras de ventas de las consolas Xbox 360 en 2011 y, a continuación, en el cuarto trimestre del año y, a continuación, en el mes de diciembre y, a continuación, en la semana previa a Navidad y, finalmente, en Nochebuena.

Perforación

Cuando los usuarios "perforan" los datos desean ver todas las transacciones individuales que han contribuido a los datos agregados del cubo OLAP. En otras palabras, el usuario puede recuperar los datos con un nivel de detalle menor para un valor de medida determinado. Por ejemplo, si tiene los datos de ventas de un mes y una categoría de producto concretos, puede perforar dichos datos para ver una lista de cada fila de la tabla contenida dentro de esa celda de datos.

Es fácil confundir los términos "obtención de datos" y "perforación". La diferencia principal entre ellos es que una obtención de datos funciona en una jerarquía predefinida de datos: por ejemplo, EE.UU y, a continuación, Washington y, a continuación, Seattle, dentro del cubo OLAP. Una perforación va directamente al nivel más pequeño de detalle de datos y recupera un conjunto de filas del origen de datos que se ha agregado en una sola celda.

Indicador clave de rendimiento

Las organizaciones pueden utilizar indicadores clave de rendimiento (KPI) para evaluar el estado de su empresa y su rendimiento mediante la medición de su progreso hacia sus objetivos. Los KPI son métricas empresariales que se pueden definir para supervisar el progreso hacia ciertos objetivos y metas predefinidos. Normalmente, un KPI tiene un valor de destino y un valor real, que representa un objetivo cuantitativo que es fundamental para el éxito de la organización. Los KPI se suelen mostrar en grupos en un cuadro de mandos para mostrar el estado general del negocio en una instantánea rápida.

Un ejemplo de KPI es completar todas las solicitudes de cambio en un plazo de 48 horas. Un KPI se puede utilizar para medir el porcentaje de solicitudes de cambio que se resuelven en ese intervalo de tiempo. Puede crear paneles para representar visualmente los KPI. Por ejemplo, es posible que desee definir un valor de destino de KPI para la realización de todas las solicitudes de cambio en un plazo de 48 horas al 75 por ciento.

Particiones

Una partición es una estructura de datos que contiene algunos o todos los datos en un grupo de medida. Cada grupo de medida se divide en particiones. Una partición define un subconjunto de datos de hechos que se cargan en el grupo de medida. SSAS Standard Edition solo permite una partición por grupo de medida, mientras que SSAS Enterprise Edition permite un grupo de medida con varias particiones. Las particiones son una característica transparente para el usuario final, pero tienen una repercusión importante en el rendimiento y en la escalabilidad de los cubos OLAP. Todas las particiones de un grupo de medida siempre se encuentran en la misma base de datos física.

Las particiones permiten a los administradores administrar mejor los cubos OLAP y mejorar el rendimiento de los cubos OLAP. Por ejemplo, puede quitar o volver a procesar los datos de una partición de un grupo de medida sin que ello afecte al resto del grupo de medida. Cuando se cargan datos nuevos en una tabla de hechos, solo resultan afectadas las particiones que deben contener dichos datos.

La creación de particiones mejora el procesamiento y el rendimiento de las consultas en los cubos OLAP. SSAS puede procesar varias particiones en paralelo, lo que conduce a un uso mucho más eficiente de los recursos de la CPU y de la memoria en el servidor. Mientras se ejecuta una consulta, SSAS también captura, procesa y agrega datos de varias particiones. Solo se analizan las particiones que contienen los datos relevantes para una consulta, lo que reduce la cantidad total de entrada y salida.

Un ejemplo de estrategia de creación de particiones es colocar los datos de hechos de cada mes en una partición mensual. Al final de cada mes, todos los datos nuevos entran en una partición nueva, lo que conduce a una distribución natural de los datos con valores no superpuestos.

Agregaciones

Las agregaciones de un cubo OLAP son conjuntos de datos con resúmenes previos. Son análogos a una instrucción SELECT de SQL con una cláusula GROUP BY. SSAS puede usar estas agrupaciones cuando responde a las consultas para reducir la cantidad de cálculos necesarios, con lo que las respuestas llegan rápidamente al usuario. Las agregaciones integradas del cubo OLAP reducen la cantidad de agregación que SSAS tiene que realizar en el momento de la consulta. La creación de las agregaciones correctas puede mejorar significativamente el rendimiento de las consultas. A menudo este proceso está en constante evolución durante toda la duración del cubo OLAP, ya que sus consultas y so cambian.

Normalmente se crea un conjunto básico de agregaciones que serán útiles para la mayoría de las consultas del cubo OLAP. Las agregaciones se crean para cada partición de un cubo OLAP dentro de un grupo de medida. Cuando se crea una agregación, se incluyen algunos atributos de las dimensiones en el conjunto de datos con resumen previo. Los usuarios pueden realizar consultas rápidamente basándose en estas agrupaciones cuando examinan el cubo OLAP. Las agregaciones deben diseñarse con cuidado, ya que el número de posibles agregaciones es tan grande que la creación de todas ellas necesitaría una cantidad de tiempo y un espacio de almacenamiento no adecuados.

Service Manager usa las dos opciones siguientes cuando crea y diseña agregaciones en los cubos OLAP de Service Manager :

• Ganancia de rendimiento

• Optimización basada en el uso

La opción Ganancia de rendimiento define el porcentaje de agregaciones que se ha creado. Por ejemplo, si en esta opción se selecciona en el valor predeterminado y recomendado del 30 por ciento significa que las agregaciones se generarán para dar el cubo OLAP una ganancia de rendimiento del 30 por ciento. Sin embargo, esto no significa que se vaya a generar un 30 por ciento de las agregaciones posibles.

La optimización basada en el uso permite que SSAS registre las solicitudes de datos para que cuando se ejecute una consulta, la información se introduce en el proceso de diseño de agregación. A continuación, SSAS revisa los datos y recomienda las agregaciones que se deben generar para dar la máxima ganancia de rendimiento.

Personalización del almacenamiento de datos