La plupart des entreprises stockent leurs volumes massifs de données transactionnelles et analytiques au repos dans des entrepôts de données ou des lacs de données. Les équipes de vente, de marketing et de réussite client ont besoin d’accéder à ces ensembles de données. Reverse ETL est un mot à la mode qui définit le concept de collecte de données à partir de magasins de données existants pour les fournir facilement et rapidement aux équipes commerciales.
Cet article de blog explore pourquoi les fournisseurs de logiciels (essayent) d’introduire de nouvelles solutions pour l’ETL inversé, lorsque cela est nécessaire, et comment elles s’intègrent dans l’architecture d’entreprise. L’implication du streaming d’événements avec des outils comme Apache Kafka pour traiter les données en mouvement est un élément crucial de l’ETL inversé pour les cas d’utilisation en temps réel.
Que sont l’ETL et l’ETL inversé ?
Commençons par les termes. Que signifient ETL et ETL inversé ?
ETL (Extraire-Transformer-Charger)
Extract-Transform-Load (ETL) est un terme courant pour l’intégration de données. Des fournisseurs comme Informatica ou Talend fournissent un codage visuel pour implémenter des pipelines ETL robustes. Le cloud a amené de nouveaux acteurs SaaS et le terme plate-forme d’intégration en tant que service (iPaaS) sur le marché ETL avec des fournisseurs tels que Boomi, SnapLogic ou Mulesoft Anypoint.
La plupart des outils ETL fonctionnent dans des processus par lots pour les charges de travail de Big Data ou utilisent des services Web et des API SOAP/REST pour une communication en temps réel non évolutive. Les pipelines ETL consomment des données provenant de diverses sources de données, les transforment ou les agrégent et stockent les données traitées au repos dans des puits de données tels que des bases de données, des entrepôts de données ou des lacs de données :
Extract-Load-Transform (ELT) est une approche très similaire. Cependant, les transformations et les agrégations se produisent après l’ingestion dans le magasin de données :
Il n’est pas surprenant que les fournisseurs modernes de stockage et d’analyse de données tels que Databricks et Snowflake promeuvent l’approche ELT. Par exemple, Snowflake présente le « mesh de tableau de bord interne » où tous les domaines et produits de données sont construits au sein de leur service cloud.
ETL inversé
Comme son nom l’indique, Reverse ETL renverse l’histoire d’ETL. Cela signifie le processus de déplacement des données d’un magasin de données vers des systèmes tiers pour « rendre les données opérationnelles », comme le dit le marketing de ces solutions :
Les données sont consommées à partir de systèmes de stockage à long terme (entrepôt de données, lac de données). Les données sont ensuite transmises à des applications commerciales telles que Salesforce (CRM), Marketo (marketing) ou Service Now (réussite client) pour les exploiter pour la génération de pipelines, les campagnes marketing ou la communication client.
Produits et offres SaaS pour l’ETL inversé
Il suffit de rechercher sur Google « ETL inversé » pour trouver des fournisseurs proposant spécifiquement leurs solutions. Ils paient également des publicités pour les « conditions normales d’intégration de données ». Par conséquent, il y a de fortes chances que vous les ayez déjà vus même si vous ne les avez pas recherchés. 🙂 La plupart de ces entreprises sont de jeunes entreprises et des startups qui créent une nouvelle entreprise autour des produits Reverse ETL. Les fournisseurs de logiciels que j’ai trouvés dans mes recherches incluent Hightouch, Census, Grouparoo (open source), Rudderstack, Omnata et Seekwell.
Fait amusant : si vous recherchez l’ETL inversé de Snowflake, vous ne trouverez aucun résultat sur Google, car ils souhaitent conserver les données dans leur entrepôt de données.
Un point fort et un argument de vente clé de tous les outils ETL est le codage visuel, et donc le temps de mise sur le marché pour le développement et la maintenance des pipelines ETL. Certaines solutions ciblent l’intégrateur citoyen (terme inventé par Gartner), c’est-à-dire les hommes d’affaires qui construisent leurs intégrations.
ETL inversé == Données en temps réel pour les ventes, le marketing et la réussite des clients
La plupart des histoires de réussite d’ETL inversé parlent de se concentrer sur les ventes, le marketing ou le succès des clients. Ces cas d’utilisation attirent les divisions commerciales. Ces équipes ne souhaitent pas acheter un outil technique ETL comme Informatica ou Talend. Les professionnels attendent des interfaces utilisateur simples et intuitives, à la manière d’un intégrateur citoyen.
Les vendeurs ciblent les hommes d’affaires et promettent une infrastructure technique simplifiée. Par exemple, un fournisseur fait la promotion de « Supprimer les middleware hérités et réduire les tâches ETL ». Ma première pensée : bienvenue, shadow IT !
Néanmoins, jetons un coup d’œil à la cas d’utilisation de l’ETL inversé:
- Identifier les clients à risque et le taux de désabonnement des clients potentiels avant qu’il ne se produise
- Générer de nouvelles ventes en corrélant les données du CRM et d’autres interfaces
- Marketing hyper-personnalisé pour la vente croisée et la vente incitative aux clients existants
- Analyse opérationnelle pour suivre plus rapidement les évolutions des applications et des données métiers
- Réplication des données vers des applications cloud modernes pour de meilleures capacités de reporting et de recherche d’informations
De plus, tous les fournisseurs parlent également de données en temps réel pour les cas d’utilisation ci-dessus. C’est génial. MAIS : Malheureusement, Reverse ETL est un énorme ANTI-MOTIF pour créer des cas d’utilisation en temps réel. Explorons plus en détail pourquoi.
ETL inversé + Data Lake + Temps réel == Mythe
Les cas d’utilisation décrits ci-dessus sont excellents et ont une valeur commerciale énorme. Si vous suivez mon blog ou mes présentations, vous avez probablement vu exactement les mêmes cas d’utilisation en temps réel construits nativement avec des données de traitement de flux d’événements en mouvement.
Si vous stockez des données dans un entrepôt de données ou un lac de données, vous ne pouvez plus les traiter en temps réel car elles sont déjà stockées au repos. Ces magasins de données sont conçus pour l’indexation, la recherche, le traitement par lots, la création de rapports, la formation de modèles et d’autres cas d’utilisation qui ont du sens dans le système de stockage. Mais vous ne pouvez pas consommer les données en temps réel en mouvement à partir du stockage au repos :
C’est là que le streaming d’événements entre en jeu. Des plateformes comme Apache Kafka permettent de traiter les données en mouvement en temps réel pour les charges de travail transactionnelles et analytiques. Examinons donc une architecture d’entreprise moderne qui exploite le streaming d’événements pour le traitement des données en mouvement ET un entrepôt de données ou un lac de données pour le traitement des données au repos.
ETL inversé dans l’architecture d’entreprise
Explorons comment Reverse ETL s’intègre dans l’architecture d’entreprise et quand vous avez besoin d’un outil séparé pour cela. Pour cela, revenons d’abord en arrière. Que fait l’ETL inversé ? Il retire les données du stockage, les transforme ou les agrège, puis les ingère dans les applications métier.
Deux options existent pour l’ETL inversé : les requêtes SQL et la capture de données modifiées (CDC).
ETL inversé == Requêtes SQL vs capture de données modifiées
Si un outil ETL inversé utilise SQL, il s’agit généralement d’une requête sur les données au repos. Ce cas d’utilisation permet aux professionnels de créer des requêtes dans des interfaces utilisateur intuitives. Les cas d’utilisation incluent la création de nouvelles campagnes marketing ou l’analyse du parcours de réussite du client. L’ETL inversé basé sur SQL nécessite des outils intuitifs et simples à utiliser.
Si un outil ETL inversé fournit une corrélation de données en temps réel et envoie des notifications, il utilise la capture de données modifiées (CDC). CDC est automatisé et permet d’agir en temps réel sur les évolutions du stockage des données. Le pipeline comprend la corrélation des données à partir de différentes sources de données et l’envoi de messages push en temps réel dans les applications métier. L’ETL inversé basé sur CDC nécessite une infrastructure de streaming d’événements évolutive et fiable.
Comme vous pouvez le voir, les approches SQL et CDC ont leurs cas d’utilisation et se chevauchent parfois dans l’outillage et l’infrastructure. Le CDC basé sur le journal des modifications est souvent l’approche technique préférée au lieu de synchroniser les données selon un calendrier récurrent avec SQL ou lors du déclenchement en appelant une API, que vous utilisiez « juste » une plate-forme de streaming d’événements ou un produit Revere ETL particulier.
Cependant, la question la plus importante est de savoir comment concevoir une architecture d’entreprise pour ÉVITER le besoin d’ETL inversé.
Architecture événementielle + Streaming ETL == Reverse ETL intégré
Les données en temps réel battent les données lentes. C’est vrai pour la plupart des cas d’utilisation. Par conséquent, la montée en puissance des architectures événementielles est imparable :
L’ETL inversé n’est pas nécessaire dans l’architecture événementielle moderne ! Il est « intégré » dans l’architecture prête à l’emploi. Chaque consommateur consomme directement les données en temps réel si cela est approprié et techniquement faisable. Et les entrepôts de données ou les lacs de données le consomment toujours à leur propre rythme en temps quasi réel ou par lots :
Le moteur SQL de streaming natif de Kafka ksqlDB fournit des fonctionnalités CDC et un traitement de flux continu. Par conséquent, vous pouvez même appeler ksqlDB un outil ETL inversé si votre marketing le demande.
Si vous souhaitez en savoir plus sur la création de plates-formes de données en temps réel, consultez l’article « L’architecture Kappa remplace Lambda par le grand public ». Il explore comment des entreprises comme Uber, Shopify et Disney ont construit une architecture Kappa basée sur les événements pour tous les cas d’utilisation, y compris en temps réel, en temps quasi réel, par lots et par requête-réponse.
Quand avez-vous besoin d’un ETL inversé ?
Une architecture entièrement nouvelle construite à partir de zéro avec une plate-forme de streaming d’événements en son cœur n’a pas besoin d’ETL inversé pour consommer les données d’un entrepôt de données ou d’un lac de données, car chaque consommateur peut déjà consommer les données en temps réel.
Cependant, fournir une interface pour les utilisateurs professionnels n’est PAS résolu immédiatement avec une plate-forme de streaming d’événements telle qu’Apache Kafka. Vous devez ajouter des outils supplémentaires tels que des connecteurs Kafka CDC ou des outils tiers dotés d’interfaces utilisateur intuitives. Par conséquent, Reverse ETL peut être utile dans deux scénarios : intégration Brownfield et outils simples pour les utilisateurs professionnels.
Architectures de friches industrielles où les données sont stockées au repos et les hommes d’affaires doivent les utiliser dans des applications d’entreprise. Les données doivent être extraites du stockage de données pour les cas d’utilisation des ventes, du marketing ou de la réussite client :
Les outils d’intégration simples pour les gens d’affaires sont beaucoup plus intuitifs et faciles à utiliser que les solutions ETL et iPaaS traditionnelles. Même dans une approche entièrement nouvelle, les outils ETL inversés peuvent toujours être la solution la plus simple et offrir le meilleur délai de mise sur le marché.
N’oubliez pas non plus que les outils modernes tels que Salesforce ou SAP fournissent déjà des interfaces basées sur les événements. Les fournisseurs de stockage de données tels que Elastic, Splunk ou Snowflake investissent également massivement dans les couches de streaming pour s’intégrer de manière native avec des outils tels que Apache Kafka. L’intégration avec les applications métier est possible via le streaming d’événements en temps réel au lieu de l’intégration via l’ETL inverse à partir du magasin de données. Pour ces raisons, évaluez votre problème commercial et si vous avez besoin d’une plate-forme de streaming d’événements, d’un outil ETL inversé ou d’une combinaison des deux.
Exemples Kafka pour l’ETL inversé
Voyons deux exemples concrets.
Apache Kafka + Salesforce + Oracle CDC + Snowflake
L’architecture suivante combine la diffusion de données en temps réel, la capture de données modifiées, le lac de données et un service cloud ETL inversé :
Quelques remarques sur cette architecture :
- Les le système nerveux central est une plateforme de streaming d’événements (Confluent Cloud) qui fournit un streaming de données évolutif en temps réel et un véritable découplage entre n’importe quelle source et récepteur de données.
- UNE Service cloud SaaS (Salesforce) fournit nativement un API asynchrone pour une intégration en temps réel basée sur les événements.
- UNE base de données relationnelle traditionnelle (Oracle) est intégré à ETL inversé via la capture de données modifiées à l’aide du connecteur Oracle CDC de Confluent pour Kafka Connect.
- Des données de toutes les données les sources sont traitées en continu avec traitement de flux des outils tels que Kafka Streams et ksqlDB.
- Ingestion de données dans un entrepôt de données (Snowflake) configuré dans le cadre du connecteur Kafka Connect entièrement géré de Confluent Cloud.
- UNE l’utilisateur professionnel tire parti d’une solution ETL inversée dédiée (Seekwell) pour extraire les données de l’entrepôt de données (Snowflake) dans une application métier (Google Sheets).
L’ensemble de l’infrastructure fournit un système nerveux en temps réel basé sur les événements, évolutif et fiable. Chaque application peut consommer et traiter des données en mouvement en temps réel (si nécessaire). Le stockage des données au repos est complémentaire pour les cas d’utilisation par lots et intégré à la plate-forme basée sur les événements.
TL;DR : Cette architecture découple véritablement les applications, évite…