Comment faire du big data sans risquer l’indigestion ?

Un beau jour de mars 2021…

La catastrophe arriva.

Les serveurs OVH ont pris feu.

Et nos données… Avec.

Au-delà du bref rappel que tout ce qui est digital est finalement très physique, nous avons également pu voir l’impact énorme sur notre application de géodata, Smappen.

Où la donnée est centrale. C’est notre cœur de métier.

Notre ADN et challenge de tous les jours : une application à jour, fiable, rapide, performante, complète.

Aujourd’hui nous proposons des données des bases INSEE, SIRENE, recensements US, Belgique…

Et nous continuons d’implémenter toujours plus de données pour répondre aux besoins de nos clients.

Alors… Les questions sont les suivantes :

  1. Comment être plus réactif en cas de catastrophe ?
  2. Comment éviter l’indigestion en implémentant un max de données ?

Comment tout a commencé

Pour commencer, l’équipe était réduite : 1 développeur.

Pour arriver à des premiers résultats efficacement, il a donc été au plus simple :

L’opération d’acquisition et de stockage de ces données était manuelle.

Ca ne pose pas de problème tant que la quantité de données et le nombre de développeur n’augmente pas.

Prévenir les soucis

Quand les soucis commencent à arriver…

Quand le datacenter hébergeant nos bases de données prend feu…🔥

C’est le branle-bas de combat !

Il faut reconstruire toute ces bases de données et la documentation est incomplète.

En plus, certaines données externes étaient également hébergées dans ce datacenter.

Nous n’y avions donc plus accès. Il faut donc aller retrouver les données directement à la source (recensement des différents pays que les serveurs officiels de chacun)

Grandir de manière cohérente

Avec une quantité de données grandissante, et le besoin de reconstruire nos données en cas de catastrophe, il faut être capable de les maintenir à jour.

Pour améliorer notre réactivité en cas de catastrophe mais aussi pour faire face à une quantité de données grandissante : nous devions mettre à jour nos données plus régulièrement.

En plus, notre CEO demande qu’on soit capable de mettre à jours ces données en moins de 15 jours ! Il pense que nous avons mieux à faire.

Allez, au boulot…

Premier réflexe : documenter

Commençons par les bases.

Notre première approche : documenter pas à pas le chemin pour reconstruire ces données.

Merci à Notion qui nous garde toutes ces informations au chaud.

Les procédures sont un peu complexes mais elles doivent nous permettre de rétablir notre service en toutes circonstances.

Les limitations

Malgré une documentation correcte, plusieurs problèmes persistent :

  • En cas de problème, la reconstruction de la base de données prend plusieurs jours
  • Avec le nombre croissant de données la documentation se complexifie
  • Certaines données dépendent de données précédemment importées
  • Dans le cas où certaines données ne sont plus disponibles, il n’est plus possible de les retrouver
  • La mise à jour de ces données devient compliquée. Certaines de nos sources de données sont mises à jour mensuellement. Il n’est pas possible de faire des opérations manuelles si souvent.

Ensuite : on automatise

Problématique

Les données présentées à nos utilisateurs sont variées :

  • Données ponctuelles (liste d’entreprises)
  • Données de surface (contours des IRIS, codes postaux ou communes)
  • Données numériques (recensements rattachés à des données de surface)

Les objectifs d’automatisation que nous nous souhaitons atteindre sont :

  • Pouvoir planifier périodiquement les tâches d’ingestion des données,
  • Enchaîner plusieurs traitements
  • Agréger des données issues de plusieurs sources (données surfaciques + données numériques en particulier),
  • La description des tâches doit être suffisamment simple pour tenir lieu de documentation.

Nos données doivent être disponibles dans une base de données PostgreSQL (avec l’extension postGIS pour la gestion des données géographiques).

Un chef d’orchestre

Pour remplacer nos petites mains lors de l’exécution des procédures, nous avons décidé d’utiliser un orchestrateur.

Un orchestrateur permet d’enchaîner des traitements et de gérer les dépendances entre ces différents traitements.

Il présente en général aussi une synthèse claire des opérations effectuées avec leur statut.

Il nous faut ensuite créer une série de traitements unitaires qui pourront être enchaînés par notre orchestrateur.

Nous avons identifiés les traitements suivants:

  • Télécharger un fichier
  • Décompresser un fichier (zip, tar.gz, …)
  • Lire les données d’un fichier de données CSV/XLS et écriture en base de données
  • Lire un fichier de données géographiques (GeoJSON, Shapefile) et écriture en base de données
  • Exécuter des opérations sur la base de données afin d’agréger les données issues de plusieurs sources.

À partir de ces traitements, nous espérons pouvoir réaliser toutes nos chaînes de traitement. 🤞

Le choix de la solution technique

Bon on va rentrer dans le coeur du réacteur, ça va devenir un peu plus technique 🔧.

Il existe de nombreux outils d’orchestration.

Pour notre benchmark nous en avons retenus 3 :

  • Google Cloud Workflow

    ➕ Saas, aucune administration

    ➕ Simple

    ➕ peu cher. Paiement à l’exécution

    ➖ Ne s’occupe que de l’orchestration. Nécessite une autre solution pour l’exécution a proprement parlé

    ➖ Ne propose pas non plus d’exécution périodique

  • Apache Airflow

    ➕ La référence

    ➕ Opensource

    ➖ Complexe à utiliser

  • Argo Workflow

    ➕ Opensource

    ➕ Simple

    ➕ Basé sur kubernetes que nous utilisons déjà

    ➖ Moins réputé

A l’issu de notre benchmark, Argo Workflow a gagné nos cœurs. 🎉

Argo Workflow

Argo Workflow nous permet de construire des tâches de traitement, de les enchaîner et de nous présenter le résultat sous une forme graphique.

Chaque traitement doit être défini sous la forme d’un container Docker.

Ce container pourra prendre en entrée un fichier de données, ou simplement des paramètres de configuration.

Il sera exécuté, puis le résultat de son exécution pourra être transmis au container suivant.

Par exemple, le traitement effectué pour les données de recensement Autrichien est représenté de la manière suivante :

  • backupGeometries et backupStatistics permettent d’effectuer un backup des données issues de l’organisme de sondage autrichien.
  • ingestStatistics et IngestGeometries enregistrent en base de données respectivement les données statistiques (numériques) et les données géographiques (contours de chaque zone de recensement).
  • joinGeometriesStatistics permet de faire la liaison entre les données géographiques et les données statistiques. À partir de cette étape, nous avons à notre disposition des données sur lesquelles notre application peut faire des recherches.
  • cleanTopology permet de nettoyer nos géométries et de s’assurer que nous avons une base saine pour la suite de nos traitements géographiques.
  • les 2 tâches finales publishCatalog... inscrivent dans la base de données le compte rendu de l’acquisition. Nous avons ainsi un catalogue de données permettant de connaître les sources et les traitements sur chacune de nos données disponibles.

Nous avons maintenant un chef pleinement rassuré et nous pouvons manipuler confortablement un plus grand volume de données.

Ce qui va nous aider grandement pour ce que nous avons prévu à l’avenir !

Stay tuned 😉

Benoît Goudy
Architecte logiciels

Notre homme à tout faire… Quand il s’agit de code et de trucs bizarres 😉

Cet article fait partie d’une série d’articles pour fêter le million d’euros de chiffre d’affaires annuel. Découvrez les autres récits ! 

Dan Faudemer
CEO & Fondateur

Les débuts : "traverser le fossé", récit d'une aventure SaaS

De la simple application de calcul d’isochrone à une plateforme de géomarketing : comment et pourquoi Dan a créé Smappen ?

Retour sur une aventure entrepreneuriale plutôt originale !

Laurent Leclerc
Co-fondateur & Business Developer

Pourquoi nous n'avons pas levé de fonds en tant que start-up

La question qui revient le plus souvent de la part de nos clients et utilisateurs : “avez-vous levé des fonds ?” ou “qui sont vos investisseurs ?”. 

Car qui dit start-up… Dit souvent levée de fonds. 

Mais Dan et Laurent, co-fondateurs de Smappen, ont fait le choix d’une croissance organique, dénuée de levée. 

Brice de Marcillac
Customer Success Manager

Démocratiser le géomarketing avec la Smappen Academy

Un outil puissant c’est bien… Mais inutile s’il est mal utilisé. 

Comment délivrer un maximum de valeur à nos utilisateurs pour leur permettre d’utiliser tout le potentiel de notre application ? 

Retour sur le lancement de la Smappen Academy en mode agile pour aider nos clients à grandir.

Et c’est Brice qui prend la parole ! 

Laura Birot
Marketing Manager

Changer le nom de notre start-up en 3 mois

Vous vous souvenez d’OALLEY ? 

Nous, oui !

En mars 2022, OALLEY est devenu Smappen.

Pourquoi ce changement de nom ? 

Et comment nous avons pu réaliser ce changement en trois mois ? 

Retour sur l’aventure avec Laura, Marketing Manager. 

Brice de Marcillac
Customer Success Manager

Passer de 0 à 2 Customer Success Manager

Quand il y a tout à construire… C’est du travail. 

Quand Brice est arrivé en janvier 2021, il y avait quelques éléments en place pour le suivi client. 

Mais il restait encore beaucoup à construire. 

Comment passer de 0 à 2 Customer Success Manager ? Retour en images avec Brice. 

Mélissa Giboreau
Customer Success Manager

3 enjeux auxquels nous faisons face en tant que CSM

Mélissa est arrivée chez Smappen en mars 2022 en tant que Customer Success Manager. 

Avec désormais 500 clients, les enjeux sont nombreux. 

Comment proposer un accompagnement de qualité ? 

Retour sur 3 enjeux auxquels l’équipe CSM de Smappen fait face ! 

Commencez à utiliser smappen dès maintenant

blog

Anne-Claire rejoint l’équipe tech de Smappen

Avec 14 ans d’expérience dans le développement, nous sommes ravis d’accueillir Anne-Claire qui vient renforcer l’équipe tech de Smappen !  Encore une belle arrivée pour