Introducción a los cubos OLAP de Service Manager para el análisis avanzado

En Service Manager, los datos que aparecen en el almacenamiento de datos se pueden consolidar desde varios orígenes. Se muestra mediante Service Manager con cubos de datos predefinidos y personalizados de Procesamiento analítico en línea (OLAP) de Microsoft. En resumen, los análisis avanzados de Service Manager constan de la publicación, visualización y manipulación de datos de cubo, normalmente en Microsoft Excel o en Microsoft SharePoint. Excel se usa principalmente para ver y manipular datos. SharePoint se usa principalmente como medio de publicar y compartir datos de cubo.

Service Manager incluye un almacenamiento de datos para todo el System Center. Por lo tanto, los datos de Operations Manager, Configuration Manager y Service Manager se pueden consolidar en el almacenamiento de datos, donde puedes usar fácilmente varias vistas de datos para obtener cualquier información que desees. También es una interfaz en la que puedes añadir datos en el mismo almacenamiento de datos desde sus propios orígenes personalizados, como aplicaciones SAP o una aplicación de recursos humanos de terceros. Esta consolidación crea un modelo de datos común y permite que los análisis enriquecidos te puedan ayudar a crear un almacenamiento de datos en toda la organización de tecnologías de la información (TI) con los que puedas cubrir todas las necesidades de inteligencia empresarial e informes.

Tener los datos en un modelo común te permite manipular información y tener definiciones comunes y una taxonomía común para toda la empresa. Puedes hacerlo mediante cubos de datos OLAP y acceder a la información de los cubos mediante herramientas estándar como Excel y SharePoint. Esto permite a los usuarios utilizar herramientas que ya conocen. Podrás controlar la definición de la lógica de negocio de forma centralizada. Por ejemplo, podrás definir indicadores clave de rendimiento, como los umbrales de tiempo de resolución de incidentes y qué valores corresponden a los umbrales verde, amarillo o rojo. Puedes controlar estas opciones de manera centralizada y permitir a los usuarios manipular fácilmente los datos, aunque la definición común aparecerá en los informes de Excel o en los paneles de SharePoint.

Información sobre los cubos OLAP de Service Manager

Los cubos de procesamiento analítico en línea (OLAP) son una característica de Service Manager que usa la infraestructura de almacenamiento de datos existente para proporcionar funcionalidades de inteligencia empresarial con características de autoservicio a los usuarios finales.

Un cubo OLAP es una estructura de datos que supera las limitaciones de las bases de datos relacionales al proporcionar un análisis rápido de los datos. Los cubos pueden mostrar y sumar grandes cantidades de datos, al mismo tiempo que permite a los usuarios la búsqueda de cualquier punto de datos. De este modo, los datos se pueden consolidar, segmentar y analizar según sea necesario para gestionar la mayor variedad de preguntas relevantes para el área de interés de un usuario.

Los proveedores de software o los desarrolladores de tecnología de la información (TI) con un conocimiento práctico de los cubos OLAP pueden crear módulos de administración para definir sus propios cubos OLAP extensibles y personalizables que se basan en la infraestructura de almacenamiento de datos. Estos cubos se almacenan en SQL Server Analysis Services (SSAS). Herramientas de inteligencia empresarial con características de autoservicio, como Excel o SQL Server Reporting Services (SSRS), pueden hacer uso de estos cubos en SSAS y usarlos para analizar los datos desde varias perspectivas.

Las bases de datos que utiliza una empresa para almacenar todas sus transacciones y registros se llaman bases de datos de procesamiento de transacciones en línea (OLTP). Estas bases de datos suelen tener registros que se escriben de uno en uno y que contienen una gran cantidad de información que pueden usar los estrategas para tomar decisiones fundamentadas sobre su negocio. Sin embargo, las bases que se utilizan para el almacenamiento de datos no se diseñaron para el análisis. Por lo tanto, obtener respuestas de estas bases de datos es costoso en términos de tiempo y esfuerzo. Las bases de datos OLAP son bases de datos especializadas diseñadas para ayudar a extraer la información de inteligencia empresarial de los datos.

Los cubos OLAP se pueden considerar como la última pieza del rompecabezas para una solución de almacenamiento de datos. Un cubo OLAP, también conocido como cubo multidimensional o hipercubo, es una estructura de datos en SQL Server Analysis Services (SSAS) que se compila, mediante bases de datos OLAP, con el fin de realizar análisis casi instantáneos de datos. La topología de este sistema se muestra en la siguiente ilustración.

Una característica útil de un cubo OLAP es que los datos del cubo se pueden comprender en un formulario agregado. Para el usuario, el cubo parece tener las respuestas de antemano, ya que las selecciones de valores ya están precalculadas. Sin tener que consultar la base de datos OLAP de origen, el cubo puede devolver respuestas para una amplia gama de preguntas casi instantáneamente.

El objetivo principal de los cubos OLAP de Service Manager es proporcionar a los proveedores de software o a los desarrolladores de tecnología de la información (TI) la capacidad de realizar análisis casi instantáneos de datos para análisis históricos y de tendencias. Service Manager hace esto mediante:

• Definir cubos OLAP en módulos de administración que se crearán automáticamente en SSAS cuando se implemente el módulo de administración.
• Mantener automáticamente el cubo sin intervención del usuario, incluyendo tareas como procesamiento, creación de particiones, traducciones y localización, y cambios de esquema.
• Permitir que los usuarios usen herramientas de inteligencia empresarial con características de autoservicio, como Excel, para analizar los datos desde varias perspectivas.
• Guardar informes generados en Excel para futuras referencias.

Para ver cómo se representan los cubos de almacenamiento de datos en la consola de Service Manager, dirígete al área de trabajo Almacenamiento de datos y selecciona Cubos.

Cubos OLAP de Service Manager

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

Origen de datos

Un origen de datos es el origen de todos los datos contenidos en un cubo OLAP. Un cubo OLAP se conecta a un origen de datos para leer y tratar los datos sin procesar para realizar agregaciones y cálculos para sus medidas asociadas. El origen de datos de todos los cubos OLAP de Service Manager son los almacenes de datos, que incluyen los almacenes de datos para tanto Operations Manager como Configuration Manager. La información de autenticación sobre el origen de datos debe almacenarse en SQL Server Analysis Services (SSAS) para establecer el nivel correcto de permisos.

Vista del origen de datos

La vista del origen de datos (DSV) es una colección de vistas que representan las tablas de dimensiones, hechos y subdimensiones del origen de datos, como las data marts de Service Manager. La DSV contiene todas las relaciones entre las tablas, como las claves principales y externas. En otras palabras, el DSV especifica de qué manera la base de datos SSAS se asignará al esquema relacional y proporciona una capa de abstracción sobre la base de datos relacional. Con esta capa de abstracción, las relaciones se pueden definir entre tablas de hechos y dimensiones, incluso si no existen relaciones dentro de la base de datos relacional de origen. Los cálculos con nombre, las medidas personalizadas y los nuevos atributos también se pueden definir en el DSV, los cuales pueden no existir de forma nativa en el esquema dimensional del almacén de datos. Por ejemplo, un cálculo con nombre que define un valor booleano para Incidentes resueltos calcula el valor como true si el estado de un incidente se resuelve o se cierra. Gracias al uso del 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 nombrado proporciona una comprobación rápida del estado de salud en el número de registros de versión en los que la fecha de finalización real es anterior o coincide con 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 al proporcionar un análisis rápido de los datos. Los cubos OLAP pueden mostrar y sumar grandes cantidades de datos, al mismo tiempo que proporcionan a los usuarios acceso con función de búsqueda a cualquier punto de datos, de manera que los datos se puedan resumir, segmentar y desglosar según sea necesario para controlar la mayor variedad de preguntas pertinentes en función del área de interés de un usuario.

Dimensiones

Una dimensión de SSAS hace referencia a una dimensión del almacenamiento de datos de Service Manager. En Service Manager, una dimensión es aproximadamente equivalente a una clase del módulo de administración. Cada clase del módulo de administración tiene una lista de propiedades, mientras que cada dimensión contiene una lista de atributos, con cada asignación de atributos a una propiedad de una clase. Las dimensiones permiten filtrar, agrupar y etiquetar los datos. Por ejemplo, puedes filtrar los equipos en función del sistema operativo instalado y agrupar las personas en categorías por sexo o edad. Entonces los datos se pueden presentar en un formato en el que se clasifiquen de forma natural en estas jerarquías y categorías para permitir un análisis más detallado. Las dimensiones también pueden tener jerarquías naturales para permitir a los usuarios "explorar en profundidad" a niveles más pormenorizados de información. Por ejemplo, la dimensión Fecha tiene una jerarquía que se puede desglosar por Año, luego Trimestre, mes, semana y día.

