Quel avenir pour les développeurs SQL à l’ère du machine learning ?

Quel avenir pour les développeurs SQL à l’ère du machine learning ?

  • Mark Balkenende
    Mark Balkenende is a Sales Solution Architects Manager at Talend. Prior to joining Talend, Mark has had a long career of mastering and integrating data at a number of companies, including Motorola, Abbott Labs and Walgreens. Mark holds an Information Systems Management degree and is also an extreme cycling enthusiast.

J'ai obtenu mon diplôme universitaire à la fin des années 1990... Juste à temps pour profiter de la crise des années 2000. Si vous vous souvenez de cette drôle de période, alors vous êtes assez vieux pour lire cet article. J'ai suivi un cursus de Systèmes de gestion des informations, un mélange d'informatique et de gestion d'entreprise, et bien que je sois plus un informaticien qu'un gestionnaire, j'ai survécu. Un cours à la croisée des deux disciplines, appelé Théorie des bases de données, nous enseignait les principes des systèmes de gestion des bases des données relationnelles (SGBDR). J'étais assez doué pour cela ! Nous avons tout appris, des structures de tables correctes aux techniques de modélisation basiques, en passant par les clés primaires et étrangères. C'est également dans ce cours que nous avons entendu pour la première fois le terme « SQL ».

SQL est l'acronyme de Structured Query Language, en français langage de requête structurée. Il est régi par un ensemble de normes, bien que celles-ci semblent être mises en œuvre de manière différente par chaque fournisseur de bases de données. Le codage en SQL est donc légèrement différent selon que vous utilisiez MySQL, Oracle DB2 ou un autre outil, mais si vous savez bien écrire en SQL et que vous connaissez le modèle de base de données, vous pouvez facilement vous adapter et obtenir les données dont vous avez besoin.

Dans ma carrière, j'ai occupé diverses fonctions liées à l'intégration de données pendant 14 ans, et j'ai toujours utilisé des SGBDR quels qu'ils soient comme sources et cibles. J'excellais dans la conception de modèles de données variés pour la création de rapports, les data marts et les magasins de données opérationnelles. Tous ces modèles de données servaient les opérations, la consolidation des données ou d'autres besoins de l'entreprise. Je suis devenu TRÈS, TRÈS bon pour écrire du code SQL complexe et efficace au cours de ma carrière dans l'informatique.

Aujourd'hui, j'aime encore tester différents systèmes et bases de données tous plus ou moins compatibles avec SQL. Par exemple, j'ai récemment obtenu ma certification Data Vault 2.0, en concevant un Data Vault pour nos besoins professionnels à l'aide de Snowflake, un système de data warehouse cloud entièrement compatible ANSI SQL. J'étais heureux de constater que je n'avais pas perdu la main.

Mais, la question à laquelle cette longue introduction amène est la suivante : un développeur tel que moi a-t-il encore sa place dans ce monde de nouvelles plates-formes et de nouveaux traitements ?

SQL ou pas SQL

Le paradigme des bases de données a changé. Il existe maintenant NoSQL, les bases de données de documents, les bases de données orientées colonnes, les bases de données orientées graphes, Hadoop ou encore Spark, et d'autres plates-formes de traitement massivement parallèle (Massively Parallel Processing, ou MPP) apparaissent chaque jour. Tous ces systèmes offrent des avantages pour de nombreux cas d'usage auxquels les SGBDR traditionnels ne sont pas adaptés.

Les plates-formes de big data permettent de traiter des données plus variées, beaucoup plus rapidement que nous n'aurions pu l'imaginer en 1999, lorsque la plupart des informaticiens devaient connaître SQL pour répondre aux besoins des entreprises. Aujourd'hui, les développeurs doivent connaître de nombreuses plates-formes et de nombreux environnements pour exploiter tous les avantages et toutes les fonctionnalités que les prestataires de big data promettent. Ceux d'entre nous qui comme moi sont spécialistes des systèmes compatibles SQL peuvent-ils survivre dans le métier ? Ou devons-nous apprendre Scala, Python, R, Java ou tout autre nouveau langage ou nouvelle plate-forme à la mode ?

Certains outils, tels que Hive et Impala, nous permettent heureusement d'utiliser nos connaissances en SQL pour rechercher des données sur des plates-formes Hadoop et des data lakes, et y accéder. Mais des outils tels que Hive sont restreints. Seules certaines fonctions peuvent être exécutées sur les données : les fonctions définies qui ont toujours été supportées par SQL. Bien sûr, il est toujours possible d'utiliser des fonctions définies par l'utilisateur, mais cela implique de programmer.

Python peut-il être votre avenir ?

Lorsque vous commencez à appliquer les dernières méthodes de machine learning à vos données ou que vous souhaitez exploiter d'importants volumes de données en streaming et interroger des données en mouvement, les systèmes compatibles SQL ne sont pas à la hauteur. Pour ceux d'entre nous qui aiment les SGBDR, il faut se rendre à l'évidence : les données ne sont pas toujours au repos.

Les temps ont changé, et nous devons faire évoluer nos compétences. Personnellement, j'ai commencé à apprendre Python, car ce langage est plus simple que Java et est compatible avec de nombreuses méthodes de machine learning. Dans cinq à dix ans, tous les professionnels de l'information ou techniciens informatiques devront savoir comment utiliser le machine learning, ou au moins comment assurer son bon fonctionnement. Il faudra savoir prendre en charge les systèmes MPP, tels que Hadoop et Spark, pour le traitement des données. Le machine learning sera crucial pour permettre des prises de décisions basées sur les données et pour obtenir les insights concurrentiels indispensables à la conquête de son marché.

SQL est mort, vive SQL

Avec l'évolution de méthodologies telles que les data vaults, qui deviennent très populaires dans les espaces de stockage/HDFS et NoSQL, il existe toujours un réel besoin de SQL. Les systèmes structurés, comme ERP et CRM, auront toujours besoin de data warehouses structurés. Tout cela ne risque pas de disparaître. Mais, si les décideurs de votre entreprise vous demandent de prédire l'avenir et ses conséquences pour votre société, ou de comprendre les solutions d'optimisation hautement automatisées qui ne cessent de gagner en intelligence, vous ne pourrez pas vous contenter de chercher des réponses là où vous les avez toujours cherchées. Vous devrez prendre en compte toutes les données disponibles, quel que soit leur format naturel (structuré ou semi-structuré), et améliorer vos prédictions, vos prescriptions, et même vos facultés cognitives. Certes, SQL et les SGBDR, tout comme l'ordinateur central, ont encore de beaux jours devant eux, mais le vent tourne en faveur des outils d'analyse en temps réel, car SQL n'est pas à la hauteur des nouveaux enjeux.

Participer aux discussions

0 Comments

Laisser un commentaire

Your email address will not be published. Required fields are marked *