Schritt 5: Bereitstellung konfigurieren

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

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 gemäß den folgenden Parametern:

    Parameter Bedeutung Standardwert Beschreibung
    testData Testdaten bereitstellen true Das 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 das Rohdatenset leer ist und keine Tabellen enthält.
    deploySAP SAP bereitstellen true Führen Sie die Bereitstellung für die SAP-Arbeitslast (ECC oder S/4HANA) aus.
    deploySFDC Salesforce bereitstellen true Führen Sie die Bereitstellung für die Salesforce-Arbeitslast aus.
    deployMarketing Deploy Marketing true Führen Sie die Bereitstellung für Marketingquellen (Google Ads, CM360 und TikTok) aus.
    deployOracleEBS Oracle EBS bereitstellen true Führen Sie die Bereitstellung für die Oracle EBS-Arbeitslast aus.
    enableTaskDependencies Aufgabenabhängige DAGs false Aktivieren Sie aufgabenabhängige DAGs, damit unterstützte SQL-Tabellen innerhalb einzelner DAGs in der Reihenfolge ihrer Abhängigkeiten ausgeführt werden. Weitere Informationen finden Sie unter Aufgabenabhängige DAGs.
    turboMode Stellen Sie die Funktion im Turbomodus bereit. true Alle Ansichts-Builds als Schritt im selben Cloud Build-Prozess parallel ausführen, um die Bereitstellung zu beschleunigen. Wenn diese Option auf false festgelegt ist, wird jede Berichtsansicht 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.
    projectIdSource Quellprojekt-ID - Das Projekt, in dem sich das Quelldataset befindet und in dem der Build ausgeführt wird.
    projectIdTarget Zielprojekt-ID - Zielprojekt für nutzerorientierte Datasets.
    targetBucket Ziel-Bucket zum Speichern generierter DAG-Skripts - Bucket, der zuvor erstellt wurde und in dem DAGs (und temporäre Dataflow-Dateien) generiert werden. Verwenden Sie nicht den tatsächlichen Airflow-Bucket.
    location Standort oder Region "US" Standort des BigQuery-Datasets und der Cloud Storage-Buckets.

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

    testDataProject Quelle für Test-Harnisch kittycorn-public Quelle der Testdaten für Demobereitstellungen. Gilt, wenn testData true ist.

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

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

  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.

Optionale Schritte zur besseren Anpassung Ihres Deployments:

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:

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

Datei mit Berichtseinstellungen anpassen

Die reporting_settings-Dateien bestimmen, wie die BigQuery-Objekte (Tabellen oder Ansichten) für Berichts-Datasets 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 gesetzt 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. Details 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.

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 steuern:

Attribut Beschreibung Wert
column Spalte, nach der die CDC-Tabelle partitioniert wird. Spaltenname.
partition_type Typ der Partition. "time" für die zeitbasierte Partitionierung. 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.
time_grain Zeitabschnitt für die Partitionierung Erforderlich, wenn partition_type = "time". "hour", "day", "month" oder "year".
integer_range_bucket Bucket-Bereich Erforderlich, wenn partition_type = "integer_range" "start" = Startwert, "end" = Endwert und "interval = Intervall des Bereichs.

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:

Attribut Beschreibung Wert
columns Spalten, nach denen eine Tabelle geclustert wird. Liste der Spaltennamen. Beispiel: "mjahr" und "matnr".

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