Open Standards for Data Products

El ponente

Simon Harrer se describe como un ingeniero de software de corazón que hace unos cinco años se pasó al mundo de los datos. Es coautor de "Java by Comparison" (que hoy forma parte de los datos de entrenamiento de varios modelos de lenguaje, como señala con una sonrisa) y tradujo al alemán "Data Mesh", de Zhamak Dehghani. La edición impresa alemana va a todo color, cosa que ninguna original en inglés hace.

Hoy es co-founder y CEO de Entropy Data, una pequeña startup que construye un marketplace de productos de datos y una capa de metadatos, con clientes en todo el mundo, seis personas y un montón de agentes haciendo el trabajo. Forma parte del Technical Steering Committee de Bitol en la Linux Foundation, contribuye a Open Semantic Interchange (la iniciativa de estandarización que puso en marcha Snowflake) y desarrolla herramientas open source alrededor de todo ello.

También mantiene data-landscape.com, un panorama abierto de los estándares abiertos del mundo de los datos. Merece la pena echarle un vistazo, dice: es todo abierto y gratuito.

El plan

Tres cosas. Primero, asomarnos al futuro a modo de motivación: ¿qué aspecto podría tener? Después, aprender sobre estándares, los abiertos: por qué existen y qué pueden hacer.

Y por último, hacer historia juntos. Ten el móvil a mano e inicia sesión en GitHub, le dice Simon a la sala, porque lo vamos a necesitar antes de terminar.

Un adelanto del futuro (solo un aperitivo)

La pregunta que enmarca todo: ¿y si ya estuviéramos usando estándares abiertos para productos de datos, y los viviéramos de verdad? Para responderla, Simon lanza una demo en vivo (con una grabación de respaldo lista, por si acaso). En un mismo directorio hay dos archivos: un Data Contract conforme al estándar que describe los datos que quiere ofrecer, y un archivo de producto de datos en ODPS que describe la caja del diagrama de arquitectura, con su propósito, su dominio, sus Output Ports y sus enlaces hacia la capa semántica.

Entonces arranca el agente de programación: claude --dangerously-skip-permissions, "haz que este producto de datos sea una realidad". Él solo escribió qué quiere. El agente se encarga del resto, y la construcción tarda unos 15 minutos.

Así que lo deja corriendo en segundo plano, con los tokens trabajando duro para nosotros, y pasa al verdadero tema de la charla. Quédate con esta imagen. La recompensa llega al final.

Primero: ¿qué es un producto de datos?

El público de una conferencia de datos ya se lo sabe, así que Simon va rápido. Un producto de datos es pensamiento de producto aplicado a los datos: optimizas para tus consumidores, asumes la propiedad, tienes un equipo que responde por él y construyes interfaces de las que te haces responsable. Es el segundo de los cuatro principios de Data Mesh.

El Data Product Canvas, gratuito y open source, es donde lo diseñas sobre el papel, en un taller con gente, partiendo del caso de uso. Simon llama al canvas terminado la "partida de nacimiento" del producto.

Como arquitecto de software de corazón, también ve un producto de datos como una unidad arquitectónica: recibe cosas por sus Input Ports, hace un montón de trabajo por dentro y expone resultados por sus Output Ports. En la demo inicial solo especificó el Output Port y la caja, y luego soltó al agente de programación.

¿Y qué es un estándar?

El xkcd de rigor lo explica muy bien. Necesitamos estándares para ponernos de acuerdo en algo y recortar complejidad: el único formato de fecha correcto es el estándar ISO, y todo lo demás está mal. Lo mismo con la cuenta atrás antes de empezar, "3, 2, 1, ya", para que nadie dude de si la acción arranca en el "uno" o después.

Y el riesgo de rigor: hay 14 estándares, un actor grande quiere entrar, y ahora hay 15. Pasa en todas partes, y el mundo de los datos no es una excepción. Útil cuando recorta complejidad, doloroso cuando solo añade otro competidor.

Qué hace bueno a un estándar

Simon plantea cuatro dimensiones, y en todas quiere el lado izquierdo:

• De facto frente a de iure (uso): si todo el mundo simplemente lo usa, en la práctica ya es un estándar, aunque ningún organismo lo declare así.
• Iniciativa frente a proveedor (propiedad): mejor cuando hay una iniciativa detrás, para que el poder no quede en manos de una sola empresa capaz de controlarlo por completo.
• Muchos frente a uno (control): ¿el poder está repartido entre quienes contribuyen, o lo tiene una única parte?
• Abierto frente a de pago (coste): ¿cualquiera puede leerlo y adoptarlo, o hay que pagarle a un organismo solo para leer la especificación?

