Configuration du déploiement

Ce document décrit les options de configuration du déploiement pour Cortex Framework dans les domaines suivants :

Ce guide fournit également des guides pratiques avec des instructions détaillées pour les cas d'utilisation et les scénarios de déploiement courants.

Fichier de configuration : config/config.yaml

Le fichier config/config.yaml, généralement initialisé à partir du modèle config/config.yaml.example, sert de configuration principale pour le déploiement du Cortex Framework. Il définit des paramètres critiques, y compris le projet d'exécution cible Google Cloud , les ensembles de données BigQuery source et de destination, ainsi que les spécifications Dataform telles que les noms de dépôt et d'espace de travail.

Les sections suivantes fournissent une description détaillée de la structure config/config.yaml.

Environnement de compilation

Le projet d'environnement de compilation est celui qui est facturé pour les actions de compilation, telles que les jobs BigQuery (lecture de DD03L).

buildEnvironment:
  buildProjectId: YOUR_BUILD_PROJECT_ID

Le tableau suivant décrit les paramètres de l'environnement de compilation.

Paramètre Signification Valeur par défaut Description
buildEnvironment.buildProjectId ID du projet de compilation YOUR_BUILD_PROJECT_ID Google Cloud  : ID du projet dans lequel les opérations de compilation sont exécutées.

Présentation de la section "Données"

La section data: du fichier de configuration définit vos sources de données, vos cibles et les modules spécifiques pour la base de données et les produits de données. Sa structure générale est la suivante :

data:
   # Geographic location for BigQuery datasets (for example: US, EU, us-central1)
   # For full list see: https://docs.cloud.google.com/cortex/docs/supported-locations
  bigQueryLocation: US
  # List of namespaces for data foundation and product modules.
  namespaces:
    - name: cortex
      path: cortex
  # List of source datasets.
  sources:
    - ...
  # List of target datasets.
  targets:
    - ...

  # Configuration for data foundation and product modules.
  modules:
    # List of foundation modules.
    foundation:
    - ... 
    # List of data product modules.
    product:
    - ...

Données : emplacement BigQuery

Définit l'emplacement des ensembles de données source et cible BigQuery.

Paramètre Signification Valeur par défaut Description
data.bigQueryLocation Emplacement BigQuery US Emplacement de l'ensemble de données BigQuery (par exemple, US, us-central1 ou europe-west1).

Données : espace de noms Cortex

Définit l'espace de noms Cortex Framework.

Paramètre Signification Valeur par défaut Description
data.namespaces.name Nom de l'espace de noms - Nom de l'espace de noms Cortex Framework. Par exemple, cortex.
data.namespaces.path Chemin d'accès à l'espace de noms - Chemin d'espace de noms du Cortex Framework pour les sous-répertoires utilisés dans les dossiers src et config. Par exemple, cortex.

Données : sources BigQuery et ensembles de données cibles

La liste des sources définit les ensembles de données BigQuery dans lesquels les données brutes du système source ont été répliquées ou diffusées.

Les cibles définissent une liste d'ensembles de données BigQuery dans lesquels les ensembles de données traités par Dataform seront stockés.

Chacune des sources et des cibles est référencée à partir des modules à l'aide de son ID unique.

# Data source and target mapping
sources:
  - id: sap_raw
    projectId: YOUR_SOURCE_PROJECT_ID
    datasetId: cortex_sap_raw

targets:
  - id: sap_foundation
    projectId: YOUR_TARGET_PROJECT_ID
    datasetId: cortex7_sap_data_foundation

Le tableau suivant décrit les paramètres de mappage de la source de données et de la cible.

