Quel est le quotidien de nos consultants en mission ? Quels sont les challenges techniques qu’ils doivent relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers le témoignage de nos consultants.

Passionné par l’IT, Damien a rejoint D2SI après un parcours d’intégrateur, puis d’architecte d’infrastructure et enfin de DevOps. Dans son métier, Damien apprécie d’apprendre de nouvelles choses tous les jours, et il tire satisfaction du développement de solutions qui répondent à 100% au besoin métier. A ses heures perdues, il aime aussi faire un peu de développement en Python et en Scala. Damien partage ici avec nous son retour d’expérience sur un projet Datalake, depuis ses phases préparatoires jusqu’à la construction et l’évolution d’un pipeline d’ingestion de données basé sur du Serverless.

Quelle a été la première phase de construction du Data Lake?

Dans un premier temps, nous avons expliqué le concept de Data Lake aux différentes parties prenantes du projet (DSI, BU métiers…), ainsi que les briques utilisées pour chacune des phases : l’ingestion de données, le processing, le structuring, puis la restitution. L’objectif d’un Data Lake est de pouvoir traiter différents cas d’usage : customer churm (prédiction de la perte client), détection de fraude, optimisation de processus industriels, recommandation de contenus, maintenance prédictive, agile analytics. Nous avons également réalisé une présentation pour démystifier les métiers de Data Engineer, Data Scientist, Data Analyst , Data Owner (pour plus de détails sur ces sujets, consultez notre Ebook Data as a Service).

Quelles sont les conditions de réussite d’un Data Lake ?

C’est une conviction personnelle, mais je pense que pour garantir le succès d’un projet de Data Lake, il faut y intégrer un état d’esprit agile de bout en bout, tant dans la phase de construction du Data Lake que sur les cas d’usage métiers qui seront élaborés sur celui-ci. Un Data Lake est un moyen et non une fin. Adopter une approche agile permet d’accroître la flexibilité et l’aptitude au changement en réponse aux expressions de besoin des métiers. Dans l’idéal les cas d’usage métiers sont traitées par une features team customer centric. Un tel dispositif facilite les interactions et permet de maximiser la valeur métier de chaque cas d’usage.

Quel environnement technique a été choisi pour ce Data Lake ?

Notre client souhaite utiliser autant que possible les services managés AWS. Aujourd’hui les challengers HortonWorks, Cloudera disposent d’outils permettant d’instancier très rapidement des clusters sur le IAAS d’AWS. Cependant la force de l’usage des services Big Data PAAS et Serverless, c’est beaucoup plus que du Time to market. Nous parlons d’interopérabilité des services AWS , de paiement à l’usage , de sécurité by design, d’élasticité à toute épreuve et d’une forte baisse du MCO en comparaison avec le on-premise et le simple IAAS. Dans ce cas, la première brique de ce Data Lake était un pipeline d’ingestion générique basé sur un pattern événementiel. L’architecture utilise un ensemble de services ServerLess avec Amazon S3, Amazon SNS, Amazon SQS , AWS Lambda , AWS GLUE et Amazon Athena :

Comment est traitée la data ?

Une Data Source entre dans le Data Lake en étant déposée sur le service de stockage Amazon S3. Cela déclenche un événement référençant la key S3 du fichier qui sera consommée par plusieurs fonctions Lambdas. Ces Lambdas appliquent un certain nombre de traitements sur cet événement, jusqu’à ce que la dernière Lambda déclenche un job AWS Glue pour appliquer une transformation sur la donnée source et l’écrire dans un format optimisé pour les traitements Data dans la partie structuring du Data Lake (on parle de ORC et Parquet). Enfin cette même fonction Lambda réalise un update du catalog Glue. Amazon Athena est utilisé pour les requêtes Ad Hoc sur nos fichiers Parquet ou ORC disposés sur Amazon S3.

Cette chaîne permet de manière générique d’ingérer certaines typologies de Data Source texte/csv/json/etc.. et d’y appliquer une optimisation de format pour être tout de suite consommé de la manière la plus efficiente (la donnée reste Raw).

Quel est l’état d’avancement du Data Lake ?

Le pipeline d’ingestion est actuellement en phase d’expérimentation, et nous nous concentrons maintenant sur de la valeur ajoutée du Data engineering. Cette phase consiste à faire des contrôles d’intégrité de la donnée : est-ce que les champs sont du type attendu, est-ce que les colonnes ne sont pas inversées, etc. L’objectif du Data Lake est de structurer la donnée pour pouvoir répondre à plusieurs usages. Structurer la donnée nous amène naturellement sur une réflexion Master Data Management ( MDM ) et gouvernance de la donnée.

Comment l’entreprise se structure-t-elle pour mieux exploiter la donnée ?

Au sein de son organisation Data Driven, le client attribue des rôles de Data Owners. Ce sont des postes stratégiques avec un rôle de référents sur les Datasets. Idéalement il s’agit de quelqu’un issu du métier. L’objectif de cette démarche est de donner au métier les moyens d’assurer la conformité aux réglementations, de définir les contrôles à mettre en place pour l’accès au Dataset pour gérer les risques, de s’assurer de la qualité du Dataset. Tout simplement être garants du Dataset, car ce sont les mieux placés pour réaliser ces actions.

