DataLake & DataWarehouse : quels usages pour le SEO ?

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.

DataWarehouse, entrepôt de données structurées

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.

Quel est le contenu d’un DataWarehouse?

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.

Qui utilise le DataWarehouse au quotidien ?

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.

Comment communiquer avec un DataWarehouse ?

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.

Pour quels cas d’usage, quelles typologies de projets ?

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) :

• Extraction :
  Une première étape consiste à identifier et collecter les données des diverses sources nécessaires pour la suite des opérations.
• Transformation :
  Cette seconde étape est très importante, car sans ajustement, sans harmonisation, il est généralement impossible d’utiliser de nouvelles données et de les faire communiquer à celles déjà existantes dans le DWH.
  C’est donc une phase d’uniformisation nécessaire qui peut parfois rencontrer des frictions avec la rigidité qu’impose le DWH en termes de formatage et de schéma de table.
• Loading (Chargement – Ingestion):
  Phase d’ingestion des données traitées (et donc structurées) dans le DWH.

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.

DataLake, le lac de mégadonnées (BigData)

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?

Quel est le contenu d’un DataLake ?

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.»

Qui utilise le DataLake au quotidien ?

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.

Pour quels cas d’usages, quelles typologies de projets ?

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 :

• La mise en application d’algorithmes de machine learning pour créer une valeur ajoutée au BigData :
  On parle donc souvent ici d’analyses prédictives, se basant sur des algorithmes de machines learning exploitant toutes sortes de données.
  Pour prendre un exemple plus concret, imaginons qu’une entreprise du secteur financier (banque & assurance) veuille déterminer, la probabilité qu’une transaction financière x soit frauduleuse. Cette dernière peut faire appel à des data scientists, capables de créer des algorithmes de machine learning qui vont s’entraîner sur la quantité astronomique de données contenue dans le DataLake (montant, date, fréquence, profil habituel de transactions réalisées par le propriétaire du compte, etc.). L’objectif étant de réaliser une étude prédictive qui servira à identifier les transactions potentiellement frauduleuses et ainsi permettre à l’entreprise de réduire son temps de réaction quant à leur détection et in fine, éviter de grosses pertes pour eux et pour leurs clients.
  C’est un exemple simple et qui sert régulièrement à illustrer l’intérêt et la valeur ajoutée du machine learning, mais il en existe autant d’autres qu’il est possible d’en imaginer.
• Le DataLake comme source de donnée pour le DataWarehouse :
  Très simplement, un DataLake peut faire office de zone de transit entre vos différentes sources de données internes et externes et votre DWH. Le principe même d’un DataLake et de centraliser toutes sortes de données, structurées ou non afin de réaliser des études prédictives via ML, ou encore à des fins d’extractions sous forme d’échantillons pour des analyses. Le DWH semble donc tout indiqué pour cette seconde catégorie de projet et profite très bien du DataLake comme source potentielle (pour peu que les données du DataLake soient importées de façon structurée via un prétraitement si nécessaire).
• Du DataLake aux logiciels de BI (Business Intelligence) :
  On peut voir ça comme un usage proche du DataWarehouse, tout en conservant certaines spécificités. Le DataLake va permettre de faire des visualisations un peu plus exotiques (de par la variété des datas qu’il contient), via des outils tels que Tableau, Qlikview, Google Data Studio, Microstrategy, etc.

Comment communiquer avec un DataLake ?

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:

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).

DataWarehouse et DataLake SEO

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.

Pourquoi rapprocher DataLake et DataWarehouse au Marketing et au 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:

• Des données analytiques (Google Analytics, AT internet, etc.)
• Des données de performance (Google Search Console, Analytics)
• Des données de logs, une « source » de données très conséquente pour certains sites, qui nécessite une haute fréquence de mise à jour et une grande capacité de stockage.
• Des données de Netlinking (Majestic, Ahrefs, Babbar)
• Des données de positionnement (SemRush, Monitorank, MyPoseo, Ranks.fr, etc.)
• Des données de crawl (Oncrawl, etc.)
• Parfois des données métier/terrain également

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.

Les cas d’usage d’un DataWarehouse SEO ou d’un DataLake SEO

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 :

• La multiplication de fichiers Excel (les feuilles volantes de notre décennie) et les copier/coller qui vont avec :
  Pour beaucoup de SEO c’est encore la norme, mais soyons honnête, c’est à la fois chronophage, contraignant et très propice aux erreurs humaines.Pour ce genre de cas, le DataWarehouse est une solution tout indiquée. Ce dernier permet en effet de regrouper, parmi les diverses sources de données disponibles, l’ensemble des KPIs nécessaires pour réaliser tels ou tels audits/analyses, mais aussi, d’automatiser l’ensemble des traitements nécessaire pour arriver au résultat attendu.
  Au fur et à mesure de la construction d’un DataWarehouse, de plus en plus de cas d’usage sont identifiés, de plus en plus de problématiques résolues, induisant un gain de temps de plus en plus important au fil du temps.
