Créer et former des modèles ML à l'aide d'une architecture de maillage de données sur AWS : partie 1

Des organisations de divers secteurs utilisent l'intelligence artificielle (IA) et l'apprentissage automatique (ML) pour résoudre les défis commerciaux spécifiques à leur secteur. Par exemple, dans le secteur des services financiers, vous pouvez utiliser l'IA et le ML pour résoudre les problèmes liés à la détection des fraudes, à la prévision des risques de crédit, au marketing direct et bien d'autres.

Les grandes entreprises mettent parfois en place un centre d'excellence (CoE) pour répondre aux besoins des différents secteurs d'activité (LoBs) avec des analyses innovantes et des projets ML.

Pour générer des modèles de ML de haute qualité et performants à grande échelle, ils doivent procéder comme suit :

• Fournir un moyen simple d'accéder aux données pertinentes pour leurs analyses et leur ML CoE
• Créer une responsabilité sur les fournisseurs de données à partir de LoBs individuels pour partager des ressources de données organisées qui sont détectables, compréhensibles, interopérables et dignes de confiance

Cela peut réduire le temps de cycle long pour convertir les cas d'utilisation ML de l'expérimentation à la production et générer de la valeur commerciale dans toute l'organisation.

Une architecture de maillage de données s'efforce de résoudre ces défis techniques et organisationnels en introduisant une approche socio-technique décentralisée pour partager, accéder et gérer les données dans des environnements complexes et à grande échelle, au sein ou entre les organisations. Le modèle de conception de maillage de données crée un modèle de partage de données responsable qui s'aligne sur la croissance organisationnelle pour atteindre l'objectif ultime d'augmenter le rendement des investissements commerciaux dans les équipes de données, les processus et la technologie.

Dans cette série en deux parties, nous fournissons des conseils sur la manière dont les organisations peuvent créer une architecture de données moderne à l'aide d'un modèle de conception de maillage de données sur AWS et permettre à un centre d'expérience analytique et ML de créer et de former des modèles ML avec des données sur plusieurs LoB. Nous utilisons un exemple d'organisation de services financiers pour définir le contexte et le cas d'utilisation de cette série.

Dans ce premier article, nous montrons les procédures de mise en place d'une architecture de maillage de données avec plusieurs comptes de producteur et de consommateur de données AWS. Ensuite, nous nous concentrons sur un produit de données, qui appartient à un LoB au sein de l'organisation financière, et comment il peut être partagé dans un environnement de maillage de données pour permettre à d'autres LoB de consommer et d'utiliser ce produit de données. Celle-ci vise principalement le data steward persona, qui est chargé de rationaliser et de standardiser le processus de partage des données entre les producteurs et les consommateurs de données et d'assurer le respect des règles de gouvernance des données.

Dans le deuxième article, nous montrons un exemple de la façon dont un CoE d'analyse et de ML peut consommer le produit de données pour un cas d'utilisation de prédiction des risques. Cela cible principalement le personnage de scientifique des données, qui est chargé d'utiliser des actifs de données à l'échelle de l'organisation et de tiers pour créer et former des modèles ML qui extraient des informations commerciales pour améliorer l'expérience des clients des services financiers.

Présentation du maillage de données

La fondatrice du modèle de maillage de données, Zhamak Dehghani dans son livre Data Mesh offrant une valeur basée sur les données à grande échelle, a défini quatre principes vers l'objectif du maillage de données :

