Guida dell'utente di Data Mesh

Data Mesh per Cortex Framework estende la base di dati per abilitare la governance, la rilevabilità e il controllo dell'accesso ai dati tramite i metadati di BigQuery e Dataplex. Questo viene implementato fornendo un insieme di base di risorse di metadati e annotazioni degli asset BigQuery che possono essere personalizzate e, facoltativamente, implementate insieme alla base dati. Queste specifiche di base forniscono una configurazione personalizzata che costituisce la base dei metadati per integrare la Data Foundation di Cortex Framework. Consulta i concetti di Data Mesh prima di procedere con questa guida.

I passaggi descritti in questa pagina sono progettati specificamente per la configurazione di Data Mesh per Cortex Framework. Trova i file di configurazione di Data Mesh nelle cartelle specifiche per ogni carico di lavoro nella sezione Directory di Data Mesh.

Avviso: questa guida di Data Mesh potrebbe cambiare nel tempo. Rivolgiti al team di Cortex per eventuali feedback o problemi correlati.

Figura 1. Architettura Data Mesh per Cortex Framework.

Design

La piattaforma Data Mesh di Cortex è progettata in modo simile alla base di dati complessiva e consiste di tre fasi con diversi componenti secondari gestiti da Cortex o dagli utenti:

1. Aggiornamento delle specifiche delle risorse di base: con ogni release, Cortex aggiorna le specifiche delle risorse di base, fornendo una base di metadati standardizzata per il Data Mesh.
2. Personalizzazione delle specifiche delle risorse: prima del deployment, gli utenti possono personalizzare le specifiche delle risorse in base ai loro casi d'uso e requisiti specifici.
3. Deployment e aggiornamenti di Data Mesh: gli utenti possono attivare Data Mesh nel file di configurazione di Cortex. Viene implementato dopo le risorse di dati durante il deployment di Cortex. Inoltre, gli utenti hanno la flessibilità di eseguire il deployment di Data Mesh in modo indipendente per ulteriori aggiornamenti.

Figura 2. Progettazione di Data Mesh per Cortex Framework.

Directory di Data Mesh

Trova i file di configurazione di base di Data Mesh per ogni workload e origine dati nelle seguenti posizioni. Tieni presente che le directory contengono strutture di file diverse, ma tutte le specifiche sono posizionate in modo simile nella cartella config.

Carico di lavoro	Origine dati	Percorso della directory
Operativo	SAP ECC	src/SAP/SAP_REPORTING/config/ecc
	SAP S/4 HANA	src/SAP/SAP_REPORTING/config/s4
	Salesforce Sales Cloud (SFDC)	src/SFDC/config
	Oracle EBS	src/OracleEBS/config
Marketing	CM360	src/marketing/src/CM360/config
	Google Ads	src/marketing/src/GoogleAds/config
	Meta	src/marketing/src/Meta/config
	Salesforce Marketing Cloud (SFMC)	src/marketing/src/SFMC/config
	TikTok	src/marketing/src/TikTok/config
	YouTube (con DV360)	src/marketing/src/DV360/config
	Google Analytics 4	src/marketing/src/GA4/config

Nota: Data Mesh non supporta LiveRamp o i dati di Dun & Bradstreet (ESG).

Le risorse di metadati vengono definite a livello di origine dati con un singolo file YAML per Google Cloud progetto e contengono un elenco di tutte le risorse. Se necessario, gli utenti possono estendere il file esistente o creare altri file YAML contenenti specifiche aggiuntive delle risorse all'interno della directory.

Le annotazioni degli asset sono definite a livello di asset e contengono molti file YAML nella directory con una singola annotazione per file.

Attivare le API e verificare le autorizzazioni

La modifica dei valori predefiniti per Data Mesh ti consente di implementare funzionalità oltre alle descrizioni. Se devi modificare i valori predefiniti per Data Mesh in config.json per implementare funzionalità oltre alle descrizioni, assicurati che le API e le autorizzazioni di conferma necessarie siano impostate come descritto nella tabella seguente. Quando esegui il deployment di Data Mesh con la base di dati, concedi le autorizzazioni all'utente che esegue il deployment o all'account Cloud Build. Se l'implementazione prevede progetti di origine e di destinazione diversi, assicurati che queste API e autorizzazioni siano abilitate in entrambi i progetti ovunque vengano utilizzate queste funzionalità.

