Démanteler l’ELT : quand il faut un graphe, pas des silos

• L’ELT (Extract, Load, Transform) est utilisé pour relier les « silos » entre l’analyse de données et le développement logiciel au sein des organisations, mais cette structure en silos est elle-même la source du problème

• L’ELT n’est qu’un pont entre des silos. Un monde sans silos, c’est un « graphe »

Les limites de la façon de penser ELT

• Dans un monde en silos, où le logiciel se trouve dans un silo et l’analyse de données dans un autre, l’ELT a beaucoup de sens
• L’ELT fonctionne en partant du principe d’une structure en silos
  • Quand les équipes de développement logiciel et d’analyse de données sont séparées, l’étape d’« extraction » apparaît
  • L’équipe logicielle ne s’intéresse pas au travail de l’équipe data, et l’équipe data extrait les données sans ménagement à l’aide des droits d’accès à la base de données
  • Ce n’est qu’après l’extraction que des principes d’ingénierie comme la qualité des données et la modélisation sont appliqués, mais il est déjà trop tard
• La loi de Conway est à l’œuvre
  • « La conception des systèmes produits par une organisation reflète la structure de communication de cette organisation »
• À cause de cette logique en silos, ETL/ELT/Reverse ETL sont inadaptés pour gérer la complexité de l’architecture data moderne
  • Les données ne résident plus seulement dans les systèmes opérationnels ou analytiques, elles s’étendent désormais à un troisième domaine incarné par le SaaS
  • Les données circulent entre régions et cloud, entre backends et SaaS
  • Il existe aujourd’hui 100 fois plus d’applications qu’autrefois, les organisations se « softwarisent », et le réseau de relations entre systèmes logiciels devient de plus en plus complexe

Pourquoi il faut penser en graphes

• Si les équipes logicielles et data collaborent harmonieusement, on peut passer d’un modèle d’extraction et de stockage des données comme l’ELT à un modèle en graphe
  • Imaginez un graphe composé de nœuds qui « consomment » des données
  • Chaque nœud produit ou consomme des données, formant naturellement un réseau ou un graphe
• Les avantages d’une pensée en graphes :
  • Moins d’extraction de données, plus de consommation
  • Davantage de modélisation autour de jeux de données de haute qualité
  • Moins de nettoyage des données, moins de stockage de données brutes, moins de correction d’erreurs de pipeline
  • Usage de traitements incrémentaux et de sources en streaming à la place des processus batch
  • L’analytique ne se limite plus aux outils d’aide à la décision stratégique et s’étend aux usages opérationnels
  • Plus de collaboration et d’alignement entre équipes, moins de silos

Conclusion

• La logique ELT est le résultat de la loi de Conway, qui reflète la fracture entre équipes logicielles et équipes data
• Il n’est pas nécessaire de jeter tous les outils ETL/ELT existants, mais il faut se concentrer sur la consommation des données et la construction de jeux de données dérivés fiables
• En pratique, le Shift Left reste encore au stade aspirationnel, et les problèmes d’intégration avec l’infrastructure legacy existante demeurent
  • Shift Left : stratégie qui consiste à intégrer des pratiques de développement importantes dès les premières phases du cycle de vie du développement logiciel (SDLC)
• Les organisations qui adoptent une pensée en graphes en tireront les plus grands bénéfices en matière d’usage des données, de ROI de l’IA et de performance métier

« Il n’y a pas d’extraction. Il n’y a que de la consommation. » – le Yoda de la data

[udopeanut]

Après avoir lu le livre Data Mesh, il y a beaucoup de points qui me paraissent plus clairs.

[softer]

Je réfléchis de façon continue à la prise de décision fondée sur les graphes, et ce serait formidable si des personnes qui partagent la même vision pouvaient se rassembler.

[kimsk]

Le terme approprié dans ce cas est donc « idéation ». J’aurai appris quelque chose. C’est un sujet qui m’intéresse beaucoup personnellement. Ce serait vraiment bien si nous pouvions nous réunir.

[jwseo]

Quelqu’un pourrait-il expliquer un peu plus ? La méthode dont parle l’auteur consiste-t-elle à stocker et gérer séparément tous les jeux de données dérivés sous forme de graphe ? Si ce n’est pas le cas, j’ai du mal à comprendre en quoi cela diffère de l’ETL.

[rlaehdus2003]

On dit que la structure traditionnelle, où les domaines opérationnel et analytique sont séparés, pose un problème structurel de silo. Lors de la conception d’une architecture de données, ces deux domaines ne devraient donc pas être envisagés séparément, mais selon une distinction entre producteurs et consommateurs de données.

Désormais, à mesure que la frontière entre données opérationnelles et données analytiques devient floue, il faudrait adopter une pensée en graphe (graph thinking, ou the graph mindset).

À mon sens, plutôt qu’une séparation explicite entre données opérationnelles et données analytiques, il s’agit de distinguer les consommateurs et les producteurs de données dans le prolongement des données opérationnelles, et d’envisager l’accès aux données du point de vue du flux de données (même si les rôles peuvent rester séparés).

J’ai l’impression qu’il parle de l’architecture des données dans une logique où l’on analyse les données opérationnelles, puis on les réinjecte dans l’opérationnel, avant qu’elles repartent à nouveau vers l’analytique.