Diese Seite wurde von der Cloud Translation API übersetzt.

Upgradeempfehlungen

Auf dieser Seite werden Empfehlungen für das Upgrade auf neue Versionen von benutzerdefinierten Cortex Framework Data Foundation beschrieben. Bei jeder Veröffentlichung verpflichtet sich das Cortex-Team, Unterbrechungen zu minimieren, während es dem Cortex Framework neue Funktionen hinzufügt. Bei neuen Updates wird die Abwärtskompatibilität priorisiert. Mit diesem Leitfaden können Sie jedoch die möglichen Probleme minimieren.

Die Cortex Framework Data Foundation bietet eine Reihe vordefinierter Inhalte und Vorlagen, mit denen sich der Wert von Daten, die in BigQuery repliziert werden, schneller steigern lässt. Unternehmen passen diese Vorlagen, Module, SQL-, Python-Scripts, Pipelines und andere bereitgestellte Inhalte an ihre Anforderungen an.

Kernkomponenten

Die Inhalte der Cortex Framework Data Foundation sind nach dem Prinzip der Offenheit konzipiert. Organisationen können die Tools verwenden, die für sie am besten geeignet sind, wenn sie mit den bereitgestellten BigQuery-Datenmodellen arbeiten. Die einzige Plattform, auf die die Stiftung stark angewiesen ist, ist BigQuery. Alle anderen Tools können bei Bedarf ausgetauscht werden:

Datenintegration: Jedes Integrationstool, das eine Verknüpfung mit BigQuery hat, kann verwendet werden, sofern es Rohtabellen und ‑strukturen replizieren kann. Rohtabellen sollten beispielsweise demselben Schema entsprechen, wie sie in SAP erstellt wurden (gleiche Namen, Felder und Datentypen). Außerdem sollte das Integrationstool grundlegende Transformationsdienste bereitstellen können, z. B. das Aktualisieren von Zieldatentypen für die BigQuery-Kompatibilität sowie das Hinzufügen zusätzlicher Felder wie Zeitstempel oder Vorgangsflag, um neue und geänderte Einträge hervorzuheben.
Datenverarbeitung:Die Verarbeitungsscripts für die Änderungsdatenerfassung (Change Data Capture, CDC) sind optional und können mit Cloud Composer (oder Apache Airflow) verwendet werden. Umgekehrt werden die SQL-Anweisungen nach Möglichkeit getrennt von den Airflow-spezifischen Dateien erstellt, damit Kunden die separaten SQL-Dateien bei Bedarf in einem anderen Tool verwenden können.
Datenvisualisierung: Es werden zwar Dashboard-Vorlagen für Looker bereitgestellt, die Visualisierungen und eine minimale Logik enthalten, die Hauptlogik bleibt jedoch in der Datengrundlage in BigQuery verfügbar, um Visualisierungen mit dem gewünschten Berichtstool zu erstellen.

Hauptvorteile

Die Cortex Framework Data Foundation ist so konzipiert, dass sie an verschiedene Geschäftsanforderungen angepasst werden kann. Die Komponenten sind flexibel aufgebaut, sodass Organisationen die Plattform an ihre spezifischen Anforderungen anpassen und von den folgenden Vorteilen profitieren können:

Offenheit: Lässt sich nahtlos in verschiedene Tools zur Datenintegration, ‑verarbeitung und ‑visualisierung integrieren, die über BigQuery hinausgehen.
Anpassung: Organisationen können vorgefertigte Komponenten wie SQL-Ansichten ändern und erweitern, um sie an ihre Datenmodelle und Geschäftslogik anzupassen.
Leistungsoptimierung:Verfahren wie Partitionierung, Datenqualitätsprüfungen und Clustering können an individuelle Arbeitslasten und Datenmengen angepasst werden.
Abwärtskompatibilität:Cortex bemüht sich, die Abwärtskompatibilität in zukünftigen Releases beizubehalten, um Unterbrechungen bei bestehenden Implementierungen zu minimieren. Informationen zu Versionsänderungen finden Sie in den Versionshinweisen.
Communitybeitrag:Ermöglicht den Austausch von Wissen und die Zusammenarbeit zwischen Nutzern.

Prozess aktualisieren

In den folgenden Abschnitten wird eine Möglichkeit beschrieben, wie Entwickler ihren Code mit dem Cortex Framework Data Foundation-Repository auf dem neuesten Stand halten und gleichzeitig ihre Anpassungen beibehalten können. Verwendung der vorinstallierten Bereitstellungsscripts in CI/CD-Pipelines Organisationen können jedoch alternative Tools und Methoden verwenden, die ihren Anforderungen entsprechen, z. B. Dataform oder Automatisierungstools, die von den verschiedenen Git-Hosts bereitgestellt werden, z. B. GitHub-Aktionen.

Repository einrichten

In diesem Abschnitt wird ein Ansatz zur Einrichtung Ihres Repositories beschrieben. Bevor Sie diese Schritte ausführen, sollten Sie mit Git vertraut sein.