En la ilustración siguiente, se muestra un cubo OLAP que contiene las dimensiones Date, Region y Product.

Por ejemplo, los miembros del equipo de Microsoft podrían querer un resumen rápido y sencillo de las ventas de la consola de juegos de Xbox One de una versión en particular. Pueden profundizar aún más para obtener las cifras de ventas de un período de tiempo más específico. Es posible que los analistas de negocios quieran examinar cómo las ventas de las consolas Xbox One se vieron afectadas por el lanzamiento del nuevo diseño de la consola y de Kinect para Xbox One. Esto les ayuda a determinar qué tendencias de ventas se están produciendo y qué posibles revisiones de la estrategia empresarial son necesarias. Al filtrar en función de la dimensión de fecha, esta información se puede entregar y consumir rápidamente. Esta segmentación y desglose de los datos está habilitada únicamente porque las dimensiones se han diseñado con atributos con miras a que los clientes puedan filtrar y agrupar fácilmente los datos.

En Service Manager, todos los cubos OLAP comparten un conjunto común de dimensiones. Todas las dimensiones utilizan el datamart del almacén de datos principal como fuente, incluso en escenarios de múltiples datamarts. En varios escenarios de data mart, esto puede provocar errores clave en las dimensiones durante el procesamiento del cubo.

Grupo de medida

Grupo de medida es un concepto equivalente a hecho en la terminología del almacenamiento de datos. Al igual que los hechos contienen medidas numéricas en un almacén de datos, un grupo de medidas contiene medidas para un cubo OLAP. Todas las medidas de un cubo OLAP que se derivan de una tabla de hechos única en una vista del origen de datos también se pueden considerar un grupo de medida. Sin embargo, puede haber instancias en las que habrá varias tablas de hechos a partir de las cuales se derivan las medidas de un cubo OLAP. Las medidas de un mismo nivel de detalle se reúnen en un grupo de medida. Los grupos de medida definen qué datos se cargan en el sistema (y cómo se cargan), así como la manera en que se enlazan al cubo multidimensional.

Cada grupo de medida también contiene una lista de particiones, las cuales contienen los datos reales en secciones independientes que no se superponen. Los grupos de medida también contienen un diseño de agregaciones, el cual define los conjuntos de datos prerresumidos que se calculan para cada grupo de medida para mejorar el rendimiento de las consultas de los usuario.

Medidas

Las medidas son los valores numéricos que los usuarios desean segmentar, desglosar, agregar y analizar. Además, constituyen una de las razones fundamentales por las podría interesarte crear cubos OLAP mediante la infraestructura de almacenamiento de datos. SSAS posibilita la compilación de cubos OLAP que aplicarán reglas de negocio y cálculos para dar formato y mostrar las medidas en un formato personalizable. Gran parte del tiempo de desarrollo del cubo OLAP se dedicará a determinar y definir qué medidas se mostrarán y cómo se calcularán.

Las medidas son valores que normalmente se asignan a columnas numéricas en una tabla de hechos de un almacén de datos, pero también se pueden crear en atributos de dimensión y dimensiones degeneradas. Estas medidas son los valores más importantes de un cubo OLAP que se analizan y el interés principal para los usuarios finales que examinan 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 que cada actividad está en un estado determinado. El nivel de detalle de una medida se compone de todas las dimensiones a las que se hace referencia. Por ejemplo, el nivel de detalle del dato relacional ComputerHostsOperatingSystem consta de las dimensiones Equipo y Sistema operativo.

Las funciones de agregación se calculan en medidas para habilitar análisis de datos adicionales. La función de agregación más común es Sum. Una consulta de cubo OLAP común, por ejemplo, es la suma del tiempo total de todas las actividades que están en curso. Otras funciones de agregación comunes incluyen Min, Max y Count.

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 propias expresiones de medida o miembros calculados. MDX es el estándar del sector para consultar y acceder a datos almacenados en sistemas OLAP. SQL Server no se diseñó para trabajar con el modelo de datos que admiten las bases de datos multidimensionales.

