La tecnología de un lago de datos

En general, yo dividiría las opciones de almacenamiento de datos en tres categorías. Ficheros: los datos se almacenan como simples ficheros y se utilizan como tablas.

Estos archivos deben contener información sobre la estructura y también deben estar indexados. El formato de archivo Parquet es representativo de esta categoría.

Proceso de base de datos: En lugar de trabajar directamente con los archivos, hay un servicio activo en la parte superior que se siente como una base de datos. Se encarga de almacenar en caché los datos de uso frecuente y puede consultarse a través de ODBC/JDBC. Un representante típico de este tipo en el mundo de los macrodatos es Apache Hive.

En memoria: Para obtener el máximo rendimiento, todos los datos se almacenan en memoria, se indexan y se utilizan para construir algo similar a Hana. Exasol y SAP Vora funcionan según este principio.

El mundo del big data vive únicamente del hecho de que muchos servidores pequeños (y por tanto baratos) forman un sistema global. Esto permite un escalado infinito, con costes de hardware que solo aumentan linealmente.

Pero cuantos más nodos forman el sistema global, más cara resulta su sincronización. Un enlace ("join") de tres o incluso más tablas puede suponer que cada nodo tenga que buscar los resultados intermedios apropiados del enlace anterior y que la consulta se prolongue durante horas.

Este problema se denomina "redistribución". Por supuesto, el hecho de que los datos se almacenen en memoria no ayuda a la hora de redistribuir los resultados provisionales a través de la red.

Hana, en cambio, es una auténtica base de datos. Es increíblemente rápida en las búsquedas. El rendimiento de las uniones es estupendo y la consistencia de las transacciones es total al leer y escribir. Todo esto requiere mucha sincronización.

Sin embargo, una base de datos de este tipo no escala infinitamente. Muchos proyectos resuelven el dilema de la "reorganización" almacenando los datos de forma optimizada para determinadas consultas. Esto, a su vez, reduce la flexibilidad y aumenta los costes, es decir, precisamente los puntos que en realidad se pretendían como ventajas de un lago de datos.

El esfuerzo de sincronización de la coherencia de las transacciones es un problema lógico. No puede resolverse sin imponer requisitos más blandos, como la "coherencia eventual".

Este problema se conoce como el teorema CAP. De los tres requisitos Consistencia-Disponibilidad-Partición, nunca se pueden alcanzar todos los puntos, especialmente en caso de error.

Un sistema distribuido y de alta disponibilidad tiene que hacer concesiones en términos de coherencia de los datos, mientras que un sistema de base de datos transaccional tiene que hacer concesiones en términos de disponibilidad o escalabilidad.

Los datos disponibles en Big Data son datos en bruto que se convierten en información mediante transformaciones no SQL, por lo que un almacén de datos basado en Big Data con consultas SQL no tiene sentido.

El lago de datos es el patio de recreo del científico de datos. Esta persona tiene fácil acceso a datos que antes se eliminaban o eran de difícil acceso.

El científico de datos puede enfrentarse a todos los problemas que plantea la tecnología de big data: Semántica de los datos; rendimiento lento; y, qué datos hay. ¿Mezcla de big data y datos empresariales? Ningún problema para él.

Acoplar Hana con Vora no tiene mucho sentido desde este punto de vista. Ambos almacenan los datos en memoria y permiten búsquedas rápidas, con los costes correspondientes. Ambos tienen almacenamiento en caliente en disco (base de datos Sybase), ambos se centran en consultas SQL. Además, Vora ya no figura en la lista de precios de SAP como producto independiente.

En cambio, los archivos parquet y una base de datos se complementan a la perfección. Los archivos parquet de un lago de datos no cuestan prácticamente nada de almacenar, mientras que el espacio de almacenamiento en la base de datos es caro.

Una base de datos como Hana está excelentemente adaptada para las uniones y las consultas SQL complicadas; para un clúster informático, son precisamente estas operaciones las más complejas.

La combinación de ambas permite realizar consultas rápidas de inteligencia empresarial y acceder cómodamente a todos los datos en bruto. Ambos aportan sus puntos fuertes.