Construire une Data Stack à partir de zéro : Guide étape par étape

Ayant travaillé pendant 7 ans en tant que Senior Data Manager chez Criteo et Head of Data chez Payfit, et après avoir effectué des entretiens avec plus de 200 data leaders dans la recherche utilisateur, je commence à avoir une bonne vue d’ensemble des data stacks. C’est pourquoi, à la demande générale, je vais vous faire part des tendances que j’ai pu constater.

Au début du mois de mars, j’ai reçu deux appels: l’un venant d’un ancien collègue, désormais Head of Data chez Swile et l’autre d’un ami, également head of data chez Cajoo. Tous les deux, ayant changé d’emploi, avait besoin de construire un data stack en partant de zéro. Je suppose que cela pourrait en intéresser d’autres. Voici les conseils que je leur ai donnés.

Avant de commencer, voici un modèle de d’évaluation des outils que vous pouvez utiliser à des fins de comparaison:

• Facilité d’utilisation
• Intégration dans le cloud
• La communauté et documentation
• Capacités de gouvernance
• Taxation

Pour simplifier les choses, nous allons simplement suivre les données depuis la source jusqu'au dashboard.

Data warehouse

Là où vous stockez vos données pour les besoins analytiques.

Ma recommandation est simple:

• Si votre stack de développement opère sur Google Cloud, optez pour BigQuery
• Si votre stack de développement opère sur AWS, optez pour Snowflake

Voici pourquoi:

• Redshift était effectivement le premier acteur majeur sur le marché du stockage de données dans le cloud, ce qui signifie qu'ils ont fait de nombreuses erreurs que les concurrents suivants ont pu éviter. De plus, ils n'ont pas beaucoup évolué au cours des dernières années
• Redshift a une mauvaise interface utilisateur, particulièrement pour les utilisateurs finaux
• BigQuery et Snowflake sont assez similaires en termes de fonctionnalités et de modèles de tarification (basé sur l’utilisation: BigQuery vous facture par données scannées alors que Snowflake vous facture par temps de requête). Ce qui les différencie c’est que le premier est plus puissant lorsque l'ensemble de la stack est exécuté sur Google Cloud, tandis que le second est légèrement plus axé sur l'analytique, en en faisant un choix parfait pour les utilisateurs d'AWS.

Snowflake se dirige vers une plateforme de données complète (multi-cloud, Snowpipe, jobs, partage de données, fonctions python/js) avec une interface utilisateur collaborative.

La force de BigQuery réside dans son intégration au sein des systèmes Google Cloud : lecture/écriture à partir de GCS, gestion des droits IAM, facturation, intégration native avec Google Spreadsheets, ...

Ingestion

Transférez vos données à votre data warehouse

Pour les données provenant d'un SaaS, privilégiez Stitch ou Fivetran. Ces deux entreprises offrent un excellent service pour gérer les données de milliers de clients. Leur tarification est linéaire et prévisible. Elles peuvent récupérer des données depuis de nombreuses sources, consultez-les ici et ici.

Vous pouvez également choisir de sélectionner vous-même certaines tables à intégrer, selon leur fréquence d'utilisation ou d'autres critères. Profitez des nombreux "open-source taps" disponibles ici.

Si vous recherchez un compromis entre une solution entièrement gérée et personnalisée, essayez Airbyte. Vous devrez l'héberger, mais il est fourni avec les fonctionnalités, sources et destinations nécessaires.

Segment propose des fonctionnalités similaires, selon le plan choisi. Cependant, Segment se concentre davantage sur le suivi des événements, ce qui est essentiel pour synchroniser vos campagnes marketing avec l'activité des utilisateurs. Considérez Segment comme de grandes oreilles à l'écoute de ce qui se passe sur votre site. Cela nécessite également un plan d'étiquetage continu. Contentsquare est une alternative qui ne s'intègre pas aussi bien avec d'autres sources de données, mais ne nécessite pas de plan d'étiquetage.

Pas d'inquiétude, il reste encore beaucoup de travail à faire en matière de data engineering  : vous devez construire des pipelines d'ingestion pour toutes vos données de production. Si votre environnement de production est en NoSQL (comme MongoDB), alors vous devez effectuer la transformation avant d'ingérer les données dans votre data warehouse. Si votre environnement de production est déjà au format SQL, alors vous pouvez simplement charger toutes les données nécessaires dans votre data warehouse et passer directement au paragraphe suivant.

Transformation

De données brutes à des modèles et rapports prêts à l’emploi.

Avant tout, l'ETL est révolu, place à l'ELT (notez le L est au milieu maintenant). Ces dernières années, les coûts de stockage ont considérablement baissé (moins de 30€ ****par To/mois), à un tel point qu’il est maintenant possible de charger toutes les données brutes dans le data warehouse, puis de réaliser la transformation en SQL. Il faut garder à l’esprit que le stockage dans Snowflake et Bigquery est aussi économique que celui de S3, c'est le traitement qui représente un coût.

Maintenant, focalisons-nous sur l'outil devenu évident pour 90% des équipes data avec lesquelles j'ai discuté : le fameux dbt. Il y a même un nouveau titre de poste qui l'accompagne : data engineer. dbt est open source, plutôt facile à mettre en place, et offre de nombreuses fonctionnalités intéressantes axées sur la qualité, comme les tests unitaires.

L'idée générale est de charger toutes les données dans le warehouse, puis d'utiliser dbt pour créer le Datamart, c'est-à-dire des données approfondies, prêtes à être utilisées à des fins d'analyse.

Il est important de noter que DBT n'est pas un planificateur, vous devrez toujours le programmer. C'est votre planificateur qui lancera les exécutions de DBT, ce qui nous amène naturellement à la section sur les planificateurs ci-dessous. À noter également qu'à la fin de l'année dernière, Google a acquis Dataform, qui est désormais gratuit et bien intégré à Big Query, bien que la communauté ne soit pas encore très étendue.

Planificateur

Exécutez la tâche 1, puis exécutez la tâche 2.

La norme du marché en matière de planification se résume principalement à Airflow, la question est quel type de déploiement vous souhaitez ? Vous pouvez opter pour :

• Auto-géré : Airflow dockerisé
• Géré : Version AWS / Version GCP
• Entièrement géré : Astronomer

Astronomer vous permet de démarrer plus rapidement mais ceci a un coût ...

Visualisation de données

Rendez vos dashboards attrayants

C'est un choix difficile, car la concurrence est rude dans ce secteur. Ce sera également la seule partie que les utilisateurs de votre entreprise verront de l'ensemble de la data stack que vous construisez. De bonnes options seraient Tableau, Looker ou Metabase. Je sais qu'il y a beaucoup d'autres options disponibles, c'est juste mon avis.

Je rédigerai un article dédié à ce sujet, mais pour commencer, optez pour Metabase. Premièrement, du côté de la visualisation de données, c'est simple et direct, il vous suffit de quelques minutes pour passer d'une table à un dashboard. Gardez à l'esprit que pendant un certain temps, vos dashboards seront simples, car vous devrez sensibiliser les différentes équipes. C'est également gratuit tant que vous l'hébergez vous-même.

Découverte de données

Trouvez, comprenez et utilisez les données plus rapidement.

Pensez-vous que la découverte de données est réservée aux personnes qui ont trop de données ou à de grandes équipes ? Saviez-vous qu'après quelques transferts de données à partir de Stitch ou Segment, vous aurez déjà des centaines de tables ?

En plus de cela, je suis assez sûr que le data analyst ou data engineer que vous embaucherez créera sa propre documentation de données sur un document Google ou autre. Ne serait-il pas préférable que ces informations soient accessibles à tous et surtout au deuxième employé ?

Chez CastorDoc, c'est exactement ce que nous proposons !

À propos de nous

Nous écrivons sur tous les processus impliqués dans l'exploitation des actifs de données : de data stack moderne à la composition des équipes de données, en passant par la gouvernance des données. Notre blog couvre les aspects techniques et moins techniques de la création de valeur tangible à partir des données.

Chez CastorDoc, nous développons un outil de documentation des données pour la génération Notion, Figma, Slack.

Ou, pour les adeptes de Fivetran, Looker, Snowflake et DBT, une solution axée sur les données. Nous avons conçu notre logiciel de catalogue pour qu'il soit facile à utiliser, plaisant et collaboratif.

Envie de le découvrir ? Contactez-nous et nous vous ferons une démonstration.

‍

S'inscrire à la newsletter