Paramètre Signification Valeur par défaut Description
data.sources.id ID source - Définit l 'ID de l'ensemble de données source à partir duquel extraire les données. Par exemple, sap_raw.
data.sources.projectId ID du projet source YOUR_SOURCE_PROJECT_ID Fait référence à l'ID du projet Google Cloud avec les données sources.
data.sources.datasetId ID de l'ensemble de données BigQuery source - Fait référence à l'ID de l'ensemble de données BigQuery contenant les données sources. Par exemple, cortex_sap_raw.
data.targets.id ID de la cible - Définit l 'ID de l'ensemble de données cible. Par exemple, sap_foundation.
data.targets.projectId ID du projet cible YOUR_TARGET_PROJECT_ID Fait référence à l'ID du projet Google Cloud pour les données cibles.
data.targets.datasetId ID de l'ensemble de données BigQuery cible - Fait référence à l'ID de l'ensemble de données BigQuery pour les données cibles. Par exemple, cortex7_sap_data_foundation.

Données : modules

Les modules définissent la structure et les composants des pipelines de données Dataform.

Données : modules : principes de base

Cette section configure les modules de la couche de base de données qui traitent les données de la couche brute (flux CDC) pour obtenir une représentation standardisée des derniers enregistrements des données sources. Si la source fournit directement une vue sur les derniers enregistrements ou si de telles transformations sont effectuées par le connecteur du système source, le module peut être configuré comme source de data foundation externe.

modules:
  # List of foundation modules.
  foundation:
    # Unique identifier for the module instance.
    - moduleId: erp
      # Type of the module (namespaced, for example, cortex.sap).
      type: cortex.sap
      # Reference to the source dataset ID.
      dataSourceId: sap_raw
      # Reference to the target dataset ID.
      dataTargetId: sap_foundation
      # Module-specific configuration settings.
      moduleSettings:
        # SAP version (for example, ecc, s4).
        sapVersion: ecc
        # SAP client number.
        mandt: "100"
      # Whether the module is enabled.
      # enabled: true
      # Whether the foundation is external (does not create target dataset).
      # external: false
      # Custom table settings file, relative to 'config/' file directory
      # Recommended path: '{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
      # Default path: '../src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml'
      # tableSettings: "custom_datafoundation_table_settings.yaml"

Le tableau suivant décrit les paramètres des modules de fondation de données pour la configuration modules.foundation.

