Ce talk est un retour d’expérience sur la réarchitecture d’un système existant chez un de nos clients, gros industriel de l’automobile.

Le système était constitué de jobs Spark en batch mal architecturés, conduisant à des problèmes de performance et d’utilisation mémoire. Il était aussi nécessaire d’aller vers du streaming pour fournir des résultats plus rapidement aux équipes métier.

Le client était organisé par domaines fonctionnels, avec chacun ses règles métiers fortes. Le code, basé sur une conception trop orientée héritage, n’avait pas la souplesse nécessaire pour faire évoluer facilement les règles métier.

Ces éléments ont conduit au choix du Domain Driven Design pour architecturer la nouvelle version.

Dans ce talk, nous montrerons comment l’utilisation du DDD a abouti à une architecture supportant mieux les règles métiers pour apporter plus de valeur aux équipes.

Nous expliquerons aussi les choix d’implémentation. Spark et Spanner, envisagés initialement, n'ont pas apporté satisfaction. C’est finalement Apache Beam et BigQuery qui ont répondu au besoin.

Embarquez avec nous dans le récit de cette ré-architecture ambitieuse d’un système essentiel chez notre client !

Ce ReX a pour but de mettre en lumière les problématiques que nous avions chez notre client, les outils qui avaient été proposés initialement et les raisons qui nous ont poussé à faire cette migration.

Partie modèle de données :
Nous montrerons le modèle initial avec Spanner et expliquerons pourquoi l'outil et la modélisation ne faisait pas l'affaire et pourquoi nous sommes allés vers BigQuery.

Partie data processing :
Nous expliquerons l'architecture initiale des jobs Spark, qui posait des problèmes de mémoire, ainsi que la conception de code des jobs trop orienté héritage qui empêchait le code d'évoluer facilement.

Ces problèmes et l'organisation des équipes métiers, nous ont poussé naturellement à aller vers le DDD, ce qui a permis de rendre le code plus évolutif et d'avoir cette ligne directrice orientée "métier".

Nous expliquerons aussi pourquoi nous avons choisi Apache Beam, comme framework pour la partie processing de la donnée.

Après avoir expliqué les raisons de nos choix, le code montrera l'intérêt du DDD avec Beam et aussi d'avoir du découplage de code.
Nous montrerons en live qu'on pourra décrocher une entrée (input connector) et adapter batch pour le remplacer par un adapter streaming, sans modifier le code métier.

Pour cette migration, nous avons travaillé avec les équipes de Google.
C'est moi qui ai mené cette migration et ai aidé les équipes à monter en compétence sur Beam et les archi en DDD.

Voici un article écrit par des Googlers qui parlent de cette migration vers BigQuery et Beam/Dataflow :
https://cloud.google.com/blog/topics/manufacturing/renault-improves-its-industrial-data-platform-with-bigquery