Avec plus de 60 000 utilisateurs, 500 000 messages échangés et 200 000 recherches par mois, Hopwork commençait à “avoir de la donnée” en ce début d’année 2016. Mais qu’en faire ? En particulier, comment utilisons-nous ces informations pour :
  • Valider nos choix et notre implémentation ?
  • Guider le développement du produit ?
  • Optimiser notre UX et les différents processus d’onboarding ou de rétention ?
Évidemment, nous ne sommes pas les premiers à nous poser la question et nos prédécesseurs nous ont légué un ensemble d’outils de BI (Business Intelligence) qui nous permettent de mieux comprendre (i.e. trier, filtrer, transformer, corréler et visualiser) nos données.

Ces outils nous donnent la possibilité de poser des questions comme

Quelle est l’évolution (et la tendance) du nombre de freelances sur la plateforme ?

ou encore

Quel est le tunnel de conversion entre la page de recherche et l’acceptation d’un devis ?

Évidemment, si ces questions sont intrinsèquement intéressantes, c’est leur évolution qui apporte le plus de valeur, en particulier lorsque nous la corrélons avec la mise en place de nouvelles fonctionnalités.
Il ne nous restait donc plus qu’à choisir notre outil de business intelligence et le tour était joué ! Malheureusement, un choix technique est venu ralentir notre progression…

Notre situation début 2016

Depuis le début d’Hopwork, notre référentiel de données est géré par une base MongoDB. Elle a parfaitement rempli son rôle jusque là et même si elle a pu nous poser quelques problèmes, elle n’avait jamais été bloquante.
C’était avant de faire de la BI car à ma connaissance, le seul moyen de faire nativement de la business intelligence sur une base MongoDB en temps réel est MongoDB connector for BI. Pas encore disponible à l’époque et annoncé à 4K$ par serveur et par an, cette solution n’était pas envisageable pour nous.

Alors nous avons fait quelques tests

Il s’agissait de faire le tour de l’existant pour trouver la perle rare ! C’est plein d’optimisme que nous commencions notre quête !

Metabase

Metabase est un produit open-source ayant vocation à offrir une solution de business intelligence simple, avec une interface claire et léchée, et surtout compatible avec de nombreuses bases de données, en particulier MongoDB :
metabase_dashboard
La promesse est très belle mais après quelques heures, nous avons rejeté cette solution pour les raisons suivantes :
  • Metabase n’extrait pas le timestamp d’un objet avec son ObjectId : À moins de rajouter une colonne calculée sur chaque collection, il n’est pas possible d’avoir la date de création d’un document. Pratique.
  • Metabase ne sait pas faire de somme cumulée : La première question que tout le monde se pose sur son produit est “Quelle est l’évolution du nombre d’utilisateurs ?“. Metabase ne sait pas répondre à cette question, quand bien même nous aurions les timestamps dans un champ.
Alors oui nous aurions pu hacker le produit avec des colonnes générées mais honnêtement, ces deux indicateurs nous semblaient être la preuve que même si le projet semble extrêmement prometteur, il manque encore de maturité. Pour l’avoir utilisé par la suite sur un autre projet, il se révèle aussi particulièrement lent.

MoSQL

S’il n’est pas possible de faire de la business intelligence directement sur MongoDB, tentons de streamer nos données vers une base relationnelle et de brancher l’outil sur celle-ci.
C’est ce que se propose de faire Stripe avec MoSQL.
68747470733a2f2f7374726970652e636f6d2f696d672f626c6f672f706f7374732f6d6f73716c2f6d6f73716c2e706e67
L’outil semble proposer tout ce qu’il nous faut :
  • Une définition externe du mapping, que nous pourrons mettre à jour au fil de l’eau.
  • Un mode batch (dump de la base MongoDB vers un SGBDR) ou un mode streaming.
Après avoir écrit nos premiers mappings, nous avons tenté de traiter le cas des comptes et des profils. Deux objets, deux collections. Jusque là pas de problème mais comment créer une clé étrangère entre ces objets ? Pas possible ? Tant pis, on écrira un script qui repasse après un import batch pour les ajouter…
Puis en avançant, nous somme tombés sur un objet possédant des objets embarqué (bah oui, MongoDB je rappelle). Puis des listes d’objets embarqués. Puis des listes d’objets contenant eux-même des objets embarqués, référençant des objets d’autres collections…
Il nous a alors paru évident que le problème n’était pas simple et que MoSQL ne répondrait pas à (tous) nos besoins (et ne répondra probablement pas aux vôtres).
Désespérés, nous partons en week-end en espérant que la solution apparaîtrait magiquement d’ici le lundi.

Mongo connector : De Mongo vers …

Et c’est littéralement ce qu’il s’est passé ! En revenant le lundi suivant, j’ai découvert qu’Hugo Lassiège, un des deux CTOs d’Hopwork, avait implémenté une ébauche de solution en utilisant un projet open-source : Mongo-connector.
tous-les-badges(2)-17
Mongo-connector est un outil écrit en python qui lit l’oplog d’un réplica MongoDB et envoie les objets qui sont crées ou modifiés à un module au choix. En français, il permet de suivre les modifications opérées sur la base de données en temps réel et les envoie à un code de notre choix (par exemple pour les stocker dans une base relationnelle !).
Et bien il n’y a plus qu’à, Mongo Connector PostgreSQL (quel joli nom n’est-ce pas ?) est né ! En une phrase, il se propose de streamer n’importe quel document dans une base relationnelle. Et par n’importe quel document, je veux dire, ceux de la vie réelle et de toute la merde complexité qu’elle comporte, i.e. :
  • Des références vers des objets d’autres collections
  • Des tableaux de scalaires
  • Des tableaux de documents
  • Tout ça imbriqué (pensez à une liste de documents dont un sous-champ est une référence vers une autre collection)
