La trinidad de las plataformas de datos: ¿competitivas o complementarias?

La arquitectura de la plataforma de datos tiene una historia interesante. Hacia el cambio de milenio, las empresas comenzaron a darse cuenta de que la carga de trabajo de informes y business intelligence requería una nueva solución en lugar de las aplicaciones. Surgió una plataforma optimizada para la lectura que puede integrar datos de múltiples aplicaciones. Fue Datawarehouse.

En otra década, Internet y los dispositivos móviles comenzaron a generar datos de volumen, variedad y velocidad imprevistos. Requería una solución de plataforma de datos diferente. Por lo tanto, surgió el lago de datos, que maneja datos estructurados y no estructurados con un gran volumen.

Pasó otra década más. Y quedó claro que el lago de datos y el almacén de datos ya no son suficientes para manejar la complejidad del negocio y la nueva carga de trabajo de las empresas. Pero era demasiado costoso. El valor de los proyectos de datos es difícil de apreciar. Las plataformas de datos son difíciles de cambiar. El tiempo exigía una nueva solución, una vez más.

¿Cuál es? Esta vez, están surgiendo al menos tres soluciones de plataforma de datos diferentes: lakehouse de datos, tejido de datos y malla de datos. Aunque esto es alentador, también está generando confusión en el mercado. Los conceptos y valores se superponen. A veces surgen diferentes interpretaciones dependiendo de a quién se le pregunte.

Este artículo intenta aliviar esas confusiones. Se explicarán los conceptos. Y luego se presentará un marco, que mostrará cómo estos tres conceptos pueden conducirse entre sí o usarse entre sí.

Databricks popularizó el concepto de lakehouse. Lo definieron como: “Un lakehouse de datos es una nueva arquitectura de gestión de datos abierta que combina la flexibilidad, la rentabilidad y la escala de los lagos de datos con la gestión de datos y las transacciones ACID de los almacenes de datos, lo que permite business intelligence (BI) y machine learning (ML) en todos los datos”.

Mientras que los almacenes de datos tradicionales utilizaban un proceso de extracción, transformación y carga (ETL) para ingerir datos, los lagos de datos se basan en un proceso de extracción, carga y transformación (ELT). Los datos extraídos de múltiples fuentes se cargan en un almacenamiento BLOB económico, luego se transforman y se conservan en un almacén de datos, que utiliza un costoso almacenamiento de bloques.

Esta arquitectura de almacenamiento es inflexible e ineficiente. La transformación debe realizarse de manera continua para mantener sincronizados el almacenamiento BLOB y el almacén de datos, lo que genera costos adicionales. Y la transformación continua sigue consumiendo mucho tiempo. Para cuando los datos estén listos para el análisis, los insights que puedan generar serán obsoletos en relación con el estado actual de los sistemas transaccionales.

Además, el almacenamiento de datos no puede admitir cargas de trabajo como la inteligencia artificial (IA) o el machine learning (ML), que requieren enormes cantidades de datos para el entrenamiento de modelos. Para estas cargas de trabajo, los proveedores de lagos de datos suelen recomendar extraer los datos en archivos planos que se utilizarán únicamente con fines de entrenamiento y prueba de modelos. Esto agrega un paso ETL adicional, lo que hace que los datos sean aún más obsoletos.

El lakehouse de datos se creó para resolver estos problemas. La capa de almacenamiento del almacén de datos se elimina de las arquitecturas de lakehouse. En su lugar, la transformación de datos se realiza dentro del almacenamiento BLOB. Se añaden múltiples API para que diferentes tipos de cargas de trabajo puedan utilizar los mismos depósitos de almacenamiento. Esta es una arquitectura muy adecuada para la nube, ya que AWS S3 o Azure DLS2 pueden proporcionar el almacenamiento necesario.

El tejido de datos representa una nueva generación de arquitectura de plataformas de datos. Se puede definir como: Una colección ligeramente acoplada de servicios distribuidos, que permite que los datos correctos estén disponibles en la forma correcta, en el momento y lugar correctos, desde fuentes heterogéneas de naturaleza transaccional y analítica, en cualquier nube y plataformas on premises, generalmente a través de autoservicio, al tiempo que satisface requisitos no funcionales, incluida la rentabilidad, el rendimiento, la gobernanza, la seguridad y el cumplimiento.

El objetivo del tejido de datos es hacer que los datos estén disponibles donde y cuando se necesiten, eliminando las complejidades tecnológicas que implican el movimiento, la transformación y la integración de datos, de modo que cualquiera pueda utilizarlos. Algunas características clave del tejido de datos son:

Un tejido de datos se compone de una red de nodos de datos (por ejemplo, plataformas de datos y bases de datos), todos interactuando entre sí para proporcionar un mayor valor. Los nodos de datos se distribuyen por todo el ecosistema informático híbrido y multicloud de la empresa.

Un tejido de datos puede constar de múltiples almacenes de datos, lagos de datos, dispositivos IoT/edge y bases de datos transaccionales. Puede incluir tecnologías que van desde Oracle, Teradata y Apache Hadoop hasta Snowflake en Azure, RedShift en AWS o MS SQL en el centro de datos on premises, por nombrar solo algunas.

La estructura de datos abarca todas las fases del ciclo de vida de los datos: información e insight. Un nodo de la estructura puede proporcionar datos sin procesar a otro que, a su vez, realiza analytics. Estos analytics pueden exponerse como API REST dentro de la estructura, de modo que puedan ser consumidos por los sistemas transaccionales de registro para la toma de decisiones.