• Propriété de domaine distribué – Poursuivre un changement organisationnel de la propriété centralisée des données par des spécialistes qui exécutent les technologies de plate-forme de données vers un modèle de propriété des données décentralisé, repoussant la propriété et la responsabilité des données vers les LoB où les données sont produites (domaines alignés sur la source) ou consommées ( domaines alignés sur la consommation).
• Les données en tant que produit – Pousser en amont la responsabilité de partager des ressources de données organisées, de haute qualité, interopérables et sécurisées. Par conséquent, les producteurs de données de différents LoB sont chargés de créer des données sous une forme consommable directement à la source.
• Analyse en libre-service – Pour rationaliser l'expérience des utilisateurs de données d'analyse et de ML afin qu'ils puissent découvrir, accéder et utiliser des produits de données avec leurs outils préférés. En outre, pour rationaliser l'expérience des fournisseurs de données LoB pour créer, déployer et maintenir des produits de données via des recettes et des composants et modèles réutilisables.
• Gouvernance informatique fédérée - Pour fédérer et automatiser la prise de décision impliquée dans la gestion et le contrôle de l'accès aux données pour être au niveau des propriétaires de données des différents LoB, ce qui est toujours conforme aux politiques juridiques, de conformité et de sécurité de l'organisation au sens large qui sont finalement appliquées par le maillage.

AWS a présenté sa vision de la création d'un maillage de données au-dessus d'AWS dans divers articles :

• Tout d'abord, nous nous sommes concentrés sur la partie organisationnelle associée à la propriété de domaine distribué et aux données en tant que principes de produit. Les auteurs ont décrit la vision d'aligner plusieurs LOB à travers l'organisation vers une stratégie de produits de données qui fournit aux domaines alignés sur la consommation des outils pour trouver et obtenir les données dont ils ont besoin, tout en garantissant le contrôle nécessaire autour de l'utilisation de ces données en introduisant la responsabilité pour les domaines alignés sur la source pour fournir des produits de données prêts à être utilisés directement à la source. Pour plus d'informations, reportez-vous à Comment JPMorgan Chase a construit une architecture de maillage de données pour générer une valeur significative pour améliorer sa plate-forme de données d'entreprise.
• Ensuite, nous nous sommes concentrés sur la partie technique associée à la création de produits de données, à l'analyse en libre-service et aux principes de gouvernance informatique fédérée. Les auteurs ont décrit les principaux services AWS qui permettent aux domaines alignés sur la source de créer et de partager des produits de données, une grande variété de services qui peuvent permettre aux domaines alignés sur les consommateurs de consommer des produits de données de différentes manières en fonction de leurs outils préférés et des cas d'utilisation qu'ils utilisent. travaillent vers, et enfin les services AWS qui régissent la procédure de partage de données en appliquant des politiques d'accès aux données. Pour plus d'informations, reportez-vous à Concevoir une architecture de maillage de données à l'aide d'AWS Lake Formation et d'AWS Glue.
• Nous avons également présenté une solution pour automatiser la découverte de données et le contrôle d'accès via une interface utilisateur de maillage de données centralisée. Pour plus de détails, reportez-vous à Créez un flux de travail de partage de données avec AWS Lake Formation pour votre maillage de données.

Cas d'utilisation des services financiers

En règle générale, les grandes organisations de services financiers ont plusieurs LoB, tels que la banque de consommation, la banque d'investissement et la gestion d'actifs, ainsi qu'une ou plusieurs équipes d'analyse et de ML CoE. Chaque LoB propose différents services :

• Le LoB des services bancaires aux consommateurs fournit une variété de services aux consommateurs et aux entreprises, y compris le crédit et l'hypothèque, la gestion de trésorerie, les solutions de paiement, les produits de dépôt et d'investissement, etc.
• Le LoB de la banque commerciale ou d'investissement propose des solutions financières complètes, telles que les prêts, le risque de faillite et les paiements de gros aux clients, y compris les petites entreprises, les entreprises de taille moyenne et les grandes entreprises
• Le LoB de gestion d'actifs fournit des produits de retraite et des services d'investissement dans toutes les classes d'actifs

Chaque LoB définit ses propres produits de données, qui sont organisés par des personnes qui comprennent les données et sont les mieux placées pour spécifier qui est autorisé à les utiliser et comment elles peuvent être utilisées. En revanche, d'autres LoBs et domaines d'application tels que l'analyse et le ML CoE sont intéressés par la découverte et la consommation de produits de données qualifiés, en les mélangeant pour générer des informations et en prenant des décisions basées sur les données.

