Barry Art

Préface

Le passage d'un modèle d'usine de données à une architecture de lac de données représente un changement majeur dans la manière dont les organisations gèrent et exploitent leurs actifs de données. Cet article présente les considérations stratégiques, les contraintes opérationnelles et les risques de défaillance liés à cette transition, notamment dans le contexte du National Institute of Standards and Technology (NIST). En tirant parti des technologies avancées des lacs de données, les organisations peuvent valoriser leurs ensembles de données existants tout en garantissant la conformité et la gouvernance des données.

Définition

Un lac de données est défini comme un référentiel centralisé permettant le stockage à grande échelle de données structurées et non structurées, et facilitant ainsi l'analyse avancée et l'apprentissage automatique. À l'inverse, une usine de données se concentre généralement sur le traitement et la transformation des données pour des applications spécifiques. La compréhension de ces définitions est essentielle pour les décideurs d'entreprise confrontés à la complexité de la gestion des données.

Réponse directe

La transition stratégique d'une usine de données vers un lac de données est essentielle pour les organisations souhaitant moderniser leur infrastructure de données. Cette transition permet une plus grande évolutivité, une meilleure gouvernance des données et une exploitation efficace des ensembles de données existants. Toutefois, elle exige une planification rigoureuse et la prise en compte des contraintes opérationnelles afin de garantir la conformité et la qualité des données.

Pourquoi maintenant

L'urgence de la transition vers une architecture de lac de données est dictée par le volume et la variété croissants des données générées par les organisations. Les systèmes existants peinent souvent à absorber cet afflux, ce qui entraîne une sous-utilisation des ressources de données. De plus, les contraintes réglementaires et le besoin de capacités d'analyse avancées imposent une approche de gestion des données plus flexible et évolutive. Les organisations doivent agir sans tarder pour ne pas prendre de retard dans leur stratégie de données.

Tableau de diagnostic

Question Impact Stratégie d'atténuation
Les taux d'ingestion de données ont dépassé la capacité de traitement. Retards dans la disponibilité des données Mettre en œuvre des cadres d'ingestion évolutifs
Les contrôles de conformité ne sont pas automatisés. Augmentation des erreurs manuelles Adopter des outils de conformité automatisés
Les formats de données hérités posent des problèmes d'intégration Incompatibilité avec les systèmes modernes Normaliser les formats de données lors de la migration
Suivi insuffisant de la lignée des données Défis liés aux processus d'audit Mettre en œuvre des solutions robustes de suivi de lignage
Les politiques de rétention ne sont pas appliquées de manière uniforme. Risque de non-conformité Établir des politiques de rétention claires
Les contrôles d'accès des utilisateurs ne sont pas adaptés à la confidentialité des données. Violations de données potentielles Examiner régulièrement les contrôles d'accès

Sections analytiques approfondies

Transition stratégique de Data Factory vers Data Lake

La transition stratégique d'une usine de données vers un lac de données implique plusieurs considérations essentielles. Les lacs de données offrent une évolutivité pour les données non structurées, un atout de plus en plus important à mesure que les organisations collectent des données de types variés. Cependant, cette transition exige une planification rigoureuse afin de garantir la conformité aux cadres réglementaires et de préserver la qualité des données. Les jeux de données existants peuvent être efficacement exploités dans un lac de données, mais les organisations doivent relever les défis liés à leur intégration dans une nouvelle architecture.

Contraintes opérationnelles liées à la mise en œuvre d'un lac de données

La mise en place d'un lac de données s'accompagne de contraintes opérationnelles que les organisations doivent gérer. La gouvernance des données doit être une priorité afin de garantir la conformité aux réglementations telles que le RGPD et la loi HIPAA. De plus, l'intégration de données existantes peut engendrer des problèmes de qualité des données, ce qui nécessite des processus robustes de nettoyage et de validation. Les implications financières du stockage et du traitement doivent également être évaluées, car les organisations peuvent être confrontées à des dépenses imprévues lors de la mise en œuvre.