Explorar en profundidad

Cuando un usuario explora en profundidad los datos de un cubo OLAP, el usuario está analizando los datos en un nivel diferente de resumen. El nivel de detalle de los datos cambia a medida que el usuario explora en profundidad los datos en distintos niveles de la jerarquía. A medida que los usuarios exploran en profundidad, pasan de la información de resumen a los datos con un enfoque más preciso. A continuación se muestran ejemplos de exploración en profundidad:

• Profundizar en los datos para examinar información demográfica sobre la población en Estados Unidos, luego en el estado de Washington, luego en el área metropolitana de Seattle, luego en la ciudad de Redmond y finalmente sobre la población en Microsoft.
• Profundizar en las cifras de ventas de las consolas Xbox One para el año natural de 2015, luego el cuarto trimestre del año, luego el mes de diciembre, luego la semana antes de Navidad, y finalmente Nochebuena.

Ir al detalle

Cuando los usuarios realizan perforaciones en los datos, quieren ver todas las transacciones individuales que han contribuido a los datos agregados del cubo OLAP. Es decir, el usuario puede recuperar los datos en el nivel más bajo de detalle para un determinado valor de medida. Por ejemplo, cuando recibes los datos de ventas de un mes determinado y una categoría de producto, puedes explorar esos datos para ver una lista de cada fila de la tabla contenida en esa celda de datos.

Es habitual confundir los términos explorar en profundidad y obtener detalles entre sí. La principal diferencia entre ellos es que una exploración en profundidad opera sobre una jerarquía predefinida de datos dentro del cubo OLAP; por ejemplo, primero EE. UU., luego Washington y, después, Seattle. Una consulta detallada va directamente al nivel más bajo de detalle de los datos y extrae un conjunto de filas del origen de datos que se ha resumido en una única celda.

indicador clave de rendimiento

Las organizaciones pueden usar indicadores clave de rendimiento (KPI) para medir 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 determinados objetivos y metas predefinidas. Un KPI tiene un valor objetivo y un valor real, que representa un objetivo cuantitativo que es primordial para el éxito de la organización. Los KPI se muestran en grupos en un registro de resultados, con el fin de tener una vista general del estado de la empresa en un vistazo.

Un ejemplo de KPI es completar todas las solicitudes de cambio en un plazo de 48 horas. Un KPI se puede usar para medir el porcentaje de solicitudes de cambio que se resuelven dentro de ese período de tiempo. Se pueden crear registros de resultados donde se muestran los KPI visualmente. Por ejemplo, se puede definir un valor de objetivo de KPI que sea completar todas las solicitudes de cambio en un plazo de 48 horas al 75 %.

Particiones

Una partición es una estructura de datos que contiene algunos o todos los datos de un grupo de medida. Cada grupo de medida se divide en particiones. Una partición define un subconjunto de los 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 que un grupo de medida contenga varias particiones. Las particiones son una característica que es transparente para el usuario final, pero tienen un impacto importante en el rendimiento y la escalabilidad de los cubos OLAP. Todas las particiones de un grupo de medida siempre existen en la misma base de datos física.

Las particiones permiten a un administrador administrar mejor un cubo OLAP y mejorar el rendimiento de un cubo OLAP. Por ejemplo, puede quitar o volver a procesar los datos de una partición de un grupo de medida sin afectar al resto del grupo de medida. Cuando se cargan nuevos datos en una tabla de datos, solo se verán afectadas las particiones que contendrán los nuevos datos.

La creación de particiones también mejora el procesamiento y el rendimiento de las consultas para los cubos OLAP. SSAS puede procesar varias particiones en paralelo, lo que implica un uso mucho más eficaz de los recursos de la CPU y la memoria en el servidor. Mientras se ejecuta una consulta, SSAS capta y procesa y agrega datos de varias particiones y solo se examinan las particiones que contienen los datos pertinentes para la consulta, lo que reduce la cantidad total de los flujos de entrada y salida.

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

Agregaciones

