Structure d’une stack data en scale-up + exemple de Payfit
Certaines problématiques data apparaissent quand l'entreprise grandit. Julie, data engineer chez 360Learning, décrit la structure de la stack data d'une scale-up.
On vous en avait déjà parlé dans cet article, le choix de vos outils data dépend de la taille de votre entreprise et surtout de votre niveau de maturité sur les sujets data.
J’aborderai donc dans ce contenu les problématiques, les challenges et les méthodes de travail liés au niveau de maturité de la scale-up spécifiquement.
Commençons par poser les bases : qu’est-ce qu’une scale-up ?
Il s’agit d’un statut intermédiaire entre la start-up et la licorne. Généralement, l’objectif de ce type d’entreprise n’est plus d’itérer pour rechercher un business model viable, mais plutôt de suivre ce business model pour générer de la croissance.
C’est le cas de Payfit, de 360Learning ou encore de Tiller, dont je partagerai les exemples plus loin.
Voici un exemple de structure de stack data classique, inspirée par l’exemple de SumUp – ex-Tiller Systems. L’avantage, c’est que les outils data utilisés varient rarement d’une entreprise à l’autre. Vous pouvez donc considérer que ce schéma représente la stack data de 80% des scale-up.
Si l’on regarde ce schéma, on y voit différentes étapes. Pour chacune d’elle, vous serez amené à choisir les outils adaptés.
Plus l’entreprise grandit, plus les utilisateurs et les données sont nombreux, et donc plus le nombre de requêtes est important. Il est donc essentiel que la base de données puisse supporter la charge.
L’une des techniques utilisées par Julie consiste à créer des noeuds : les calculs intermédiaires sont ainsi traités séparément sur chaque noeud, puis les calculs finaux sont rassemblés sur le noeud central. C’est notamment ce que permet de faire BigQuery.
Vous pouvez ainsi travailler en parallèle sur de nombreuses requêtes et gagner ainsi du temps.
Comme je le disais plus haut, l’ETL est un logiciel qui permet de récolter, de transformer et de stocker les données de l’entreprise. Dans le cas de l’utilisation d’un ETL, je formate ma donnée entre la data source et le data warehouse. Dès que j’ai besoin d’un nouveau type d’analyse, j’ai donc besoin d’aller de nouveau chercher la donnée dans ma data source puis de la transformer.
De plus en plus d’entreprises envisagent de passer à un modèle ELT, c’est-à-dire que je formate ma donnée une fois qu’elle a été stockée dans le data warehouse. Ainsi plutôt que de réaliser l’étape de transformation en amont de l’étape de chargement, elle est réalisée après. Cela permet de décorréler les deux actions et apporte une plus grande flexibilité.
Ainsi si l’on souhaite de nouveau apporter une transformation, je n’ai pas besoin de charger de nouveau l’ensemble des données et gagne donc un temps précieux.
Généralement, l’entreprise peut gérer toute sa collecte et sa transformation de données en autonomie, en utilisant le langage Python, assorti de l’outil Airflow. Cet outil permet notamment de programmer des workflows et donc d’automatiser certains traitements de la donnée.
Néanmoins, quand les équipes grandissent et demandent de plus en plus d’analyses, cela nécessite une bande passante importante des data engineers.
Je recommande donc d’utiliser des ETL managés, à l’image de Fivetran. Ce sont des logiciels permettant de simplifier et d’automatiser le traitement de la data. Par exemple, si un collaborateur vous demande une donnée spécifique, vous avez simplement à cocher une case, plutôt que de créer une nouvelle requête
Dans la plupart des entreprises, les requêtes quotidiennes chargent l’ensemble des données, ce qui demande une bande passante significative ainsi qu’un délai important. C’est ce qu’on appelle le full refresh.
En scale-up, on adopte de plus le chargement incrémental. Ce dernier permet d’actualiser uniquement les données modifiées depuis le dernier chargement, ce qui représente un gain de temps considérable.
Pour gagner du temps, les requêtes ne chargent pas l’ensemble des données chaque matin, mais uniquement les données modifiées depuis le dernier chargement.
Plus le nombre de personnes avec lesquelles les data engineers sont amenés à collaborer augmente, plus la formalisation des process et l’automatisation prend de l’ampleur.
Ainsi, la gestion des accès à la base de données peut se transformer en une tâche très chronophage si de nouveaux salariés arrivent chaque semaine. Cette action peut donc être automatisée.
De même, tout le monde n’aura pas le même niveau d’accès aux données. Par exemple, les équipes sales ne voudront pas que d’autres départements aient accès à leur variable. Il faut donc définir des règles de visualisation claires.
Pour que l’ensemble des parties prenantes puisse avoir une vision sur ce qui existe et qui est responsable de telle ou telle donnée ou requête, Julie conseille de créer un data catalog – un peu comme un content manager pourrait créer un catalogue de contenus.
Enfin, pour que les data analysts et data scientists puissent travailler en toute autonomie, les data engineers doivent préparer un framework optimal.
Avec l’atteinte de la maturité data d’une scale-up, de nouvelles problématiques se posent.
Pour en savoir plus sur la mise en place d’une stack data, retrouvez mes cours dans la formation Emil sur le Marketing & Data Automation. Le programme se trouve ici !