Risques stratégiques et coûts cachés

La transition vers une architecture de lac de données introduit des risques stratégiques et des coûts cachés que les organisations doivent prendre en compte. Par exemple, le choix entre des solutions sur site et des solutions cloud implique d'évaluer l'infrastructure existante, les contraintes budgétaires et les besoins d'évolutivité. Les coûts cachés peuvent inclure la maintenance des solutions sur site ou les frais potentiels de transfert de données pour les options cloud. Les organisations doivent réaliser des analyses coûts-avantages approfondies afin d'éviter les pièges financiers.

Modes de défaillance lors de la migration d'un lac de données

Plusieurs modes de défaillance peuvent compromettre le succès d'une migration vers un lac de données. La perte de données pendant la migration peut être due à des procédures de sauvegarde inadéquates, entraînant la perte définitive de données critiques. Des manquements à la conformité peuvent résulter d'un défaut de mise en œuvre des contrôles de gouvernance des données nécessaires, ce qui peut engendrer des amendes réglementaires et nuire à la réputation de l'organisation. Il est donc essentiel de comprendre ces modes de défaillance pour élaborer des stratégies d'atténuation efficaces.

Cadre de mise en œuvre

Un cadre de mise en œuvre efficace pour la transition vers un lac de données doit inclure les composantes suivantes : un modèle de gouvernance des données clair, des processus d’ingestion de données automatisés et des évaluations robustes de la qualité des données. Les organisations doivent également établir des politiques de conservation des données claires et les réviser régulièrement afin de garantir leur conformité avec l’évolution de la réglementation. En intégrant ces composantes, les organisations peuvent créer une architecture de lac de données résiliente qui répond à leurs besoins opérationnels.

Intégration de solution

L'intégration d'une solution de lac de données aux systèmes existants exige une planification et une exécution rigoureuses. Les organisations doivent évaluer leurs flux de données actuels et identifier les points de blocage potentiels liés à l'intégration. L'utilisation d'outils facilitant une intégration fluide peut contribuer à atténuer ces difficultés. Par ailleurs, les organisations doivent prioriser la formation du personnel afin de garantir sa capacité à gérer efficacement la nouvelle architecture.

Scénario d'entreprise réaliste

Prenons l'exemple d'une agence gouvernementale, comme le National Institute of Standards and Technology (NIST), qui souhaite moderniser ses pratiques de gestion des données. L'agence a accumulé d'immenses quantités de données anciennes, sous-exploitées en raison de systèmes obsolètes. En adoptant une architecture de lac de données, le NIST peut améliorer ses capacités d'analyse, renforcer sa conformité aux réglementations fédérales et exploiter des ensembles de données auparavant inaccessibles. Toutefois, l'agence doit composer avec les contraintes opérationnelles et les risques de défaillance pour garantir la réussite de cette transition.

QFP

Q : Quel est le principal avantage de la transition vers un lac de données ?
A : Le principal avantage réside dans la capacité à stocker et à analyser de grands volumes de données structurées et non structurées, permettant des capacités d'analyse avancée et d'apprentissage automatique.

Q : Quels sont les principaux défis liés à la mise en œuvre d'un lac de données ?
A: Les principaux défis consistent à garantir la qualité des données, à assurer la conformité aux réglementations et à intégrer les ensembles de données existants dans la nouvelle architecture.

Q : Comment les organisations peuvent-elles atténuer les risques pendant la transition ?
A: Les organisations peuvent atténuer les risques en mettant en œuvre des cadres de gouvernance des données robustes, en menant des analyses coûts-avantages approfondies et en établissant des politiques claires de conservation des données.

Mode de défaillance observé en lien avec le sujet de l'article