Las agregaciones en un cubo OLAP son conjuntos de datos previamente resumidos. Equivalen a una instrucción SELECT de SQL con una cláusula GROUP BY. SSAS puede usar estas agregaciones cuando responde a las consultas para reducir la cantidad de cálculos necesarios y devolver las respuestas rápidamente al usuario. Las agregaciones integradas en el 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 drásticamente el rendimiento de las consultas. Esto suele ser un proceso en constante evolución durante toda la vigencia del cubo OLAP a medida que cambian sus consultas y uso.

Normalmente, se crea un conjunto base de agregaciones que será útil para la mayoría de las consultas en el cubo OLAP. Las agregaciones se compilan para cada partición de un cubo OLAP dentro de un grupo de medida. Cuando se compila una agregación, se incluyen determinados atributos de dimensiones en el conjunto de datos previamente resumidos. Los usuarios pueden consultar rápidamente los datos en función de estas agregaciones cuando examinan el cubo OLAP. Las agregaciones deben diseñarse cuidadosamente porque el número de agregaciones potenciales es tan grande que la creación de todas ellas supondría una cantidad de tiempo y espacio de almacenamiento poco razonable.

Service Manager usa las dos opciones siguientes para compilar y diseñar agregaciones en cubos OLAP de Service Manager:

• El aumento de rendimiento alcanza
• Optimización basada en el uso

La opción "Performance Gain Reaches" define qué porcentaje de agregaciones se genera. Por ejemplo, establecer esta opción en el valor predeterminado y recomendado del 30 % significa que las agregaciones se compilarán para dar al cubo OLAP una ganancia de rendimiento estimada del 30 %. Pero esto no significa que se construirá un 30 por ciento de las posibles agregaciones.

La optimización basada en el uso permite a SSAS registrar las solicitudes de datos para que cuando se ejecute una consulta, la información se agregue en el proceso de diseño de agregaciones. Luego SSAS revisará los datos y recomendará qué agregaciones se deben compilar para proporcionar la mejor ganancia de rendimiento estimada.

Particionamiento de cubos de Service Manager

Cada grupo de medida de un cubo se divide en particiones, y una partición define una parte de los datos factuales que se cargan en un grupo de medida. SQL Server Analysis Services (SSAS) en SQL Server Standard Edition solo permite una partición por grupo de medida, mientras que en Enterprise Edition se permiten varias particiones. Las particiones son completamente transparentes para el usuario final, pero tienen un impacto importante en el rendimiento y la escalabilidad. Por ejemplo, las particiones se pueden procesar por separado y en paralelo. Pueden tener diferentes diseños de agregación. Puedes procesar de nuevo una partición sin afectar al resto de las particiones de un grupo de medida. Además, SSAS solo examina automáticamente las particiones que contienen los datos necesarios para una consulta, lo que puede mejorar enormemente el rendimiento de las consultas.

La partición de cubos se realiza en cada ejecución del trabajo de mantenimiento del almacenamiento de datos, que es cada hora de forma predeterminada. El módulo del proceso específico que se ejecuta se denomina ManageCubePartitions. Siempre se ejecuta después del paso CreateMartPartitions. Estos datos de dependencia se almacenan en la tabla infra.moduletriggercondition.

La biblioteca de vínculos dinámicos (DLL) principal, que controla la creación de particiones, se encuentra en el archivo DLL de la utilidad de almacenamiento, Microsoft.EnterpriseManagement.Warehouse.Utility, en la clase PartitionUtil. En concreto, hay un método ManagePartitions() en la clase que controla todo el mantenimiento de las particiones. El archivo DLL de mantenimiento del almacenamiento de datos, Microsoft.EnterpriseManagement.Warehouse.Maintenance, y el archivo DLL de procesamiento analítico en línea (OLAP) del almacenamiento de datos, Microsoft.EnterpriseManagement.Warehouse.Olap, llaman a Microsoft.EnterpriseManagement.Warehouse.Utility para controlar las particiones durante el mantenimiento y la implementación del cubo. Este es el motivo por el que el control de particiones real se encuentra en el archivo DLL de la utilidad de almacenamiento común para evitar la duplicación de la lógica o el código.

El mantenimiento de particiones de cubos realiza las siguientes tareas:

