Questa pagina è stata tradotta dall'API Cloud Translation.

Consigli per l'upgrade

Questa pagina descrive i consigli per eseguire l'upgrade alle nuove versioni da Cortex Framework Data Foundation personalizzato. A ogni release, il team di Cortex si impegna a ridurre al minimo le interruzioni durante l'aggiunta di nuove funzionalità a Cortex Framework. I nuovi aggiornamenti danno la priorità alla compatibilità con le versioni precedenti. Tuttavia, questa guida ti aiuta a ridurre al minimo i possibili problemi.

Cortex Framework Data Foundation fornisce un insieme di contenuti e modelli predefiniti per accelerare il valore dei dati replicati in BigQuery. Le organizzazioni adattano questi modelli, moduli, script SQL, Python, pipeline e altri contenuti forniti in base alle proprie esigenze.

Componenti principali

I contenuti di Cortex Data Foundation sono progettati in base al principio di apertura. Le organizzazioni possono utilizzare gli strumenti più adatti alle loro esigenze quando lavorano con i modelli di dati BigQuery forniti. L'unica piattaforma su cui la Fondazione ha una dipendenza stretta è BigQuery. Tutti gli altri strumenti possono essere scambiati in base alle esigenze:

Integrazione dei dati:qualsiasi strumento di integrazione che abbia interconnettività con BigQuery può essere utilizzato a condizione che possa replicare strutture e tabelle non elaborate. Ad esempio, le tabelle non elaborate devono avere lo stesso schema di quelle create in SAP (stessa denominazione, campi e tipi di dati). Inoltre, lo strumento di integrazione deve essere in grado di fornire servizi di trasformazione di base come l'aggiornamento dei tipi di dati di destinazione per la compatibilità con BigQuery, nonché l'aggiunta di campi aggiuntivi come timestamp o indicatore di operazioni per evidenziare i record nuovi e modificati.
Elaborazione dei dati: gli script di elaborazione di Change Data Capture (CDC) forniscono il lavoro con Cloud Composer (o Apache Airflow) sono facoltativi. Al contrario, ove possibile, le istruzioni SQL vengono prodotte separatamente dai file specifici di Airflow, in modo che i clienti possano utilizzare i file SQL separati in un altro strumento, se necessario.
Visualizzazione dei dati: anche se sono forniti modelli di dashboard di Looker che contengono visualizzazioni e logica minima, la logica di base rimane disponibile nella base dati di BigQuery per impostazione predefinita per creare visualizzazioni con lo strumento di generazione di report preferito.

Vantaggi principali

Cortex Framework Data Foundation è progettato per essere adattabile alle varie esigenze aziendali. I suoi componenti sono progettati per essere flessibili, consentendo alle organizzazioni di personalizzare la piattaforma in base alle loro esigenze specifiche e di ottenere i seguenti vantaggi:

Apertura: si integra perfettamente con vari strumenti di integrazione, elaborazione e visualizzazione dei dati oltre a BigQuery.
Personalizzazione:le organizzazioni possono modificare ed espandere i componenti predefiniti come le visualizzazioni SQL in base ai propri modelli di dati e alla propria logica aziendale.
Ottimizzazione delle prestazioni: tecniche come la partizione, i controlli della qualità dei dati e il clustering possono essere regolate in base ai singoli carichi di lavoro e ai volumi di dati.
Compatibilità con le versioni precedenti: Cortex si impegna a mantenere la compatibilità con le versioni precedenti nelle release future, riducendo al minimo le interruzioni delle implementazioni esistenti. Per informazioni sulle modifiche alle versioni, consulta le note di rilascio.
Contributo della community:incoraggia la condivisione delle conoscenze e la collaborazione tra gli utenti.

Aggiornamento processo

Le sezioni seguenti descrivono un modo in cui gli sviluppatori possono mantenere aggiornato il proprio codice con il repository Data Foundation di Cortex Framework mantenendo le proprie personalizzazioni. Utilizzo degli script di deployment pre-caricati nelle pipeline CI/CD. Tuttavia, le organizzazioni possono utilizzare strumenti e metodi alternativi in base alle proprie preferenze, come Dataform o gli strumenti di automazione forniti dai diversi host Git, come GitHub Actions.

Configura il tuo repository

Questa sezione illustra un approccio alla configurazione del repository. Prima di seguire questi passaggi, ti consigliamo di avere una buona conoscenza di Git.

