Data Catalog

Executive summary

Quando un'organizzazione gestisce centinaia o migliaia di tabelle, pipeline e report distribuiti su sistemi diversi, individuare rapidamente i dati giusti e comprenderne provenienza, qualità e significato diventa un problema operativo che rallenta le decisioni e aumenta i rischi di conformità. I cataloghi di dati sono strumenti progettati per raccogliere, organizzare e rendere ricercabili le informazioni descrittive associate a ogni risorsa informativa aziendale, dalla definizione tecnica delle colonne fino al significato concordato tra i reparti. Questa analisi confronta le principali piattaforme a codice aperto oggi disponibili, evidenziando come ciascuna affronti in modo diverso la raccolta automatica dei metadati, la ricostruzione del percorso dei dati e il controllo della terminologia condivisa. Ne emerge che la scelta dello strumento dipende meno dalle funzionalità dichiarate e più dall'architettura sottostante, dal modello con cui i metadati vengono rappresentati e dalla capacità di integrarsi con i processi di governo dei dati già in essere.

Background

La proliferazione di fonti dati eterogenee all'interno delle organizzazioni, data warehouse, data lake, piattaforme di streaming, strumenti di business intelligence, ha reso la gestione dei metadati un problema di ingegneria non più trascurabile. Già nel 2016, Halevy et al. documentavano come all'interno di Google esistessero miliardi di dataset prodotti da migliaia di team, senza un sistema centralizzato per catalogarli; il progetto Goods rappresentò uno dei primi tentativi sistematici di costruire un catalogo post-hoc capace di inferire automaticamente schemi, provenienza e relazioni tra dataset [1]. Il problema, lungi dall'essere confinato ai giganti tecnologici, si ripresenta in qualsiasi organizzazione data-intensive: senza metadati strutturati, la ricerca dei dati si riduce a conoscenza tacita, comunicazioni informali e query esplorative su sistemi di produzione.

La letteratura accademica ha formalizzato il concetto di data catalog come sistema software che raccoglie, indicizza e rende ricercabili i metadati tecnici, operativi e di business associati agli asset informativi di un'organizzazione. Ehrlinger et al. [2], nella prima systematic literature review dedicata ai data catalog, identificano come requisiti funzionali minimi la capacità di ingestion automatica dei metadati, la ricerca full-text e per facet, la gestione della data lineage e il supporto alla collaborazione tra utenti. Jahnke e Otto [3] estendono questa analisi al contesto enterprise, individuando sette classi applicative dei data catalog, dalla data discovery interna alla condivisione cross-organizzazione, e sottolineando come l'integrazione con il landscape di metadata management esistente costituisca la sfida principale per l'adozione.

Sul piano degli standard, due riferimenti fondamentali inquadrano il problema della rappresentazione dei metadati. Lo standard ISO/IEC 11179 [4] definisce un framework per i metadata registry, stabilendo un metamodello per la descrizione e registrazione di elementi dati in modo indipendente dal sistema che li ospita. Il vocabolario W3C DCAT (Data Catalog Vocabulary), giunto alla versione 3 nel 2024 [5], fornisce un modello RDF per descrivere dataset e servizi dati in modo interoperabile tra cataloghi distribuiti. A questi si aggiungono i principi FAIR (Findable, Accessible, Interoperable, Reusable), formulati da Wilkinson et al. [6], che pongono l'accento sulla necessità che i metadati siano machine-actionable, un requisito che le piattaforme di data catalog moderne tentano di soddisfare attraverso API programmatiche e schemi tipizzati.

Il contesto applicativo in cui operano i data catalog è ulteriormente complicato dalla convergenza con la gestione dei data lake. Sawadogo e Darmont [7] evidenziano come la metadata management nei data lake richieda funzionalità di semantic enrichment, data indexing, link generation e data versioning che eccedono le capacità dei cataloghi tradizionali basati su semplici inventari tabulari. Questa osservazione è particolarmente rilevante per le piattaforme open-source analizzate nelle sezioni successive, che si trovano a operare in architetture ibride dove coesistono data warehouse strutturati e data lake schema-on-read.

