Schritt 5: Bereitstellung konfigurieren

Auf dieser Seite wird der fünfte Schritt zum Bereitstellen der Cortex Framework Data Foundation, dem Kern von Cortex Framework, beschrieben. In diesem Schritt passen Sie die Konfigurationsdatei im Repository „Cortex Framework Data Foundation“ an Ihre Anforderungen an.

Hinweis :Die auf dieser Seite beschriebenen Schritte sind speziell für die Bereitstellung der Cortex Framework Data Foundation aus dem offiziellen GitHub-Repository vorgesehen.

Konfigurationsdatei

Das Verhalten des Deployments wird durch die Konfigurationsdatei config.json in der Cortex Framework Data Foundation gesteuert. Diese Datei enthält die globale Konfiguration und die spezifische Konfiguration für jede Arbeitslast. Bearbeiten Sie die Datei config.json nach Bedarf. Gehen Sie dazu so vor:

1. Öffnen Sie die Datei config.json in Cloud Shell.

2. Bearbeiten Sie die Datei config.json anhand der folgenden Parameter:

   Hinweis :Weitere Parameter speziell für Cortex for Meridian finden Sie unter Zusätzliche Bereitstellungsparameter für Meridian.
   <td"> Parameter <td">Bedeutung <td">Standardwert <td">Beschreibung </td"></td"></td"></td"><td">testData <td">Testdaten bereitstellen <td">true <td">Projekt, in dem sich das Quelldataset befindet und in dem der Build ausgeführt wird. Hinweis: Die Bereitstellung von Testdaten wird nur ausgeführt, wenn der Rohdatensatz leer ist und keine Tabellen enthält. </td"></td"></td"></td"><td">deploySAP <td">SAP bereitstellen <td">true <td">Stellen Sie die Bereitstellung für den SAP-Arbeitslast (ECC oder S/4 HANA) bereit. </td"></td"></td"></td"><td">deploySFDC <td">Salesforce bereitstellen <td">true <td">Stellen Sie die Salesforce-Arbeitslast bereit. </td"></td"></td"></td"><td">deployMarketing <td">Marketing bereitstellen <td">true <td">Stellen Sie die Marketingquellen (Google Ads, CM360 und TikTok) bereit. </td"></td"></td"></td"><td">deployOracleEBS <td">Oracle EBS bereitstellen <td">true <td">Stellen Sie die Oracle EBS-Arbeitslast bereit. </td"></td"></td"></td"><td">enableTaskDependencies <td">Aufgabenabhängige DAGs <td">false <td">Aktivieren Sie aufgabenabhängige DAGs, damit unterstützte SQL-Tabellen in einzelnen DAGs in der Reihenfolge der Abhängigkeiten ausgeführt werden. Weitere Informationen finden Sie unter Aufgabenabhängige DAGs. </td"></td"></td"></td"><td">turboMode <td">Im Turbomodus bereitstellen. <td">true <td">Alle Ansichts-Builds als Schritt im selben Cloud Build-Prozess parallel ausführen, um die Bereitstellung zu beschleunigen. Wenn auf false festgelegt, wird jede Berichtsdatenansicht in einem eigenen sequenziellen Build-Schritt generiert. Wir empfehlen, den Wert nur auf true zu setzen, wenn Sie Testdaten verwenden oder nachdem alle Abweichungen zwischen den Berichtsspalten und den Quelldaten behoben wurden. </td"></td"></td"></td"><td">projectIdSource <td">Source Project ID <td">- <td">Project where the source dataset is and the build runs. </td"></td"></td"></td"><td">projectIdTarget <td">Target Project ID <td">- <td">Target project for user-facing datasets. </td"></td"></td"></td"><td">targetBucket <td">Ziel-Bucket zum Speichern generierter DAG-Scripts <td">- <td">Bucket, das zuvor erstellt wurde, in dem DAGs (und temporäre Dataflow-Dateien) generiert werden. Verwenden Sie nicht den tatsächlichen Airflow-Bucket. </td"></td"></td"></td"><td">location <td">Standort oder Region <td">"US" <td">Standort des BigQuery-Datasets und der Cloud Storage-Buckets.

   Die Einschränkungen finden Sie unter BigQuery-Dataset-Standorte.

   </td"></td"></td"></td"><td">testDataProject <td">Quelle für Test-Harness <td">kittycorn-public <td">Quelle der Testdaten für Demobereitstellungen. Gilt, wenn testData true ist.

   Ändern Sie diesen Wert nur, wenn Sie einen eigenen Testharness haben.

   </td"></td"></td"></td"><td">k9.datasets.processing <td">K9-Datasets – Verarbeitung <td">"K9_PROCESSING" <td">Führen Sie Vorlagen für verschiedene Arbeitslasten (z. B. Datumsdimension) aus, wie in der K9-Konfigurationsdatei definiert. Diese Vorlagen sind normalerweise für die nachgelagerten Arbeitslasten erforderlich. </td"></td"></td"></td"><td">k9.datasets.reporting <td">K9-Datasets – Berichterstellung <td">"K9_REPORTING" <td">Führen Sie Vorlagen für verschiedene Arbeitslasten und externe Datenquellen (z. B. Wetter) gemäß der K9-Konfigurationsdatei aus. Standardmäßig auskommentiert. </td"></td"></td"></td">

