{"id":1542,"date":"2025-12-06T00:00:00","date_gmt":"2025-12-06T00:00:00","guid":{"rendered":"https:\/\/cloudlab.urv.cat\/catedracloud\/?p=1542"},"modified":"2026-02-04T23:16:06","modified_gmt":"2026-02-04T23:16:06","slug":"de-caja-negra-a-plano-maestro-como-dbt-domestica-la-arquitectura-moderna-de-datos","status":"publish","type":"post","link":"https:\/\/cloudlab.urv.cat\/catedracloud\/2025\/12\/06\/de-caja-negra-a-plano-maestro-como-dbt-domestica-la-arquitectura-moderna-de-datos\/","title":{"rendered":"De caja negra a plano maestro: c\u00f3mo dbt domestica la arquitectura moderna de datos"},"content":{"rendered":"\n

Como mencionamos en anteriores publicaciones, el data lakehouse<\/a><\/em> y la Arquitectura Medallion<\/a> son nuestros planos fundamentales. Entendemos el valor de este enfoque por capas: los datos en bruto llegan a la capa Bronce, se limpian y se conforman en la capa Plata, y finalmente se modelan en agregados listos para el negocio en la capa Oro.<\/p>\n\n\n\n

Esta arquitectura nos brinda un framework s\u00f3lido y escalable para organizar nuestros datos. Proporciona un camino claro y l\u00f3gico para que los datos fluyan desde la ingesta hasta la obtenci\u00f3n de informaci\u00f3n. Tenemos claramente definido el \u201cqu\u00e9\u201d y el \u201cd\u00f3nde\u201d de nuestras capas de datos.<\/p>\n\n\n\n

Sin embargo, tener datos bien estructurados es solo la mitad de la batalla. A medida que nuestras canalizaciones crecen en n\u00famero y complejidad, la sem\u00e1ntica de esos datos se vuelve difusa. Aunque sabemos d\u00f3nde reside nuestra tabla gold_customer_lifetime_value<\/em>, la historia de c\u00f3mo fue construida a menudo se pierde. La intrincada red de transformaciones, l\u00f3gica de negocio y dependencias que conecta una fuente en bruto con un KPI cr\u00edtico sigue siendo una caja negra, documentada \u00fanicamente en fragmentos dispersos de scripts SQL o, peor a\u00fan, en la memoria de un antiguo colega. Es aqu\u00ed donde comienzan a aparecer las grietas en nuestra arquitectura, por lo dem\u00e1s perfecta.<\/p>\n\n\n\n

El Problema: Cuando la claridad se derrumba bajo la complejidad<\/h2><\/div>\n\n\n\n

La Arquitectura Medallion nos da un excelente mapa del destino de nuestros datos, pero no nos dice nada sobre el viaje. En un entorno real, el camino de Bronce a Oro rara vez es una l\u00ednea recta. Es una red compleja de transformaciones y, sin un marco adecuado para gestionarla, esa red se convierte r\u00e1pidamente en un enredo fr\u00e1gil y dif\u00edcil de mantener.<\/p>\n\n\n\n

Veamos los problemas espec\u00edficos que surgen de esta \u201ccaja negra de transformaciones\u201d:<\/p>\n\n\n\n

    \n
  1. El D\u00e9ficit de Confianza<\/strong> Imagina que un l\u00edder de negocio pregunta: \u201cVeo que el KPI de \u2018Ingresos Trimestrales\u2019 en el dashboard baj\u00f3 un 5%. \u00bfPuedes explicar por qu\u00e9?\u201d<\/em> En una arquitectura opaca, responder a esa pregunta se convierte en una excavaci\u00f3n arqueol\u00f3gica. Primero hay que encontrar el script SQL que materializ\u00f3 la tabla Oro, luego rastrear las transformaciones de la capa Plata y finalmente intentar mapearlas a las fuentes Bronce. Es un proceso lento, propenso a errores y que a menudo termina con una respuesta incierta: \u201cCreo que es por c\u00f3mo estamos gestionando las devoluciones de la tienda de la UE.\u201d<\/em> Cuando el linaje de las m\u00e9tricas cr\u00edticas no est\u00e1 claro, la confianza en los datos se erosiona\u2014no solo para los usuarios de negocio, sino tambi\u00e9n para los propios equipos de datos.<\/li>\n\n\n\n
  2. El Efecto Castillo de Naipes<\/strong> Los datos no son est\u00e1ticos. La l\u00f3gica de negocio cambia, los sistemas de origen se actualizan y surgen nuevos requisitos. En un mundo donde las transformaciones son solo un conjunto de scripts SQL desconectados, hacer un cambio sencillo se siente como jugar al Jenga. \u00bfNecesitas a\u00f1adir una nueva columna a una tabla Plata central? Tienes que identificar manualmente todas las tablas Oro que dependen de ella, actualizar su c\u00f3digo y rezar para no haber pasado por alto ninguna. Un solo error puede derribar una cascada de dashboards cr\u00edticos. Esta fragilidad hace que el desarrollo sea lento y arriesgado, sofocando la agilidad que el lakehouse<\/em> promete.<\/li>\n\n\n\n
  3. El Cuello de Botella en la Colaboraci\u00f3n<\/strong> Cuando la l\u00f3gica de transformaci\u00f3n vive en cuadernos personales o en scripts oscuros dentro de un repositorio Git, se crean silos de conocimiento. El \u201cexperto\u201d en datos de clientes se convierte en la \u00fanica persona capaz de modificar los modelos de forma segura. Esto genera un cuello de botella para todo el equipo. Incorporar a un nuevo ingeniero significa semanas, si no meses, de aprender reglas no escritas y descifrar c\u00f3digo cr\u00edptico. No existe una \u00fanica fuente de verdad sobre c\u00f3mo se define el negocio en los datos, lo que lleva a l\u00f3gica inconsistente y trabajo duplicado, ya que distintos ingenieros resuelven el mismo problema de maneras diferentes.<\/li>\n<\/ol>\n\n\n\n

    En esencia, aunque nuestra arquitectura de almacenamiento (lakehouse<\/em>) es moderna y escalable, nuestra arquitectura de transformaciones sigue siendo primitiva. Estamos intentando construir un rascacielos sobre unos planos dispersos. Lo que necesitamos con urgencia es un marco que trate la l\u00f3gica de transformaci\u00f3n como un ciudadano de primera clase, que aporte estructura, visibilidad y fiabilidad a la parte m\u00e1s cr\u00edtica de nuestra canalizaci\u00f3n de datos. Necesitamos una forma de gestionar el \u201cc\u00f3mo\u201d y el \u201cpor qu\u00e9\u201d con el mismo rigor que aplicamos al \u201cqu\u00e9\u201d y al \u201cd\u00f3nde.\u201d<\/p>\n\n\n\n

    La Soluci\u00f3n: dbt como la Capa de Transformaci\u00f3n<\/h2><\/div>\n\n\n\n

    Si el problema es la falta de estructura y visibilidad en nuestras transformaciones, la soluci\u00f3n es una herramienta que trate esa l\u00f3gica como un ciudadano de primera clase dentro de nuestra arquitectura de datos. Aqu\u00ed entra en juego dbt (data build tool)<\/strong>.<\/p>\n\n\n\n

    Entonces, \u00bfqu\u00e9 es exactamente dbt?<\/p>\n\n\n\n

    En esencia, dbt es un flujo de trabajo de transformaci\u00f3n open-source<\/em> que permite a los equipos de datos construir, probar y documentar modelos de manera colaborativa directamente dentro de su data warehouse<\/em> o lakehouse<\/em>. No es una nueva base de datos ni una herramienta de movimiento de datos. Es un marco que trae las mejores pr\u00e1cticas de la ingenier\u00eda de software al mundo de la anal\u00edtica de datos. dbt adopta el paradigma moderno de ELT: primero Extraes<\/strong> los datos, luego los Cargas<\/strong> en tu almac\u00e9n, y finalmente los Transformas<\/strong> en el lugar con dbt.<\/p>\n\n\n\n

    dbt resuelve los problemas que mencionamos cambiando de forma fundamental c\u00f3mo escribimos y gestionamos nuestra l\u00f3gica de transformaci\u00f3n.<\/p>\n\n\n\n

      \n
    1. Restaurar la Confianza con Documentaci\u00f3n y Linaje Autom\u00e1ticos<\/strong>: \u00bfRecuerdas el \u201cD\u00e9ficit de Confianza\u201d? dbt lo elimina al hacer que el linaje y la documentaci\u00f3n de los datos sean parte nativa del proceso de desarrollo. Cuando escribes un modelo en dbt, no solo est\u00e1s creando un script SQL; est\u00e1s definiendo un nodo en un grafo. Usando funciones simples como ref()<\/code> para referenciar otras tablas, dbt entiende autom\u00e1ticamente toda la cadena de dependencias.<\/li>\n<\/ol>\n\n\n\n

      Con un solo comando, dbt docs generate<\/code>, dbt analiza tu proyecto completo, inspecciona el almac\u00e9n y produce un sitio de documentaci\u00f3n interactivo. Este sitio muestra:<\/p>\n\n\n\n

        \n
      • Todas las tablas y columnas del proyecto.<\/li>\n\n\n\n
      • El c\u00f3digo SQL exacto usado para crear cada modelo.<\/li>\n\n\n\n
      • Un grafo visual de dependencias (DAG) que te permite rastrear cualquier tabla Oro hasta sus fuentes Bronce.<\/li>\n<\/ul>\n\n\n\n

        Responder a \u201c\u00bfPor qu\u00e9 cambiaron los ingresos?\u201d deja de ser una excavaci\u00f3n arqueol\u00f3gica y se convierte en una exploraci\u00f3n con unos pocos clics.<\/p>\n\n\n\n

          \n
        1. Reemplazar el Castillo de Naipes con un DAG Resiliente<\/strong>: El \u201cEfecto Castillo de Naipes\u201d se mitiga gracias a la innovaci\u00f3n central de dbt: el grafo ac\u00edclico dirigido (DAG). Cuando ejecutas dbt run<\/code>, dbt no corre tus modelos en orden aleatorio. Analiza las dependencias definidas con ref()<\/code> y construye un DAG, ejecutando cada modelo solo despu\u00e9s de que todos sus padres se hayan completado con \u00e9xito.<\/li>\n<\/ol>\n\n\n\n

          Esto significa que puedes modificar con confianza una tabla Plata central. dbt identificar\u00e1 y reconstruir\u00e1 autom\u00e1ticamente todos los modelos descendientes que dependan de ella, garantizando consistencia en todo tu ecosistema de datos. Adem\u00e1s, el marco de pruebas integrado de dbt te permite asegurar la calidad de los datos (por ejemplo, que customer_id<\/code> nunca sea nulo, o que order_date<\/code> sea siempre una fecha v\u00e1lida) y detectar errores antes de que lleguen a la capa Oro.<\/p>\n\n\n\n

            \n
          1. Romper los Cuellos de Botella con un Marco Colaborativo:<\/strong> dbt aborda el \u201cCuello de Botella en la Colaboraci\u00f3n\u201d proporcionando una estructura de proyecto estandarizada y modular. Te anima a pensar en t\u00e9rminos de componentes reutilizables. En lugar de copiar y pegar l\u00f3gica compleja, puedes crear macros<\/em> que se usan en todo el proyecto. Esto genera una \u00fanica fuente de verdad para la l\u00f3gica de negocio.<\/li>\n<\/ol>\n\n\n\n

            Los nuevos miembros del equipo pueden ponerse al d\u00eda r\u00e1pidamente leyendo la documentaci\u00f3n generada autom\u00e1ticamente y entendiendo la estructura modular del proyecto. Las revisiones de c\u00f3digo se vuelven significativas porque los cambios se realizan dentro de un contexto estructurado, no en un conjunto de scripts improvisados. dbt convierte la transformaci\u00f3n de datos de un acto solitario de \u201cmagia\u201d en una disciplina de ingenier\u00eda colaborativa.<\/p>\n\n\n\n

            En resumen, dbt es la pieza que faltaba en la arquitectura moderna de datos. Proporciona la capa sem\u00e1ntica, la gobernanza y el rigor operativo necesarios para transformar un lakehouse<\/em> bien organizado de un simple repositorio de datos en un motor confiable, escalable y digno de confianza para la inteligencia de negocio.<\/p>\n\n\n\n

            Un Ejemplo Sencillo con dbt<\/h2><\/div>\n\n\n\n

            Veamos c\u00f3mo funciona en la pr\u00e1ctica. Imagina que tenemos datos de pedidos de e\u2011commerce en bruto que llegan a nuestra capa Bronce. Queremos crear una tabla limpia y agregada en la capa Oro que muestre el importe total de pedidos por cliente.<\/p>\n\n\n\n

            As\u00ed es como lo modelar\u00edamos usando dbt.<\/p>\n\n\n\n

            Paso 1: La Capa Plata \u2013 Preparando los Datos en Bruto<\/strong><\/h4>\n\n\n\n

            Primero, creamos un modelo de staging<\/em> para limpiar y preparar nuestros datos en bruto. Este modelo leer\u00e1 de nuestra fuente orders<\/code> y aplicar\u00e1 transformaciones b\u00e1sicas.<\/p>\n\n\n\n

            models\/staging\/stg_orders.sql<\/code><\/strong><\/p>\n\n\n\n

            -- Este modelo limpia nuestros datos de pedidos en bruto.\n-- Renombramos columnas para mayor claridad, convertimos tipos de datos y filtramos datos inv\u00e1lidos.\n\nselect\n    order_id,\n    user_id as customer_id, -- Renombrado para consistencia\n    order_date,\n    status,\n    -- Convertimos el precio a tipo num\u00e9rico y manejamos posibles errores\n    safe_cast(amount as numeric(10, 2)) as order_amount,\n\nfrom {{ source('raw_ecommerce', 'orders') }} -- Referencia a los datos Bronce\n\nwhere status not in ('returned', 'cancelled') -- Solo queremos pedidos completados\n<\/code><\/pre>\n\n\n\n
            Este sencillo archivo SQL ya es un modelo dbt. Hemos renombrado columnas, convertido tipos de datos y filtrado pedidos irrelevantes, creando una tabla confiable stg_orders<\/code> en nuestra capa Plata.<\/p>\n\n\n\n
            Paso 2: La Capa Oro \u2013 Creando Valor de Negocio<\/strong><\/h4>\n\n\n\n
            Ahora, creamos nuestro modelo Oro. Este modelo no leer\u00e1 directamente de los datos en bruto, sino que se construir\u00e1 sobre nuestro modelo Plata limpio usando la funci\u00f3n ref()<\/code>.<\/p>\n\n\n\n
            models\/marts\/fct_customer_orders.sql<\/code><\/strong><\/p>\n\n\n\n
            -- Este modelo agrega datos de pedidos por cliente para anal\u00edtica de negocio.\n-- Usa nuestro modelo stg_orders como fuente, creando una dependencia clara.\n\nwith\ncustomer_orders as (\n\n    select * from {{ ref('stg_orders') }} -- \u00a1Aqu\u00ed est\u00e1 la magia!\n\n)\n\nselect\n    customer_id,\n    count(order_id) as number_of_orders,\n    sum(order_amount) as lifetime_value\n\nfrom customer_orders\ngroup by 1\n<\/code><\/pre>\n\n\n\n
            La funci\u00f3n ref('stg_orders')<\/code> es el coraz\u00f3n de dbt.<\/strong> Le dice a dbt: \u201cEste modelo depende de stg_orders<\/code>.\u201d dbt usa esta informaci\u00f3n para construir autom\u00e1ticamente el grafo de dependencias (DAG). Al ejecutar dbt run<\/code>, sabe que debe construir stg_orders<\/code> con \u00e9xito antes de intentar construir fct_customer_orders<\/code>.<\/p>\n\n\n\n
            Paso 3: A\u00f1adiendo Pruebas de Calidad de Datos<\/strong><\/h4>\n\n\n\n
            Finalmente, podemos a\u00f1adir pruebas a nuestro modelo Plata para asegurar su calidad, justo al lado del c\u00f3digo.<\/p>\n\n\n\n
             models\/staging\/schema.yml<\/code><\/strong><\/p>\n\n\n\n
            version: 2\n\nmodels:\n  - name: stg_orders\n    columns:\n      - name: order_id\n        tests:\n          - unique\n          - not_null\n      - name: customer_id\n        tests:\n          - not_null\n      - name: order_amount\n        tests:\n          - dbt_expectations.expect_column_values_to_be_of_type:\n              column_type: NUMBER\n<\/code><\/pre>\n\n\n\n
            Ahora, cada vez que ejecutamos dbt test<\/code>, dbt validar\u00e1 estas reglas sobre la tabla stg_orders<\/code>, fallando la construcci\u00f3n si un order_id<\/code> est\u00e1 duplicado o es nulo. Esto detecta problemas de calidad antes de que contaminen la capa Oro.<\/p>\n\n\n\n
            Con solo estos tres archivos tenemos:<\/p>\n\n\n\n
              \n
            • Linaje Claro:<\/strong> La documentaci\u00f3n mostrar\u00e1 que fct_customer_orders<\/code> depende directamente de stg_orders<\/code>. Sin m\u00e1s suposiciones.<\/li>\n\n\n\n
            • Resiliencia:<\/strong> Si actualizamos la l\u00f3gica en stg_orders<\/code>, dbt run<\/code> reconstruir\u00e1 autom\u00e1ticamente fct_customer_orders<\/code>. Sin rastreo manual.<\/li>\n\n\n\n
            • Colaboraci\u00f3n:<\/strong> La l\u00f3gica es modular, documentada y probada. Cualquier miembro del equipo puede entenderla y contribuir con confianza.<\/li>\n<\/ul>\n\n\n\n
              Este ejemplo sencillo ilustra c\u00f3mo dbt aporta estructura, fiabilidad y visibilidad directamente al proceso de transformaci\u00f3n, resolviendo los problemas centrales del modern data stack<\/em>.<\/p>\n\n\n\n
              Conclusi\u00f3n: Construyendo la Capa Sem\u00e1ntica de tu Modern Data Stack<\/em><\/h2><\/div>\n\n\n\n
              Hemos recorrido el camino desde el mundo bien organizado pero opaco de la Arquitectura Medallion hacia un nuevo paradigma de claridad y control. El lakehouse<\/em> nos dio una base poderosa y escalable para almacenar nuestros datos. Pero sin una forma de gestionar el significado y la transformaci\u00f3n de esos datos, nos quedamos con una biblioteca hermosa pero ininteligible.<\/p>\n\n\n\n
              dbt es la pieza que faltaba.<\/strong> Es el marco esencial que completa la arquitectura moderna de datos. No reemplaza tu data warehouse<\/em>; desbloquea todo su potencial. Al tratar SQL como c\u00f3digo, dbt introduce el rigor, la disciplina y la colaboraci\u00f3n de la ingenier\u00eda de software en el mundo de la anal\u00edtica de datos.<\/p>\n\n\n\n
              El resultado es mucho m\u00e1s que canalizaciones m\u00e1s limpias. Es un cambio fundamental en c\u00f3mo trabajamos con los datos:<\/p>\n\n\n\n
                \n
              • La confianza se restaura<\/strong> porque cada m\u00e9trica puede rastrearse hasta su fuente con un solo clic.<\/li>\n\n\n\n
              • La agilidad se logra<\/strong> porque los cambios dejan de ser arriesgados y pasan a estar gestionados, probados y desplegados con confianza.<\/li>\n\n\n\n
              • La colaboraci\u00f3n se convierte en la norma<\/strong> porque el conocimiento est\u00e1 codificado, documentado y compartido, no aislado en scripts individuales.<\/li>\n<\/ul>\n\n\n\n
                La combinaci\u00f3n de un data lakehouse<\/em> y dbt ya no es una elecci\u00f3n de nicho; es el est\u00e1ndar emergente para construir una plataforma de datos verdaderamente robusta e inteligente. Proporciona la \u201ccapa sem\u00e1ntica\u201d que se sit\u00faa sobre tus datos en bruto, traduci\u00e9ndolos en un conjunto consistente, confiable y comprensible de verdades de negocio. Esta es la base sobre la cual las grandes empresas est\u00e1n construyendo su futuro impulsado por los datos. Es hora de dejar de simplemente almacenar datos y empezar a ingeniarlos con intenci\u00f3n<\/strong>.<\/p>\n\n\n\n
                <\/p>\n","protected":false},"excerpt":{"rendered":"
                Como mencionamos en anteriores publicaciones, el data lakehouse y la Arquitectura Medallion son nuestros planos fundamentales. Entendemos el valor de este enfoque por capas: los datos en bruto llegan a la capa Bronce, se limpian y se conforman en la capa Plata, y finalmente se modelan en agregados listos para el negocio en la capa […]<\/p>\n","protected":false},"author":6,"featured_media":1543,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","_swt_meta_header_display":false,"_swt_meta_footer_display":false,"_swt_meta_site_title_display":false,"_swt_meta_sticky_header":false,"_swt_meta_transparent_header":false,"footnotes":""},"categories":[113],"tags":[],"class_list":["post-1542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-computing"],"jetpack_featured_media_url":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min.png","uagb_featured_image_src":{"full":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min.png",1536,1024,false],"thumbnail":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min-150x150.png",150,150,true],"medium":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min-300x200.png",300,200,true],"medium_large":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min-768x512.png",768,512,true],"large":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min-1024x683.png",1024,683,true],"1536x1536":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min.png",1536,1024,false],"2048x2048":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/11\/ChatGPT-Image-Nov-11-2025-07_53_37-PM-min.png",1536,1024,false]},"uagb_author_info":{"display_name":"Aitor Arjona","author_link":"https:\/\/cloudlab.urv.cat\/catedracloud\/author\/aitor\/"},"uagb_comment_info":0,"uagb_excerpt":"Como mencionamos en anteriores publicaciones, el data lakehouse y la Arquitectura Medallion son nuestros planos fundamentales. Entendemos el valor de este enfoque por capas: los datos en bruto llegan a la capa Bronce, se limpian y se conforman en la capa Plata, y finalmente se modelan en agregados listos para el negocio en la capa…","_links":{"self":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/comments?post=1542"}],"version-history":[{"count":1,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1542\/revisions"}],"predecessor-version":[{"id":1544,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1542\/revisions\/1544"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/media\/1543"}],"wp:attachment":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/media?parent=1542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/categories?post=1542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/tags?post=1542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}