Data Warehouse y BBDDs – aníbal goicochea

MS Power BI con fuentes SAP BW, también limitado por la conexión MDX

Actualmente, fabricantes tales como Tableau, Qlik (antes QlikView) o MicroStrategy utilizan la misma conexión MDX y señalan similares limitaciones que reconoce MS Power BI a través de su mecanismo de conexión denominado DirectQuery, utilizando tanto su conector SAP BW Versión 1 o como el mejorado, denominado Versión 2.

CONECTIVIDAD A LOS DATOS BW

SAP ofrece dos tipos de conexión a fuentes SAP BW y BW/4HANA para la recuperación de datos para soluciones de BI y Análisis, por un lado, tenemos la conexión BICS (Business Intelligence Consumer Services) y, por otro lado, tenemos la conexión vía MDX (MultiDimensional eXpressins – Lenguaje para base de datos multidimensionales).

BICS, es considerada la alternativa más eficiente por los tiempos de respuesta y por reflejar con mayor fiabilidad/exactitud los modelos de datos SAP BW, especialmente la diversidad de características, sus atributos, variables y jerarquías.

MDX es una consulta que es procesada por otro motor distinto a BICS, por una interfaz pública denominada OLAP BAPIs. El procesador MDX de esta interfaz, brinda un resultado de datos y metadatos que casi siempre difiere de la arquitectura de la fuente SAP BW consultada.

MDX, EL VERDUGO DE LAS SOLUCIONES BI «NO-SAP»

BICS es la conexión de uso exclusivo de los productos ABI (Analytics and Business Intelligence) de SAP. MDX es la conexión que utilizan las herramientas de BI de terceros fabricantes, incluyendo MS Power BI. En las primeras versiones de BusinessObjects (especialmente con Web Intelligence) integrada a SAP, la única alternativa de conexión a BW era MDX y el resultado era muy frustrante para los usuarios al consultar o analizar sus datos.

Actualmente, fabricantes tales como Tableau, Qlik (antes QlikView) o MicroStrategy utilizan la misma conexión MDX y señalan similares limitaciones que reconoce MS Power BI a través de su mecanismo de conexión denominado DirectQuery, utilizando tanto su conector SAP BW Versión 1 o como el mejorado, denominado Versión 2.

LIMITACIONES AL ACCEDER A DATOS BW CON MDX

Entre otras, MS Power BI reconoce las siguientes limitaciones:

Cálculo de agregaciones diferentes,
Imposibilidad de uso de atributos de características,
Ningún tratamiento de jerarquías con niveles desiguales o dependientes del tiempo (sólo se utiliza la vigente o última),
Criterios de ordenación (caso meses es alfabético),
Imposibilidad de tratar las variables de texto (caso uso como variables de sustitución)
Las estructuras de despliegan en su totalidad, por ejemplo, si se tiene dos ratios (Ventas y Coste) y una estructura con dos líneas (Real y Presupuesto) se obtendrían 4 ratios desplegados (Ventas Real, Ventas Presupuesto, Coste Real y Coste Presupuesto).
En cuanto al rendimiento, Microsoft también se ve afectado por el mecanismo MDX que está obligado a utilizar. Con la Versión 2 de su conector a SAP BW de MS Power BI ha agregado opciones tales modificar el tamaño del paquete de datos que se recupera por bloque, lo cual podría ayudar a reducir la latencia o tiempos de espera, pero modificar este parámetro por defecto, debe ser controlado/alineado con los recursos del sistema.

CONCLUSION

Las limitaciones reconocidas por Microsoft al conectarse MS Power BI con fuentes SAP BW, señala como “responsable” la API pública a través de MDX, la cual, visto lo que ha sucedido con otros fabricantes, difícilmente mejore. En cuanto al rendimiento, la solución pasa por limitar el número de características o dimensiones que se recuperen y en agregar más filtros/variables obligatorias para reducir el volumen de datos que se lee.

Microsoft sugiere importar los datos, opción que se debe valorar dependiendo de cada necesidad y conjunto de datos a utilizar, por ejemplo, volumen o frecuencia de variación de datos.

