Arquitectura de Big Data

Como arquitecto de software, mi objetivo es realizar tareas complicadas mediante soluciones sencillas. Cada uno de los componentes de una solución tiene ventajas e inconvenientes; el arte consiste en combinarlos de tal manera que en suma las ventajas se mantengan y los inconvenientes se anulen mutuamente.

Para muchos usuarios de SAP, el primer paso será habilitar la analítica con big data, es decir, encontrar información interesante en estas enormes cantidades de datos.

Pero en lugar de construir una infraestructura completamente nueva para los usuarios, combino el sistema de Big Data con el almacén de datos existente.

El científico de datos obtiene el lago de datos, un área de datos en la que están disponibles todos los datos en bruto, y una potente herramienta con la que también puede procesar estos datos en bruto. El resultado de su trabajo son nuevos ratios que añado al almacén de datos. Esto tiene varias ventajas:

• El usuario empresarial sigue utilizando sus herramientas habituales de análisis, sólo que ahora dispone de más ratios.
• El científico de datos tiene acceso a todos los datos, Big Data y datos ERP.
• Para TI, el esfuerzo es asumible.

Esta solución también es atractiva en el contexto de costes vs. beneficios vs. probabilidades de éxito: al acoplarme a lo existente, tengo un ámbito de proyecto reducido, por tanto un riesgo de proyecto minimizado y una implantación más barata, pero sigo aprovechando al máximo los beneficios potenciales.

Así, una solución de Big Data consta únicamente de dos componentes: el lago de datos con los datos en bruto y un clúster de servidores donde tiene lugar la preparación de los datos.

Lago de datos o SAP Vora

En el pasado, SAP ofrecía SAP Vora como lago de datos y vende la solución Altiscale con el nombre de Big Data Services. Básicamente, sin embargo, el lago de datos no es más que un gran sistema de archivos. Si, a pesar de todo, los comerciales de SAP proponen Vora, Altiscale o DataHub, habrá que cuestionarse muy críticamente el precio y el rendimiento.

¿Por qué no empezar con un disco duro local o el servidor central de archivos en la primera fase del proyecto? Mientras haya espacio suficiente y los costes del espacio de almacenamiento no sean demasiado elevados, esto es válido en todas partes. Copiar los archivos es posible en cualquier momento y sin problemas, así que no bloqueo nada para el futuro.

Preparación con Apache Spark

Para procesar estos datos, la mayoría de los proyectos actuales utilizan el marco de código abierto Apache Spark. Permite escribir programas para el tratamiento de datos con solo unas pocas líneas de código y ejecutarlos en paralelo en un clúster de servidores.

No hay razón para que reinvente la rueda aquí, sobre todo porque una instalación de este tipo es muy sencilla y puede hacerse en diez minutos: descargar el paquete en un pequeño ordenador Linux, extraerlo e iniciar un maestro y un primer trabajador mediante el comando start-all.

Reto: Algoritmo

La tecnología es manejable con el planteamiento anterior. Desarrollar los algoritmos para los nuevos ratios es la parte difícil: ¿cómo extraer información de los datos masivos que, en última instancia, se reflejará en los beneficios de la empresa?

Aquí es exactamente donde se decide el éxito de un proyecto de Big Data. Aquí es exactamente donde creo que tiene sentido invertir, por ejemplo, en la formación de un científico de datos.

En las siguientes columnas responderé, entre otras, a las siguientes preguntas: ¿Por qué usar Apache Spark y no una herramienta ETL? ¿Por qué necesitas un lago de datos si los datos ya están en el almacén de datos? Etc.