• Creación de particiones
• Eliminación de particiones
• Actualización de los límites de las particiones

Para ello, se lee la tabla etl.TablePartition del lenguaje de consulta estructurada (SQL) para determinar todas las particiones de hechos que se han creado para un grupo de medidas. Se producen las siguientes acciones:

1. Inicia el procesamiento de cubos para cada grupo de medida del cubo
2. Obtén todas las particiones de la tabla etl.TablePartition para el grupo de medida
3. Elimina las particiones que existen en el grupo de medida, pero que faltan en la tabla etl.TablePartition
4. Agrega las nuevas particiones que se hayan creado y que solo existan en la tabla etl.TablePartition
5. Actualiza cualquier partición que pueda haber cambiado haciendo coincidir cada partición con RangeStartDate y RangeEndDate en la tabla etl.TablePartition

Recuerda lo siguiente sobre el procesamiento de cubos:

• Solo los grupos de medida que están orientados a hechos contienen varias particiones en SQL Server Standard Edition. De forma predeterminada, todos los grupos de medida y de dimensiones contienen una sola partición. Por lo tanto, la partición no tiene ningún tipo de condición en cuanto a su límite.
• Los límites de partición se definen mediante un enlace de consulta que se basa en las claves de fecha que coinciden con las claves de fecha de la partición de datos correspondiente a la tabla etl. TablePartition.

Implementación del cubo OLAP de Service Manager

Los cubos de procesamiento analítico en línea (OLAP) usan la infraestructura de implementación de Service Manager para crear cubos OLAP en la base de datos de SQL Server Analysis Services (SSAS).

En resumen, un elemento implementable devuelve un implementador con una colección de recursos que se serializan y que se usan para crear el cubo OLAP en la base de datos SSAS. Para los cubos OLAP, el nombre del elemento implementable es CubeDeployable para el elemento SystemCenterCube y CubeExtensionDeployable para el elemento CubeExtension. El implementador de ambos elementos es CubeDeployer.

La tabla dbo.Selector de la base de datos DWStagingAndConfig contiene una entrada para los elementos del módulo de administración SystemCenterCube y CubeExtension. El motor de implementación usa estos metadatos si se necesita un procesamiento de implementación adicional para un elemento del módulo de administración cuando el módulo de administración se importa al almacenamiento de datos mediante la tarea MPSync.

Las implementaciones usan la API de los Objetos de Administración de Análisis (AMO) para crear y modificar todos los componentes del cubo de la base de datos SSAS. En concreto, se usa AMO en modo desconectado porque el elemento CubeDeployable no tendrá una conexión a la base de datos SSAS. Trabajar con AMO en modo desconectado permite crear todo el árbol de elementos de AMO sin establecer una conexión con el servidor. A continuación, Service Manager serializa la jerarquía de objetos como recursos de secuencia y los asocia al objeto del implementador, que se devuelve a la infraestructura de implementación. Después, el elemento implementable se deserializa, establece una conexión con la base de datos SSAD y crea los elementos enviando las solicitudes pertinentes al servidor.

Solo se pueden serializar los elementos principales. En AMO, los elementos principales se consideran clases que representan un elemento completo como una entidad completa y no como parte de otro elemento. Por ejemplo, los elementos principales incluyen Server, Cube y Dimension, que son todas entidades independientes. Sin embargo, DimensionAttribute no es un elemento principal porque solo se puede crear como parte de un elemento principal primario de Dimension. DimensionAttribute, por lo tanto, es un elemento secundario. El diseño del cubo OLAP se centra en crear todos los elementos principales necesarios para los cubos, junto con los elementos secundarios dependientes. Estos elementos principales son los que se serializarán y, los que, finalmente, se deserializarán antes de crear los elementos en la base de datos SSAS.

Los recursos que envuelven los objetos principales deben crearse en un orden específico a fin de que la implementación se complete correctamente y cumpla con los requisitos de dependencia de los elementos del cubo OLAP. En las dos listas siguientes se muestra la secuencia de implementación de los elementos SystemCenterCube y CubeExtension, respectivamente:

1. Elementos DataSourceView
2. Elementos de dimensión
3. Elemento de la dimensión de fecha
4. Elemento cubo
5. Elementos DataSourceView
6. elemento cubo

