Guida per l'utente di Data mesh

Data Mesh per Cortex Framework estende la base dei dati per consentire la governance, la rilevabilità e controllo dell'accesso ai dati tramite i metadati BigQuery e il catalogo universale Dataplex. Ciò 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 base di dati di Cortex Framework. Consulta la sezione Concetti di Data Mesh prima di procedere con questa guida.

I passaggi descritti in questa pagina sono progettati specificamente per configurare Data Mesh per Cortex Framework. Trova i file di configurazione di Data Mesh all'interno delle cartelle specifiche per ogni workload nella sezione Directory Data Mesh.

Design

Data Mesh di Cortex è progettato in modo simile alla base dati complessiva e consiste di tre fasi con diversi sottocomponenti gestiti da Cortex o dagli utenti:

1. Aggiornamento delle specifiche delle risorse di base: a 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 modo che siano in linea con i 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 eseguito il deployment dopo gli asset 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.

Directory 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 una struttura di file diversa, ma tutte le specifiche si trovano in modo simile nella cartella config.

Le risorse di metadati sono definite a livello di origine dati con un singolo file YAML per progetto Google Cloud e contengono un elenco di tutte le risorse. Se necessario, gli utenti possono estendere il file esistente o creare file YAML aggiuntivi contenenti specifiche di risorse aggiuntive all'interno di quella 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 consente di implementare funzionalità oltre le descrizioni. Se devi modificare i valori predefiniti per Data Mesh in config.json per implementare funzionalità oltre le descrizioni, assicurati che le API necessarie e le autorizzazioni siano impostate come indicato nella tabella seguente. Quando esegui il deployment di Data Mesh con la base dati, concedi le autorizzazioni all'utente che esegue il deployment o all'account Cloud Build. Se il deployment coinvolge progetti di origine e di destinazione diversi, assicurati che queste API e autorizzazioni siano abilitate in entrambi i progetti ovunque vengano utilizzate queste funzionalità.

Informazioni sulle specifiche della risorsa di base

L'interfaccia principale per configurare il Data Mesh per Cortex è tramite le specifiche delle risorse di base, ovvero un insieme di file YAML forniti preconfigurati che definiscono le risorse e le annotazioni dei metadati 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 varie risorse di dati. Ad esempio, i modelli di tag di Catalog che definiscono come gli asset possono essere taggati con i domini aziendali.
• Annotazioni che specificano come le risorse di metadati vengono applicate a una risorsa di dati specifica. Ad esempio, un tag catalogo che associa una tabella specifica al dominio Vendite.

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

Risorse per i metadati

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

• Contiene 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 introdurre requisiti aggiuntivi. In questi casi, sono inclusi i link alla documentazione canonica.

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

Lake Dataplex Universal Catalog

Lake, zone e asset di Dataplex Universal Catalog vengono utilizzati per organizzare i dati da un punto di vista ingegneristico. I lake hanno un region e le zone hanno un location_type, entrambi correlati alla località Cortex (config.json > location). La località 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 in modo che corrisponda. Tuttavia, le regioni del lago devono sempre essere una singola regione. Se la località e la zona location_type di Cortex sono multiregionali, seleziona una singola regione all'interno di questo gruppo per la regione Lake.

• Requisiti
  • Il lake display_name viene utilizzato come lake_id e deve rispettare i requisiti ufficiali. Questo vale anche 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 sola regione.
  • asset_name deve corrispondere all'ID del set di dati BigQuery, mentre display_name può essere un'etichetta più intuitiva.
• Limitazioni
  • Dataplex Universal Catalog supporta solo la registrazione di set di dati BigQuery anziché di singole tabelle come asset di Dataplex Universal Catalog.
  • Una risorsa potrebbe essere registrata in una sola zona.
  • Dataplex Universal Catalog è supportato solo in determinate località. Per saperne di più, consulta Località di Dataplex Universal Catalog.

Vedi 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 tuoi dati da un punto di vista tecnico e aziendale in un modo integrato con gli strumenti di ricerca di Dataplex Universal Catalog. Definiscono i campi specifici che puoi utilizzare per etichettare i dati e il tipo di informazioni che ogni campo può contenere (ad esempio testo, numero, data). I tag catalogo sono istanze dei modelli con valori di campo effettivi.

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

Cortex Data Mesh crea tutti i modelli di tag come leggibili pubblicamente. Introduce inoltre un concetto aggiuntivo level alle specifiche dei modelli di tag, che definisce se un tag deve essere applicato a un intero asset, a singoli campi all'interno di un asset o a entrambi, con i valori possibili: ASSET | FIELD | ANY. Sebbene al momento non sia strettamente applicata, i futuri controlli di convalida potrebbero garantire che i tag vengano applicati al livello appropriato durante il deployment.

Vedi il seguente esempio.

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

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

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

Cortex Framework offre la possibilità di attivare controllo dell'accesso a livello di asset o colonna su tutti gli artefatti 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 del catalogo line_of_business con diversi responsabili specificati per ogni dominio aziendale. Ogni norma accetta filters che possono essere utilizzati per trovare corrispondenze solo con tag con valori specifici. In questo caso potremmo abbinare i valori di 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 esempio, filter_a AND filter_b). L'insieme finale di norme sugli asset è l'unione di quelle definite direttamente nelle annotazioni e di quelle delle norme dei modelli.

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

1. Tag di policy diretto:se un tag di policy è definito direttamente nell'annotazione della colonna, ha la priorità.
2. Norma del modello di tag corrispondente: in caso contrario, l'accesso è determinato dalla prima norma corrispondente definita in un campo all'interno del modello di tag del catalogo associato.