Funzionalità	Ruoli di autorizzazione	Documentazione
Accesso alle righe e agli asset BigQuery	Proprietario dati BigQuery	Per ulteriori informazioni, consulta Ruoli richiesti per i ruoli delle risorse e Autorizzazioni richieste per i ruoli delle righe.
Accesso alle colonne BigQuery	Policy Tag Admin	Per ulteriori informazioni, consulta la sezione Ruoli utilizzati con il controllo dell'accesso a livello di colonna e la documentazione Limitare l'accesso con il controllo dell'accesso a livello di colonna.
Tag del catalogo	Data Catalog TagTemplate Owner	Per ulteriori informazioni, consulta Collega i tag a una tabella BigQuery utilizzando Data Catalog e la documentazione di IAM di Data Catalog.
Dataplex Lakes	Dataplex Editor	Per ulteriori informazioni, consulta la documentazione su come creare un lago.

Nota: Cortex Data Mesh non richiede l'integrazione delle API Dataproc e Dataproc Metastore.

Informazioni sulle specifiche delle risorse di base

L'interfaccia principale per la configurazione di Data Mesh per Cortex è tramite le specifiche delle risorse di base, ovvero un insieme di file YAML forniti pronti all'uso che definiscono le risorse di metadati e le annotazioni di cui viene eseguito il deployment. Le specifiche di base forniscono consigli iniziali ed esempi di sintassi, ma sono pensate per essere ulteriormente personalizzate in base alle esigenze degli utenti. Queste specifiche rientrano in due categorie:

• Risorse di metadati che possono essere applicate a vari asset di dati. Ad esempio, i modelli di tag di Catalog che definiscono in che modo gli asset possono essere taggati con i domini aziendali.
• Annotazioni che specificano in che modo le risorse di metadati vengono applicate a un determinato asset di dati. Ad esempio, un tag catalogo che associa una tabella specifica al dominio Vendite.

Le sezioni seguenti illustrano esempi di base di ogni tipo di spec e spiegano come personalizzarli. Le specifiche di base sono contrassegnate con ## CORTEX-CUSTOMER dove devono essere modificate per adattarsi a un deployment se è attivata l'opzione di deployment associata. Per utilizzi avanzati, consulta la definizione canonica di questi schemi di specifiche in src/common/data_mesh/src/data_mesh_types.py.

Risorse di metadati

Le risorse di metadati sono entità condivise esistenti all'interno di un progetto che possono essere applicate a molti asset di dati. La maggior parte delle specifiche include un campo display_name sottoposto ai seguenti criteri:

• Deve contenere solo lettere, numeri (0-9), trattini bassi (_), trattini (-) e spazi ( ) Unicode.
• Non può iniziare o terminare con spazi.
• Lunghezza massima di 200 caratteri.

In alcuni casi, il display_name viene utilizzato anche come ID, il che potrebbe comportare requisiti aggiuntivi. In questi casi sono inclusi i link alla documentazione canonica.

Se il deployment fa riferimento a risorse di metadati in progetti di destinazione e di origine diversi, deve essere definita una specifica per ogni progetto. Ad esempio, Cortex Salesforce (SFDC) contiene due specifiche Lake. Uno per le zone non elaborate e CDC e un altro per i report.

Dataplex Lakes

I lake, le zone e gli asset Dataplex vengono utilizzati per organizzare i dati da un punto di vista dell'ingegneria. I lake hanno un region e le zone un location_type, entrambi correlati alla località di Cortex (config.json > location). La località di Cortex definisce dove vengono archiviati i set di dati BigQuery e può essere una singola regione o più regioni. La zona location_type deve essere impostata su SINGLE_REGION | MULTI_REGION per corrispondere a quella. Tuttavia, le regioni del lago devono sempre essere una singola regione. Se la località e la zona location_type di Cortex sono multiregione, seleziona una singola regione all'interno del gruppo per la regione del lago.

• Requisiti
  • Il lake display_name viene utilizzato come lake_id e deve essere conforme ai requisiti ufficiali. Lo stesso vale per la zona e l'asset display_name. Gli ID zona devono essere univoci in tutti i lake del progetto.
  • Le specifiche del lago devono essere associate a una singola regione.
  • asset_name deve corrispondere all'ID del set di dati BigQuery, ma display_name può essere un'etichetta più user-friendly.
• Limitazioni
  • Dataplex supporta solo la registrazione di set di dati BigQuery anziché di singole tabelle come asset Dataplex.
  • Una risorsa potrebbe essere registrata solo in un'unica zona.
  • Dataplex è supportato solo in determinate località. Per ulteriori informazioni, consulta Località di Dataplex.

Consulta l'esempio seguente in lakes.yaml.

Queste risorse sono definite in file YAML che specificano data_mesh_types.Lakes.

Modelli di tag del catalogo

I modelli di tag di Data Catalog possono essere utilizzati per aggiungere contesto alle tabelle BigQuery o alle singole colonne. Ti aiutano a classificare e comprendere i dati sia dal punto di vista tecnico sia da quello aziendale in un modo integrato con gli strumenti di ricerca di Dataplex. Definiscono i campi specifici che puoi utilizzare per etichettare i dati e il tipo di informazioni che ciascun campo può contenere (ad esempio testo, numero, data). I tag del catalogo sono istanze dei modelli con valori di campo effettivi.

Il campo del modello display_name viene utilizzato come ID campo e deve soddisfare i requisiti per TagTemplate.fields specificati in Class TagTemplate. Per saperne di più sui tipi di campi supportati, consulta Tipi di campi di Data Catalog.

Cortex Data Mesh crea tutti i modelli di tag come leggibili pubblicamente. Inoltre, introduce un concetto aggiuntivo level nelle specifiche del modello di tag, che definisce se un tag deve essere applicato a un asset intero, a singoli campi all'interno di un asset o a entrambi, con i possibili valori: ASSET | FIELD | ANY. Anche se al momento non è applicato rigorosamente, i controlli di convalida futuri potrebbero garantire che i tag vengano applicati al livello appropriato durante il deployment.

Vedi l'esempio che segue.

I modelli sono definiti in file YAML che specificano data_mesh_types.CatalogTagTemplates.

I tag di catalogo sono istanze dei modelli e sono descritti di seguito nelle annotazioni degli asset.

Controllo dell'accesso a livello di asset e colonna con i modelli di tag

Cortex Framework offre la possibilità di attivare il controllo dell'accesso a livello di asset o colonna su tutti gli elementi associati a un modello di tag del catalogo. Ad esempio, se gli utenti vogliono concedere l'accesso agli asset in base alla linea di business, possono creare asset_policies per il modello di tag di catalogo line_of_business con diversi principali specificati per ogni dominio aziendale. Ogni criterio accetta filters, che può essere utilizzato per associare i tag solo a valori specifici. In questo caso potremmo abbinare i valori domain. Tieni presente che questi filters supportano solo la corrispondenza per uguaglianza e nessun altro operatore. Se sono elencati più filtri, i risultati devono soddisfare tutti i filtri (ad es. filter_a AND filter_b). L'insieme finale di norme delle risorse è costituito dall'unione di quelle definite direttamente nelle annotazioni e di quelle delle norme dei modelli.

Il controllo dell'accesso a livello di colonna con i tag di catalogo si comporta in modo simile applicando tag criterio ai campi corrispondenti. Tuttavia, poiché a una colonna può essere applicato un solo tag criterio, la precedenza è la seguente:

1. Tag di criteri diretto:se un tag di criteri è definito direttamente nell'annotazione della colonna, ha la precedenza.
2. Norma del modello di tag di corrispondenza: in caso contrario, l'accesso viene determinato dal primo criterio di corrispondenza definito in un campo all'interno del modello di tag di catalogo associato.

Quando utilizzi questa funzionalità, ti consigliamo vivamente di attivare o disattivare insieme il deployment dei tag di catalogo e degli elenchi di controllo dell'accesso (ACL). In questo modo, le ACL vengono implementate correttamente.

Per comprendere le specifiche di questa funzionalità avanzata, consulta le definizioni dei parametri asset_policies e field_policies in data_mesh_types.CatalogTagTemplate.

Glossario del catalogo

Il glossario è uno strumento che può essere utilizzato per fornire un dizionario di termini utilizzati da colonne specifiche all'interno delle risorse di dati che potrebbero non essere universalmente compresi. Gli utenti possono aggiungere i termini manualmente nella console, ma non è supportato tramite le specifiche della risorsa.

Tassonomie e tag di criteri

