SCHNEIDER ELECTRIC virtualise l’accès à ses données mondiales avec la plateforme DENODO
Retour vers le Journal
Un SI mondial, des données réparties dans plusieurs pays, des soucis de performance sur les requêtes… Laurent Marzouk, Architecture & Innovation Director, Practice Technical Debt Leader Data & Performance, nous explique comment la solution DENODO pourrait permettre à terme de croiser ces données sans devoir systématiquement les répliquer par des flux entre régions ou entre plateformes data.
Quelle était la stratégie de Data Management déployée par Schneider Electric avant de virtualiser vos données ?
Comme toute grande entreprise, Schneider Electric avait développé au cours de la dernière décennie un Datawarehouse d’entreprise. Au fil du temps, cette plateforme qui tournait sur la deuxième plus grosse machine virtuelle disponible sur AWS, est devenue victime de son succès. Elle était arrivée aux limites de ses capacités, et constituait un point de fragilité dans la mesure où elle concentrait de plus en plus de données issues de nos différents systèmes opérationnels, et était utilisée à des fins analytiques, opérationnelles et Master Data Management. Par ailleurs, elle ne répondait pas aux attentes des Data Scientists et ne permettait pas de traiter les données semi et non structurées.
Il y a cinq ans et demi, Schneider Electric s'est donc lancé dans le projet de constituer sa plateforme Data Hub globale basée sur AWS. Cette plateforme était bâtie sur une architecture à 3 niveaux : un Data Lake traditionnel basé sur S3 dans lequel les données brutes (i.e. non transformées) issues des différents systèmes opérationnels sont chargées de manière incrémentale sous forme de fichiers, un niveau d’unification (basé sur Redshift) dans lequel les données du Data Lake sont normalisées, standardisées et consolidées (typiquement, l’ensemble des données de même nature telles que les Commandes issues de différents ERP sont consolidés dans une seule et même table), et enfin un troisième niveau (sous Redshift également) dans lequel les données du niveau unifié sont organisées sous forme de modèles analytiques.
Nous avons créé notre premier Data Product basé sur les Sales Orders, parce que c'est traditionnellement ce qui intéresse le plus la plupart des utilisateurs pour analyser l’activité business et plus généralement les performances du Groupe. Pour y arriver, il a fallu extraire à l’époque les données hébergées dans nos dizaines d’ERP, en définissant pour chaque source les patterns d’extraction adaptés.
Comment envisagiez-vous la généralisation de cette première étape, aux autres domaines fonctionnels ?
C’est l’équipe centrale en charge de construire cette nouvelle data platform qui avait également développé ce premier Data Product autour des Sales Orders. Mais cette équipe n'avait pas pour vocation de développer les Data Products des autres domaines fonctionnels de l’entreprise. Pour passer à l’échelle, il fallait donc former d’autres équipes plus business à des technologies assez complexes, pas forcément accessibles par tout le monde.
C’est la raison pour laquelle nous avons cherché des solutions du marché permettant de simplifier cette approche pour nos équipes. Une solution de data virtualisation non seulement permet de simplifier l'accès aux données où qu’elles soient, mais offre en plus une interface graphique assez simple permettant de modéliser des Business Views (BV) en seulement quelques drags and drops, ou avec très peu de code SQL. C’était une solution de type Low Code / No Code dont nous avions besoin pour rendre ces équipes beaucoup plus efficaces et autonomes.
C’est ce qui vous oriente vers une solution de virtualisation des données ?
Oui, notre volonté était de vraiment pouvoir fédérer les principales data platforms du groupe, hébergées dans différentes régions, avec une couche de virtualisation qui permettrait de croiser ces données de manière simple et performante sans devoir systématiquement répliquer physiquement les données par des flux entre les régions ou entre les plateformes data. La couche de virtualisation permet justement de masquer aux concepteurs de vues métiers la nature technique, la complexité relative et les spécificités propres à chacune des sources de données.
Dans le cadre de notre approche Data Mesh, nous avons commencé à déléguer à nos équipes régionales (US et Chine dans un premier temps) la responsabilité d’ingérer les données des différentes sources colocalisées à leurs data hubs régionaux. A titre d’exemple, les équipes chinoises sont en charge d’ingérer sur leur Data Hub les données de toutes les sources opérationnelles hébergées en Chine. Outre le fait que cela nous permet de demeurer conforme aux exigences de type « Data Residency » en vigueur dans ce pays, ce Data Hub devient de fait une Data Gateway unique à partir de laquelle nous pouvons alimenter notre Data Hub global de manière contrôlée et gouvernée, et nous réfléchissons à présent à présent à la façon dont nous pourrions utiliser Denodo pour rendre les données sensibles accessibles sans avoir à les répliquer ni les stocker physiquement en dehors des pays régis par des réglementation de type Data Residency.
Vous êtes d’abord passés par une phase de PoC avec DENODO ?
Oui, nous avons d’abord testé leurs solutions sur quatre ou cinq cas d'usages réels. Tous se sont avérés positifs tant pour les équipes métiers que pour les équipes IT.
En déployant Denodo en frontal de nos clusters Redshift, nous espérons observer une nette diminution du nombre de requêtes concurrentes auquel nous faisons face aujourd’hui (grâce au cache adossé à Denodo), ce qui devrait par la même occasion améliorer globalement la scalabilité de la plate-forme et les temps de réponses des requêtes, et par la même occasion la satisfaction des utilisateurs.
Nous nous apprêtons également à évaluer comment Denodo pourrait nous aider à renforcer la sécurité d’accès aux données. L’outil permet en effet de définir des data policies pour restreindre (en filtrant et/ou masquant) l'accès aux données en fonction de différents critères tels que le profil utilisateur, la nature et/ou la sensibilité des données.
En 2022, nous avons donc conduit un certain nombre de PoC afin d’évaluer l’adéquation de l’outil par rapport à nos principaux cas d’usage, qui se sont tous conclus positivement. Début 2023, nous avons commencé à déployer Denodo et à définir un Operating Model afin de garantir un usage gouverné de cette plate-forme, avant d’ouvrir progressivement son utilisation au niveau du groupe.
Quel soutien avez-vous eu des équipes DENODO durant le projet ?
Franchement, Denodo est l’un des éditeurs avec lesquels j'ai eu la meilleure expérience en termes de support et de suivi. Que ce soit l’Account Manager, l’équipe avant-vente, le Product Manager ou le CTO, tous les interlocuteurs Denodo ont su se rendre disponibles pour nous accompagner sur les différentes phases de notre projet et recueillir nos suggestions d’amélioration du produit.
Depuis maintenant quelques mois, nous avons mis en place une équipe qui va être en charge officiellement de déployer Denodo à l'échelle du Groupe, de définir l’Operating Model de la plateforme et de supporter les différentes équipes qui vont progressivement l'utiliser.
Quelle était la stratégie de Data Management déployée par Schneider Electric avant de virtualiser vos données ?
Comme toute grande entreprise, Schneider Electric avait développé au cours de la dernière décennie un Datawarehouse d’entreprise. Au fil du temps, cette plateforme qui tournait sur la deuxième plus grosse machine virtuelle disponible sur AWS, est devenue victime de son succès. Elle était arrivée aux limites de ses capacités, et constituait un point de fragilité dans la mesure où elle concentrait de plus en plus de données issues de nos différents systèmes opérationnels, et était utilisée à des fins analytiques, opérationnelles et Master Data Management. Par ailleurs, elle ne répondait pas aux attentes des Data Scientists et ne permettait pas de traiter les données semi et non structurées.
Il y a cinq ans et demi, Schneider Electric s'est donc lancé dans le projet de constituer sa plateforme Data Hub globale basée sur AWS. Cette plateforme était bâtie sur une architecture à 3 niveaux : un Data Lake traditionnel basé sur S3 dans lequel les données brutes (i.e. non transformées) issues des différents systèmes opérationnels sont chargées de manière incrémentale sous forme de fichiers, un niveau d’unification (basé sur Redshift) dans lequel les données du Data Lake sont normalisées, standardisées et consolidées (typiquement, l’ensemble des données de même nature telles que les Commandes issues de différents ERP sont consolidés dans une seule et même table), et enfin un troisième niveau (sous Redshift également) dans lequel les données du niveau unifié sont organisées sous forme de modèles analytiques.
Nous avons créé notre premier Data Product basé sur les Sales Orders, parce que c'est traditionnellement ce qui intéresse le plus la plupart des utilisateurs pour analyser l’activité business et plus généralement les performances du Groupe. Pour y arriver, il a fallu extraire à l’époque les données hébergées dans nos dizaines d’ERP, en définissant pour chaque source les patterns d’extraction adaptés.
Comment envisagiez-vous la généralisation de cette première étape, aux autres domaines fonctionnels ?
C’est l’équipe centrale en charge de construire cette nouvelle data platform qui avait également développé ce premier Data Product autour des Sales Orders. Mais cette équipe n'avait pas pour vocation de développer les Data Products des autres domaines fonctionnels de l’entreprise. Pour passer à l’échelle, il fallait donc former d’autres équipes plus business à des technologies assez complexes, pas forcément accessibles par tout le monde.
C’est la raison pour laquelle nous avons cherché des solutions du marché permettant de simplifier cette approche pour nos équipes. Une solution de data virtualisation non seulement permet de simplifier l'accès aux données où qu’elles soient, mais offre en plus une interface graphique assez simple permettant de modéliser des Business Views (BV) en seulement quelques drags and drops, ou avec très peu de code SQL. C’était une solution de type Low Code / No Code dont nous avions besoin pour rendre ces équipes beaucoup plus efficaces et autonomes.
C’est ce qui vous oriente vers une solution de virtualisation des données ?
Oui, notre volonté était de vraiment pouvoir fédérer les principales data platforms du groupe, hébergées dans différentes régions, avec une couche de virtualisation qui permettrait de croiser ces données de manière simple et performante sans devoir systématiquement répliquer physiquement les données par des flux entre les régions ou entre les plateformes data. La couche de virtualisation permet justement de masquer aux concepteurs de vues métiers la nature technique, la complexité relative et les spécificités propres à chacune des sources de données.
Dans le cadre de notre approche Data Mesh, nous avons commencé à déléguer à nos équipes régionales (US et Chine dans un premier temps) la responsabilité d’ingérer les données des différentes sources colocalisées à leurs data hubs régionaux. A titre d’exemple, les équipes chinoises sont en charge d’ingérer sur leur Data Hub les données de toutes les sources opérationnelles hébergées en Chine. Outre le fait que cela nous permet de demeurer conforme aux exigences de type « Data Residency » en vigueur dans ce pays, ce Data Hub devient de fait une Data Gateway unique à partir de laquelle nous pouvons alimenter notre Data Hub global de manière contrôlée et gouvernée, et nous réfléchissons à présent à présent à la façon dont nous pourrions utiliser Denodo pour rendre les données sensibles accessibles sans avoir à les répliquer ni les stocker physiquement en dehors des pays régis par des réglementation de type Data Residency.
Vous êtes d’abord passés par une phase de PoC avec DENODO ?
Oui, nous avons d’abord testé leurs solutions sur quatre ou cinq cas d'usages réels. Tous se sont avérés positifs tant pour les équipes métiers que pour les équipes IT.
En déployant Denodo en frontal de nos clusters Redshift, nous espérons observer une nette diminution du nombre de requêtes concurrentes auquel nous faisons face aujourd’hui (grâce au cache adossé à Denodo), ce qui devrait par la même occasion améliorer globalement la scalabilité de la plate-forme et les temps de réponses des requêtes, et par la même occasion la satisfaction des utilisateurs.
Nous nous apprêtons également à évaluer comment Denodo pourrait nous aider à renforcer la sécurité d’accès aux données. L’outil permet en effet de définir des data policies pour restreindre (en filtrant et/ou masquant) l'accès aux données en fonction de différents critères tels que le profil utilisateur, la nature et/ou la sensibilité des données.
En 2022, nous avons donc conduit un certain nombre de PoC afin d’évaluer l’adéquation de l’outil par rapport à nos principaux cas d’usage, qui se sont tous conclus positivement. Début 2023, nous avons commencé à déployer Denodo et à définir un Operating Model afin de garantir un usage gouverné de cette plate-forme, avant d’ouvrir progressivement son utilisation au niveau du groupe.
Quel soutien avez-vous eu des équipes DENODO durant le projet ?
Franchement, Denodo est l’un des éditeurs avec lesquels j'ai eu la meilleure expérience en termes de support et de suivi. Que ce soit l’Account Manager, l’équipe avant-vente, le Product Manager ou le CTO, tous les interlocuteurs Denodo ont su se rendre disponibles pour nous accompagner sur les différentes phases de notre projet et recueillir nos suggestions d’amélioration du produit.
Depuis maintenant quelques mois, nous avons mis en place une équipe qui va être en charge officiellement de déployer Denodo à l'échelle du Groupe, de définir l’Operating Model de la plateforme et de supporter les différentes équipes qui vont progressivement l'utiliser.