Upgradeempfehlungen

Auf dieser Seite finden Sie Empfehlungen für das Upgrade auf neue Versionen der angepassten Cortex Framework Data Foundation. Bei jeder Version ist das Cortex-Team bestrebt, 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 mögliche Probleme minimieren.

Die Cortex Framework Data Foundation bietet eine Reihe vordefinierter Inhalte und Vorlagen, um den Wert von Daten, die in BigQuery repliziert werden, zu steigern. Unternehmen passen diese Vorlagen, Module, SQL-, Python-Skripts, Pipelines und andere bereitgestellte Inhalte an ihre Anforderungen an.

Kernkomponenten

Die Inhalte der Cortex Framework Data Foundation sind auf Offenheit ausgelegt. 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, von der die Grundlage stark abhängig ist, ist BigQuery. Alle anderen Tools können nach Bedarf ausgetauscht werden:

  • Datenintegration:Alle Integrationstools, die mit BigQuery verbunden werden können, können verwendet werden, sofern sie Rohdatentabellen und ‑strukturen replizieren können. Rohdatentabellen sollten beispielsweise dasselbe Schema wie in SAP haben (dieselben Namen, Felder und Datentypen). Außerdem sollte das Integrationstool grundlegende Transformationsdienste bieten, z. B. das Aktualisieren von Zieldatentypen für die BigQuery-Kompatibilität sowie das Hinzufügen zusätzlicher Felder wie Zeitstempel oder Operationsflag zum Hervorheben neuer und geänderter Datensätze.
  • Datenverarbeitung:Die Verarbeitungsskripts für Change Data Capture (CDC) für Managed Service for Apache Airflow (oder Apache Airflow) sind optional. Umgekehrt werden die SQL-Anweisungen nach Möglichkeit separat von den Airflow-spezifischen Dateien erstellt, sodass Kunden die separaten SQL-Dateien bei Bedarf in einem anderen Tool verwenden können.
  • Datenvisualisierung:Es werden Looker-Dashboardvorlagen mit Visualisierungen und minimaler Logik bereitgestellt. Die Kernlogik ist jedoch standardmäßig in der Datenbasis in BigQuery verfügbar, damit Sie Visualisierungen mit dem Reporting-Tool Ihrer Wahl erstellen können.

Hauptvorteile

Die Data Foundation von Cortex Framework ist so konzipiert, dass sie sich an verschiedene Geschäftsanforderungen anpassen lässt. Die Komponenten sind flexibel aufgebaut, sodass Unternehmen die Plattform an ihre spezifischen Anforderungen anpassen können. Das bietet folgende Vorteile:

  • Offenheit: Lässt sich nahtlos in verschiedene Tools zur Datenintegration, -verarbeitung und -visualisierung einbinden, die über BigQuery hinausgehen.
  • Anpassung:Organisationen können vorgefertigte Komponenten wie SQL-Ansichten an ihre Datenmodelle und Geschäftslogik anpassen und erweitern.
  • Leistungsoptimierung:Techniken wie Partitionierung, Datenqualitätsprüfungen und Clustering können an die jeweiligen Arbeitslasten und Datenvolumen angepasst werden.
  • Abwärtskompatibilität:Cortex ist bestrebt, die Abwärtskompatibilität in zukünftigen Versionen aufrechtzuerhalten, um Unterbrechungen bestehender Implementierungen zu minimieren. Informationen zu Versionsänderungen finden Sie in den Versionshinweisen.
  • Community-Beiträge:Fördern den Wissensaustausch und die Zusammenarbeit zwischen Nutzern.

Prozess aktualisieren

In den folgenden Abschnitten finden Sie eine Anleitung dazu, wie Entwickler ihren Code mit dem Repository „Cortex Framework Data Foundation“ auf dem neuesten Stand halten und gleichzeitig ihre Anpassungen beibehalten können. Verwendung der vorab bereitgestellten Bereitstellungsskripts 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 zum Einrichten Ihres Repositorys beschrieben. Bevor Sie diese Schritte ausführen, sollten Sie sich mit Git auskennen.

  1. Core-Repository forken: Erstellen Sie eine Fork des Cortex Framework Data Foundation-Repositorys. Durch das Forking erhält das Repository weiterhin Updates vom Google Cloud -Repository und es wird ein separates Repository für das Haupt-Repository des Unternehmens erstellt.

  2. Unternehmensrepository 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.

  3. Unternehmensrepository initialisieren: Kopieren Sie den Code aus Ihrem geforkten Repository in das neu erstellte Unternehmensrepository. Fügen Sie das ursprüngliche geforkte Repository 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 dem Repository Ihres Unternehmens und dem ursprünglichen Repository hergestellt.

    git remote add google <<remote URL>>
git remote -v
git push --all google

  4. Repository-Einrichtung überprüfen: Prüfen Sie, ob das Repository Ihres Unternehmens den geklonten Code und Verlauf enthält. Nachdem Sie den Befehl verwendet haben, sollten Sie die beiden Remotes „origin“ und die von Ihnen hinzugefügte sehen:

    git remote -v:

    Sie haben jetzt das Repository, das Repository des Unternehmens, in dem Entwickler ihre Änderungen einreichen können. Entwickler können das neue Repository jetzt klonen und in Branches arbeiten.

Änderungen mit einem neuen Cortex-Release zusammenführen

In diesem Abschnitt wird beschrieben, wie Sie Änderungen aus dem Repository des Unternehmens und Änderungen aus dem Google Cloud -Repository zusammenführen.

  1. Forks aktualisieren: Klicken Sie auf Fork synchronisieren, um Ihre Forks für Ihr Repository mit den Änderungen aus dem Google Cloud Repository zu aktualisieren. Im Folgenden werden beispielsweise die folgenden Änderungen am Repository des Unternehmens vorgenommen. Außerdem hat Google Cloud einige andere Änderungen am Data Foundation-Repository in einer neuen Version vorgenommen.

    • Eine neue Ansicht in SQL erstellt und eingebunden
    • Vorhandene Ansichten wurden geändert
    • Ein Skript wurde vollständig durch unsere eigene Logik ersetzt.

    Mit der folgenden Befehlsfolge wird das Fork-Repository als Upstream-Remote-Repository hinzugefügt, aus dem die aktualisierte Version als GitHub abgerufen wird, und der zugehörige Hauptzweig wird als GitHub-main ausgecheckt. In diesem Beispiel wird dann der Hauptzweig aus dem Repository des Unternehmens in Google Cloud Source ausgecheckt und ein Zweig zum Zusammenführen 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 verschiedene Möglichkeiten, diesen Ablauf zu erstellen. Der Zusammenführungsprozess kann auch im Fork auf GitHub erfolgen, durch einen Rebase anstelle einer Zusammenführung ersetzt werden und der Zusammenführungszweig kann auch als Merge-Anfrage gesendet werden. Diese Variationen des Prozesses hängen von den aktuellen Organisationsrichtlinien, dem Umfang der Änderungen und der Benutzerfreundlichkeit ab.

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

    Es wird empfohlen, Anpassungen mit Kommentaren zu kennzeichnen, die sich visuell abheben, um den Vergleichsprozess zu erleichtern.

  2. Zusammenführungsprozess starten: Verwenden Sie den erstellten Branch (in diesem Beispiel merging_br), um alle Änderungen zusammenzuführen und Dateien zu verwerfen. Wenn Sie bereit sind, können Sie diesen Zweig wieder mit dem Hauptzweig oder einem anderen Zweig für das Repository Ihres Unternehmens zusammenführen, um eine Merge-Anfrage zu erstellen. Führen Sie in diesem zusammenzuführenden Zweig, der aus dem Hauptzweig (git checkout merging_br) des Repositorys Ihres Unternehmens ausgecheckt 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 von Konflikten generiert. Verwenden Sie den grafischen IDE-Vergleich, um die Änderungen nachzuvollziehen und zwischen Aktuell, Eingehend und Beide zu wählen. Hier ist es hilfreich, wenn Sie einen Kommentar im Code zu den Anpassungen haben. Sie können Änderungen vollständig verwerfen, Dateien löschen, die Sie überhaupt nicht zusammenführen möchten, und Änderungen an Ansichten oder Scripts ignorieren, die Sie bereits angepasst haben.

  3. Änderungen zusammenführen: Nachdem Sie sich für die anzuwendenden Änderungen entschieden haben, prüfen Sie die Zusammenfassung und übernehmen Sie sie mit dem folgenden Befehl:

        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 unsicher sind, lesen Sie den Abschnitt Git basic undoing things.

  4. Testen und bereitstellen: Bisher führen Sie nur in einen „temporären“ Branch zusammen. Wir empfehlen, an dieser Stelle eine Testbereitstellung über die cloudbuild\*.yaml-Skripts auszuführen, um sicherzustellen, dass alles wie erwartet ausgeführt wird. Automatisierte Tests können diesen Prozess optimieren. Wenn dieser Zusammenführungszweig gut aussieht, können Sie Ihren Hauptzielzweig auschecken und den merging_br-Zweig darin zusammenführen.