Étape 5 : Configurez 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 dans le dépôt Cortex Framework Data Foundation pour l'adapter à vos besoins.

Fichier de configuration

Le comportement du déploiement est contrôlé par le fichier de configuration config.json dans Cortex Framework Data Foundation. Ce fichier contient la configuration globale et la configuration spécifique à chaque charge de travail. Modifiez le fichier config.json selon vos besoins en suivant les étapes ci-dessous :

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

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

    <td"> Parameter <td">Meaning <td">Default Value <td">Description </td"></td"></td"></td"><td">testData <td">Deploy Test Data <td">true <td">Project where the source dataset is and the build runs. Remarque : Le déploiement des données de test ne s'exécute que si l'ensemble de données brutes est vide et ne comporte aucune table. </td"></td"></td"></td"><td">deploySAP <td">Déployer SAP <td">true <td">Exécutez le déploiement de la charge de travail SAP (ECC ou S/4 HANA). </td"></td"></td"></td"><td">deploySFDC <td">Déployer Salesforce <td">true <td">Exécutez le déploiement de la charge de travail Salesforce. </td"></td"></td"></td"><td">deployMarketing <td">Déployer le marketing <td">true <td">Exécuter le déploiement pour les sources marketing (Google Ads, CM360 et TikTok). </td"></td"></td"></td"><td">deployOracleEBS <td">Déployer Oracle EBS <td">true <td">Exécuter le déploiement pour la charge de travail Oracle EBS. </td"></td"></td"></td"><td">enableTaskDependencies <td">DAG dépendant des tâches <td">false <td">Activez les DAG dépendant des tâches afin que les tables SQL compatibles soient exécutées en fonction de l'ordre de dépendance, dans des DAG uniques. Pour en savoir plus, consultez DAG avec dépendances de tâches. </td"></td"></td"></td"><td">turboMode <td">Déployez en mode Turbo. <td">true <td">Exécutez toutes les compilations de vues en tant qu'étape du même processus de compilation Cloud Build, en parallèle pour un déploiement plus rapide. Si la valeur est définie sur false, chaque vue de rapport est générée dans sa propre étape de compilation séquentielle. Nous vous recommandons de ne définir cette valeur sur true que lorsque vous utilisez des données de test ou après avoir résolu toute incohérence entre les colonnes des rapports et les données sources. </td"></td"></td"></td"><td">projectIdSource <td">ID du projet source <td">- <td">Projet dans lequel se trouve l'ensemble de données source et où la compilation s'exécute. </td"></td"></td"></td"><td">projectIdTarget <td">ID du projet cible <td">- <td">Projet cible pour les ensembles de données destinés aux utilisateurs. </td"></td"></td"></td"><td">targetBucket <td">Bucket cible pour stocker les scripts DAG générés <td">- <td">Bucket créé précédemment où les DAG (et les fichiers temporaires Dataflow) sont générés. Évitez d'utiliser le bucket Airflow réel. </td"></td"></td"></td"><td">location <td">Emplacement ou région <td">"US" <td">Emplacement des buckets de jeu de données BigQuery et Cloud Storage.

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

    </td"></td"></td"></td"><td">testDataProject <td">Source pour le harnais de test <td">kittycorn-public <td">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 harnais de test.

    </td"></td"></td"></td"><td">k9.datasets.processing <td">Traitement des ensembles de données K9 <td">"K9_PROCESSING" <td">Exécutez les modèles intercharges de travail (par exemple, la dimension de date) tels qu'ils sont définis dans le fichier de configuration K9. Ces modèles sont normalement requis par les charges de travail en aval. </td"></td"></td"></td"><td">k9.datasets.reporting <td">Ensembles de données K9 – Reporting <td">"K9_REPORTING" <td">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. </td"></td"></td"></td">

  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 Étape 3 : Déterminer le mécanisme d'intégration.

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

Optimisation des performances pour les vues de rapports

Les artefacts de reporting peuvent être créés sous forme de vues ou de tables actualisées régulièrement à l'aide de DAG. D'une part, les vues calculent les données à chaque exécution d'une requête, ce qui permet de toujours obtenir des résultats récents. 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 ces tables en ajoutant le partitionnement et le 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 :

<td">Source de données <td">Fichiers de paramètres </td"></td"><td">Opérationnel – SAP <td">src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml </td"></td"><td">Opérationnel – Salesforce Sales Cloud <td">src/SFDC/config/reporting_settings.yaml </td"></td"><td">Opérationnel – 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 (avec 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 – Insights cross-média et produit connecté <td">src/marketing/src/CrossMedia/config/reporting_settings.yaml </td"></td">

Personnaliser le fichier de paramètres de reporting

Les fichiers reporting_settings déterminent la façon dont les objets BigQuery (tables ou vues) sont créés pour les ensembles de données de reporting. Personnalisez votre fichier à l'aide des descriptions de paramètres suivantes. Considérez que ce fichier contient deux sections :

  1. bq_independent_objects : tous les objets BigQuery qui peuvent être créés indépendamment, sans aucune autre dépendance. Lorsque Turbo mode est activé, ces objets BigQuery sont créés en parallèle lors 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 vis-à-vis 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 et des procédures stockées BigQuery).
  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 : façon dont la table doit être partitionnée. Cette valeur est facultative. Pour en savoir plus, consultez la section Partition de table.
    • cluster_details : façon dont la table doit être regroupée. Cette valeur est facultative. Pour en savoir plus, consultez la section Paramètres du cluster.

Partition de table

Certains fichiers de paramètres vous permettent de configurer des tables matérialisé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 à tous les fichiers 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 :

<td">Propriété <td">Description <td">Valeur </td"></td"></td"><td">column <td">Colonne par laquelle la table CDC est partitionnée. <td">Nom de la colonne. </td"></td"></td"><td">partition_type <td">Type de partition. <td">"time" pour la partition basée sur le temps. Pour en savoir plus, consultez 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. </td"></td"></td"><td">time_grain <td">Partie temporelle à partitionner Obligatoire lorsque partition_type = "time". <td">"hour", "day", "month" ou "year". </td"></td"></td"><td">integer_range_bucket <td">Plage de buckets Obligatoire lorsque partition_type = "integer_range" <td">"start" = valeur de début, "end" = valeur de fin et "interval = intervalle de la plage. </td"></td"></td">

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

Paramètres du cluster

Le clustering de tables peut être activé 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 du cluster pour un tableau donné :

<td">Propriété <td">Description <td">Valeur </td"></td"></td"><td">columns <td">Colonnes selon lesquelles une table est mise en cluster. <td">Liste des noms de colonnes. Par exemple, "mjahr" et "matnr". </td"></td"></td">

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. Établissez des charges de travail.
  2. Clonez le dépôt.
  3. Déterminez le mécanisme d'intégration.
  4. Configurer les composants
  5. Configurer le déploiement (cette page).
  6. Exécutez le déploiement.