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

   Paramètre	Signification	Valeur par défaut	Description
   testData	Déployer des données de test	true	Projet dans lequel se trouve l'ensemble de données source et dans lequel la compilation s'exécute. 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 aucun tableau.
   deploySAP	Déployer SAP	true	Exécutez le déploiement pour la charge de travail SAP (ECC ou S/4HANA).
   deploySFDC	Déployer Salesforce	true	Exécutez le déploiement pour la charge de travail Salesforce.
   deployMarketing	Deploy Marketing	true	Déployez les sources marketing (Google Ads, CM360 et TikTok).
   deployOracleEBS	Déployer Oracle EBS	true	Exécutez le déploiement de la charge de travail Oracle EBS.
   deployDataMesh	Déployer un maillage de données	true	Exécutez le déploiement pour le maillage de données. Pour en savoir plus, consultez le guide de l'utilisateur Data Mesh.
   enableTaskDependencies	DAG dépendant des tâches	false	Activez les DAG dépendants des tâches afin que les tables SQL compatibles soient exécutées en fonction de l'ordre de dépendance, dans les DAG individuels. Pour en savoir plus, consultez DAG dépendant des tâches.
   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 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.
   projectIdSource	ID du projet source	-	Projet dans lequel se trouve l'ensemble de données source et dans lequel la compilation s'exécute.
   projectIdTarget	ID du projet cible	-	Projet cible pour les ensembles de données destinés aux utilisateurs.
   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 réel.
   location	Emplacement ou région	"US"	Emplacement de l'ensemble de données BigQuery et des buckets Cloud Storage. Consultez les restrictions listées dans 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 harnais de test.
   k9.datasets.processing	Ensembles de données K9 – Traitement	"K9_PROCESSING"	Exécutez des modèles de charge de travail croisée (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.
   k9.datasets.reporting	Ensembles de données K9 : création de rapports	"K9_REPORTING"	Exécutez des modèles et des sources de données externes (par exemple, la météo) inter-charges de travail, comme défini dans le fichier de configuration K9. Commenté par défaut.
   DataMesh.deployDescriptions	Data Mesh : descriptions des composants	true	Déployez les descriptions de schéma des éléments BigQuery.
   DataMesh.deployLakes	Data Mesh : lacs et zones de données	false	Le déploiement de lacs et de zones Dataplex Universal Catalog qui organisent les tables par couche de traitement nécessite une configuration avant l'activation.
   DataMesh.deployCatalog	Data Mesh : tags et modèles de catalogue	false	Le déploiement de tags Data Catalog permettant des métadonnées personnalisées sur les ressources ou les champs BigQuery nécessite une configuration avant l'activation.
   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 l'activation.

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 :

• Désactivation de la télémétrie :
• Configuration des ensembles de données externes pour K9.
• Recherchez les balises CORTEX-CUSTOMER.

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 :

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

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

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.