Archivo de la categoría: In-memory computing

Tecnología de procesamiento en memoria

Aspectos claves de SAP BW/4HANA


SAP BW/4HANA es la, relativamente, nueva solución de data warehouse (liberado el 7 de septiembre 2016), a la que SAP dedicará sus mejores esfuerzos en el futuro. El fabricante señala que BW 4HANA no es el sucesor de soluciones actuales similares tales SAP BW o SAP BW powered by HANA o BW edition for HANA, dado que es una solución completamente construida sobre SAP HANA, la cual introduce nuevos objetos y descarta otros, inclusive cuenta con un nuevo Business Content.

BW 4/HANA introduce, a través de nuevas interfaces de usuario, una nueva gama de objetos para el modelado de datos que cubran necesidades tales como acceso en tiempo real a grandes volúmenes de información.

¿Qué pasará con las actuales soluciones BW de SAP?

La solución clásica de SAP NW BW o las más recientes, basadas en HANA, denominadas con los sufijos ON HANA o powered by HANA entrarán en fase de mantenimiento, con innovaciones mínimas, las más relevantes innovaciones se darán en BW/4HANA, solución que será independiente de la plataforma SAP NetWeaver.

¿Qué relación tiene BW/4HANA  con S/4HANA?

El término “/4” puede inducir a creer que existe una relación entre ambos productos, pues esto no es así, se trata de dos productos totalmente independientes uno del otro.  Tampoco se solapan, dado que la filosofía, ámbito y alcance de ambas plataformas es distinta. S/4 HANA es una plataforma transaccional que brinda la posibilidad de obtener informes operativos de los datos actuales de una única aplicación SAP.

BW/4HANA es una plataforma data warehouse que permite consolidar información actual e histórica, de diversas fuentes, SAP y no SAP, con el fin de facilitar su explotación.

¿SAP BW/4HANA con qué  herramientas analíticas es compatible?

SAP asegura compatibilidad SAP Digital Boardroom y SAP BusinessObjects Cloud. Así mismo asegura compatibilidad con la plataforma SAP BusinessObjects BI Enterprise la cual incluye a Lumira, Design Studio, Analysis for Office, Web Intelligence y Crystal Reports.

En cuanto a la plataforma BEx (Business Explorer), una vez más, parece que esta vez será así, SAP asegura que no será soportado. Las querys BEx seguirán siendo compatibles pero se deberá utilizar la herramienta SAP BW/4HANA Modeling Tools para mantenerlas.

Comentario final

Sí, la “vorágine innovadora” de SAP conlleva a que nuevas implementaciones sean obsoletas desde el momento en que se planifican. Pero resulta elevadamente arriesgado adoptar una plataforma con tan poco recorrido, cuyas mejoras e innovaciones se encuentran en curso, los mecanismos de migración son artesanales y la compatibilidad o equivalencia entre objetos, tal como señala el fabricante, es mínima.

Pero este riesgo, que en algunos casos se deberá asumir, tanto para nuevas implementaciones como implementaciones existentes que requieren una actualización, debe ser gestionado definiendo fases con criterio funcional, identificando con claridad la arquitectura de datos crítica en cada momento, determinando los elementos técnicos de BW4/HANA disponibles que requiere el modelo de datos identificado y minimizando desarrollos personalizados, dado lo que pueda faltar hoy, puede ser posteriormente agregado por el fabricante, por ejemplo,  el denominado Business Content Optimizado recientemente ha agregado definiciones para FI, CO, MM y SD.

Los cambios qué hay que tener en cuenta al adoptar SAP S/4 HANA


Tal como señala el fabricante, SAP S/4 HANA no es el sucesor de SAP Business Suite, S4 sigue los principios funcionales del conocido ERP, con las características estándares para los negocios, pero se erige sobre la arquitectura de datos in-memory de SAP HANA Database y la filosofía de interfaz de usuario de SAP Fiori. Estas dos nuevas tecnologías de SAP, las más disruptivas, conllevan cambios técnicos que se deben tener en cuenta al considerar la adopción de SAP S/4 HANA.

simplification-list-for-sap-s-4hana-on-premise-edition-1511

Muestra del documento de referencia

Muchas organizaciones cuentan con desarrollos a medida que utilizan una serie de estructuras de datos que quizás, por la simplificación de la nueva arquitectura de S/4, ya no existan o podrían estar considerablemente modificadas. SAP ha intentado agrupar, en un documento, la relación de estos cambios, en el denominado “Simplification List for SAP S/4HANA“, el cual consideramos de obligada lectura si se está considerando o planificando la implementación de SAP S/4 HANA.

Referencia: Simplification List for SAP S/4HANA (en sitio oficial o aquí)

Objetivos de un proyecto basado en SAP BPC 10.1 con modelos Embedded


