Metabase: Maintenabilité et accessibilité de vos dashboards

Introduction

Metabase est un puissant outil de Business Intelligence (BI) qui permet aux utilisateurs, quel que soit leur niveau de compétence technique, d'analyser et de visualiser facilement leurs données, afin de prendre des décisions éclairées et d'optimiser leurs performances commerciales.

Cet article n'est pas un tutoriel sur l'utilisation de Metabase. Si vous n'êtes pas encore familier avec cet outil et souhaitez en apprendre davantage, je vous invite à consulter ce lien qui explique les fondamentaux. Si vous maîtrisez déjà l'outil, commençons sans plus tarder !

Créer des dashboards efficaces et maintenables sur Metabase est essentiel pour tirer le meilleur parti de vos données. Cet article s'adresse principalement aux développeurs et aux créateurs de dashboards qui souhaitent optimiser leur utilisation de Metabase.

L'objectif de cet article est de vous aider à éviter les erreurs courantes telles que la "SQL obsession", l'architecture non définie et la duplication de la logique de filtrage, tout en proposant des solutions pratiques pour améliorer la qualité et l'efficacité de vos dashboards Metabase. Je vais donc vous présenter 3 smells à ne pas reproduire si vous voulez confectionner des dashboards maintenables.

SQL Obsession

Qu'est-ce que c'est ?

Comme vous pouvez le deviner si vous connaissez le code smell d'obsession primitive, l'obsession SQL consiste à poser trop de questions SQL ou native même quand ça n’est pas nécessaire.

Pourquoi est-ce mauvais ?

À moins que votre équipe ne soit composée de maîtres en SQL, l'interface de Metabase est meilleure. La première fois que j'ai vu ce conseil, j'ai pensé qu'il était destiné aux utilisateurs occasionnels de Metabase. Cependant, après plusieurs mois, j'ai dû revenir et modifier certains tableaux de bord de mon projet, et il était vraiment difficile de me rappeler ce que j'avais fait au premier coup d'œil. J'ai alors progressivement migré vers des questions utilisant l'interface de Metabase, et voici pourquoi l'utilisation excessive des questions SQL était une erreur :

1. Réduction de l'accessibilité : Les questions via interface permettent entre autres de redonner la main de la data au métier. En utilisant des questions SQL, vous réduisez l'accessibilité de votre tableau de bord. En effet, grâce à l'interface de Metabase, n'importe qui peut contribuer à votre tableau de bord même sans connaître le langage SQL. En utilisant des questions SQL, vous créez des questions que certains membres de votre équipe ne comprendraient pas et ne pourraient pas maintenir.
2. Complexité et maintenance : Les questions SQL rendent votre tableau de bord beaucoup plus complexe et difficile à maintenir. Au début, votre question peut sembler facile à comprendre, mais lorsque vous y reviendrez après plusieurs mois, vous constaterez qu'elle n'était pas si claire et facile à comprendre. En outre, si votre équipe a pour habitude d'utiliser des requêtes SQL, une seule requête complexe et mal rédigée par l'un de vos développeurs peut rendre la compréhension et la maintenance de votre tableau de bord particulièrement difficile, là où les questions via l’interface metabase sont plus standardisées.

Priorisez également les questions metabase aux snippets. Les questions créées avec l'interface de Metabase ont plusieurs avantages par rapport aux snippets SQL :

1. Historique et restauration : Les questions sont historisées, permettant de revenir à des versions précédentes, contrairement aux snippets SQL.
2. Coloration syntaxique : Les questions SQL bénéficient de la coloration syntaxique lors de leur édition.
3. Visualisation : Vous pouvez visualiser les questions en exécutant la requête directement dans Metabase.
4. Pas de limite de taille : Les questions n'ont pas de limite de taille, contrairement aux snippets SQL qui sont limités (à environ 10 000 caractères).

Cas d'utilisation des snippets SQL : Le seul avantage des snippets est que vous pouvez utiliser du code SQL incomplet ou les appliquer à plusieurs questions provenant de bases de données différentes.
‍

Que dois-je faire alors ?

Le but ici n'est pas d'éviter les questions SQL, mais de ne les utiliser que lorsque c'est nécessaire. Vous pouvez recourir à des requêtes SQL et, dans certains cas, il n'y a pas d'autre possibilité. Cependant, n'oubliez pas de garder à l'esprit l'objectif visé par leur utilisation.

Rappelez-vous que vous n'êtes pas seul sur un projet et que d'autres collaborateurs pourraient avoir du mal à lire votre question plus tard. Gardez à l'esprit que Metabase offre de nombreuses fonctionnalités pour répondre à la plupart de vos besoins.

