Enfoques y consideraciones de rendimiento en escenarios y soluciones de planeación de inteligencia empresarial

Artículo
03/03/2017

Se aplica a: SharePoint Server 2010 Enterprise

Última modificación del tema: 2016-11-30

En este artículo:

Consideraciones de rendimiento
Seguridad y roles

Consideraciones de rendimiento

Diseño y configuración

Mantenga los tamaños de la dimensión tan pequeños como sea necesario para el proceso de planeación.
Mantenga el número de dimensiones utilizadas en un cubo en el mínimo necesario para la planeación.
Evite los cálculos MdxScript cuando sea posible y saque el máximo provecho de los cálculos del lado cliente, como los cálculos relacionales o en la hoja de Excel, que están programados para ejecutarse periódicamente (es decir, la conversión de divisa).
Cuando use reglas de MdxScript, tenga cuidado al comprobar no solo la corrección lógica, sino también su rendimiento. A veces se puede modificar la instrucción MdxScript para proporcione grandes mejoras de rendimiento al escribirla ligeramente diferente, pero con la misma equivalencia lógica.
Evite las jerarquías de equipo que sean muy profundas.
Evite las consultas MDX complejas cuando diseñe informes y formularios de entrada. Las consultas que contienen la instrucción WITH y otros miembros calculados harán que el equipo con Microsoft SQL Server Analysis Services (SSAS) use una lógica de almacenamiento en caché limitada y, por lo tanto, darán como resultado menos escala y rendimiento.
Si trabaja con un gran conjunto de datos, cree varias particiones para administrar mejor los datos volátiles frente a los estáticos.
Evite la seguridad de nivel de celda dentro de las definiciones de seguridad de rol, ya que la lógica de almacenamiento en caché se verá limitada cuando se aplique la seguridad de nivel de celda.

Tamaño de formulario, diseño y uso

Diseñe formularios (tablas dinámicas) que hagan uso de filtros y segmentación de datos para limitar el número de celdas y consultar el formulario; es decir, no diseñe el formulario con toda la entrada de datos posibles visible, sino que proporcione un filtro o segmentación de datos para que el diseño del formulario (tamaño) siga siendo coherente desde un punto de vista de diseño y se dinamice mediante la modificación de la segmentación de datos.
Tener varias tablas dinámicas aumentará el tiempo de consulta y respuesta. Se recomienda limitar el número de tablas dinámicas en la misma hoja y en el mismo libro.
Al diseñar formularios e informes, establezca el valor predeterminado de los filtros en un miembro de nivel más bajo en la jerarquía. Esto permitirá que las consultas predeterminadas precedan cálculos de agregaciones innecesarias en el cubo.
No mantenga grandes cambios del lado cliente (por ejemplo, dentro de los cambios de reescritura de las tablas dinámicas de Excel), sino que más bien publique de forma incremental estos cambios en el servidor para obtener un rendimiento óptimo en tiempo de ejecución de SQL Server Analysis Services.

Soporte para usuarios remotos

Los usuarios remotos en WAN podrían tener tiempos de respuesta y una conexión de red más lentos. Para atender a los usuarios remotos, sería preferible hacer lo siguiente:
Proporcionarles su propia instancia de SQL o SharePoint lo más cerca posible de su ubicación física.
Proporcionarles acceso de Servicios de Escritorio remoto a Excel en un equipo con una mayor proximidad con el servidor de SharePoint o SQL Server.

Para obtener más información, vea la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008.

Consideraciones de ETL

ETL es el proceso de extraer datos de sistemas de origen, transformarlos y cargarlos en el modelo de datos. SQL Server Integration Serviceses la tecnología premier de Microsoft para trabajar con procesos ETL. Los integradores de datos diseñan paquetes SSIS mediante el uso de Microsoft Business Intelligence Development Studio (BIDS), que incluye las siguientes ventajas:

Acceso a una biblioteca grande de lógica ETL incorpora para elementos tales como la combinación de conjuntos de datos, las búsquedas de columnas, el control de errores, etc.
Transferencias rápidas de datos para carga de datos desde el origen al destino.
Interfaz de usuario para visualizar el proceso ETL.

La planeación de los paquetes ETL puede dividirse en las siguientes áreas:

Importación de datos para dimensiones, jerarquías y hechos.
Exportación de datos desde tablas de hechos a sistemas de origen.

Importación de datos

Para nuestra solución, crearemos una tabla provisional para cada una de las tablas de hechos, jerarquías y dimensiones que existen en la base de datos relacional. Las tablas provisionales se usarán inicialmente como la tabla de destino para cargar datos desde el sistema de origen. Es posible hacer ETL sin usar ninguna tabla provisional en absoluto, ya que SSIS tiene la capacidad de transformar la mayoría de los datos en memoria y cargarlos directamente en las tablas de la solución. Sin embargo, entre las ventajas de tener tablas provisionales se incluyen las siguientes:

