“Magic Quadrant for Business Intelligence and Analytics Platforms 2015″ – Parte I – Las Tendencias del BI


Ya contamos con la última edición del Cuadrante Mágico para Plataformas de Business Intelligence y Análisis 2015 de la consultora Gartner (Magic Quadrant for Business Intelligence and Analytics Platforms). Este informe es el mejor documento de referencia para definir una estrategia de Business Intelligence (BI) de una organización, o reconducirla.

Magic Quadrant for Business Intelligence and Analytics Platforms 2015 (Cuadrante Mágico para Plataformas de Business Intelligence y Análisis)

Vamos desgranar este informe en varias entradas, vamos a comenzar señalando las principales tendencias que Gartner identifica en el mundo del BI:

  • Más Análisis Avanzado. Las necesidades de reporntig operativo, omnipresente en todas las organizaciones está siendo cubierto por soluciones tradicionales, pero una cada vez más amplia gama de usuarios de negocio demandan soluciones que faciliten el análisis, con funcionalidades avanzadas e interactivas, fáciles de implementar y mantener.
  • Funciones básicas centralizadas, nuevas necesidades descentralizadas. Gartner estima que más de la mitad de las adquisiciones de soluciones que realizan los clientes en el sector del Business Intelligence corresponde a propuestas de análisis avanzado, exploración y descubrimiento, tendencia que corresponde a un modelo centralizado para implementar soluciones tradicionales y descentralizado para cubrir las nuevas necesidades de los usuario, dónde Tableau sigue dominando este sector, éxito difícilmente replicable por propuestas equivalentes de los clásicos fabricantes, como Lumira de SAP o Watson Analytics de IBM.
  • Interés por la nube. Con respecto al año anterior el interés por la nube o implementaciones cloud computing ha descendido, de 45% a 42%, lo cual se compone de 28% de los clientes encuestados que señala tener una implementación cloud BI y un 14% que tienen planificado hacerlo. La mayoría de los líderes ofrecen una alternativa cloud, pero no ofrecen mecanismos para integrarlas con las implementaciones clásicas on-premise (instalaciones locales).
  • Más aplicaciones analíticas. Las mejores capacidades gráficas y analíticas de las propuestas BI, aunadas al aumento de la facilidad de acceso a fuentes de datos multiestructura, de origen interno y externo, está dando lugar a nuevos tipos de análisis, tales como análisis de ubicación/geográficos o el análisis de emociones/sentimientos.

Cargas y descargas de datos en memoria en SAP HANA


Como ya sabemos, una de las claves del buen rendimiento de SAP HANA es tener los datos en memoria. Este proceso consiste en llevar las columnas de las tablas con almacenamiento columnar a la memoria, a la zona denominada SAP HANA Column Store Memory. Las tablas con almacenamiento basado en filas, son cargadas al iniciarse el sistema y permanecen en esta zona sin variación.

 Cuando las columnas se cargan en memoria, usualmente no se generan problemas, estos se pueden producir al descargarse. Las columnas se cargan en memoria en las siguientes situaciones:

  • Explícitamente accedidas. Cuando una columna es consultada, y si esta no se encuentra en memoria, esta es cargada. Exceptuando las columnas de tipo Hybrid LOB. El tiempo dedicado a las tareas de carga de datos a memoria pueden ser consultados (M_SQL_PLAN_CACHE).
  • Explícitamente cargadas. Vía la sentencia LOAD es posible cargar todas las columnas de todas las tablas o algunas columnas de ciertas tablas, entre otras especificaciones.
  •  Recargadas después del arranque (tablas explícitamente configuradas). A través de la sentencia ALTER TABLE <tabla> PRELOAD puede ser utilizada para definir las tablas que deben ser cargadas directamente después del arranque del sistema.
  • Recargadas después del arranque (basado en columnas previamente cargadas). A través de parametrización de ficheros del sistema (indeserver.ini) se puede establecer que se carguen al iniciar el sistema, las columnas que estaban cargadas antes de la parada previa del sistema.

 Las descarga de una columna se puede producir por los siguientes motivos (columna REASON de la vista M_CS_UNLOADS):

  • Descarga por poca memoria disponible (LOW MEMORY). SAP HANA automáticamente realiza descargas cuando la memoria escasea, esto puede ser muy crítico para el rendimiento del sistema. Esta situación se debe evitar, entre otras cosas, es posible parametrizar el tamaño máximo de los objetos que se deben mantener en memoria (indexserver.ini).
  • Explícitamente descargada. A través de la sentencia UNLOAD es posible descargar las tablas que se deseen.
  • Descarga de recurso no utilizado (UNUSED RESOURCE). Puede establecerse que automáticamente se descargan las columnas cuando exceden un período sin uso (global.ini).