Essayez d'abord d'utiliser des options disponibles sur Metabase comme les colonnes personnalisées avant de recourir à une requête SQL. Ensuite, si vous devez créer votre propre requête, essayez de réduire son périmètre, utilisez une autre question dans votre question SQL, puis réutilisez-la dans une autre question de l'interface Metabase.

Vous pouvez même décrire l'objectif de votre question afin que d'autres utilisateurs de votre tableau de bord qui ne connaissent pas SQL puissent au moins comprendre votre question.

Astuce :

Nous pouvons réutiliser des questions avec {{#<id-request>}}, vous pouvez voir simplement l’id de votre question en dernier paramètre de l’url de votre question comme ici : http://localhost:3000/question/27-commandes

God folder & Undefined Architecture

Qu'est-ce que c'est ?

Un "god folder" ou une architecture indéfinie consiste à avoir toutes vos questions dans un seul dossier ou à ne pas savoir où aller pour trouver ce que vous cherchez, ce qui peut vous causer beaucoup de maux de tête lorsque vous essayez de trouver une question.

Voici à quoi ressemblerait une architecture en god folder (on peut imaginer ce que ça donnerait avec plus de question)

Pourquoi est-ce mauvais ?

Cela vous fera perdre du temps. Comme dans tout projet, l'architecture est cruciale pour sa maintenabilité. Si vous arrivez sur un projet dans lequel Metabase n'est pas une priorité, vous trouverez souvent des tableaux de bord Metabase avec beaucoup de "god folders" contenant différents types de questions sans aucune structure.

Mais décider d'une architecture n'est jamais une perte de temps, cela vous permettra de mettre en œuvre de nouvelles fonctionnalités plus rapidement et en toute sécurité, et d’onboarder de nouvelles personnes rapidement.

Que dois-je faire ?

Trouvez une architecture qui convient à votre projet. Typiquement, sur mon projet, avoir un dossier par équipe, puis par site, et diviser chaque question par type ("questions de données" et "questions d'analyses" le premier dossier pour récupérer les données m’intéressant et le deuxième dossier pour créer les graphiques qui seront présentés dans mon tableau de bord) est suffisant, car nous n'avons pas beaucoup de questions. Mais si vous en avez beaucoup, je vous recommande de trouver une architecture plus spécifique.

Voici les mêmes questions présenté juste avant, cette fois-ci sous une autre architecture

Duplication de la logique de filtrage

Qu'est-ce que c'est ?

La duplication de la logique de filtrage est l'absence de centralisation des filtres, c'est-à-dire filtrer vos données avec le même filtre dans plusieurs questions. De même, bien qu’ayant en général moins d’impact, si vous appliquez des transformations de données différentes, telles que le formatage des dates, sur chaque graphique, cela peut également nuire à la compréhension globale de la donnée.

Par exemple, si vous avez une question pour afficher votre CA/mois sur vos produits, que vous faites cette question :

‍


Ou même cette question via l’interface :

Alors, vous faites surement de la duplication de logique de filtrage puisque ce filtre est susceptible d’être utilisé un jour ou l’autre dans une autre question de votre dashboard si ce n’est pas déjà le cas.

Pourquoi est-ce mauvais ?

• Réduction de la productivité : Développer vos filtres plusieurs fois vous fera perdre plus de temps que de les centraliser.
• Augmentation du risque d'erreurs : Dupliquer vos filtres augmente considérablement les chances que vos tableaux de bord soient incohérents, car vous pourriez oublier un élément dans l'un de vos filtres de l'une de vos questions.
• Diminution de la flexibilité et de la maintenabilité : Dès que vous devez changer vos filtres, vous devrez alors les changer tous, ce qui se traduit par plus de travail et un risque accru d'introduire des erreurs.

Que dois-je faire alors ?

La meilleure pratique est de créer des modèles pour centraliser les filtres et les transformations. En effet, il est préférable de créer un modèle par périmètre/tableau de bord, puis chaque question de votre tableau de bord commence à partir de ce modèle afin que tous vos filtres ou transformations proviennent du même endroit.

[Définition d’un modèle]

Vous pouvez convertir simplement une question en modèle, voici les étapes  à partir d’une simple question :

Nous avons pu très simplement filtrer les produits qui nous intéressent ainsi que modifier la structure de nos dates, ainsi toutes nos questions dans notre dashboard auront le même format de date.

Conclusion

En évitant les pièges courants comme la "SQL obsession", une architecture de projet mal définie ou encore la duplication de la logique de filtrage, vous pouvez créer des dashboards Metabase plus accessibles, maintenables et collaboratifs.

Utiliser l'interface de Metabase pour construire vos questions permet non seulement de simplifier le processus de création, mais aussi de rendre vos analyses de données plus compréhensibles pour toute votre équipe. En adoptant ces bonnes pratiques, vous assurerez la pérennité et l'efficacité de vos dashboards, facilitant ainsi la prise de décision basée sur les données dans votre organisation.

‍