Procesamiento de cubos OLAP de Service Manager

Cuando se ha implementado un cubo de procesamiento analítico en línea (OLAP) y se han creado todas sus particiones, está listo para procesarse para que se pueda ver. El procesamiento de un cubo es el paso final después de las ejecuciones de extracción, transformación y carga (ETL). Estos pasos se producen de la siguiente manera:

1. Extracción: extracción de datos del sistema de origen
2. Transformación: aplica funciones para ajustar los datos a un esquema dimensional estándar
3. Carga: carga los datos en el almacén de datos para su consumo.
4. Proceso: carga los datos del data mart en el cubo OLAP para la navegación.

El procesamiento de un cubo OLAP se produce cuando se calculan todas las agregaciones del cubo y el cubo se carga con estas agregaciones y datos. Las tablas de dimensiones y datos se leen y los datos se calculan y se cargan en el cubo. Al diseñar un cubo OLAP, el procesamiento es un paso muy importante, ya que podría ser una etapa significativa en un entorno de producción donde pueden existir millones de registros. Un proceso completo de todas las particiones de este entorno puede tardar días e incluso semanas, por lo que es posible que los usuarios finales no puedan tener disponibles para su uso la infraestructura y los cubos de Service Manager. Recomendamos deshabilitar la programación de procesamiento de los cubos que no se usan para reducir la sobrecarga en el sistema.

El procesamiento de cubos OLAP consta de dos tareas independientes:

1. Procesamiento de la dimensión
2. Procesamiento de particiones

Cada cubo OLAP tiene una tarea de procesamiento correspondiente en la consola de Service Manager y se ejecuta mediante una programación configurable por el usuario. En las siguientes secciones, se describe cada tipo de tarea de procesamiento.

Procesamiento de la dimensión

Cada vez que se agrega una nueva dimensión a la base de datos de SQL Server Analysis Server (SSAS), se debe ejecutar un proceso completo en la dimensión para llevarlo a un estado totalmente procesado. Sin embargo, después de procesar una dimensión, no hay ninguna garantía de que se procesará de nuevo cuando se procese otro cubo que tenga como destino la misma dimensión. Al no volver a procesar automáticamente la dimensión, se impide que Service Manager vuelva a procesar todas las dimensiones de cada cubo. Esto es especialmente cierto si la dimensión se ha procesado recientemente, ya que es poco probable que existan nuevos datos que aún no se hayan procesado. Para optimizar la eficacia del procesamiento, hay una clase singleton, que se define en el módulo de administración Microsoft.SystemCenter.Datawarehouse.OLAP.Base, denominado Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval. A continuación, se muestra un ejemplo de esta clase:

<!-- This singleton class defines the minimum interval of time in minutes that must elapse before a shared dimension is reprocessed. -->   
<ClassType ID="Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval" Accessibility="Public" Abstract="false" Base="AdminItem!System.AdminItem" Singleton="true">  
<Property ID="IntervalInMinutes" Type="int" Required="true" DefaultValue="60"/>  
</ClassType>  

Esta clase singleton contiene una propiedad IntervalInMinutes, que describe la frecuencia con la que procesar una dimensión. De manera predeterminada, esta propiedad se encuentra configurada en 60 minutos. Por ejemplo, si se procesó una dimensión a las 3:05 p.m. y otro cubo que tiene como destino la misma dimensión se procesa a las 3:45 p.m., la dimensión no se vuelve a procesar. Un inconveniente de este enfoque es la mayor probabilidad de errores de clave de dimensión. Un mecanismo de reintento controla los errores de clave de dimensión para volver a procesar la dimensión y, después, la partición del cubo. Para obtener más información sobre los errores de procesamiento, consulta la sección "Problemas comunes de depuración y solución de problemas".

Una vez que se ha procesado completamente una dimensión, se ejecuta el procesamiento incremental con ProcessUpdate. La única vez que se ejecuta ProcessFull es cuando cambia un esquema de dimensión, ya que da como resultado que la dimensión vuelva a un estado no procesado. Recuerda que si se ejecuta ProcessFull en una dimensión, todos los cubos afectados y sus particiones existirán en un estado no procesado y tendrán que procesarse completamente en su siguiente ejecución programada.