El tejido de datos está diseñado para unir los mundos analítico y transaccional. Aquí, todo es un nodo, y los nodos interactúan entre sí a través de una variedad de mecanismos. Algunos de estos requieren movimiento de datos, mientras que otros permiten el acceso a datos sin movimiento. La idea subyacente es que los silos de datos (y la diferenciación) eventualmente desaparecerán en esta arquitectura.

Las políticas de seguridad y gobernanza se aplican cada vez que los datos viajan o se accede a ellos a través del tejido de datos. Al igual que Istio aplica la gobernanza de seguridad a los contenedores en Kubernetes, la estructura de datos aplicará políticas a los datos según principios similares, en tiempo real.

La estructura de datos promueve la capacidad de descubrir datos. Aquí, los activos de datos se pueden publicar en categorías, creando un mercado de datos en toda la empresa. Este mercado ofrece un mecanismo de búsqueda que utiliza metadatos y un gráfico de conocimiento para permitir el descubrimiento de activos. Esto permite el acceso a los datos en todas las etapas de su ciclo de vida de valor.

La llegada del tejido de datos abre nuevas oportunidades para transformar las culturas empresariales y los modelos operativos. Dado que las estructuras de datos están distribuidas, pero son inclusivas, su uso promueve una gobernanza federada pero unificada. Esto hará que los datos sean más confiables y dignos de confianza. El mercado facilitará que los stakeholders de todo el negocio descubran y utilicen datos para innovar. A diversos equipos les resultará más fácil colaborar y administrar activos de datos compartidos con un sentido de propósito común.

La estructura de datos es una arquitectura global, en la que algunas tecnologías nuevas (por ejemplo, la virtualización de datos) desempeñan un papel clave. Pero permite que las bases de datos y plataformas de datos existentes participen en una red, donde un catálogo de datos o un mercado de datos pueden ayudar a descubrir nuevos activos. Los metadatos desempeñan un papel clave aquí en el descubrimiento de los activos de datos.

Thoughtworks introduce la malla de datos como concepto. Lo definieron como: “... Una arquitectura de datos analíticos y modelo operativo donde los datos son tratados como un producto y propiedad de equipos que más íntimamente conocen y consumen los datos”. El concepto se basa en cuatro principios: propiedad del dominio, datos como producto, plataformas de datos de autoservicio y gobernanza computacional federada.

El tejido de datos y la malla de datos como conceptos tienen superposiciones. Por ejemplo, ambos recomiendan una arquitectura distribuida, a diferencia de las plataformas centralizadas como el almacén de datos, el lago de datos y la casa de datos. Ambos quieren destacar la idea de un producto de datos ofrecido a través de un mercado.

También existen diferencias. Como se desprende claramente de la definición anterior, a diferencia de la estructura de datos, la malla de datos se refiere a los datos analíticos. Su enfoque es más limitado que el del tejido de datos. En segundo lugar, enfatiza el modelo operativo y la cultura, lo que significa que va más allá de una arquitectura como el tejido de datos. La naturaleza del producto de datos puede ser genérica en el tejido de datos, mientras que la malla de datos prescribe claramente la propiedad de los productos de datos basada en el dominio.

Es evidente que estos tres conceptos tienen su propio enfoque y fortaleza. Sin embargo, la superposición es evidente.

Lakehouse se distingue de los otros dos. Es una nueva tecnología, como sus predecesoras. Se puede codificar. Existen múltiples productos en el mercado, incluidos Databricks, Azure Synapse y Amazon Athena.

La malla de datos requiere un nuevo modelo operativo y un cambio cultural. A menudo, estos cambios culturales requieren un cambio en la mentalidad colectiva de la empresa. Como resultado, la malla de datos puede ser revolucionaria por naturaleza. Se puede construir desde cero en una parte más pequeña de la organización antes de extenderlo al resto.

El tejido de datos no tiene requisitos previos como la malla de datos. No se espera tal cambio cultural. Se puede construir utilizando los activos existentes, en los que la empresa ha invertido a lo largo de los años. Por lo tanto, su enfoque es evolutivo.

Entonces, ¿cómo puede una empresa adoptar todos estos conceptos?

Puede adoptar un lakehouse como parte de su propio proceso de evolución de la plataforma de datos. Por ejemplo, un banco puede deshacerse de su almacén de datos de una década y ofrecer todos los casos de uso de BI e IA desde una única plataforma de datos, mediante la implementación de un lakehouse.

Si la empresa es compleja y tiene múltiples plataformas de datos, si el descubrimiento de datos es un desafío, si la entrega de datos en diferentes partes de la organización es difícil, el tejido de datos puede ser una buena arquitectura para adoptar. Junto con los nodos de la plataforma de datos existente, también pueden participar uno o varios nodos de lakehouse. Incluso las bases de datos transaccionales también pueden unirse a la red de tejido como nodos para ofrecer o consumir activos de datos.

Para abordar la complejidad del negocio, si la empresa se embarca en un cambio cultural hacia la propiedad de datos impulsada por el dominio, promueve el autoservicio en el descubrimiento de datos y la entrega de datos, y adopta la gobernanza federada, están en un camino de malla de datos. Si la arquitectura de estructura de datos ya está implementada, la empresa puede utilizarla como un factor clave en su transición hacia la malla de datos. Por ejemplo, el mercado del tejido de datos puede ofrecer productos de datos centrados en el dominio, un resultado clave de la malla de datos. El descubrimiento basado en metadatos, que ya se ha consolidado como una capacidad a través de la estructura de datos, puede resultar útil para descubrir los nuevos productos de datos que surgen de la malla.

Cada empresa puede analizar sus respectivos objetivos comerciales y decidir qué punto de entrada les conviene más. Pero aunque los puntos de entrada o las motivaciones pueden ser diferentes, una empresa puede usar fácilmente los tres conceptos juntos en su búsqueda de la centralidad de los datos.