Paramètre Signification Valeur par défaut Description
moduleId Identifiant du module erp Identifiant unique d'une instance de module de transformation de la base de données.
type Type logique du module cortex.sap Définit la logique métier ou le modèle appliqué (par exemple, cortex.sap).
dataSourceId Lien source sap_raw Fait référence à l'ID de la liste data.sources à partir de laquelle extraire les données.
dataTargetId Lien cible sap_foundation Fait référence à l'ID de la liste des cibles vers laquelle transférer les données.
moduleSettings.sapVersion Version du système SAP ecc Applicable uniquement aux sources de données SAP. Détermine la logique spécifique à la source pour les systèmes ecc (ECC) ou s4 (S/4HANA).
moduleSettings.mandt Client SAP (Mandant) 100 Applicable uniquement aux sources de données SAP. Identifiant client SAP à trois chiffres utilisé pour filtrer les lignes de données.
enabled Activation des modules true Indique si le module est activé.
external Fondation externe false Indique si la base est externe (ne crée pas d'ensemble de données cible).
tableSettings Paramètres de table src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml Chemin d'accès au fichier de configuration personnalisé Table settings, relatif à ce fichier de configuration.
Chemin recommandé : relatif au répertoire `config/` : '{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
Chemin par défaut : '../src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml'

Données : Modules : Produits

Les modules de produits de données définissent les agrégations, les calculs et les jointures nécessaires pour transformer les données brutes en insights qui répondent à des cas d'utilisation métier spécifiques.

La configuration des produits de données permet de définir un ID unique, de définir des dépendances, ainsi que de référencer le module de base de données et l'ensemble de données cible dans lequel les résultats seront stockés.

La configuration détaillée des produits de données spécifiés est définie dans les fichiers référencés par la clé tableSettings.

modules:
  # List of data product modules.
  product:
    # Unique identifier for the data product instance.
    - moduleId: sap_purchasing_organizational_structure
      # Type of the data product (namespaced).
      type: cortex.purchasing_organizational_structure
      # Map of module dependencies.
      dependsOn:
        sapModule: erp
      # Reference to the target dataset ID.
      dataTargetId: product_target
      # Whether the module is enabled.
      # enabled: true

      # Custom table settings file, relative to 'config/' file directory
      # Recommended path: '{namespace}/data_product/{data_product_module_type}/table_settings.yaml'
      # If omitted, defaults to '../src/data_modules/{namespace}/data_product/{data_product_module_type}/table_settings.default.yaml'
      # tableSettings: "custom_dataproduct_table_settings.yaml"

Le tableau suivant décrit les paramètres des modules de produits de données pour la configuration modules.product.

Paramètre Signification Valeur par défaut Description
moduleId Identifiant du module - Identifiant unique d'une instance de module de transformation spécifique.
type Type logique du module - Définit la logique métier ou le modèle appliqué, défini dans le dossier src/data_modules/{namespace}/data_product/{data_product_module_type}.
dataTargetId Lien cible product_target Fait référence à l'ID de la liste des cibles vers laquelle transférer les données.
dependsOn Dépendance en amont sapModule: erp Spécifie le module de base qui doit exister avant que le module produit puisse être créé.
enabled Activation des modules true Indique si le module est activé.
tableSettings Paramètres de table src/data_modules/{namespace}/data_product/{data_product_module_type}/table_settings.default.yaml Chemin d'accès au fichier de configuration personnalisé Table settings, relatif à ce fichier de configuration.
Chemin recommandé : relatif au répertoire "config/" : "{namespace}/data_product/{data_product_module_type}/table_settings.yaml"
Chemin par défaut : "../src/data_modules/{namespace}/data_product/{data_product_module_type}/table_settings.default.yaml"

Environnement de déploiement

Cortex Framework utilise Dataform pour orchestrer les transformations SQL dans BigQuery. Le bloc deployment: définit la configuration Dataform, responsable de l'exécution des pipelines de données, y compris le projet de dépôt, l'emplacement, le nom du dépôt et le nom de l'espace de travail Dataform.

deployment:
  targets:
    - type: dataform
      enabled: true
      targetSettings:
        repositoryProjectId: YOUR_REPO_PROJECT_ID
        repositoryRegion: us-central1
        repositoryName: cortex-repository
        workspaceName: dev
        # serviceAccount: "example@example.com"

Le tableau suivant décrit les paramètres de localisation des cibles de déploiement (deployment.targets:).

Paramètre Signification Valeur par défaut Description
type Type de déploiement dataform Type des cibles de déploiement.
enabled Activé/ Désactivé true Indique si la cible de déploiement donnée est activée ou désactivée.
targetSettings.repositoryProjectId ID du projet de dépôt YOUR_REPO_PROJECT_ID ID du projet Google Cloud dans lequel le dépôt Dataform est géré.
targetSettings.repositoryRegion Région du dépôt us-central1 Région Google Cloud du dépôt Dataform (par exemple, us-central1 ou europe-west1).
targetSettings.repositoryName Nom du dépôt cortex-repository Nom spécifique du dépôt Dataform.
targetSettings.workspaceName Nom de l'espace de travail dev Espace de travail Dataform spécifique utilisé pour le cycle de déploiement.
targetSettings.serviceAccount Adresse e-mail du compte de service - Adresse e-mail du compte de service par défaut pour l'exécution du dépôt Dataform.

Fichier de configuration : table_settings.yaml

Ce guide explique comment utiliser le fichier table_settings.yaml pour configurer les tables de la base de données et des produits de données dans Google Cloud Cortex Framework.

Le fichier table_settings.yaml spécifique au module de données contrôle la façon dont les tables sources brutes sont conformées et dont les modèles de données analytiques sont matérialisés dans BigQuery. À l'aide de ce fichier, vous pouvez configurer des tags, des stratégies de matérialisation et des fonctionnalités avancées de performances BigQuery, comme le partitionnement ou le clustering.

Résolution dynamique des dépendances

Par défaut, Cortex Framework optimise l'empreinte de déploiement et le temps d'exécution en ne déployant et en ne compilant que les tables de base requises en tant que dépendances de vos produits de données activés. Si une table configurée dans table_settings.yaml ne comporte aucun produit de données en aval actif qui en dépend, elle est exclue du déploiement.

Pour remplacer cette optimisation et forcer le déploiement d'une table de fondation, vous pouvez définir l'attribut deployAlways sur true (voir Référence des paramètres de style de la fondation de données).

Dans Google Cloud Cortex Framework, un fichier de paramètres de tableau spécifique peut être attribué à chaque module (de base ou produit) dans le fichier de configuration du déploiement : config/config.yaml à l'aide de la propriété tableSettings.

Chemins de configuration

  • Paramètres personnalisés (recommandé) : pour personnaliser le comportement des tableaux, copiez le fichier par défaut dans votre répertoire de configuration, modifiez-le et référencez son chemin d'accès dans config/config.yaml. Voici les chemins d'accès recommandés (par rapport au répertoire config/) :
    • Modules de base : namespace/data_foundation/data_foundation/custom_table_settings.yaml (par exemple, config/cortex/data_foundation/sap/table_settings.yaml)
    • Modules de produit : namespace/data_product/data_product/custom_table_settings.yaml (par exemple, config/cortex/data_product/accounting_documents/table_settings.yaml)
  • Solution de repli par défaut : si tableSettings est omis, le framework revient automatiquement à :
    • Modules de base : ../src/data_modules/namespace/data_foundation/data_foundation/table_settings.default.yaml
    • Modules de produits : ../src/data_modules/namespace/data_product/data_product/table_settings.default.yaml

Styles de configuration

Il existe deux styles de schéma distincts pour table_settings.yaml, selon la catégorie du module :

  1. Style de la couche de données : mappage basé sur une liste qui définit les relations entre le schéma source et le schéma cible, la gestion de la CDC (capture des données modifiées) et la mise en page BigQuery.
  2. Style du produit de données : mappage basé sur une carte (dictionnaire) qui définit la manière dont les vues ou les tables analytiques sont matérialisées (par exemple, en tant que vues, tables ou tables incrémentales) et optimisées.

Les deux styles sont compatibles avec trois sections de niveau racine pour séparer les configurations par version du système source (principalement utilisées pour SAP Data Foundation et les produits dépendants de SAP) :

  • ecc : paramètres appliqués uniquement lors du déploiement d'un système source SAP ECC.
  • s4 : paramètres appliqués uniquement lors du déploiement d'un système source SAP S/4HANA.
  • common : paramètres appliqués quelle que soit la version SAP (utilisés pour les paramètres conformes ou universels).

Style de base de données

Dans un module Data Foundation, le fichier table_settings.yaml est structuré sous forme de liste d'éléments de tableau sous les clés ecc, s4 et common. Chaque élément mappe une table source brute à une table cible conforme et configure ses paramètres BigQuery.

Exemple de syntaxe YAML

common:
  - source:
      tableName: bkpf
      isCdc: true
    target:
      tableName: bkpf # Optional: defaults to source tableName if omitted
      tags: [sap, common, finance, hourly]
      clusterDetails:
        columns: [bukrs, gjahr]
      partitionDetails:
        column: budat
        partitionType: time
        timeGrain: day
    deployAlways: false

Référence de paramètre

Paramètre Type Obligatoire Par défaut / Exemple Description
ecc | s4 | common string Non [] Version ou dialecte du système source.
[].deployAlways boolean Non false Si la valeur est true, la table est toujours déployée et créée, même si les règles d'optimisation pourraient normalement l'ignorer. Consultez également Résolution dynamique des dépendances.
Paramètres de la source

Définit les caractéristiques de la table brute des données entrantes.

Paramètre Type Obligatoire Par défaut / Exemple Description
tableName string Oui bkpf Nom de la table source brute dans BigQuery (non sensible à la casse).
isCdc boolean Non true Indique si la table source contient des journaux de capture des données modifiées (CDC).

• true (par défaut) : le framework traite les journaux CDC (à l'aide des codes temporels et des indicateurs d'opération) pour reconstruire le dernier état conforme.

• false : la table est traitée comme un instantané complet.
Paramètres de ciblage

Définit la mise en page de la table conforme de sortie dans l'ensemble de données cible.

Paramètre Type Obligatoire Par défaut / Exemple Description
tableName string Non *(Même source)* Nom de la table conforme cible à créer. Si aucune valeur n'est spécifiée, le framework est défini par défaut sur la source tableName.
tags array[string] Non [sap, finance] Liste des tags de métadonnées associés à l'action conforme dans Dataform. Il s'agit de chaînes arbitraires qui n'ont pas besoin d'être préenregistrées ni définies dans d'autres configurations. Elles peuvent être utilisées immédiatement pour filtrer les exécutions de pipeline (par exemple, à l'aide de dataform run --tags ...).
clusterDetails map Non — Facultatif. Configuration du clustering BigQuery. Consultez Détails du clustering.
partitionDetails map Non — Facultatif. Configuration du partitionnement BigQuery. Pour en savoir plus, consultez Détails sur le partitionnement.

