La historia de HANA a S/4HANA (I)
La situación de partida
En el vertiginoso mundo de la tecnología empresarial, la necesidad de sistemas eficientes y ágiles se ha vuelto crucial para el éxito de las organizaciones.
En esta búsqueda constante de innovación, SAP, ha desempeñado un papel destacado.
En esta serie de artículos, exploraremos la fascinante evolución desde la aparición de SAP HANA hasta la puesta en escena de S/4HANA, dos hitos fundamentales que han transformado la forma en que las empresas gestionan sus datos y procesos.
Todo surgió con los problemas de procesamiento del big data.
Pero para comprenderlo mejor vamos primero a recordar las 3 capas en la arquitectura de la mayor parte de los sistemas:
Tenemos estas 3 capas:
- Base de datos: para almacenar y recuperar los datos.
- Aplicación: procesa los datos.
- Presentación: es la interfaz para mostrar los datos al usuario.
Nuestro propio ordenador es un buen ejemplo.
Pensemos en los documentos de Word, que están guardados en el disco duro (o sea, en la base de datos).
Luego recuperamos un documento para trabajar sobre él, añadiendo palabras, borrando otras, insertando una imagen, etc.
Eso sería la capa de aplicación.
Y lo que sería la interfaz de Word, si el tema es oscuro o claro, o las opciones de apariencia, eso todo se gestionaría en la capa de presentación.
Pues bien, estos sistemas funcionan perfectamente para registrar operaciones pero ¡no para analizar grandes volúmenes de datos! ⚠️
Veámoslo con un ejemplo
Supón que cada mes registramos 1 millón de facturas a clientes, junto con información como el área de ventas, el grupo de vendedores, el tipo de cliente, la línea de negocio, etc.
Y ahora llega el director de ventas y nos dice que quiere los resultados del último trimestre de la zona Norte, según todos los grupos de vendedores y totalizados por línea de negocio.
En este caso, nuestro sistema SAP se tiene que ir a la base de datos, leer los 3 millones de facturas, procesarlas y hacer los subtotales en base a los criterios anteriores.
O sea, que desde que el director de ventas pulsa el botón del informe hasta que obtiene los resultados va a pasar bastante tiempo debido a la gran cantidad de datos a analizar. ¡Normal que se desespere!
El cuello de botella
¿Dónde está el cuello de botella?
Pues en la base de datos, ya que el acceso a disco es lento.
Además, no es una sola lectura a disco, sino muchas, porque la memoria RAM que tenemos en la capa de aplicación es relativamente pequeña como para cargar todos los datos a procesar de una sola vez.
Es decir, estos sistemas de 3 capas están muy bien para realizar operaciones (y por eso se llaman OLTP, o de procesamiento de transacciones on line) pero no para analizar los datos (que serían sistemas OLAP, o de procesamiento analítico on line).
Una primera solución
¿Cuál fue la solución adoptada en la década del 2000?
Pues realizar los cálculos antes y almacenarlos en otra base de datos para tenerlos disponibles.
Por ejemplo, por la noche se calcularían los totales de ventas por mes, por grupo de vendedores, zona geográfica, línea de negocio, etc. y se guardarían en otra base de datos.
A la mañana siguiente, el director de ventas entrará en el sistema que tiene la nueva base de datos para consultar el informe del último trimestre.
Y como tenemos los cálculos ya realizados y totalizados por mes, la capa de aplicación solo tendrá que hacer una suma de 3 sumandos para obtener los resultados por trimestre, lo cual es rápido.
De esta forma, este informe de análisis de datos lo obtuvo nada más apretar el botón.
Pero claro, aunque el director de ventas esté contento, todo esto tiene contrapartidas.
Fíjate en todo lo que tuvimos que hacer: configurar 2 sistemas, cada uno con su base de datos y software de aplicación y, además, un proceso ETL de extracción de datos, transformación y carga.
Esto es complejo, lo que dificulta el mantenimiento, y hay que pagar a diferentes equipos de mantenimiento (uno por sistema más el del ETL), pagar las licencias de cada base de datos…
Además, cada sistema en sí, sigue siendo lento.
Es decir, si en vez de hacer una simple suma de 3 operandos como antes, hubiese que procesar otra vez gran cantidad de datos en el sistema OLAP, esto requeriría tiempo, no sería instantáneo.
Bueno, pues para solventar este último problema, y teniendo en cuenta que el precio de la memoria RAM se estaba abaratando, en 2011 SAP lanzó el SAP BWA, es decir, el acelerador de sistemas OLAP (también llamados BW).
Esto era, a grandes rasgos, una gran memoria RAM del tamaño del disco duro del sistema OLAP, en la que se cargaban todos los datos.
De esta forma, ya no había que hacer lecturas a disco (pues todo estaba en RAM), con lo que la rapidez de procesamiento de datos en los sistemas OLAP se incrementó sustancialmente.
¡Esto es justo la antesala a la incorporación de la base de datos HANA en los sistemas OLAP al año siguiente!
Pero eso lo veremos en el siguiente artículo.
¡No te lo pierdas!
Si te interesa este tipo de publicaciones, déjame un comentario para seguir aportando más.