Información general de los cubos

OLAP de Service Manager para realizar

análisis avanzados
 05/05/2019
 Tiempo de lectura: 27 minutos

o

En Service Manager, los datos que se encuentra en el almacén de datos se pueden

consolidar desde varios orígenes. Se presenta a través de Service Manager
mediante el uso de predefinidos y personalizados Microsoft Online Analytical
Processing (OLAP) cubos de datos. En resumen, análisis avanzado en Service
Manager constan de publicar, ver y manipular los datos del cubo, por lo general en
Microsoft Excel o Microsoft SharePoint. Excel se utiliza principalmente por sí mismo
para ver y manipular los datos. SharePoint se utiliza principalmente como medio
para publicar y compartir datos del cubo.

Service Manager incluye un almacén de datos de System Center-wide. Por lo tanto,

se pueden consolidar datos de Operations Manager, Configuration Manager y
Service Manager en el almacén de datos, donde puede usar fácilmente varias vistas
de datos para obtener la información que es posible que desee. Esto también es
una interfaz que puede colocar datos en el mismo almacén de datos desde sus
propios orígenes personalizados, como las aplicaciones de SAP o por un tercero-
aplicación de recursos humanos. Esta consolidación crea un modelo de datos
común y permite realizar análisis enriquecidos que le ayudarán a crear un almacén
de datos a través de la tecnología de la información (TI) organización que puede
actuar todas la inteligencia empresarial y necesidades de informes.

Una vez que los datos están en un modelo común, puede manipular la información
y tener definiciones comunes y una taxonomía común para toda la empresa. Puede
hacerlo mediante la implementación de cubos de datos OLAP, desde donde se
tiene acceso a la información a través de herramientas estándar, como Excel y
SharePoint. Esto posibilita que los usuarios empleen las habilidades que ya
conocen. La definición de la lógica empresarial se controla de manera
centralizada. Por ejemplo, puede definir indicadores clave de rendimiento, como la
hora de incidentes-a-los umbrales de resolución y que los valores de los umbrales
son verdes, amarillo o rojo. Puede controlar estas opciones de forma centralizada y
permitir a los usuarios que utilicen los datos de forma sencilla, a la vez que tienen
una definición común en sus informes Excel o paneles SharePoint.

Acerca de los cubos OLAP de Service Manager

Procesamiento analítico en línea (OLAP) cubos son una característica en el
Administrador de servicios que usan la infraestructura de almacenamiento de datos
existente para proporcionar self-capacidades de inteligencia empresarial a los
usuarios finales del servicio.

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 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 este modo, los
datos pueden se acumulan, segmentar y o reorganizar según sea necesario para
procesar la variedad más amplia de preguntas pertinentes al área de un usuario de
interés.

Los proveedores de software o tecnología de la información (TI) los desarrolladores

con conocimientos prácticos de los cubos OLAP pueden crear módulos de
administración para definir sus propios cubos OLAP extensibles y personalizables
que se basan en el almacén de datos infraestructura. Estos cubos se almacenan en
SQL Server Analysis Services (SSAS). Self-servicio herramientas de inteligencia
empresarial, como Excel y SQL Server Reporting Services (SSRS) puede acceder a
estos cubos en SSAS, y puede usar para analizar los datos desde varias
perspectivas.

Las bases de datos que utiliza una empresa para almacenar todas sus transacciones
y registros se conocen como el procesamiento de transacciones en línea (OLTP)
bases de datos. Normalmente, estas bases de datos tienen registros que se
introducen uno a uno y que contienen una gran cantidad de información, que los
estrategas pueden utilizar para tomar decisiones fundamentadas sobre sus
negocios. Sin embargo, las bases de datos que se utilizan para almacenar los datos
no se diseñaron para el análisis. Por lo tanto, obtener respuestas de estas bases de
datos requiere tiempo y esfuerzo. Las bases de datos OLAP son bases de datos
especializadas, diseñadas para ayudar a extraer esta 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 genera mediante bases de datos OLAP para
permitir que casi-análisis instantáneo de datos. La topología de este sistema se
muestra en la siguiente ilustración.

La característica útil de un cubo OLAP es que los datos del cubo pueden estar
contenidos en un formulario agregado. Para el usuario, el cubo parece tener las
respuestas de antemano debido a la variedad de valores que ya están
precalculados. Sin tener que consultar la base de datos OLAP de origen, el cubo
puede devolver respuestas para una amplia gama de preguntas casi al instante.

El objetivo principal de los cubos OLAP de Service Manager es ofrecer a los