Los estándares por los que merece la pena apostar se inclinan a la izquierda en las cuatro: usados de verdad, en manos de la comunidad, con gobernanza amplia y abiertos.

Un mapa de los estándares abiertos

Los estándares aparecen por todas partes en un producto de datos: para describirlo, para leer otros productos, en el procesamiento, el almacenamiento, la planificación, la monitorización y la observabilidad. Para ver todo el panorama de un vistazo, Simon mantiene data-landscape.com, un mapa interactivo y con criterio de los estándares de datos y metadatos, clasificados como adoptar, situacional, evaluar o precaución.

Para esta charla se centra en tres que conoce de cerca y sobre los que puede hablar con honestidad: ODCS, ODPS y OSI. Los demás solo los conoce desde fuera.

¿Qué es un Data Contract?

Un Data Contract existe para generar confianza. Un productor ofrece datos, un consumidor quiere usarlos, y el contrato que hay en medio recoge las promesas y garantías del productor sobre ese conjunto de datos (que puede ser varias tablas). Cubre estructura, semántica, propiedad, calidad y condiciones de uso.

La necesidad de Data Contracts surgió en paralelo en muchas empresas hace unos años. Cada una montó su propio formato en YAML, JSON, Excel, Word o Confluence, pero el problema de fondo siempre era el mismo: capturar las garantías que da un proveedor sobre una oferta de datos. (Más en ¿Qué es un Data Contract?)

La gran fusión de formatos

Esta es la historia. PayPal liberó su formato de Data Contract como versión 2.2 y lo donó a la Linux Foundation. La empresa de Simon también tenía un formato competidor, igual que muchas otras. Él se sumó al esfuerzo de estandarización, y el grupo reformó la versión de PayPal (que estaba pensada para una única plataforma de datos, porque no todo el mundo es PayPal ni trabaja solo con BigQuery) para que encajara en cualquier empresa.

Con la versión 3.1 fusionaron los dos linajes y retiraron el suyo, porque un estándar fuerte vale más que dos compitiendo. ODCS 3.2 está a la vuelta de la esquina. La lección: en lugar de convertirlo en 15 estándares, los bandos se unieron en uno solo, gobernado en Bitol.

Por dentro del Open Data Contract Standard

ODCS v3 lleva información de esquema, calidad de datos, precios (está en el estándar, aunque Simon nunca ha visto a nadie usarlo, una discusión académica divertida), propiedad y equipo, seguridad, acuerdos de nivel de servicio, infraestructura y más. Puedes leerlo todo en datacontract.com.

La parte interesante es el esquema: guarda cosas como la clasificación de los datos y las marcas de PII, valores de ejemplo y comprobaciones de calidad de datos integradas. Una comprobación puede imponer un conjunto de valores válidos; otra puede ser SQL puro que se ejecuta como control de calidad conforme al estándar. También puedes registrar quién es el dueño del producto y cómo contactarlo, las condiciones de uso (qué puedes y qué no puedes hacer con los datos, con enlaces a una política de privacidad o a la licencia si son datos comprados) y SLAs como retención y frescura.

Y dice dónde viven los datos. En el ejemplo es Postgres sobre Supabase, y a partir de ODCS 3.2 también hay una ubicación Hana. (Contexto: Open Data Contract Standard.)

¿Y ahora qué? Automatizarlo todo

¿Por qué merecía la pena el estándar? Porque no tienes que inventarte el formato y puedes colgarle lógica encima. Son los mejores metadatos que puedes tener sobre un conjunto de datos, sostiene Simon, y no hay nada mejor, sobre todo cuando además los enlazas con una ontología. En cuanto un contrato es legible por máquinas, impulsa todo lo demás:

• Generación de código: Java, Pydantic, modelos dbt, SQL DDL
• Tests: comprobar los datos en Hana o en cualquier otro sistema contra el contrato, en cada punto del ciclo de vida, más detección de cambios incompatibles y monitorización
• Distribución de metadatos: enviarlos a metastores, catálogos y marketplaces
• Aprovisionamiento de infraestructura: Output Ports, Input Ports, anonimización, control de acceso
• Colaboración y gobernanza: convenciones de nombres, evolución del esquema, acuerdos de uso, flujos de aprobación

