Aymeric, vous pilotez des projets BI depuis plus de 10 ans, parlez-nous de Looker en quelques mots..
#cloud-native #not-only-bi
Looker est plus qu’un n-ième outil de BI, c’est une plateforme Data complète, moderne, multi-cloud et unifiée. Il fait partie de la catégorie des solutions appelée “Cloud-Native”.
En effet, Looker a été développé dans le Cloud, pour le Cloud. C’est bien plus qu’un outil de BI classique, il permet de mettre en action ses données rapidement et efficacement, sans connaissances techniques poussées nécessaires.
L’outil remet véritablement l’utilisateur au plus près des données, et réinvente la notion de “self-service” décisionnel.
Puisqu’on en parle, pourquoi le “self-service” a été jusqu’ici une fausse promesse ?
#self-service
On pourrait dire que le self-service idéal, c’est quand la machine répond toute seule à une question posée (à l’oral ou dans un chat par exemple). Il n’existe pas vraiment de solution où la réponse à toute question Business arrive instantanément même si les sommes investies en R&D sont conséquentes.
On doit encore faire la balance entre la richesse de la solution (souvent décrite à un cahier des charges exhaustif) et son appréhension par les utilisateurs (qui, plus qu’un ensemble de fonctionnalités veulent tout simplement … des réponses à leurs questions). On se retrouve encore trop dans un affrontement fonctionnalités vs efficacité.
De nombreuses implémentations d’outils de Business Intelligence font trop la part belle à l’outil lui-même et moins au modèle de données métiers qui doit en fait porter toute la puissance des données.
Quelles sont les particularités de Looker par rapport aux autres outils du marché ?
Elles sont nombreuses, je vais partager ici celles qui me semblent les plus différenciantes.
#git
La première chose qui me vient en tête est l’intégration native de Github dans la solution. C’est incroyable quand on y pense, la data est par essence collaborative, et presque aucune solution du marché analytique ne permet de travailler sur des projets à plusieurs.
En effet, la majorité des outils concurrents sont peu, voire pas pensés pour le développement collaboratif et le versionning. C’est parfois un véritable casse-tête pour les entreprises qui font intervenir plusieurs collaborateurs sur un même reporting. Combien de fois a-t-on fait face à des incohérences de KPIs au bout de la 4è ou 5è application développée ?
Ici chaque développeur travaille sur sa branche, et peut, s’il a les droits nécessaires, merger ses modifications vers la production. C’est bien connu de la communauté de développeurs informatique, mais c’est une petite révolution pour le monde de la BI.
#cloud-native
C’est également un outil qui s’intègre parfaitement dans le cloud (rappelons que l’outil a été racheté par Google) et en tire tous ses avantages. Ainsi, un dashboard Looker branché sur un datamart BigQuery tirera pleinement parti de la puissance de calcul de ce dernier, offrant ainsi des capacités quasi illimitées en termes de volume de données analysées. Il n’est désormais plus interdit de calculer un agrégat sur plusieurs millions, voire milliards, de lignes.
Certaines solutions “in-memory” concurrentes, malgré tous leurs avantages, ne peuvent pas en dire autant, car elles ont souvent l’obligation de “charger” les données en mémoire avant d’effectuer des calculs. On remet donc au centre du jeu, la base de données et le SQL.
Par contre, Looker doit ainsi être obligatoirement “connecté” à la base de données pour fonctionner.
#workflow
Des solutions de rapports planifiés sont intégrées, ce qui est parfois un module très coûteux chez certains concurrents.
#connectors
Au-delà des workflow, on peut interconnecter (de manière récurrente si besoin), très simplement un dataset avec une autre solution SaaS (Marketing Automation, Google Sheets, Slack…) ou API externe (pour stopper une campagne par exemple qui ne serait pas assez rentable).
#api
Nous pourrions également parler des puissantes solutions d’APIs qui sont disponibles, et permet de développer des applications complètes (JS, App Mobiles) Data lorsque l’interface fournie par défaut n’est pas suffisante.
#realtime
Grâce à son accès direct à la base de données, Looker est capable (si la base le permet) de restituer des dashboards en temps réel, fonctionnalité que nous avions perdu avec les solutions “in-memory”.
Quelles sont toutes les compétences et expertises nécessaires pour concevoir et déployer un projet avec Looker ?
#sql
Impossible de parler de Looker sans parler de SQL!
Ce langage est véritablement au centre de l’outil et les utilisateurs aguerris de SQL sont en mesure de monter en compétence d’une manière vraiment rapide.
Et finalement, quand on fait de la data, il est assez logique voire rassurant de devoir parler SQL. A l’inverse, combien d’outils et solutions privent les équipes techniques ou métier de SQL, ce qui en devient frustrant.
Nous avons pu observer que remettre le SQL au centre des compétences permet de mieux fédérer, et faire communiquer l’ensemble de l’équipe de manière plus fluide.
Bien sûr, la connaissance de la data de l’entreprise sera également nécessaire afin d’identifier les dimensions et métriques les plus pertinentes pour le besoin métier.
Pour se former à Looker, quels types de compétences vous semblent indispensables ?
#sql
Là où Looker se démarque de ses concurrents, c’est par sa facilité d’accès à des profils moins techniques. Un Business Analyst, ou même un utilisateur métier, pourra créer ses propres dashboards avec une grande facilité, moyennant quelques formations ainsi qu’une préparation des modèles par un Data Analyst si nécessaire.
Pour les développeurs, encore une fois, il est bien entendu nécessaire d’avoir des connaissances, au moins basiques, de SQL pour pouvoir être opérationnel sur Looker.
Des connaissances basiques de git sont aussi importantes pour les ingénieurs qui travaillent en équipe.
Si vous aviez une équipe projet Looker à constituer, comment feriez-vous ?
#data_engineer
D’une manière assez classique, un ou plusieurs Data Engineer seront nécessaires pour intégrer la donnée, par exemple dans GCP. Ceux-ci peuvent être appuyés par un architecte Cloud & Data qui s’assurera du choix et du paramétrage des différents composants, et la fiabilité des choix réalisés.
#data_analyst
Une fois les données intégrées, un Data Analyst sera quant à lui responsable de construire le modèle Looker à partir des tables du ou des datamarts. Il s’assurera de la construction des dimensions et indicateurs ainsi que des restitutions associées. La principale compétence de ce profil est le SQL.
La technologie utilisée est LookML, qui permet de modéliser de manière assez simple (description utilisant un syntaxe JSon lisible et simplement documentable), les différents modèles d’accès aux données, incluant liens entre les tables, champs natifs ou calculés, agrégats et autres filtres. En effet, un seul “modèle de données” suffit rarement dans une exploitation analytique, il est important de pouvoir proposer différents points d’entrées et vues métiers sur les ensembles de données.
Enfin, un Sponsor métier validera les data et dashboards ainsi restitués, et fera la promotion de l’outil auprès de ses pairs.
Vous pouvez partager quelques conseils pour monter en expertise ? Pour réaliser des beaux projets sous Looker ?
#learning
L’outil propose un ensemble de cours en ligne très bien faits qui permettent de se lancer très rapidement sur le sujet, je recommande vivement d’effectuer les parcours de formation précautionneusement, qui peuvent se terminer par des certifications.
Nous avons par ailleurs l’occasion de collaborer systématiquement avec l’éditeur Looker qui propose en parallèle des projets que nous réalisons, une phase d’on-boarding très efficace et très appréciée des utilisateurs pour les rendre autonomes dans leur quotidien. Les équipes de support sont aussi très réactives et créatives pour résoudre les sujets qui se présentent.
Pour convaincre, réaliser un POC, sur des grands volumes de données en intégrant, le temps réel
#volume #realtime #lookml
Pour convaincre par rapport aux autres solutions, la meilleure recette consiste à réaliser un POC sur des données réelles (et en volume, grâce à BigQuery c’est un plaisir), et alimentées si possible en temps réel.
La compréhension de LookML (le cœur du produit), ainsi que les fonctions de versioning et de workflow automatisables sont impressionnantes et convainquent rapidement des utilisateurs même aguerris des solutions Data.
Si vous avez un peu de temps, n’hésitez pas à développer une UI utilisant les APIs Data du produit, vous comprendrez alors toute la puissance des solutions modernes Cloud-Natives.