Esegui il fork del repository principale: crea un fork del repository Data Foundation di Cortex Framework. Il fork mantiene il repository in cui vengono ricevuti gli aggiornamenti dal repository Google Cloud e un repository separato per il codice principale dell'azienda.
Crea repository dell'azienda: stabilisci un nuovo host Git per il repository della tua azienda (ad esempio Cloud Source). Crea un repository con gli stessi nomi del repository sottoposto a fork sul nuovo host.
Inizializza il repository dell'azienda: copia il codice dal repository sottoposto a forking nel repository dell'azienda appena creato. Aggiungi il repository sottoposto a forking originale come repository remoto upstream con il seguente comando e verifica che il repository remoto sia stato aggiunto. In questo modo viene stabilita una connessione tra il repository della tua azienda e il repository originale.
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
Verifica la configurazione del repository: assicurati che il repository della tua azienda contenga il codice e la cronologia clonati. Dovresti vedere i due telecomandi, origin e quello che hai aggiunto dopo aver utilizzato il comando:
```
git remote -v:
```
Ora hai il repository, il repository dell'azienda, dove gli sviluppatori possono inviare le loro modifiche. Ora gli sviluppatori possono clonare e lavorare nei branch del nuovo repository.

Unisci le modifiche con una nuova release di Cortex

Questa sezione descrive la procedura di unione delle modifiche provenienti dal repository dell'azienda e da quello Google Cloud .

Aggiorna i fork: fai clic su Sincronizza fork per aggiornare i fork del tuo repository con le modifiche apportate al repository. Google Cloud Ad esempio, vengono apportate le seguenti modifiche al repository dell'azienda. Inoltre, sono state apportate altre modifiche al repository Data Foundation da Google Cloud in una nuova release.
- È stata creata e incorporata l'utilizzo di una nuova vista in SQL
- Visualizzazioni esistenti modificate
- Abbiamo sostituito completamente uno script con la nostra logica
La seguente sequenza di comandi aggiunge il repository del fork come un repository remoto upstream da cui estrarre la release aggiornata come GitHub e ne esegue il check-out del ramo principale come GitHub-main. Poi, questo esempio esegue il check-out del ramo principale dal repository dell'azienda in Google Cloud Origine e crea un ramo per l'unione denominato merging_br.
```
git remote add github <<github fork>>
git fetch github main
git checkout -b github-main github/main
git checkout  main
git checkout -b merging_br
```
Esistono diversi modi per creare questo flusso. La procedura di unione potrebbe anche avvenire nel fork su GitHub, essere sostituita da un rebase anziché da un'unione e il ramo di unione potrebbe anche essere inviato come richiesta di unione. Queste variazioni della procedura dipendono dai criteri organizzativi attuali, dall'entità delle modifiche e dalla praticità.

Con questa configurazione, puoi confrontare le modifiche in arrivo con le modifiche locali. Ti consigliamo di utilizzare uno strumento in un'IDE grafica di tua scelta per vedere le modifiche e scegliere cosa unire. Ad esempio Visual Studio.

Per semplificare la procedura di confronto, ti consigliamo di segnalare le personalizzazioni utilizzando commenti che risaltano visivamente.
Avvia la procedura di unione: utilizza il ramo creato (in questo esempio, il ramo chiamato merging_br) per unire tutte le modifiche e ignorare i file. Quando è tutto pronto, puoi unire nuovamente questo ramo al ramo principale o a un altro ramo del repository della tua azienda per creare una richiesta di unione. Dal ramo di unione che è stato estratto dal ramo principale del repository della tua azienda (git checkout merging_br), unisci le modifiche in arrivo dal fork remoto.
```
    ## git branch -a
    ## The command shows github-main which was created from the GitHub fork
    ## You are in merging_br

    git merge github-main

    ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`
```
Questo comando genera un elenco di conflitti. Utilizza il confronto grafico dell'IDE per comprendere le modifiche e scegliere tra attuale, in entrata e entrambi. È qui che diventa utile inserire un commento nel codice relativo alle personalizzazioni. Scegli di ignorare del tutto le modifiche, di eliminare i file che non vuoi e di ignorare le modifiche apportate a visualizzazioni o script che hai già personalizzato.

Unisci modifiche: dopo aver deciso le modifiche da applicare, controlla il riepilogo e esegui il commit con il comando:

    git status
    ## If something doesn't look right, you can use git rm or git restore accordingly
    git add --all #Or . or individual files
    git commit -m "Your commit message"

Se hai dubbi su un passaggio, consulta Annullamento di operazioni di base in Git.

Test e deployment: finora hai eseguito l'unione solo in un ramo "temporaneo". A questo punto, ti consigliamo di eseguire un deployment di prova dagli script cloudbuild\*.yaml per assicurarti che tutto funzioni come previsto. I test automatici possono contribuire a semplificare questa procedura. Una volta che il ramo di unione è corretto, puoi eseguire il checkout del ramo di destinazione principale e unire il ramo merging_br.