proveedores de software o tecnología de la información (TI) a los desarrolladores la
capacidad de realizar casi-análisis instantáneo de datos para tendencias y análisis
histórico con fines. Service Manager para ello:

 Permite 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.
 Se ocupa automáticamente del mantenimiento del cubo, sin intervención del
usuario, y realiza tareas tales como el procesamiento, la creación de
particiones, las traducciones y la localización, así como los cambios del
esquema.
 Lo que permite a los usuarios usar self-herramientas de inteligencia
empresarial, como Excel, para analizar los datos desde varias perspectivas de
servicio.
 Guarda informes generados de Excel para futuras referencias.

Para ver cómo se representan los cubos del almacenamiento de datos en la

consola de Service Manager, navegue hasta la Data Warehouse área de trabajo y,
a continuación, haga clic en cubos.
Cubos OLAP de Service Manager
La siguiente ilustración muestra una imagen de SQL Server Business Intelligence
Development Studio (BIDS) que representa las partes principales que son
necesarias para el procesamiento analítico en línea (OLAP) cubos. 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.

Origen de datos

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 para todos los cubos OLAP de Service Manager es el
data marts, que incluye los data marts de Operations Manager y Configuration
Manager. 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

Vista del origen de datos (DSV) es una colección de vistas que representan las
tablas de dimensiones, hechos y subdimensión de origen de datos, por ejemplo,
los puestos de datos 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 define un valor booleano para de incidentes
resueltos calcula el valor como true si el estado de un incidente es resuelto o
cerrado. Mediante el cálculo con nombre, Service Manager, a continuación, 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
que no se resuelven.

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. Cubos OLAP
pueden mostrar y sumar grandes cantidades de datos también proporciona a los
usuarios acceso de búsqueda a los puntos de datos para que los datos se pueden
acumular, segmentar y o reorganizar según sea necesario para procesar la variedad
más amplia de preguntas pertinentes al área de un usuario de interés.

Dimensiones

Una dimensión en SSAS hace referencia a una dimensión desde el almacenamiento

de datos de Service Manager. En Service Manager, una dimensión es
aproximadamente 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, se pueden presentar los datos en un formato donde los datos se
clasifican de forma natural en estas jerarquías y categorías para permitir una más
en-análisis de profundidad. 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 Xbox una consola de juegos en
2016. Pueden desglosarlo más para obtener cifras de ventas de un período de
tiempo más específico. Los analistas de negocios que desee examinar cómo las
ventas de Xbox consolas uno afectadas por el lanzamiento del nuevo diseño de
consola y la Kinect para Xbox uno. 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 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.

Después de procesar los datos sin procesar en un cubo OLAP, los usuarios pueden
realizar cálculos y consultas mediante expresiones multidimensionales más
complejos (MDX) para definir sus propias expresiones de medida o miembros
calculados. 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 que admiten las bases de datos multidimensionales.

Exploración en profundidad

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.
 Explore en profundidad las cifras de ventas para Xbox uno consolas para el
año 2015, a continuación, el cuarto trimestre del año, a continuación, el mes
de diciembre, a continuación, en la semana previa a Navidad y, finalmente, en
Nochebuena.
Obtención de detalles

Cuando los usuarios detallado datos, que desean ver datos agregados de todas las
transacciones individuales que han contribuido al 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" entre sí. La

diferencia principal entre ellos es que una exploración en profundidad-funciona en
una jerarquía predefinida de datos: por ejemplo, EE.UU y, a continuación,
Washington, a continuación, Seattle-dentro del cubo OLAP.Un simulacro-vaya
directamente en el nivel más bajo de detalle de los datos a través 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, desea definir un valor de destino KPI para la
finalización de todas las solicitudes de cambio dentro de 48 horas a 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 un administrador para administrar un cubo OLAP mejor

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. Compila-en las agregaciones del cubo OLAP, reducir la
cantidad de agregación que SSAS tiene que realizar en tiempo de 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
 Uso-optimización basada en

La opción Ganancia de rendimiento define el porcentaje de agregaciones que se ha

creado. Por ejemplo, si el valor predeterminado de esta opción y valor de 30
recomendado por ciento significa que las agregaciones se generarán para dar el
cubo OLAP una 30-por ciento de ganancia de rendimiento estimada. Sin embargo,
esto no significa que 30 por ciento de las agregaciones posibles se compilará.

Uso-optimización basada en hace posible que SSAS registre las solicitudes de

datos para que cuando se ejecuta una consulta, la información se introduce en el
proceso de diseño de agregaciones. A continuación, SSAS revisa los datos y
recomienda las agregaciones que se deben generar para dar la máxima ganancia
de rendimiento.

