Passaggio 5: configura il deployment

Questa pagina descrive il quinto passaggio per il deployment di Cortex Framework Data Foundation, il componente principale di Cortex Framework. In questo passaggio, modifichi il file di configurazione nel repository Data Foundation di Cortex Framework in base ai tuoi requisiti.

File di configurazione

Il comportamento del deployment è controllato dal file di configurazione config.json nella base dati di Cortex Framework. Questo file contiene la configurazione globale e quella specifica per ogni workload. Modifica il file config.json in base alle tue esigenze seguendo questi passaggi:

  1. Apri il file config.json da Cloud Shell.

  2. Modifica il file config.json in base ai seguenti parametri:

    Parametro Significato Valore predefinito Descrizione
    testData Esegui il deployment dei dati di test true Progetto in cui si trova il set di dati di origine e in cui vengono eseguite le build. Nota: il deployment dei dati di test verrà eseguito solo se il set di dati non elaborato è vuoto e non contiene tabelle.
    deploySAP Esegui il deployment di SAP true Esegui il deployment per il workload SAP (ECC o S/4 HANA).
    deploySFDC Esegui il deployment di Salesforce true Esegui il deployment per il carico di lavoro Salesforce.
    deployMarketing Deploy Marketing true Esegui il deployment per le origini di marketing (Google Ads, CM360 e TikTok).
    deployOracleEBS Esegui il deployment di Oracle EBS true Esegui il deployment per il workload Oracle EBS.
    deployDataMesh Esegui il deployment di Data Mesh true Esegui il deployment per Data Mesh. Per ulteriori informazioni, consulta la Guida dell'utente di Data Mesh.
    enableTaskDependencies DAG dipendenti dalle attività false Attiva i DAG dipendenti dalle attività in modo che le tabelle SQL supportate vengano eseguite in base all'ordine di dipendenza all'interno di singoli DAG. Per maggiori informazioni, vedi DAG dipendenti dalle attività.
    turboMode Esegui il deployment in modalità Turbo. true Esegui tutte le build delle visualizzazioni come passaggio nello stesso processo Cloud Build, in parallelo per un deployment più rapido. Se impostato su false, ogni visualizzazione dei report viene generata in un passaggio di build sequenziale separato. Ti consigliamo di impostarlo su true solo quando utilizzi dati di test o dopo aver risolto eventuali discrepanze tra le colonne dei report e i dati di origine.
    projectIdSource ID progetto di origine - Progetto in cui si trova il set di dati di origine e in cui vengono eseguite le build.
    projectIdTarget ID progetto di destinazione - Progetto di destinazione per i set di dati rivolti agli utenti.
    targetBucket Bucket di destinazione in cui archiviare gli script DAG generati - Bucket creato in precedenza in cui vengono generati i DAG (e i file temporanei di Dataflow). Evita di utilizzare il bucket Airflow effettivo.
    location Località o regione "US" Posizione in cui si trovano il set di dati BigQuery e i bucket Cloud Storage.

    Consulta le limitazioni elencate in Località dei set di dati BigQuery.

    testDataProject Origine per test harness kittycorn-public Origine dei dati di test per le implementazioni demo. Si applica quando testData è true.

    Non modificare questo valore, a meno che tu non disponga di un harness di test personalizzato.

    k9.datasets.processing Set di dati K9 - Elaborazione "K9_PROCESSING" Esegui modelli cross-workload (ad esempio, la dimensione data) come definito nel file di configurazione K9. Questi modelli sono normalmente richiesti dai workload downstream.
    k9.datasets.reporting Set di dati K9 - Report "K9_REPORTING" Esegui modelli cross-workload e origini dati esterne (ad esempio: meteo) come definito nel file di configurazione K9. Commentato per impostazione predefinita.
    DataMesh.deployDescriptions Data Mesh - Asset descriptions true Esegui il deployment delle descrizioni dello schema degli asset BigQuery.
    DataMesh.deployLakes Data mesh - Data lake e zone false Il deployment di lake e zone di Dataplex Universal Catalog che organizzano le tabelle per livello di elaborazione richiede la configurazione prima dell'attivazione.
    DataMesh.deployCatalog Data Mesh - Catalog Tags and Templates false Il deployment dei tag Data Catalog che consentono metadati personalizzati su asset o campi BigQuery richiede la configurazione prima dell'attivazione.
    DataMesh.deployACLs Data Mesh - Controllo dell'accesso false Esegui il deployment controllo dell'accesso a livello di asset, riga o colonna sugli asset BigQuery. Richiede la configurazione prima dell'attivazione.

  3. Configura i workload richiesti in base alle esigenze. Non è necessario configurarli se il parametro di deployment (ad esempio deploySAP o deployMarketing) per il workload è impostato su False. Per saperne di più, vedi Passaggio 3: determina il meccanismo di integrazione.

Per una migliore personalizzazione del deployment, consulta i seguenti passaggi facoltativi:

Ottimizzazione del rendimento per le visualizzazioni dei report

Gli artefatti di reporting possono essere creati come viste o come tabelle aggiornate regolarmente tramite i DAG. Da un lato, le viste calcolano i dati a ogni esecuzione di una query, il che mantiene i risultati sempre aggiornati. D'altra parte, la tabella esegue i calcoli una sola volta e i risultati possono essere interrogati più volte senza incorrere in costi di calcolo più elevati e ottenendo un runtime più rapido. Ogni cliente crea la propria configurazione in base alle proprie esigenze.

I risultati materializzati vengono aggiornati in una tabella. Queste tabelle possono essere ottimizzate ulteriormente aggiungendo partizionamento e clustering.

I file di configurazione per ogni workload si trovano nei seguenti percorsi all'interno del repository Cortex Framework Data Foundation:

Origine dati File di impostazioni
Operativo - SAP src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml
Operativo - Salesforce Sales Cloud src/SFDC/config/reporting_settings.yaml
Operativo - Oracle EBS src/oracleEBS/config/reporting_settings.yaml
Marketing - Google Ads src/marketing/src/GoogleAds/config/reporting_settings.yaml
Marketing - CM360 src/marketing/src/CM360/config/reporting_settings.yaml
Marketing - Meta src/marketing/src/Meta/config/reporting_settings.yaml
Marketing - Salesforce Marketing Cloud src/marketing/src/SFMC/config/reporting_settings.yaml
Marketing - TikTok src/marketing/src/TikTok/config/reporting_settings.yaml
Marketing - YouTube (con DV360) src/marketing/src/DV360/config/reporting_settings.yaml
Marketing - Google Analytics 4 src/marketing/src/GA4/config/reporting_settings.yaml
Marketing - Approfondimenti cross-media e sui prodotti connessi src/marketing/src/CrossMedia/config/reporting_settings.yaml

Personalizzare il file delle impostazioni dei report

I file reporting_settings determinano la modalità di creazione degli oggetti BigQuery (tabelle o viste) per i set di dati dei report. Personalizza il file con le seguenti descrizioni dei parametri. Tieni presente che questo file contiene due sezioni:

  1. bq_independent_objects: Tutti gli oggetti BigQuery che possono essere creati in modo indipendente, senza altre dipendenze. Quando Turbo mode è abilitato, questi oggetti BigQuery vengono creati in parallelo durante il tempo di deployment, velocizzando il processo di deployment.
  2. bq_dependent_objects: tutti gli oggetti BigQuery che devono essere creati in un ordine specifico a causa delle dipendenze da altri oggetti BigQuery. Turbo mode non si applica a questa sezione.

Il programma di deployment crea prima tutti gli oggetti BigQuery elencati in bq_independent_objects e poi tutti gli oggetti elencati in bq_dependent_objects. Definisci le seguenti proprietà per ogni oggetto:

  1. sql_file: il nome del file SQL che crea un determinato oggetto.
  2. type: tipo di oggetto BigQuery. Valori possibili:
    • view : se vuoi che l'oggetto sia una vista BigQuery.
    • table: se vuoi che l'oggetto sia una tabella BigQuery.
    • script: serve per creare altri tipi di oggetti (ad esempio, funzioni BigQuery e procedure archiviate).
  3. Se type è impostato su table, è possibile definire le seguenti proprietà facoltative:
    • load_frequency: frequenza con cui viene eseguito un DAG Composer per aggiornare questa tabella. Per informazioni dettagliate sui valori possibili, consulta la documentazione di Airflow.
    • partition_details: come deve essere partizionata la tabella. Questo valore è facoltativo. Per ulteriori informazioni, consulta la sezione Partizione della tabella.
    • cluster_details: Come deve essere raggruppata la tabella. Questo valore è facoltativo. Per saperne di più, consulta la sezione Impostazioni cluster.

Partizione della tabella

Alcuni file di impostazioni consentono di configurare tabelle materializzate con opzioni di clustering e partizionamento personalizzate. Ciò può migliorare significativamente le prestazioni delle query per set di dati di grandi dimensioni. Questa opzione si applica solo ai file SAP cdc_settings.yaml e a tutti i file reporting_settings.yaml.

Il partizionamento delle tabelle può essere attivato specificando quanto seguepartition_details:

- base_table: vbap
  load_frequency: "@daily"
  partition_details: {
    column: "erdat", partition_type: "time", time_grain: "day" }

Utilizza i seguenti parametri per controllare i dettagli del partizionamento per una determinata tabella:

Proprietà Descrizione Valore
column Colonna in base alla quale è partizionata la tabella CDC. Nome della colonna.
partition_type Tipo di partizione. "time" per la partizione basata sul tempo. Per ulteriori informazioni, vedi Tabelle partizionate in base al timestamp. "integer_range" per la partizione basata su numeri interi. Per saperne di più, consulta la documentazione sull'intervallo di numeri interi.
time_grain Parte dell'ora da partizionare Obbligatorio quando partition_type = "time". "hour", "day", "month" o "year".
integer_range_bucket Intervallo del bucket Obbligatorio quando partition_type = "integer_range" "start" = Valore iniziale, "end" = Valore finale e "interval" = Intervallo dell'intervallo.

Per ulteriori informazioni sulle opzioni e sulle limitazioni correlate, consulta Partizione della tabella BigQuery.

Impostazioni cluster

Il clustering delle tabelle può essere abilitato specificando cluster_details:

  - base_table: vbak
    load_frequency: "@daily"
    cluster_details: {columns: ["vkorg"]}

Utilizza i seguenti parametri per controllare i dettagli del cluster per una determinata tabella:

Proprietà Descrizione Valore
columns Colonne in base alle quali è raggruppata una tabella. Elenco dei nomi delle colonne. Ad esempio, "mjahr" e "matnr".

Per saperne di più sulle opzioni e sulle limitazioni correlate, consulta la documentazione sui cluster di tabelle.

Passaggi successivi

Dopo aver completato questo passaggio, vai al passaggio di deployment successivo:

  1. Stabilire i carichi di lavoro.
  2. Clona il repository.
  3. Determinare il meccanismo di integrazione.
  4. Configura i componenti.
  5. Configura il deployment (questa pagina).
  6. Esegui il deployment.