Cuando hablamos de modelos SAP BPC 10.1 embedded, unificado o integrado, estamos refiriéndonos a la versión  de SAP BusinessObjects Planning and Consolidation 10.1 para SAP NetWeaver sobre la plataforma SAP HANA.   Al margen de matices o estilos para decir las cosas, consideramos que los objetivos que se planteen en un proyecto basado en modelos embebidos de SAP BPC 10.1 deben girar en torno a las siguientes aspiraciones:

  • Optimizar el uso de estructuras de datos. En versiones previas de SAP BPC, en muchas ocasiones, es inevitable tener replicada la misma información hasta en tres o más fuentes de datos (por ejemplo, los datos maestros en el ERP, BW y BPC). La filosofía 10.1 permite tener una única estructura en la capa BW-BPC, facilitando el modelado, permitiendo la reutilización de estructuras para nuevas soluciones, disminuyendo así, los costes de mantenimiento y desarrollos futuros.
  • Maximizar el uso de la potencia de cálculo de HANA. El anterior objetivo seguro que sería imperceptible para el usuario de negocio o usuario final. A través de la potencia de cálculo de la base de datos in-memory SAP HANA podemos implementar soluciones con funcionalidades, hasta ahora postergadas por los lentos tiempos de respuesta que se obtienen en las plataformas tradicionales, tales como los procesos online.  En modelos BPC Embedded se debe tratar que la gran mayoría de los cálculos se ejecuten en la capa de datos, en otras palabras, SAP HANA no tan sólo es el repositorio de datos de los modelos embebidos, sino también el motor que los procesa.  

el-fin-de-un-motor-de-base-de-datos-in-memory-computing-que-la-gran-parte-de-los-procesos-de-calculo-no-se-realicen-en-la-capa-de-aplicacion

Teniendo objetivos claros en el horizonte para este tipo de proyectos, se contribuirá a que la organización obtenga más beneficios de  una inversión tan importante como es SAP HANA.

Mejoras importantes para la conectividad SAP HANA en WebI de SAP BusinessObjects BI 4.2


La actualización 4.2 y posteriores de la plataforma SAP BusinessObjects BI introduce dos características que podrían potenciar, aún más, el uso de SAP HANA como fuente de datos en los informes de Web Intelligence, para lo cual, es necesario contar con un nivel de actualización posterior a la SPS08 de la plataforma in-memory (Ref.  SAP Note: 2210945). Nos referimos a las nuevas funcionalidades “Web Intelligence HANA Direct Access” (Acceso directo SAP HANA)  y “Web Intelligence HANA Online” (Modo con conexión SAP HANA).

Web Intelligence de SAP BusniessObjects BI 4.2 - Conectividad

Acceso directo SAP HANA en WebI

  • Consiste en acceder directamente a vistas calculadas o analíticas de SAP HANA Database a través de un universo temporal  (transient universe).
  • Este “universo temporal” se podría construir al vuelo desde la interfaz de Web Intelligence (versiones JAVA, HTML o Rich client) al seleccionar como fuente de datos una conexión relacional u OLAP a HANA, conexiones publicadas en el repositorio de la plataforma (conexión segura), la cual podría definirse desde la CMC o desde Information Design Tool (IDT).
  • Dependiendo el tipo de conexión, relacional u OLAP, se generarán unos objetos u otros. Este universo temporal no es reutilizable.
  • Lo bueno: facilidad y rapidez para utilizar modelos de datos existentes en HANA. Lo malo: La imposibilidad de reutilizar los universos temporales que se definan.

Conexión online SAP HANA en WebI

  • Con la nueva opción SAP HANA Online (o SAP HANA Conectado) es posible conectarnos, a través de una conexión relacional, a vistas analíticas o calculadas de SAP HANA para delegar los cálculos y agregaciones a la base de datos de HANA.
  • Al perder algunas funcionalidades de la interfaz de WebI, hay la posibilidad de pasar al modo clásico, pero no habría la posibilidad de volver al modo conectado.
  • Si se accede a un importante volumen de datos o se realizan varios cálculos y agregaciones en las consultas de un informe contra fuentes HANA, esta nueva característica será muy útil.

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

Gestión de la carga de trabajo de SAP HANA (o Workload Management)


SAP HANA puede gestionar los siguientes tipos de carga de trabajo (Workload):

  • OLAP Workload: Por ejemplo, reporting sobre BW.
  • OLTP Workload: Por ejemplo, transacciones de un sistema ERP.
  • Workload mixto: Combinan los dos tipos de carga de trabajo anteriores, OLAP y OLTP, el cual se puede dar en sistemas transaccionales con funciones analíticas.
  • Workload interno: Generado por operaciones internas de SAP HANA, tales como backups, puntos de salvaguarda (savepoints).