L'illustration suivante décrit certains LoB et des exemples de produits de données qu'ils peuvent partager. Il montre également les consommateurs de produits de données tels que l'analyse et ML CoE, qui créent des modèles ML qui peuvent être déployés sur des applications orientées client pour améliorer encore l'expérience du client final.

En suivant le concept socio-technique du maillage de données, nous commençons par l'aspect social avec un ensemble d'étapes organisationnelles, telles que les suivantes :

• Utilisation d'experts de domaine pour définir les limites de chaque domaine, afin que chaque produit de données puisse être mappé à un domaine spécifique
• Identifier les propriétaires des produits de données fournis par chaque domaine, afin que chaque produit de données ait une stratégie définie par son propriétaire
• Identifier les politiques de gouvernance à partir d'incitations mondiales et locales ou fédérées, de sorte que lorsque les consommateurs de données accèdent à un produit de données spécifique, la politique d'accès associée au produit peut être automatiquement appliquée via une couche centrale de gouvernance des données

Ensuite, nous passons à l'aspect technique, qui comprend le scénario de bout en bout suivant défini dans le schéma précédent :

1. Offrez au LoB des services bancaires aux consommateurs des outils pour créer un produit de données de profil de crédit à la consommation prêt à l'emploi.
2. Autoriser le LoB bancaire grand public à partager des produits de données dans la couche de gouvernance centrale.
3. Intégrez des définitions globales et fédérées des politiques d'accès aux données qui doivent être appliquées lors de l'accès au produit de données de profil de crédit des consommateurs via la gouvernance centrale des données.
4. Autorisez l'analyse et le ML CoE à découvrir et à accéder au produit de données via la couche de gouvernance centrale.
5. Renforcez l'analyse et le ML CoE avec des outils pour utiliser le produit de données pour créer et former un modèle de prévision du risque de crédit. Nous ne couvrons pas les étapes finales (6 et 7 dans le diagramme précédent) de cette série. Cependant, pour montrer la valeur commerciale qu'un tel modèle ML peut apporter à l'organisation dans un scénario de bout en bout, nous illustrons ce qui suit :
6. Ce modèle pourrait ensuite être déployé sur des systèmes destinés aux clients, tels qu'un portail Web bancaire grand public ou une application mobile.
7. Il peut être spécifiquement utilisé dans la demande de prêt pour évaluer le profil de risque des demandes de crédit et d'hypothèque.

Ensuite, nous décrivons les besoins techniques de chacun des composants.

Analyse approfondie des besoins techniques

Pour rendre les produits de données accessibles à tous, les organisations doivent faciliter le partage de données entre différentes entités au sein de l'organisation tout en maintenant un contrôle approprié sur celles-ci, ou en d'autres termes, pour équilibrer l'agilité avec une gouvernance appropriée.

Consommateur de données : Analytics et ML CoE

Les consommateurs de données tels que les scientifiques des données de l'analyse et du ML CoE doivent être en mesure de faire ce qui suit :

• Découvrir et accéder à des ensembles de données pertinents pour un cas d'utilisation donné
• Être sûr que les ensembles de données auxquels ils souhaitent accéder sont déjà organisés, à jour et ont des descriptions solides
• Demander l'accès aux ensembles de données d'intérêt pour leurs analyses de rentabilisation
• Utiliser leurs outils préférés pour interroger et traiter ces ensembles de données dans leur environnement pour ML sans avoir besoin de répliquer les données à partir de l'emplacement distant d'origine ou de se soucier des complexités d'ingénierie ou d'infrastructure associées au traitement des données physiquement stockées dans un site distant
• Soyez informé de toute mise à jour des données effectuée par les propriétaires des données

Producteur de données : propriété du domaine

Les producteurs de données, tels que les équipes de domaine de différents LoB dans l'organisation des services financiers, doivent enregistrer et partager des ensembles de données conservés contenant les éléments suivants :