Style du produit de données

Dans un module de produit de données, le fichier table_settings.yaml est structuré sous forme de dictionnaire (map) sous les clés ecc, s4 et common. Les clés du dictionnaire représentent les noms des tables ou des vues analytiques, et les valeurs définissent leurs paramètres de matérialisation et de performances.

Exemple de syntaxe YAML

s4:
  customers:
    materializationType: incremental
    tags: [sap, dataproduct, masterdata]
    clusterDetails:
      columns: [mandt, ktokd]

Référence de paramètre

Paramètre Type Obligatoire Par défaut / Exemple Description
ecc | s4 | common map Non {} Carte des ressources analytiques cibles (tables ou vues) et de leurs configurations.
[table_name].materializationType string Non incremental Comment l'élément analytique est créé dans BigQuery.

Valeurs autorisées :

  • incremental : ne traite que les enregistrements nouveaux ou modifiés depuis la dernière exécution. Recommandé pour les grands ensembles de données transactionnelles afin de réduire les coûts.
  • table : recompile complètement la table à partir de zéro à chaque exécution.
  • view : déploie le composant en tant que vue SQL BigQuery (table virtuelle).
[table_name].tags array[string] Non [sap, dataproduct] Tags de métadonnées associés au composant analytique dans Dataform. Il s'agit de chaînes arbitraires qui n'ont pas besoin d'être préenregistrées. Elles peuvent être utilisées immédiatement pour des exécutions de pipeline sélectives.
[table_name].clusterDetails map Non — Facultatif. Configuration du clustering BigQuery. Consultez Détails du clustering.
[table_name].partitionDetails map Non — Facultatif. Configuration du partitionnement BigQuery. Pour en savoir plus, consultez Détails sur le partitionnement.

