• Le système d'acquisition de données de Meta, que nos équipes d'ingénierie utilisent pour les instantanés actuels du graphe social, a récemment subi une refonte majeure, améliorer sa fiabilité à grande échelle.
• Le passage de notre ancien système à notre nouvelle architecture a nécessité une migration à grande échelle de l'ensemble de notre système de collecte de données..
• Nous partageons les solutions et les stratégies, qui ont permis une migration système réussie à grande échelle, ainsi que les facteurs clés, qui a influencé nos décisions architecturales.

---

Chez Meta, la nôtre diagramme social est alimenté par l'un des les plus grands déploiements MySQL au monde. Chaque jour, notre système de collecte de données récupère progressivement plusieurs pétaoctets de données de graphiques sociaux de MySQL vers l'entrepôt de données., sur les analyses, Rapports et produits de données en aval, utiliser les équipes de toute l'entreprise pour les tâches, allant de la prise de décision quotidienne à la formation de modèles d'apprentissage automatique et au développement de produits.

Nous avons récemment révisé l'architecture de notre système de collecte de données, pour améliorer considérablement son efficacité et sa fiabilité. La nouvelle architecture s'éloigne des pipelines appartenant aux clients, qui a fonctionné efficacement à petite échelle, vers un service d’entrepôt de données autogéré plus simple, qui fonctionne toujours efficacement même dans le secteur hyperscale.

Nous avons 100 % La charge de travail a été convertie avec succès et l'ancien système a été complètement abandonné. Cependant, la migration d'un système de capture de données de cette envergure représentait un défi majeur. Plusieurs solutions et stratégies clés y ont contribué, qu'une migration dans cette zone a réussi.

Le défi migratoire

À mesure que notre entreprise grandissait, Notre ancien système de collecte de données a montré des signes d'instabilité en raison d'exigences de plus en plus strictes en matière de temps d'arrivée des données.. Nous savions, que nous avons dû migrer vers un nouveau système. Mais nous savions aussi, que cela signifiait plus que de simples défis, comment pouvons-nous garantir, que chaque commande puisse être exécutée correctement migré en toute transparence mais aussi comment réaliser soi-même une migration à grande échelle.

Assurer une transition fluide

Pour assurer une migration fluide, Nous devions suivre efficacement et déployer de manière robuste le cycle de vie de la migration pour des milliers d'emplois.- et configurer les contrôles de restauration, pour faire face à des problèmes, qui pourraient survenir pendant le processus de migration.

Le cycle de vie de la migration

Notre première étape était la suivante, Établir un cycle de vie clair pour le travail de migration, pour garantir l’intégrité des données et la fiabilité opérationnelle tout au long du processus.

L'exactitude de chaque travail devait être vérifiée et répondre à des critères de réussite définis., avant de passer à l'étape suivante du cycle de vie de la migration:

• Aucun problème de qualité des données. Il n'y a aucune différence entre les données fournies par l'ancien système et le nouveau système. Nous vérifions cela, en comparant à la fois le nombre de lignes et la somme de contrôle des données, garantissant ainsi une cohérence complète entre les deux systèmes.
• Aucune régression de la latence d'atterrissage n'est observée. Les données fournies par le nouveau système devraient avoir amélioré la latence d'atterrissage ou au moins correspondre aux performances de l'ancien système..
• Aucune régression dans l’utilisation des ressources n’est observée. Les râteaux- et l'utilisation de la mémoire du travail exécuté dans le nouveau système devrait être améliorée ou au moins comparable à celle de l'ancien système..
• Pour la migration des tables critiques, nous avons défini des critères de migration supplémentaires et convenu avec les équipes, qui dépendait du service.

Phase 1: La phase d'ombre

Dans la première étape du cycle de vie, nous mettons en place des travaux parallèles dans l'environnement de pré-production, qui sera fourni via le nouveau système. Il s'agit essentiellement d'un test réaliste de production, où chaque travail reflet consomme la même source que le travail de production, mais les données vers une autre table, la soi-disant table fantôme, livre. Cette configuration peut vous aider, découvrir des problèmes, car il expose le nouveau système à des données et à des comportements de production réels tout en fournissant un emplacement isolé, où les résultats peuvent être vérifiés et des corrections peuvent être apportées rapidement.

Nous avons surveillé en permanence le nombre de lignes et les écarts de somme de contrôle entre les tâches de production et les tâches fantômes.. Si des écarts se sont produits, nous avons rapidement enquêté sur la cause profonde, correctifs déployés puis sécurisés dans l'environnement de pré-production, que les écarts ont été corrigés.

Lors de cette étape nous avons aussi les râteaux- et les quotas de stockage pour les travaux parallèles ont été mesurés, pour assurer, que l'environnement de production dispose de ressources suffisantes, avant de continuer.

