Si vous n'avez pas lu la première partie sur les bases du calcul haute performance (HPC), consultez-la dès maintenant!
Bien que les logiciels de simulation d'ingénierie traditionnels excellent pour aider les ingénieurs mécaniques à préparer, exécuter et analyser des travaux de simulation, ils manquent d'une conception native pour gérer les flux de travail modernes de machine learning (ML) et les pipelines de données. Un lac de données ouvert peut combler cette lacune, en offrant aux ingénieurs de R&D des capacités robustes et contemporaines sur une plateforme que le département informatique connaît probablement déjà.
Les principaux cas d'utilisation et avantages d'un lakehouse de données ouvertes sont les suivants :
Archivage des données rentable et gouverné : offre un stockage pratiquement illimité et peu coûteux pour archiver des années de clichés de simulation (les ensembles de données générés par les sessions de résolution). Ce stockage est géré et gouverné de manière cohérente dans toutes les organisations ou équipes d'ingénierie et informatiques. Il est essentiel que les métadonnées essentielles et la traçabilité soient préservées pour chaque ensemble de données, le transformant d’un fichier opaque en un actif de confiance pouvant être facilement réutilisé au-delà de son créateur initial.
Accès simplifié aux ressources de calcul : Les ingénieurs peuvent facilement et rapidement déployer des notebooks partagés et des grappes Apache Spark ou Python Ray. Ces derniers partagent souvent les mêmes ressources GPU dédiées utilisées par la grappe HPC principale.
Protection via des normes ouvertes : un data lakehouse ouvert privilégie les normes ouvertes comme Apache Iceberg, Parquet et Python plutôt que les formats d’ingénierie propriétaires. Ceci est crucial pour la protection de la propriété intellectuelle (PI) d'une entreprise, en garantissant que les données de simulation restent accessibles et utilisables par n'importe quel outil, maintenant et à l'avenir, indépendamment de l'évolution de l'infrastructure informatique de l'entreprise ou de sa stratégie de fournisseur.
Une expérience PaaS de type cloud : les data lakehouses structurés comme des piles de plateformes en tant que service (PaaS) conviviales et en libre-service simplifient l’utilisation d’outils complexes d’ingénierie des données et de MLOps, comblant efficacement le fossé de connaissances entre les utilisateurs de différents horizons techniques et favorisant un échange productif de compétences.
Si un data lakehouse offre de nombreux avantages, il ne constitue pas en soi une solution complète pour les secteurs hautement réglementés (tels que l’aérospatiale, la défense, l’énergie et l’automobile), où la souveraineté est une exigence non négociable. Pour le dire simplement : tous les data lakehouses ne peuvent pas être déployés et exploités en conformité avec les mandats de souveraineté des données, et s’appuyer sur le cloud public comporte des risques importants pour maintenir le contrôle le plus strict sur la propriété intellectuelle exclusive.
Par exemple, un seul instantané d'un travail de dynamique des fluides computationnelle (CFD) — comme une nouvelle conception de moteur — représente efficacement le plan complet de ses performances et de sa conception industrielle ; cet ensemble de données est le joyau de la couronne d'une entreprise. Il est donc crucial de déterminer quelles capacités non fonctionnelles clés d’un data lakehouse peuvent fournir l’assurance juridique absolue de la souveraineté opérationnelle nécessaire pour stocker de tels actifs stratégiques. Cela nous amène directement au cœur du débat entre la résidence et la souveraineté.
La définition traditionnelle de la souveraineté, qui consiste à opérer dans le pays d'origine d'une entreprise, est une notion dépassée, vestige de l'ère pré-cloud. Auparavant, l'infrastructure des centres de données était généralement gérée par le personnel local, ce qui la soumettait à la juridiction locale de l'entreprise et à ses obligations légales. Cependant, l'essor des offres cloud commerciales et la nécessité pour les fournisseurs de garantir des objectifs de niveau de service extrêmement élevés 24 h/24 et 7 j/7 ont pleinement permis des opérations cloud globales à distance, suivant le soleil. Cette avancée rend impossible de garantir — du moins dans les régions aux normes commerciales standard — la résidence de l'équipe de gestion, rompant ainsi le lien entre la «résidence des données» et la véritable « souveraineté ».
Par conséquent, l'architecture la plus fiable pour la gestion et le traitement des données d'ingénierie critiques est un data lakehouse souverain : un data lakehouse ouvert qui est nativement hybride et indépendant du cloud.
Cette approche offre la rapidité et la facilité d'une expérience PaaS similaire au cloud, tout en intégrant une conformité par conception, permettant à une entreprise de respecter les politiques nationales ou d'autres juridictions qui exigeraient une opération entièrement au sein d'un environnement souverain, privé et contrôlé (y compris le personnel).
Durée |
Explication |
Impact métier |
Résidence des données |
Les données résident physiquement sur du matériel à l'intérieur des frontières géopolitiques d'un pays spécifique. |
Il gère les exigences locales de conformité de base, pas nécessairement liées à la sécurité, mais surtout à la latence entre les données elles-mêmes et les solutions informatiques consommant cet ensemble de données particulier. |
Souveraineté opérationnelle |
Garantit que les personnes gérant l'infrastructure cloud (Cloud Ops) et le cadre juridique régissant le fournisseur sont également locaux et sous la bonne gouvernance souveraine. |
Prévient le risque de demandes d’accès de gouvernements étrangers qui pourraient légalement contraindre le fournisseur à communiquer des informations de propriété intellectuelle sensibles sans le consentement de l’entreprise. |
Au-delà de la sécurité et de la conformité légale, une architecture de data lakehouse souveraine offre un autre avantage crucial : une gestion prévisible des coûts pour la mise en œuvre des workflows d'IA.
Le modèle financier de l'exploitation de services d'IA dans le cloud public est intrinsèquement variable et basé sur la consommation, liant les coûts directement aux paramètres d'utilisation (tels que les heures de GPU, les jetons traités, le volume opérationnel et les données numérisées). À mesure que davantage d'équipes, de projets et d'applications tirent parti de l'infrastructure cloud, les coûts augmentent de manière exponentielle. Ce modèle est particulièrement difficile pour les tâches à forte demande comme l'entraînement de modèles d'IA générative (GenAI) complexes ou d'auto-encodeurs lourds, qui nécessitent une utilisation dédiée, constante et massive des GPU, souvent difficile à partager efficacement.
La transition vers un data lakehouse souverain déployé dans un centre de données privé ou de colocation à coût fixe permet à une organisation de prévoir ses dépenses :
Investissement en actifs fixes : les organisations investissent dans des infrastructures physiques partageables. Cette configuration permet à de multiples équipes et projets d'utiliser les mêmes ressources, ce qui a pour effet de réduire à près de zéro le coût marginal du lancement de nouvelles expériences de recherche et développement (R&D).
Élimination du « bill shock » : cette architecture élimine totalement tout risque financier lié à des dépenses imprévues et massives, par exemple celles dues à une inférence à haut volume, à des boucles continues et itératives d’entraînement de R&D, ou à des frais de transfert de données prohibitifs, fréquents dans les zones du cloud public.
This may have been caused by one of the following: