Étape 5: Configurer le déploiement

Cette page décrit la cinquième étape du déploiement de Cortex Framework Data Foundation, le cœur de Cortex Framework. Au cours de cette étape, vous allez modifier le fichier de configuration du dépôt Cortex Framework Data Foundation pour qu'il corresponde à vos exigences.

Fichier de configuration

Le comportement du déploiement est contrôlé par le fichier de configuration config.json dans la fondation de données Cortex Framework. Ce fichier contient la configuration globale et la configuration spécifique à chaque charge de travail. Modifiez le fichier config.json selon vos besoins en procédant comme suit:

  1. Ouvrez le fichier config.json depuis Cloud Shell.

  2. Modifiez le fichier config.json en fonction des paramètres suivants:

    Paramètre Signification Valeur par défaut Description
    testData Déployez les données de test. true Projet dans lequel se trouve l'ensemble de données source et où s'exécute le build. Remarque: Le déploiement des données de test ne s'exécute que si l'ensemble de données brut est vide et ne contient aucune table.
    deploySAP Déployer SAP true Exécutez le déploiement pour la charge de travail SAP (ECC ou S/4 HANA).
    deploySFDC Déployer Salesforce true Exécutez le déploiement pour la charge de travail Salesforce.
    deployMarketing Déployer Marketing true Exécutez le déploiement pour les sources marketing (Google Ads, CM360 et TikTok).
    deployOracleEBS Déployer Oracle EBS true Exécutez le déploiement pour la charge de travail Oracle EBS.
    deployDataMesh Déployer un maillage de données true Exécutez le déploiement pour Data Mesh. Pour en savoir plus, consultez le guide de l'utilisateur de Data Mesh.
    turboMode Déployez en mode Turbo. true Exécutez toutes les compilations de vues en tant qu'étape du même processus Cloud Build, en parallèle pour un déploiement plus rapide. Si la valeur est false, chaque vue de rapport est générée dans sa propre étape de compilation séquentielle. Nous vous recommandons de ne le définir sur true que lorsque vous utilisez des données de test ou après avoir résolu les incohérences entre les colonnes de reporting et les données sources.
    projectIdSource ID du projet source - Projet dans lequel se trouve l'ensemble de données source et où s'exécute le build.
    projectIdTarget ID du projet cible - Projet cible pour les ensembles de données destinés aux utilisateurs (ensembles de données de reporting et de ML).
    targetBucket Bucket cible pour stocker les scripts DAG générés - Bucket créé précédemment dans lequel les DAG (et les fichiers temporaires Dataflow) sont générés. Évitez d'utiliser le bucket Airflow.
    location Emplacement ou région "US" Emplacement de l'ensemble de données BigQuery et des buckets Cloud Storage.

    Consultez les restrictions listées sous Emplacements des ensembles de données BigQuery.

    testDataProject Source de l'atelier de test kittycorn-public Source des données de test pour les déploiements de démonstration. S'applique lorsque testData est true.

    Ne modifiez pas cette valeur, sauf si vous disposez de votre propre banc d'essai.

    k9.datasets.processing Ensembles de données K9 : traitement "K9_PROCESSING" Exécutez des modèles multi-charges de travail (par exemple, la dimension de date) tels que définis dans le fichier de configuration K9. Ces modèles sont généralement requis par les charges de travail en aval.
    k9.datasets.reporting Ensembles de données K9 : création de rapports "K9_REPORTING" Exécutez des modèles multi-charges de travail et des sources de données externes (par exemple, la météo) comme défini dans le fichier de configuration K9. Commenté par défaut.
    DataMesh.deployDescriptions Data Mesh : descriptions des composants true Déployez des descriptions de schéma d'éléments BigQuery.
    DataMesh.deployLakes Data Mesh : lacs et zones false Le déploiement de lacs et de zones Dataplex qui organisent les tables par couche de traitement nécessite une configuration avant d'être activé.
    DataMesh.deployCatalog Data Mesh : tags et modèles de catalogue false Le déploiement de balises Data Catalog qui autorisent les métadonnées personnalisées sur les composants ou les champs BigQuery nécessite une configuration avant d'être activé.
    DataMesh.deployACLs Data Mesh : contrôle des accès false Le déploiement du contrôle des accès au niveau des éléments, des lignes ou des colonnes sur les éléments BigQuery nécessite une configuration avant d'être activé.

  3. Configurez la ou les charges de travail requises selon vos besoins. Vous n'avez pas besoin de les configurer si le paramètre de déploiement (par exemple, deploySAP ou deployMarketing) de la charge de travail est défini sur False. Pour en savoir plus, consultez la section Étape 3: Déterminer le mécanisme d'intégration.

Pour personnaliser davantage votre déploiement, consultez les étapes facultatives suivantes:

Optimisation des performances pour les vues de rapports

Les artefacts de création de rapports peuvent être créés en tant que vues ou en tant que tables actualisées régulièrement via des DAG. D'une part, les vues calculent les données à chaque exécution d'une requête, ce qui permet de maintenir les résultats à jour. En revanche, la table exécute les calculs une seule fois, et les résultats peuvent être interrogés plusieurs fois sans entraîner de coûts de calcul plus élevés et en obtenant un temps d'exécution plus rapide. Chaque client crée sa propre configuration en fonction de ses besoins.

Les résultats matérialisés sont mis à jour dans un tableau. Vous pouvez affiner davantage ces tables en ajoutant des fonctionnalités de partitionnement et de clustering.

Les fichiers de configuration de chaque charge de travail se trouvent dans les chemins d'accès suivants du dépôt Cortex Framework Data Foundation:

Source de données Fichiers de paramètres
Opérationnel - SAP src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml
Opérationnel : Salesforce Sales Cloud src/SFDC/config/reporting_settings.yaml
Opérationnel : 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 (avec DV360) src/marketing/src/DV360/config/reporting_settings.yaml
Marketing – Google Analytics 4 src/marketing/src/GA4/config/reporting_settings.yaml
Marketing : insights cross-média et liés aux produits src/marketing/src/CrossMedia/config/reporting_settings.yaml

Personnaliser le fichier de paramètres de création de rapports

Les fichiers reporting_settings déterminent la manière dont les objets BigQuery (tables ou vues) sont créés pour les ensembles de données de reporting. Personnalisez votre fichier avec les descriptions des paramètres suivants. Supposons que ce fichier contienne deux sections:

  1. bq_independent_objects: tous les objets BigQuery pouvant être créés indépendamment, sans aucune autre dépendance. Lorsque Turbo mode est activé, ces objets BigQuery sont créés en parallèle au moment du déploiement, ce qui accélère le processus de déploiement.
  2. bq_dependent_objects: tous les objets BigQuery qui doivent être créés dans un ordre spécifique en raison de dépendances envers d'autres objets BigQuery. Turbo mode ne s'applique pas à cette section.

Le déployeur crée d'abord tous les objets BigQuery listés dans bq_independent_objects, puis tous les objets listés dans bq_dependent_objects. Définissez les propriétés suivantes pour chaque objet:

  1. sql_file: nom du fichier SQL qui crée un objet donné.
  2. type: type d'objet BigQuery. Valeurs possibles :
    • view : si vous souhaitez que l'objet soit une vue BigQuery.
    • table: si vous souhaitez que l'objet soit une table BigQuery.
    • script: permet de créer d'autres types d'objets (par exemple, des fonctions BigQuery et des processus stockés).
  3. Si type est défini sur table, les propriétés facultatives suivantes peuvent être définies :
    • load_frequency: fréquence à laquelle un DAG Composer est exécuté pour actualiser ce tableau. Pour en savoir plus sur les valeurs possibles, consultez la documentation Airflow.
    • partition_details: méthode de partitionnement de la table. Cette valeur est facultative. Pour en savoir plus, consultez la section Partitionnement de table.
    • cluster_details: méthode de regroupement de la table. Cette valeur est facultative. Pour en savoir plus, consultez la section Paramètres du cluster.

Partitionnement de table

Certains fichiers de paramètres vous permettent de configurer des tables materialisées avec des options de clustering et de partitionnement personnalisées. Cela peut considérablement améliorer les performances des requêtes pour les grands ensembles de données. Cette option ne s'applique qu'aux fichiers SAP cdc_settings.yaml et reporting_settings.yaml.

Vous pouvez activer le partitionnement de table en spécifiant les éléments suivantspartition_details:

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

Utilisez les paramètres suivants pour contrôler les détails du partitionnement d'une table donnée:

Propriété Description Valeur
column Colonne par laquelle la table CDC est partitionnée. Nom de la colonne.
partition_type Type de partition. "time" pour le partitionnement temporel. Pour en savoir plus, consultez la section Tables partitionnées par code temporel. "integer_range" pour le partitionnement basé sur des entiers. Pour en savoir plus, consultez la documentation sur les plages d'entiers.
time_grain Partie de temps à partitionner avec. Obligatoire avec partition_type = "time". "hour", "day", "month" ou "year".
integer_range_bucket Plage de buckets obligatoire lorsque partition_type = "integer_range" "start" = valeur de début, "end" = valeur de fin et "interval" = intervalle de la plage.

Pour en savoir plus sur les options et les limites associées, consultez Partitionnement de table BigQuery.

Paramètres du cluster

Vous pouvez activer le clustering de tables en spécifiant cluster_details:

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

Utilisez les paramètres suivants pour contrôler les détails des clusters pour une table donnée:

Propriété Description Valeur
columns Colonnes par lesquelles une table est regroupée. Liste des noms de colonnes. Par exemple, "mjahr" et "matnr".

Pour en savoir plus sur les options et les limites associées, consultez la documentation sur les clusters de tables.

Étapes suivantes

Une fois cette étape terminée, passez à l'étape de déploiement suivante:

  1. Définir les charges de travail
  2. Clonez le dépôt.
  3. Déterminer le mécanisme d'intégration
  4. Configurez les composants.
  5. Configurer le déploiement (cette page).
  6. Exécutez le déploiement.