DataLakes & DataWarehouses : leur utilisation en SEO

Bien que les concepts de DataWarehouses et de DataLakes fassent depuis longtemps partie du langage courant des Data Analysts et des Data Scientists, nous n'en entendons parler dans d'autres industries que depuis quelques années.
Par exemple, les analystes Web et les experts en référencement commencent à se pencher sérieusement sur ces concepts, en raison de la nature de leur travail et du lien étroit qui existe entre ce qu'ils font et la manipulation des données. De nombreux articles récents parlent de l'intérêt de mettre en place un SEO DataLake ou un SEO DataWarehouse, en traitant les deux termes comme interchangeables et sans faire de distinction entre les deux.

Dans cet article, nous allons vous guider dans la détermination des différences entre DataLakes et DataWarehouses afin de comprendre leurs finalités et leurs cas d'utilisation en SEO et web analytics.

DataWarehouse : entrepôt structuré pour les donné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 . Cet article nous donne une première définition du concept comme un environnement de bases de données relationnelles facile d'accès, regroupant toutes les données métiers utiles à la prise de décision stratégique.

Que contient un DataWarehouse ?

Le DataWarehouse permet de rassembler en un seul endroit les données métiers utiles à la prise de décision stratégique de l'entreprise. Nous parlons de données commerciales qui peuvent couvrir n'importe quoi, des données clients aux informations d'inventaire, en passant par les conversions sur un site Web commercial ou les visites organiques (à partir d'un moteur de recherche tel que Google par exemple).

Il est communément admis que les données envoyées à un DataWarehouse sont des données structurées et prétraitées utilisées pour décharger des bases de données opérationnelles, ce qui permet in fine de solliciter le moins possible ces bases de données opérationnelles à des fins d'interrogation.
L'objectif principal d'un DataWarehouse et de ceux qui l'administrent est de compiler des données provenant de diverses sources hétérogènes (internes et externes) afin de les standardiser afin que les différentes sources puissent communiquer entre elles. L'objectif final est d'utiliser ces données pour réaliser des analyses, des reportings, des aides à la décision, etc.

Qui sont les utilisateurs quotidiens d'un DataWarehouse ?

En raison de la nature du DataWarehouse et du format et du type de données qu'il contient, c'est un terrain de jeu idéal pour les analystes de données et Web.
Les analystes de données travaillent aux côtés de l'administrateur DataWarehouse (ou de l'équipe d'administration). Ils définissent les besoins métiers et les cas d'utilisation. Ils identifient les sources de données et les actions nécessaires pour traiter les données en amont. Ces données seront ensuite exploitées par les Data Analysts en bout de chaîne.

Comment les utilisateurs communiquent-ils avec un DataWarehouse ?

Une fois les sources de données identifiées et les données traitées, ingérées et liées dans le DataWarehouse, le Data Analyst peut utiliser ces données dans des analyses et créer de nouvelles combinaisons de données. Ce processus peut être utilisé pour maintenir des tableaux de bord de reporting, des tableaux de bord d'alerte, etc.

Le langage de programmation le plus couramment utilisé pour interroger dans un DataWarehouse est SQL (ou langages de type SQL). SQL permet aux Data Analysts de manipuler et de traiter les données afin de répondre aux besoins métiers : veille, prise de décision stratégique, etc.

Quels cas d'utilisation et types de projets les DataWarehouses servent-ils ?

Il est impossible de dresser une liste exhaustive des cas d'utilisation 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 :
Ce type de projet est souvent rencontré 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 (là encore, il peut s'agir de données internes ou externes).
Dans ce cas on parle souvent de processus ETL (Extraction-Transformation-Chargement) :

• Extraction:
  Une première étape consistant à identifier et collecter les données auprès des différentes sources nécessaires à la suite des opérations.
• Transformation:
  Cette deuxième étape est très importante, car sans ajustement, sans normalisation, il est généralement impossible d'utiliser de nouvelles données et de les faire communiquer avec celles déjà existantes dans le DWH.
  Il s'agit donc d'une phase de normalisation nécessaire qui peut parfois être compliquée par la rigidité imposée par le DWH en termes de formatage et de schéma de table.
• Chargement:
  Phase d'ingestion des données traitées (et donc structurées) dans le DWH.

Réalisation d'analyses statistiques :
Il s'agit d'une utilisation très fréquente des DWH. Le but peut être de prouver X ou Y à travers les données, de produire des statistiques basées sur les données historiques disponibles, ou d'établir des liens de causalité pour expliquer un résultat, etc.
Rapports et alertes :
C'est, encore une fois, un cas d'utilisation très fréquent. En effet, comme les données d'un DWH sont très structurées et formatées (partageant un schéma fixe et prédéfini), tout est adapté pour pousser les données vers des tableaux de bord de reporting ou d'alerte.

C'est une demande récurrente du top management, qui doit pouvoir suivre les équipes opérationnelles et la santé des résultats, des ventes, etc. de la manière la plus simple et la plus rapide possible.

Si nous résumons tout cela, nous avons plus ou moins 2 types de projets : des projets d'acquisition et d'intégration de données (qui peuvent également être assimilés à une forme de stockage et d'historisation de données) et des projets d'analyse et d'évaluation de données (via le suivi/tableau de bord et l'alerte ).

Le concept de DWH est présent depuis longtemps dans le langage courant de ceux qui travaillent avec des données. Son fonctionnement et ses nombreux cas d'usage sont confirmés depuis longtemps, et les DWH se retrouvent dans de nombreuses entreprises plus ou moins matures sur les questions de gestion des données.

C'est moins le cas pour le concept de DataLakes, beaucoup plus jeune et beaucoup moins répandu.

Oncrawl Data³

Développez votre analyse avec des connexions transparentes à des ensembles de données supplémentaires. Analysez votre stratégie de référencement en fonction des données sur les backlinks, le trafic SEO, les classements et les ensembles de données personnalisés de votre CRM, de votre solution de surveillance ou de toute autre source.

Apprendre encore plus

DataLake : lac de mégadonnées (BigData)

L'origine de ce concept est attribuée à James Dixon, CTO de Penthao, qui le définit comme une solution de stockage et d'exploitation de gros volumes de données, sans pré-traitement et sans forcément de cas d'usage précis… Contrairement aux DWH, qui sont très orientés vers une activation immédiate.
Le DL tente de combler le vide, de plus en plus important avec l'émergence du BigData, de savoir quoi faire de toute cette masse de données que nous sommes capables de collecter aujourd'hui et comment en tirer parti.

Que contient un DataLake ?

Je commencerai par citer James Dixon qui utilise une comparaison très évocatrice, servant à la fois d'explication au nom « lac » de son concept et de différenciation avec le DWH :

« Si vous considérez un datamart comme un magasin d'eau en bouteille - nettoyée, conditionnée et structurée pour une consommation facile - le lac de données est une grande masse d'eau dans un état plus naturel. Le contenu du lac de données provient d'une source pour remplir le lac, et divers utilisateurs du lac peuvent venir examiner, plonger ou prélever des échantillons.

Cette citation illustre parfaitement la différence entre le type de données contenues dans un DWH, qui sont structurées et organisées dans des tableaux aux motifs précis et figés, et le type de données contenues dans un DataLake, qui sont brutes, sans traitement préalable, disponibles pour prendre des échantillons au besoin, qu'ils soient exploratoires ou non.

Là où un DWH est restreint pour 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 référentiel de stockage qui contient une grande quantité de données brutes dans son format natif, y compris des données structurées, semi-structurées et non structurées. La structure et les exigences des données ne sont pas définies tant que les données ne sont pas nécessaires. »

Qui sont les utilisateurs quotidiens de DataLakes ?

Là où un Data Analyst était parfaitement apte à travailler avec les données structurées contenues dans un ECS, les données brutes sont plutôt la spécialité des Data Scientists, souvent mieux armés pour manipuler ce type de données.
Ce changement de profil de données et d'utilisateur principal se traduit également par des langages de programmation et des cas d'utilisation différents.

Quels cas d'utilisation et types de projets les DataLakes servent-ils ?

Du fait de sa nature non structurée et du volume considérable de données que peut contenir un DataLake, les cas d'usage peuvent être très différents de ceux rencontrés précédemment dans le framework DWH, par exemple :

• La mise en place d'algorithmes de machine learning pour créer de la valeur ajoutée pour le BigData :
  On parle souvent ici d'analyse prédictive, basée sur des algorithmes de machine learning exploitant toutes sortes de données.
  Pour prendre un exemple plus concret, imaginons qu'une entreprise du secteur financier (banque & assurance) souhaite déterminer la probabilité qu'une transaction financière X soit frauduleuse. Cela peut faire appel à des Data Scientists, capables de créer des algorithmes de machine learning qui s'entraîneront sur la quantité astronomique de données contenues dans le DataLake (montant, date, fréquence, profil habituel des transactions effectuées par le titulaire du compte, etc.). L'objectif est 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 pour les détecter et in fine éviter de grosses pertes pour eux et leurs clients.
  C'est un exemple simple qui est régulièrement utilisé pour illustrer l'intérêt et la valeur ajoutée du machine learning, mais il en existe autant d'autres que vous pouvez l'imaginer.
• DataLakes comme source de données pour un DataWarehouse :
  Très simplement, un DataLake peut servir 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 est de centraliser toutes sortes de données, structurées ou non, afin de réaliser des études prédictives via ML, ou d'en extraire sous forme d'échantillons pour analyse. Le DWH semble donc très adapté à cette deuxième catégorie de projet et bénéficie d'un DataLake comme source potentielle (à condition que les données DataLake soient importées de manière structurée via des pré-traitements, si nécessaire).
• Du DataLake au logiciel BI (Business Intelligence) :
  On peut voir cela comme une utilisation similaire à celle que nous avons vue avec les DataWarehouses, bien qu'il y ait certaines spécificités à utiliser un DataLake à cette fin. Un DataLake vous permettra de faire des visualisations un peu plus exotiques (du fait de la variété des données qu'il contient), via des outils comme Tableau, Qlikview, Google Data Studio, Microstrategy, etc.