Le tassonomie e i tag dei criteri consentono il controllo dell'accesso a livello di colonna su asset di dati sensibili in modo standardizzato. Ad esempio, potrebbe esserci una tassonomia per i tag che controllano i dati PII in una determinata attività commerciale, dove solo determinati gruppi possono leggere i dati mascherati, i dati non mascherati o non avere accesso in lettura.

Per ulteriori dettagli sulle tassonomie e sui tag delle norme, consulta la documentazione di Introduzione al mascheramento dei dati delle colonne. Le sezioni seguenti sono particolarmente pertinenti:

• Interazione tra i ruoli
• Ereditarietà delle autorizzazioni
• Regole di mascheramento e gerarchia
• Best practice per i tag delle norme

Cortex Framework fornisce tag criterio di esempio per dimostrare come vengono specificati e i potenziali utilizzi, tuttavia le risorse che influiscono sul controllo dell'accesso non sono attivate per impostazione predefinita nel deployment di Data Mesh.

Vedi l'esempio che segue.

Le tassonomie delle norme sono definite in file YAML che specificano data_mesh_types.PolicyTaxonomies.

Annotazioni degli asset

Le annotazioni specificano i metadati applicabili a una risorsa specifica e possono fare riferimento alle risorse di metadati condivisi che sono state definite. Le annotazioni includono:

• Descrizioni degli asset
• Descrizioni dei campi
• Tag del catalogo
• Controllo dell'accesso a livello di asset, riga e colonna

Nota: se modifichi un file di annotazioni, tieni presente che la console visualizza come spazi bianchi solo le nuove righe nelle descrizioni.

La base di dati di Cortex Framework offre annotazioni preconfigurate (descrizioni) per i seguenti carichi di lavoro.

• SAP ECC (dati non elaborati, CDC e report)
• SAP S4 HANA (dati non elaborati, CDC e report)
• SFDC (solo generazione di report)
• Oracle EBS (solo generazione di report)
• CM360 (solo report)
• Google Ads (solo report)
• Meta (solo generazione di report)
• SFMC (solo generazione di report)
• TikTok (solo generazione di report)
• YouTube (con DV360) (solo report)
• Google Analytics 4 (solo report)

Vedi l'esempio che segue.

Le annotazioni sono definite nei file YAML che specificano data_mesh_types.BqAssetAnnotation.

Tag del catalogo

I tag del catalogo sono istanze dei modelli definiti in cui vengono assegnati i valori di campo applicabili alla risorsa specifica. Assicurati di assegnare valori corrispondenti ai tipi di campo dichiarati nel modello associato.

I valori TIMESTAMP devono essere in uno dei seguenti formati:

  "%Y-%m-%d %H:%M:%S%z"
  "%Y-%m-%d %H:%M:%S"
  "%Y-%m-%d"

Vedi l'esempio che segue.

Consulta la definizione delle specifiche in data_mesh_types.CatalogTag.

Specifica di lettori e entità dei criteri di accesso

Controlla l'accesso ai dati di BigQuery in Cortex Framework utilizzando i criteri di accesso. Questi criteri definiscono chi (principali) può accedere a risorse di dati specifiche, righe all'interno di una risorsa o anche singole colonne. I principali devono seguire un formato specifico definito da IAM Policy Binding member.

Accesso a livello di asset

Puoi concedere l'accesso a interi asset BigQuery con varie autorizzazioni:

• READER: visualizza i dati nell'asset.
• WRITER: modifica e aggiungi dati all'asset.
• OWNER : controllo completo dell'asset, inclusa la gestione dell'accesso.

Queste autorizzazioni sono equivalenti all'istruzione GRANT DCL in SQL.

A differenza del comportamento della maggior parte delle risorse e delle annotazioni, il flag di sovrascrittura non rimuove i principali esistenti con il ruolo OWNERS. Quando aggiungi nuovi proprietari con l'opzione di sovrascrittura attivata, questi vengono aggiunti solo ai proprietari esistenti. Si tratta di una misura di salvaguardia per evitare la perdita involontaria dell'accesso. Per rimuovere i proprietari degli asset, utilizza la console. La sovrascrittura rimuove le entità esistenti con il ruolo READER o WRITER.

Vedi l'esempio che segue.

Consulta la definizione delle specifiche in data_mesh_types.BqAssetPolicy.

Accesso a livello di riga

Puoi concedere l'accesso a insiemi di righe in base a determinati filtri dei valori delle colonne. Quando specifichi il criterio di accesso alle righe, la stringa di filtro fornita verrà inserita in un CREATE DDL statement. Se il flag overwrite è attivato, vengono eliminati tutti i criteri di accesso alle righe esistenti prima di applicarne di nuovi.

Tieni presente quanto segue sull'accesso a livello di riga:

• L'aggiunta di qualsiasi criterio di accesso alle righe comporta che gli utenti non specificati in quelle policy non avranno accesso per visualizzare le righe.
• I criteri di riga funzionano solo con le tabelle, non con le visualizzazioni.
• Evita di utilizzare colonne partizionate nei filtri dei criteri di accesso alle righe. Consulta il file YAML delle impostazioni di generazione di report associato per informazioni sul tipo di asset e sulle colonne partizionate.

Per ulteriori informazioni sui criteri di accesso a livello di riga, consulta le best practice per la sicurezza a livello di riga.

Vedi l'esempio che segue.

Consulta la definizione delle specifiche in data_mesh_types.BqRowPolicy.

Accesso a livello di colonna

Per abilitare l'accesso a livello di colonna, annota i singoli campi con un tag criterio identificato dal nome del tag criterio e dal nome della tassonomia. Aggiorna la risorsa dei metadati dei tag delle norme per configurare il controllo dell'accesso.

Vedi l'esempio che segue.

Consulta la definizione delle specifiche in data_mesh_types.PolicyTagId.

Eseguire il deployment di Data Mesh

Il Data Mesh può essere implementato nell'ambito del deployment della data foundation o autonomamente. In entrambi i casi, utilizza il file Cortex config.json per determinare le variabili pertinenti, ad esempio i nomi dei set di dati BigQuery e le opzioni di implementazione. Per impostazione predefinita, il deployment di Data Mesh non rimuove né sovrascrive le risorse o le annotazioni esistenti per evitare perdite involontarie. Tuttavia, è anche possibile sovrascrivere le risorse esistenti quando viene eseguito il deployment in modo autonomo.

Opzioni di deployment

Le seguenti opzioni di implementazione possono essere attivate o disattivate in base alle esigenze e ai vincoli di spesa dell'utente in config.json > DataMesh.

Nota: se deployACLs è attivato, ti consigliamo vivamente di eseguire il controllo dell'accesso esclusivamente tramite queste specifiche delle risorse. In questo modo si impedisce l'aggiunta o la rimozione involontaria dell'accesso.

Opzione	Note
deployDescriptions	Questa è l'unica opzione abilitata per impostazione predefinita e consente di implementare le annotazioni BigQuery con descrizioni di asset e colonne. Non è richiesta l'abilitazione di API o autorizzazioni aggiuntive.
deployLakes	Esegue il deployment di lake e zone.
deployCatalog	Esegue il deployment delle risorse del modello di catalogo e dei relativi tag associati nelle annotazioni delle risorse.
deployACLs	Esegue il deployment delle risorse della tassonomia dei criteri e dei criteri di controllo dell'accesso a livello di asset, riga e colonna tramite le annotazioni degli asset. I log contengono messaggi che indicano in che modo sono state modificate le norme di accesso.

Deployment con Data Foundation

Per impostazione predefinita, config.json > deployDataMesh consente di eseguire il deployment delle descrizioni delle risorse Data Mesh alla fine di ogni passaggio di compilazione del workload. Questa configurazione predefinita non richiede l'attivazione di API o ruoli aggiuntivi. È possibile eseguire il deployment di funzionalità aggiuntive di Data Mesh con la base di dati attivando le opzioni di deployment, le API e i ruoli richiesti e modificando le specifiche delle risorse associate.

Deployment autonomo

Per eseguire il deployment solo di Data Mesh, gli utenti possono utilizzare il filecommon/data_mesh/deploy_data_mesh.py. Questa utility viene utilizzata durante le procedure di compilazione per eseguire il deployment del data mesh un carico di lavoro alla volta, ma se chiamata direttamente può essere utilizzata anche per eseguire il deployment di più carichi di lavoro contemporaneamente. I workload per le specifiche da eseguire devono essere abilitati nel file config.json. Ad esempio, assicurati che deploySAP=true se esegui il deployment di Data Mesh per SAP.

