Audit LookML : la check-list en 25 points

Un audit LookML passe en revue cinq couches d'un projet Looker : la structure des explores, la justesse des jointures et des agrégations, la persistance et le cache, la qualité du code (nommage, duplication, champs morts) et la performance vue par l'utilisateur. Les 25 points ci-dessous sont ceux que Neuravoid vérifie en cinq jours sur un projet en production, dans cet ordre, avec pour chaque point ce qu'il révèle et comment le corriger.

Pourquoi auditer un projet qui « marche »

Un projet LookML se dégrade sans bruit. Chaque nouveau besoin ajoute un champ, une jointure, une table dérivée. Au bout de plusieurs années, les explores comptent quatre cents champs, trois mesures s'appellent « CA » avec des formules différentes, et un dashboard de direction met quarante secondes à s'ouvrir. Personne n'a fait d'erreur ; le modèle a juste grandi sans jardinier.

L'audit sert à trois choses : retrouver la confiance dans les chiffres, réduire les temps de réponse et la facture BigQuery, et rendre le modèle prêt pour les agents conversationnels, qui héritent de tous ses défauts.

A. Structure des explores (points 1 à 5)

1. Nombre et rôle des explores. Un explore par question métier, pas un par table. Un projet avec quarante explores dont trente ne servent jamais (vérifiable dans System Activity, explore History) impose une charge de maintenance sans valeur. Cible : moins de quinze explores actifs, chacun avec une description.

2. Explores fourre-tout. Un explore all_data qui joint vingt vues produit des requêtes lentes et des résultats faux dès que deux jointures ont une relation many-to-many. Découper par domaine.

3. Champs exposés. Le paramètre fields: de l'explore et hidden: yes sur les champs techniques réduisent le bruit pour l'utilisateur et pour les agents. Un explore de quatre cents champs, dont soixante utiles, est un problème de gouvernance, pas de formation.

4. Filtres par défaut. Les explores sur de grandes tables partitionnées doivent porter un always_filter ou un conditionally_filter sur la date de partition. Sans cela, une exploration innocente balaie toute la table.

explore: orders {
  conditionally_filter: {
    filters: [orders.created_date: "last 90 days"]
    unless: [orders.order_id]
  }
}

5. Labels et descriptions. Chaque explore, chaque vue et chaque mesure importante a un label métier et une description. C'est aussi le premier prérequis de Conversational Analytics.

B. Jointures et agrégations (points 6 à 10)

6. Clés primaires déclarées. Chaque vue jointe doit déclarer primary_key: yes sur une dimension réellement unique. Sans cela, Looker ne peut pas activer les agrégats symétriques, et les sommes se multiplient sur les jointures one-to-many.

7. Relations correctes. relationship: many_to_one, one_to_many, one_to_one doivent refléter les données, pas l'intention. Une relation déclarée many_to_one alors que la table de droite a des doublons produit un fan-out silencieux. Vérifier par une requête COUNT(*) contre COUNT(DISTINCT key).

8. Agrégats symétriques. Quand une mesure de type sum porte sur une vue côté « one » d'une jointure one-to-many, Looker génère un SQL avec des fonctions de hachage pour éviter le double comptage, à condition que la clé primaire soit déclarée. Vérifier dans le SQL généré la présence de SUM(DISTINCT ...) et de la clé. Si l'auditeur trouve des sql_distinct_key posés au hasard, c'est un signe de correction à la main.

9. Type de jointure. type: left_outer par défaut, inner seulement quand la sémantique l'exige. Une jointure inner posée pour « aller plus vite » fait disparaître des lignes des totaux.

10. Mesures de comptage. type: count compte les lignes de la vue de base de l'explore, pas de la vue où la mesure est écrite, une source classique de confusion. Préférer des count_distinct explicites sur la clé métier.

C. Persistance et cache (points 11 à 15)

11. Datagroups définis. Chaque modèle doit avoir au moins un datagroup avec un sql_trigger qui reflète réellement l'arrivée de nouvelles données, et un max_cache_age.

datagroup: daily_load {
  sql_trigger: SELECT MAX(loaded_at) FROM `dwh.meta.load_log` ;;
  max_cache_age: "24 hours"
}

12. persist_with au niveau modèle et explore. Un explore sans datagroup hérite d'un cache par défaut d'une heure, souvent trop court pour des données quotidiennes, ce qui multiplie les requêtes BigQuery.

13. Tables dérivées persistantes (PDT). Pour chaque PDT : est-elle déclenchée par un datagroup (datagroup_trigger) plutôt que par persist_for ? Utilise-t-elle partition_keys et cluster_keys sur BigQuery ? Sa reconstruction dure combien de temps (visible dans Admin, PDTs) ? Une PDT reconstruite toutes les heures qui balaie trois ans de données coûte plus cher que le problème qu'elle résout.

14. PDT incrémentales. Sur les grandes tables de faits, increment_key et increment_offset évitent la reconstruction complète. Rarement utilisées, souvent le gain le plus rapide sur la facture.

15. Chaînes de PDT. Une PDT qui dépend d'une PDT qui dépend d'une PDT crée des cascades de reconstruction. Au-delà de deux niveaux, la logique appartient à dbt, pas à Looker.

D. Qualité du code (points 16 à 20)

