En el episodio de hoy de Un podcast ninja sobre Big Data vamos a hablar de las distintas soluciones y paradigmas para guardar datos y luego poder utilizarlos en un ecosistema de Big Data: almacenes de datos (data warehouses), data lakehouses, mallas de datos (data mesh), tejidos de datos (data fabric)…
Y por supuesto también de lagos de datos 🦢
La mayoría de las empresas que quieren hacer algo con sus datos - y eso ahora está muy de moda - les pasa lo que le pasaba a Uber en sus inicios.
Diseñan soluciones para almacenar y poder procesar sus datos pero estas soluciones van haciendo aguas cuando el volumen de los datos va creciendo mucho.
Especialmente si crece mucho y además muy rápido
Entonces no queda otra que ir evolucionando sus soluciones para guardar estos datos según el volumen que manejan va creciendo.
Y cada poco tiempo aparece un paradigma nuevo para tener los datos bajo control.
En el principio de los tiempos Uber almacenaba sus datos en unas cuantas bases de datos.
Seguramente estos datos no eran más que los datos operacionales que iban generando en sus inicios. Es decir, datos que se generan a partir de eventos o interacciones con el cliente como puede ser un traslado de un cliente del punto A al punto B.
Estos datos se llaman operacionales porque es información en la que se basan para gestionar las operaciones del negocio, en este caso: Uber.
O sea para funcionar.
¿Más datos operacionales? Pues un contacto de un cliente para una reclamación, un pago, una valoración de un conductor o como decía una reserva y ejecución de un viaje.
Estos datos operacionales son los datos a los que en el episodio de la semana pasada llamaba fuentes de datos.
Los datos operacionales se van almacenando y consolidando para tener una visión más global del negocio.
Se convierten en datos analíticos.
Con los datos analíticos podemos obtener información del rendimiento pasado y actual del negocio con análisis descriptivo o intentar ver hacia donde parece que va el negocio a futuro y hacer cosas basadas en esa información, mediante análisis predictivo y prescriptivo.
En el episodio 6, hablábamos ya de estos tres tipos de análisis de datos.
Bien, pues todos estos datos analíticos son los que se extraen de las fuentes de datos, se transforman y se cargan en lagos de datos y almacenes de datos.
Esta es labor de los ingenieros de datos tal y como ya os contaba en el episodio 24.
El almacén de datos es el lugar en el que se guardan de manera organizada los datos estructurados.
Por ejemplo, aquí es donde iríamos a buscar los datos históricos para hacer un análisis descriptivo o también donde iríamos a buscar los datos para entrenar un modelo de Machine Learning.
Y si recordamos lo que les pasó en Uber al principio es que según el volumen de los datos que almacenaban crecía, que era además muy rápido, empezaron a utilizar su almacén de datos como un lago de datos.
¿Cuál es la diferencia?
Pues que un lago de datos es el sitio en el que se almacenan los datos en crudo. Antes de transformarlos de ninguna manera.
Además, a diferencia de los almacenes de datos que albergan datos estructurados, algo más parecido a una base de datos o a un montón de tablas de excel gigantescas, en los lagos de datos se pueden guardar datos no estructurados como imágenes, audio, documentos y cosas así.
En los inicios del Big Data, cuando empezaba a escucharse que era bastante guay tener muchos datos lo que hacían las empresas era básicamente montarse un lago de datos y guardarlo todo ahí sin ningún caso de uso muy presente para esos datos y eso sí, decir que estaban a la vanguardia del Big data.
Además de los lagos y almacenes de datos tb han surgido soluciones híbridas como los data lakehouses.
Los lakehouses consisten en almacenar los datos en crudo en un data lake o lago de datos peeero cargar una parte de esos datos en un almacén de datos. Así que tendríamos las ventajas de ambas soluciones.
Si recordáis es lo que hizo Uber cuando introdujo un lago de datos Hadoop pero seguía usando el data warehouse de Vertica para almacenar algunos de los datos.
Pero claro, si os fijáis, en los tres casos he hablado de un único sitio en el que guardar los datos, o como mucho, una arquitectura que combine un lago de datos y un almacén de datos pero es UNO de cada.
Una arquitectura centralizada, donde todos los datos analíticos se almacenan en un solo lugar, que además están gestionados por un ÚNICO equipo central de ingeniería de datos.
Entonces, al ser un ÚNICO equipo de ingenieros de datos, cualquier equipo en la empresa puede ir a pedirles los datos que sean que necesiten para su proyecto y la arquitectura servirá, peeeero no atiende específicamente las necesidades de cada uno de los equipos.
Es agnóstica a si necesita los datos alguien de marketing, o alguien de experiencia de usuario o quien sea y mucho menos del proyecto concreto que quieran implementar.
Está como poco personalizado, como si dijéramos.
Y entonces aquí es donde aparece el paradigma de malla de datos o data mesh.
La idea aquí es alejarse un poco de la arquitectura monolítica en la que hay un único lugar en el que se almacenan todos los datos y tiende más hacia la descentralización.
Cada equipo dentro de la empresa, cada dominio, gestiona un poco los datos que necesita.
Peeeero sin volver a los silos de datos. Claro.
No tiene nada que ver con cuando cada unidad de negocio tenía su propia base de datos con lo suyo y ni idea de lo que tenía el vecino.
Aquí cada dominio o unidad de negocio o equipo, o cómo queráis llamarlo es un nodo de la red que genera soluciones basadas en datos que no son útiles solo para ellos sino que pueden ser reutilizadas por otros equipos.
Estos nodos, estos equipos, tienen sus propios ingenieros de datos que están diseñando canalizaciones de extracción y transformación de datos para crear estas soluciones más personalizadas y que se ajustan mejor a lo que realmente necesitan en el equipo.
Una malla de datos no es una solución técnica o una herramienta como puede ser un lago de datos o un almacén de datos.
La malla de datos se enfoca conceptualmente en cómo organizar la plataforma de Big Data no en cómo resolver el problema técnicamente por lo que no define ninguna tecnología específica.
Por otro lado tendríamos el tejido de datos o data fabric.
Una arquitectura basada en Data fabric tiene por objetivo resolver los puntos flojos que presenta una arquitectura centralizada y monolítica con un lago de datos o un almacén de datos inmenso.
Al final, cuando teníamos un lago de datos inmenso con todos los datos gran parte del esfuerzo de los ingenieros de datos está en construir las canalizaciones que extraen y transforman los datos para que el resto de los equipos puedan utilizarlos.
Pero... ¿y si en lugar de mover todos los datos a un lugar centralizado pusiéramos una capa adicional de información de manera que se pudiera acceder a los datos sin tener que moverlos realmente?
Es como si se pudiera crear una vista virtual de datos que provienen de distintas fuentes pero sin tener que moverlos todos al mismo sitio.
Así de primeras, hablar de datos virtuales es un poco raro… si os habéis quedado en plan WTF, es normal del todo.
Entonces... ¿cómo se hace esto?
Pues para empezar se hace uso de metadatos.
Los metadatos no son más que datos sobre los datos.
Después también se crean catálogos de datos, de manera que los usuarios son capaces de explorar los datos que hay disponibles de una manera más eficiente.
La gracia del tejido de datos es poder usar estos datos sin tener que moverlos de un data lake a un data warehouse o a ningún sitio.
Normalmente en data fabric se utilizan estas técnicas de virtualización de datos lo que reduce la complejidad de la plataforma de Big Data.
Aunque no lo parezca.
Vais al catálogo que tiene todos los metadatos necesarios sobre todo lo que hay disponible y seleccionáis lo que necesitáis.
Además un Data Fabric permite utilizar Machine Learning para descubrir patrones dentro de esos metadatos.
Igual gracias a estos patrones podríamos descubrir que un equipo concreto puede utilizar unos datos adicionales en sus modelos además de los que ya estaba considerando.
En resumen, una solución de data fabric os permite tener una visión global de todos los datos y facilitar su acceso sin necesidad de que estén todos guardaditos en el mismo sitio. De esta manera la gestión se simplifica.
La idea es crear una capa unificada y coherente que abarca todas las fuentes de datos.
El punto en torno al cual gira el paradigma de Data Mesh es la descentralización y la distribución de la gestión de datos mientras que un Data Fabric crea una capa tecnológica unificada para la gestión de datos.
La elección entre estos enfoques depende de las necesidades y la estructura organizativa específica de la empresa e incluso sería posible combinar elementos de ambos enfoques según los requisitos.
Así que espero que el episodio de hoy os sea de provecho y que aprendáis algo de valor.
Si es así, no olvidéis dejar una valoración de 5 estrellas del podcast en Apple podcasts, en Spotify, en Ivoox, en Google podcast o donde quiera que escuchéis el podcast.
Recordad que si tenéis cualquier duda o pregunta podéis contactar conmigo a través del formulario de contacto o podemos seguir la conversación en Twitter.
Muchas gracias por estar ahí y os espero en el próximo episodio de Un Podcast Ninja sobre Big Data.