Creación de particiones de cubo de Service Manager

Cada grupo de medida de un cubo se divide en particiones, donde una partición
define una parte de los datos de hechos que se carga 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 se permiten varias particiones en la
edición Enterprise. 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 distintos diseños de agregación. Puede volver a procesar
una partición sin afectar al resto de las particiones de un grupo de
medida. Además, SSAS solo escanea automáticamente las particiones que
contienen los datos necesarios para una consulta, lo que puede mejorar
considerablemente 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 se tiene lugar 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 principal (DLL), que controla la creación de

particiones, que está en la utilidad DLL del almacenamiento,
Microsoft.EnterpriseManagement.Warehouse.Utility, en la clase PartitionUtil. En
concreto, hay un ManagePartitions( ) método en la clase que controla todo el
mantenimiento de partición. DLL de mantenimiento,
Microsoft.EnterpriseManagement.Warehouse.Maintenance y el procesamiento
analítico en línea de almacén de datos del almacenamiento de datos (OLAP) DLL,
Microsoft.EnterpriseManagement.Warehouse.Olap, ambos llamar a
Microsoft.EnterpriseManagement.Warehouse.Utility para administrar particiones
durante la implementación de mantenimiento y el cubo. Por esta razón, para evitar
la duplicación de la lógica o del código, el procesamiento real de la partición se
realiza en la utilidad DLL del almacenamiento común.

El mantenimiento de las particiones de un cubo realiza las siguientes tareas:

 Crear particiones
 Eliminar particiones
 Actualizar límites de la partición

Para ello, lenguaje de consulta de la estructurado (SQL) etl de la tabla.

TablePartition se lee para determinar todas las particiones de hechos que se han
creado para un grupo de medida. Se emprenden las siguientes acciones:

1. Iniciar el procesamiento del cubo para cada grupo de medida del cubo
2. Obtener todas las particiones de la tabla etl.TablePartition para el grupo de
medida
3. Eliminar todas las particiones que existen en el grupo de medida, pero que
faltan en la tabla etl.TablePartition
 4. Agregar las particiones nuevas que se han creado y que sólo existen en la
tabla etl.TablePartition
5. Actualizar cualquier partición que pueda haber cambiado haciendo coincidir
cada partición con RangeStartDate y RangeEndDate en la tabla
etl.TablePartition

Recuerde lo siguiente sobre el procesamiento de cubos:

 Solo los grupos de medidas que tienen como destino hechos contienen varias
particiones en SQL Server Standard Edition. De forma predeterminada, todos
los grupos de medida y dimensiones contienen sólo una partición. Por lo
tanto, la partición no tiene ninguna condición de límite.
 Los límites de la partición se definen mediante un enlace de consulta que se
basa en los datekeys que coinciden con los datekeys de la partición de hecho
correspondiente en la tabla etl.TablePartition.
Implementación del cubo OLAP de Service Manager
Procesamiento analítico en línea (OLAP) implementación del cubo, usa la
infraestructura de implementación de Service Manager para crear cubos OLAP en
el código SQL Server Analysis Services (SSAS) base de datos.

En resumen, un elemento que se puede implementar devuelve un implementador

con una colección de recursos que se serializan y que se utilizan para crear el cubo
OLAP en la base de datos de SSAS.Para los cubos OLAP, el nombre del objeto que
se puede implementar es CubeDeployable, para el elemento SystemCenterCube, y
CubeExtensionDeployable, para el elemento CubeExtension. El implementador de
ambos elementos es CubeDeployer.

La tabla dbo.Selector, en la base de datos DWStagingAndConfig, contiene una

entrada para los elementos SystemCenterCube y CubeExtension del módulo de
administración. El motor de implementación utiliza este metadato si es necesario
realizar un procesamiento adicional para un elemento del módulo de
administración al importar dicho módulo al almacenamiento de datos mediante el
trabajo MPSync.

Los objetos de administración de análisis de uso de implementaciones (AMO)

interfaz de programación de aplicaciones (API) para crear y modificar todos los
componentes del cubo en la base de datos SSAS. En concreto, se utiliza AMO en
modo desconectado, ya que el elemento CubeDeployable no tiene una conexión a
la base de datos de SSAS. Al trabajar con AMO en un modo sin conexión, es
posible crear un árbol completo de objetos AMO sin tener que conectarse al
servidor. Service Manager, a continuación, serializa la jerarquía de objetos como
recursos de secuencia y los asocia al objeto del implementador que se pasa a la
infraestructura de implementación. A continuación, el objeto del implementador se
deserializa, establece una conexión con la base de datos de SSAD y crea los objetos
mediante el envío de las solicitudes correspondientes al servidor.

Sólo los objetos principales se pueden serializar. En AMO, los principales objetos se
consideran clases que representan un objeto completo como una entidad
completa y no como parte de otro objeto. Por ejemplo, los objetos principales
incluyen servidor, cubo y dimensión, que son todas las reuniones-entidades por sí
solo. Sin embargo, DimensionAttribute no es un objeto principal, porque sólo se
puede crear como parte de un objeto principal primario de Dimensión. Por lo
tanto, DimensionAttribute es un objeto secundario. El diseño del cubo OLAP se
centra en la creación de todos los objetos principales que son necesarios para los
cubos, junto con los objetos dependientes de menor importancia. Estos objetos
principales son los objetos que se va a serializar- y, finalmente, deserializar antes
los objetos se crean en la base de datos SSAS.

Los recursos que ajustan los objetos principales se deben crear en un orden
específico para que la implementación se realice correctamente y satisfaga los
requisitos de dependencia de los elementos del cubo OLAP. Las dos listas
siguientes ilustran la secuencia de implementación de los elementos
SystemCenterCube y CubeExtension, respectivamente:

1. Elementos DataSourceView
2. elementos de dimensión
3. elemento de dimensión de fecha
4. elemento de cubo
5. Elementos DataSourceView
6. elemento de cubo
Procesamiento de cubos OLAP de Service Manager
Cuando un procesamiento analítico en línea (OLAP) cubo se ha implementado y se
han creado todas sus particiones, está listo para ser procesado de modo que sea
visible. Procesar un cubo es el último paso después de la extracción,
transformación y carga (ETL) se ejecuta. Estos pasos se producen de la forma
siguiente:

1. Extraer: Extraer datos del sistema de origen

 2. Transformación: Aplicar funciones para ajustar los datos a un esquema
dimensional estándar
3. Carga: Cargar los datos en el data mart para su uso
4. Proceso: Cargar los datos del data mart en el cubo OLAP para la exploración

El procesamiento de un cubo OLAP se produce una vez que se han calculado todas
sus agregaciones y se ha cargado con estos datos y agregaciones. Se leen las
tablas de hechos y dimensiones, y los datos se calculan y se cargan en el cubo. A la
hora de diseñar un cubo OLAP, es necesario reflexionar detenidamente sobre su
procesamiento, debido al efecto potencialmente significativo de dicho
procesamiento en un entorno de producción donde podrían existir millones de
registros. Un proceso completo de todas las particiones en un entorno podría
tardar días o incluso semanas, lo que podrían inutilizar la infraestructura de Service
Manager y los cubos a los usuarios finales. Una recomendación es deshabilitar el
programa de procesamiento de algunos cubos que no se utilizan para reducir la
sobrecarga en el sistema.

El procesamiento de los cubos OLAP consta de dos tareas independientes:

1. Procesamiento de dimensiones
2. Procesamiento de particiones

Cada cubo OLAP tiene un trabajo de procesamiento correspondiente en la consola

de Service Manager, y se ejecuta en un usuario-programación configurable. En las
siguientes secciones se describe cada tipo de tarea de procesamiento.

Procesamiento de dimensiones

Cada vez que se agrega una nueva dimensión a SQL Server Analysis Server (SSAS)
base de datos, se debe ejecutar un proceso completo en la dimensión para que
tenga un estado totalmente procesado. Sin embargo, una vez procesada la
dimensión, no existe ninguna garantía de que se procesará de nuevo cuando se
procese otro cubo que tenga como destino la misma dimensión. Al no reprocesar
automáticamente la dimensión impide que Service Manager reprocesar cada
dimensión de cada cubo. Esto es especialmente cierto si la dimensión se ha
procesado recientemente, ya que es poco probable que existan datos nuevos que
todavía no se han procesado. Para optimizar la eficacia del procesamiento, hay una
clase singleton, que se define en el módulo de administración de
Microsoft.SystemCenter.Datawarehouse.OLAP.Base, denominada
Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval. El siguiente es
un ejemplo de esta clase:
Copiar
<!-- 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 de procesamiento de una dimensión. De forma predeterminada, esta
propiedad se establece en 60 minutos. Por ejemplo, si una dimensión se procesa 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., no se volverán a procesar la dimensión. Un inconveniente de este
enfoque es el aumento de las posibilidades de errores de clave de dimensión.Un
mecanismo de reintento controla los errores clave de la dimensión para poder
reprocesar tanto la dimensión como la partición del cubo. Para obtener más
información acerca de los errores de procesamiento, vea la sección "Comunes
problemas con la depuración y solución de problemas".

Una vez que la dimensión se ha procesado completamente, se ejecuta un

procesamiento incremental con ProcessUpdate . La otra ocasión en que se
ejecuta ProcessFull es cuando se producen cambios en el esquema de una
dimensión, ya que la devuelven a un estado sin procesar.Recuerde que si se
realiza ProcessFull en una dimensión, posteriormente, todos los cubos afectados y
sus particiones existirán en un estado sin procesar y será necesario procesarlos
completamente en su siguiente ejecución programada.

Procesamiento de particiones

Reflexione detenidamente sobre el procesamiento, ya que volver a procesar una

partición grande resulta muy lento y consume muchos recursos de CPU en el
servidor que hospeda SSAS.Generalmente, el procesamiento de particiones tarda
más que el procesamiento de dimensiones. A diferencia del procesamiento de
dimensiones, el procesamiento de particiones no tiene efectos secundarios en
otros objetos. Los dos únicos tipos de procesamiento se realizan en System Center
2016 - cubos OLAP de 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 que
se pueda consultar. Dado que una tarea ProcessFull es una operación costosa, solo
se debe realizar cuando sea necesario; por ejemplo, al crear una partición o al
actualizar una fila. En escenarios en los que se han agregado filas y se han
actualizado ninguna fila, Service Manager puede realizar una tarea
ProcessAdd. Para ello, Service Manager utiliza marcas de agua y otros
metadatos. En concreto, se consultan las tablas etl.cubepartition y etl.tablepartition
para determinar el tipo de procesamiento que se va a llevar a cabo.

El siguiente diagrama ilustra cómo Service Manager determina qué tipo de

procesamiento que desea realizar según los datos de marca de agua.

Cuando se realiza una tarea ProcessAdd, Service Manager limita el ámbito de la

consulta mediante marcas de agua. Por ejemplo, si el valor de InsertedBatchId es
100 y el valor de WatermarkBatchId es 50, la consulta carga únicamente los datos
del data mart en el que el valor de InsertedBatchId sea superior a 50 e inferior a
100.

Por último, es importante tener en cuenta que Service Manager no admite el

procesamiento manual de los cubos OLAP mediante SSAS o Business Intelligence
Development Studio. Procesamiento de cubos fuera de los métodos que se
proporcionan en System Center - Service Manager, incluida la consola de Service
Manager y cmdlets de Service Manager, no se actualizarán las tablas de marca de
agua. Por lo tanto, se podrían producir problemas de integridad de datos. En caso
de reprocesamiento manual de un cubo de forma accidental, una solución posible
es cancelar manualmente el proceso del cubo OLAP de la misma manera. A
continuación, la próxima vez que el Administrador de servicio procesa el cubo,
realizará automáticamente una tarea ProcessFull porque las particiones estarán en
un estado sin procesar. De esta forma, las marcas de agua y los metadatos se
actualizarán correctamente y así se solucionará cualquier posible problema de
integridad de datos.

Mantener cubos OLAP de Service Manager

La información en las secciones siguientes describe prácticas recomendadas de
mantenimiento para procesamiento analítico en línea (OLAP) cubos.

Reprocesamiento periódico de las dimensiones de Analysis Services

SQL Server Analysis Services (SSAS) las prácticas recomendadas indican que las
dimensiones SSAS se deben procesar completamente periódicamente. Al procesar
por completo las dimensiones se vuelven a generar índices y se optimiza el
almacenamiento de datos multidimensionales, lo que mejora el rendimiento de las
consultas y del cubo, que puede reducirse con el trascurso del tiempo.El proceso es
similar a la desfragmentación periódica de un disco duro en un equipo.

Sin embargo, un inconveniente de procesar por completo una dimensión SSAS es

que todos los cubos OLAP afectados pasan a un estado sin procesar y también se
deben procesar por completo para devolverlos al estado en el que se pueden
consultar. Service Manager no procesa explícitamente por completo en las
dimensiones SSAS. Por lo tanto, debe decidir cuándo realizar esta tarea de
mantenimiento.

Consideraciones de memoria

Si ejecutar todas extracción, transformación y carga (ETL) operaciones y las

funciones del cubo OLAP en un servidor, considere detenidamente las necesidades
de memoria del sistema operativo, almacenamiento de datos y SSAS para
asegurarse de que el servidor puede administrar todos los datos-operaciones
intensivas que pueden ejecutarse simultáneamente. Esto es especialmente
importante porque el procesamiento de cubos OLAP es una memoria-de manera
intensiva.