Architetture a confronto: generazioni e modelli di metadata ingestion

L'evoluzione architetturale delle piattaforme di data catalog può essere descritta attraverso un modello a tre generazioni, formalizzato dal team di LinkedIn nell'ambito del progetto DataHub [8]. La comprensione di queste generazioni è essenziale per valutare le scelte progettuali delle piattaforme attuali.

Le piattaforme di prima generazione adottano un'architettura monolitica con ingestion basata su crawling periodico. Il catalogo esegue job batch che interrogano le sorgenti dati, estraggono i metadati e li centralizzano in un repository unico. Apache Atlas [9], originariamente progettato come framework di governance per l'ecosistema Hadoop, rappresenta un esempio paradigmatico di questo approccio: i metadati vengono raccolti tramite hook integrati in componenti Hadoop (Hive, HBase, Kafka, Sqoop) e memorizzati in un graph database (JanusGraph, già Titan) con indicizzazione su Elasticsearch o Solr. Amundsen, sviluppato da Lyft e rilasciato come open source nel 2019 [10], si colloca anch'esso in questa generazione, pur con un'architettura a microservizi più moderna. Il suo modello a grafo, implementato su Neo4j o, in alternativa, su Apache Atlas come backend, privilegia le relazioni tra entità (tabelle, colonne, utenti, dashboard) e utilizza PageRank sui log di accesso per ordinare i risultati di ricerca per rilevanza d'uso effettivo [10].

Le piattaforme di seconda generazione introducono un livello di servizio separato (service-oriented architecture) attraverso cui i sistemi produttori di metadati possono inviare aggiornamenti via API push, riducendo la dipendenza dal crawling batch [8]. Il catalogo espone un'API di metadata ingestion che consente ai sistemi upstream di registrare autonomamente i propri asset. In questo modello, il servizio di metadati è disaccoppiato dal frontend e dal motore di ricerca, ma la comunicazione resta sincrona e non event-driven. La separazione del metadata service come componente indipendente rappresenta un progresso architetturale significativo: consente l'evoluzione indipendente dei client e del backend, e abilita l'accesso programmatico ai metadati da parte di sistemi esterni (strumenti di data quality, pipeline di ML, sistemi di compliance) che nella prima generazione dovevano interrogare direttamente il database del catalogo.

Le piattaforme di terza generazione adottano un'architettura event-driven a microservizi. DataHub rappresenta l'implementazione più completa di questo paradigma [8, 11]. L'architettura si articola in quattro componenti principali: un metadata store (GMS, Generalized Metadata Service), un message broker (Apache Kafka) per la propagazione asincrona dei metadata change event (MCE) e metadata audit event (MAE), un graph database per le relazioni e un motore di ricerca (Elasticsearch). Questa architettura stream-oriented consente la propagazione dei metadati in near real-time, nell'ordine dei secondi, e supporta la federazione: team diversi possono operare servizi di metadati indipendenti, comunicando con l'indice di ricerca e il grafo centralizzati attraverso Kafka [8]. In produzione presso LinkedIn, DataHub gestisce oltre dieci milioni di record di metadati su 19 tipologie di entità [11].

OpenMetadata, progetto avviato nel 2021 da un team con esperienza nella metadata platform di Uber, adotta un'architettura che combina elementi della seconda e terza generazione [12]. Il design si distingue per la semplicità architetturale deliberata: quattro componenti principali (backend API in Java, framework di ingestion in Python, interfaccia utente in TypeScript/React, e database relazionale) anziché il grafo di servizi distribuiti tipico di DataHub. L'ingestion avviene in modalità pull-based attraverso oltre 90 connettori pre-costruiti, coordinati dal framework Python, che estraggono metadati da database, data warehouse, data lake, piattaforme di streaming, strumenti di BI e modelli di machine learning [12]. Questa scelta architetturale riduce la complessità operativa del deployment a costo di una latenza di aggiornamento maggiore rispetto all'approccio event-driven.