Toda gestión de recursos tiene como finalidad controlar su consumo, los cuales suelen ser limitados y de valor crítico, evitando cuellos de botella o contratiempos mayores. Para el caso de SAP HANA, esta gestión se centra en la memoria, CPU y la Red (ancho de banda y latencia).

Para la gestión de la carga de trabajo de la memoria se puede configurar, entre otros, los siguientes aspectos:

  • Limitar el consumo de memoria para todas las sentencias SQL (desde la actualización SPS 08). Se debe tener en cuenta que la especificación es por host, si se señala un tope de 100 GB, y se tiene un escenario de escalabilidad horizontal (scale-out), los 100 GB se multiplicarán por el número de host que tuviese la instalación.
  • Limitar el consumo de memoria para sentencias SQL para un usuario en particular (a partir de la actualización SPS 09).
  • Establecer un consumo máximo de memoria por clase de carga de trabajo (a partir de la actualización SPS 10).

Ante un consumo elevado de CPU o los hilos de procesamiento (threads) activos, se sugiere, en primer lugar, realizar un análisis de rendimiento u optimización de los procesos que lo estuviesen provocando.  Adicionalmente se pueden establecer los siguientes límites.

  • Establecer un número máximo de hilos de procesamiento (threads). Si se superase este límite, el proceso generaría error.
  • Tiempo de espera en microsegundos antes de iniciar un nuevo proceso cuando se alcanza el límite máximo establecido.
  • Número de máximo de procesos concurrentes y otros parámetros que regulan el procesamiento paralelo.

En cuanto a la carga de trabajo de la red, si existiesen problemas debido a la latencia o ancho de banda, estos usualmente se resuelven optimizando la infraestructura de red. SAP HANA ofrece alertas y otros recursos para monitorizar el tráfico de la red, y algunos parámetros para determinar el comportamiento de los elementos que conforman una plataforma HANA (ver nota 2222200), pero que no serán tan gravitantes como puede ser una administración y monitorización de la red, ajena a HANA.

Referencia: SAP Note 2222250

Los LOBs Hibridos de SAP HANA Database


Como veíamos en la entrada anterior, con los tipos de datos LOB de SAP HANA es posible almacenar datos de gran tamaño, tales como documentos, imágenes o videos. Ahora bien, pero toda esta información dentro de una estructura de tablas de la base de datos podría significar un gran consumo de recursos de manera innecesaria.  Desde la actualización SPS 07 de SAP HANA están disponibles los denominados LOBs híbridos, los cuales estarán en memoria sólo cuando son utilizados.

Con los LOB híbridos se puede almacenar datos LOB en el disco hasta que se necesite en lugar de tener que cargarlos en la memoria. Esto influye en el consumo de recursos, por lo tanto afecta a la puesta en marcha del sistema y los tiempos de respuesta. SAP HANA puede almacenar objetos binarios grandes (LOB) en el disco y no dentro de estructuras de columnas o filas de la memoria principal.

Los LOB híbridos residen primero en el disco y se hace referencia a este contenido únicamente por un ID en la columna de la tabla correspondiente. Si hay escasez de memoria, los datos LOB pueden ser descargados desde la memoria principal. A través de unos parámetros del sistema se puede determinar que los datos LOBs pequeños (por defecto, menos de 1.000 bytes) se mantengan en memoria, mientras que los de tamaño superior se mantengan en el disco.

Los cambios que introdujo la actualización SPS 07 de SAP HANA Database sobre los datos LOBs, derivó a que se introdujeran los términos  LOBs de memoria (el mecanismo inicial) y LOBs Híbridos (o LOBS de disco). SAP HANA ofrece un conjunto de sentencias SQL que permiten la parametrización, creación y gestión de estos tipos de datos.

Almacenamiento de gran tamaño en SAP HANA: Campos LOBs


Si estas necesitando almacenar contenidos de gran tamaño, tales como documentos o imágenes en una plataforma SAP HANA Database, debes pensar en los tipos de datos LObs (Large Objetcs), especialmente diseñados para este fin. Existen los siguientes tipos:

  • BLOB: Datos binarios. Por ejemplo, imágenes. Para tablas con almacenamiento por filas y columnas.
  • CLOB: Texto ASCII. Para tablas con almacenamiento por filas y columnas.
  • NCLOB: Texto UNICODE. Para tablas con almacenamiento por filas y columnas.
  • TEXT: Texto con características adicionales de búsqueda. Sólo para tablas columnares. Muchas funciones de cadenas no son aplicables a este tipo de dato.
  • BINTEXT: Texto y datos binarios con características adicionales de búsqueda. Con similares restricciones al tipo TEXT.  La definición de este tipo de dato genera una columna de tipo NCLOB.
  • Nota: El tipo de dato VARBINARY, a pesar que puede almacenar hasta 5.000 bytes no es considerado un tipo LOB, por lo que se carga en memoria cuando se acceda sin ninguna restricción como las que se podrían aplicar con los LOBs híbridos, señalados en próxima entrada.