Comment les utilisateurs communiquent-ils avec un DataLake ?

Compte tenu des cas d’usage et des utilisateurs (Data Scientists), on retrouvera très souvent des langages de programmation comme Python, Java, R, Scala, etc…
Pour la plupart, ces langages sont présents depuis longtemps dans le domaine de la science des données.

Un DataLake est donc un outil de gestion du BigData. Il s'appuie sur le stockage massif de données brutes à des fins d'analyse et de visualisation avancées, permettant ainsi la valorisation de données jusqu'alors peu exploitées.

Pour résumer, voici un tableau des éléments différenciateurs établis depuis le début de cet article :

Analyse prédictive, machine learning, zone de transit entre data sources et DWH, visualisation avancée – BI, data-driven analysis

Ce sont ces différences qui font de ces deux concepts des outils complémentaires. Dans de nombreux cas, selon la maturité de la gouvernance et de la gestion des données d'une entreprise, ils peuvent s'appuyer sur une combinaison de ces deux outils.
Un DWH est principalement utilisé pour le reporting et l'analyse traditionnels, tandis qu'un DataLake sert de source de données avant d'atteindre son plein potentiel à mesure que l'entreprise approche de la maturité sur les sujets de données.

Selon moi, les DataLakes sont plus une réponse aux nouveaux enjeux data du 21e siècle, notamment avec l'émergence du BigData et la capacité croissante des entreprises à collecter des données, qu'un substitut aux DWH, comme certains pourraient le penser.
Les deux ont leurs avantages, leurs inconvénients, leurs forces et leurs faiblesses. La meilleure façon de tirer le meilleur parti des deux est encore de les utiliser ensemble pour pouvoir faire face à toute éventualité et répondre à une plus grande variété de besoins.

Maintenant que nous avons clairement défini les concepts, nous allons enfin nous concentrer sur l'utilisation des DataWarehouses et des DataLakes pour le marketing et plus spécifiquement pour le SEO (même si dans bien des cas, ce qui est vrai pour le premier sera vrai pour le second, et vice versa versa).

DataWarehouse et DataLake SEO

On parlera ici d'un DataWarehouse ou d'un DataLake (ou les deux) où au moins une partie des données présentes peuvent être utilisées pour des cas d'usage SEO.

Pourquoi associer DataLakes et DataWarehouses au Marketing et au SEO ?

Le SEO (et plus généralement le marketing) a déjà pris un virage très marqué vers la data ces dernières années. De plus en plus de tâches nécessitent l'utilisation de diverses sources de données :