graph TD
    subgraph "Prima generazione (Batch/Crawl)"
        A1[Sorgenti dati] -->|Crawling periodico| A2[Catalogo monolitico]
        A2 --> A3[Graph DB + Search Index]
    end

    subgraph "Terza generazione (Event-Driven)"
        B1[Sorgenti dati] -->|Connettori / Hook| B2[Kafka - Event Bus]
        B2 --> B3[Metadata Store - GMS]
        B2 --> B4[Search Index]
        B2 --> B5[Graph DB]
        B3 --> B6[API Layer]
    end

Figura 1, Confronto schematico tra architettura di prima generazione (crawl batch centralizzato) e terza generazione (event-driven con message broker). Le piattaforme di terza generazione disaccoppiano ingestion, storage e indicizzazione, consentendo aggiornamenti near real-time e federazione dei servizi di metadati.

Modelli di metadati e schemi di rappresentazione

La scelta del modello di rappresentazione dei metadati determina la flessibilità, l'estensibilità e l'interoperabilità di un data catalog. Le tre piattaforme analizzate adottano approcci significativamente diversi.

OpenMetadata impiega un approccio schema-first basato su JSON Schema [13]. Il progetto definisce oltre 700 schemi JSON che coprono entità (table, database, pipeline, dashboard, ML model, topic), relazioni, eventi e configurazioni. Gli schemi sono conformi a JSON Schema Draft 07/2020-12 e sono stati recentemente estesi con modelli RDF/OWL, SHACL e JSON-LD per garantire compatibilità con il Semantic Web [13]. Questo approccio presenta vantaggi significativi in termini di interoperabilità: gli schemi sono auto-documentanti, versionabili, e utilizzabili per la generazione automatica di API, validatori e client in diversi linguaggi. L'adozione di uno standard aperto come JSON Schema riduce il rischio di lock-in e consente a terze parti di estendere il modello senza modificare il core della piattaforma.

DataHub utilizza un modello a entità basato su Pegasus Data Language (PDL), un linguaggio di definizione dei dati sviluppato internamente da LinkedIn [11]. Ogni entità (dataset, dashboard, pipeline, utente, glossary term) è definita come un set di aspetti, frammenti di metadati tipizzati che possono essere aggiornati indipendentemente. Questo modello aspect-based consente aggiornamenti granulari: è possibile modificare lo schema di un dataset senza toccare i metadati di ownership o di lineage. L'architettura supporta inoltre la definizione di aspetti custom, permettendo alle organizzazioni di estendere il modello per domini verticali. Il trade-off risiede nella minore interoperabilità nativa con standard aperti: il modello PDL è specifico dell'ecosistema LinkedIn/DataHub e richiede adapter per l'integrazione con sistemi che utilizzano JSON Schema, RDF o altri formati standardizzati.

Amundsen adotta un modello a grafo esplicito, dove entità e relazioni sono rappresentate come nodi e archi in un graph database (Neo4j o Apache Atlas) [10]. Le entità principali, table, column, user, application, dashboard, sono connesse da relazioni tipizzate (OWNER, COLUMN_OF, READ_BY, GENERATES). Il modello a grafo eccelle nella navigazione relazionale: la scoperta di dati avviene attraversando il grafo delle relazioni piuttosto che interrogando un indice flat. Tuttavia, la mancanza di un tipo-sistema formale per le entità rende l'estensione del modello meno strutturata rispetto agli approcci schema-first di OpenMetadata e DataHub.

La tabella seguente sintetizza le differenze architetturali e di modellazione tra le tre piattaforme.

Data lineage: dal table-level al column-level

La data lineage, la capacità di tracciare l'origine, le trasformazioni e la destinazione dei dati attraverso la pipeline analitica, rappresenta una delle funzionalità più critiche e tecnicamente complesse di un data catalog. La sua rilevanza si estende dalla compliance normativa (GDPR, BCBS 239) all'analisi d'impatto delle modifiche agli schemi fino al debugging delle anomalie nei dati.