Fork des Kern-Repositorys: Erstellen Sie einen Fork des Cortex Framework Data Foundation-Repositorys. Über die Fork erhält dieses Repository weiterhin Updates aus dem Google Cloud -Repository und ein separates Repository für die Hauptversion des Unternehmens.
Unternehmens-Repository erstellen: Richten Sie einen neuen Git-Host für das Repository Ihres Unternehmens ein (z. B. Cloud Source). Erstellen Sie auf dem neuen Host ein Repository mit denselben Namen wie Ihr geforktes Repository.
Unternehmens-Repository initialisieren: Kopieren Sie den Code aus Ihrem geforkten Repository in das neu erstellte Unternehmens-Repository. Fügen Sie das ursprüngliche Repository, das geforkt wurde, mit dem folgenden Befehl als Upstream-Remote-Repository hinzu und prüfen Sie, ob das Remote-Repository hinzugefügt wurde. Dadurch wird eine Verbindung zwischen Ihrem Unternehmens-Repository und dem ursprünglichen Repository hergestellt.
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
Repository-Einrichtung prüfen: Achten Sie darauf, dass Ihr Unternehmens-Repository den geklonten Code und den Verlauf enthält. Sie sollten die beiden Remotes sehen, „origin“ und diejenige, die Sie nach Eingabe des Befehls hinzugefügt haben:
```
git remote -v:
```
Sie haben jetzt das Repository, das Repository des Unternehmens, in dem Entwickler ihre Änderungen einreichen können. Entwickler können jetzt Branches im neuen Repository klonen und darin arbeiten.

Änderungen mit einem neuen Cortex-Release zusammenführen

In diesem Abschnitt wird beschrieben, wie Änderungen aus dem Repository des Unternehmens und Änderungen aus dem Google Cloud -Repository zusammengeführt werden.

Forks aktualisieren: Klicken Sie auf Fork synchronisieren, um Ihre Forks für Ihr Repository mit den Änderungen aus dem Google Cloud -Repository zu aktualisieren. Angenommen, die folgenden Änderungen werden am Repository des Unternehmens vorgenommen. Außerdem gab es in einer neuen Version von Google Cloud einige weitere Änderungen am Data Foundation-Repository.
- Neue Ansicht in SQL erstellt und verwendet
- Vorhandene Ansichten geändert
- Ein Script wurde vollständig durch unsere eigene Logik ersetzt.
Mit der folgenden Befehlssequenz wird das Fork-Repository als Upstream-Remote-Repository hinzugefügt, um die aktualisierte Version von GitHub abzurufen, und der Hauptzweig wird als GitHub-main herausgecheckt. Anschließend wird in diesem Beispiel der Hauptzweig aus dem Repository des Unternehmens in Google Cloud Source geholt und ein Merge-Zweig namens merging_br erstellt.
```
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
```
Es gibt mehrere Möglichkeiten, diesen Ablauf zu erstellen. Der Zusammenführungsprozess kann auch im Fork auf GitHub erfolgen, durch einen Rebase anstelle eines Zusammenführens ersetzt werden und der Zusammenführungszweig kann auch als Zusammenführungsanfrage gesendet werden. Diese Varianten des Prozesses hängen von den aktuellen organisatorischen Richtlinien, dem Umfang der Änderungen und der Nutzerfreundlichkeit ab.

So können Sie die ankommenden Änderungen mit Ihren lokalen Änderungen vergleichen. Es empfiehlt sich, ein Tool in einer beliebigen grafischen IDE zu verwenden, um die Änderungen zu sehen und auszuwählen, was zusammengeführt werden soll. z. B. Visual Studio.

Es wird empfohlen, Anpassungen mit Kommentaren zu kennzeichnen, die sich visuell abheben, um den Vergleich zu erleichtern.
Zusammenführungsprozess starten: Verwenden Sie den erstellten Branch (in diesem Beispiel merging_br), um alle Änderungen zusammenzuführen und Dateien zu verwerfen. Wenn Sie fertig sind, können Sie diesen Zweig wieder mit dem Hauptzweig oder einem anderen Zweig des Repositorys Ihres Unternehmens zusammenführen, um einen Zusammenführungsantrag zu erstellen. Führen Sie aus diesem Merge-Zweig, der aus dem Hauptzweig (git checkout merging_br) des Repositorys Ihres Unternehmens herausgecheckt wurde, die eingehenden Änderungen aus dem Remote-Fork zusammen.
```
    ## 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`
```
Mit diesem Befehl wird eine Liste der Konflikte generiert. Verwenden Sie den grafischen IDE-Vergleich, um die Änderungen zu verstehen, und wählen Sie zwischen aktuell, eingehend und beide aus. Hier ist ein Kommentar im Code zu Anpassungen hilfreich. Sie können Änderungen vollständig verwerfen, Dateien löschen, die nicht zusammengeführt werden sollen, und Änderungen an Ansichten oder Scripts ignorieren, die Sie bereits angepasst haben.
Änderungen zusammenführen: Nachdem Sie sich für die anzuwendenden Änderungen entschieden haben, prüfen Sie die Zusammenfassung und führen Sie sie mit dem Befehl commit aus:
```
    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"
```
Wenn Sie sich bei einem Schritt nicht sicher sind, lesen Sie den Hilfeartikel Grundlegende Schritte zum Rückgängigmachen in Git.
Testen und bereitstellen: Bisher haben Sie nur einen „vorübergehenden“ Branch zusammengeführt. Es wird empfohlen, an dieser Stelle eine Testbereitstellung über die cloudbuild\*.yaml-Scripts auszuführen, um sicherzustellen, dass alles wie erwartet ausgeführt wird. Automatisierte Tests können diesen Prozess optimieren. Sobald dieser Zusammenführungszweig in Ordnung ist, können Sie den Hauptzielzweig auschecken und den Zweig merging_br mit ihm zusammenführen.