Lors d'une récente transition d'une architecture de fabrique de données vers une architecture de lac de données, nous avons rencontré une défaillance critique dans nos mécanismes d'application de la gouvernance, notamment autour de application de la conservation légale pour les actions liées au cycle de vie du stockage d'objets non structurésAu départ, nos tableaux de bord indiquaient que tous les systèmes étaient opérationnels, mais à notre insu, le plan de contrôle divergeait déjà du plan de données, entraînant des conséquences irréversibles.

La première anomalie est survenue lorsque nous avons constaté un problème de propagation des métadonnées de conservation légale entre les versions d'objets. Ce problème est resté silencieux : nos outils de surveillance n'ont émis aucune alerte et les données semblaient intactes. Cependant, lors de la récupération d'objets pour des audits de conformité, nous avons constaté que plusieurs éléments clés, notamment les étiquettes d'objets et les indicateurs de conservation légale, avaient dévié. Le problème a été mis en évidence lors de la tentative d'accès à un objet marqué pour conservation légale, mais devenu inaccessible suite à des purges de cycle de vie effectuées sans application correcte de l'état de conservation.

Cette situation a été aggravée par le découplage de l'exécution du cycle de vie et de l'état de conservation légale, ce qui a engendré un scénario où les marqueurs de suppression étaient présents alors que les objets avaient été purgés. La reconstruction de l'index n'a pas permis de prouver l'état antérieur des données, rendant impossible toute restauration. Ce défaut de gouvernance n'était pas une simple négligence technique ; il constituait une contrainte opérationnelle majeure, soulignant la nécessité d'une intégration plus étroite entre le plan de contrôle et le plan de données.

Il s'agit d'un exemple hypothétique ; nous ne citons pas de clients ou d'institutions figurant au classement Fortune 500 à titre d'exemples.

  • fausse hypothèse architecturale
  • Qu'est-ce qui a cassé en premier ?
  • Leçon d'architecture générale liée à l'article « Moderniser les données sous-utilisées : passer de l'usine de données au lac de données »

Perspective unique tirée de « » sous les contraintes de « Modernisation des données sous-utilisées : transition de l’usine de données au lac de données »

L'un des principaux enseignements de cet incident réside dans l'importance d'une articulation étroite entre les contrôles de gouvernance et la gestion du cycle de vie des données. Le modèle de « séparation des rôles » entre le plan de contrôle et le plan de données lors de la récupération réglementée illustre comment un manque de synchronisation peut engendrer des défaillances catastrophiques en matière de conformité. Les organisations doivent s'assurer que leurs mécanismes de gouvernance sont non seulement en place, mais également appliqués rigoureusement tout au long du cycle de vie des données.

La plupart des équipes ont tendance à négliger la nécessité d'une validation continue des états de gouvernance au regard de l'état réel des données. Cette négligence peut engendrer des risques importants de non-conformité, notamment dans les environnements réglementés où l'intégrité des données est primordiale. Il est essentiel de gérer avec soin le compromis entre efficacité opérationnelle et contrôle de la conformité afin d'éviter de tels écueils.

Test EEAT Ce que font la plupart des équipes Ce qu'un expert fait différemment (sous la pression réglementaire)
Quel facteur donc ? On suppose que la conformité est maintenue lors de la configuration initiale Auditer et valider régulièrement les états de conformité aux conditions de données
Preuves d'origine S'appuyer sur des processus automatisés sans contrôles manuels Mettre en place des points de contrôle manuels pour vérifier l'application des règles de gouvernance.
Delta unique / Gain d'information Privilégier la disponibilité des données plutôt que la conformité Faire de la conformité un élément central de la stratégie de gestion des données

La plupart des directives publiques ont tendance à omettre le besoin crucial d'une validation continue de la gouvernance, ce qui peut entraîner de graves manquements à la conformité si ce problème n'est pas traité de manière proactive.

Références

  • NISTSP 800-53Conseils pour la mise en œuvre de contrôles efficaces de gouvernance des données.
  • ISO 15489 : Normes relatives aux politiques de gestion et de conservation des documents.
Barry Art

Barry Art

Vice-président du marketing, Solix Technologies Inc.

Barry Art Il dirige les initiatives marketing chez Solix Technologies, où il traduit les défis complexes liés à la gouvernance des données, à la mise hors service des applications et à la conformité en stratégies claires pour les clients figurant au classement Fortune 500.

Expérience en entreprise : Barry avait auparavant travaillé avec IBM zSeries écosystèmes soutenant l'activité mainframe multimilliardaire de CA Technologies, avec une exposition pratique à l'économie des infrastructures d'entreprise et aux risques liés au cycle de vie à grande échelle.

Référence orale vérifiée : Inscrit comme panéliste au programme du symposium sur l'IA explicable et sécurisée de l'UC San Diego ( Consulter l'agenda au format PDF ).

AVERTISSEMENT : LE CONTENU, LES POINTS DE VUE ET LES OPINIONS EXPRIMÉS DANS CE BLOG SONT LA RESPONSABILITÉ EXCLUSIVE DES AUTEURS ET NE REFLÈTENT PAS LA POLITIQUE OU LA POSITION OFFICIELLE DE SOLIX TECHNOLOGIES, INC., DE SES SOCIÉTÉS AFFILIÉES OU DE SES PARTENAIRES. CE BLOG EST EXPLOITÉ DE MANIÈRE INDÉPENDANTE ET N'EST NI RÉVISÉ NI APPROUVÉ PAR SOLIX TECHNOLOGIES, INC. À TITRE OFFICIEL. TOUTES LES MARQUES, LOGOS ET DOCUMENTS PROTÉGÉS PAR LE DROIT D'AUTEUR TIERS MENTIONNÉS DANS CE BLOG APPARTIENNENT À LEURS PROPRIÉTAIRES RESPECTIFS. TOUTE UTILISATION EST STRICTEMENT À DES FINS D'IDENTIFICATION, DE COMMENTAIRE OU ÉDUCATIVES CONFORMÉMENT À LA DOCTRINE DE L'US FAIR USE (US COPYRIGHT ACT § 107 ET ÉQUIVALENTS INTERNATIONAUX). AUCUN PARRAINAGE, AUCUNE APPROBATION OU AFFILIATION AVEC SOLIX TECHNOLOGIES, INC. N'EST IMPLICITE. LE CONTENU EST FOURNI « EN L'ÉTAT », SANS GARANTIE D'EXACTITUDE, D'EXHAUSTIVITÉ OU D'ADÉQUATION À UN USAGE PARTICULIER. SOLIX TECHNOLOGIES, INC. DÉCLINE TOUTE RESPONSABILITÉ POUR LES ACTIONS PRISES SUR LA BASE DE CE MATÉRIEL. LES LECTEURS ASSUMENT L'ENTIÈRE RESPONSABILITÉ DE LEUR UTILISATION DE CES INFORMATIONS. SOLIX RESPECTE LES DROITS DE PROPRIÉTÉ INTELLECTUELLE. POUR SOUMETTRE UNE DEMANDE DE RETRAIT DMCA, ENVOYEZ UN E-MAIL À INFO@SOLIX.COM AVEC : (1) L'IDENTIFICATION DE L'ŒUVRE, (2) L'URL DU MATÉRIEL CONTREFAÇANT, (3) VOS COORDONNÉES ET (4) UNE DÉCLARATION DE BONNE FOI. TOUTE RÉCLAMATION VALIDE RECEVRA UNE EXAMEN RAPIDE. EN ACCÉDANT À CE BLOG, VOUS ACCEPTEZ CET AVIS DE NON-RESPONSABILITÉ ET NOS CONDITIONS D'UTILISATION. CE CONTRAT EST RÉGI PAR LES LOIS DE LA CALIFORNIE.