16. Mesures dupliquées. Rechercher les mesures dont le sql est identique ou quasi identique dans plusieurs vues. Trois définitions de « chiffre d'affaires net » avec des formules divergentes est le constat le plus fréquent et le plus coûteux. Une seule mesure, dans la vue de faits, réutilisée partout.

17. Nommage. Convention unique : snake_case, préfixes cohérents pour les dimension groups, _amount, _count, _rate en suffixe des mesures. Les label gèrent l'affichage, jamais le nom du champ.

18. Champs inutilisés. L'explore System Activity, Field Usage, liste les champs jamais interrogés sur les 90 derniers jours. En supprimer la moitié n'est pas rare. Chaque champ mort est une occasion de confusion pour un analyste ou un agent.

19. Refinements et extends. Les extends empilés sur trois niveaux et les refinements (view: +orders) dispersés dans plusieurs fichiers rendent la lecture impossible. Un champ doit pouvoir être compris en ouvrant un seul fichier.

20. Validation continue. Le LookML Validator et le Content Validator passent-ils sans erreur ? Le projet est-il branché sur Git avec des PR obligatoires ? Existe-t-il un test automatisé (par exemple Spectacles ou un script sur l'API run_query) qui exécute les explores critiques à chaque PR ?

E. Sécurité et performance (points 21 à 25)

21. Access grants. Les champs sensibles (salaires, marges, données personnelles) sont protégés par access_grant et required_access_grants, adossés à un attribut utilisateur, pas cachés par un simple hidden: yes.

access_grant: can_view_margin {
  user_attribute: department
  allowed_values: ["finance", "direction"]
}

22. Sécurité au niveau ligne. access_filter sur les explores multi-entités, avec un attribut utilisateur alimenté par le SSO, et un test avec un compte de chaque profil. Un sql_always_where codé en dur ne remplace pas un filtre par utilisateur.

23. Requêtes lentes. L'explore History, trié par durée, montre les dix requêtes les plus lentes des 30 derniers jours. Pour chacune : lecture du SQL généré, vérification des partitions touchées dans BigQuery, décision entre PDT, agrégat ou table dbt.

24. Dashboards de direction. Un dashboard avec trente tuiles lance trente requêtes. Objectif : moins de douze tuiles, des filtres qui s'appliquent à la partition, et des aggregate_table (aggregate awareness) pour les vues agrégées les plus consultées.

25. Coût BigQuery attribuable à Looker. Croiser l'historique Looker avec INFORMATION_SCHEMA.JOBS de BigQuery, filtré sur le compte de service Looker. Les vingt requêtes les plus chères du mois indiquent où agir en premier. Sans ce chiffre, aucun audit ne peut prouver son retour sur investissement.

Ce que livre l'audit

Le résultat utile n'est pas la liste des 25 points cochés, mais une hiérarchie : ce qui produit des chiffres faux (à corriger cette semaine), ce qui coûte de l'argent ou du temps (à planifier ce mois-ci), ce qui gêne la maintenance (à intégrer au fil de l'eau). Sur un projet de taille moyenne, les corrections de la première catégorie tiennent généralement dans une branche de développement livrée avec le rapport.

Ce qui s'observe en production : dans un grand groupe industriel, sur Looker et BigQuery depuis plusieurs années, les trois gains les plus nets sont venus des points 6 à 8 (clés et agrégats symétriques, qui avaient fait gonfler certains totaux), du point 13 (PDT partitionnées) et du point 16 (une seule définition du chiffre d'affaires). Aucun de ces trois ne demandait un nouvel outil.

FAQ

Combien de temps prend un audit LookML ?

Cinq jours ouvrés pour un projet de taille moyenne (dix à trente explores, quelques centaines de champs), incluant la lecture du code, l'analyse de System Activity, la vérification des coûts BigQuery et la rédaction d'un rapport priorisé avec les correctifs critiques sur une branche.

Faut-il un accès administrateur pour auditer ?

Un compte développeur avec accès à System Activity et aux PDT dans l'administration suffit pour l'essentiel. L'accès en lecture à INFORMATION_SCHEMA.JOBS de BigQuery est nécessaire pour le point 25. Aucun accès en écriture à la production n'est requis : tout se fait sur une branche.

Un audit LookML sert-il si nous prévoyons Conversational Analytics ?

C'est même le meilleur moment. Les agents utilisent les explores, les labels, les descriptions et les mesures tels qu'ils existent. Un modèle avec des mesures dupliquées et des champs morts produit des réponses ambiguës. Les points 3, 5, 16 et 18 sont les prérequis directs.

Peut-on faire cet audit soi-même ?

Oui, la liste est faite pour cela. La difficulté n'est pas technique, c'est le temps : une équipe qui tient le modèle au quotidien passe rarement cinq jours d'affilée à le relire avec du recul. Un regard extérieur apporte surtout la priorisation.

Et ensuite

Si trois points de cette liste vous ont fait tiquer, le modèle mérite une semaine de relecture. Le rapport d'audit donne un plan d'action chiffré et les correctifs les plus urgents déjà écrits.

Voir l'offre Audit LookML, et pour aller plus loin : Pourquoi vos chiffres ne concordent pas et La stack dbt, BigQuery, Looker.