Restricciones de los tipos de datos LObs

  • Un campo de un tipo LOB sólo puede tener un máximo de 2 GB. Hay alertas que permiten controlar esta situación (Check ID 450 – Tables with memory LOBs > 2 GB).
  • Una columna LOB no puede ser utilizada con la cláusula ORDER BY, GROUP BY, SLECT DISTINC, SELECT con funciones de agregación, FROM como operando en joins.
  • Una columna LOB no puede ser clave primaria

Tratamientos de cadena soportados

  • LENGTH para los tipos CLOB, NCLOB y BLOB. Retorna el tamaño de campo LOB en bytes.
  • SUBSTR para los tipos CLOB y NCLOB. Retorna una subcadena del campo LOB.
  • Las clausulas LIKE y CONTAINS para los tipos CLOB y NCLOB.
  • Cláusula IS NUL sólo para los tipos CLOB, NCLOB y BLOB.

Nota: Ver siguiente entrada sobre LOBs híbridos.

Referencia: SAP Note 2220627

Terminología sobre Correcciones y Mejoras en SAP HANA


En cuanto a las correcciones y mejoras que pueden liberarse en SAP HANA, existe una terminología similar a otras plataformas de SAP, quizás con ciertos matices que tratamos de aclarar a continuación:

  • Revisions. Se trata de correcciones para los componentes centrales o core tales como SAP HANA Database, Clientes, Application Fuction Library o SDA).
  • Support Packages (SP). Incluye correcciones o mejoras de todos los demás componentes de SAP HANA, que no cubre una revisión.
  • Support Package Stack (SPS). Se trata de nuevas capacidades o funcionalidades, las cuales tienen una ferecuencia de dos vesces al año. Incluyen las revisiones o SP previos.

La numeración de las SPS y revisiones están alineadas para facilitar su identificación. Por ejemplo, la revisión 90 se refiere a la primera revisión del SPS 09.

Revisiones, SP y SPS de SAP HANA

Revisando el Roadmap sobre IoT de SAP


Al igual que sucedió con el cloud o el Big Data, los líderes en tecnología están incluyendo el Internet of Things (IoT) en sus propuestas. Son muy optimistas las expectativas de adopción de esta tecnología, que prevén consultoras como Gartner, y que no dejan indiferentes ni a SAP, que en el pasado fue más cauto con otras tecnologías.

Revisando una de las primeras versiones del roadmap sobre IoT que ha publicado SAP el 29 de septiembre de 2015, resulta, por lo menos, complejo de comprenderlo. Como es lógico, este “mapa de ruta” gira alrededor de su plataforma SAP HANA y a las capacidades predictivas que SAP ha ido desarrollando (o adquiriendo) en los últimos años y ha incorporado en su base de datos in-memory y en otros productos.

Visión de integración de dispositivos y procesos según SAP

Salvo mejor parecer, la confusión viene dada porque en un solo documento se ha querido plasmar las posibilidades instalación de la plataforma, toda la gama de posibilidades de interconexión con otros productos y las posibilidades analíticas que se podrían explotar para la implementación de una solución basada en IoT.

SAP Internet of Things - roadmap

Quizás pretendemos ser muy simplistas, pero en IoT para SAP, por un lado señalaríamos la capacidad de cálculo en-memoria de HANA, lo que facilita el procesamiento de grandes volúmenes de datos, y por otro lado, una herramienta como SAP HANA Smart Data Streaming, una de las herramientas señaladas en el roadmap de IoT de SAP.

SAP HANA Smart Data Streaming

SAP HANA Smart Data Streaming (lo abreviaremos como SDS on HANA) fue presentada en la actualización SPS 09 de HANA como una herramienta para capturar datos de manera continuada proveniente de dispositivos y aplicaciones, procesarlos en tiempo real con los siguientes fines:

  • Detectar tendencias y patrones,
  • Identificar valores y monitorizar correlaciones,
  • Generar alertas y notificaciones
  • Actualizar en tiempo real tableros (dashboards operacionales),
  • Formular respuestas a preguntas básicas
  • Agregar y resumir los datos.

SDS on HANA cuanta con varias alternativas de conectividad a varias fuentes de datos. Los datos recibidos son tratados de acuerdo a consultas y reglas (business logic) que brindan la salida deseada que son encaminadas de acuerdo a adaptadores de salida.

Arquitectura de SAP HANA Smart Data Streaming

SDS on HANA incluye varios componentes, entre ellos un plugin para SAP HANA Studio (para los desarrolladores), así como soporte a Continuous Computation Language (CCL) para la aplicación de funcionalidades complejas como agrupamiento y agrupamiento de datos.

Referencia: Roadmap sobre IoT de SAP (o aquí)