La mayoría de las organizaciones que impulsan iniciativas de IA hoy no tienen un problema de falta de datos. Tienen un problema de dónde ponerlos para que funcionen a la vez con analítica, machine learning e IA generativa, sin tres copias separadas ni tres pipelines separados. IBM watsonx.data es la respuesta de IBM a ese problema: un lakehouse abierto diseñado para almacenar datos estructurados, semiestructurados y no estructurados en un solo lugar, consultable por múltiples motores y con la gobernanza suficiente para que los equipos de IA y los equipos de analítica trabajen desde la misma fuente sin pisarse. Para los equipos que ya usan Kafka para datos en tiempo real, la pregunta más interesante es cómo esos datos en streaming llegan realmente a un lakehouse construido de esta forma.
IBM watsonx.data es un lakehouse de arquitectura abierta que separa el cómputo, los metadatos y el almacenamiento en capas independientes, de modo que distintos motores de consulta pueden acceder a los mismos datos subyacentes sin duplicarlos. Almacena los datos usando Apache Iceberg como formato de tabla abierto principal, con soporte adicional para Avro, Parquet y ORC, y expone esos datos a múltiples motores de consulta, entre ellos Presto (tanto la variante Java como la C++) y Spark. La gobernanza se gestiona a través de IBM Knowledge Catalog, que garantiza la coherencia de los esquemas y administra los metadatos en toda la plataforma. También incluye Milvus, una base de datos vectorial, para el almacenamiento de embeddings y la búsqueda por similitud, que es lo que conecta la plataforma con cargas de trabajo de IA e IA generativa, y no solo con la analítica tradicional.
La plataforma también admite acceso sin copia a datos que ya residen en sistemas existentes, incluidos Db2 Warehouse y Netezza Performance Server, lo que significa que no hace falta migrar nada antes de que un equipo pueda empezar a consultar esos datos a través de watsonx.data. Las opciones de despliegue incluyen AWS, Azure, IBM Cloud y on-premises a través de Red Hat OpenShift, y una Developer Edition empaqueta motores preconfigurados para instalación local en macOS, Windows o Linux, que es como suelen evaluar la plataforma los equipos antes de comprometerse con un despliegue en producción.
Un data lakehouse es una arquitectura que combina el almacenamiento flexible y de bajo coste de un data lake con las funciones de gestión de datos de un data warehouse: transacciones ACID, cumplimiento de esquemas y rendimiento en las consultas. La idea es no tener que elegir entre «barato y flexible» y «estructurado y rápido». Los datos llegan una sola vez, en un formato abierto, y tanto la analítica exploratoria como los informes gobernados se ejecutan sobre la misma copia.
| Aspecto | Data warehouse | Data lake | Data lakehouse |
|---|---|---|---|
| Estructura de los datos | Muy estructurados, schema-on-write | En bruto, estructurados o no estructurados | Estructurados y no estructurados, en formatos de tabla abiertos |
| Coste | Coste de almacenamiento más alto | Almacenamiento de objetos de bajo coste | Almacenamiento de objetos de bajo coste |
| Gobernanza | Sólida, integrada | A menudo débil sin herramientas adicionales | Integrada mediante metadatos y cumplimiento de esquemas |
| Flexibilidad para datos diversos | Limitada | Alta | Alta |
| Modo de fallo habitual | Caro de escalar para datos en bruto | Se convierte en un data swamp sin gobernanza | Exige decisiones deliberadas sobre formato de tabla y gobernanza |
| Más adecuado para | Informes basados en SQL | Almacenamiento de datos en bruto, exploración | Cargas de trabajo unificadas de analítica, ML e IA |
El patrón que lleva hasta aquí resulta familiar para la mayoría de los equipos de datos. Primero se construye un warehouse para los informes, porque los informes necesitan estructura y velocidad. A medida que se acumulan datos en bruto y semiestructurados, casi siempre más rápido de lo que el warehouse puede absorber, se añade un lake al lado para tener almacenamiento barato y flexibilidad. En pocos años, la organización acaba manteniendo dos sistemas, pagando por mantenerlos más o menos sincronizados y pidiendo a los data scientists que tiren de uno u otro según dónde estén los datos que necesitan. El lakehouse es un intento de dejar de pagar ese peaje haciendo que un solo sistema cumpla bien las dos funciones.
Las cargas de trabajo de IA y machine learning necesitan grandes volúmenes de datos en bruto y semiestructurados para el entrenamiento, y los necesitan sin pasar por un ciclo largo de extract-transform-load hacia un almacén estructurado aparte. Un lakehouse mantiene esos datos en un formato abierto que tanto un job de Spark de un data scientist como una consulta SQL de un analista de negocio pueden leer directamente. En el caso concreto de watsonx.data, la incorporación de Milvus hace que los embeddings y la búsqueda vectorial convivan con los mismos datos gobernados, en lugar de vivir en un almacén vectorial desconectado que hay que sincronizar aparte.
Esto importa sobre todo en la generación aumentada por recuperación (RAG), donde el resultado de un modelo es tan bueno como el contexto que consigue recuperar. Si el almacén vectorial que guarda los embeddings es un sistema distinto del lakehouse que guarda los registros estructurados que esos embeddings describen, mantener ambos sincronizados se convierte en un problema de ingeniería continuo. Alojar los dos en watsonx.data elimina ese paso de sincronización, porque la búsqueda vectorial y los datos gobernados subyacentes se consultan desde la misma plataforma en lugar de reconciliarse después.
watsonx.data en sí es una capa de consulta y almacenamiento, no un procesador de streams, así que los topics de Kafka no llegan directamente a ella. En la práctica, los datos en streaming llegan al lakehouse a través de una capa de ingesta, normalmente un job de change-data-capture o de procesamiento de streams, que consume los eventos de Kafka y los escribe en tablas Iceberg a medida que llegan. Una vez que esos datos están en forma de tabla, se comportan como cualquier otro dataset de watsonx.data: consultables por Presto o Spark, gobernados por IBM Knowledge Catalog y disponibles para las mismas cargas de trabajo de analítica e IA que los datos cargados por lotes. La ventaja práctica es que un equipo que ya usa Kafka para eventos en tiempo real no necesita una capa de servicio en tiempo real aparte junto a su almacén analítico. El pipeline de streaming alimenta una única tabla gobernada, y cada consumidor posterior, un dashboard, un informe por lotes o un job de entrenamiento de un modelo, lee de esa misma fuente en lugar de una copia aparte solo para tiempo real.
Esto sí introduce una contrapartida que conviene reconocer sin rodeos: los datos están tan actualizados como lo esté el job de ingesta que los alimenta, no al instante como lo estarían con un procesador de streams nativo. Para la mayoría de los casos de uso de analítica e IA, una frescura de tabla medida en segundos o minutos es más que suficiente, y supone una mejora considerable frente a una carga por lotes nocturna. Para los casos que realmente necesitan un procesamiento por debajo del segundo, como la detección de fraude actuando sobre transacciones individuales, esa lógica sigue perteneciendo a la propia capa de procesamiento de streams, no al lakehouse.
Los equipos adoptan watsonx.data sobre todo para tres tipos de problemas: consolidar la analítica entre sistemas que han ido acumulando data marts independientes con el tiempo, construir una única fuente gobernada tanto para los informes de BI como para los datos de entrenamiento de machine learning, y dar soporte a cargas de trabajo de generación aumentada por recuperación en las que la búsqueda vectorial con Milvus necesita convivir con los datos estructurados de los que extrae el contexto. Un cuarto caso, cada vez más habitual, es la analítica casi en tiempo real, donde las tablas Iceberg alimentadas por Kafka permiten que los dashboards y los modelos trabajen con datos de minutos de antigüedad en lugar de una carga por lotes nocturna.
Un quinto caso aparece específicamente en sectores regulados: usar el acceso sin copia para consultar datos que siguen viviendo en un sistema Db2 Warehouse o Netezza existente, de modo que se pueda introducir una capa de gobernanza y control de acceso sin completar antes una migración de datos completa. Esto permite abordar los requisitos de cumplimiento y auditoría con su propio calendario, separado del proyecto más grande y más lento de consolidar el almacenamiento.
La palabra «abierto» en un open lakehouse no es un detalle de marketing. Determina qué pasará con los datos dentro de cinco años, no solo hoy.
Como watsonx.data almacena los datos en Iceberg, Parquet, Avro y ORC en lugar de un formato propietario, los datos subyacentes siguen siendo legibles por cualquier motor que admita esos formatos, no solo por los de IBM. Cambiar de motor de consulta o añadir uno nuevo más adelante no exige reexportar ni reformatear los datos que ya existen.
Los formatos abiertos permiten que las mismas tablas se consulten con Presto, Spark u otros motores compatibles con Iceberg que un equipo ya pueda estar usando en otro sitio, sin duplicar los datos para cada herramienta. Esto importa sobre todo en organizaciones que han ido acumulando varias herramientas de analítica y data science con el tiempo y que, en la práctica, no pueden estandarizar en un único motor.
Los datos duran más que las herramientas que se construyen a su alrededor. Un formato de tabla abierto significa que, aunque los motores de consulta, los frameworks de IA y las herramientas de gobernanza cambien en los próximos años, los datos subyacentes no necesitan migrarse ni reescribirse para seguir el ritmo. La inversión está en la capa de datos, no en el motor de un proveedor concreto.
Adoptar watsonx.data no es un simple reemplazo directo de un warehouse o un lake existente. Exige decidir qué fuentes de datos se mueven primero, normalmente las que ya generan más duplicación o más problemas de gobernanza, y construir las rutas de ingesta, por lotes o en streaming, que mantendrán actualizadas las tablas Iceberg. Los equipos también tienen que decidir cómo se conectarán las herramientas de BI y los pipelines de machine learning existentes a los nuevos motores de consulta, algo que suele implicar actualizar cadenas de conexión y políticas de acceso más que reescribir las propias herramientas. Nada de esto es un proyecto de arrancar y sustituir. Se parece más a consolidar el acceso a datos que ya existen, fuente por fuente.
Suele haber tres decisiones que determinan si el despliegue avanza sin problemas. Primero, qué motor de consulta, Presto o Spark, gestiona cada carga de trabajo, porque enrutar todas las consultas por un único motor sin tener en cuenta su naturaleza suele dar peor rendimiento que asignar el motor adecuado a cada tarea. Segundo, cómo se corresponden las políticas de gobernanza de IBM Knowledge Catalog con los controles de acceso ya aplicados en los sistemas de origen, para que consolidar el acceso no lo relaje sin querer. Tercero, quién es responsable de los jobs de ingesta que alimentan las tablas Iceberg desde fuentes de streaming o por lotes, porque un pipeline de ingesta sin un responsable claro suele ser lo primero que falla en silencio cuando cambia el esquema de una fuente en origen.
En Mimacom diseñamos arquitecturas de lakehouse y streaming para clientes que necesitan que la analítica gobernada y las cargas de trabajo de IA funcionen sobre los mismos datos, no sobre copias separadas que mantienen equipos distintos. Esto incluye la capa de ingesta que conecta Kafka u otros event streams con las tablas Iceberg, el modelo de gobernanza que evita que un lakehouse se convierta en un data swamp sin control, y la ruta de migración desde un warehouse o un lake existente hacia una arquitectura abierta como watsonx.data.
La decisión de plataforma importa menos de lo que la mayoría de los equipos asumen al principio. Lo que realmente determina si un proyecto de lakehouse tiene éxito es si las rutas de ingesta, por lotes y en streaming, mantienen de forma fiable las tablas subyacentes actualizadas y gobernadas. Si aciertas con eso, la elección del motor de consulta o del framework de IA que va encima se convierte en una decisión mucho más fácil de revertir más adelante.
No necesariamente, y no de forma inmediata. watsonx.data puede consultar los datos donde están, en sistemas como Db2 Warehouse y Netezza, sin necesidad de migración, lo que permite a los equipos consolidar el acceso antes de decidir si retiran del todo un warehouse existente.
Los motores de consulta de watsonx.data no leen directamente los topics de Kafka. Una capa de streaming o de change-data-capture consume los eventos de Kafka y los escribe en tablas Iceberg, y los motores Presto y Spark de watsonx.data consultan después esas tablas como cualquier otro dataset del lakehouse.
Porque el formato determina qué pasa con los datos si la plataforma cambia. Iceberg, Parquet, Avro y ORC son legibles por muchos motores además de los propios de IBM, así que los datos siguen siendo utilizables aunque más adelante cambie el motor de consulta o la relación con el proveedor. La plataforma se puede sustituir. Un formato de datos propietario no.
Tanto si estás consolidando data marts existentes como si estás construyendo una ruta gobernada desde los streams de Kafka hasta las cargas de trabajo de IA, en Mimacom podemos diseñar e implementar la arquitectura de lakehouse que encaja con tus sistemas actuales.