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

Ce guide décrit les étapes nécessaires pour déplacer les tables de sortie des graphes orientés acycliques (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écifiquement conçu pour les utilisateurs qui ont implémenté des DAG externes dans les versions précédentes de la Data Foundation du Cortex Framework (de 4.2 à 5.0) et qui effectuent maintenant une mise à niveau. Si vous n'avez pas utilisé de DAG externes ni déployé SAP, ce guide ne s'applique pas.

Contexte

Les versions de Cortex Framework Data Foundation antérieures à la version 4.2 utilisaient un indicateur _GEN_EXT pour gérer le déploiement de sources de données externes, certaines sources étant liées à des charges de travail spécifiques (comme la conversion de devises pour SAP). Toutefois, cet indicateur a été supprimé dans la version 5.0. Un nouveau module dédié à la gestion des DAG pouvant traiter plusieurs charges de travail est désormais disponible. 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 pour plusieurs charges de travail

La version 5.0 de la couche de données Cortex Framework introduit K9, un nouveau composant chargé d'ingérer, de traiter et de modéliser les éléments de données réutilisables partagés entre différentes sources de données. Les vues de rapport 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 l'ensemble de données K9_PROCESSING de K9 :

  • date_dimension
  • holiday_calendar
  • trends
  • weather

DAG dépendant de SAP

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

  • currency_conversion
  • inventory_snapshots
  • prod_hierarchy_texts

Guide de migration

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

Déployer Cortex Framework Data Foundation 5.0

Tout d'abord, déployez 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 provenant 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 ne leur est apportée lors du déploiement.
  2. Définissez testData et SAP.deployCDC sur False dans config/config.json.
  3. Créez un projet de création de rapports SAP distinct de votre environnement v4.2 existant à des fins de test. Cela permet d'évaluer le processus de mise à niveau en toute sécurité, sans impacter vos opérations actuelles.
  4. Facultatif. Si des DAG Airflow sont en cours d'exécution pour votre version précédente de la Data Foundation du Cortex Framework, 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 la documentation Ouvrir l'interface utilisateur Airflow depuis Composer et Mettre en veille le DAG.

En suivant ces étapes, vous pouvez passer en toute sécurité à la version 5.0 de la couche de données 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 à l'aide de 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 :

    <td"> Nom <td"> Description </td"></td"><td"> project_id_src <td"> Source Google Cloud Projet : projet dans lequel se trouve votre ensemble de données SAP CDC existant issu du déploiement de la version 4.2. L'ensemble de données K9_PROCESSING est également créé dans ce projet. </td"></td"><td"> project_id_tgt <td"> Cible Google Cloud où se trouve l'ensemble de données SAP Reporting que vous venez de déployer à partir de la nouvelle version 5.0. Il peut être différent du projet source. </td"></td"><td"> dataset_cdc_processed <td"> Ensemble de données CDC BigQuery : ensemble de données BigQuery dans lequel les données CDC traitées sont stockées, avec les derniers enregistrements disponibles. Il peut être identique à l'ensemble de données source. </td"></td"><td"> dataset_reporting_tgt <td"> Ensemble de données BigQuery cible pour les rapports : ensemble de données BigQuery dans lequel les modèles de données prédéfinis Data Foundation pour SAP sont déployés. </td"></td"><td"> k9_datasets_processing <td"> Ensemble de données K9 BigQuery : ensemble de données BigQuery dans lequel le K9 (sources de données augmentées) est déployé. </td"></td">

  3. Créez un fichier JSON contenant 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ésentera 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. Ensuite, remplacez-les par les fichiers nouvellement générés à partir de votre déploiement Cortex Framework Data Foundation version 5.0. Pour obtenir des instructions détaillées, consultez la documentation suivante :

Validation et nettoyage

La migration est maintenant terminée. Vous pouvez maintenant vérifier que toutes les vues de rapport du nouveau déploiement de rapports v5.0 fonctionnent correctement. Si tout fonctionne correctement, recommencez le processus, cette fois en ciblant le déploiement de la version 5.0 sur 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