Referencia: SAP Note 2127458

S4HANA, un producto 100% SAP HANA


S4HANA LogoS4HANA es la nueva generación de SAP Business Suite, es la evolución más importante del clásico conjunto de herramientas transaccionales de SAP. SAP Business Suite 4 SAP HANA no es un concepto totalmente nuevo, podríamos señalar que su predecesor inmediato es SAP Business Suite powered by SAP HANA (SoH o Suite on HANA), liberada a inicios de 2013, la diferencia es que S4HANA  estará construida de forma nativa sobre la plataforma SAP HANA, lo que conlleva a destacar los siguientes aspectos propios de este nuevo producto:

  • Código reescrito para aprovechar todo el potencial del procesamiento in-memory de SAP HANA.
  • Modelo de datos simplificado, dado que con SAP HANA resultan prescindibles tablas tales como agregados y subtotales.
  • Interfaz de usuario mejorada, pensada para la movilidad y basada en SAPUI5.
  • Complementario al aspecto anterior, simplificación de la conectividad con SAP Fiori.

Hay otros aspectos que se conocieron con Suite on HANA y que también estarán presentes en S4HANA:

  • Capacidad OLAP (analítica) y OLTP (transaccional) en un único sistema.
  • Plataforma lista para procesamientos Big Data.
  • Disponible en cloud (en la nube) y on-premise (infraestructura propia).
  • Reducción del costo de propiedad (TCO). A nuestro parecer, principalmente si se opta por una edición Cloud.
  • Disponibilidad de RDS (Rapid Deployment Solutions) con distintas configuraciones.

S4HANA Presentacion 03

Por lo visto, S4HANA será uno de los principales protagonista en los próximos años en el mundo SAP. Entre los argumentos del marketing que rodean a este nuevo producto se señala que la “S” de S4 corresponde a “Suite” y a la “Simplicidad” de adopción y configuración que tendrá. En cuanto al “4”, correspondería a la diferenciación de una nueva generación de productos.

Otros aspectos que se señalan sobre S4HANA son los siguientes:

  • Tendrá a SAP Lumira como herramienta de visualización por defecto.
  • Habría la posibilidad de utilizar las “Guided Configuration”, para facilitar la adopción e implementación.
  • Los primeros módulos que se ofrecerán serán del área financiera (SimpleFinance o sFinance).
  • El soporte de las suites actuales sería hasta 2025.

Para SAP,  queda claro que la movilidad, la nube y la capacidad de análisis será una característica esperada en cualquiera de sus nuevas aplicaciones de negocios, pero sólo para las organizaciones que adopten SAP HANA como plataforma y base de datos.

Los “Delta Merges” de SAP HANA


Operaciones de escritura y lectura con los Delta Storage de SAP HANA en una tabla con almacenamiento basado en columnasLas actualizaciones de las tablas con almacenamiento columnar de SAP HANA a través de sentencias tales como INSERT, UPDATE o DELETE no son inmediatamente volcadas a la base de datos, estos cambios son guardados en una zona, a la que podríamos calificar como intermedia, denominada “Delta Storage”. Estos datos serán actualizados en la base de datos (Main Storage) a través de un proceso denominado “Delta Merge” el cual se ejecuta en determinados períodos de tiempo.

Antes, durante y luego de la ejecución de un proceso Delta Merge

Este mecanismo resulta imperceptible para el usuario que explote o consulte la información, porque las operaciones de lectura tomarán en cuenta tanto los datos del almacenamiento principal como del Delta Storage. SAP HANA utiliza esta técnica para disminuir el acceso a disco y evitar la pérdida de rendimiento.

Modalidades en que un Delta Merge puede ser desencadenado

Las operaciones de Delta Merge se ejecutan en segundo plano, de manera automática o manual, forzada o condicionada. Información sobre cómo configurar, monitorizar y más información técnica sobre los Delta Merge puede encontrarse en la nota SAP 2057046.

SAP vuelve a cambiar nombres, esta vez en BPC 10.1


Podríamos señalar que el cambio de nombres a los productos y/o a los componentes que lo conforman, es el paso inevitable por el que transcurre la gran mayoría de productos SAP hacia su maduración. Esta vez, le ha tocado al recientemente estrenado SAP Business Planning and Consolidation 10.1 para NetWeaver.

