Arbre de décision et cas d'utilisation des approches Gestion par Talend et Gestion par le·a client·e

Les deux approches principales (Gestion par Talend/Gestion par le·a client·e) parmi lesquelles choisir la manière de déployer et d'exécuter les artefacts Talend construits avec la plateforme sont décrites ici : Gestion par Talend/Serverless versus Gestion par le·a client·e.

Vous pouvez trouver un arbre de décision et des sections de cas d'usage ci-dessous, faisant référence à vos prérequis spécifiques.

Le diagramme ci-dessous décrit les points de décision principaux en faveur de l'approche Gestion par Talend ou de l'approche Gestion par le·a client·e, en fonction de celle qui correspond le mieux à vos besoins. Vous pouvez adopter ces principes dans de nombreuses autres variations d'environnements.

Processus ETL par lots et orientés événements

Le traitement par lots est utile lorsque vous devez ingérer régulièrement de gros volumes de données dans un temps limité, mais la configuration et la mise à l'échelle d'un cluster de machines virtuelles pour traiter des Jobs complexes par lots peuvent être difficiles à gérer. Le traitement pushdown est de plus en plus répandu – ELT pour les bases de données ou exécution d'un Job sur un cluster Big Data.

Avec le concept orienté événements, les données sont traitées lorsqu'un événement survient, comme l'arrivée d'un fichier, une mise à jour de données... Ce processus est souvent utilisé dans des scénarios relatifs à des sites d'e-commerce pour traiter les commandes des client·es avec les applications en aval ou encore les institutions financières traitant les fichiers de transations des partenaires. Par exemple : une société financière héberge un data lake sur AWS S3 qui permet à leurs entreprises partenaires de charger des fichiers de transaction à cet emplacement. Les fichiers partenaires seront traités par les processus ETL d'intégration de données en aval pour mettre à jour le système ERP de la société financière. Ce processus peut être exécuté de manière immédiate via un framework orienté événements, ou être exécuté via un modèle par lots ordonnancé – cela dépend de l'entreprise et des prérequis de conformité.

Pour plus d'informations, consultez les sections suivantes :

• Construire un Job en tant qu'image Docker :

ETL Pushdown et Jobs Big Data

Pour les clients tirant parti des plateformes Big Data (comme AWS EMR) ou des data warehouses Cloud (comme Snowflake), Talend fournit des fonctionnalités d'exécution pushdown avec des codes Spark natifs ou du code ELT. Au lieu d'extraire/de transformer les données avant leur saisie (comme dans le cas de Jobs ETL Talend s'exécutant sur un moteur distant), ce mécanisme laisse les plateformes cibles effectuer le lourd traitement de données. Les fichiers exécutables générés par Talend (Jobs ELT ou Big Data) seront d'abord copiés dans les plateformes cibles (data warehouse ou plateforme Big Data) puis traités à cet emplacement. Vous pouvez donc choisir d'exécuter des processus pushdown avec l'approche Gestion par Talend ou Gestion par le·a client·e. Cependant, comme le calcul n'est pas effectué par un Job Talend, un service de données ou une Route dans un scénario pushdown, la complexité supplémentaire de l'approche Gestion par le·a client·e doit être évitée, sauf si elle est déjà utilisée à d'autres fins.

Services de données REST/SOAP et Routes de médiation

Pour l'intégration en temps réel, Talend supporte le développement de Jobs de services de données (RESTful et SOAP) et de Routes de médiation. Ces éléments peuvent être déployés dans la plateforme gérée par Talend, en option native. De plus, Talend fournit également la possibilité de générer des Jobs de services de données RESTful ou des Routes de médiation en tant que microservices autonomes (Spring Boot), pour pouvoir les déployer sur une plateforme serverless/de conteneur gérée par le·a client·e sans dépendance aux applications d'infrastructure, comme Talend Runtime. Talend ne supporte pas directement les Services de données SOAP en tant que microservices, mais les services SOAP construits à partir de Routes de médiation sont autorisés. SOAP est un ensemble plus rigide de modèles de messaging que RESTful. Les règles, dans SOAP sont importantes car il n'est pas possible d'effectuer la moindre standardisation sans ces règles. Les services de données SOAP ont besoin d'impliquer plus de services relatifs à l'infrastructure, comme la sécurité, les autorisations, l'authentification, le registre des services (Service Registry), entre autres. Ces services sont généralement gérés par des passerelles d'API externes (ce qui sort de la portée de ce document).

Avantages de l'approche Gestion par Talend :

1. Efficacité opérationelle : Utilisation de services et de fonctionnalités natif·ves géré·es par Talend, notamment le monitoring, l'ordonnancement ou encore le déploiement.
2. Rentabilisation rapide : Environnement (paire runtime ou microservice + moteur distant) et outil de développement rapides à configurer (Studio Talend).
3. Coûts de maintenance réduits : Aucun coût d'installation ou de support des services natifs de Talend Cloud (Talend Management Console, par exemple).

Avantages de l'approche Gestion par le·a client·e :

• Évolutivité horizontale native pour les demandes de plus haut niveau : l'orchestration de conteneurs et la plateforme serverless mettent à l'échelle les microservices lors de plus hauts niveaux de demandes d'API. Par exemple, les entreprises d'e-commerce ont toujours besoin d'un environnement stable et évolutif pour leurs applications de services Web – particulièrement le besoin d'une disponibilité de 100 % lors d'événements commerciaux, comme le Black Friday.
• Applications Talend sans serveur : Aucun besoin d'hébergement d'applications relatives aux serveurs Talend pour les services ou les Routes de médiation en temps réel.

Les deux approches nécessitent d'avoir suffisamment de jetons de moteur. Votre équipe de compte peut vous apporter son aide concernant les questions relatives aux licences.