2023, l’année du “zero-ETL”

Avec un peu de retard sur ses concurrents Microsoft et Google, AWS a proclamé que 2023 serait une année “zero-ETL”. Qu’est-ce que ça veut dire et qu’est-ce que ça change pour nous ? Essentiellement que réaliser des analyses analytiques sur nos données de production n’aura jamais été aussi simple ! Explications.

L’indispensable data warehouse : pourquoi ne pas requêter sa base de données de production pour des analyses analytiques ?

Parce que les requêtes de type analytique (OLAP*) sont de nature bien différente de nos bonnes vieilles requêtes SQL traditionnelles (OLTP*). En général, les lectures réalisées sur une base de données relationnelle sont très rapides et demandent peu d’accès disque, grâce entre autres aux mécanismes avancés d’indexation et de jointures des données.

Par exemple : “Quel est le numéro de téléphone du client de la facture #43584”. 

La requête est quasi instantanée parce que le moteur de requête sait exactement où aller lire l’information sur le disque dur, à partir du numéro de facture puis de l’id du client. 

Imaginons maintenant que nous souhaitions connaître la facture avec le plus gros montant : dans ce cas-là le moteur de requête n’a pas d’autre choix que de parcourir l’intégralité de la table factures, à la recherche du plus gros montant. C’est une requête de type OLAP. 

Si la table factures fait 10Go, il est facile d’imaginer que ce type de requête peut impacter très fortement les performances de la base de données.

C’est pour ça qu’on a inventé les data warehouses ! Un data warehouse est une base de données relationnelle optimisée pour les requêtes de type OLAP. Le principe est simple : diviser pour mieux régner. La base de données y est découpée en une multitude de petits fragments qui seront lus en parallèle par autant de nœuds de calcul (Data Warehouse Units), permettant ainsi de démultiplier les performances.

Jusqu’à aujourd’hui, utiliser Redshift, le data warehouse d’AWS, réclamait un peu de travail : il s’agissait d’extraire régulièrement les données issues de la base de production (soit par streaming temps-réel, soit par batch via un data lake S3) avant de les charger dans Redshift. Il s’agit concrètement d’une opération de type ETL (Extract, Transform, Load) qu’il est nécessaire de mettre en place pour alimenter en données le data warehouse.  

AWS 2023 : une connexion directe entre RDS Aurora et Redshift !

AWS a annoncé en décembre 2022 l’intégration de la base de données SQL RDS Aurora dans Redshift, le tout en full serverless et sans aucune opération ETL.

Cela signifie qu’en une poignée de secondes, vous pouvez instancier un Redshift capable de se synchroniser tout seul, et en quasi temps-réel, avec votre base de données SQL de production. Il devient alors possible d’effectuer des requêtes SQL de type OLAP sur vos données en temps-réel et sans impacter vos performances de production. Tout cela sans déployer la moindre architecture data, ni le moindre data lake et tout en profitant d’un scaling entièrement managé. Alléluia !

Du zero-ETL jusqu’au notebook Python

Les équipes d’AWS ne se sont pas arrêtées là, puisqu’ils ont également annoncé l’intégration d’Apache Spark avec Redshift. Il faut voir Apache Spark comme un notebook (Python ou SQL) boosté aux stéroïdes. Spark repose sur un principe de parallélisation dans lequel les données sont partitionnées et stockées en RAM sur des dizaines ou des centaines de nœuds de calcul. Il est donc possible de créer et de charger une quantité massive de données dans un dataframe (similaire à celui de Python Pandas) et de profiter du confort et de la simplicité d’un notebook Python (ou SQL), cher aux data scientists, pour une analyse exploratoire des données.

Par transitivité, RDS vers Redshift vers Spark, AWS nous laisse donc l’opportunité d’explorer nos données de production en quasi temps-réel depuis un simple notebook, sans avoir à déployer la moindre instance, ni même crawling.

LES PROs du zero-ETL : 

• une réplication de la base de production en quasi-réel

• utilisation de Spark à la demande, avec une capacité ajustable

• un gain de temps et d’argent considérable : il n’y a pas de développement nécessaire !

LES CONs : 

• ne permet pas de transformer les données : pas de nettoyage, de dénormalisation ni de schéma en étoile…

Malgré cette importante dernière limitation, nous assistons à une avancée majeure dans la démocratisation de la donnée. Je ne serais pas surpris de voir cette année exploser le nombre de projets data basés sur la paire RDS/Redshift. Quant à Spark en full serverless et son intégration à Redshift (mais aussi à AWS Athena !), c’est déjà une petite révolution en soi.

* : OLTP (online transaction processing) / OLAP (online analytical processing)