Son las dos palabras de moda más importantes en la arquitectura de datos, pero ¿qué son y cómo deberían las empresas elegir lo que es adecuado para ellas?. El campo de la arquitectura de datos está lleno de jerga, desde «data meshes» hasta «hubs» y «warehouses». Sin embargo, dos de las palabras de moda más importantes en este momento son «data lakes» y «data fabric», dos enfoques diferentes para manejar las grandes cantidades de datos que una empresa moderna acaba recolectando.
El concepto de un «data lake» es una metáfora: si un lago almacena agua en cualquier forma «natural» en la que llegue, ya sea de la lluvia, ríos o arroyos, un «data lake» almacena datos en cualquier forma en la que lleguen, desde cualquier parte de tu organización que los esté creando, ya sean datos estructurados o no estructurados.
Tradicionalmente, esto se posicionaba en oposición a un «data warehouse», donde defines qué tipos de datos vas a almacenar antes de recopilarlos, estandarizando y estructurando tus datos a medida que llegan.
La falla en ese enfoque es obvia. Si tengo un negocio que vende sombreros y he configurado mi «data warehouse» para registrar información sobre sombreros, pero luego decido expandirme y vender zapatos, tendría que cambiar la estructura del almacén para almacenar diferentes tipos de información de productos. Pero a un «data lake» no le importa si los datos son sobre zapatos, sombreros o dinosaurios, o incluso en qué formato están. Simplemente puedes verter cualquier cosa allí y descubrir el resto más tarde.
Vea también: Tendencias y tecnologías: Perspectivas de expertos en retail y marketing
¿Cuáles son las ventajas y desventajas de diferentes arquitecturas de datos?
Por supuesto, cada enfoque tiene sus ventajas y desventajas. Los datos almacenados con una estructura clara y predefinida son más fáciles de usar, mientras que darle sentido a todo lo que se ha volcado en un lago requiere un conocimiento más especializado y probablemente necesitará pasar por un científico de datos antes de que otras personas en tu empresa puedan obtener información útil de él. La naturaleza sin filtrar de los datos también puede presentar problemas de confiabilidad y/o seguridad.
Pero los «data lakes» son más flexibles, tienen costos de almacenamiento más bajos y pueden admitir una gama más amplia de usos. Por ejemplo, a menudo se utilizan en combinación con el aprendizaje automático, ya que los datos no estructurados en bruto a menudo son más adecuados allí que algo que ya ha sido cuidadosamente etiquetado, filtrado y etiquetado.
Desafortunadamente, existen problemas más amplios con el manejo de datos que ninguna solución de almacenamiento puede resolver por sí sola. Aquí es donde entra en juego el concepto de «data fabric» (tela de datos). Aunque en teoría una empresa podría utilizar una única solución de almacenamiento, en la práctica esto rara vez es ideal, ya que las organizaciones suelen tener una amplia gama de casos de uso y demandas en sus datos: un equipo enfocado en el aprendizaje automático puede tener prioridades muy diferentes a un equipo enfocado en el cumplimiento normativo.
Un «data fabric» establece relaciones e interoperabilidad entre todos los datos que una organización posee. La metáfora es que puedes «tejer» todas estas cosas diferentes juntas para crear un marco único que tenga en cuenta todos tus datos, sin tener que almacenar todos esos datos juntos en un mismo lugar.
¿Cómo se puede adaptar una arquitectura de datos a las necesidades de tu empresa?
La arquitectura real detrás de esto variará según las necesidades de la empresa. Conectar diferentes fuentes puede ser tan simple como vincularlas a través de APIs o tan complejo como emparejar datos mediante inteligencia artificial. El punto es hacer esto dentro de un marco claramente definido para garantizar que todos en la organización puedan acceder a los datos que necesitan, cuando los necesiten, sin comprometer los recursos técnicos y de datos, y sin introducir problemas de seguridad y gobierno de datos.
La diferencia con el enfoque de un «data warehouse» es que no necesariamente debes definir rigurosamente cómo cada componente individual del marco está almacenando los datos. En su lugar, simplemente puedes incorporar nuevos componentes a la tela cuando los necesites.
Un caso de uso común para un «data fabric» es el seguimiento de la identidad a lo largo de tus datos, ya sea la identidad humana de un cliente o empleado, o la identidad no humana de una máquina u otra entidad.
Cuando se requieren análisis en tiempo real en casos de uso financieros y de atención médica, las telas de datos pueden ser útiles.
John Pritchard, de la plataforma de datos de identidad Radiant Logic, describe los problemas y cómo una tela de datos puede abordarlos. «Es muy común que las organizaciones tengan muchos sistemas que definen a sus empleados o clientes, y a menudo se utiliza una tela de datos para tratar de unirlos en un estado coherente y cohesionado», explica.
Una empresa puede tener mucha información diferente sobre un empleado, por ejemplo: detalles de contacto, los tipos de capacitación que han realizado, certificaciones para usar una máquina en particular, cualquier procedimiento de cumplimiento por el que hayan pasado.
Como lo describe Pritchard: «Esos tipos de atributos de datos tienden a vivir en muchos sistemas especializados diferentes. Y la idea de una tela de datos es tratar de unirlos. Es necesario cuando tienes muchas cosas diferentes sucediendo. Esa es probablemente la principal motivación para la mayoría de las organizaciones. Y en nuestro mundo, es muy común que esos datos no coincidan exactamente entre sí».
¿Qué está en juego si eliges la arquitectura de datos incorrecta?
Este tipo de datos inconsistentes e incompletos pueden tener grandes implicaciones. «En nuestro ámbito, muchas veces esa completitud se relaciona con el riesgo», dice Pritchard. «Cuando los datos de identidad tienen problemas de calidad o desviación de datos, los sistemas que utilizan esos datos para tomar decisiones de acceso, por ejemplo, pueden correr riesgos porque los datos se han vuelto obsoletos. Un enfoque de tela, conectando muchas fuentes de datos diferentes, puede observar cómo los datos se mueven con el tiempo y evaluar su completitud».
Pero un enfoque de tela de datos no se trata solo de asegurarse de que todos los sistemas que contienen tus datos puedan comunicarse entre sí. También se trata de utilizar todos esos datos juntos para asegurarse de que estás construyendo una imagen completa y actualizada basada en todo lo que sabes sobre una entidad específica, ya sea un cliente, un producto o un socio comercial.
Daniel Wood, de la plataforma de desarrollo Unqork, destaca ejemplos en los que esto puede ser clave. «Cuando se requieren análisis en tiempo real en casos de uso financieros y de atención médica, como comprender los datos de los pacientes, realizar detección de fraudes o monitoreo y alerta general, las telas de datos pueden ser increíblemente útiles debido a las complejas integraciones de datos».
Cómo armar tu arquitectura de datos
Entonces, ¿cuál debería usar tu organización, una tela o un lago? Bueno, esa podría no ser la forma correcta de verlo, porque un lago de datos bien podría ser uno de los componentes integrados en la arquitectura de una tela de datos.
Lo que cualquier líder tecnológico debe considerar, en primer lugar, es el tipo de datos que se recopilan y si es necesario compartirlos en toda la empresa. Un equipo que trabaje mucho con dispositivos de IoT, aprendizaje automático o cualquier otro caso de uso de big data probablemente necesitará un lago de datos de algún tipo.
Lo que cualquier líder tecnológico debe tener en cuenta, en primer lugar, es el tipo de datos que se están recopilando y si es necesario compartirlos en toda la empresa. Es probable que un equipo que trabaje mucho con dispositivos de IoT, aprendizaje automático o cualquier otro caso de uso de big data necesite algún tipo de lago de datos.
La verdadera pregunta es si, o cuándo, esos datos necesitan ser utilizados fuera de ese silo particular. ¿Cómo se debe gestionar ese proceso? Ahí es donde una tela de datos se vuelve útil.
