Histoire de la stack data

2 minute read

Perdus dans l’évolution rapide des systèmes data ? Cet article retrace les principales étapes de l’évolution des stacks data.

Des années 80 jusqu’à 2005 - 2010 : le modèle “classique” (legacy data stack)

Le modèle dit “classique” ou legacy est celui historiquement mis en place pour les systèmes décisionnels. Il naît d’une problématique matérielle : les systèmes transactionnels, à l’origine des données, ne sont pas prévus pour supporter une charge analytique. La solution est donc de déverser la donnée depuis le système de production dans un système décisionnel où la donnée peut être historisée et utilisée pour diverses tâches : reporting, visualisation, modélisation…

Il se compose de :

  • un pipeline de données suivant généralement une séquence ETL (Extract, Transform, Load) qui extrait les données des systèmes sources, les met sous une forme tabulaire pensée pour leur stockage, puis les charge dans…
  • un entrepôt de données (Data Warehouse) qui centralise l’ensemble des données, pour consommation soit directe par extraction (ex: requêteurs Excel), soit par…
  • un outil d’extraction et d’analyse qui permet de créer des cubes de données préparées pour l’analyse

Note sur les écoles d’architecture

Deux références principales en architecture des entrepôts de données : Bill Inmon1 et Ralph Kimball2

Le problème avec les cubes OLAP

De 2010 à 2015 : le modèle “big data / Hadoop”

Depuis 2016 : le modèle “moderne” ou modern data stack

Un Data Warehouse as a service

La modern data stack est un retour vers la logique de la stack classique, avec des outils modernisés et surtout, managés, as a service. Mais au-delà de la modernisation des systèmes, c’est aussi et surtout un retour à SQL comme langage de modélisation des données.

Le modèle moderne apporte de la flexibilité et des économies :

  • on ne consomme les moyens de traitement des données (compute) que lorsqu’on les utilise, et la puissance s’adapte à la charge, horizontalement comme verticalement.
  • la maintenance et l’optimisation des serveurs sous-jacents sont réalisées, à deux échelles, par le fournisseur du compute et le fournisseur du stockage, tous deux en cloud.

La prédominance de Snowflake

Les grands noms de l’entrepôt de données version modern data stack :

Trois problématiques non adressées par la modern data stack

Inadaptation à certains contextes

Pour autant, ce modèle n’apporte pas une solution adaptée à tous les contextes et besoins analytiques :

  • Inadaptation au temps réel : par construction, le déversement de la donnée dans un entrepôt décisionnel introduit une latence. L’implémentation d’analytics en pseudo-temps réel demande alors un effort important.

(streaming analytics / kafka)

  • Inadaptation aux organisations complexes : les principes de Data Warehouse unique, et encore plus de modèle de données unique, peuvent être des contraintes inutiles, le modèle s’avérant inadapté aux organisations complexes : de grande taille, hétérogènes, ou de nature fédérée.

(data mesh)

Goulot d’étranglement du self-service

Il n’apporte pas non plus de solution au problème du goulot d’étranglement des équipes techniques, qui concernait déjà le modèle classique.

En effet, le passage d’une donnée architecturée dans un data warehouse à une donnée prête à être exploitée par des analystes dans des outils de BI reste dépendant de l’intervention d’une équipe spécialisée, qui devient rapidement un goulot d’étranglement, apportant de la frustration et augmentant le time to market.

Effets de la non-gouvernance des données

“Good pipelines, bad data?” : émergence des pratiques de gouvernance et d’observabilité

Depuis 2021 : la modern data stack sémantisée

  1. Bill Inmon, Building the Data Warehouse (1992), Wiley 

  2. Ralph Kimball, The Data Warehouse Toolkit (1996), Wiley 

Updated: