Mercedes-Benz crée un maillage de données inter-cloud avec Delta Sharing et la réplication intelligente, réduisant les coûts de 66 %

Mercedes-Benz, l'une des marques automobiles de luxe les plus reconnues au monde, navigue actuellement à travers deux changements majeurs dans l'industrie : la numérisation et la transition vers les véhicules électriques. Cette ère est définie par le concept du "véhicule défini par les données".

• Du matériel aux données : Dans le passé, les véhicules étaient définis par leur matériel, puis par leur logiciel, mais l'industrie entre maintenant dans l'ère des véhicules définis par les données. Ce changement signifie que les données – y compris la télémétrie du véhicule et les informations client – sont l'actif principal qui stimule l'amélioration des produits et l'expérience client.
• Le besoin de partage de données : Pour construire ce véhicule défini par les données, diverses unités commerciales, comme la Recherche et Développement (R&D), l'Après-Vente et le Marketing, doivent pouvoir partager des données de manière transparente, sécurisée et rentable. Mercedes-Benz visait à remplacer les méthodes précédentes, peu sûres ou inefficaces comme les serveurs FTP et les e-mails pour le transfert de données, par une place de marché de partage de données robuste et centralisée.

Le défi critique est survenu de l'architecture multi-cloud de l'entreprise (AWS et Azure). Les consommateurs de données sur Azure avaient besoin d'accéder à de grands ensembles de données après-vente fréquemment mis à jour, principalement stockés dans AWS. Cet accès inter-cloud entraînait des coûts d'égress élevés et posait d'importants obstacles techniques pour garantir la fraîcheur des données.

Le défi commercial : Coûts d'égress élevés et silos de données

Mercedes-Benz exploite une configuration multi-cloud, utilisant AWS et Azure, ainsi qu'une configuration multi-régions au sein de ces clouds. Cette approche leur permet de sélectionner les services hyperscale qui correspondent le mieux aux exigences techniques spécifiques.

Un exemple crucial implique leurs données après-vente, qui comprennent des informations provenant des événements du véhicule en direct (over-the-air) et des visites à l'atelier. Ces données sont vitales pour améliorer les composants en recherche et développement (R&D) et pour analyser les cas de garantie.

• Volume de données : Les données après-vente principales sont substantielles, avec un sous-ensemble d'environ 60 To nécessaire pour servir des dizaines de cas d'utilisation exécutés sur Azure. Ce volume ne cesse de croître.
• Barrière de coût : Lorsque les consommateurs basés sur Azure interrogeaient directement ce grand ensemble de données résidant sur AWS, les coûts d'égress devenaient une considération pour les cas d'utilisation soucieux des coûts. Bien que l'accès direct convienne à certains besoins d'analyse en temps réel, l'équipe recherchait une approche plus économique pour les charges de travail moins sensibles au temps.
• Latence et fraîcheur des données : Avant la nouvelle solution, l'ensemble des données était souvent copié sous forme de chargement complet hebdomadaire. Les consommateurs de données demandaient des mises à jour plus fréquentes, mais les chargements complets quotidiens étaient trop coûteux. Un délai de sept jours pouvait être critique pour réagir aux cas de garantie.
• Compatibilité du format de données : Les données d'origine sur AWS étaient au format Iceberg, tandis que de nombreux consommateurs de données du côté Azure s'attendaient à un format compatible avec Delta.

La solution : Une stratégie hybride de Delta Sharing et de réplication

Mercedes-Benz a mis en œuvre une solution technique qui a combiné la capacité d'échange de données sécurisé de Databricks Delta Sharing avec un mécanisme de réplication locale contrôlée (Delta Deep Clone) pour résoudre les coûts d'égress récurrents associés au partage de grands ensembles de données très demandés.

Unity Catalog et Delta Sharing : Les fondations

La solution est ancrée dans la plateforme d'intelligence de données de Databricks, construite sur Unity Catalog (UC) et Delta Sharing.

• Unity Catalog (UC) : UC fonctionne comme le catalogue mondial pour tous les produits de données de l'entreprise. Il centralise les métadonnées, gère les accès et permet un modèle de gouvernance "hub-and-spoke", permettant aux données de devenir transparentes pour les autres tout en maintenant le contrôle. UC a également simplifié le processus en fédérant les tables d'AWS Glue, en les enregistrant directement dans Unity pour déclencher le partage de données.
• Delta Sharing : Delta Sharing sert de protocole ouvert pour l'échange sécurisé de données entre différents Metastore UC, à travers diverses régions et à travers les hyperscalers (AWS vers Azure). Il a été choisi car il s'agit d'une technologie open source prenant en charge les mises à jour incrémentielles des données.

Delta Sharing est utilisé dans trois configurations principales au sein du maillage de données de Mercedes-Benz :

1. Partage inter-cloud / inter-hyperscaler : C'est le cas d'utilisation principal, comblant le fossé entre AWS et Azure. Il exploite la plateforme Databricks unifiée des deux côtés pour utiliser la même technologie à travers les clouds.
2. Partage inter-régions / inter-metastore : Delta Sharing est utilisé en interne entre différentes régions du même cloud.
3. Partage externe : La solution permet de partager des données avec des partenaires externes, tels que des fournisseurs, qui peuvent également utiliser Databricks ou Delta Sharing. C'est une manière plus sécurisée de recevoir des données que d'échanger des secrets ou d'utiliser FTP.

Approche hybride : Réplication locale pour minimiser l'égress

