Migration des DAG externes de la version 4.2 vers la version 5.0

Ce guide décrit les étapes nécessaires pour déplacer les tables de sortie des graphiques acycliques dirigés (DAG) externes vers leurs nouveaux emplacements dans l'architecture Cortex Data Foundation v5.0. (par exemple, Météo et Tendances). Ce guide est spécialement conçu pour les utilisateurs qui ont implémenté des DAG externes dans les versions précédentes de Cortex Framework Data Foundation (4.2 à 5.0) et qui effectuent maintenant la mise à niveau. Si vous n'avez pas utilisé de DAG externes ni déployé SAP, ce guide ne s'applique pas.

Contexte

Les versions antérieures à 4.2 de Cortex Framework Data Foundation utilisaient un indicateur _GEN_EXT pour gérer le déploiement de sources de données externes, certaines sources étant associées à des charges de travail spécifiques (comme la conversion de devises pour SAP). Toutefois, avec la version 5.0, cet indicateur a été supprimé. Un nouveau module est désormais dédié à la gestion des DAG pouvant servir plusieurs charges de travail. Ce guide décrit les étapes à suivre pour ajuster vos pipelines de données existants afin qu'ils fonctionnent avec cette nouvelle structure.

DAG réutilisables entre les charges de travail

La version 5.0 de Cortex Framework Data Foundation introduit K9, un nouveau composant chargé d'ingérer, de traiter et de modéliser des éléments de données réutilisables partagés entre différentes sources de données. Les vues de rapports font désormais référence à l'ensemble de données K9_PROCESSING pour accéder à ces composants réutilisables, ce qui simplifie l'accès aux données et réduit la redondance. Les sources de données externes suivantes sont désormais déployées dans le cadre de K9, dans l'ensemble de données K9_PROCESSING:

  • date_dimension
  • holiday_calendar
  • trends
  • weather

DAG dépendants de SAP

Les DAG dépendants de SAP suivants sont toujours déclenchés par le script generate_external_dags.sh, mais sont désormais exécutés lors de l'étape de création des rapports et écrivent désormais dans l'ensemble de données de reporting SAP au lieu de l'étape CDC (Change Data Capture).

  • currency_conversion
  • inventory_snapshots
  • prod_hierarchy_texts

Guide de migration

Ce guide décrit les étapes à suivre pour mettre à niveau votre Data Foundation Cortex Framework vers la version 5.0.

Déployer Cortex Framework Data Foundation 5.0

Commencez par déployer la dernière version (v5.0) de Cortex Framework Data Foundation dans vos projets, en suivant les consignes suivantes:

  1. Utilisez vos ensembles de données RAW et CDC existants de déploiements de développement ou de préproduction précédents comme ensembles de données RAW et CDC de ce déploiement, car aucune modification n'est apportée pendant le déploiement.
  2. Définissez testData et SAP.deployCDC sur False dans config/config.json.
  3. Créez un projet de reporting SAP distinct de votre environnement v4.2 existant à des fins de test. Cela permet d'évaluer de manière sécurisée le processus de mise à niveau sans affecter vos opérations en cours.
  4. Facultatif. Si des DAG Airflow actifs s'exécutent pour votre précédente version de l'infrastructure de données du framework Cortex, mettez-les en veille avant de procéder à la migration. Pour ce faire, utilisez l'interface utilisateur d'Airflow. Pour obtenir des instructions détaillées, consultez les pages Ouvrir l'interface utilisateur d'Airflow depuis Composer et Mettre en pause le DAG.

En suivant ces étapes, vous pouvez passer en toute sécurité à la version 5.0 de Cortex Framework Data Foundation et valider les nouvelles fonctionnalités.

Migrer des tables existantes

Pour migrer vos tables existantes vers leur nouvel emplacement, utilisez jinja-cli pour mettre en forme le modèle de script de migration fourni afin de terminer la migration.

  1. Installez jinja-cli avec la commande suivante:

    pip install jinja-cli

  2. Identifiez les paramètres suivants à partir de votre déploiement existant de la version 4.2 et de la nouvelle version 5.0:

    Nom Description
    project_id_src Source Google Cloud Project: projet dans lequel se trouve votre ensemble de données CDC SAP existant à partir du déploiement de la version 4.2. L'ensemble de données K9_PROCESSING est également créé dans ce projet.
    project_id_tgt Google Cloud cible où se trouve votre nouvel ensemble de données de reporting SAP déployé à partir de la nouvelle version 5.0. Il peut être différent du projet source.
    dataset_cdc_processed Ensemble de données BigQuery du CDC : ensemble de données BigQuery dans lequel les données traitées par le CDC enregistrent les derniers enregistrements disponibles. Il peut être identique à l'ensemble de données source.
    dataset_reporting_tgt Ensemble de données de reporting BigQuery cible: ensemble de données BigQuery dans lequel les modèles de données prédéfinis de Data Foundation pour SAP sont déployés.
    k9_datasets_processing Ensemble de données BigQuery K9 : ensemble de données BigQuery dans lequel K9 (sources de données enrichies) est déployé.

  3. Créez un fichier JSON avec les données d'entrée requises. Assurez-vous de supprimer de la section migrate_list tous les DAG que vous ne souhaitez pas migrer:

    {
  "project_id_src": "your-source-project",
  "project_id_tgt": "your-target-project",
  "dataset_cdc_processed": "your-cdc-processed-dataset",
  "dataset_reporting_tgt": "your-reporting-target-dataset-OR-SAP_REPORTING",
  "k9_datasets_processing": "your-k9-processing-dataset-OR-K9_REPORTING",
  "migrate_list":
    [
        "holiday_calendar",
        "trends",
        "weather",
        "currency_conversion",
        "inventory_snapshots",
        "prod_hierarchy_texts"
    ]
}
EOF

    Par exemple, si vous souhaitez supprimer weather et trends, le script se présente comme suit:

    {
  "project_id_src": "kittycorn-demo",
  "project_id_tgt": "kittycorn-demo",
  "dataset_cdc_processed": "CDC_PROCESSED",
  "dataset_reporting_tgt": "SAP_REPORTING",
  "k9_datasets_processing": "K9_PROCESSING",
  "migrate_list":
    [
        "holiday_calendar",
        "currency_conversion",
        "inventory_snapshots",
        "prod_hierarchy_texts"
    ]
    }

  4. Créez un dossier de sortie à l'aide de la commande suivante:

      mkdir output

  5. Générez le script de migration analysé à l'aide de la commande suivante (cette commande suppose que vous vous trouvez à la racine du dépôt):

      jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql

  6. Examinez le fichier SQL de sortie et exécutez-le dans BigQuery pour migrer vos tables vers le nouvel emplacement.

Mettre à jour et réactiver les DAG Airflow

Sauvegardez les fichiers DAG actuels dans votre bucket Airflow. Remplacez-les ensuite par les fichiers nouvellement générés à partir de votre déploiement de la version 5.0 de Cortex Framework Data Foundation. Pour obtenir des instructions détaillées, consultez la documentation suivante:

Validation et nettoyage

La migration est maintenant terminée. Vous pouvez désormais vérifier que toutes les vues de rapports du nouveau déploiement de rapports v5.0 fonctionnent correctement. Si tout fonctionne correctement, répétez le processus, cette fois en ciblant le déploiement de la version 5.0 dans votre ensemble de rapports de production. Ensuite, n'hésitez pas à supprimer toutes les tables à l'aide du script suivant:

    jinja -d data.json -o output/delete_old_dag_tables.sql docs/external_dag_migration/scripts/delete_old_dag_tables.sql