DataLake & DataWarehouse : quels usages pour le SEO ?
2021-02-16 - 14 min de lecture - par Xavier Stevens
Si les concepts de DataWarehouse et de DataLake se sont depuis bien longtemps installés dans le langage courant du Data Analyst et du Data Scientist , on commence depuis quelques années à en entendre parler dans d’autres branches.
Par exemple, les Web analysts et les experts en référencement (SEO), de par la nature de leur métier et la forte intrication qui existe entre ce dernier et la manipulation de données, commencent à se pencher sérieusement sur ces concepts. De nombreux articles récents parlent de l’intérêt de mettre en place un DataLake SEO ou un DataWarehouse SEO, sans distinction ou de manière interchangeable.
Dans cet article, nous allons vous guider pour déterminer les différences entre DataLake et DataWarehouse afin de comprendre leurs intérêts et cas d’usage pour le SEO et la Web Analyse.
La première utilisation du terme « DataWarehouse » remonte à 1988 dans un article de Paul Murphy et Barry Delvin, An architecture for a business and information systems. Ce dernier nous donne une première définition du concept comme étant un entrepôt de données relationnelles facile d’accès, rassemblant l’ensemble des données business utiles à la prise de décisions stratégiques.
Le DataWarehouse sert à regrouper à un même endroit les données business utiles à la prise de décision stratégique pour l’entreprise. On parle donc de données métier pouvant aller du référentiel client, aux informations de stocks, en passant par les conversions d’un site marchand ou encore les visites SEO (provenant d’un moteur de recherche tel que Google par exemple).
Il est communément admis que les données envoyées dans un DataWarehouse sont des données structurées, prétraitées servant à décharger les bases de données opérationnelles et donc in fine, de les solliciter le moins possible à des fins de requêtes.
L’enjeu principal du DataWarehouse et de ceux qui l’administrent est donc de compiler des données de sources diverses (internes comme externes), hétérogènes, à des fins d’harmonisation pour qu’elles puissent communiquer entre elles. L’objectif final étant de se servir de cette data pour réaliser des analyses, du reporting, de l’aide à la décision, etc.
De par la nature du DataWarehouse, le format et le type de données qu’il contient, c’est un terrain de jeu tout trouvé pour les Data et les Web analysts.
Le Data Analyst travaille avec l’administrateur (ou l’équipe d’administration) du DataWarehouse. Ils définissent les besoins métier et les cas d’usages. Ils identifient les sources de données et les actions nécessaires pour traiter en amont les données qui seront ensuite utilisées en bout de chaîne par les Data Analysts.
Une fois les sources identifiées, les données traitées, ingérées et mises en relation dans le DataWarehouse, le Data Analyst peut ensuite s’en servir pour analyser, créer de nouvelles combinaisons de données. Ces dernières pouvant ensuite servir à alimenter des dashboards de reporting, d’alerting, etc.
Le langage de programmation le plus communément utilisé pour requêter dans un DataWarehouse reste le SQL (ou SQL like). Il permet aux data analysts de manipuler et traiter la donnée dans le but de répondre aux besoins métiers : monitoring, prise de décision stratégique, etc.
Il est impossible de dresser une liste exhaustive des cas d’usage impliquant l’utilisation d’un DataWarehouse. Cependant, voici quelques exemples de projets sur lesquels un data analyst est susceptible de travailler :
Amélioration d’un DataWarehouse :
On rencontre souvent ce type de projets lors de la mise en place d’un DataWarehouse, mais aussi lorsqu’un nouveau besoin ou cas d’usage métier est identifié.
Il s’agit ici d’ajouter de nouvelles données à un DWH (encore une fois, il peut s’agir de données internes comme de données externes).
Dans ce cas-là on parle souvent d’un processus de type ETL (Extraction—Transformation—Loading) :
Réalisation d’analyses statistiques :
C’est un cas très fréquent d’usage de DWH. L’objectif peut être d’établir, par l’entremise de la donnée, un constat x ou y, de réaliser des statistiques en se basant sur la donnée historique à disposition, ou encore, d’établir des liens de causes à effet pour expliquer un constat, etc.
Reporting & alerting :
C’est, là encore, un cas d’usage très fréquent. En effet, dans la mesure où les données présentes dans un DWH sont très structurées et formatées (même schéma figé et prédéfini), elles sont toutes indiquées pour alimenter des dashboards de reporting ou à l’alerting.
C’est une demande récurrente du top management qui a besoin de pouvoir suivre les équipes opérationnelles, la bonne santé des résultats, des ventes, etc. de la manière la plus simple et la plus rapide possible.
Si on résume le tout, on tombe plus ou moins sur 2 types de projets : des projets d’acquisition et d’intégration de données (que l’on peut également mettre en face d’une forme de stockage et d’historisation de la data) ainsi que des projets d’analyse et d’évaluation de la donnée (par l’entremise du monitoring/dashboarding et de l’alerting).
Le concept de DWH, est présent depuis longtemps dans le langage courant de ceux qui travaillent dans la data. Son fonctionnement et ses nombreux cas d’usage ont depuis longtemps été éprouvés et on en retrouve dans beaucoup d’entreprises, plus ou moins matures sur les problématiques data.
C’est moins le cas du concept de DataLake, beaucoup plus jeune et beaucoup moins répandu.
La parenté de ce concept est attribuée à James Dixon, CTO (chief technical officer) de Penthao qui le définit comme une solution de stockage et d’exploitation de gros volumes de données, sans prétraitements et sans forcément de cas d’usage déterminé… À l’inverse du DWH qui est très orienté vers l’activation immédiate.
Le DL essaie de saisir une opportunité, de plus en plus importante avec l’émergence du BigData : que faire de toute cette masse de données que nous sommes aujourd’hui capables de récolter et comment en tirer un profit, une valeur ajoutée?
Je commencerai par citer James Dixon qui utilise une comparaison très justement trouvée, servant à la fois d’explication à l’appellation « lake » de son concept et de différenciation avec le DWH :
« Comparons un entrepôt de données à un entrepôt d’eau en bouteille. L’eau qui s’y trouve est traitée, conditionnée et structurée pour être consommée plus facilement. Le contenu du lac de données s’apparente quant à lui à un lac depuis lequel divers usagers peuvent faire des observations, y plonger ou y prélever des échantillons. »
Cette citation illustre parfaitement la différence entre le type de données contenues dans un DWH, structurées et organisées en tables avec des schémas précis, figés et le type de données contenues dans un DataLake, brutes, sans traitement préalable, disponibles pour en prélever des échantillons selon le besoin, qu’il soit exploratoire ou non.
Là où le DWH est cantonné à accueillir des données structurées, le DataLake est fait pour stocker toutes sortes de données brutes (structurées ou non). Un débat entre Tamara Dull (Amazon Web Service) et Anne Buff (Microsoft SAS), nous donne une vision un peu plus concrète du contenu d’un DataLake:
«Un lac de données est un dépôt de stockage qui contient une vaste quantité de données brutes dans leur format d’origine, y compris des données structurées, semi-structurées et non structurées. La structure des données et les exigences ne sont pas définies tant que les données ne sont pas requises.»
Là ou un Data Analyst était tout indiqué pour travailler avec la donnée structurée contenue dans les DHW, les données brutes sont plutôt la spécialité des data scientists, souvent mieux armés pour manipuler ce type de data.
Ce changement de profil de données et d’utilisateur principal se traduit également par des langages de programmation et des cas d’usages différents.
De par sa nature peu structurée et le volume considérable de données que peut contenir le DataLake, les cas d’usages peuvent être très différents de ceux que l’on pouvait trouver précédemment dans le cadre du DWH, par exemple :
Compte tenu des cas d’usage et des utilisateurs (Data Scientists), on retrouve très souvent des langages de programmation tels que Python, Java, R, Scala, etc.
Pour la plupart, ces langages sont depuis longtemps installés dans le domaine de la data science.
Le DataLake est donc un outil de gestion du BigData. Il s’appuie sur le stockage massif de données brutes à des fins d’analyses poussées et de visualisations avancées permettant ainsi une mise en valeur de données jusqu’alors peu exploitées.
Pour résumer, voici un tableau récapitulatif des éléments différenciants établis depuis le début de cet article:
| DataWarehouse | DataLake | |
|---|---|---|
| Type de data | De la donnée structurée, prétraitée, organisée en table avec des schémas définis | Donnée brute, stockée de manière structurée ou non |
| Utilisateurs | Data Analysts, Web Analysts | Data Scientists (parfois des Data Analysts) |
| Volumétrie de données | Petite — Grande (Selon le besoin et le cas d’usage) |
Potentiellement très grand (Big Data) |
| Langage de programmation utilisé | SQL ou SQL like | Python, R, Java, Scala, entre autres |
| Type de projet | Projets analytiques & statistiques, Reporting, Alerting, projet de type ELT (export, transform, load), un peu de prédictif et d’analyses augmentées par la data | Analyse prédictive, machine learning, zone de transit entre les sources de données et le DWH, visualisation avancée – BI, analyses augmentées par la data |
Ce sont ces différences qui font de ces deux concepts, des outils complémentaires. Dans bien des cas en entreprise d’ailleurs, dépendamment de la maturité de sa gouvernance et de sa gestion de la donnée, on observe une combinaison de ces deux outils.
Le DWH servant principalement pour le reporting et les analyses classiques, là où le DataLake sert de source de données avant de révéler tout son potentiel à mesure que l’entreprise se rapproche de sa maturité sur les sujets data.
Le DataLake constitue selon moi davantage une réponse aux nouveaux enjeux data de ce siècle, (notamment avec l’émergence du BigData et la capacité toujours plus grande des entreprises à récolter de la donnée) qu’un remplaçant du DWH comme certains pourraient le penser.
L’un comme l’autre a ses avantages, ses inconvénients, ses points forts et ses points faibles. Le meilleur moyen de tirer le meilleur parti des deux reste encore d’utiliser conjointement l’un et l’autre pour pouvoir faire face à toute éventualité et adresser une plus grande variété de besoins.
Après cette redéfinition des concepts, nous allons enfin nous focaliser sur l’usage du DataWarehouse et du DataLake pour le marketing et plus particulièrement pour le SEO (même si dans beaucoup de cas, ce qui vaut pour le premier, vaudra pour l’autre, et vice versa).
On va donc parler ici d’un DataWarehouse ou d’un DataLake (voire les deux) dont au moins une partie de la donnée présente peut servir pour des cas d’usages SEO.
Le SEO (et le marketing de façon plus générale) a d’ores et déjà pris un virage data très marqué ces dernières années. De plus en plus de tâches nécessitent l’utilisation de diverses sources de données:
Auxquelles s’ajoute la manipulation d’API comme celle de la Search Console, de Majestic, de Google Analytics par exemple, qui nous pousse naturellement vers le genre de solutions décrites plus haut dans cet article.
C’est cette forte intrication entre SEO et Data qui pousse de plus en plus les Web Analysts et les experts SEO à se renseigner sur de nouveaux moyens d’organiser leur pipeline data.
Cependant, les moteurs vers cette transition ne résident pas uniquement dans une question de potentiel et d’intrication SEO — Data. De nombreux cas d’usage quotidiens trouvent un écho avec les typologies de projets listés précédemment pour le DWH et le DL.
Je vais d’abord partir de pain points (points bloquants) communément rencontrés par les experts SEO avant d’expliquer en quoi l’utilisation d’un DataLake ou d’un DataWarehouse est une réponse à considérer pour les adresser.
Parmi les principaux pain points, on constate notamment :
C’est là encore une liste non exhaustive de pain points et de cas d’usage possibles pour un DataWarehouse — DataLake SEO. Les limites se trouvant plus dans le manque d’imagination de ceux qui les utilisent que dans les outils eux-mêmes.
En définitive, contrairement à ce qu’on peut souvent entendre ou lire, DataWarehouse et DataLake ne sont pas incompatibles. Rien n’oblige à en choisir un plutôt que l’autre, bien au contraire. Les deux ont des cas d’usages différents et il existe même quelques adhérences.
Le cas du SEO est très parlant et va dans ce sens. C’est un secteur d’activité où la data est omniprésente, où on est amené à manipuler d’énormes quantités de données de sources différentes. Ce n’est donc pas étonnant qu’on parle de DataWarehouse et de DataLake dans ce contexte. On peut imaginer énormément de cas d’usages de DataWarehouse ou de DataLake dans le SEO, que ce soit à des fins d’automatisation, de réalisation d’analyses “augmentées” par la data ou simplement pour solutionner des problèmes récurrents (pain points).