• Les limites de capacité (pour rappel, Excel ne peut ouvrir un fichier en entier que si ce dernier n’excède pas 1 048 576 lignes. Ça semble beaucoup, mais finalement pas tant que ça…) :Il n’y a pas vraiment de cas d’usage particulier ici. En général, le DataLake comme le DataWarehouse, ne souffrent pas de ce genre de limites. Ils offrent tous les deux le moyen de requêter de gros volumes de données pour tout type de besoin. Pour ce cas précis, il faut plutôt garder en tête que selon le besoin, l’un ou l’autre vous permettra de vous affranchir des limites de capacités et donc in fine, d’y répondre plus facilement.
• Répondre à un besoin d’historisation de la donnée
  Spoiler, un des uses cases peut être par exemple d’historiser les données de la Search Console dans un DataWarehouse SEO, plutôt que de copier/coller ses données toutes les semaines dans un Google Sheets pour son dashboard Data Studio.Nous avons selon moi ici, l’un des cas d’usage le plus communément répandu chez les experts SEO, qu’ils soient en agence ou chez l’annonceur, l’historisation de données. En effet, beaucoup d’analystes SEO regardent l’historique de données et se basent dessus pour en tirer des conclusions.
  Celui qui vous est peut-être venu en tête directement, c’est le cas de la Google Search Console. Cette dernière ne donne accès qu’à 16 mois d’historique aujourd’hui (même via API). Et si une historisation manuelle reste possible via des exports à coller dans Google Sheets toutes les semaines (ou autres obscures méthodes), cela entraîne une perte de temps considérable en plus d’être pénible et rébarbatif.
  Ça tombe bien, car c’est un problème relativement simple à adresser avec un DataWarehouse. Il suffit de paramétrer une connexion automatique à l’API de la Google Search Console, de définir les différents prétraitements éventuels ainsi que les combinaisons de données nécessaires pour obtenir une donnée avec une vraie valeur ajoutée et enfin, d’automatiser les appels API.
• La volonté d’aller plus loin dans l’analyse, de croiser des données de crawl, d’audience, de logs, etc. de façon industrielle.
  Parce qu’un petit avantage concurrentiel ne fait jamais de mal.Les descriptions que nous avons faites d’un DataWarehouse et d’un DataLake parlent d’elles-mêmes ici. L’un des buts premiers de ces deux outils est d’ouvrir de nouvelles possibilités d’analyse, par l’entremise de la collecte et du croisement de données et/ou du machine learning.
  Pour ne garder qu’un seul exemple assez représentatif ; l’utilisation d’algorithmes de machine learning tels que Random Forest ou XG-Boost afin de faire de la prédiction de ranking sur Google.
  Très simplement, le principe est d’entraîner un algorithme sur un grand nombre de SERPs (pages de résultats) Google et toutes les métriques SEO récoltables pour ces SERPs afin de déterminer en fonction de ces mêmes critères, le potentiel de ranking d’une URL donnée (et donc a fortiori, de déterminer les critères les plus importants sur un secteur/thématique particulière).
  → Vous retrouverez la méthodologie complète dans l’article de Vincent Terrasi, ancien Directeur Produit chez Oncrawl « Successfully predicting Google rankings at the cutting edge of data science », 2018
• La volonté d’automatiser au maximum le reporting, pour se concentrer sur les tâches à forte valeur ajoutéeCela tombe là encore, littéralement dans les cas d’usage classiques d’un DataWarehouse. Ce dernier offrant la possibilité d’automatiser toute la partie récupération et traitement des différentes sources de données, il adresse parfaitement ce pain point. Une fois mis en place, une table sera alimentée automatiquement dans le DWH et pourra servir de connexion à un logiciel de BI pour du Dashboarding de monitoring, d’alerting, etc.L’automatisation ne s’arrête bien évidemment pas aux seuls projets de reporting. Le DWH comme le DL peuvent être utilisés pour beaucoup d’optimisations SEO automatisées. Par exemple, la mise à jour de bloc de maillage dynamique en fonction de la position, du budget crawl, de l’audience SEO etc. (données contenues dans le DWH).
• La volonté d’en finir une bonne fois pour toutes avec les soucis de sécurité (on sait qui a fait quoi et où le retrouver) et d’éviter de passer du temps sur de la maintenance.Nous terminons ici sur un aspect plus process que cas d’usage à proprement parler.
  Le DataLake comme le DataWarehouse impliquent la mise en place de process particuliers que l’on pourrait simplifier de la manière suivante:
  • On part d’un constat que l’on décline en une expression de besoin (équipe métier / SEO – Data Analyst)
  • Cette dernière se transforme ensuite en spécification plus technique qui va permettre aux équipes administrant l’outil de comprendre ce qui doit être fait et comment cela doit être fait.
  • Cette même équipe d’administration réalise la demande.
  • Les équipes métiers et les Data Analysts réalisent une recette du travail effectué.
  • Subsiste alors de l’on-going dans lequel les deux bouts de chaînes (les équipes métier et les équipes d’administration du DataWarehouse ou du DataLake) s’assurent que rien ne bouge en termes de mode d’ingestion et d’output.
    C’est notamment le cas pour un DWH, qui rejettera toutes données ne faisant pas partie de la structure, du schéma défini préalablement.

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.

Choisir entre DataLake et DataWarehouse pour votre SEO

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).