Quando utilizzi questa funzionalità, ti consigliamo vivamente di attivare o disattivare l'implementazione di tag catalogo ed elenchi di controllo dell'accesso (ACL) insieme. 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 dei termini utilizzati da colonne specifiche all'interno degli asset di dati che potrebbero non essere compresi universalmente. Gli utenti possono aggiungere i termini manualmente nella console, ma non è previsto il supporto tramite le specifiche delle risorse.

Tassonomie e tag di policy

Le tassonomie e i tag dei criteri consentono il controllo dell'accesso a livello di colonna sugli asset di dati sensibili in modo standardizzato. Ad esempio, potrebbe esistere una tassonomia per i tag che controllano i dati PII in una particolare linea di business, in cui solo determinati gruppi possono leggere dati mascherati, dati non mascherati o non avere alcun accesso in lettura.

Per maggiori dettagli sulle tassonomie e sui tag delle norme, consulta la documentazione 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#39;accesso non sono abilitate nel deployment di Data Mesh per impostazione predefinita.

Vedi il seguente esempio.

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

Annotazioni degli asset

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

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

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

• SAP ECC (dati non elaborati, CDC e report)
• SAP S4 HANA (non elaborato, 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 il seguente esempio.

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

Tag catalogo

I tag catalogo sono istanze dei modelli definiti in cui vengono assegnati valori di campo che si applicano alla risorsa specifica. Assicurati di assegnare valori che corrispondano ai tipi di campo dichiarati nel modello associato.

I valori di 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 il seguente esempio.

Vedi la definizione delle specifiche in data_mesh_types.CatalogTag.

Specifica di lettori e entità del criterio di accesso

Controlla l'accesso ai tuoi dati BigQuery in Cortex Framework utilizzando i criteri di accesso. Queste norme definiscono chi (i principal) può accedere a risorse di dati specifiche, a righe all'interno di una risorsa o persino a singole colonne. I principal devono seguire un formato specifico definito dal membro del binding dei criteri IAM.

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 la sovrascrittura abilitata, 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 il seguente esempio.

Vedi 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 a livello di riga esistenti prima di applicare quelli nuovi.

Tieni presente quanto segue in merito all'accesso a livello di riga:

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

Per saperne di più sui criteri di accesso a livello di riga, consulta le best practice per la sicurezza a livello di riga.

Vedi il seguente esempio.

Vedi la definizione delle specifiche in data_mesh_types.BqRowPolicy.

Accesso a livello di colonna

Per attivare 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 di metadati tag di criteri per configurare controllo dell'accesso#39;accesso.

Vedi il seguente esempio.

Vedi la definizione delle specifiche in data_mesh_types.PolicyTagId.

Deployment del data mesh

Il Data Mesh può essere implementato nell'ambito dell'implementazione della base di dati oppure separatamente. In entrambi i casi, utilizza il file Cortex config.json per determinare le variabili pertinenti, come i nomi dei set di dati BigQuery e le opzioni di deployment. Per impostazione predefinita, il deployment del data mesh non rimuove né sovrascrive risorse o annotazioni esistenti per evitare perdite involontarie. Tuttavia, è anche possibile sovrascrivere le risorse esistenti quando vengono implementate autonomamente.

Opzioni di deployment

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

Deployment con Data Foundation

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

Deployment autonomo

Per eseguire il deployment della mesh di dati da sola, gli utenti possono utilizzare il filecommon/data_mesh/deploy_data_mesh.py. Questa utilità viene utilizzata durante i processi 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 implementare 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 con i parametri disponibili e il loro utilizzo, esegui questo 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 del data mesh per informazioni sulle posizioni delle directory.

Sovrascrivi

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

La sovrascrittura delle risorse di metadati come i lake, i modelli di tag del catalogo e i tag dei criteri elimina tutte le risorse esistenti che condividono gli stessi nomi, ma non modifica le risorse esistenti con nomi diversi. Ciò significa che se una specifica di risorsa viene rimossa completamente dal file YAML e poi il Data Mesh viene ridistribuito con la sovrascrittura abilitata, la specifica di risorsa non verrà eliminata perché non si verificherà una collisione di 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, la sovrascrittura di una risorsa rimuove tutti i relativi elementi secondari. Ad esempio, la sovrascrittura di un lake rimuove anche i riferimenti a zone e asset esistenti. Per i modelli di tag del catalogo e i tag delle norme sovrascritti, vengono rimosse anche le referenze di annotazione associate esistenti dalle risorse. La sovrascrittura dei tag catalogo in un'annotazione dell'asset sovrascrive solo le istanze esistenti dei tag catalogo che condividono lo stesso modello.

L'override della descrizione della risorsa e del campo ha effetto solo se viene fornita una nuova descrizione valida e non vuota che è in conflitto con la descrizione esistente.

D'altra parte, le ACL si comportano in modo diverso. La sovrascrittura degli ACL rimuove tutte le entità esistenti (ad eccezione dei proprietari a livello di asset). Questo perché le entità omesse dalle policy di accesso sono importanti quanto le entità a cui viene concesso l'accesso.

Esplorazione del data mesh

Dopo aver eseguito il deployment del data mesh, gli utenti possono cercare e visualizzare gli asset di dati con Data Catalog. Ciò include la possibilità di scoprire gli asset in base ai valori dei tag del catalogo che sono stati 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 una risorsa specifica a ogni livello.

Derivazione dei dati

Gli utenti potrebbero trovare utile attivare e visualizzare la derivazione tra gli asset BigQuery. È possibile accedere alla derivazione anche in modo programmatico tramite l'API. Data Lineage supporta solo la derivazione a livello di asset. Data Lineage non è intrecciato con Cortex Data Mesh, tuttavia 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.