Si distinguono due livelli di granularità. La table-level lineage traccia le dipendenze tra tabelle o dataset: la tabella A alimenta la tabella B attraverso un job ETL. Questa forma di lineage è relativamente semplice da implementare, poiché può essere derivata dai metadati dei sistemi di orchestrazione (Airflow, Dagster) o dai log delle query. La column-level lineage (CLL) traccia il flusso dei dati a livello di singola colonna: la colonna revenue nella tabella di output è derivata dalla colonna unit_price * quantity nella tabella sorgente. La CLL è significativamente più complessa, poiché richiede l'analisi sintattica e semantica delle query SQL, dei modelli dbt e del codice delle trasformazioni.

L'approccio tecnico prevalente per la column-level lineage si basa sul SQL parsing tramite Abstract Syntax Tree (AST). Il parser analizza le query SQL, costruisce l'albero sintattico astratto e lo attraversa per risolvere le dipendenze tra colonne, incluse quelle introdotte da CTE (Common Table Expression), subquery e funzioni di aggregazione. SQLGlot, una libreria Python pura che supporta oltre 20 dialetti SQL, si è affermata come componente fondamentale in questo dominio [14]. La sua funzione traverse_scope() consente di navigare sistematicamente ogni scope di una query, CTE, subquery, SELECT finale, ricostruendo la catena di derivazione colonna per colonna.

DataHub ha sviluppato il proprio modulo di SQL parsing costruito sopra SQLGlot, aggiungendo logiche di risoluzione degli schemi e gestione delle ambiguità che portano l'accuratezza della lineage generata al 97-99% secondo le misurazioni interne [14]. Questa integrazione è attiva per le sorgenti principali: Snowflake, BigQuery, Redshift, dbt, Looker, PowerBI e Airflow. OpenMetadata utilizza un approccio ibrido che combina SQLLineage e parser interni per la CLL, con risultati più variabili in termini di accuratezza su query complesse [12]. Amundsen, al contrario, non include funzionalità native di lineage automatica: la lineage deve essere alimentata attraverso il framework Databuilder tramite integrazioni custom con i sistemi di orchestrazione.

Oltre al SQL parsing, esistono approcci complementari per la cattura della lineage. La lineage by data tagging associa identificatori univoci ai record durante il transito nelle pipeline, consentendo il tracciamento a livello di singolo record, un approccio utile per requisiti di compliance stringenti ma costoso in termini di overhead computazionale. La query log analysis analizza i log delle query eseguite sui database per ricostruire la lineage effettiva, catturando anche le query ad-hoc che sfuggono ai sistemi di orchestrazione formali. La combinazione di SQL parsing statico e query log analysis rappresenta lo stato dell'arte per una copertura completa della lineage in ambienti enterprise eterogenei.

Business glossary e data governance

Il business glossary, un vocabolario controllato che definisce i termini di business in modo univoco e condiviso, costituisce il punto di contatto tra la dimensione tecnica del data catalog e la dimensione organizzativa della data governance. Senza un glossario condiviso, lo stesso concetto (ad esempio, "cliente attivo") può avere definizioni operative diverse tra reparti, generando inconsistenze nei report e nelle analisi. La letteratura sulla data governance identifica il business glossary come prerequisito per qualsiasi programma di governance efficace, poiché stabilisce il linguaggio comune su cui si fondano policy, metriche di qualità e classificazioni di sensibilità [3].

Le tre piattaforme implementano il business glossary con livelli di maturità diversi. OpenMetadata offre un glossary service strutturato gerarchicamente: i termini sono organizzati in glossari e sotto-glossari, ciascun termine può avere sinonimi, termini correlati, owner e reviewer. Il collegamento tra termini del glossario e asset tecnici (tabelle, colonne, dashboard) avviene tramite tagging esplicito, consentendo la navigazione bidirezionale: da un termine di business è possibile risalire a tutti gli asset che lo implementano, e da un asset tecnico è possibile verificare quali concetti di business rappresenta [12]. Questo meccanismo supporta direttamente l'impact analysis: modificare la definizione di "cliente attivo" consente di identificare immediatamente tutte le tabelle e i report che ne dipendono.

