Los productos de datos se entienden mejor cuando dejamos de mirar únicamente el pipeline y miramos a la persona que necesita utilizar el dato. En mi TFM me encontré con un caso que resume bastante bien ese cambio: la información existía, pero estaba repartida entre una intranet, fotografías y audios, un modelo de clasificación, Catastro, cartografía censal y varias tablas. Construir la ETL fue imprescindible. Sin embargo, el valor apareció cuando toda esa complejidad terminó convertida en un visor capaz de responder preguntas sin obligar al usuario a conocer joins, shapefiles, colas de mensajes o procesos de enriquecimiento.
De datos dispersos a productos de datos
Cuando empecé mi Trabajo Fin de Máster en Big Data & Analytics había una paradoja muy concreta encima de la mesa.
Podíamos saber cuántos equipos se habían vendido. Lo difícil era saber en qué ciudad, barrio o edificio habían terminado instalados.
El motivo tenía bastante lógica. El modelo era B2B: el fabricante vendía a distribuidores y estos, a su vez, a instaladores. La trazabilidad comercial terminaba mucho antes que la instalación física. Tener el dato de venta no significaba conocer la realidad del parque instalado.
Para reducir ese hueco se puso en marcha un proyecto de mapeo de instalaciones. Personas sobre el terreno capturaban fotografías de las placas de calle, audios, coordenadas y direcciones. A partir de esas capturas, un modelo de clasificación podía ayudar a identificar fabricante y, cuando correspondía, tecnología.
El problema es que aquello no producía un dataset limpio esperando tranquilamente a ser consultado.
- La información básica estaba repartida entre distintas tablas de la intranet.
- Las fotografías y audios residían en almacenamiento de objetos.
- La clasificación añadía nuevos atributos sobre fabricante y tecnología.
- La Sede Electrónica del Catastro podía aportar información del edificio y de la parcela.
- El INE y su cartografía de secciones censales permitían contextualizar geográficamente cada punto.
- Las fotografías de tablones de comunidad abrían incluso una vía adicional de extracción mediante OCR.
Había datos. Muchos. Pero estaban dispersos, tenían formatos distintos y no hablaban todavía el mismo idioma. Es el mismo patrón que aparece cuando varias aplicaciones trabajan como islas: antes de pedir más dashboards hay que conseguir que las fuentes compartan contexto, identificadores y reglas. En otro artículo explico esta idea desde la interoperabilidad entre sistemas, datos y servicios.
Este fue el problema real de partida: no necesitábamos simplemente almacenar más información. Necesitábamos conectar piezas que vivían en sistemas diferentes y transformarlas en algo coherente.
Por eso entró ETL.
El proceso sincronizaba periódicamente las placas nuevas o modificadas mediante una API, aplanaba información que en origen estaba distribuida por varias tablas, construía un DataFrame de Pandas, trataba nulos y fechas, normalizaba provincias y municipios, y dejaba los datos preparados para seguir enriqueciéndolos con información catastral, censal u OCR.
El proyecto empezó con unos pocos miles de registros. Después llegaron decenas de miles. Y finalmente el mapeo se acercó a las 100.000 placas. Lo que funcionaba de manera iterativa empezó a ser demasiado lento. Hubo que paralelizar, separar responsabilidades y terminar construyendo servicios Python en Docker comunicados mediante RabbitMQ.
A partir de ahí, la ETL ya podía hacer el trabajo pesado.
Sin embargo, entonces apareció otra pregunta:
¿Cómo usa todo esto una persona que solo quiere saber qué hay instalado en una zona?
La respuesta fue un visor de placas. Un mapa construido con Leaflet, filtros por fabricante, tecnología, provincia, municipio, sección censal o características del edificio, fichas de detalle, tablas exportables y estadísticas. El usuario podía moverse por València o Madrid, acercarse a un barrio, seleccionar una placa y consultar información que, por debajo, procedía de media docena de procesos distintos.
Con la perspectiva de hoy, esa evolución me parece bastante más interesante que la ETL en sí.
Los pipelines consiguieron que los datos llegaran. El visor consiguió que alguien pudiera utilizarlos.
TL;DR
Mi TFM empezó como un problema de integración: datos multimedia, geográficos y de negocio repartidos entre varias fuentes. ETL permitió sincronizarlos, normalizarlos y enriquecerlos. Sin embargo, el valor para el usuario apareció cuando esa complejidad quedó escondida detrás de un visor capaz de responder preguntas. Esa diferencia resume bien por qué los productos de datos empiezan donde el pipeline deja de ser el objetivo final.
Por qué ETL sigue siendo importante en una arquitectura de datos
En aquel proyecto ETL no era un adorno arquitectónico. Era lo que hacía posible pasar de una colección de capturas y fuentes heterogéneas a un conjunto de información que pudiera consultarse con cierta coherencia.
No creo, por tanto, que tenga sentido hablar de productos de datos empezando por declarar muerto a ETL.
ETL resolvió durante décadas un problema muy concreto: extraer información de sistemas operacionales, transformarla y llevarla a un lugar donde pudiera utilizarse para reporting, analítica o integración.
En mi TFM esa secuencia tenía una traducción bastante tangible: recuperar placas nuevas desde la intranet, unir datos dispersos, normalizarlos, enriquecerlos con fuentes públicas y persistirlos en un DataWarehouse.
Después llegaron, en la industria, ELT, los DAG, los warehouses cloud, los data lakes, los lakehouses y plataformas cada vez más sofisticadas. Mejoramos escala, paralelismo, capacidad de proceso, trazabilidad y velocidad.
El problema no está en esa evolución. Está en una idea que solemos arrastrar con ella: pensar que el resultado final del trabajo de datos es una tabla correctamente cargada.
Productos de datos: activos diseñados para casos de uso y consumidores concretos, con significado explícito, ownership, reglas de calidad, contrato y expectativas de servicio. Un producto de datos no se define por la herramienta que lo construye, sino por la necesidad que resuelve y las garantías que ofrece.
¿Cuál es la diferencia entre un pipeline y un producto de datos? Un pipeline transporta y transforma información entre sistemas. Un producto de datos añade propósito, consumidores, semántica, calidad, ownership, contrato y ciclo de vida. El pipeline puede formar parte del producto, pero no es el producto.
Productos de datos: un pipeline tiene un destino, un producto tiene un usuario
En el proyecto de mapeo, la arquitectura podía resumirse de forma simplificada así:
Desde el punto de vista técnico, cada flecha tenía mucho trabajo detrás: APIs, SQL, Pandas, normalizaciones, XML, WFS, web scraping, GeoPandas, colas, contenedores y persistencia.
Desde el punto de vista del usuario, la pregunta era mucho más sencilla:
¿Qué hay instalado en esta zona, de qué fabricante es y qué sabemos del edificio?
Ahí está el cambio de perspectiva: la arquitectura explica cómo se produce el dato; el producto explica para qué merece la pena producirlo.
El pipeline se preocupa por que una referencia catastral llegue a una tabla. El usuario quiere saber cuántas viviendas tiene el edificio. El pipeline necesita localizar una sección censal. El usuario quiere filtrar un barrio. El pipeline trata fotografías, coordenadas y clasificaciones. El usuario quiere hacer clic sobre un punto del mapa y entender qué hay allí.
Los productos de datos empiezan a tomar forma cuando dejamos de formular el trabajo exclusivamente como:
¿Cómo llevo estos datos hasta el DataWarehouse?
y añadimos otra pregunta:
¿Qué necesita resolver la persona que va a consumirlos?
- ¿Quién va a utilizar estos datos?
- ¿Qué decisión o análisis soportan?
- ¿Cuándo deben estar actualizados?
- ¿Qué significa exactamente cada campo?
- ¿Qué calidad necesitamos?
- ¿Quién responde cuando dejan de representar la realidad?
Productos de datos y calidad: el pipeline termina, ¿y el dato?
Una de las cosas que aprendimos al ampliar el mapeo fue que un proceso puede ejecutarse correctamente y seguir generando un resultado equivocado.
Había placas con coordenadas erróneas. A veces por la precisión de versiones antiguas de la aplicación de captura. Otras, porque la ubicación introducida durante el mapeo no era correcta.
Eso tiene una consecuencia interesante en una arquitectura de enriquecimiento geográfico.
Si la coordenada de entrada es incorrecta, el código puede funcionar perfectamente. La API responde. El XML es válido. El parser no falla. La fila se actualiza.
Y aun así podemos haber asociado la placa al edificio equivocado.
También aparecieron otras casuísticas: puntos situados en jardines o solares sin las propiedades esperadas de un edificio, límites de peticiones del Catastro o diferencias de nomenclatura geográfica que obligaban a normalizar municipios y provincias para poder cruzarlos con datos del INE.
La disponibilidad del pipeline y la calidad del dato son dos cosas distintas. Un sistema puede no lanzar una sola excepción y propagar un error de ubicación, una clasificación incorrecta o una asociación catastral equivocada hasta el consumidor final.
Por eso, en los productos de datos empiezan a importar otras dimensiones: freshness, completeness, validity, uniqueness, consistency y accuracy.
Además, algunas de ellas no pueden evaluarse mirando únicamente logs. Para comprobar que una placa estaba realmente donde decían sus coordenadas tuvimos que contrastar casos con herramientas GIS y con información pública del Catastro.
Las tablas no deberían convertirse en APIs por accidente
Esta es una de las situaciones que más se repite en plataformas de datos que han crecido de forma orgánica.
- El equipo A crea una tabla para resolver una necesidad.
- El equipo B la descubre.
- Le resulta útil y empieza a depender de ella.
- Después llega otro consumidor.
- Y otro.
Nadie decidió que esa tabla fuera una interfaz pública. Pero en la práctica lo es.
ALTER TABLE customers
DROP COLUMN legacy_segment;Y aparecen siete procesos rotos.
La persona que hizo el cambio no rompió ninguna API documentada. No cambió un endpoint ni retiró una versión pública. Solo eliminó una columna que parecía antigua. Este tipo de dependencia oculta también aparece en sistemas heredados; por eso, al modernizar software legacy sin detener el negocio, crear fronteras y contratos estables suele ser más importante que cambiar de tecnología.
El problema es que la organización llevaba meses tratándola como una interfaz sin haberlo admitido. El contrato existía. Solo estaba escrito en las dependencias de otros equipos.
Ahí entra el data contract
Un contrato de datos hace explícito aquello que antes estaba implícito: esquema, tipos, significado, expectativas, propietario y evolución. La documentación de dbt sobre model contracts es un buen ejemplo de cómo convertir la forma esperada de un dataset en garantías verificables para los consumidores.
customers_v1
──────────────────────────
customer_id : string
country : ISO-3166
created_at : timestamp
status : enum
Freshness: < 2 h
Completeness: > 99.9 %
Owner: Customer Platform
Version: v1Una tabla compartida se parece mucho más a una API de lo que solemos admitir. Tiene consumidores, compatibilidad, cambios, expectativas y fallos aguas abajo. La diferencia es que muchas veces la gobernamos bastante peor.
Qué necesitan los productos de datos para ser fiables
No hay una plantilla universal para los productos de datos y tampoco creo que la necesitemos. La prueba práctica es más sencilla: si un dataset es importante para otros, deberíamos poder responder con claridad a unas cuantas preguntas.
Semántica
Qué representa realmente cada métrica y dimensión.
Contrato
Qué esquema y comportamiento pueden esperar los consumidores.
Calidad
Qué condiciones debe cumplir el dato para considerarse utilizable.
Ownership
Quién responde por el significado y quién por la implementación.
La semántica merece especial atención. Un número como revenue = 1.284.392 parece inequívoco hasta que preguntas si es bruto o neto, si incluye IVA, si representa facturado o cobrado, cómo trata devoluciones, en qué moneda consolida o qué zona horaria utiliza.
Una métrica útil debería poder describirse de forma mucho más concreta:
net_revenue_daily
Ingresos netos facturados,
sin IVA,
descontando devoluciones,
consolidados en EUR,
por fecha de factura.
La semántica no es documentación auxiliar. Forma parte de la interfaz del dato.
Cuando el mapa empezó a responder preguntas, apareció la semántica
En el visor había filtros que parecían muy simples: fabricante, tecnología, municipio, sección censal, año de construcción, número de viviendas.
Pero cada uno escondía una pequeña historia de procedencia y significado.
- Tecnología podía proceder de la clasificación automática de la placa.
- Número de viviendas se obtenía a partir de la información catastral de la parcela.
- Sección censal exigía situar un punto dentro de uno de los polígonos geográficos publicados por el INE.
- Municipio y provincia necesitaban normalización para que distintas fuentes utilizaran una nomenclatura compatible.
Para el usuario, sin embargo, todo eso terminaba convertido en un selector.
Y eso cambia la responsabilidad. En cuanto una persona filtra por “número de viviendas” o “tecnología” para hacer un análisis, esos campos ya no son simples columnas. Son una interfaz con significado.
La semántica empieza a importar justo cuando dejamos de mirar el dato como ingenieros y alguien empieza a utilizarlo para entender la realidad.
El equipo de datos puede implementar una definición. No debería inventarla. Cuando un campo representa un concepto del dominio, alguien debe poder explicar qué significa, de dónde procede y qué limitaciones tiene.
Ahí aparece el ownership. No como una etiqueta decorativa en un catálogo, sino como la respuesta a una pregunta muy concreta: ¿quién responde cuando el dato técnicamente existe, pero ya no representa lo que el consumidor cree que representa?
SLO y calidad: expectativas para los datos
En software estamos acostumbrados a definir disponibilidad, latencia o tasa de error. En datos podemos expresar expectativas parecidas. En el caso del mapeo, por ejemplo, la pregunta no era solo si el proceso diario había terminado, sino si las placas estaban sincronizadas, correctamente geolocalizadas y suficientemente enriquecidas para aparecer en el visor.
| Dimensión | Ejemplo | Pregunta que responde |
|---|---|---|
| Freshness | Sincronización diaria completada | ¿Están incorporadas las últimas placas? |
| Completeness | Campos críticos presentes | ¿Tenemos la información mínima para mostrar la placa? |
| Accuracy | Coordenadas y clasificación verificables | ¿Representa correctamente la instalación real? |
| Consistency | Municipios y provincias normalizados | ¿Podemos cruzar fuentes sin ambigüedad? |
| Delivery | Disponible antes del uso de negocio | ¿Llega cuando el consumidor lo necesita? |
Además, esto evita sobrediseñar. En aquel proyecto los datos llegaban en bloques y la actualización periódica era suficiente para el caso de uso. No necesitábamos convertir el visor en un sistema de streaming en tiempo real solo porque técnicamente fuera posible.
El producto define la necesidad. La arquitectura debería venir después. Cuando ocurre al revés, terminamos justificando tecnologías en lugar de resolver problemas.
El pipeline pasa a ser una implementación
Para mí, aquí aparece el cambio conceptual más interesante.
En el TFM podía cambiar la forma de orquestar los procesos, reescribir un extractor o sustituir la tecnología de persistencia. Ninguno de esos cambios alteraba la necesidad principal: que alguien pudiera abrir el visor y entender qué había instalado en una zona con datos suficientemente fiables.
Durante mucho tiempo hemos hablado de una nueva capacidad de datos y hemos saltado inmediatamente al pipeline que había que construir.
Pero un producto de datos puede distribuirse de varias formas según el consumidor.
Por ejemplo, un batch puede alimentar reporting; un stream puede soportar operaciones en tiempo real; y una API puede servir integraciones. En cambio, una tabla analítica puede facilitar exploración. Un mismo producto puede necesitar varias de esas salidas.
En software nadie diría que su producto es “este cron de PHP”. El cron puede ser crítico, pero sigue siendo un detalle de implementación.
Con ETL, por tanto, ocurre lo mismo.
ETL no ha muerto. Simplemente ha dejado de ser el centro.
De scripts a productos de datos
La evolución no suele ocurrir con una gran migración. En aquel proyecto, de hecho, ocurrió de una forma bastante reconocible: primero scripts y pruebas de concepto; después procesos repetibles; más tarde servicios distribuidos y, finalmente, una aplicación que escondía toda esa complejidad al usuario.
Nivel 1: scripts
Los primeros prototipos de extracción eran procesos directos que permitían validar que podíamos obtener y enriquecer la información. Es la fase correcta cuando todavía estás comprobando la hipótesis.
Nivel 2: pipelines
Al crecer el volumen, la extracción dejó de ser una prueba y se convirtió en un proceso repetible: sincronización, normalización, Catastro, datos censales, OCR y actualización del DataWarehouse.
Nivel 3: plataforma
La separación en contenedores, las colas RabbitMQ, el orquestador y el servicio de persistencia empezaron a funcionar como capacidades compartidas sobre las que podían ejecutarse distintos enriquecimientos.
Nivel 4: productos
La unidad de diseño deja de ser solamente el proceso técnico. En mi caso, el paso visible fue el visor: un punto de entrada que convertía el parque de instalaciones en algo consultable por personas con necesidades concretas.
No necesitas construir un Data Mesh
Hablar de productos de datos suele llevar rápidamente a Data Mesh. Es comprensible: ponemos nombre a un problema y enseguida buscamos una arquitectura completa que lo resuelva. Yo no empezaría por ahí.
Puedes aplicar pensamiento de producto a los datos con tres ingenieros, PostgreSQL y dbt. No necesitas veinte equipos de dominio, Kafka, Kubernetes, un lakehouse ni una plataforma federada para empezar.
Empieza por algo bastante menos vistoso:
- Define qué representa el dato.
- Identifica quién lo consume.
- Asigna un owner de negocio y una responsabilidad técnica.
- Documenta el esquema estable.
- Explicita la semántica de las métricas importantes.
- Define freshness y reglas básicas de calidad.
- Versiona los cambios que puedan romper consumidores.
Solo con eso cambia bastante la conversación. Ya no preguntas únicamente si el pipeline ha ejecutado. Preguntas si el dato sigue cumpliendo aquello para lo que alguien depende de él.
Cómo convertiría hoy aquel dataset en un producto de datos
Cuando desarrollé el TFM hablaba de procesos ETL, DataWarehouse y de una aplicación de visualización. Hoy añadiría una capa conceptual más.
Definiría explícitamente algo parecido a un producto de datos del parque de instalaciones.
Y respondería siete preguntas antes de añadir otra tabla o construir otro pipeline:
- Propósito: ¿qué necesidad resuelve?
- Consumidores: ¿quién depende de este dato?
- Owner: ¿quién responde por su significado?
- Esquema: ¿qué campos forman la interfaz estable?
- Semántica: ¿qué significa cada atributo relevante?
- Freshness: ¿cuándo debe estar actualizado?
- Calidad: ¿qué condiciones debe cumplir para poder confiar en él?
Después añadiría tests, monitorización, versionado y documentación donde realmente aporten valor.
No hace falta rediseñar toda la plataforma. El primer cambio es mental: dejar de medir el éxito únicamente por lo bien que se mueve el dato y empezar a medirlo también por lo bien que alguien puede utilizarlo.
ETL sigue ahí. Lo que cambia es el centro
Cuando terminé aquel TFM, una parte importante del orgullo técnico estaba en la arquitectura.
Habíamos pasado de procesos más simples e iterativos a consumidores paralelos, servicios Python encapsulados en Docker, colas RabbitMQ y un sistema capaz de enriquecer los datos varias veces más rápido. El procesamiento llegó a pasar, en las pruebas descritas en la memoria, de aproximadamente una placa por segundo a hasta diez.
Eso importaba. Sin esa ingeniería, el sistema no habría escalado.
Pero, visto con distancia, la imagen que mejor resume el valor del proyecto no es un diagrama de contenedores.
Es el mapa.
Un usuario desplazándose por un barrio de València, viendo cientos de placas agrupadas, filtrando por fabricante o tecnología, activando edificios, consultando una ficha y obteniendo contexto sobre una instalación sin saber que, detrás de ese clic, habían intervenido una API, varias tablas, fotografías, un clasificador, Catastro, datos geográficos, procesos de normalización y un DataWarehouse.
Ese es el cambio que me interesa hoy.
ETL sigue siendo fundamental. Los pipelines siguen siendo fundamentales. También las transformaciones, la observabilidad, los warehouses y la infraestructura.
Pero no son necesariamente el resultado final.
El pipeline consiguió reunir el dato. El visor consiguió convertirlo en una herramienta.
Con la terminología que utilizaría hoy: el pipeline era una implementación. El producto era la capacidad de responder preguntas con datos utilizables.
ETL no ha muerto.
Simplemente ha dejado de ser el centro.
La señal de madurez no es tener más pipelines. Es conseguir que toda la complejidad necesaria para construir el dato desaparezca para quien solo necesita utilizarlo.
Una prueba sencilla
Escoge un dataset que ya utilice más de un equipo. Intenta explicar, sin mirar el pipeline, qué problema resuelve, qué significa, cuándo está disponible y quién responde por él. Si esas respuestas cuestan más que explicar el DAG, probablemente todavía estás pensando en pipelines antes que en productos.
Preguntas frecuentes sobre productos de datos
¿Qué es un producto de datos?
Es un activo de datos diseñado para consumidores y casos de uso concretos, con semántica, ownership, contrato, calidad, documentación y expectativas de servicio explícitas.
¿Un producto de datos sustituye a ETL?
No. ETL, ELT, batch, streaming o APIs siguen siendo mecanismos necesarios. La diferencia es que pasan a ser detalles de implementación de un producto cuyo objetivo es resolver una necesidad de datos.
¿Qué diferencia hay entre un dataset y un producto de datos?
Un dataset puede ser simplemente una colección de datos. Un producto de datos añade propósito, consumidores, semántica, ownership, garantías de calidad, contrato y un ciclo de vida gestionado.
¿Necesito Data Mesh para trabajar con productos de datos?
No. Puedes empezar aplicando pensamiento de producto a uno o dos datasets críticos sin cambiar tu arquitectura organizativa ni adoptar una plataforma Data Mesh.
¿Qué debería contener un data contract?
Como mínimo, el esquema estable, tipos, reglas relevantes, versión, owner y expectativas que afecten a los consumidores. En productos críticos también puede incluir freshness, completeness y políticas de compatibilidad.
¿Cuál es la diferencia entre ETL y los productos de datos?
ETL describe cómo extraemos, transformamos y cargamos información. Los productos de datos describen qué necesidad resolvemos con esos datos, quién los consume, qué significan y qué garantías ofrecemos. ETL puede ser una parte esencial de la implementación sin ser el resultado final.
¿Cuándo conviene tratar un dataset como producto de datos?
Cuando tiene consumidores recurrentes, soporta decisiones o procesos, genera dependencias aguas abajo, necesita estabilidad semántica o requiere garantías explícitas de calidad y disponibilidad.
Deja una respuesta