Federación de fuentes de datos en SAP BusinessObjects BI

Con el término “federación” (federation) en SAP BusinessObjects BI se hace referencia a la posibilidad de combinar conjuntos de datos de proveedores o bases de datos distintas, sin la necesidad de recurrir a un repositorio físico que los agrupe. La principal ventaja que obtendríamos es que accederíamos a la información más actualizada que almacenarían las fuentes de datos de nuestro interés.

Con el término “federación” (federation) en SAP BusinessObjects BI se hace referencia a la posibilidad de combinar conjuntos de datos de proveedores o bases de datos distintas, sin la necesidad de recurrir a un repositorio físico que los agrupe. La principal ventaja que obtendríamos es que accederíamos a la información más actualizada que almacenarían las fuentes de datos de nuestro interés.

A través del Information Design Tool (IDT, traducida como Herramienta de Diseño de Información), la aplicación cliente para crear universos, podemos definir diversas conexiones a fuentes de datos relacionales tales como Microsoft SQL Server, Oracle, IBM DB2, Sybase, Teradata, SAP BW (modo relacional), ficheros de texto, XML, Excel, entre otros. Definidas las conexiones relacionales las podemos agrupar en una capa de “infraestructura de datos multifuente” (multisource data foundation) para que se puedan acceder a ellas como si de una única fuente de datos se tratase.

En la denominada “Capa de Federación” (Federation Layer) del IDT, podemos definir los flujos de combinación de las tablas de las distintas fuentes que hemos seleccionado, para dar lugar a nuevas tablas lógicas, denominada tablas federadas, en estas combinaciones señalaremos los criterios y lógicas para este fin, haciendo uso de interfaz gráfica sin apenas necesidad de escribir código SQL, de manera similar a herramientas ETL (Extracción, Transformación y Carga de datos). Si fuese necesario escribir scripts SQL para la creación de una tabla federada, se deberá utilizar un SQL estándar, sin utilizar sentencias particulares que ofreciese cada fabricante de motores de bases de datos.

Debes tener presente que las infraestructuras multifuente para la federación de datos requieren más recursos del host de SAP BusinesObjects BI, los cuales son gestionados por el servicio “Data Federation”, incluido en el servidor Adaptive Processing Server (APS), el cual, como tarea de custumización o puesta a punto de la plataforma, debería estar en funcionamiento de manera aislada, con una asignación de 2 a 8 GB de memoria, según los volúmenes de datos que se acceda.

De «powered by SAP HANA» a «edition for SAP HANA»

La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.

La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.

Posteriormente hemos venido viendo soluciones “powered by SAP HANA” o simplemente “on SAP HANA”, caracterizadas por llevar, con mínimos cambios, los modelos de datos de las aplicaciones a SAP HANA y por consiguiente, el procesamiento de los datos es ejecutado en memoria obteniéndose importantes mejoras en los tiempos de respuesta.

El cambio más disruptivo que se está dando por SAP HANA es la irrupción de una nueva generación de aplicaciones, las denominadas “edition for SAP HANA”. La cual prescinde de todos los elementos u objetos que tuviese la aplicación original e impiden que sea más eficiente y veloz en SAP HANA. El primero y más relevante representante “edition for SAP HANA” es SAP BW 7.5, del cual destacamos los siguientes cambios:

La clásica interface SAP GUI del denominado Data Warehousing Worbench es sustituida por el denominado BW Modelling tolos in Eclipse.
Las funcionalidades o herramientas para el modelado BW han sido adaptadas en el entorno de modelado SAP HANA. Por el momento, hay algunos objetos que deben ser definidos en el Data Warehousing Workbench.
Algunos objetos ya no son soportados y serán sustituidos por uevos tipos de objetos especialmente diseñados para SAP HANA. En este enlace puedes ver estos cambios: aquí.
SAP Business Explorer (BEx) ya no será soportado nunca más (esto ya lo han dicho más de alguna vez. :-I). Las consultas o queries serán definidas con las herramientas de modelado BW de SAP HANA. Para la visualización de datos se recomienda el uso de Analysis for Office o Design Studio (o SAP BusinessObjects Lumira).