DataHub implementa il glossary come entità first-class nel suo modello a aspetti, con supporto per gerarchie, ownership (individual e group) e institutional knowledge, annotazioni che collegano i termini a documentazione esterna e risorse di contesto [11]. I glossary term possono essere associati a dataset, schemi e colonne tramite il meccanismo di tagging, e il sistema di governance integra il glossario con le policy di accesso basate su tag. DataHub supporta inoltre la propagazione automatica dei tag di governance lungo la lineage: se una colonna sorgente è classificata come PII (Personally Identifiable Information), il sistema può propagare automaticamente questa classificazione alle colonne derivate.

Amundsen offre un supporto più limitato al business glossary, orientato principalmente alla documentazione collaborativa degli asset tramite badge e descrizioni curate dagli utenti. La piattaforma non implementa un glossary service strutturato nativo, delegando questa funzionalità a integrazioni esterne [10].

La dimensione della data governance nei data catalog si estende oltre il glossario, includendo la classificazione della sensibilità dei dati, il controllo degli accessi basato su ruoli e attributi (RBAC/ABAC), il data quality monitoring, la data observability e l'audit trail delle modifiche ai metadati. La convergenza tra data catalog e data observability, la capacità di monitorare proattivamente la freshness, il volume, la distribuzione e la consistenza dei dati, è una tendenza architetturale recente: OpenMetadata ha integrato funzionalità di profiling e alerting direttamente nella piattaforma [12], mentre DataHub offre integrazioni con strumenti di observability esterni tramite il suo modello a aspetti estensibili [11]. OpenMetadata e DataHub offrono entrambi policy engine integrati per la governance, sebbene con approcci diversi: OpenMetadata adotta un modello RBAC con ownership a livello di dominio, mentre DataHub supporta policy più granulari basate su combinazioni di ruoli, tag e tipi di risorsa. Apache Atlas, pur essendo architetturalmente più datato, merita menzione in questo contesto per la sua integrazione nativa con Apache Ranger per l'enforcement delle policy di accesso ai dati, un'integrazione che le piattaforme più recenti tendono a replicare attraverso meccanismi di policy propagation [9].

Limiti, trade-off e problemi aperti

L'adozione di un data catalog in contesti enterprise presenta sfide che trascendono la selezione della piattaforma tecnologica. L'analisi delle tre piattaforme evidenzia trade-off strutturali e problemi aperti che meritano considerazione.

Il cold start problem rappresenta la barriera iniziale più significativa. Un catalogo vuoto non offre valore, e il popolamento iniziale richiede la configurazione dei connettori, la mappatura degli schemi, la definizione del glossario e la curazione dei metadati di ownership. Ehrlinger et al. [2] osservano che la complessità del setup iniziale è una delle cause principali di abbandono dei progetti di data catalog. Le piattaforme con un ampio set di connettori pre-costruiti (OpenMetadata con oltre 90, DataHub con integrazioni per i principali cloud data warehouse) mitigano parzialmente questo problema, ma la curazione dei metadati di business resta un'attività intrinsecamente manuale.

La freshness dei metadati costituisce un trade-off architetturale fondamentale. Le piattaforme event-driven (DataHub) offrono aggiornamenti in near real-time ma richiedono un'infrastruttura distribuita più complessa (Kafka, servizi consumer, graph database). Le piattaforme pull-based (OpenMetadata, Amundsen) sono operativamente più semplici ma introducono una latenza tra la modifica nel sistema sorgente e il suo riflesso nel catalogo. In ambienti ad alta velocità di cambiamento, ad esempio, piattaforme di data engineering con deployment continui di modelli dbt, questa latenza può rendere il catalogo inaffidabile come fonte di verità.

