AWS Glue est le service d’ETL entièrement managé par AWS, qui a été annoncé au re:Invent 2016.
Il s’intègre avec les autres services managés d’AWS, tels que Amazon Aurora, Amazon RDS pour MySQL, Amazon RDS pour Oracle, Amazon RDS pour PostreSQL, Amazon RDS pour SQL Server, Amazon Redshift et Amazon S3, Lambda, etc.
Il s’interface également avec les bases de données MySQL, Oracle, Microsoft SQL Server et PostgreSQL dans votre Virtual Private Cloud (Amazon VPC) s’exécutant sur Amazon EC2.
Vous pouvez aussi personnaliser vos connecteurs pour interagir avec des technologies non gérées nativement par Glue.
Glue peut également se connecter à des sources de données « on-premise », permettant ainsi de migrer les données vers le Cloud.
Les flux de données sont écrits en Python et exécutés via Apache Spark et PySpark.
Comme la plupart des services AWS, Glue est conçu pour générer du code que les développeurs adaptent à leur guise pour tirer pleinement parti du service.
Il est de nature propriétaire, tous les flux conçus dans Glue fonctionnent uniquement sur AWS.
Voici l’analogie que l’on peut faire entre les composants AWS Glue et ceux d’Oracle Data Integrator :

• Catalogue :
  • Description : le catalogue de données AWS Glue est un référentiel central pour stocker les métadonnées structurelles et opérationnelles de toutes vos données. Pour un ensemble particulier de données, vous pouvez stocker la définition de sa table et son emplacement physique, ajouter les attributs pertinents de l’entreprise et suivre les modifications apportées aux données dans le temps.
  • Analogie dans ODI : le catalogue correspond à la partie « modèles de données » (contenant les datastores) du module Designer d’ODI.
• Classifier (Classificateur) :
  • Description : un classificateur permet de décrire/catégoriser une structure de données.
  • Analogie dans ODI : cela correspond aux types de données (d’un datastore).
• Crawler (Robots d’analyse) :
  • Description : un robot d’analyse AWS Glue se connecte à un magasin de données, progresse en passant par une liste hiérarchique de classificateurs afin d’extraire le schéma et d’autres statistiques de vos données, puis alimente le catalogue de données Glue avec ses métadonnées.
  • Analogie dans ODI : ce principe correspond en quelque sorte au processus de Reverse Engineering d’ODI, mais avec des fonctionnalités en plus (le versioning notamment).
• Code généré :
  • Description : Glue génère du code Scala ou Python.
  • Analogie dans ODI : ODI génère du code SQL ou Jython (selon les KM (modules de connaissances) et les besoins/technologies sous-jacent(e)s).
• Logs d’exécution :
  • Description : Les logs sont stockés dans CloudWatch, et peuvent ensuite faire l’objet de notifications.
  • Analogie dans ODI : Les logs d’exécution se trouvent dans le module Operator.
• Agents (ODI) :
  • Description : Glue est un service entièrement managé par AWS, il n’y a donc pas de notion d’agents, tout est géré par AWS, l’utilisateur n’a rien à configurer à ce niveau.
  • Analogie dans ODI : Les agents ODI sont à configurer et à déployer sur des serveurs (pour les agents standalone) ou sur des serveurs d’applications (pour les agents JEE).
• Triangulaire Architecture logique – Contexte – Architecture physique (ODI) :
  • Description : Glue ne possède pas (encore) d’équivalent à ce concept. Tout est basé sur la définition des endpoints, il n’y a pas de couche d’abstraction permettant un découplage comme dans ODI.
  • Analogie dans ODI : Chaque traitement ODI pointe vers des sources et cibles de données à travers une architecture logique (couche d’abstraction) et dans un contexte choisi. Cela permet ensuite de déterminer les réelles connexions physiques, et de switcher « à chaud » (sans modification des développements ni redéploiements) toute la chaîne de traitements d’un contexte de Développement à un contexte de Recette par exemple. Le découplage entre la conception et les connexions physiques vers les sources et cibles de données est donc total.
• Sécurité :
  • Description : Les profils utilisateurs et habilitations sont gérés via les utilisateurs et rôles IAM.
  • Analogie dans ODI : Les profils utilisateurs et habilitations sont gérés dans le module Securité.