Instantáneas de las tablas y las relaciones desde el sistema de origen para facilitar el trabajo fuera de una versión de los datos sin riesgo de perder el acceso futuro al sistema de origen o estar sujeto a cambios de datos inesperados.
Auditoría fácil de los datos provisionales antes de insertarlos en las tablas de la solución. Por ejemplo, puede decidir realizar una carga masiva en todas las tablas de la solución solo después de que alguien compruebe la corrección de las tablas provisionales.

Una vez que se cargan los datos en las tablas provisionales y se llevan a cabo las transformaciones necesarias, puede comenzar el proceso de carga desde las tablas provisionales a las tablas de la solución. Con SSIS, la carga desde las tablas provisionales a las tablas de la solución puede ser tan sencilla como la asignación de columnas desde la tabla de origen a las columnas de la tabla de destino. SSIS proporciona un conjunto de características muy eficaces para ETL y se recomienda al lector que lea más sobre el tema aquí, en las notas del producto de introducción a los servicios de integración de SQL Server 2008.

Sugerencia

Simplifique el modelo de recuperación de SQL durante el rendimiento de ETL. Esto mejorará el rendimiento ya que reducirá la sobrecarga de registros innecesarios en la base de datos.

Exportación de datos

Es habitual en la mayoría de los escenarios que una vez completado el proceso de planeación, los resultados deban recopilarse y procesarse para la exportación en el sistema de origen, donde los datos se conservarán y estarán disponibles para los requisitos de informes.

En nuestra solución, dado que los datos ya están almacenados en las tablas de hechos de una manera normalizada, la preparación de los datos para la exportación solo requiere algunas combinaciones sencillas con las tablas de dimensiones.

Sin embargo, la exportación de datos puede llegar a ser ligeramente más complicada cuando los datos que se van a exportar no existen en la tabla de hechos y, en su lugar, solo existen como cálculos en el cubo. ¿Cómo superar este escenario? La respuesta radica en usar consultas ad-hoc distribuidas en el cubo OLAP. Para obtener más información, vea Guía de modelado e informes de planeación para escenarios y soluciones de planeación de BI.

Seguridad y roles

La seguridad se debe definir en la base de datos de SSAS a través de los roles de seguridad. Para obtener un rendimiento óptimo, es mejor mantener la seguridad lo más sencilla posible.

El máximo nivel de seguridad es la seguridad de la base de datos y se recomienda que cada trabajador de la información que necesite acceso al modelo de datos disponga al menos del permiso 'Leer definición' en la base de datos.

El segundo nivel más amplio de seguridad se define en el cubo y controla si los cubos individuales son de solo lectura o de lectura y escritura, o si se impide el acceso a estos.

El siguiente nivel de seguridad se define en las dimensiones. Puede optar por permitir que determinados miembros de una dimensión estén visibles u ocultos. Es recomendable detenerse en la seguridad de dimensión para obtener un rendimiento óptimo de SQL Server Analysis Services.

Si se define la seguridad al nivel más bajo de acceso, sería en el nivel de celda. El rendimiento se verá afectado negativamente ya que la lógica de almacenamiento en caché estaría gravemente limitada en las consultas de cualquier usuario que tenga definida la seguridad de nivel de celda.

Puede crear roles de seguridad en la base de datos de SQL Server Analysis Services mediante Business Intelligence Development Studio (BIDS) de Microsoft SQL Server.

Es importante tener en cuenta que BIDS puede definir configuraciones altamente complejas en la seguridad y puede requerir más experiencia técnica en un administrador para la configuración y el mantenimiento. Sin embargo, puede ser una buena área para la personalización, donde la seguridad se puede definir en otro lugar, ya sea con una hoja de cálculo estructurada o una tabla vinculada de SharePoint que se pueda introducir en un módulo de traducción y, finalmente, actualice la seguridad de OLAP según sea necesario.

Seguridad compleja

La seguridad dinámica de SQL Server 2008 Analysis Services también se puede configurar en los casos en que los roles estándar de SQL Server Analysis Services no son suficientes para cubrir todas las relaciones complejas que existen. El escenario ocurre cuando:

Cada trabajador de la información necesita acceso a un conjunto específico de miembros de dimensión.
Existen pocas superposiciones en los requisitos de seguridad dimensional, es decir, hay muchas combinaciones únicas de miembros de dimensión asignadas a diferentes trabajadores de la información.

Share via