SAP HANA a prueba para BI

SAP ha publicado los resultados de una prueba del rendimiento de SAP HANA para necesidades de Business Intelligence. Para lo cual definió un escenario de ventas con cinco años de transacciones que equivalían a 100 TB de información (aplicando una compresión de 20X, en base de datos ocupó 3,78 TB).


SAP ha publicado los resultados de una prueba del rendimiento de SAP HANA para necesidades de Business Intelligence.  Para lo cual definió un escenario de ventas con cinco años de transacciones que equivalían a 100 TB de información (aplicando una compresión de 20X, en base de datos ocupó 3,78 TB).

Para este entorno de pruebas se configuró unas características de hardware detalladas en informe adjunto y se definieron una serie de consultas SQL que equivalen a las consultas que se generan en un entorno de BI.

La conclusión más relevante es que el acceso a los cien mil millones de filas (100.000.000.000) consumieron entre uno y dos segundos para el caso de los informes con opciones de drill-down (profundizar o detallar la información) y hasta un promedio de 3,8 segundos para las consultas de tipo analíticas, las cuales implican mayor complejidad al incluir combinación de tablas y comparaciones de períodos.  Estos tiempos de acceso es lo que algunos llaman “Real-time BI”.

Referencias: (informe)

Productos SAP BusinessObjects con «fecha de caducidad»

SAP ha publicado las fechas de «End of Life» de una serie de productos SAP BusinessObjects (Crystal Reports incluidos), estas fechas indican la culminación del soporte de mantenimiento y mejoras de este software. En algunos casos se trata de versiones muy antiguas para las cuales ya existen una o dos versiones por encima.


SAP ha publicado las fechas de «End of Life» de una serie de productos SAP BusinessObjects (Crystal Reports incluidos), estas fechas indican la culminación del soporte de mantenimiento y mejoras de este software.  En algunos casos se trata de versiones muy antiguas para las cuales ya existen una o dos versiones por encima.

Quizás pueda extrañar la inclusión de SAP BusinessObjects Dashboard 4.0 (Xcelsius) en esta lista, esto no significa que desaparecerá esta herramienta, entendemos que para esta fecha, 30 de junio de 2013, ya se habrá publicado una nueva versión con posibilidades HTML5, la cual coexistirá con SAP Zen (nombre en fase de desarrollo) como propuestas para el diseño de cuadros de mando.

Con respecto a la presencia de Crystal Reports 2011 en esta lista, entendemos es porque Crystal Reports y Xcelsius tienen una estrategia de mantenimiento común.   La amplia comunidad de usuarios que tienen estas dos herramientas garantizan su continuidad.

Referencia: SAP SDN

Vías para estimar las necesidades de hardware (Sizing)

Hemos escrito un par entradas sobre Sizing basada en SAP Quick Sizer (aquí y aquí), pero esta no es la única vía para trasladar las necesidades del negocio en necesidades de hardware, hay otros procedimientos para dimensionar las necesidades de CPU, memoria, espacio en disco y en algunos casos, capacidad de la red de datos.


Hemos escrito un par entradas sobre Sizing basada en SAP Quick Sizer (aquí y aquí), pero esta no es la única vía para trasladar las necesidades del negocio en necesidades de hardware, hay otros procedimientos para dimensionar las necesidades de CPU, memoria, espacio en disco y en algunos casos, capacidad de la red de datos.

En todos los casos, se parte de más o menos supuestos, el resultado final son unas estimaciones de características iniciales que luego se deberán ajustar según la auditoria y seguimiento que se le dará a la implantación. A continuación, la descripción de los cinco procedimientos que considera SAP para el Sizing:

Pensamiento Big Data

Cuando se habla de Big Data (para nosotros, la gestión de grandes volúmenes de información) se recurre a la mención de las “V” (uves), algunos señalan entre tres y cuatro, y otros con, “más perspectiva”, hasta cinco.


Cuando se habla de Big Data (para nosotros, la gestión de grandes volúmenes de información) se recurre a la mención de las “V” (uves), algunos señalan entre tres y cuatro, y otros con, “más perspectiva”, hasta cinco. 

De todas estas palabras, que se han identificado o inventado para explicar en qué consiste Big Data, nos quedamos, en primer lugar, con dos de ellas, Volumen y Variedad que describen la naturaleza de los datos, Velocidad que sintetiza la forma en que deberían ser procesados y por último, Valor, que es la sensación que debe aportar el resultado a los usuarios.

Sobre la naturaleza de los datos (p.e. estructurados y no estructurados) poco podremos hacer.  Influir sobre  la forma de procesamiento para que realmente sea veloz, dependerá, en gran medida, de la tecnología elegida.  Quizás, sobre el factor que más influencia podrían tener los usuarios, sería la obtención de valor, entendiendo la “obtención de valor”, en este contexto, como la obtención de una nueva información, desconocida hasta entonces, que podría ser útil para tomar decisiones, aprovechar oportunidades o evitar riesgos que no se aprecian con los sistemas de información tradicionales.

¿Cómo Obtener Valor?

En una entrevista a Timo Elliott encontramos unas pautas a tener en cuenta, para lo que nosotros denominamos “Pensamiento Big Data”:

  • Conocer los procesos de negocio de la organización.
  • Conocer cómo se consume la información dentro de la organización.
  • Conocer los punto de decisión más críticos y encaminar las discusiones utilizando un razonamiento “Qué pasaría si (“What if”)
  • Utilizar herramientas de visualización que faciliten la compresión de los resultados (“what could be”).

A nuestro parecer, la clave del “Pensamiento Big Data” es plantearse preguntas tales como “¿Y si pudiéramos predecir de antemano si las entregas eran propensas a llegar tarde?” de este modo, podríamos estructurar y encaminar las necesidades de una organización y las expectativas de una autentica obtención de Valor, la “uve” más importante del Big Data.