Archivo de la categoría: Data Warehouse y BBDDs

Data warehouse (repositorio de datos) y bases 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.

sap-businessobjects-bi-4-1-y-posteriores-idt-data-foundation-federation-layer

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.

Anuncios

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.

Recorrido de SAP BW hacia SAP HANA

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.

Cambios en los objetos de SAP BW 7.5

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).

Road map de SAP BW

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

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).

Particionamiento multinivel en SAP HANA Database

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).

Particionado de Tablas en SAP HANA (I) – Definiciones


En ocasiones, los problemas de rendimiento de muchos sistemas de información pasan por una falta de particionamiento de los datos o una mala adopción de esta técnica, SAP HANA no es una excepción, a pesar de los grandes recursos disponibles que puede tener la plataforma in-memory de SAP, está medida en ocasiones es necesaria.

A continuación, una breve relación de respuestas a preguntas frecuentes sobre este tema en SAP HANA:

Que es el Particionado de tablas de datos

  • El particionamiento significa que las tablas son divididas en sub-tablas denominadas particiones según un criterio específico.
  • Sólo es aplicable en tablas con almacenamiento columnar (column store), en tablas con almacenamiento en filas (row store) no soportan particionamiento.
  • El particionamiento es transparente para que las aplicaciones funcionen correctamente. Sin embargo la partición puede tener un impacto en el rendimiento, positivo o negativo, que pueden percibir los usuarios en la carga de los sistemas, depende de la estrategia implementada.

Cuando Particionar las tablas de datos

  • Por lo general, el particionado es muy útil en tablas de gran tamaño, por otro lado, debe tener presente que las tablas columnares no pueden superar los dos mil millones de registros.
  • Además del procesamiento paralelo, en un despliegue scale-out (escalabilidad horizontal, uso de más de un host), en consultas complejas, accediendo a particiones distribuidas en distintos nodos, se obtendría un alto rendimiento, más no en consultas simples.
  • Si las tablas tienes conjuntos de datos de uso frecuente, y otros conjuntos de menos uso, deberían ser particionados según este criterio (partition prune).
  • Si una región de datos sólo es actualizada y la otra no, los procesos de actualización serán más eficientes.

Uso de una vista de atributos de SAP HANA en SAP Data Services


SAP Data Services es algo más que una herramienta de ETL (Extract, Transform, Load) es una plataforma de tratamiento de datos con múltiples funciones y posibilidades, especialmente por las amplias alternativas de utilizar diversos tipos fuentes de datos. En un entono SAP HANA se acopla perfectamente, pudiendo ser el instrumento clave para mover los datos desde y hacia la base de datos de esta plataforma in-memory computing.

Una de las posibilidades que podemos tener en cuenta es el uso de Vistas de Atributos (Attibute View) de SAP HANA en Data Services como DataStore (objeto que define una conexión a una fuente de datos), el procedimiento es señalado en la nota de referencia.

Referencia: SAP Note 2009982

Las claves de la eficiencia de la tecnología columnar


Con la expresión “tecnología columnar” nos referimos a las técnicas de almacenamiento de los datos por columnas, característica incluida en las alternativas más actuales de base de datos como esel caso de SAP HANA Database y SAP Sybase IQ, propuesta de base de datos para fines analíticos y de data warehouse de SAP.

La mejor eficiencia que proporciona el almacenamiento por columnas en entornos analíticos, podríamos resumirlos en los siguientes aspectos:

  • Más rapidez. Las consultas analíticas se basan en el ordenamiento, agrupación, clasificación o elaboración de rankings de la información, para lo cual se accede a campos o columnas de datos. Las tablas basadas en el almacenamiento en columnas, además de contener los datos en esta estructura, cuentan con índices que señalan la ubicación de los valores en cada columna. Este hecho facilita la recuperación de los datos consultados, sin tener que acceder a toda las filas de datos de una tabla (tal como sucede en un esquema relacional). Finalmente, todo esto redunda en un menor consumo de CPU y en menores tiempos de respuesta.
  • Menor espacio. Con la tecnología columnar los valores similares en cada columna son sustituidos por claves más pequeñas que requieren menos espacio que el valor original.  Como resultado final, el almacenamiento de una tabla puede reducirse en una proporción entre 3x a 7x, aunque este ratio puede variar considerablemente dependiendo de los valores repetidos y del tipo de dato que se almacene.

La tecnología columnar no es mejor que la relacional, cada una tiene un mejor uso recomendable, ya sea en un entorno analítico o transaccional, respectivamente (aquí post relacionado)