Procesamiento de particiones

El procesamiento de particiones debe considerarse detenidamente porque el reprocesamiento de una partición grande es lento y consume muchos recursos de CPU en el servidor que hospeda SSAS. El procesamiento de particiones suele tardar más tiempo que el procesamiento de dimensiones. A diferencia del procesamiento de dimensiones, el procesamiento de una partición no tiene efectos secundarios en otros objetos. Los dos únicos tipos de procesamiento que se realizan en los cubos OLAP de System Center - Service Manager son ProcessFull y ProcessAdd.

De forma similar a las dimensiones, la creación de nuevas particiones en un cubo OLAP requiere una tarea ProcessFull para que la partición esté en un estado en el que se pueda consultar. Dado que una tarea ProcessFull es una operación costosa, debes realizar una tarea ProcessFull solo cuando sea necesario; por ejemplo, al crear una partición o cuando se ha actualizado una fila. En escenarios en los que se han agregado filas y no se ha actualizado ninguna fila, Service Manager puede realizar una tarea ProcessAdd. Para ello, Service Manager usa marcas de agua y otros metadatos. En concreto, se consultan la tabla etl.cubepartition y la tabla etl.tablepartition para determinar qué tipo de procesamiento se va a realizar.

En el diagrama siguiente se muestra cómo Service Manager determina el tipo de procesamiento que se va a realizar en función de los datos de marca de agua.

Cuando se realiza una tarea ProcessAdd, Service Manager limita el ámbito de la consulta mediante marcadores. Por ejemplo, si el valor InsertedBatchId es 100 y el valor WatermarkBatchId es 50, la consulta carga datos solo desde el data mart donde InsertedBatchId es mayor que 50 y menor que 100.

Por último, es importante tener en cuenta que Service Manager no admite el procesamiento manual de cubos OLAP mediante SSAS o Business Intelligence Development Studio. El procesamiento de cubos fuera de los métodos proporcionados en System Center - Service Manager, incluida la consola de Service Manager y los cmdlets de Service Manager, no actualizará las tablas de marcas de agua. Por lo tanto, es posible que se produzcan problemas de integridad de datos. Si has vuelto a procesar accidentalmente el cubo manualmente, una posible solución alternativa es desprocesar el cubo OLAP manualmente de la misma manera. Después, la próxima vez que Service Manager procese el cubo, realizará automáticamente una tarea ProcessFull porque las particiones estarán en un estado no procesado. Esto actualizará todas las marcas de agua y los metadatos correctamente para que se corrigan los posibles problemas de integridad de datos.

Mantenimiento de cubos OLAP de Service Manager

En la información de las secciones siguientes se describen los procedimientos recomendados de mantenimiento para los cubos de procesamiento analítico en línea (OLAP).

Reprocesar periódicamente las dimensiones de Analysis Services

Los procedimientos recomendados de SQL Server Analysis Services (SSAS) recomiendan que las dimensiones de SSAS deben procesarse completamente de manera periódica. El procesamiento total de las dimensiones vuelve a generar índices y optimiza el almacenamiento de datos multidimensionales, lo que mejora el rendimiento de las consultas y de los cubos, que pueden degradarse con el tiempo. Esto es similar a desfragmentar periódicamente un disco duro en un equipo.

Sin embargo, un inconveniente de procesar completamente una dimensión SSAS es que todos los cubos OLAP afectados se vuelven sin procesar y también deben procesarse por completo para devolverlos al estado en el que puedes consultarlos. Service Manager no procesa completamente de manera explícita en dimensiones SSAS. Por lo tanto, debes decidir cuándo realizar esta tarea de mantenimiento.

Consideraciones de memoria

Si ejecutas todas las operaciones de extracción, transformación y carga de almacenamiento de datos (ETL) y funciones de cubo OLAP en un servidor, considera cuidadosamente las necesidades de memoria del sistema operativo, el almacenamiento de datos y SSAS para asegurarte de que el servidor pueda controlar todas las operaciones que consumen muchos datos que se pueden ejecutar simultáneamente. Esto es especialmente importante porque el procesamiento de cubos OLAP es una operación que consume mucha memoria.

Pasos siguientes

• Modelar cubos OLAP en módulos de administración.