Et tout ça, au prix d’une complexité franchement faible. Par exemple, voici le mapping (partiel) utilisé en production pour nos profils :

 

"accounts": {
    "pk": "id",
    "_id": {
        "dest": "id",
        "type": "TEXT"
    },
    "email": {
        "dest": "email",
        "type": "TEXT"
    },
    "photo.name": {
        "dest": "picture_url",
        "type": "TEXT"
    },
    "lastConnection": {
        "dest": "last_connection",
        "type": "TIMESTAMP"
    },
    "identities": {
        "dest": "identities",
        "type": "_ARRAY",
        "fk": "account_id"
    }
}
Une fois la logique assimilée, aucun problème pour écrire de nouveaux mappings. De plus, si la configuration par mapping nécessite une évolution à chaque modification de l’objet, elle permet quand même de contrôler la donnée qui atterrit dans notre base de BI et de limiter ainsi le volume (et donc d’améliorer les temps de réponse).
À l’heure actuelle, le connecteur tourne en production depuis plusieurs mois sans problèmes majeurs. Évidemment, tout n’est pas rose et notre solution gagnerait à posséder quelques fonctionnalités supplémentaires mais dont nous n’avons pas besoin aujourd’hui.
Si vous souhaitez  en savoir plus, consulter la documentation, utiliser le logiciel et même contribuez, vous êtes les bienvenus !

Enfin ! Nos premiers dashboards !

C’est bien joli tout ça mais on a pas encore fait de BI ! Maintenant que nos données sont dans une base relationnelle, nous en revenons à notre problème de départ : Quelle solution de BI utiliser ?
Pour nous, plusieurs critères étaient importants :
  • L’aspect fonctionnel : Après le benchmark, nous avons constaté que toutes les solutions proposent plus ou moins les mêmes fonctionnalités (en tout cas à notre niveau d’analyse).
  • L’aspect communautaire : Chez nous chacun est libre d’utiliser le matériel qu’il juge idéal. En résumé, du Windows, du Mac, du Linux (la légende raconte même que Jean-Baptiste Lemée utilise une game boy color pour coder). En plus de ça, nous ne voulions pas nous taper l’installation, et d’expérience nous savions que ça serait un frein à l’adoption. Nous utiliserons donc une application SaaS.
  • L’aspect UX : Si toutes les solutions ont plus ou moins les mêmes fonctionnalités, elles ne disposent pas de la même UX, loin de là ! Hors de question de payer un consultant pour nous former, le produit devait se passer d’explications et puisque nous voulions que chacun puisse l’utiliser, il se devait même d’être dummy-proof !
  • Le prix : Le prix devait nous sembler raisonnable et en rapport avec le gain que nous serons amené à faire en étudiant les données.
Je vous passe le benchmark parce que dans le monde de la BI, les consultants en costard/cravate règnent en maîtres, et franchement, il est difficile de filtrer le bullshit de la vérité.
Mais par le plus grand hasard, c’est lors d’un forum ouvert organisé chez Evaneos (une startup de voyage) qu’un de leur ingénieur nous a parlé de ChartIO. Et c’est pas tombé dans l’oreille d’un sourd ! Dès notre retours au bureau (après avoir décuvé de la veille…), notre cher CTO, encore lui, contactait ChartIO pour un essai. Révélation !
 
Nous avons découvert un super produit. UX au top, pleins de fonctionnalités sympas (comme la possibilité de définir à posteriori nos clés étrangères, de créer de nouvelles tables dynamiquement, etc.), super rapide et facile d’utilisation. Bref, génial.
Et au final, ça donne quelque chose comme ça :
Un exemple détaillé de business intelligence sur ChartIO
Un exemple détaillé de business intelligence sur ChartIO

Quoi qu’il en soit, aujourd’hui, nous avons plus de 400 graphiques détaillant les moindres aspects de notre acquisition, des performances financières et techniques, de nos différents tunnels de conversion, de toutes les nouvelles fonctionnalités, etc. Le plus beau dans tout ça, c’est que tous nos corps de métier l’utilisent, de notre product manager à notre COO en passant par nos développeurs et nos business developers.

En bref

S’il ne fallait retenir que deux choses :
  • C’est compliqué de faire de la BI sur une base Mongo. D’ailleurs, ne le faites pas, utilisez notre outil (ou celui de mongo si vous en avez les moyens) et gagnez du temps !
  • Dans sa fourchette de prix, ChartIO est un des meilleurs outils que nous avons pu trouver et nous ne regrettons pas notre choix !
Ce genre de challenge vous intéresse ? Contactez nous, pour discuter et plus si affinité !

3 thoughts on “Business Intelligence sur MongoDB :
De Mongo à PostgreSQL à ChartIO

  1. Pour compléter mon très cher Maxime, avant d’essayer Chartio nous avons utilisé Tableau Software. Ayant utilisé a fond les deux je trouve que Tableau est plus simple à utiliser, mais en revanche c’est moins joli, et surtout la solution en SaaS est horriblement onéreuse. J’étais donc bien seul sur ce petit outil. Merci de m’avoir donné un jeu multijoueur 😉

    PS : Impossible également de se connecter directement à MongoDB, nous avions du répliquer une partie de la base en SQL.

Leave a Reply

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