Consideraciones básicas para el despliegue de “BW on HANA” (I)


Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

  • SAP no da soporte al despliegue de múltiples  sistemas SAP NW BW en un sistema productivo SAP HANA.
  • SAP brinda soporte al despliegue de múltiples sistemas SAP NW BW on HANA en arquitecturas de nodo único o multinodo con fines distintos a un entorno productivo, con una base de datos por cada sistema SAP NW BW.
  • El servidor de base de datos de un sistema BW es desplegado en un esquema de la base de datos SAP HANA.  La instancia central del sistema BW y todas las aplicaciones de servidor asociadas no se instalan en el appliance SAP HANA, son instalados en un servidor aparte.
  • Con respecto al párrafo anterior, existen “excepciones” señaladas en la nota 1661202 que permiten aplicaciones residan en el sistema SAP HANA en un entorno productivo.  Si una aplicación que no figura en el listado de excepciones es instalada en BW on HANA en un entorno productivo, esta aplicación no tendría soporte por parte de SAP.  En un entono distinto a producción si tendría soporte.
  • BW on HANA permite la aplicación de técnicas de alta disponibilidad (High Availability – HA) y tolerancia a fallos (Disaster Tolerance – DT).  En cuanto a HA sigue los mismos mecanismos que un sistema SAP HANA, a través de la activación de nodos pasivos. En general, especialmente en los casos de DT, estas técnicas pueden variar en función del proveedor de Hardware.
  • Las técnicas que se aplican en un sistema SAP HANA para evitar que los datos en memoria se pierdan ante un fallo en el servicio eléctrico también incluye los datos de BW on HANA.
  • Es recomendable tener por los menos tres nodos en un sistema SAP HANA en el que se despliegue BW on HANA. En el nodo principal estarían las tablas con almacenamiento basado en filas y en lo nodos esclavos se tendría las particiones de los infocubos y ODSs (Ref. nota 1702409).
  • Para información adicional y futuras novedades sobre los aspectos comentados en esta entrada revisar las notas 1666670 y 1661202.

Consideraciones para el despliegue de más de una base de datos SAP HANA


Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Hace unos días leíamos un listado de acrónimos y términos vinculados al mundo SAP HANA, una buena referencia, pero faltaría considerar otros como MCOS  que corresponden a las iniciales de “Multiple Components One System” que describen la arquitectura de múltiple nodo que se señala en el párrafo anterior.   Otro término que también se utiliza en el contexto SAP HANA es “Multi-SID” o MSID (Multiple Database on one SAP HANA appliance) que hace referencia a la posibilidad de configurar más de una base de datos en un sistema  SAP HANA.

Cabe recordar que en un entorno productivo HANA sólo tendrá soporte si tiene una única base de datos en el sistema (SIDS).  Es posible tener más de una base de datos HANA, pero sólo debería ser considerado en entornos que no son con fines de producción, tales como los clásicos entornos de pruebas o desarrollo.  Esta consideración se aplica tanto si se trata de una arquitectura de un nodo o multinodo.

SAP HANA - Deployment view

Un appliance HANA, recién entregada por  los partners de hardware, lo encontraremos con  una base de datos SAP HANA, usando  “On-Site Configuration tool” se podrá configurar una base de datos adicional, para lo cual deberá considerar lo siguiente:

  • No debería realizarse en un entorno productivo.
  • Se debería contar con la configuración de hardware necesaria para soportar el despliegue de más de una base de datos (especialmente en cuanto a memoria).
  • Se debe tener en cuenta que se puede perder rendimiento o velocidad en la ejecución de varios procesos.
  • Si hubiera problemas en el sistema y se solicitará el servicio de soporte de SAP, podría indicarse detener las bases de datos para comprobar si el problema es originado por la configuración de las bases de datos adicionales.
  • Para más información y futuras novedades revisar las notas 1681092 y 1661202.

Restricciones técnicas en objetos de SAP NW BW


Cuando comentamos las sugerencias de buenas prácticas o restricciones que se deben tener en cuenta al diseñar modelos en SAP Business Planning and Consolidation (SAP BPC especialmente en entornos NetWeaver), los usuarios técnicos, habituados al uso de SAP NW BW, no pueden evitar las comparaciones, afirmando en ocasiones que en entornos BW no existen limitaciones.  

Por supuesto que menos amplias que en SAP BPC, pero las restricciones técnicas también existen en entornos SAP NW BW, algunas de estas restricciones han sido recopiladas en la nota de referencia, tenerlas en cuenta ayudará en la eficiencia de los procesos.

Referencia: SAP Note 1837308 “FAQ: Technical limitations of Infoproviders and Characteristics in BW