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:

• Disattivazione della telemetria.
• Configurazione dei set di dati esterni per K9.
• Controlla la presenza di tag CORTEX-CUSTOMER.

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:

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:

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:

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.