OpenMetadata — qué es para nosotros, y qué NO puede ser
Ejercicio de posicionamiento pedido por el owner (2026-08-03). «Collate usa OM como producto principal porque trabajan únicamente en el layer de la metadata. Nosotros, al trabajar con datos, nos parecemos mucho más a Snowflake o watsonx.data. ¿Usaría Snowflake OM por debajo? ¿Para qué lo usaría? Nuestro deber es llevar la arquitectura al siguiente nivel, y no hay ningún motivo por el que no podamos hacerlo de forma nativa.»
Este documento contesta eso y precisa la frontera N2 de semantic-context-graph.md, que hoy está enunciada de una forma que es correcta para los sistemas ajenos y al revés para los nuestros.
Cruza con: agentic-data-cloud.md (el norte) · index-catalog-sota.md (dónde somos fuertes) · index-catalog-c2-usage-approach.md (el primer sitio donde esta frontera decide código) · trino-openmetadata-warehouse.md (lo medido).
1 · El eje que lo explica todo: ¿estás en el camino del dato?
No es «metadata vs datos». Es posición. Y de la posición sale, por deducción, todo lo demás: qué puedes saber, con qué exactitud, con cuánto retardo y qué puedes impedir.
| ¿En el camino? | Cómo obtiene los hechos | Qué puede hacer con ellos | |
|---|---|---|---|
| OpenMetadata / Collate | ❌ Fuera | Infiere: parsea query logs, muestrea perfiles, reconstruye linaje del SQL, ingiere por lotes | Describir, avisar, puntuar. Nunca impedir |
| Snowflake · Databricks · watsonx.data | ✅ Dentro | Emite: el motor escribe ACCOUNT_USAGE / system tables / query history como subproducto de ejecutar | Describir y aplicar |
| Carbon | ✅ dentro de lo nuestro · ❌ fuera de lo del cliente | Junction ve cada resolución y cada commit | Aplicar en lo nuestro; sólo describir lo ajeno |
El mérito de OpenMetadata es enorme precisamente porque está fuera. Han construido un modelo de entidades, un motor de linaje, calidad, gobernanza y ~700 especificaciones JSON Schema sin poder tocar el dato. Eso es ingeniería de primera. Pero es también su techo: «0th percentile = nunca consultada» es un percentil porque es una estimación a partir de logs; no puede ser un conteo, porque nadie le contó nada.
Nosotros estamos dentro. Y ahí está la respuesta al «siguiente nivel»: no consiste en hacer lo mismo que OM mejor. Consiste en emitir lo que ellos sólo pueden estimar.
2 · ¿Usaría Snowflake OpenMetadata por debajo?
No como metastore — y la evidencia es su propia conducta: Snowflake construyó Horizon (su catálogo de gobernanza) y donó Polaris a la ASF. Cuando has pagado el coste de estar en el camino, delegar el registro de lo que pasa en un sistema que no está en el camino es regalar tu única ventaja.
Pero la pregunta interesante no es ésa. Es:
¿Qué le da OpenMetadata a una plataforma que SÍ posee el plano de datos?
Tres cosas reales, y una que no.
✅ ① La flota de conectores — 130+ sistemas ajenos
Es la pieza que no es producto para nosotros construir, y la que hace viable el concepto C-fed (federación) de index-catalog-sota.md: poder decir «tu Glue, tu Snowflake, tu Postgres aparecen en el Warehouse sin ingesta» sin escribir 130 conectores. Snowflake no lo necesita porque su cliente ya movió el dato a Snowflake. Nuestro cliente no, y ahí somos más parecidos a Foundry que a Snowflake.
✅ ② El modelo de entidades como ESPECIFICACIÓN
Las ~700 JSON Schemas son, leídas bien, un vocabulario público del significado de un activo de datos — probado, versionado, con ecosistema. Eso no se usa desplegando un servicio: se usa conformándose a la forma.
Es exactamente el invariante nº 5 de Index Catalog —«la superficie de Index es una spec abierta, nunca una API propietaria»— aplicado a la metadata en vez de al catálogo. Conformar sin depender: nuestros hechos salen con la forma que su ecosistema entiende, y el día que OM no esté, los hechos siguen siendo legibles.
✅ ③ La superficie humana
Glosario, propiedad, discusiones, anuncios, Data Insights, la gestión de ingestas. Es producto de colaboración que ya funciona y que reconstruir sería quemar trimestres para llegar a lo mismo. Su UI es un activo (N3-bis, ya decidido).
❌ Lo que NO le da: el plano de datos
Calidad que bloquea en vez de anotar, linaje desde la escritura en vez de reconstruido, uso exacto en vez de percentil, política aplicada en vez de declarada. Nada de eso puede venir de fuera del camino. Y es justo la lista de lo que nos diferencia.
3 · Lo que un producto del plano de metadata no puede hacer, y nosotros sí
El «siguiente nivel» que pide el owner, hecho lista concreta. Cada punto es una capacidad estructural, no una cuestión de esfuerzo:
| Ellos (desde fuera) | Nosotros (desde Junction) | |
|---|---|---|
| 1 · Exactitud | percentil de uso estimado del query log | conteo exacto por objeto, actor y superficie (C2) |
| 2 · Latencia | workflow por lotes, «córrelo de noche» | evento en el momento de la resolución |
| 3 · Cobertura no-SQL | sólo ve lo que dejó rastro en un log de consultas | ve la hidratación de un Pod, la lectura de features de ML, la llamada de un agente — cosas que ningún query log registra jamás |
| 4 · La DECISIÓN, no sólo el hecho | no puede saber por qué se permitió | policy_id: qué política lo decidió. Auditoría defendible, no reconstruida |
| 5 · Linaje desde la escritura | reconstruido parseando SQL, con sus fallos | la arista se emite en el acto: quien resuelve para escribir declara sus entradas |
| 6 · Aplicar | anota y avisa | impide — es la diferencia entre una política y una sugerencia |
| 7 · Cerrar el bucle | el catálogo no aprende de su uso | uso → materializar un Pod caliente (norte §8) |
Y hay un punto 8 que es el que de verdad justifica el norte: ellos catalogan tablas; nosotros servimos Pods. Un agente que habla con el MCP de OpenMetadata ve metadata, no objetos de negocio hidratados — la invariante «el agente NUNCA ve las tablas» se rompe. Eso ya está registrado como decisión pendiente en el norte §10·1, y este documento la refuerza: el MCP que sirve Pods tiene que ser nuestro.
4 · La corrección que esto obliga: N2-ter
La decisión vigente (N2) dice: «OpenMetadata es la fuente de verdad de la metadata, desde la ingesta; el Index deja de aspirar a ser el catálogo». Fue una corrección acertada de un error real —queríamos autorar a mano lo que sus conectores extraen solos— pero está enunciada sin frontera, y aplicada a nuestro propio Warehouse se vuelve del revés.
La evidencia, medida, de que se vuelve del revés:
- OpenMetadata no tiene conector Iceberg. Para ver nuestras tablas hay que ponerle Trino delante — un motor entero como intermediario para leer lo que Junction ya sabe.
- Su perfilado no arrancaba hasta que soltamos
__row_indexde 32 tablas: el ORM de SQLAlchemy descarta los atributos con doble guión bajo. Un rodeo caro para un hecho que teníamos. - Su uso saldría de parsear los query logs de Trino — es decir, de una sombra de nuestro tráfico, y sólo del que pasa por Trino.
- Su linaje de nuestras derivaciones tendría que reconstruirse del SQL, cuando
transform_pathsya tiene la arista puesta por quien la hizo. - Sus tests de calidad ejecutan escaneos completos contra R2 — pagamos el almacenamiento y el cómputo para que un tercero deduzca algo que podríamos emitir.
N2-ter — la frontera precisa
OpenMetadata es SoT de lo que Carbon NO observa.
De todo lo que pasa por Junction, Carbon es first-party y PROYECTA hacia OM.No contradice N2: le pone el límite que le faltaba, igual que N2-bis hizo con la línea metadata/configuración. Y conserva lo intocable: Carbon sigue sin autorar metadata en OM — descripciones, términos y clasificaciones los produce la ingesta. Lo que proyectamos son hechos medidos, no opiniones.
En una tabla, por área:
| Área | ¿Quién es autoridad? | Dirección |
|---|---|---|
| Esquema, linaje, uso y calidad de nuestras tablas | Carbon (Junction) | Carbon → OM |
| Esquema, linaje, uso y calidad de sistemas ajenos | OpenMetadata (sus conectores) | OM → Carbon |
| Glosario, términos, clasificaciones, propiedad, discusiones | OpenMetadata | OM → Carbon |
| Configuración de fuentes e ingestas | Carbon (su UI) | Carbon → OM |
| Políticas, tiers, procedencia, Pods | Index Catalog — OM no tiene el concepto | interno |
5 · La regla operativa, en una línea
Para no re-litigar esto caso por caso:
Si el hecho pasa por Junction, lo emitimos nosotros y lo proyectamos.
Si no pasa, lo lee OpenMetadata y lo consumimos.
Y el test que la acompaña, para cuando haya duda: ¿puede OM saber esto sin adivinar? Si la respuesta es «parseando algo», entonces es nuestro.
6 · El riesgo real, que no es el que parece
El riesgo no es depender demasiado de OpenMetadata. Es reconstruirlo.
«No hay ningún motivo por el que no podamos hacerlo de forma nativa» es cierto, y por eso mismo es peligroso: la misma frase justifica emitir uso exacto (correcto) y reescribir un glosario con discusiones y notificaciones (ruinoso). La línea que separa las dos:
Nativo = los HECHOS que sólo nosotros podemos conocer.
Prestado = la PRESENTACIÓN, la colaboración y todo lo AJENO.
Tres contenciones concretas:
- Un solo catálogo a los ojos del usuario. Proyectamos hacia OM precisamente para que no haya dos UIs de metadata compitiendo. Si algún día hay dos, esta estrategia falló.
- OM nunca en el camino caliente. Es superficie y proyección; si se cae, Carbon sirve datos igual. La proyección es asíncrona y reintentable, por diseño.
- Conformarse a sus esquemas, no a su despliegue. Nuestros hechos se emiten con la forma de sus JSON Schemas — así son portables a Atlan, a DataHub o a un fichero, y la dependencia nunca se vuelve estructural.
7 · Lo que este documento decide, y lo que deja abierto
Decide:
- N2-ter (§4): la frontera es observado por Junction vs no observado, no datos vs metadata.
- C2 nace first-party y proyecta a OM en su fase 4 — no al revés (approach).
- Las 700 JSON Schemas se adoptan como especificación de intercambio, no como servicio del que colgar.
Deja abierto (y son del owner):
- El linaje. N2-ter dice que el de nuestras tablas es nuestro — pero hoy son seis almacenes desconectados y casi vacíos. Emitirlo desde la escritura (N·5 de index-frontier.md) es un proyecto, no un ajuste. ¿Se adelanta, o se deja que OM lo reconstruya por ahora?
- La calidad. Sus tests ya funcionan vía Trino. ¿Se queda ahí, o los veredictos pasan a ser hechos de primera clase sobre
(objeto, snapshot, política)— que es lo que haría aplicables los tiers, hoy afirmados y nunca comprobados? - El MCP. Confirmar que el de OM queda restringido a uso interno y que el que sirve Pods es el nuestro (norte §10·1).