Configurations BigQuery avancées

Les deux styles partagent la même structure pour optimiser le stockage et les performances des requêtes BigQuery grâce au clustering et au partitionnement.

Détails du clustering

Le clustering regroupe les données en fonction des valeurs de colonnes spécifiques. BigQuery trie les données de chaque bloc de stockage à l'aide de ces colonnes, ce qui accélère considérablement les requêtes qui filtrent (WHERE) ou joignent (JOIN) les données en fonction de ces colonnes.

clusterDetails:
  columns: [bukrs, gjahr]
Référence de paramètre
Paramètre Type Obligatoire Exemple Description
columns array[string] Oui [bukrs, gjahr] Liste ordonnée de quatre noms de colonnes maximum selon lesquels regrouper la table.

Contrainte : les colonnes doivent être alphanumériques et ne contenir que des traits de soulignement. L'ordre des colonnes dans la liste détermine la hiérarchie de tri.

Détails du partitionnement

Le partitionnement divise une grande table en segments physiques plus petits en fonction des valeurs d'une colonne de date, de code temporel ou d'entiers. Cela empêche BigQuery d'analyser l'intégralité de la table lorsqu'une requête ne demande qu'une plage spécifique de jours, de mois ou d'ID.

partitionDetails:
  column: budat
  partitionType: time
  timeGrain: day
Référence de paramètre
Paramètre Type Obligatoire Exemple Description
column string Oui budat Nom de la colonne utilisée pour partitionner la table. Le nom ne doit comporter que des caractères alphanumériques et des traits de soulignement. Le type de colonne doit correspondre à partitionType.
partitionType string Oui time Stratégie de partitionnement.

Valeurs autorisées :

  • time : partitionne par unité de temps (colonne "Date", "Code temporel" ou "Date et heure").
  • DATE : partitionne explicitement par colonne de date.
  • integer : partitionne par plage d'entiers.
timeGrain string Non day Obligatoire si partitionType est time ou DATE. Définit la précision des partitions temporelles.

Valeurs autorisées : hour, day, month, year (non sensible à la casse).
rangeStart integer Non 1 Obligatoire si partitionType est défini sur integer. Valeur de début de la première partition (incluse).
rangeEnd integer Non 1000 Obligatoire si partitionType est défini sur integer. Valeur de fin de la dernière partition (exclusive).
rangeInterval integer Non 10 Obligatoire si partitionType est défini sur integer. Largeur de chaque intervalle de partition.

Exemples

Les exemples suivants présentent des modèles de configuration pour les modules de base de données et de produit de données. Ils expliquent comment personnaliser les tables cibles, optimiser la mise en page du stockage dans BigQuery et configurer les types de matérialisation.

1. Exemple de paramètres de tableau de données personnalisés

Cet exemple montre comment configurer une couche de base avec des tables transactionnelles partitionnées et mises en cluster (comme bseg et ekbe) à côté des tables de données standards :

# ==============================================================================
# S/4HANA-Specific Tables
# ==============================================================================
s4:
  # ACDOCA is a massive table in S/4HANA; clustering is vital
  - source:
      tableName: acdoca
    target:
      tags: [sap, s4, finance, transactional, hourly]
      clusterDetails:
        columns: [rclnt, rbukrs, gjahr]

# ==============================================================================
# ECC-Specific Tables
# ==============================================================================
ecc:
  - source:
      tableName: faglflexa
    target:
      tags: [sap, ecc, finance, transactional, hourly]

# ==============================================================================
# Common Tables (ECC & S/4HANA)
# ==============================================================================
common:
  # Financial document header (partitioned by posting date)
  - source:
      tableName: bkpf
      isCdc: true
    target:
      tags: [sap, common, finance, hourly]
      clusterDetails:
        columns: [bukrs, gjahr]
      partitionDetails:
        column: budat
        partitionType: time
        timeGrain: day

  # Purchasing document items (partitioned by creation date)
  - source:
      tableName: ekpo
    target:
      tags: [sap, common, logistics, purchasing, hourly]
      clusterDetails:
        columns: [mandt, ebeln]
      partitionDetails:
        column: aedat
        partitionType: time
        timeGrain: month

  # Standard master data table (no partitioning/clustering needed)
  - source:
      tableName: lfa1
    target:
      tags: [sap, common, masterdata, vendor, daily]

2. Exemple de paramètres de tableau de données produit personnalisés

Cet exemple montre comment configurer des types de matérialisation pour les produits de données analytiques en aval. Nous définissons les sales_documents transactionnelles comme incrémentielles pour optimiser les performances de compilation et réduire les coûts, tandis que les tables de données non transactionnelles telles que customers sont compilées en tant que tables standards :

# settings applied for both ECC and S/4HANA pipelines
common:
  # Transactional data product - incremental build
  sales_documents:
    materializationType: incremental
    tags: [sap, dataproduct, sales, transactional]
    clusterDetails:
      columns: [vkorg, vbeln]
    partitionDetails:
      column: audat
      partitionType: time
      timeGrain: day

  # Master data product - full table rebuild
  customers:
    materializationType: table
    tags: [sap, dataproduct, masterdata]
    clusterDetails:
      columns: [mandt, ktokd]

  # Aggregated reporting view - virtual view
  sales_performance_summary:
    materializationType: view
    tags: [sap, dataproduct, sales, reporting]

