Sergey Nivens - Fotolia

ForePaaS remplace son ETL par un moteur orienté événements

ForePaas annonçait en février sa feuille de route. La startup avait notamment évoqué le remplacement de son ETL par le Data Processing Engine (DPE). Celui-ci entraîne une évolution du modèle économique pour la plateforme dédiée au déploiement de projets de data science.

Les projets de data science entraînent une modification en profondeur des architectures d’accès à la donnée. Depuis 2013, la startup ForePaaS misait sur un ETL personnalisé, un des composants clés de sa plateforme de traitement de données dans le cloud. L’outil d’extraction, de transformation et de chargement semble avoir fait son temps. ForePaaS le remplace par le Data Processing Engine (DPE), une évolution de son précédent outil qui a demandé environ six mois de développement et de tests. 

« Le passage au DPE est pour nous un changement assez important dans l’approche que nous offrons à nos utilisateurs. L’ingestion des données est dorénavant basée sur des événements. Cela va permettre aux clients qui en ont besoin d’actualiser leurs informations en temps réel d’obtenir de meilleures performances », déclare Paul Sinaï, PDG de ForePaaS.

L’ETL de ForePaaS fera bientôt ses adieux

Le DPE est donc un composant essentiel de la brique de data preparation proposée par l’éditeur. Celui-ci s’organise autour de trois piliers : les actions, les workflows et les environnements. Les actions sont des fonctions programmatiques en Python (FaaS) qui réalisent des opérations de données unitaires à partir des sources disponibles via API ou connecteurs. Un workflow permet d’orchestrer plusieurs actions en étapes. Les environnements sont des fichiers de configuration partagés appliqués à l’exécution d’actions ou de workflows. Les actions ou les workflows peuvent être déclenchés manuellement ou automatiquement par appel d’API. Le tout est accessible depuis une interface visuelle (développé en VueJS), tandis que le SDK et les API associés ont été revus.

Par ailleurs, ForePaaS a renforcé les intégrations avec les dépôts GIT, dont GitHub, GitLab et GitBucket. De la sorte, l’éditeur veut faciliter le versioning des jeux de données et des modèles depuis la plateforme. À l’avenir, il souhaite également déployer un outil de synchronisation des versions de data sets et des modèles afin de faciliter la traçabilité des travaux de data science. Une fonctionnalité en partie proposée par Databricks avec MLflow.

En arrière-plan, la plateforme exécute et éteint automatiquement des containers nécessaires à la mise en place des pipelines de données. Tout comme l’ETL, le Data Processing Engine est lié à Kubernetes. En effet, ForePaaS avait rapidement associé cette brique à l’orchestrateur de container. Selon Paul Sinaï, le DPE profite des fonctionnalités actualisées de Kubernetes, ce qui n’était pas forcément le cas pour l’ETL malgré les mises à jour successives. Disponible en production sur la version 1.16 de Kubernetes, l’ETL « ne permettait pas de traiter des volumes de données aussi importants que le DPE », précise le PDG.

Pour le calcul distribué, la startup propose son propre moteur, le ForePaaS Engine. Les clients auront prochainement le choix entre ce composant propriétaire ou Apache Spark, pour l’instant en Alpha. « Nous proposons surtout cette option pour les utilisateurs de Spark couplé à Scala, mais le moteur ne sert pas aux mêmes usages ou aux mêmes transformations », détaille Paul Sinaï. Dans ForePaaS, le framework développé par les fondateurs de Databricks est davantage associé aux traitements sur de gros volumes de données. 

Pour développer cette architecture repensée, ForePaaS utilise Nameko, un jeune framework open source de conception de microservices en Python. « Nameko nous a aidé à accélérer la migration vers Python 3, et à développer tous nos microservices de notre back-end ». ForePaaS est en effet passé à Python 3 et annonce la fin du support de la version 2.7.

Une facturation à l’usage pour s’adapter aux tâches de data science

Le Data Processing Engine introduit surtout un mode de paiement « pay as you go ». « Avec l’ETL, les opérateurs (workers) fonctionnent en continu. La nouveauté avec le DPE, c’est que ces workers sont dynamiques. Dans l’idée, nous allons facturer au moment où la donnée est véritablement propulsée », indique Paul Sinaï.

Pour autant, les FPU (ForePaaS Processing Unit) ne disparaissent pas. Ces crédits sont maintenant consommés à la demande. Ils peuvent être redirigés au besoin vers d’autres fonctionnalités de la plateforme comme le machine learning quand ils sont disponibles. Pour les clients qui n’optent pas pour un mode de disponibilité à la volée, cela doit leur permettre de mieux allouer les ressources à leur disposition dans la Data Plant, selon l’éditeur. Il s’agit aussi de faire baisser le coût des traitements les plus lourds des projets de data science, qui ne sont souvent pas en production.

Si certains clients de ForePaaS sont déjà passés ou sont en train de migrer vers le DPE, la plupart d’entre eux doivent encore le faire. La brique ETL est dépréciée. « Un certain nombre de partenaires sont en train de se former sur le DPE pour s’adapter aux nouvelles fonctionnalités », explique Paul Sinaï.

Selon le PDG, la startup n’est pas directement impactée par la crise sanitaire en cours. En revanche, elle prépare une solution pour s’adapter à la nouvelle donne et anticiper l’après-confinement.

« Nous en sommes en train de réfléchir à nouvelle version de la plateforme qui permet de commencer à orchestrer des charges de travail de data science avec de plus petites équipes et pour un budget largement inférieur aux solutions traditionnelles », conclut-il.

Pour approfondir sur Intelligence Artificielle et Data Science

Close