La column-level lineage resta un problema parzialmente risolto. Nonostante i progressi nel SQL parsing, diverse classi di trasformazioni sfuggono all'analisi statica: le trasformazioni implementate in codice procedurale (stored procedure PL/SQL complesse, UDF in Python o Scala), i flussi di dati mediati da sistemi di messaging dove la relazione produttore-consumatore non è esplicita, e le trasformazioni che coinvolgono dynamic SQL generato a runtime. La copertura dichiarata del 97-99% da parte di DataHub [14] si riferisce a query SQL standard; in ambienti con logica di trasformazione eterogenea, la copertura effettiva può essere significativamente inferiore.

Il problema dell'adozione organizzativa è trasversale a tutte le piattaforme. Un data catalog genera valore solo se gli utenti lo consultano e lo aggiornano. Amundsen affronta questo problema con un approccio pragmatico, il ranking dei risultati basato sull'uso effettivo (PageRank sui log) privilegia i dataset che vengono realmente utilizzati [10], ma il problema dell'engagement resta strutturalmente irrisolto dalla sola tecnologia. Jahnke e Otto [3] evidenziano come l'integrazione del catalogo nei workflow esistenti degli analisti (IDE, notebook, strumenti di BI) sia un fattore critico di successo, più determinante delle funzionalità intrinseca della piattaforma.

L'interoperabilità tra cataloghi rappresenta un problema emergente nelle organizzazioni che adottano architetture data mesh, dove team diversi possono utilizzare cataloghi diversi per i propri domini. Lo standard DCAT [5] offre un vocabolario per la descrizione interoperabile di dataset, ma non copre la semantica specifica dei metadati operativi (lineage, qualità, ownership) che costituiscono il valore principale di un data catalog. Gli sforzi di standardizzazione di OpenMetadata [13], con l'adozione di JSON Schema e l'estensione verso RDF/OWL, rappresentano un passo nella direzione giusta, ma un protocollo di federazione maturo tra piattaforme eterogenee non è ancora disponibile.

Infine, l'integrazione dell'intelligenza artificiale nei data catalog sta emergendo come direzione evolutiva significativa. Le applicazioni includono la classificazione automatica della sensibilità dei dati, il suggerimento di tag e descrizioni basato sul contenuto e sullo schema, e la generazione di lineage da codice non-SQL tramite analisi del codice sorgente. OpenMetadata ha introdotto funzionalità di automazione basate su modelli di linguaggio per la generazione di descrizioni e la classificazione dei dati nel corso del 2024 [12]. Tuttavia, l'affidabilità di queste funzionalità in contesti enterprise, dove un errore nella classificazione della sensibilità può avere conseguenze normative, resta un problema aperto che richiede meccanismi robusti di human-in-the-loop.

Implicazioni pratiche per l'adozione

La selezione di una piattaforma di data catalog deve essere guidata dall'analisi del contesto organizzativo e tecnologico, non dalla comparazione feature-per-feature. I risultati dell'analisi suggeriscono criteri di orientamento differenziati.

OpenMetadata si posiziona come scelta preferenziale per organizzazioni che privilegiano la semplicità operativa e l'aderenza a standard aperti. L'architettura a quattro componenti riduce la complessità del deployment e della manutenzione, mentre l'approccio schema-first in JSON Schema facilita l'integrazione con sistemi esterni e l'estensione del modello. Il glossary service strutturato e il supporto nativo alla data quality lo rendono particolarmente adatto a organizzazioni che investono in programmi di data governance formali. Il limite principale risiede nella latenza dell'ingestion pull-based e nella scala ancora limitata rispetto a DataHub [12, 13].

