Cubos de Datos
Cubos de Datos
Cubos de Datos
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.
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.
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.
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.
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
Grupo de medida
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.
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.
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.
Agregaciones
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
Crear particiones
Eliminar particiones
Actualizar límites de la partición
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
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.
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:
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.
1. Procesamiento de dimensiones
2. Procesamiento de particiones
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>
Procesamiento de particiones
Consideraciones de memoria