3. Konfigurieren Sie die erforderlichen Arbeitslasten nach Bedarf. Sie müssen sie nicht konfigurieren, wenn der Bereitstellungsparameter (z. B. deploySAP oder deployMarketing) für die Arbeitslast auf False festgelegt ist. Weitere Informationen finden Sie unter Schritt 3: Integrationsmechanismus festlegen.

Hinweis :Wenn Sie mehrere Cortex Framework-Arbeitslasten installieren, müssen Sie die Kontingente für Build and Operation Get requests per minute und Build and Operation Get requests per minute per user erhöhen. Weitere Informationen finden Sie unter Kontingente und Systemlimits.

Optionale Schritte zur besseren Anpassung Ihres Deployments:

• Telemetrie deaktivieren:
• Konfiguration externer Datasets für K9.
• Nach CORTEX-CUSTOMER-Tags suchen:

Leistungsoptimierung für Berichtsansichten

Berichtsobjekte können als Ansichten oder als Tabellen erstellt werden, die regelmäßig über DAGs aktualisiert werden. Einerseits werden die Daten in Ansichten bei jeder Ausführung einer Abfrage berechnet, sodass die Ergebnisse immer aktuell sind. Bei der Tabelle werden die Berechnungen nur einmal ausgeführt. Die Ergebnisse können mehrmals abgefragt werden, ohne dass höhere Rechenkosten anfallen. Außerdem ist die Laufzeit kürzer. Jeder Kunde erstellt seine eigene Konfiguration entsprechend seinen Anforderungen.

Materialisierte Ergebnisse werden in einer Tabelle aktualisiert. Diese Tabellen können durch Hinzufügen von Partitionierung und Clustering weiter optimiert werden.

Die Konfigurationsdateien für die einzelnen Arbeitslasten befinden sich in den folgenden Pfaden im Cortex Framework Data Foundation-Repository:

<td">Datenquelle <td">Einstellungsdateien </td"></td"><td">Betrieblich – SAP <td">src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml </td"></td"><td">Betrieblich – Salesforce Sales Cloud <td">src/SFDC/config/reporting_settings.yaml </td"></td"><td">Betrieblich – Oracle EBS <td">src/oracleEBS/config/reporting_settings.yaml </td"></td"><td">Marketing – Google Ads <td">src/marketing/src/GoogleAds/config/reporting_settings.yaml </td"></td"><td">Marketing – CM360 <td">src/marketing/src/CM360/config/reporting_settings.yaml </td"></td"><td">Marketing – Meta <td">src/marketing/src/Meta/config/reporting_settings.yaml </td"></td"><td">Marketing – Salesforce Marketing Cloud <td">src/marketing/src/SFMC/config/reporting_settings.yaml </td"></td"><td">Marketing – TikTok <td">src/marketing/src/TikTok/config/reporting_settings.yaml </td"></td"><td">Marketing – YouTube (mit DV360) <td">src/marketing/src/DV360/config/reporting_settings.yaml </td"></td"><td">Marketing – Google Analytics 4 <td">src/marketing/src/GA4/config/reporting_settings.yaml </td"></td"><td">Marketing – Cross-Media- und produktbezogene Statistiken <td">src/marketing/src/CrossMedia/config/reporting_settings.yaml </td"></td">

Datei mit Berichtseinstellungen anpassen

Die reporting_settings-Dateien steuern, wie die BigQuery-Objekte (Tabellen oder Ansichten) für Berichtsdatasets erstellt werden. Passen Sie Ihre Datei mit den folgenden Parameterbeschreibungen an. Diese Datei enthält zwei Abschnitte:

1. bq_independent_objects: Alle BigQuery-Objekte, die unabhängig und ohne andere Abhängigkeiten erstellt werden können. Wenn Turbo mode aktiviert ist, werden diese BigQuery-Objekte parallel während der Bereitstellungszeit erstellt, was den Bereitstellungsprozess beschleunigt.
2. bq_dependent_objects: Alle BigQuery-Objekte, die aufgrund von Abhängigkeiten von anderen BigQuery-Objekten in einer bestimmten Reihenfolge erstellt werden müssen. Turbo mode gilt nicht für diesen Abschnitt.