Reconnaissant que tous les cas d'utilisation ne nécessitent pas une fraîcheur des données en temps réel, Mercedes-Benz a conçu une approche de réplication incrémentielle contrôlée pour les grands ensembles de données fortement consultés où l'efficacité des coûts était privilégiée par rapport à une fraîcheur inférieure à l'heure.

1. Partage inter-cloud : Delta Sharing est configuré entre le Metastore Fournisseur (AWS) et le Metastore Destinataire (Azure).
2. Tâche de synchronisation périodique : Des Tâches de synchronisation automatisées s'exécutent périodiquement, utilisant Delta Deep Clone pour persister des répliques des tables partagées dans le stockage objet du cloud destinataire (ADLS/S3).
3. Mises à jour incrémentielles : Deep Clone permet au processus de mettre à jour les données de manière incrémentielle, de sorte que l'ensemble des données n'est pas copié en permanence, ce qui permet de réduire les coûts.
4. Consommation locale : Les consommateurs de données sur Azure interrogent les données répliquées localement sur Azure, réduisant considérablement les mouvements de données inter-cloud et les coûts d'égress élevés associés.

Cette architecture reflète la force principale de Delta Sharing : la flexibilité permet aux utilisateurs de choisir entre une fraîcheur des données élevée avec un coût plus élevé (partages Delta directs) ou une fraîcheur des données faible avec un coût et une latence minimaux (données répliquées localement). Cette approche à plusieurs niveaux permet à Mercedes-Benz de répondre efficacement à divers cas d'utilisation.

Mise en œuvre technique et meilleures pratiques

L'équipe a eu la solution de bout en bout prête en quelques semaines seulement. Pour garantir la scalabilité, la sécurité et une gestion précise des coûts, Mercedes-Benz a intégré plusieurs meilleures pratiques opérationnelles et architecturales :

• Orchestrateur Dynamic Data eXchange (DDX) : DDX joue un rôle central en tant que méta-catalogue en libre-service. DDX automatise la gestion des autorisations (octroi d'autorisations via des microservices et des API Databricks), la gestion des tâches de synchronisation et les flux de travail de partage/réplication de données.
• Automatisation avec Databricks Asset Bundles (DABs) : Le déploiement des tâches de synchronisation et la configuration sont entièrement automatisés à l'aide de DABs et de déploiements pilotés par YAML via Azure DevOps. Cela garantit une approche DevOps complète et robuste.
• Suivi et attribution des coûts : Les tâches de synchronisation enregistrent la quantité exacte de données transférées. Une Tâche de reporting distincte agrège ces données quotidiennement pour calculer le coût d'égress approximatif par produit de données, qui est ensuite utilisé pour facturer les producteurs de données en amont. Ce tableau de bord des coûts suit également les coûts de calcul pour les tâches de synchronisation.
• RGPD et gouvernance : La solution répond aux préoccupations du RGPD en utilisant la fonctionnalité VACUUM de Delta Lake sur les tables répliquées, garantissant que les suppressions de données côté source se reflètent côté destinataire.

Bénéfices quantitatifs et ROI

La solution de maillage de données inter-cloud a généré des résultats commerciaux significatifs et mesurables, transformant le modèle économique du partage de données chez Mercedes-Benz.

1. Réduction des coûts d'exploitation / d'égress

En tirant parti des capacités de mise à jour incrémentielle de Delta Sharing et de la réplication intelligente via Deep Clone, Mercedes-Benz a optimisé la fraîcheur des données tout en réduisant les coûts d'égress.

• Réduction des coûts d'égress : Les coûts d'égress pour les 10 premiers produits de données ont diminué de 66 %.
• Retour sur investissement des sorties de données : Ceci représente une réduction d'environ deux tiers des coûts hebdomadaires de sortie de données. En considérant le même exemple de calcul pour 50 cas d'utilisation de la consommation directe de données à partir d'AWS, le coût annuel approximatif de sortie de données a été réduit de 93%.

2. Fraîcheur accrue des données et agilité commerciale

La capacité de synchroniser les données de manière incrémentielle a permis d'augmenter considérablement la fréquence des mises à jour pour les consommateurs Azure.

• Fraîcheur améliorée : Les consommateurs de données reçoivent désormais des données fraîches plus fréquemment (par exemple, tous les deux jours), au lieu d'attendre sept jours complets. Cela évite des retards critiques dans la réaction aux problèmes tels que les cas de garantie.

3. Coût d'exploitation informatique réduit

L'utilisation de Databricks Jobs entièrement Serverless pour le processus de synchronisation a réduit les dépenses de calcul et la surcharge opérationnelle.

• Stabilité opérationnelle : Les jobs s'exécutent "plus ou moins sans problème et sans aucune intervention", minimisant ainsi les coûts d'exploitation informatique.

Impact stratégique : Le véhicule défini par les données

Le cadre de partage de données centralisé et rentable est essentiel à la vision de Mercedes-Benz du "véhicule défini par les données".

Delta Sharing et le maillage de données qui en résulte aident à connecter des sources de données précédemment isolées, telles que les données après-vente, avec les collègues de la recherche et du développement, du marketing et des ventes. Cela crée une vision holistique du véhicule et du client, accélérant la mission de l'entreprise vers la numérisation et l'électrification de sa gamme de produits.

Vous voulez savoir comment Mercedes-Benz a tiré parti de la flexibilité de Delta Sharing pour optimiser son maillage de données inter-cloud ? Regardez la présentation d'Alexander Summa du Data + AI Summit :

Regardez la présentation sur YouTube

Dans cette session, vous en apprendrez davantage sur l'architecture technique, les défis de mise en œuvre et les leçons tirées du déploiement de cette solution à grande échelle.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original