• Métadonnées techniques et opérationnelles, telles que les noms et tailles des bases de données et des tables, les schémas de colonnes et les clés
• Métadonnées commerciales telles que la description, la classification et la sensibilité des données
• Suivi des métadonnées telles que l'évolution du schéma depuis le formulaire source vers le formulaire cible et tous les formulaires intermédiaires
• Métadonnées sur la qualité des données telles que les taux d'exactitude et d'exhaustivité et le biais des données
• Politiques et procédures d'accès

Celles-ci sont nécessaires pour permettre aux consommateurs de données de découvrir et d'accéder aux données sans s'appuyer sur des procédures manuelles ou avoir à contacter les experts du domaine du produit de données pour acquérir plus de connaissances sur la signification des données et comment y accéder.

Gouvernance des données : découvrabilité, accessibilité et auditabilité

Les organisations doivent équilibrer les agilités illustrées précédemment avec une atténuation appropriée des risques associés aux fuites de données. En particulier dans les secteurs réglementés comme les services financiers, il est nécessaire de maintenir une gouvernance centrale des données pour fournir un accès global aux données et un contrôle d'audit tout en réduisant l'empreinte de stockage en évitant plusieurs copies des mêmes données sur différents sites.

Dans les architectures de lac de données centralisées traditionnelles, les producteurs de données publient souvent des données brutes et transfèrent la responsabilité de la conservation des données, de la gestion de la qualité des données et du contrôle d'accès aux ingénieurs des données et de l'infrastructure au sein d'une équipe de plate-forme de données centralisée. Cependant, ces équipes de plate-forme de données peuvent être moins familières avec les différents domaines de données et compter toujours sur le soutien des producteurs de données pour être en mesure de gérer et de gérer correctement l'accès aux données en fonction des politiques appliquées à chaque domaine de données. En revanche, les producteurs de données eux-mêmes sont les mieux placés pour fournir des actifs de données sélectionnés et qualifiés et sont conscients des politiques d'accès spécifiques au domaine qui doivent être appliquées lors de l'accès aux actifs de données.

Vue d'ensemble de la solution

Le diagramme suivant montre l'architecture de haut niveau de la solution proposée.

Nous abordons la consommation de données par l'analyse et le ML CoE avec Amazone Athéna ainsi que Amazon Sage Maker in partie 2 de cette série.

Dans cet article, nous nous concentrons sur le processus d'intégration des données dans le maillage de données et décrivons comment un LoB individuel tel que l'équipe des données du domaine bancaire grand public peut utiliser des outils AWS tels que Colle AWS ainsi que Brassage de données AWS Glue pour préparer, organiser et améliorer la qualité de leurs produits de données, puis enregistrer ces produits de données dans le compte central de gouvernance des données via Formation AWS Lake.

Banque de consommation LoB (producteur de données)

L'un des principes fondamentaux du maillage de données est le concept de données en tant que produit. Il est très important que l'équipe des données du domaine bancaire grand public travaille à la préparation de produits de données prêts à être utilisés par les consommateurs de données. Cela peut être fait en utilisant des outils AWS d'extraction, de transformation et de chargement (ETL) comme AWS Glue pour traiter les données brutes collectées sur Service de stockage simple Amazon (Amazon S3), ou connectez-vous aux magasins de données opérationnelles où les données sont produites. Vous pouvez aussi utiliser Brassage de données, qui est un outil visuel de préparation de données sans code qui facilite le nettoyage et la normalisation des données.

Par exemple, lors de la préparation du produit de données sur le profil de crédit des consommateurs, l'équipe des données du domaine bancaire des consommateurs peut effectuer une simple curation pour traduire de l'allemand vers l'anglais les noms d'attribut des données brutes extraites de l'ensemble de données open source. Statlog Données de crédit allemandes, composé de 20 attributs et de 1,000 XNUMX lignes.

Gouvernance des données

Le service AWS principal pour activer la gouvernance du maillage de données est Lake Formation. Lake Formation offre la possibilité d'appliquer la gouvernance des données dans chaque domaine de données et entre les domaines pour garantir que les données sont facilement détectables et sécurisées. Il fournit un modèle de sécurité fédérée qui peut être administré de manière centralisée, avec les meilleures pratiques pour la découverte des données, la sécurité et la conformité, tout en permettant une grande agilité au sein de chaque domaine.