• Données analytiques (Google Analytics, AT internet, etc.)
• Données de performance (Google Search Console, Analytics)
• Les données de logs, une « source » de données très importante pour certains sites, qui nécessite une fréquence de mise à jour élevée et une capacité de stockage importante.
• Données de netlinking (Majestic, Ahrefs, Babbar)
• Données de positionnement (SEMRush, Monitorank, etc.)
• Données de crawl (OnCrawl, etc.)
• Parfois aussi des données commerciales/industrielles

A cette liste, il faut aussi ajouter l'utilisation d'API d'outils tels que Search Console, Majestic, Google Analytics par exemple, ce qui nous pousse naturellement vers le genre de solutions décrites plus haut dans cet article.
C'est ce lien fort entre SEO et Data qui pousse de plus en plus d'analystes Web et d'experts SEO à découvrir de nouvelles façons d'organiser leur pipeline de données.

Cependant, les moteurs de cette transition ne concernent pas seulement le potentiel et l'interdépendance du référencement et des données. De nombreux cas d'utilisation quotidiens correspondent aux types de projets répertoriés ci-dessus pour les DWH et les DL.

Les cas d'utilisation d'un SEO DataWarehouse ou d'un SEO DataLake.

Je partirai d'abord des points douloureux couramment 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 aborder.
Parmi les principaux points douloureux, les suivants se distinguent :

• La multiplication des fichiers Excel (le papier à feuilles mobiles de notre décennie) et les copier-coller associés :
  Pour beaucoup de SEO c'est encore la norme, mais soyons honnêtes, c'est à la fois chronophage, contraignant et très propice à l'erreur humaine. Pour cela, un DataWarehouse est une solution parfaite. Les DataWarehouses permettent non seulement de rassembler tous les KPI nécessaires à la réalisation de tel ou tel audit/analyse à partir des différentes sources de données disponibles, mais aussi d'automatiser les traitements nécessaires à l'obtention du résultat attendu.
  Au fur et à mesure de la construction d'un DataWarehouse, de plus en plus de cas d'utilisation sont identifiés et de plus en plus de problèmes sont résolus, entraînant dans le temps des gains de temps de plus en plus importants.
• Limites de capacité (pour rappel, Excel ne peut ouvrir un fichier entier que s'il ne dépasse pas 1 048 576 lignes. Cela semble beaucoup, mais ce n'est pas tant que ça dans les volumes d'aujourd'hui) : Il n'y a pas vraiment de cas d'utilisation particulier ici, car dans En général, les DataLakes et les DataWarehouses ne souffrent pas de ce type de limite. Ils offrent tous les deux le moyen de demander de gros volumes de données pour tout type de besoin. Pour ce cas précis, il est important de garder à l'esprit que, selon le besoin, l'un ou l'autre vous permettra de vous affranchir des limites de capacité et, in fine, d'aborder plus facilement ces situations.
• Répondre à un besoin d'historisation des données
  Spoiler : un des cas d'usage peut être, par exemple, de sauvegarder un historique des données de Google Search Console dans un SEO DataWarehouse, plutôt que de copier et paginer ses données dans un Google Sheets chaque semaine pour maintenir un tableau de bord Data Studio. A mon avis, on a là un des cas d'usage les plus courants chez les Experts SEO, que ce soit en agence ou en interne : l'historisation des données. En effet, de nombreux analystes SEO examinent les données historiques et en tirent des conclusions.
  L'exemple qui vous vient directement à l'esprit est le cas de Google Search Console. Il ne donne accès qu'à 16 mois d'historique aujourd'hui (même via API). Et si un backlog manuel reste possible via des exports à coller dans Google Sheets toutes les semaines (ou autres méthodes obscures), c'est une perte de temps considérable en plus d'être pénible et ennuyeuse.
  C'est une bonne chose car c'est un problème relativement simple à résoudre avec un DataWarehouse. Il suffit de mettre en place une connexion automatique à l'API Google Search Console, de définir les différentes combinaisons possibles de prétraitements et de données nécessaires pour obtenir des données à réelle valeur ajoutée, et enfin, d'automatiser les appels API.
