Data Platform en mode produit : mode d’emploi et bénéfices en industrialisation

Le véritable enjeu du Data Engineering : l’industrialisation

La mise en place d’un Data Lake sur un cloud public comme AWS serait devenue une tâche relativement simple. Dans l’écosystème Amazon, des services comme S3, Glue et Athena sont généralement combinés. Mais pour industrialiser le déploiement et la gestion des multiples pipelines qui alimenteront le Data Lake, au moins deux approches sont possibles.

La « traditionnelle » passe par le recours à une brique de processing centralisée et unique (un « monolithe ») pour exécuter l’ensemble des jobs.

Ce modèle monolithe pose cependant au moins trois problèmes. D’abord, le manque de traçabilité des coûts. En effet, exécuter tous les traitements sur la même infrastructure rend difficile, voire impossible, l’attribution des coûts par cas d’usage spécifique. Ensuite, le problème du « voisin bruyant » (ou « noisy neighbors »). Si un job se met à consommer une quantité anormale de ressources, il peut monopoliser la capacité de la plateforme et impacter, voire faire échouer, l’ensemble des autres traitements.

Enfin, le monolithe rime avec souci d’évolutivité. Toute mise à jour de la brique centrale devient une opération à haut risque. Vouloir, par exemple, « changer la version Spark de EMR serverless » peut, en cas d’erreur, paralyser la totalité des pipelines.

L’alternative au monolithe : le « Data Processing as a microservice »

Pour s’affranchir de ces écueils, Devoteam, ESN retenue à partir de 2021 par un grand groupe de télévision français, a mis en œuvre une architecture décentralisée. Ici, chaque job a sa propre brique dédiée.

En s’appuyant sur des services serverless, ce modèle permet de résoudre les problèmes du monolithe, assure le Data Engineer de la société de conseil IT. Chaque job a sa propre infrastructure. La facture AWS présente une ligne de coût par pipeline. Les coûts deviennent traçables, ce qui permet une analyse financière plus fine.

Les jobs sont en outre indépendants et un problème sur un traitement ne contamine pas les autres.

Enfin, les évolutions sont fiabilisées grâce à des mises à jour déployées brique par brique. Une erreur lors d’une mise à jour n’affectera qu’un seul pipeline, laissant le reste de la production intacte.

Avec une infrastructure serverless, « l’industrialisation en microservices ne coûte pas plus cher qu’une industrialisation en monolithe », assure Erwan Simon.

Attention cependant. L’architecture microservices introduit un nouveau défi : comment éviter que chaque nouveau pipeline ne devienne un projet de développement sur mesure et chronophage ?

Le framework « Data Platform » pour accélérer et standardiser

Pour répondre à la problématique de la redondance du code et accélérer le travail des Data ingénieurs, le recours à un framework interne (baptisé ici « Data Platform ») peut être une solution.

Le framework a pour but de mutualiser le code récurrent et d’abstraire la complexité technique sous-jacente. Pour remplir cette tâche, il doit embarquer trois composants. Premièrement, le générateur de DAGs Airflow. Une librairie Python génère dynamiquement le code des DAGs (les workflows d’orchestration) à partir d’un simple fichier de configuration YAML. Cette automatisation élimine une tâche répétitive et à faible valeur ajoutée pour les ingénieurs.

La « Pipeline Factory » est le second composant. Elle prend la forme d’un module Terraform qui, à partir du même fichier YAML, provisionne automatiquement toute la brique de processing nécessaire à un pipeline (EMR Serverless ou ECS Fargate, image Docker contenant le code applicatif, etc.).

Enfin, le « Data Lake SDK » est une librairie Python. Elle agit comme une « boîte à outils ». Elle mutualise toutes les fonctions récurrentes, dont l’accès sécurisé aux secrets, l’écriture standardisée dans le Data Lake, ou encore l’exécution de requêtes.

S’inspirant ouvertement d’outils populaires comme dbt (qui a rejoint le portefeuille de Fivetran), le SDK permet aux ingénieurs de fournir simplement un fichier SQL pour réaliser leurs transformations.

Des bénéfices au framework, mais aussi des points de vigilance

Pour Erwan Simon, l’adoption d’un framework au niveau de la Data Platform et de l’industrialisation des pipelines de données a des bénéfices concrets. Par exemple, les Data Engineers n’ont plus à coder leurs DAGs Airflow ni à configurer manuellement les ressources AWS.

Le développement des pipelines est simplifié, réduisant significativement le « time to production » des nouveaux cas d’usage. Et en mutualisant le code, le framework garantit que toutes les données sont écrites et gérées de la même manière.

Les évolutions sont aussi facilitées. Pour faire évoluer une pratique à l’échelle (par exemple, implémenter Apache Iceberg), il suffit de mettre à jour le SDK pour que tous les pipelines en bénéficient.