Per assicurarti di eseguire il deployment con i pacchetti e le versioni richiesti, puoi eseguire l'utilità dalla stessa immagine utilizzata dal processo di deployment di Cortex con i seguenti comandi:

  # Run container interactively
  docker container run -it gcr.io/kittycorn-public/deploy-kittycorn:v2.0

  # Clone the repo
  git clone https://github.com/GoogleCloudPlatform/cortex-data-foundation

  # Navigate into the repo
  cd cortex-data-foundation

Per assistenza sui parametri disponibili e sul loro utilizzo, esegui il seguente comando:

  python src/common/data_mesh/deploy_data_mesh.py -h

Di seguito è riportato un esempio di chiamata per SAP ECC:

  python src/common/data_mesh/deploy_data_mesh.py \
    --config-file config/config.json \
    --lake-directories \
        src/SAP/SAP_REPORTING/config/ecc/lakes \
    --tag-template-directories \
        src/SAP/SAP_REPORTING/config/ecc/tag_templates \
    --policy-directories \
        src/SAP/SAP_REPORTING/config/ecc/policy_taxonomies \
    --annotation-directories \
        src/SAP/SAP_REPORTING/config/ecc/annotations

Consulta la sezione Directory di Data Mesh per informazioni sulle posizioni delle directory.

Sovrascrivi

Attenzione: leggi attentamente questa sezione prima di utilizzare l'opzione di sovrascrittura.

Per impostazione predefinita, il deployment di Data Mesh non sovrascriverà le risorse o le annotazioni esistenti. Tuttavia, il flag --overwrite può essere attivato durante il deployment solo di Data Mesh per modificare il deployment nei seguenti modi.

La sovrascrittura delle risorse di metadati come laghi, modelli di tag di catalogo e tag di criteri elimina le risorse esistenti che condividono gli stessi nomi, ma non modifica le risorse esistenti con nomi diversi. Ciò significa che se una specifica della risorsa viene rimossa completamente dal file YAML e poi il Data Mesh viene riappliato con l'opzione di sovrascrittura attivata, la specifica della risorsa non verrà eliminata perché non ci sarà collisione dei nomi. In questo modo, il deployment di Cortex Data Mesh non influisce sulle risorse esistenti che potrebbero essere in uso.

Per le risorse nidificate come laghi e zone, l'overwriting di una risorsarimuove tutte le risorse figlio. Ad esempio, la sovrascrittura di un lakerimuove anche le zone e i riferimenti agli asset esistenti. Per i modelli di tag di catalogo e i tag delle norme che vengono sovrascritti, anche i riferimenti alle annotazioni associati esistenti vengono rimossi dalle risorse. La sovrascrittura dei tag di catalogo in un'annotazione della risorsa sovrascrive solo le istanze esistenti dei tag di catalogo che condividono lo stesso modello.

Le sostituzioni delle descrizioni delle risorse e dei campi vengono applicate solo se è presente una nuova descrizione valida non vuota che è in conflitto con la descrizione esistente.

Le ACL, invece, si comportano in modo diverso. Se sostituisci le ACL, vengono rimossi tutti gli entità esistenti (ad eccezione dei proprietari a livello di asset). Questo accade perché le entità omesse dai criteri di accesso sono ugualmente importanti per le entità a cui viene concesso l'accesso.

Esplorazione del data mesh

Dopo aver implementato il Data Mesh, gli utenti possono cercare e visualizzare gli asset di dati con Data Catalog. Sono incluse la possibilità di rilevare gli asset in base ai valori dei tag del catalogo applicati. Se necessario, gli utenti possono anche creare e applicare manualmente i termini del glossario del catalogo.

I criteri di accesso di cui è stato eseguito il deployment possono essere visualizzati nella pagina Schema BigQuery per vedere i criteri applicati a un determinato asset a ogni livello.

Derivazione dei dati

Gli utenti potrebbero trovare utile abilitare e visualizzare la sequenza tra gli asset BigQuery. È possibile accedere al lineage anche in modo programmatico tramite l'API. La funzionalità di organizzazione della cronologia dei dati supporta solo la cronologia a livello di asset. La cronologia dei dati non è correlata a Cortex Data Mesh, ma in futuro potrebbero essere introdotte nuove funzionalità che utilizzano Lineage.

Per qualsiasi richiesta relativa a Cortex Data Mesh o Cortex Framework, vai alla sezione Assistenza.