Schneider Electric accélère son « time to data »
Schneider Electric a profondément repensé son architecture et sa data platform pour une meilleure adéquation aux besoins, en particulier sur l’IA et le traitement des données non structurées. L’industriel déploie en outre une stratégie Data Mesh.
Les architectures de données ont fortement évolué au sein des entreprises. Chez Schneider Electric aussi, qui a entamé une refonte, il y a cinq ans, afin de déployer un Data Hub dans le cloud sur AWS.
Le groupe international lançait alors une initiative Data Lake. Laurent Marzouk, directeur Architecture & Innovation, lui préfère l’appellation de Data Hub, composé donc de trois briques principales : un data lake sur S3, un « layer intermédiaire d’unification des données » sur Redshift, et enfin un layer analytique hébergé sur une autre instance Redshift avec des données organisées par domaines fonctionnels.
Du data warehouse au Data Hub cloud
Avec ce projet initié au niveau de tout le groupe, Schneider Electric cherchait à remédier aux limites d’une architecture historique qui s’appuyaient sur des entrepôts de données (un global et des déclinaisons régionales).
Saturés en termes de capacité, ces data warehouses étaient en outre inadaptés aux nouveaux besoins en matière d’intelligence artificielle et de traitement de données non structurées. Le Data Hub devait y remédier.
Pour accompagner le déploiement d’une nouvelle stack technologique Big Data, l’entreprise a par ailleurs procédé à une montée en compétence des équipes chargées du dataware.
Ces nouvelles compétences permettent désormais à Schneider Electric de gérer une data platform de plus de 50 To de données – pour ce qui est du Data Hub principal. Celle-ci héberge plus d’une quinzaine de Data Products organisés en domaines fonctionnels distincts.
À ce Data Hub groupe, déployé en Europe, s’ajoutent des Data Lake régionaux, situés aux États-Unis et plus récemment en Chine. Un quatrième, hébergé dans le cloud Azure de Microsoft, est quant à lui dédié aux données IoT.
« Le Data Hub dans Azure capte toutes les données “évènements” issues de nos appareils connectés. Elles sont mises en forme et consolidées avant d’être stockées dans des bases temporelles et analytiques. Ces sources sont utilisées par les services numériques mis à disposition de nos clients dans le cadre de notre offre EcoStruxure, pour fournir par exemple de la maintenance prédictive ou des services que nous appelons les Digital Advisors, capables de faire des recommandations d’optimisation de la consommation électrique ou de proposer le remplacement d’équipements obsolètes », explique Laurent Marzouk.
L’IoT un monde de données qui s’ouvre
L’IoT constitue un « monde à part ». Cependant, depuis deux ans, ont émergé des besoins de réconciliation entre les univers IT et IoT afin de permettre des échanges de données bilatéraux. Schneider Electric remonte ainsi des données issues de ses systèmes Corporate sur AWS pour les croiser avec sa base installée de terminaux connectés.
L’objectif est de développer des services à valeur ajoutée pour ses clients : « Nous sommes en train d’améliorer des services numériques et d’en créer de nouveaux. Et cela est permis par la mise en connexion de deux mondes jusqu’à présent disjoints », déclare le directeur Architecture & Innovation au MagIT.
Les deux clouds concernés, AWS et Azure, ne sont pas interconnectés nativement. Pour échanger les données de l’un à l’autre, l’entreprise a donc conçu une solution maison, « une sorte de passerelle de données », qui permet également de « tracer les échanges et de les automatiser. »
Laurent MarzoukSchneider Electric
Pour établir ces fondations, Schneider Electric a dû au préalable faire aboutir différents chantiers. Suite à la création du Data Lake groupe, l’industriel a commencé l’ingestion de données de ses systèmes opérationnels (ERP, CRM, etc.). Pour ces opérations, il s’est dans un premier temps appuyé sur un outil interne développé par les équipes chargées du datawarehouse.
Même s’il n’était pas très scalable, « cet outil présentait l’avantage d’être déjà connecté aux sources et configuré pour en extraire les données », note Laurent Marzouk. « Nous avons donc décidé de capitaliser dessus, dans un premier temps en développant simplement un connecteur de sortie vers notre Data Lake. Cela a permis un gain de temps considérable ».
Mais outre les problèmes de scalabilité, la solution était également limitée concernant le nombre maximum de colonnes pouvant être rapatriées de SAP lors d’un call RFC. De plus, à cause des schémas de tables SAP, il fallait pour chaque nouvelle table déterminer le pattern d’extraction incrémental adéquat.
« Cela supposait la connaissance des structures de tables et le fait qu’elles contiennent des champs de type datetime ou timestamp sur lesquels nous pouvions baser nos critères d’extraction. » Cette approche était chronophage, et des requêtes spécifiques ont dû être développées pour certaines tables ne contenant pas les champs nécessaires.
Qlik Replicate simplifie l’ingestion de données
Les résultats n’étaient pas toujours satisfaisants ni optimaux. Les requêtes ainsi construites ramenaient parfois des volumes de données bien plus importants que celles réellement nécessaires, imposant alors de les filtrer a posteriori au niveau du Data Lake. Enfin, certaines modifications sur un nombre important d’enregistrements, de manière non journalisée, n’étaient pas capturées ni répercutées dans le Data Lake.
La solution a consisté à basculer sur un « paradigme de type CDC » avec l’application Qlik Replicate.
« Cela nous a permis de traquer toutes les modifications à la source, au niveau de la base de données », résume Laurent Marzouk. Mi-2017 commence donc la construction du Data Lake. La technologie Qlik Replicate a, elle, été examinée il y a trois ans. Elle sera testée un an plus tard afin de démontrer sa valeur.
La première mise en production, auprès de l’entité américaine, a été opérée il y a un an. Désormais, Qlik Replicate est « pratiquement en production sur deux sources au niveau global » et deux instances sont déployées (en US et en Europe).
Par le biais d’un ETL, d’un iPaaS ou de Qlik Replicate pour les données SAP, les équipes régionales opèrent l’ingestion des données dans les Data Lakes régionaux. Des mécanismes de data sharing permettent par ailleurs de s’assurer que les données régionales capturées localement sont rendues disponibles dans le Data Hub mondial.
« Qlik Replicate a été mis en place pour nous affranchir du besoin de définir manuellement ces patterns d’extraction incrémentale, et afin de garantir la consistance et l’exhaustivité des données rapatriées. Cela a aussi permis de réduire considérablement notre “time to data”. »
En effet, l’ingestion de chaque table nécessitait auparavant entre 3 et 5 jours contre quelques heures désormais. Qlik Replicate constitue à présent « l’un des composants techniques de la stratégie Data Mesh » de Schneider Electric. Beaucoup plus simple à mettre en œuvre qu’un ETL, il serait envisageable de le mettre entre les mains de personnes non techniques.
De nouveaux usages permis par le quasi-temps réel
L’accélération du time to data favorise également l’émergence d’autres usages des données pour « des besoins plus opérationnels comme la mise en place de “tours de contrôle” de nos activités logistiques, ou le développement de modèles d’IA qui retournent des inférences sur des données live permettant une prise de décision immédiate », illustre Laurent Marzouk.
« La faculté d’exploiter les données au plus tôt après leur création va s’avérer de plus en plus déterminante en matière de compétitivité et de valeur ajoutée », prévoit-il.
Grâce à sa plateforme et à sa stratégie Data Mesh, Schneider Electric souhaite par ailleurs apporter plus d’autonomie aux métiers dans l’utilisation des données et la conception de Data Products, avec une logique de délégation des responsabilités. « Qlik Replicate devrait nous permettre d’atteindre cet objectif pour la phase initiale d’ingestion des données. »
Laurent MarzoukSchneider Electric
Sur le volet modélisation, le groupe français a récemment introduit une solution de virtualisation des données (Denodo) afin d’apporter plus d’agilité et d’autonomie aux équipes fonctionnelles chargées de créer des vues métiers.
« La vocation de Denodo n’est pas de remplacer nos processus industrialisés d’ingestion de données, mais plutôt de les complémenter – par exemple pour aller plus vite sur des phases de prototypage avec de nouvelles sources – tout en fournissant une vision centralisée et fédérée de l’ensemble de nos sources de données, quelles qu’elles soient, afin d’en simplifier l’utilisation combinée. Cela va également nous permettre de mettre en place un audit et un contrôle d’accès centralisés de la consommation des données. »
Pour le requêtage et la visualisation, Schneider Electric dispose déjà de plusieurs outils, dont Tableau (la solution Corporate pour la BI) et de Power BI (pour les besoins de self-service BI et quelques autres usages).
« L’approche Data Mesh est le meilleur moyen de passer à l’échelle en mettant à contribution toutes les équipes dépositaires de la connaissance fonctionnelle afin qu’elles puissent construire, par elles-mêmes et en autonomie, mais dans le respect des règles de gouvernances définies, des Data Products pour leurs besoins propres qui seront ensuite mis à disposition de tous. », résume le directeur Architecture & Innovation.
La prochaine étape passera par le croisement des données et la mutualisation des produits de différents domaines. « La data virtualisation va nous aider à accélérer sur la phase suivante : la construction de ces vues business cross-domaines, qui nous permettront de tirer encore plus d’insights et de développer de nouveaux services à valeur ajoutée pour nos clients ».