Ceci étant, le choix des valeurs par défaut pour les ressources d’infrastructure (CPU, mémoire) est crucial. Si elles sont surdimensionnées, les utilisateurs ne les ajusteront que rarement. Il en résultera un gaspillage systématique avec un impact négatif sur les coûts (FinOps) et l’empreinte écologique, avertit l’expert.

Erwan Simon insiste en outre pour que le framework ne soit pas appréhendé comme une simple collection d’outils. Pour lui, il constitue un produit logiciel interne. Et en tant que tel, son développement doit suivre des règles avec une discipline rigoureuse.

Gérer la plateforme comme un produit logiciel

Pour assurer la viabilité à long terme du framework et éviter qu’il n’alimente la dette technique, cinq bonnes pratiques de développement logiciel sont incontournables.

Des tests fonctionnels. La stratégie consiste à générer, déployer et exécuter un DAG type à chaque modification du framework. Cela permet de valider de bout en bout le bon fonctionnement.

Des releases versionées. Le framework est publié sous forme de versions sémantiques. Les data engineers peuvent ainsi « fixer » la version utilisée par leurs pipelines, ce qui les protège des régressions potentielles qui pourraient être introduites dans les versions plus récentes.

Le Maintien en Condition Opérationnelle (MCO). Pour faciliter la vie des ingénieurs, les bugs critiques sont corrigés sur les anciennes versions encore supportées. Cette politique doit néanmoins être encadrée par un décommissionnement progressif des anciennes versions afin de maîtriser la charge de maintenance.

Un contrat d’interface stable. Le fichier de configuration YAML doit être considéré comme un contrat d’interface avec les utilisateurs. L’équipe s’efforce de le maintenir le plus stable possible pour éviter les changements trop profonds et la frustration des utilisateurs.

Dernier principe : une sélection rigoureuse des features. L’équipe Data gère un compromis permanent entre les principes « DRY » (Don't Repeat Yourself), qui motive la mutualisation, et « YAGNI » (You Ain't Gonna Need It), qui prévient la sur-ingénierie.

Parfois, refuser une fonctionnalité est la « solution la plus pérenne pour garantir la maintenabilité du framework », estime Erwan Simon. Cumulées.

Faut-il construire sa propre Data Platform ?

Ces recommandations orientées produit favorisent la viabilité technique de la plateforme. Mais avec des technologies en rapide évolution, une autre question se pose. Celle du Make or Buy. « Si l’on traite sa plateforme comme un produit, devrait-on nécessairement être celui qui la construit ? » interroge l’expert.

Pour le groupe audiovisuel client de Devoteam, la décision de construire a été prise en 2021. Mais à l’époque, les solutions du marché « n’avaient pas du tout la maturité qu’elles ont aujourd’hui ». En 2026, la décision serait peut-être différente.

Plusieurs paramètres sont à prendre en compte pour faire l’arbitrage. L’un des effets de bord d’une plateforme telle que détaillée précédemment est l’émergence de ce que le consultant nomme le « YAML engineering ». Et son l’impact humain est à prendre en compte.

Les data engineers, initialement recrutés pour leur expertise technique, passent une grande partie de leur temps à écrire des requêtes SQL et à remplir des fichiers de configuration. Cette abstraction peut générer de la frustration. Dans ce contexte, le groupe télévisuel a fait évoluer les fiches de poste pour rechercher davantage des profils avec une forte appétence métier plutôt que de purs experts de l’infrastructure.

Une approche pragmatique guidée par les KPIs

Par ailleurs, Build et Buy viennent chacun avec des avantages et des compromis.

En développant elle-même, une organisation conserve un contrôle total sur la stack technologique et la roadmap. Le prix à payer en contrepartie est une charge de maintenance significative.

Le Buy, à l’inverse, permet d’externaliser la R&D et la maintenance. Toutefois, cette option introduit une dépendance à un éditeur. En résumé, le « Build » garantit la maîtrise, quand le « Buy » fait bénéficier de la force de frappe d’un acteur spécialisé.

Pour trancher de manière objective entre Make or Buy, Erwan Simon recommande de s’appuyer sur des indicateurs de performance (KPIs). En mesurant, par exemple, le « time to prod » moyen d’un cas d’usage, il devient possible d’évaluer factuellement si la plateforme interne tient ses promesses d’accélération. Si cet indicateur de temps augmente, cela peut signifier que le framework est devenu trop complexe et qu’une migration vers une solution managée doit être sérieusement envisagée, en conclut l’expert AWS de Devoteam.

Mais en matière de Make or Buy, le débat n’est jamais tranché définitivement, poursuit-il. La décision reste contextuelle et elle doit être réévaluée périodiquement. « Il n’y a pas de réponse universelle. Elle dépend de chaque contexte et c’est à vous de vous la poser. Mais les KPIs seront votre meilleur allié », tranche-t-il.

Propos recueillis lors du salon Data IA de Nantes.