DataHub è la scelta naturale per organizzazioni con requisiti di scala elevati, architetture event-driven già consolidate (Kafka in produzione) e necessità di aggiornamento dei metadati in near real-time. La maturità della column-level lineage basata su SQLGlot, la scalabilità dimostrata a dieci milioni di asset e il supporto alla federazione lo rendono adatto a contesti enterprise complessi. Il trade-off è la complessità operativa: il deployment richiede Kafka, un graph database, Elasticsearch e servizi consumer multipli [8, 11, 14].

Amundsen resta rilevante come soluzione leggera per organizzazioni il cui requisito primario è la data discovery piuttosto che la governance completa. Il modello a grafo e il ranking basato sull'uso effettivo offrono un'esperienza di ricerca intuitiva, e l'architettura a microservizi consente un deployment incrementale. Tuttavia, l'assenza di lineage nativa, il glossary limitato e la comunità open-source meno attiva rispetto a OpenMetadata e DataHub ne limitano l'adozione per use case di governance avanzati [10].

In tutti i casi, il successo dell'adozione dipende da fattori non tecnologici: la definizione di un modello di ownership dei metadati, l'integrazione del catalogo nei workflow quotidiani degli utenti, e l'investimento nella curazione iniziale del glossario e delle descrizioni degli asset. Come evidenziato dalla letteratura [2, 3], i progetti di data catalog falliscono più spesso per carenze organizzative che per limiti tecnologici.

Riferimenti

[1] A. Halevy et al., "Goods: Organizing Google's Datasets," in Proc. ACM SIGMOD, 2016. https://research.google/pubs/goods-organizing-googles-datasets/

[2] L. Ehrlinger et al., "Data Catalogs: A Systematic Literature Review and Guidelines to Implementation," in Proc. DEXA Workshops, CCIS vol. 1479, pp. 148–158, 2021. https://link.springer.com/chapter/10.1007/978-3-030-87101-7_15

[3] N. Jahnke, B. Otto, "Data Catalogs in the Enterprise: Applications and Integration," Datenbank-Spektrum, vol. 23, pp. 89–96, 2023. https://link.springer.com/article/10.1007/s13222-023-00445-2

[4] ISO/IEC 11179-1:2023, "Information Technology — Metadata Registries (MDR) — Part 1: Framework," 2023. https://www.iso.org/standard/78914.html

[5] W3C, "Data Catalog Vocabulary (DCAT) — Version 3," W3C Recommendation, 2024. https://www.w3.org/TR/vocab-dcat-3/

[6] M. D. Wilkinson et al., "The FAIR Guiding Principles for Scientific Data Management and Stewardship," Scientific Data, vol. 3, 160018, 2016. https://www.nature.com/articles/sdata201618

[7] P. Sawadogo, J. Darmont, "On Data Lake Architectures and Metadata Management," Journal of Intelligent Information Systems, vol. 56, pp. 97–120, 2021. https://link.springer.com/article/10.1007/s10844-020-00608-7

[8] LinkedIn Engineering, "DataHub: Popular Metadata Architectures Explained," 2020. https://engineering.linkedin.com/blog/2020/datahub-popular-metadata-architectures-explained

[9] Apache Software Foundation, "Apache Atlas — Data Governance and Metadata Framework for Hadoop," 2024. https://atlas.apache.org/

[10] T. Feng, "Open Sourcing Amundsen: A Data Discovery and Metadata Platform," Lyft Engineering Blog, 2019. https://eng.lyft.com/open-sourcing-amundsen-a-data-discovery-and-metadata-platform-2282bb436234

[11] DataHub Project, "DataHub Architecture Overview," Official Documentation, 2025. https://docs.datahub.com/docs/architecture/architecture

[12] OpenMetadata, "OpenMetadata Documentation — Metadata Standard," 2025. https://docs.open-metadata.org/latest/main-concepts/metadata-standard

[13] OpenMetadata Standards, "Open Standard for Unified Metadata Management," 2025. https://openmetadatastandards.org/

[14] DataHub Project, "Extracting Column-Level Lineage from SQL," DataHub Blog, 2024. https://datahub.com/blog/extracting-column-level-lineage-from-sql/