Der Deployer erstellt zuerst alle in bq_independent_objects aufgeführten BigQuery-Objekte und dann alle in bq_dependent_objects aufgeführten Objekte. Definieren Sie die folgenden Attribute für jedes Objekt:

1. sql_file: Name der SQL-Datei, mit der ein bestimmtes Objekt erstellt wird.
2. type: Typ des BigQuery-Objekts. Mögliche Werte:
   • view : Wenn das Objekt eine BigQuery-Ansicht sein soll.
   • table: Wenn das Objekt eine BigQuery-Tabelle sein soll.
   • script: Damit können Sie andere Arten von Objekten erstellen, z. B. BigQuery-Funktionen und gespeicherte Prozesse.
3. Wenn type auf table festgelegt ist, können die folgenden optionalen Attribute definiert werden:
   • load_frequency: Häufigkeit, mit der eine Composer-DAG ausgeführt wird, um diese Tabelle zu aktualisieren. Weitere Informationen zu möglichen Werten finden Sie in der Airflow-Dokumentation.
   • partition_details: Wie die Tabelle partitioniert werden soll. Dieser Wert ist optional. Weitere Informationen finden Sie im Abschnitt Tabellenpartition.
   • cluster_details: Gibt an, wie die Tabelle gruppiert werden soll. Dieser Wert ist optional. Weitere Informationen finden Sie im Abschnitt Clustereinstellungen.

Hinweis :Wenn Sie aufgabenabhängige DAGs aktiviert haben, indem Sie das Feld enableTaskDependencies auf True gesetzt haben, müssen Sie für jede Datenquelle, für die Aufgabenabhängigkeiten erforderlich sind, eine separate Datei mit Berichtseinstellungen mit dem Suffix _task_dep.yaml erstellen. Weitere Informationen finden Sie unter Aufgabenabhängige DAGs.

Tabellenpartition

Mit bestimmten Einstellungsdateien können Sie materialisierte Tabellen mit benutzerdefinierten Clustering- und Partitionierungsoptionen konfigurieren. Dies kann die Abfrageleistung für große Datasets erheblich verbessern. Diese Option gilt nur für SAP cdc_settings.yaml- und alle reporting_settings.yaml-Dateien.

Die Tabellenpartitionierung kann durch Angabe der folgendenpartition_detailsaktiviert werden:

- base_table: vbap
  load_frequency: "@daily"
  partition_details: {
    column: "erdat", partition_type: "time", time_grain: "day" }

Mit den folgenden Parametern können Sie die Partitionierungsdetails für eine bestimmte Tabelle festlegen:

<td">Property <td">Description <td">Value </td"></td"></td"><td">column <td">Spalte, nach der die CDC-Tabelle partitioniert wird. <td">Spaltenname. </td"></td"></td"><td">partition_type <td">Typ der Partition. <td">"time" für zeitbasierte Partition. Weitere Informationen finden Sie unter Nach Zeitstempel partitionierte Tabellen. "integer_range" für die Partitionierung auf Grundlage von Ganzzahlen. Weitere Informationen finden Sie in der Dokumentation zu Ganzzahlbereichen. </td"></td"></td"><td">time_grain <td">Time part to partition with Required when partition_type = "time". <td">"hour", "day", "month" oder "year". </td"></td"></td"><td">integer_range_bucket <td">Bucket range Required when partition_type = "integer_range" <td">"start" = Start value, "end" = End value, and "interval" = Interval of range. </td"></td"></td">

Weitere Informationen zu Optionen und zugehörigen Einschränkungen finden Sie unter BigQuery-Tabellenpartition.

Clustereinstellungen

Tabellen-Clustering kann durch Angabe von cluster_details aktiviert werden:

  - base_table: vbak
    load_frequency: "@daily"
    cluster_details: {columns: ["vkorg"]}

Mit den folgenden Parametern können Sie Clusterdetails für eine bestimmte Tabelle festlegen:

<td">Property <td">Description <td">Value </td"></td"></td"><td">columns <td">Spalten, nach denen eine Tabelle geclustert wird. <td">Liste der Spaltennamen. Beispiel: "mjahr" und "matnr". </td"></td"></td">

Weitere Informationen zu Optionen und zugehörigen Einschränkungen finden Sie in der Dokumentation zu Tabellenclustern.

Nächste Schritte

Fahren Sie nach Abschluss dieses Schritts mit dem folgenden Bereitstellungsschritt fort:

1. Arbeitslasten einrichten:
2. Repository klonen
3. Integrationsmechanismus festlegen:
4. Komponenten einrichten
5. Bereitstellung konfigurieren (diese Seite).
6. Bereitstellung ausführen