• La volonté d'aller plus loin dans les analyses, de fusionner ou « cross-analyze » les données de crawl, les données d'audience, les logs, etc. de manière industrialisée.
  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 principaux objectifs des deux outils est d'ouvrir de nouvelles possibilités d'analyse, par la collecte de données et l'analyse croisée et/ou l'apprentissage automatique.
  Pour ne citer qu'un exemple très représentatif ; l'utilisation d'algorithmes d'apprentissage automatique tels que Random Forest ou XG-Boost pour faire des prédictions de classement sur Google.
  Très simplement, l'idée est d'entraîner un algorithme sur un grand nombre de SERP (pages de résultats) Google et toutes les métriques SEO récoltables pour ces SERP afin de déterminer, à partir de ces mêmes métriques, le potentiel de classement d'une URL donnée (et donc, encore plus particulièrement, pour déterminer les métriques les plus importantes à classer dans un secteur/thème particulier).
  → Vous trouverez la méthodologie complète dans l'article de Vincent Terrasi, Product Director chez Oncrawl, "Successfully predicting Google rankings at the cutting edge of data science" , 2018.
• La volonté d'automatiser au maximum le reporting, afin de se concentrer sur des tâches à forte valeur ajoutée. Là encore, cela rentre littéralement dans les cas d'usage classiques d'un DataWarehouse. Il offre la possibilité d'automatiser l'intégralité de la récupération et du traitement des différentes sources de données, et il répond parfaitement à ce point douloureux. Une fois mise en place, une table sera automatiquement alimentée dans le DWH et pourra servir de connexion à un logiciel de BI pour le tableau de bord, que ce soit pour le monitoring, l'alerte, etc. Bien sûr, l'automatisation ne s'arrête pas au seul reporting des projets. Un DWH et un DL peuvent être utilisés pour de nombreuses optimisations SEO automatisées. Par exemple, des mises à jour dynamiques des blocs de liens internes sur le rang, sur le budget de crawl, sur l'audience SEO, etc. (toutes les 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ù les trouver) et d'éviter de passer du temps sur la maintenance. On termine ici sur un aspect plus processuel qu'un use case à proprement parler.
  Les DataLakes comme les DataWarehouses impliquent la mise en place de processus particuliers qui peuvent être présentés de la manière simplifiée suivante :
  • Le point de départ est un constat qui se décline en un énoncé de besoin (équipe métier / SEO – Data Analyst).
  • Ensuite, cela se transforme en une spécification plus technique qui permettra à l'équipe qui administre l'outil de comprendre ce qui doit être fait et comment cela doit être fait.
  • Cette même équipe administrative exécute la demande.
  • L'équipe métier et les Data Analysts produisent un use-case procédural des travaux réalisés.
  • Il s'agit d'un processus continu dans lequel les deux bouts de la chaîne (équipe métier et équipe d'administration du DataWarehouse ou du DataLake) s'assurent que rien ne change en termes d'entrée et de sortie.
    C'est notamment le cas d'un DWH qui rejettera toute donnée ne faisant pas partie de la structure (le schéma prédéfini).

Encore une fois, il s'agit d'une liste non exhaustive des points faibles et des cas d'utilisation possibles pour DataWarehouse - DataLake SEO. Les limites se rencontrent davantage dans le manque d'imagination de ceux qui les utilisent que dans les outils eux-mêmes.

Choisir un DataWarehouse ou un DataLake pour vos usages SEO

Pour conclure, contrairement à ce que vous entendez ou lisez souvent, DataWarehouses et DataLakes sont des structures distinctes de stockage et de collecte de données, et ne sont pas incompatibles. Il n'est pas nécessaire de choisir l'un plutôt que l'autre, bien au contraire. Les deux ont des cas d'utilisation différents et il y a même des adhérences.

Le cas du SEO en est un exemple éloquent, et renforce le besoin des DataWarehouses et des DataLakes en général. Les données sont omniprésentes dans le SEO : nous devons manipuler d'énormes quantités de données provenant de différentes sources. Il n'est donc pas surprenant que nous parlions de DataWarehouses et de DataLakes dans ce contexte. On peut imaginer beaucoup de cas d'utilisation des DataWarehouses ou des DataLakes en SEO, que ce soit à des fins d'automatisation, pour effectuer des analyses « augmentées » à travers les données, ou simplement pour résoudre des problèmes récurrents (pain points).