Lake Formation propose une API pour simplifier la manière dont les données sont ingérées, stockées et gérées, ainsi qu'une sécurité au niveau des lignes pour protéger vos données. Il fournit également des fonctionnalités telles que le contrôle d'accès granulaire, les tables gouvernées et l'optimisation du stockage.

De plus, Lake Formations offre un API de partage de données que vous pouvez utiliser pour partager des données sur différents comptes. Cela permet au consommateur d'analyse et de ML CoE d'exécuter des requêtes Athena qui interrogent et joignent des tables sur plusieurs comptes. Pour plus d'informations, reportez-vous au Guide du développeur AWS Lake Formation.

Gestionnaire d'accès aux ressources AWS (AWS RAM) offre un moyen sécurisé de partager des ressources via Gestionnaire d'identité et d'accès AWS Rôles et utilisateurs (IAM) sur les comptes AWS au sein d'une organisation ou d'unités organisationnelles (UO) dans Organisations AWS.

Lake Formation et AWS RAM offrent un moyen de gérer le partage et l'accès aux données entre les comptes AWS. Nous appelons cette approche Contrôle d'accès basé sur la RAM. Pour plus de détails sur cette approche, consultez Créez un flux de travail de partage de données avec AWS Lake Formation pour votre maillage de données.

Lake Formation offre également un autre moyen de gérer le partage et l'accès aux données en utilisant Balises de la formation du lac. Nous appelons cette approche contrôle d'accès basé sur des balises. Pour plus de détails, reportez-vous à Créez une architecture de données moderne et un modèle de maillage de données à grande échelle à l'aide du contrôle d'accès basé sur des balises AWS Lake Formation.

Tout au long de cet article, nous utilisons l'approche de contrôle d'accès basée sur les balises, car elle simplifie la création de politiques sur un plus petit nombre de balises logiques que l'on trouve couramment dans différents LoB au lieu de spécifier des politiques sur des ressources nommées au niveau de l'infrastructure.

Pré-requis

Pour configurer une architecture de maillage de données, vous avez besoin d'au moins trois comptes AWS : un compte producteur, un compte central et un compte consommateur.

Déployer l'environnement de maillage de données

Pour déployer un environnement de maillage de données, vous pouvez utiliser les éléments suivants GitHub référentiel. Ce dépôt contient trois AWS CloudFormation des modèles qui déploient un environnement de maillage de données qui inclut chacun des comptes (producteur, central et consommateur). Dans chaque compte, vous pouvez exécuter son modèle CloudFormation correspondant.

Compte central

Dans le compte central, procédez comme suit :

1. Lancez la pile CloudFormation:
   
2. Créez deux utilisateurs IAM :
   1. DataMeshOwner
   2. ProducerSteward
3. Subvention DataMeshOwner en tant qu'administrateur de Lake Formation.
4. Créez un rôle IAM :
   1. LFRegisterLocationServiceRole
5. Créez deux stratégies IAM :
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Créer la base de données credit-card pour ProducerSteward au compte du producteur.
7. Partagez l'autorisation d'emplacement des données avec le compte du producteur.

Compte producteur

Dans le compte du producteur, procédez comme suit :

1. Lancez la pile CloudFormation:
   
2. Créer le compartiment S3 credit-card, qui tient la table credit_card.
3. Autorisez l'accès au compartiment S3 pour le rôle de service Lake Formation du compte central.
4. Créer le robot d'exploration AWS Glue creditCrawler-<ProducerAccountID>.
5. Créez un rôle de service d'analyseur AWS Glue.
6. Accorder des autorisations sur l'emplacement du compartiment S3 credit-card-<ProducerAccountID>-<aws-region> au rôle d'analyseur AWS Glue.
7. Créez un utilisateur IAM producteur délégué.

Compte consommateur

Dans le compte personnel, procédez comme suit :

1. Lancez la pile CloudFormation:
   
2. Créer le compartiment S3 <AWS Account ID>-<aws-region>-athena-logs.
3. Créer le groupe de travail Athena consumer-workgroup.
4. Créer l'utilisateur IAM ConsumerAdmin.

Ajouter une base de données et y inscrire le compte consommateur

Après avoir exécuté les modèles, vous pouvez parcourir les étape par étape pour ajouter un produit dans le catalogue de données et y inscrire le consommateur. Le guide commence par créer une base de données où le producteur peut placer ses produits, puis explique comment le consommateur peut s'abonner à cette base de données et accéder aux données. Tout cela est effectué en utilisant Balises LF, qui est le contrôle d'accès basé sur des balises pour la formation du lac.

Enregistrement du produit de données

L'architecture suivante décrit les étapes détaillées de la manière dont l'équipe LoB de la banque grand public agissant en tant que producteur de données peut enregistrer ses produits de données dans le compte central de gouvernance des données (produits de données intégrés au maillage de données de l'organisation).

Les étapes générales pour enregistrer un produit de données sont les suivantes :

1. Créez une base de données cible pour le produit de données dans le compte de gouvernance central. Par exemple, le modèle CloudFormation du compte central crée déjà la base de données cible credit-card.
2. Partagez la base de données cible créée avec l'origine dans le compte producteur.
3. Créez un lien de ressource de la base de données partagée dans le compte du producteur. Dans la capture d'écran suivante, nous voyons sur la console Lake Formation dans le compte producteur que rl_credit-card est le lien de ressource du credit-card base de données.
   
4. Remplir les tables (avec les données conservées dans le compte du producteur) à l'intérieur de la base de données de liens de ressources (rl_credit-card) à l'aide d'un robot d'exploration AWS Glue dans le compte producteur.
   

La table créée apparaît automatiquement dans le compte de gouvernance central. La capture d'écran suivante montre un exemple de table dans Lake Formation dans le compte central. C'est après avoir effectué les étapes précédentes pour remplir la base de données de liens de ressources rl_credit-card dans le compte du producteur.

Conclusion

Dans la partie 1 de cette série, nous avons discuté des objectifs des organisations de services financiers pour obtenir plus d'agilité pour leurs équipes d'analyse et de ML et réduire le temps entre les données et les informations. Nous nous sommes également concentrés sur la création d'une architecture de maillage de données sur AWS, où nous avons introduit des services AWS faciles à utiliser, évolutifs et économiques tels qu'AWS Glue, DataBrew et Lake Formation. Les équipes de production de données peuvent utiliser ces services pour créer et partager des produits de données organisés, de haute qualité, interopérables et sécurisés, prêts à être utilisés par différents consommateurs de données à des fins d'analyse.

In partie 2, nous nous concentrons sur les équipes d'analyse et de ML CoE qui consomment des produits de données partagés par le secteur bancaire grand public pour créer un modèle de prédiction du risque de crédit à l'aide de services AWS tels qu'Athena et SageMaker.

---

À propos des auteurs

Karim Hammouda est un architecte de solutions spécialisé pour l'analyse chez AWS avec une passion pour l'intégration de données, l'analyse de données et la BI. Il travaille avec les clients AWS pour concevoir et créer des solutions d'analyse qui contribuent à la croissance de leur entreprise. Pendant son temps libre, il aime regarder des documentaires télévisés et jouer à des jeux vidéo avec son fils.

Hassan Poonawala est architecte principal de solutions spécialisées en IA/ML chez AWS, Hasan aide les clients à concevoir et à déployer des applications d'apprentissage automatique en production sur AWS. Il a plus de 12 ans d'expérience professionnelle en tant que scientifique des données, praticien en apprentissage automatique et développeur de logiciels. Dans ses temps libres, Hasan aime explorer la nature et passer du temps avec ses amis et sa famille.

Benoît de Patoul est architecte de solutions spécialisées en IA/ML chez AWS. Il aide les clients en fournissant des conseils et une assistance technique pour créer des solutions liées à l'IA/ML à l'aide d'AWS. Pendant son temps libre, il aime jouer du piano et passer du temps avec des amis.