Et après SQL ?

Et après SQL ? Cela peut sembler une affirmation audacieuse. Mais un langage créé il y a plus de 30 ans est-il encore pertinent pour nos besoins en analyse ?

SQL a été conçu pour le OLTP (Online Transaction Processing), pour les opérations CRUD (Create, Read, Update, Delete).

À l'ère de l'analyse de données, nous utilisons désormais SQL pour transformer les données, créer des analyses ad hoc, et élaborer des dashboards de business intelligence.

Nous avons créé des outils (comme dbt) pour rationaliser ce processus et introduire les 'meilleures pratiques en matière de logiciels'. Nous avons fait de SQL notre lingua franca pour tout ce qui est lié à l'analyse.

SQL n'a pas besoin de changer. Il fonctionne très bien depuis des décennies. C'est la pierre angulaire de la plupart de nos bases de données modernes. Ce sont les données et ce que nous en faisons qui ont changé. Pourtant, nous nous reposons toujours sur des frameworks assez basiques (Spark avec Hadoop/MapReduce) et avons construit notre sémantique analytique au-dessus de SQL pour gérer des données qui ne sont plus rectangulaires.

Manquons-nous quelque chose ? Quelle est la suite après SQL ?

En revenant sur mes expériences en tant qu'ingénieur Data Ops, soutenant les équipes de données dans des entreprises telles que Deezer, Olympique de Marseille, Maisons du Monde, etc., cette présentation examinera le défaut négligé introduit par SQL dans le monde de l'analyse, comment il peut être géré et comment de nouveaux frameworks ouvrent la voie dans ce domaine.