Traiter en masse des tables Lookup volumineuses - 8.0

Exemples de Jobs d'intégration de données

Version
8.0
Language
Français
Product
Talend Big Data
Talend Big Data Platform
Talend Data Fabric
Talend Data Integration
Talend Data Management Platform
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Open Studio for Big Data
Talend Open Studio for Data Integration
Talend Open Studio for ESB
Talend Real-Time Big Data Platform
Module
Studio Talend
Content
Création et développement > Création de Jobs
Last publication date
2024-02-06

Cet article présente comment utiliser le traitement par lots pour gérer des tables Lookup volumineuses.

Une manière de traiter ce problème est d'utiliser un processus nommé Batching (traitement par lots). Le traitement par lots permet de traiter un lot d'enregistrements en une exécution, de manière itérative afin de créer plus de lots et de traiter tous les enregistrements.

Chaque itération va traiter et extraire un nombre fixe d'enregistrements depuis les tables source et Lookup, effectuer une jointure et charger la table cible.

Ainsi, vous pouvez contrôler le nombre d'enregistrements (variable batchrec) en mémoire dans le processus.

Pour ce faire, vous pouvez utiliser les variables de contexte (Context variables), le tLoop, le tContextLoad, le tMap et le tJava.

Procédure

  1. Utilisez les variables de contexte pour rendre le Job dynamique. Différentes valeurs peuvent être utilisée pour les variables de contexte dans différents environnements, comme DEV et PROD. Cela rend le Job flexible et évite de modifier le code dans chaque environnement.
    Capture d'écran des variables de contexte.
    Variables contextuelles utilisées dans le Job
    Variable Description
    Recnum Cette variable est utilisée comme point de départ de l'exécution. Sa valeur par défaut dans ce Job est "1" .
    Batchrec Cette variable est utilisée comme le nombre d'enregistrements à traiter dans le Job à chaque itération. En rendant cette variable dynamique, vous pouvez contrôler le nombre d'enregistrements à traiter dans chaque lot.
    MAX_CUSTID Cette variable est utilisée pour arrêter le processus après la dernière itération, c'est-à-dire après la lecture du dernier enregistrement. Cette variable est chargée à l'aide du composant tContextLoad.

    La requête SQL est la suivante : "SELECT 'MAX_CUSTID' as Key, max(id) as Value FROM `customer`.`cust` "

    Capture d'écran du Job dans l'espace de modélisation graphique.
  2. Utilisez les variables sssql et lsql pour construire l'isntruction SQL à exécuter sur la base de données par les composants tMysqlInput et tMSSqlInput. Les colonnes choisies dans ssqlCOLUMNS et lsqlCOLUMNS doivent être les mêmes que celles du schéma défini dans les composants d'entrée.

    Par exemple, la requête dans le composant client (tMysqlInput) est définie comme suit, rendant la requête dynamique.

    " SELECT " + context.ssqlCOLUMNS + context.ssqlFROM + context.ssqlWHERE + ">=" + context.Recnum + context.ssqlAND + "<" + (context.Recnum + context.Batchrec) ;
    Capture d'écran des paramètres simples du composant.

    Une requête SQL similaire est définie sur le composant CUST_LOCATIONS (tMSSqlInput).

    Capture d'écran des paramètres simples du composant.
  3. Configurez le composant tLoop comme suit.

    Les variables de contexte définies ci-dessus sont utilisées dans le composant tLoop, comme présenté ci-dessous. Pour chaque itération jusqu'à l'ID client maximal, le nombre d'enregistrements par lot défini dans la variable Batchrec est utilisé pour récupérer les enregistrements depuis les tables source et Lookup.

    Capture d'écran des paramètres simples du composant.
  4. Configurez le composant tJava comme suit.

    Ce composant est utilisé pour incrémenter l'ID client (cust_id) de départ du nombre d'enregistrements en cours de traitement dans chaque lot.

    Capture d'écran des paramètres simples du composant.
  5. Configurez le composant tMap comme suit.

    Ce composant est utilisé pour la condition de jointure Le Lookup Model est configuré à Load Once, car votre table Lookup est statique. Match Model est configuré à Unique match car vous n'attendez pas que la table Lookup ait des doublons. Join Model est configuré à Left Outer Join car vous souhaitez que les données source soient chargées dans la cible même si l'emplacement est introuvable.

    Capture d'écran des mappings.
  6. Reliez les sous-Jobs à l'aide de liens de déclenchement OnSubJobOk et OnComponentOk.

    Ne reliez pas le composant tLoop directement au tMysqlInput. Ne reliez pas le tJava (Update record counter) directement au tMysqlOutput_1. Les composants tLoop et tJava doivent faire partie de leur propre sous-Jobs.

    Le Job complet doit ressembler à ceci.

    Capture d'écran du Job dans l'espace de modélisation graphique.
  7. Exécuter le Job

Résultats

Voici le log d'exécution d'exemple. La table source (cust) contient 100 millions de lignes et la table Lookup (CUST_LOCATIONS) contient 70 millions de lignes. Batchrec="10000000".

L'exécution du Job a pris 66 minutes et a utilisé une partie de la mémoire disponible sur le serveur d'exécution. Il n'a pas été affecté par des exceptions relatives à un dépassement de mémoire.

Capture d'écran de la console après l'exécution réussie du Job.