Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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.
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-09-04 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis guide provides instructions for upgrading to new versions of the Cortex Framework Data Foundation while maintaining customizations made to fit organizational needs.\u003c/p\u003e\n"],["\u003cp\u003eCortex Framework Data Foundation is designed with openness and customization in mind, allowing organizations to utilize a variety of data integration, processing, and visualization tools alongside BigQuery.\u003c/p\u003e\n"],["\u003cp\u003eThe core components of Cortex Framework Data Foundation offer flexibility, enabling organizations to interchange tools, customize SQL views, and adjust performance optimization techniques to align with their specific needs.\u003c/p\u003e\n"],["\u003cp\u003eThe upgrade process involves forking the core repository, setting up a company repository, merging changes from the new Cortex release, and strategically addressing conflicts to retain customizations, and can be done with multiple variations.\u003c/p\u003e\n"],["\u003cp\u003eThe recommended process includes thorough testing and deployment of merged changes to ensure compatibility and proper functionality within the company's customized environment, before merging it into the main branch.\u003c/p\u003e\n"]]],[],null,["# Upgrade recommendations\n=======================\n\nThis page describes recommendations to upgrade to new versions from customized\n[Cortex Framework Data Foundation](https://github.com/GoogleCloudPlatform/cortex-data-foundation).\nOn every release, the Cortex team commits to minimize disruptions while it add\nnew features to the Cortex Framework. New updates prioritize backward\ncompatibility. However, this guide helps you minimize the possible issues.\n\n[Cortex Framework Data Foundation](https://github.com/GoogleCloudPlatform/cortex-data-foundation)\nprovides a set of predefined content and templates to accelerate value from\ndata replicated into [BigQuery](https://cloud.google.com/bigquery).\nOrganizations adapt these templates, modules, SQL, Python scripts, pipelines\nand other content provided to fit their needs.\n\nCore components\n---------------\n\nCortex Framework Data Foundation content is designed with a principle of openness in mind.\nOrganizations can use the tools that work best for them when working with\nthe BigQuery data models provided. The only platform on which\nthe foundation has a tight dependency on is BigQuery. All\nother tools can be interchanged as required:\n\n- **Data Integration:** Any integration tool that has interconnectivity with BigQuery can be leveraged provided it can replicate raw tables and structures. For example, raw tables should resemble the same schema as they were created in SAP (same names, fields, and data types). In addition, the integration tool should be able to provide basic transformation services such as updating target data types for BigQuery compatibility as well as adding additional fields like timestamp or operations flag for highlighting new and changed records.\n- **Data Processing:** The Change Data Capture (CDC) processing scripts provide work with [Cloud Composer](https://cloud.google.com/composer) (or Apache Airflow) are optional. Conversely, the SQL statements are produced separately from the Airflow-specific files where possible, so that customers can make use of the separate SQL files in another tool as needed.\n- **Data Visualization:** While [Looker](https://cloud.google.com/looker) dashboarding templates are provided and contain visualizations and minimum logic, the core logic remains available in the data foundation within BigQuery by design to create visualizations with their reporting tool of choice.\n\nKey benefits\n------------\n\nCortex Framework Data Foundation is designed to be adaptable to\nvarious business needs. Its components are built with flexibility,\nallowing organizations to tailor the platform to their specific\nrequirements and getting the following benefits:\n\n- **Openness**: Integrates seamlessly with various data integration, processing, and visualization tools beyond BigQuery.\n- **Customization:** Organizations can modify and expand pre built components like SQL views to match their data models and business logic.\n- **Performance Optimization:** Techniques like partitioning, data quality checks, and clustering can be adjusted based on individual workloads and data volumes.\n- **Backward Compatibility:** Cortex strives to maintain backward compatibility in future releases, minimizing disruption to existing implementations. For information about version changes, see the [Release Notes](/cortex/docs/release-notes).\n- **Community Contribution:** Encourages knowledge sharing and collaboration among users.\n\nUpdate process\n--------------\n\nThe following sections share the instructions for one way in which developers\ncan keep their code up-to-date with the Cortex Framework Data Foundation repository while\nretaining their customizations. Use of the pre-delivered deployment scripts in\nCI/CD pipelines. However, organizations can employ alternative tools and\nmethodologies to suit their preferences, such as [Dataform](/dataform/docs),\nor automation tools provided by the different Git hosts, such as GitHub actions.\n\n### Set up your repository\n\nThis section outlines one approach to setting up your repository. Before following\nthese steps, a solid understanding of Git is recommended.\n\n1. **[Fork](https://github.com/GoogleCloudPlatform/cortex-data-foundation/fork) core repository** :\n Create a fork of the Cortex Framework Data\n Foundation repository. The fork keeps\n that repository receiving updates from the Google Cloud repository, and a\n separate repository for the *Company's main*.\n\n2. **Create Company Repository**: Establish a new Git host for your\n company's repository (for example, Cloud Source). Create a repository with the same\n names as your forked repository on the new host.\n\n3. **Initialize Company Repository** : Copy the code from your forked Repository\n into the newly created company repository. Add the original forked repository as an\n [upstream remote repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork) with the following command,\n and verify the remote has been added. This establishes a connection between\n your company repository and the original repository.\n\n git remote add google \u003c\u003cremote URL\u003e\u003e\n git remote -v\n git push --all google\n\n4. **Verify Repository Setup**: Ensure your company repository contains the\n cloned code and history. You should see the two remotes,\n origin and the one you added after using the command:\n\n git remote -v:\n\n You now have the repository, the *Company's repository*, where\n developers can submit their changes. Developers can now clone and work in\n branches in the new repository.\n\n### Merge your changes with a new Cortex release\n\nThis section describes the process of merging changes from the *Company's repository*\nand changes coming from the Google Cloud repository.\n\n1. **Update forks** : Click **Sync fork** to update your forks for your\n repository with the changes from the Google Cloud repository. For example,\n the following changes to the *Company's repository* are done. And there has\n been some other changes in the Data Foundation repository by Google Cloud in a\n new release.\n\n - Created and incorporated the use of a new view in SQL\n - Modified existing views\n - Replaced a script entirely with our own logic\n\n The following commands sequence adds the fork repository as\n an upstream remote repository to pull the updated release from as *GitHub*\n and checks out its main branch as *GitHub-main.* Then, this example checks\n out the main branch from the *Company's repository* in Google Cloud Source\n and creates a branch for merging called `merging_br`. \n\n git remote add github \u003c\u003cgithub fork\u003e\u003e\n git fetch github main\n git checkout -b github-main github/main\n git checkout main\n git checkout -b merging_br\n\n There are multiple ways to build this flow. The merging process could also\n happen in the fork in GitHub, be replaced by a rebase instead of a merge,\n and the merging branch could also be sent as a merge request. These variations\n of the process depend on current organizational policies, depth of changes\n and convenience.\n\n With this setup in place, you can compare the incoming changes to your local\n changes. It's recommended to use a tool in a graphic IDE of choice to see the\n changes and choose what gets merged. For example, Visual Studio.\n\n It's recommended flagging customizations using comments that stand out\n visually, to make the diff process easier.\n2. **Start the merge process** : Use the created branch (in this example, is\n the branch called `merging_br`) to converge all changes\n and discard files. When ready, you can merge this branch back into the main or\n another branch for your Company's repository to create a merge request. From\n that merging branch that was checked out from your Company's repository's main\n (`git checkout merging_br`), merge the incoming changes from the remote fork.\n\n ## git branch -a\n ## The command shows github-main which was created from the GitHub fork\n ## You are in merging_br\n\n git merge github-main\n\n ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`\n\n This command generates a list of conflicts. Use the graphical IDE comparison\n to understand the changes and choose between *current* , *incoming* and *both*.\n This is where having a comment in the code around customizations becomes handy.\n Choose to discard changes altogether, delete files that you don't want to\n merge at all and ignore changes to views or scripts that you have already customized.\n3. **Merge changes**: After you have decided on the changes to apply, check the\n summary and commit them with the command:\n\n git status\n ## If something doesn't look right, you can use git rm or git restore accordingly\n git add --all #Or . or individual files\n git commit -m \"Your commit message\"\n\n If you feel insecure about any step, see [Git basic undoing things](https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things).\n4. **Test and deploy** : So far you are only merging into a \"temporary\" branch.\n It's recommended running a test deployment from the `cloudbuild\\*.yaml` scripts\n at this point to make sure everything is executing as expected. Automated\n testing can help streamline this process. Once this merging branch looks good,\n you can checkout your main target branch and merge the `merging_br` branch into it."]]
