Cette page a été traduite par l'API Cloud Translation.

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

Ouvrez le fichier config.json depuis Cloud Shell.

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

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:

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

sql_file: nom du fichier SQL qui crée un objet donné.
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).
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: