Le chargement des données : la pierre angulaire d’un projet Data

Laisser une évaluation

2 589
personnes ont consulté cet article

4 minutes

Rédigé par Xavier Michetti - il y a 3 ans et modifié le 25/07/2023 à 15:32

Ce que vous allez découvrir

Qu’est-ce que le chargement de données ?
Mais concrètement, quels sont les enjeux du chargement de données ?
Quid du chargement de données Big Data ?

Le chargement des données : la pierre angulaire d’un projet Data

Avec l’explosion des bases de données Big Data (NoSql, BigQuery, Snowflake, …) on assiste à une effervescence de nouveaux projets. Qui dit nouvelles technologies, dit nouvelles compétences et nouveaux acteurs. C’est un monde nouveau où tout est à faire. Mais pour les anciens qui comme moi ont connu le monde d’avant, on a comme une impression de déjà vu et on se demande si on ne pourrait pas se servir des expériences pour éviter les erreurs du passé.

Qu’est-ce que le chargement de données ?

En tant que professionnel de la data et consultant BI depuis de nombreuses années, je trouve que les bases de données Big Data sont incroyables et permettent de répondre à des problèmes de disponibilités et de volumétries qui ne peuvent pas trouver de solution avec une architecture classique. En effet quand vous chargez vos données dans une base de données classique, vous grevez les performances (car les ressources ne sont pas extensibles). Plus vous augmentez votre volumétrie de données et plus vous avez de filiales à travers le monde et plus ce problème s’aggrave. En effet la solution historique était de charger les données pendant les périodes creuses (la nuit généralement), mais en augmentant les besoins (plus de volume) et en diminuant les périodes creuses (les nuits) vous entrez dans un cercle infernal et inextricable où les périodes creuses n’existent plus vraiment.

Vous l’aurez compris, je suis convaincu que les bases de données Big Data sont incontournables aujourd’hui dans un processus d’analyse des données, car en plus de répondre à des problématiques passées elles ouvrent des possibilités nouvelles comme le machine learning ou l’analyse de données jusqu’alors impossible (Logs, IOT, Big Data, …). En revanche, il y a un point sur lequel le passé peut nous apprendre beaucoup de choses : c’est le chargement des données. Cette étape représente la partie cachée du processus d’analyse des données. On parle volontiers de machine learning et des outils de reporting (Tableau, Qlikview, …). Mais la partie chargement de données ne doit pas être oubliée pour autant, car cette dernière représente la fondation même de ce genre de processus. Il faut que les données arrivent en temps et en heure à la base de données et que ces dernières soient préparées pour les processus suivants (reporting, machine learning, …).

Dans mon passé de consultant BI, j’ai toujours utilisé des outils de chargement de données appelés ETL. Ces outils, low code, me permettaient de gérer facilement cette partie chargement de données. Sauf qu’aujourd’hui ces outils manquent cruellement (voir plus bas) aux bases de données Big Data et ce manque est la raison principale des échecs de la mise en œuvre des projets Data et un frein à leurs développements. En effet les projets BI qui étaient menés sans ETL ont pour la très grande majorité échoué (maintenance impossible, développement coûteux, perte du contrôle du projet). Même Oracle, qui était le leader incontesté des bases de données à l’époque et la référence absolue pour bon nombre de mes collègues, avait déclaré que les ETL ne servaient à rien. Oracle pensait que leur outil PL/SQL (une surcouche du SQL permettant de faire des conditions et des boucles) suffisait à répondre aux besoins, mais la compagnie s’est rendue à l’évidence quelques années plus tard car elle a acheté Sunopsis pour proposer leur ETL : ODI.

Mais concrètement, quels sont les enjeux du chargement de données ?

La partie chargement de données correspond à la logistique dans les entreprises. Et une entreprise comme Amazon n’aurait pas aussi bien marché si elle n’avait pas maîtrisé cet aspect (c’est la base même de leur activité). En effet, il est important que les colis arrivent rapidement, en quantité demandée et en bon état. Il est aussi très important de savoir où sont les colis à tout moment dans le processus.

Pour qu’un projet Data réussisse et perdure, il faut mettre en œuvre cette “logistique”. Il faut bien comprendre qu’une fois le projet mis en production, il faut contrôler que les données continuent de se charger, voir comment les temps de traitement évoluent et pouvoir revenir sur les développements en cas d’évolution des règles de gestion ou pour améliorer ou ajouter des indicateurs (KPI). Si votre traitement est effectué par un programme développé spécifiquement par des ingénieurs chevronnés vous augmentez considérablement la dette technologique de votre projet et vous risquez de perdre le contrôle de ce dernier. En effet, chaque modification vous coûtera cher (faire des modifications dans un programme spécifique est long et nécessite des compétences pointues) et un projet qui ne peut pas évoluer est un projet mort-né. De plus, les ressources qui ont développé le programme deviennent presque incontournables, car il est déjà difficile de modifier son propre programme et ça l’est encore plus si ce n’est pas le vôtre. C’est donc un risque considérable que de se lancer dans ce genre de projet…

Ce n’est pas un hasard si en 15 ans de consulting BI, je n’ai pas tapé une seule ligne de code ou même écrit une seule requête SQL dans un programme de chargement (les requêtes je les utilise pour faire des contrôles ou des recherches). Garder le contrôle du chargement de données est fondamental dans un projet de traitement de données. La plupart des data specialists dans les entreprises ont souvent plusieurs rôles, ils ont la partie technique à gérer mais également une bonne part de relationnel à gérer, car il est important qu’ils échangent avec les gens du métier (maintenance, gestion de projet, AMOA, …).

C’est pour cela que les ETL se sont imposés car ils présentent les avantages de proposer des solutions low code (diminution du temps de développement et surtout de maintenance), facilitation des mises en production (en gérant les environnements) et supervision des traitements. Voir le cas de Talend (qui est l’ETL français le plus connu), seule entreprise IT toujours française, cotée au NASDAQ qui prouve l’importance de ce genre d’outils.

Quid du chargement de données Big Data ?

Et bien, je me suis rapidement rendu à l’évidence que le chargement des données était le parent pauvre des solutions Big Data, ainsi je me suis résigné à écrire des programmes en Python avec le découpage de mes requêtes dans des Spread Sheets pour faciliter la maintenance. Comme souvent “On ne se rend compte de l’importance des choses qu’après les avoir perdues”, j’étais convaincu de l’importance de ces outils, mais je me suis rendu compte qu’ils sont en fait indispensables.

Prenons l’exemple de la base de données Cloud Google BigQuery. Bien que certains acteurs majeurs du marché aient développé des connecteurs, ces derniers ne sont en réalité pas utilisables (j’en ai d’ailleurs fait l’amère expérience). En effet, ils ne tiennent pas compte des particularités de l’outil et leur architecture ne permet pas le traitement des données Big Data. De plus, et bien que performantes, les solutions proposées par Google reposent sur des développements spécifiques et ne répondent donc pas à tous les enjeux décrits dans l’article.

La partie chargement de données est pour l’instant le parent pauvre des solutions Big Data et il y a fort à parier que de nouveaux acteurs émergent pour répondre à ce besoin essentiel.

Besoin d'un peu plus d'aide sur Google Forms ?

Des formateurs sont disponibles toute l'année pour vous accompagner et optimiser votre utilisation de Google Forms, que ce soit pour votre entreprise ou pour vos besoins personnels !

Découvrir nos formations Google Forms