Ventana de Gestión de Environments en el nuevo BPC 10.1 SP2 (Clásico o Estándar) - Opción Create estaría habilitada en una instalación Unified o Embedded

Tal como ya hemos comentado en alguna ocasión, en BPC 10.1 NW es posible crear entornos similares a los que conoces en la versión 10.0, a los que SAP nos enseñó, inicialmente, denominar como Clásicos (Classic). Por otro lado, en instalaciones de BPC 10.1 sobre SAP HANA, tenemos la posibilidad de crear estructuras para modelos de planificación que obtengan el máximo beneficio de la plataforma in-memory de SAP, esta otra categoría SAP nos indicó que se denominaba Unificado (Unified).

Pues bien, a través de la nota 2117885, SAP nos comunica que a partir del Support Package 3 (SP3) de BPC 10.1 NW, todo lo que conocíamos cómo Classic pasa a denominarse Standard  y todo lo que conocíamos cómo Unified, ahora se denomina Embedded.

Alternativas Cloud para SAP BusinessObjects BI


Lo más usual para implementar una plataforma SAP BusinessObjects Business Intelligence es utilizando una infraestructura propia, modalidad usualmente denominada on-premise. Pero la alternativa Cloud o en la nube va ganando mayor aceptación en casos como en una plataforma SAP BusinessObjects BI, en la que las necesidades de recursos de hardware, especialmente memoria, pueden fluctuar en el tiempo.