Particionado de Tablas en SAP HANA (y III) – Buenas Prácticas

A continuación señalamos algunas buenas prácticas (best practices) al definir particiones en SAP HANA Database. Cabe señalar que para los objetos BW on SAP HANA, la técnica de particionamiento es distinta (ver entradas anteriores: aquí y aquí):

Sólo aplicar el particionado de tablas cuando sea necesario y se observa un beneficio claro de esta técnica. Una alta cantidad de particiones innecesarias ocasionaría una sobrecarga en el sistema al ejecutar consultas, al tener que acceder a múltiples particiones para encontrar los datos solicitados.
Si se particiona por el límite de tamaño de tabla de los dos mil millones de registros, es aceptable si el tamaño de las particiones contienen hasta los 500 millones de registros.
Si el criterio de partición es por fecha, se debe evitar utilizar criterios granulares tales como día o semana, dado que generaría un gran número de particiones.
Si se utiliza el tipo de partición RANGE sobre una columna cuyo contenido no se distribuye uniformemente, se deben verificar la distribución de sus valores reales para definir los límites de los rangos en consecuencia
Utilizar el menor número de columnas para definir el criterio de particionamiento. En el caso del tipo de partición HASH, a menudo es útil emplear sólo la columna clave más selectiva, para que las solicitudes de datos que incluye esta columna sólo accedan a una partición.
Las buenas prácticas de los documentos de referencia, señalan que las particiones de una misma tabla estén contenidas en el mismo host si es que se cuenta con una estrategia scale-out (despliegue/escalabilidad horizontal)
Si se va a reparticionar una tabla, para lograr mayor eficiencia, elija un número múltiplo o divisor del número de particiones con respecto al actual.
Evitar la definición de particiones con restricciones únicas adicionales, por ejemplo índices secundarios, dado que las verificaciones posteriores significarían una sobrecarga importante.

Particionado de Tablas en SAP HANA (II) – Tipos de Partición

Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)
Tipos de particionamiento

Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)

Tipos de particionamiento

HASH. Los registros son asignados a particiones basados en un algoritmo hash, por lo que no se requiere un conocimiento profundo del contenido de la tabla (no hay una separación lógica de los datos). En la configuración de esta tipo de partición se debe indicar las columnas cuyos valores se utilizarán para determinar el valor hash. Si las tablas tienen columnas índices, estas deben ser utilizadas en este proceso. De fácil configuración, no requieren mantenimiento. Durante las consultas todas las particiones deben ser exploradas a menos que se indique explícitamente las particiones a consultar (parámetros “=” o “IN” de la cláusula “WHERE”).

ROUND-ROBIN. Se utiliza para lograr una distribución uniforme de los datos en las particiones, a diferencia del caso anterior, no es necesario especificar columnas para definir el criterio de este proceso. Los nuevos registros de van asignando rotativamente. Las tablas no deben tener claves primarias. Son de fáciles configuración, no requieren mantenimiento. En consultas, todas las particiones deben ser exploradas. No hay separación lógica de los datos.

RANGE. Los registros son asignados a particiones utilizando los rangos de particiones definidos. Es la única que define la asignación de particiones bajo un criterio lógico, en consecuencia, es la mejor vía para optimizar el acceso a los datos. Para una adecuada configuración, es necesario conocer los datos y sus aplicaciones. Es necesario un regular mantenimiento (p.e. para definir nuevas particiones o eliminar otras cuyos datos han sido archivados). Es necesario el uso de una clave principal. Sólo es aplicable para tipos de datos (cadenas, enteros y fechas).

Cualquier definición de partición utilizando uno de los métodos anteriores, dará lugar a un particionamiento simple (single-level partioning). Si cada partición es particionada nuevamente por otros criterios, estaríamos hablando un particionamiento multinivel (multi-level partitioning).