Avec quels interlocuteurs travailles-tu ?

J’échange essentiellement avec la DSI, le Datalab, les équipes de sécurité, les Data engineers/scientists, mes homologues de D2SI qui assurent le rôle de DataDevOps, et enfin avec les équipes projets qui portent les cas d’usage à réaliser sur le Data Lake. En bref, toutes les parties prenantes ayant pour mission de challenger la plateforme.

Précisons que le DataDevOps dans le cadre de cette mission concerne les activités DevOps sur le monde de la Data. On y retrouve une orientation GitOps avec le développement des recettes Terraform versionnées dans Git, l’orchestration des build, les méthodologies de peer programming, l’automatisation des déploiements…
Cela demande des compétences particulières car c’est un domaine extrêmement riche où les outils Data sont relativement jeunes et peu documentés. Il faut perpétuellement suivre les évolutions. De nouvelles solutions de stream, de datastore et autres sont opensourcées très régulièrement.

Quelles sont les challenges rencontrés dans la phase de structuration de la donnée ?

Il faut structurer intelligemment et éviter les doublons de données, avec un objectif de produire un Data Catalog dont la vue métier est partagée de tous. Nous travaillons à fournir un Data Catalog qui puisse répondre à un grand nombre de cas d’usages.

Comment la sécurité des données est-elle gérée ?

Dans la mesure où le client souhaite évoluer vers une organisation Data-driven, le volet sécurité est encore à l’étude. Pour le moment les premiers cas d’usage ne comportent pas de données personnelles, mais l’entreprise a défini une politique de confidentialité sur laquelle nous nous basons pour chiffrer les données. AWS offre tous les outils pour chiffrer les données en transit et au repos : Amazon KMS pour le chiffrement au repos et en transit intégré à l’ensemble des services Amazon tels que S3 avec le Server Side Encryption, Amazon Athena , Amazon EMR et bien d’autre. La partie gouvernance de cette donnée dans un premier temps sera réalisée par les rôles Amazon IAM et les tags Amazon S3 disposés sur les Dataset.

Quels sont les challenges de sécurité ?

La gouvernance de la donnée est un challenge autant sur le Cloud que On-premise. Dans un premier temps, nous utilisons Amazon IAM pour limiter les accès aux jeux de données aux différentes populations. Définir les politiques d’accès aux Datasets et les solutions qui permettront d’appliquer cette gouvernance est très chronophage. En effet aujourd’hui nous disposons des technologies de chiffrement , il existe même certains softwares permettant de réaliser de l’anonymisation de donnée, mais la plus grande difficulté reste à identifier les premiers Asset Data, définir et rédiger la politique de la donnée puis l’appliquer sur ces asset. En fonction de la taille de la structure et le nombre d’interlocuteurs, arriver à un consensus peut demander plusieurs mois.

Qu’as-tu appris sur cette mission ?

Dans le cadre de cette mission nous avons eu l’opportunité de mettre en place une solution basée uniquement sur les services Serverless, entièrement buildée et déployée en Infrastructure As code. Notre prochain challenge est l’intégration de tous le code IAC et du code métier dans notre solution de CI/CD. En effet nous souhaitons aboutir sur un niveau d’industrialisation qui nous permettent le synopsis suivant :

Après les tests unitaires et les tests de non-régressions de notre branche feature, la validation de la merge request associée sur la branche master déclenche la construction des objets d’infrastructure ( si ils ne sont pas présents) et le déploiement de l’artefact métier sur le Data Lake. Il s’agit d’un nouveau pipeline d’ingestion , d’un nouveau Job de processing Data Hive/Spark et autres.

Enfin, grâce à la réalisation terrain j’ai également pu développer des convictions sur l’usage des service AWS Glue, Amazon Athena, qui ont moins d’un an d’existence.

Qu’est-ce que tu aimes dans le métier de la Data chez D2SI ?

J’apprécie de pouvoir être onboardé directement sur les cas d’usage métier Big Data, et de pouvoir créer directement de la valeur au métier. Traditionnellement, nous étions challengés par les DSI, maintenant les BU métiers sont beaucoup plus impliquées dans le challenge et la réalisation de leur cas d’usage. C’est probablement une cause de l’adoption du Cloud .
Ces missions sont de plus en plus fréquentes chez D2SI et c’est très motivant.

Enfin, j’aime travailler au sein des équipes produits ou features team qui baignent dans les contraintes métiers. Dans le monde de la Data il est  possible de créer rapidement de la valeur pour nos métiers. Les résultats sont visibles rapidement et c’est très gratifiant.

Quelques éléments de contexte sur le Datalake pour finir :

• Facturation : encore sous le seuil de facture SNS / LAMBDA 
• Elasticité : l’architecture reste la même qu’elle traite une, cent ou mille ingestions
• Full ServerLess : aucun MCO (maintien en condition opérationnelle)