En la actualidad SAP brinda soporte a la instalación de SAP BO BI sobre Amazon Web Services (AWS) y en SAP HANA Enterprise Cloud, en este último caso es desplegado y gestionado por SAP. Para la propuesta cloud de Microsoft, MS Azure, por el momento no se brinda soporte, pero hay planes futuros de incluirla en esta lista (para más información consulta la nota 2106331.

AWS ofrece servicios de infraestructura que pueden ser utilizados para el despliegue de productos de SAP. En la nota 1656099 se describe los productos de SAP, combinaciones de bases de datos/sistemas operativos y los tipos de instancia AWS EC2 compatibles y soportados actualmente.

Verdades a medias sobre SAP HANA (y Parte III)


Continuamos con la última entrega de esta serie (Parte I, Parte II) sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA (más información en el documento de referencia):

  • En escenarios de escalabilidad horizontal (scale-out) las tablas con almacenamiento columnar no se almacenan en el nodo principal (master node). Es usual que varias tablas con almacenamiento en columnas se encuentren en el nodo principal en un escenario de escalabilidad horizontal. Pero es importante que las tablas de gran tamaño y/o críticas sean movidas a los nodos auxiliares o esclavos (slave nodes). Por ejemplo, en un entorno BW, infocubos, DSOs y PSAs deberían ser movidos a nodos esclavos.
  • En un escenario de escalabilidad horizontal el almacenamiento en filas es sólo en el nodo principal. Esta afirmación es correcta desde una perspectiva de aplicaciones, pero sin embargo, los nodos esclavos tendrán una mínima implementación técnica de tablas con almacenamiento en filas.
  • La sentencia UPDATE es siempre aplicable a operaciones DML (Data Manipulation Language). Esta afirmación no es siempre cierta. SAP HANA utiliza sentencias UPDATE también en operaciones DDL (Data Definition Language). Por ejemplo, la sentencia UPDATE para optimizar la compresión del almacenamiento columnar.
  • El motor Join (Join Engine) sólo procesa sentencias join. Esta afirmación es incorrecta. El motor join (ver aquí entrada sobre los motores SAP HANA) también es utilizado por ciertas consultas sobre una única tabla que realiza agregaciones o se utiliza la cláusula GROUP BY.

Referencia: SAP Note 2100010

Verdades a medias sobre SAP HANA (Parte II)


Continuamos con la entrada anterior, sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA:

  • SAP HANA es una base de datos en memoria pura. SAP HANA es una base de datos en memoria, sin embargo, hay una serie de operaciones de lectura y escritura en disco que tienen impacto en el rendimiento global del sistema, tales como:
    • Carga de tablas con almacenamiento en filas al iniciar el sistema
    • Carga de columnas
    • Acceso LOB (Large Objects)
    • Ejecución de savepoints y snapshots
    • Volcados a base de datos (commits)
    • Copias de seguridad (backups)
  • Todas las tablas están permanentemente en memoria. No todas las tablas SAP HANA están permanentemente y completamente en memoria. Se debe tener presente lo siguiente:

    • Las tablas con almacenamiento en filas y las columnas LOB no son cargadas en memoria.
    • Las tablas con almacenamiento columnar no son cargas sino son utilizadas o son descargadas por problemas de memoria.
    • Así mismo, la información histórica que muy rara vez se accede, no debería ser cargada en memoria
  • Las funcionalidades de almacenamiento en filas y almacenamiento en columnas están apartadas. Tradicionalmente estas dos técnicas o funcionalidades provienen de tipos distintos de bases de datos, pero en SAP HANA han sido integradas, por lo que ambos tipos de almacenamiento pueden ser combinados para procesar la información.

Verdades a medias sobre SAP HANA (Parte I)


Cuando algo nuevo surge en el mundo de tecnología el desconocimiento se hace presente en forma de mitos, verdades a medias o conceptos erróneos. En el ámbito de SAP HANA esta situación ya se está produciendo, por ello SAP ofrece una breve aclaración de los conceptos que se están tergiversando.

A continuación señalamos los siguientes conceptos o afirmaciones erróneas:

  • Todas las tablas de datos de SAP HANA se procesan con almacenamiento columnar (column-oriented). SAP HANA permite, tanto, tablas con almacenamiento en filas como en columnas. Las tablas con almacenamiento en filas son accedidas del mismo modo que las bases de datos relacionales tradicionales. Basándose en la experiencia y en el conocimiento, se puede decidir, de manera individualizada, que tipo de almacenamiento debe tener cada tabla para obtener el mejor rendimiento.
  • El almacenamiento en columnas ofrece mejor rendimiento que el almacenamiento en filas. En algunos casos es así, por ello, SAP tiende al mayor uso posible de tablas con almacenamiento en columnas, pero sin embargo, hay algunos casos en que el almacenamiento basado en filas ofrece un mayor rendimiento. (aquí tips a tener en cuenta).
  • Los índices no son necesarios. SAP HANA puede analizar grandes cantidades de datos, incluso sin la existencia de índices. Sin embargo hay situaciones en las que los índices son útiles, por ejemplo si se requiere realizar un acceso selectivo en repetidas ocasiones (para un entorno Business Suite on HANA, sugerimos la nota 1794297).
  • Los índices no se conservan en el disco. Los índices conformados por más de una columna de las tablas con almacenamiento columnar, son generalmente almacenados en disco. Los índices conformados por sólo una columna, son considerados como parte de la definición o estructura de la columna, no son almacenados en disco, se recrean automáticamente cuando la columna es cargada. Los índices de las tablas con almacenamiento en filas no se almacenan en disco, se crean cada vez que el sistema se pone en marcha.

Los Savepoints de SAP HANA


La principal técnica que utiliza SAP HANA Database para ofrecer un inmediato acceso a la información es manteniendo los datos en memoria, si la información fuese actualizada, estos cambios se reflejarían tanto en la memoria como en disco, es en este punto que interviene el concepto de Savepoints (aquí más información).

Los datos que se cargan a memoria son agrupados en “páginas”, todas las páginas que fuesen modificadas en un período de tiempo determinado, son volcadas a disco en los denominados Savepoints (el cual podríamos traducir como “puntos de sincronización” o “puntos de salvaguarda”).

Es una instalación del tipo “scale-out” conformada por más de un host, se debe tener en cuenta que cada host gestionará sus propios Savepoints.

La disponibilidad de un savepoint reciente conllevará a un reinicio del sistema más rápido porque habrá menos logs que procesar. Un Savepoin es desencadenado por las siguientes vías:

  • Intervalo predefinido. La parametrización por defecto establece que automáticamente habrá un punto de salvaguarda cada 5 minutos (global.ini >> [persistence] >> savepoint_interval_s = 300).
  • Comando del sistema. Puede utilizarse una sentencia en SAP HANA Studio para ejecutar un savepoint manualmente (ALTER SYSTEM SAVEPOINT)
  • Cierre del sistema del tipo Soft. Un “soft shutdown” ejecuta un savepoint antes de detener los servicios. Un “hard shutdown” no realiza un savepoint, lo que incrementaría el tiempo de reinicio del sistema.
  • Después de iniciar el sistema. Finalizado el reinicio del sistema, se realiza un savepoint.
  • Snapshots. Las instantáneas conllevan un savepoint que no se ven afectados por siguientes savepoints.