Guides d'utilisation

Cette section fournit des guides détaillés pour les tâches de configuration courantes et les scénarios de déploiement personnalisés.

Personnaliser le champ d'application d'un tableau dans un module de base de données

Pour ajouter ou supprimer des tables dans un module de base de données existant sans créer de modules ni exécuter d'instances de pipeline distinctes :

  • Copiez les configurations table_settings.default.yaml par défaut dans le répertoire de configuration de votre espace de travail (par exemple, config/cortex/data_foundation/sap/custom_table_settings.yaml).
  • Dans votre nouveau fichier, ajoutez vos tableaux personnalisés ou supprimez les tableaux standards inutilisés sous les clés ecc, s4 ou common, selon vos besoins :
common:
  - source:
      tableName: custom_table_name
    target:
      tags: [custom_tag]
  • Mettez à jour config/config.yaml pour faire référence au chemin d'accès aux paramètres de votre tableau personnalisé sous la propriété tableSettings du module :
data:
  modules:
    foundation:
      - moduleId: erp
        type: cortex.sap
        # Custom table settings file, relative to configuration file directory
        # Recommended path: '{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
        tableSettings: 'cortex/data_foundation/sap/custom_table_settings.yaml'

Configurer plusieurs instances d'un module d'infrastructure de données

Pour déployer deux instances de pipeline distinctes ou plus du même type de module (par exemple, pour prendre en charge plusieurs instances SAP, segmenter des tables, isoler des environnements ou cibler différents ensembles de données cibles) :

Avant de commencer : * Assurez-vous que les tables sources existent dans votre ensemble de données brutes source. * Assurez-vous que les schémas des ensembles de données cibles sont configurés. * Lorsque vous travaillez avec des modules de base de données SAP, vérifiez que la table de métadonnées DD03L contient des colonnes et des informations descriptives pour les tables personnalisées que vous souhaitez ingérer. Pour en savoir plus, consultez Exigences concernant SAP ERP.

Instructions :

  • Dans le fichier config/config.yaml, ajoutez des configurations cibles sous data.targets pour définir des ensembles de données cibles pour chaque instance de pipeline :
data:
  targets:
    - id: data_foundation_core
      projectId: target_project_id
      datasetId: data_foundation_sap_core
    - id: data_foundation_custom
      projectId: target_project_id
      datasetId: data_foundation_sap_custom
  • Définissez plusieurs instances du module dans la liste data.modules.foundation. Attribuez à chaque instance un moduleId unique, ses propres ID d'ensemble de données cibles et, éventuellement, une configuration tableSettings :
data:
  modules:
    foundation:
      # Core SAP ERP foundation module instance
      - moduleId: erp_core
        type: cortex.sap
        dataSourceId: sap_raw
        dataTargetId: data_foundation_core
        # If omitted, defaults to "../src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml"
        # tableSettings: "../src/data_modules/cortex/data_foundation/sap/table_settings.default.yaml"
      # Custom tables pipeline instance
      - moduleId: erp_custom
        type: cortex.sap
        dataSourceId: sap_raw
        dataTargetId: data_foundation_custom
        # Custom table settings file, relative to configuration file directory
        # Recommended path: 'config/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
        tableSettings: "cortex/data_foundation/sap/custom_datafoundation_table_settings.yaml"
  • Créez le fichier config/cortex/data_foundation/sap/custom_datafoundation_table_settings.yaml spécifiant le champ d'application personnalisé. Exemple :
common:
  - source:
      tableName: custom_sap_table_name
    target:
      tags: [sap, s4, hourly]
      clusterDetails:
        columns: [carrid, connid]
      partitionDetails:
        column: fldate
        partitionType: time
        timeGrain: day
  • Appliquez les modifications en exécutant le script de déploiement (uv run cortex-build-and-deploy), puis exécutez les actions Dataform comme décrit dans Étapes post-déploiement.