Si le travail parallèle répondait aux critères ci-dessus, il a été déplacé vers l'environnement de production et sécurisé, que le travail pourrait continuer à s'exécuter de manière fiable dans l'environnement de production, avant de passer à l'étape suivante.

Phase 2: La phase d'ombre inversée

Une fois que le travail de production et le travail reflet s'exécutaient de manière fiable dans l'environnement de production, nous avons commencé par la phase d'ombre inversée. Dans cette phase, les données du travail reflet ont été écrites dans la table de production, faire du travail fantôme le nouveau travail de production. Entre-temps, les données de l'ordre de fabrication ont été écrites dans la table fantôme., de sorte que l'ordre de production d'origine fonctionnait alors comme un ordre fantôme.

Cette approche offrait deux avantages clés. Premièrement, nous pourrions continuer à recevoir des signaux continus sur la qualité des données après le lancement., en poursuivant la comparaison des résultats des deux systèmes. Deuxièmement, si des écarts étaient identifiés, nous pouvions rapidement annuler, sans avoir à recréer ou configurer l'ancienne tâche système.

Phase 3: Nettoyage des migrations

Nous avons continué à surveiller et à comparer les données fournies par les deux emplois. Si aucune divergence n'a été constatée, Le travail reflet actuellement exécuté sur l'ancien système a été supprimé. Le nouveau système a ensuite pris le relais et a continué à fournir des données pendant le travail de production., qui a marqué l'achèvement de la migration.

Outils d'analyse de la qualité des données personnalisés

Nous avons également développé un ensemble complet d'outils de débogage, pour aider les membres de l'équipe avec cela, Problèmes, qui pourrait survenir lors de la migration, identifier et résoudre efficacement.

Nous avons développé un outil d'analyse de la qualité des données, pour assurer, que les cas extrêmes sont enregistrés et traités efficacement dans toutes les commandes. Pour chaque partition de table fantôme atterrie, le système lirait la partition de table de production correspondante et comparerait à la fois le nombre de lignes et la somme de contrôle.. Tous les écarts ont été enregistrés PlongerSystème de gestion de métadonnées pour une analyse en temps réel. L'outil d'analyse de la qualité des données lit les journaux de Scuba toutes les heures, requêtes effectuées, pour identifier des exemples de lignes, qui a provoqué des décalages, et enregistré des informations de débogage détaillées sur Scuba. Ce processus a permis aux membres de l'équipe, identifier et évaluer rapidement la cause profonde des problèmes, s'ils étaient déjà connus et corrigés.

Le même outil d'analyse de la qualité des données continue d'être utilisé après la migration dans le cadre du processus de validation des versions..

Gestion du déploiement et de la restauration

Nos anciens et nos nouveaux systèmes de capture de données utilisaient Change Data Capture (CDC), pour ajouter des données progressivement à la table cible. Chaque tâche d'ingestion de données possède sa propre table interne pour un vidage complet des bases de données sources. (décharge complète), une table interne pour enregistrer les modifications apportées aux bases de données sources (Delta) et la table cible utilisée par les clients de données. Toutes les informations sur les entités d'emploi, y compris les noms de table et les schémas de table, sont stockés et gérés par le service de gestion central.

Puisqu'il s'agit d'un processus CDC, les données générées par le système sont réutilisées, pour générer les nouvelles données. Cela signifie, si des problèmes surviennent avec les dates d'atterrissage précédentes, Les données problématiques sont transférées vers les nouvelles données d'atterrissage. Si des problèmes surviennent après la migration, nous devrions revenir en arrière, pour réparer les données débarquées et arrêter le saignement.

Pour réduire le risque, nous nous sommes concentrés sur deux solutions:

1. Premiers signaux, avant que les données problématiques ne parviennent au client de données.
2. Comment arrêter rapidement le saignement lors du recul.

Premiers signaux après le déploiement

Au lieu de l'attendre, que les consommateurs de données découvrent des problèmes avec des données problématiques, nous avons reçu des signaux précoces, qui nous signale, si la migration est réussie. Comme déjà mentionné, Après le déploiement, la migration est entrée dans la phase d'ombre inversée. Cela signifiait, que les données du travail reflet ont été écrites dans la table de production, faire du travail fantôme le nouveau travail de production. Et les données de l'ordre de fabrication ont été écrites dans la table fantôme, de sorte que l'ordre de production d'origine agit désormais comme un ordre fantôme.

Pour obtenir des signaux précoces, nous avons du remblai pour la production- ainsi que pour les travaux fantômes. Si les résultats du remplissage continuent de correspondre, cela signifie, que la migration a réussi. Si le résultat ne correspond pas, le travail est immédiatement réinitialisé et les consommateurs de données ne sont pas affectés.

Arrêtez rapidement la propagation des mauvaises données lors de la restauration

Comme déjà mentionné, est une caractéristique du processus CDC, que les données problématiques peuvent être transférées vers des données nouvellement générées. Arrêter rapidement la propagation des mauvaises données ne rend pas seulement la migration plus robuste, mais améliore également la fiabilité une fois la migration terminée.

Si des problèmes de qualité des données ont été détectés dans une partition particulière pendant la phase d'ombre inversée, Cette partition a été marquée comme partition avec des données de mauvaise qualité dans ses métadonnées. Si cette partition était une partition delta, Plus aucune nouvelle donnée n'atteindrait et une alerte serait envoyée à un membre de l'équipe. Si cette partition était une partition cible, le système sélectionnerait plutôt une partition plus ancienne et la fusionnerait avec plus de deltas.

Cela nous a permis d'arrêter rapidement la propagation de données incorrectes. Pour un rollback, nous pourrions rapidement interroger les métadonnées, pour trouver toutes les partitions, qui étaient marqués par des données de mauvaise qualité, et corrigez cela avec le remplissage.

Comment nous avons effectué la migration à grande échelle

Après avoir migré avec succès un petit nombre d'emplois, nous étions confiants, que nous ferions la migration complète. Les défis pourraient être grossièrement divisés en deux domaines:

1. Comment surveiller et migrer automatiquement un grand nombre de tâches. (Ce défi est causé par le volume considérable d’emplois, qui doivent être migrés, encore plus aggravé.)
2. Comment effectuer des tests fantômes efficaces avec une capacité limitée.

Surveillance avec des outils automatisés

Comme des dizaines de milliers de tâches d'enregistrement ont dû être migrées, nous avons développé des outils, qui ont automatisé l'ensemble du processus et minimisé les pertes par friction.

L'exécution de tests fantômes et la gestion des cas extrêmes sur un ensemble de tâches aussi important nécessitent une automatisation robuste et une validation approfondie., pour garantir la fiabilité et l'exactitude.

Comme nous avons établi un cycle de vie clair des emplois de migration et des critères d'éligibilité aux emplois, le système envoyait en permanence des signaux d'état du travail à Scuba, y compris des données sur les critères d'éligibilité du cycle de vie et l'étape actuelle de l'emploi dans le cycle de vie de la migration. Nous avons développé des outils de migration externes, qui surveillait en permanence les signaux de chaque tâche et activait automatiquement les tâches entre les phases du cycle de vie de la migration- ou déclassé, selon, s'ils répondaient aux critères de migration (ou n'est plus rempli). Nous avons également des tableaux de bord sur le système- et niveau d'emploi créé, afin que les ingénieurs puissent suivre rapidement la progression globale de la migration ainsi que surveiller et déboguer les tâches individuelles.

Planification avec une capacité limitée

Parce que la capacité de migration était limitée, nous ne pouvions pas exécuter tous les travaux parallèles en même temps. Au lieu de cela, nous avons migré les tâches par lots. L’efficacité de la migration en dépend fortement, comment les tâches sont sélectionnées pour chaque lot de migration.

Nous avons des commandes basées sur diverses caractéristiques telles que le débit, Les cas prioritaires et particuliers sont catégorisés. Les équipes techniques y travaillaient, assurer, que l'environnement a été correctement préparé, avant la création d'un lot. Par exemple, ils fixent des critères de sélection, pour les emplois avec des problèmes connus, cela restait encore à résoudre, et ainsi réduire le bruit causé par des doubles problèmes. Les commandes ont également été hiérarchisées en fonction des besoins de l'entreprise et des équipes., qui dépendait du service, ont été notifiés avant la migration.

Nous avons évité de créer de nouveaux travaux parallèles avec des problèmes connus, jusqu'à ce que ces problèmes soient résolus. Lorsqu'un problème a été détecté, Nous avons supprimé tous les emplois potentiellement concernés de la liste de migration et les avons retenus., jusqu'à ce qu'une solution soit trouvée.

Comme mentionné ci-dessus, En raison de la conception CDC du système, le premier instantané d'une nouvelle tâche a été obtenu via un vidage complet, ce qui est généralement lent et coûteux. Si nous avons détecté des problèmes de qualité des données dans un instantané obtenu, nous avons également déclenché un autre vidage complet, pour obtenir un instantané corrigé, une fois les bugs sous-jacents corrigés. Créer des jobs fantômes, alors que des problèmes connus existaient toujours, déclencherait donc de nombreux vidages complets inutiles, à la fois dans la création d’emplois et dans la restauration de la qualité des données. En évitant la création de ces emplois, Nous avons évité de grandes quantités de travail supplémentaire de vidage complet et amélioré l'efficacité de la migration.. Nous avons également développé des solutions créatives, comme réutiliser des partitions d'instantanés, qui étaient initialement fournis sous forme d'instantanés par l'ancien système, pour réduire la charge totale de vidage.

Remerciements

Nous tenons à remercier tous les membres de l'équipe et la direction, qui a contribué au succès de ce projet en Meta.