Lo pueden usar las personas, lo pueden usar los sistemas deterministas y también los agentes, que es exactamente lo que está haciendo ahora mismo el que sigue construyendo en segundo plano.

Los estándares abiertos traen herramientas abiertas

Un estándar abierto te permite construir herramientas abiertas que trabajan codo con codo con él, así que adoptar el estándar te da la automatización casi gratis. La Data Contract CLI, open source (unas 900 estrellas en GitHub), lee el YAML, se conecta a todos los proveedores de datos habituales, ejecuta las comprobaciones y te devuelve un informe de tests que puedes llevarte a cualquier parte. También importa y exporta, así que llegas rápido a un contrato y sigues trabajando desde ahí.

Estándar y herramientas están fuertemente acoplados. La gráfica del historial de estrellas muestra a los dos subiendo juntos hacia las 1.000: la CLI fue por delante durante un buen tramo, ayudada por una reescritura de Go a Python (el mundo de los datos vive en Python), mientras que el estándar dibuja un palo de hockey al final. Al principio, un estándar sin herramientas no vale nada, porque tienes que construirlo todo tú; dale a la gente la automatización gratis y el estándar cuaja.

Un editor y el Excel de rigor

Como no todo el mundo domina YAML, también existe un Data Contract Editor open source con vista de formulario, vista de YAML con previsualización en vivo y vista de diagrama que funciona como una herramienta de modelado de datos.

Y el Excel de rigor. Simon esperaba librarse de él, pero la realidad no paraba de mostrar empresas montando sus propias hojas de cálculo para capturar contratos ODCS, así que el equipo construyó una con conversión automática de Excel a YAML. Resultó ser muy popular. Apuesta por el estándar y te llevas el editor, la plantilla de Excel y la automatización de la CLI como paquete. Si quieres que ganen los estándares abiertos, arrima el hombro en las herramientas, porque son las que impulsan la adopción, y la adopción es lo que empuja también a los proveedores a darles soporte.

El Open Data Product Standard

Los Data Contracts no hablan de productos de datos; un contrato es en realidad la interfaz, el conjunto de datos que compartes. Un producto de datos, tal y como lo ve Simon, puede exponer varios contratos en varias plataformas a la vez, y hay un estándar que le encaja bien: ODPS.

Un producto de datos apunta a un contrato por cada Output Port (lo que comparte) y por cada Input Port (aquello de lo que depende). En el ejemplo, un producto Orders tiene cuatro Output Ports: orders en versión 1 y en versión 2, más las variantes sin PII, porque los datos sin información personal son mucho más fáciles de conseguir, mientras que los ports sensibles quedan detrás de un proceso de aprobación manual que puede tardar semanas. Un Input Port referencia un topic de Kafka que un pipeline convierte en la oferta.

Como los ports apuntan a contratos, obtienes lineage a nivel de producto: un servicio de pedidos alimenta el producto Orders, que a su vez alimenta a otros consumidores. (Ver ¿Qué es un producto de datos?)

Lo que viene en Bitol

Un rápido levantar de manos: alrededor del 10 % de la sala ya usa ODCS. ODCS 3.2 aterriza pronto, ODPS 1.1 está en camino y el grupo de trabajo está redactando más estándares en torno a la observabilidad, los dominios de datos, los acuerdos de acceso y la orquestación.

Lleva su tiempo, apunta Simon. El comité no se reúne a menudo y todos hacen esto además del trabajo que de verdad paga las facturas.

Un aviso: hay dos cosas llamadas ODPS

Ojo con la confusión: hay dos estándares llamados ODPS, ambos en la Linux Foundation. Uno forma parte de la familia Bitol, funciona bien con ODCS a través de los Input Ports y puede referenciar varios contratos. El otro va por libre, no tiene el concepto de Input Port y se corresponde con un único ODCS.

Encarnan ideas genuinamente distintas de lo que es un producto de datos. El de Bitol es más flojo en precios e internacionalización; el otro es fuerte en planes de precios e i18n. Uno se llama Standard y el otro Specification. Es, admite Simon, una verdadera lástima.

Open Semantic Interchange

Los productos de datos aterrizan en un marketplace, que es adonde van los agentes a preguntar qué existe, así que esa capa también necesita estándares, o vuelves a los formatos de metadatos propietarios. El tercer estándar es la semántica: ¿qué significan los datos? Open Semantic Interchange (OSI), muy impulsado por Snowflake, empezó con el modelo semántico clásico: datasets, relaciones y, sobre todo, métricas. Tus datos ya están en Snowflake, Databricks, Oracle o SAP, y encima les pones una capa semántica.

Lo que llama la atención es lo AI-first que es. El formato lleva instrucciones, sinónimos y ejemplos, de forma que rellenarlos hace que los agentes funcionen mucho mejor: dale instrucciones a tus metadatos y los agentes sacarán más partido de ellos. Por lo demás se parece bastante a un contrato: describes datasets, relaciones y ahora métricas, por ejemplo total_revenue como la suma de los importes de los pedidos, o full_name como nombre más espacio más apellido.

Y, como en todas partes, hay herramientas open source, incluido un editor para modelarlo. (Más: Semántica.)

Los estándares aprenden unos de otros

ODCS y OSI son en realidad bastante parecidos. La comparativa muestra dónde va por delante cada uno: OSI gana en métricas, campos dinámicos y contexto de IA, mientras que ODCS cubre las condiciones de uso, la calidad y los SLAs.

Las diferencias se van cerrando a través de los comités. El contexto de IA llega en ODCS 3.2, junto con los campos dinámicos y las métricas como el ejemplo de full_name. Los estándares están creciendo juntos y aprendiendo unos de otros, y da gusto verlo.

Ontologías y un cambio de nombre a Apache Ossie

OSI tiene muchos grupos de trabajo, y uno especialmente activo sobre ontologías, que a Simon le gusta mucho. Todo está muy verde todavía (versión 0.2.0.dev), pero cuenta con un fuerte respaldo de Snowflake. Puedes modelar una ontología de conceptos y relaciones, con internacionalización, y enlazar la columna de un contrato con un concepto.

Un guiño para el público informático: llamar "OSI" a tu iniciativa cuando ya existe un famoso modelo de redes con ese nombre es una jugada atrevida. Parece que están de acuerdo, porque justo ayer donaron la iniciativa a la Apache Foundation y la rebautizaron como Apache Ossie. Hay muchos proveedores detrás, Entropy Data incluida, así que el formato viene en camino.

El futuro ya está aquí

Volvemos al agente que corría en segundo plano. Ha tardado 17 minutos y 57 segundos, y ya está listo. El prompt que se lanzó fue simplemente "implementa el producto de datos", y Simon solo había dejado escrito qué quería.

El resultado es un proyecto dbt completo con modelos de entrada, de salida e intermedios. Por su cuenta, el agente descubrió que necesitaba datos de otros tres productos de datos (que Simon nunca especificó), recuperó sus descripciones ODPS y sus contratos ODCS, evaluó cuáles necesitaba, solicitó acceso y después construyó y ejecutó el pipeline. El marketplace muestra ahora el nuevo producto mapeado contra esos tres upstreams, con trazas de OpenLineage y lineage a nivel de columna.

¿Por qué funciona? Por los estándares abiertos. El contrato y el producto están descritos en formatos estándar, el agente habla con el marketplace y con las herramientas por MCP, usa la Data Contract CLI internamente para verificar su salida contra el contrato, y un repositorio de skills codifica cómo construye productos de datos esta empresa (Snowflake, dbt, OpenLineage). Cada caja de la primera diapositiva es hoy un estándar abierto y real, y el agente se encargó de teclear.

Vamos a hacer historia

Aquí viene la parte que la sala puede hacer junta. Justo antes de la charla, el Open Data Contract Standard estaba en 978 estrellas de GitHub. Con 1.000 alcanza el siguiente nivel y puede graduarse dentro de la Linux Foundation. Así que esta es tu oportunidad: 22 estrellas, seguro que podemos con eso.

Y la sala lo hizo. Salieron los móviles, el contador fue subiendo en directo, 998, y luego por encima de la línea.

Lo conseguimos de verdad. En menos de cinco minutos, la comunidad de Bitol llevó al Open Data Contract Standard de 978 a más de 1.000 estrellas en GitHub, en directo desde la sala. Con eso queda superado el listón para que ODCS se gradúe dentro de la Linux Foundation. Gracias a todos los que escanearon el código QR y dieron su estrella. Juntos podemos mover montañas.

Si estos estándares te resultan útiles, dale una estrella al repo de ODCS y ayuda a que siga creciendo.