Comment YouTube enregistre-t-il des fichiers vidéo volumineux ?

Bonjour à tous, je m'appelle Bucai Chen~

YouTube est le deuxième site Web le plus populaire après Google. En mai 2019, plus de 500 heures de contenu vidéo étaient mises en ligne chaque minute sur la plateforme.

La plateforme de partage de vidéos compte plus de 2 milliards d'utilisateurs, avec plus d'un milliard d'heures de vidéo jouées chaque jour, générant des milliards de vues. Ce sont des chiffres incroyables.

Cet article fournira une explication détaillée de la base de données et de l'infrastructure de données back-end utilisée par YouTube, qui permet à la plate-forme vidéo de stocker une telle quantité de données et de s'adapter à des milliards d'utilisateurs.

Alors commençons.

1. Introduction

Le parcours de YouTube a commencé en 2005. Alors que la startup technologique financée par du capital-risque continuait de connaître du succès, elle a été rachetée par Google en novembre 2006 pour 1,65 milliard de dollars. Avant d'être acquis par Google, leur équipe était composée de:

deux administrateurs système

• Deux architectes logiciels d'évolutivité
• deux développeurs de fonctionnalités
• deux ingénieurs réseau
• un nom dba
• 2. Les microservices backend sont écrits en Python, base de données, matériel, Java (en utilisant le framework Guice) et Go. L'interface utilisateur est écrite en JavaScript.

La base de données principale est MySQL prise en charge par Vitess. Vitess est un système de cluster de bases de données utilisé pour l'expansion horizontale de MySQL. De plus, utilisez Memcache pour la mise en cache et Zookeeper pour la coordination des nœuds.

Les vidéos populaires sont diffusées via un CDN, tandis que les vidéos générales, moins lues, sont extraites de la base de données.

Lorsque chaque vidéo est téléchargée, elle recevra un identifiant unique et sera traitée par une tâche par lots. Cette tâche exécutera plusieurs processus automatisés, tels que la génération de vignettes, de métadonnées, de scripts vidéo, l'encodage, la définition du statut de monétisation et bien plus encore.

Les codecs de codage vidéo avancé VP9 et H.264/MPEG-4 AVC sont utilisés pour la compression vidéo et sont capables d'encoder des vidéos de qualité HD et 4K en utilisant la moitié de la bande passante des autres encodeurs.

Le streaming vidéo utilise le streaming adaptatif dynamique basé sur le protocole HTTP, qui est une technologie de streaming à débit adaptatif qui peut obtenir un streaming vidéo de haute qualité à partir d'un serveur Web HTTP traditionnel. Grâce à cette technologie, le contenu peut être diffusé aux téléspectateurs à différents débits. Le client YouTube adapte automatiquement le rendu vidéo à la vitesse de connexion Internet du spectateur pour minimiser les temps de mise en mémoire tampon.

J'ai déjà discuté du processus de transcodage vidéo de YouTube dans un article dédié, voir « Comment YouTube fournit des vidéos de haute qualité avec une faible latence ».

Voici donc une brève introduction à la technologie backend de la plateforme. La principale base de données utilisée par YouTube est MySQL. Voyons maintenant pourquoi l’équipe d’ingénierie de YouTube a ressenti le besoin d’écrire Vitess ? Quels ont été les problèmes rencontrés avec leur environnement MySQL d’origine qui les ont amenés à implémenter un framework supplémentaire par-dessus ?

3. Pourquoi avez-vous besoin de Vitess

Le site Web ne dispose initialement que d'une seule instance de base de données. À mesure que le site Web se développe, les développeurs doivent étendre horizontalement la base de données afin de répondre aux exigences croissantes en matière de QPS (requêtes par seconde).

3.1 Réplique maître-esclave

La réplique sera ajoutée à l'instance de base de données maître. Les demandes de lecture sont acheminées vers la base de données principale et les réplicas afin de réduire la charge sur la base de données principale. L'ajout de répliques permet d'atténuer les goulots d'étranglement, d'augmenter le débit de lecture et d'augmenter la durabilité du système.

Le nœud maître gère le trafic d'écriture, et le nœud maître et le nœud de réplique gèrent le trafic de lecture en même temps.

Cependant, dans ce scénario, il est possible de lire des données obsolètes à partir de la réplique. Si une requête lit les données de la réplique avant que le maître ne mette à jour les informations sur la réplique, le visualiseur obtiendra des données obsolètes.

À l'heure actuelle, les données du nœud maître et du nœud réplica sont incohérentes. Dans ce cas, les données incohérentes correspondent au nombre de vues d'une vidéo spécifique sur les nœuds principal et réplica.

En fait, cela ne pose aucun problème. Les téléspectateurs ne verront pas d'inconvénient à une légère incohérence dans le nombre de vues, n'est-ce pas ? De plus, la vidéo peut être rendue dans leur navigateur.

Les données entre le nœud maître et le nœud réplica seront finalement cohérentes.

Les ingénieurs étaient donc très heureux et le public était également très heureux. Avec l’introduction des répliques, les choses vont bien.

Le site Web continue d'être populaire et le QPS continue d'augmenter. La stratégie de réplique maître-esclave a désormais du mal à suivre la croissance du trafic des sites Web.

Que faire maintenant ?

3.2 Sharding

La stratégie suivante consiste à partitionner la base de données. Le partage est l'un des moyens d'étendre les bases de données relationnelles en plus des répliques maître-esclave, des répliques maître-maître, des fédérations et de la dénormalisation.

Le partitionnement de base de données n'est pas un processus simple. Cela augmente considérablement la complexité du système et rend la gestion plus difficile.

Cependant, la base de données doit être fragmentée pour répondre à la croissance du QPS. Une fois que les développeurs ont partitionné la base de données, les données sont réparties sur plusieurs machines. Cela augmente le débit d'écriture du système. Désormais, au lieu d’une seule instance principale gérant les écritures, les opérations d’écriture peuvent se produire sur plusieurs machines partitionnées.

De plus, des copies distinctes sont créées pour chaque machine pour des raisons de redondance et de débit.

La popularité de la plateforme continue d'augmenter, de grandes quantités de données étant ajoutées à la base de données par les créateurs de contenu.

Afin d'éviter la perte de données ou l'indisponibilité du service causée par une panne de machine ou des événements externes inconnus, il est nécessaire d'ajouter des fonctions de gestion des catastrophes au système.

3.3 Gestion des catastrophes

La gestion des catastrophes fait référence aux mesures d'urgence face aux pannes de courant et aux catastrophes naturelles (telles que tremblements de terre, incendies). Il doit être redondant et sauvegarder les données des utilisateurs dans des centres de données situés dans différentes zones géographiques du monde. La perte des données utilisateur ou l'indisponibilité du service n'est pas autorisée.

Le fait d'avoir plusieurs centres de données dans le monde aide également YouTube à réduire la latence du système, car les demandes des utilisateurs sont acheminées vers le centre de données le plus proche au lieu d'être acheminées vers des serveurs d'origine situés sur différents continents.

Maintenant, vous pouvez imaginer à quel point l’infrastructure peut devenir complexe.

Souvent, des analyses de table complètes non optimisées provoquent le blocage de l'ensemble de la base de données. Les bases de données doivent être protégées des mauvaises requêtes. Tous les serveurs doivent être suivis pour garantir un service efficace.

Les développeurs ont besoin d'un système qui fait abstraction de la complexité du système, leur permet de résoudre les problèmes d'évolutivité et gère le système à un coût minimal. Tout cela a amené YouTube à développer Vitess.

4.Vitess : Un système d'expansion horizontale du cluster de bases de données MySQL

Vitess est un système de cluster de bases de données fonctionnant sur MySQL qui permet à MySQL de s'étendre horizontalement. Il dispose de fonctionnalités de partitionnement intégrées qui permettent aux développeurs de faire évoluer la base de données sans avoir à ajouter de logique de partitionnement à l'application. Ceci est similaire à ce que fait NoSQL.

Vitess gère également automatiquement le basculement et la sauvegarde. Il gère les serveurs et améliore les performances des bases de données en réécrivant intelligemment les requêtes gourmandes en ressources et en implémentant la mise en cache. Outre YouTube, le framework est également utilisé par d'autres acteurs bien connus du secteur, tels que GitHub, Slack, Square, New Relic, etc.

Vitess entre en jeu lorsque vous avez besoin de prise en charge des transactions ACID et d'une forte cohérence, et que vous souhaitez en même temps faire évoluer une base de données relationnelle aussi rapidement qu'une base de données NoSQL.

Sur YouTube, chaque connexion MySQL entraîne une surcharge de 2 Mo. Chaque connexion a un coût calculé, et à mesure que le nombre de connexions augmente, de la RAM supplémentaire doit être ajoutée.

Vitess est capable de gérer ces connexions à un coût très faible grâce à un pool de connexions construit sur la prise en charge de la concurrence du langage de programmation Go. Il utilise Zookeeper pour gérer le cluster et le maintenir à jour.

5. Déployer sur le cloud

Vitess est natif du cloud et est bien adapté au déploiement dans le cloud, car tout comme le modèle cloud, la capacité est progressivement ajoutée à la base de données. Il peut fonctionner comme une base de données distribuée cloud native compatible Kubernetes.

Chez YouTube, Vitess s'exécute dans un environnement conteneurisé et utilise Kubernetes comme outil d'orchestration de conteneurs.

À l’ère informatique d’aujourd’hui, tous les services à grande échelle s’exécutent dans le cloud dans un environnement distribué. L’exécution de services dans le cloud présente de nombreux avantages.

Google Cloud Platform est un ensemble de services de cloud computing basés sur la même infrastructure que celle utilisée par les produits internes des utilisateurs finaux de Google tels que la recherche Google et YouTube.

Chaque service en ligne à grande échelle possède une architecture de persistance polyglotte car un modèle de données, qu'il soit relationnel ou NoSQL, ne peut pas gérer tous les scénarios d'utilisation du service.

Lors de la recherche de cet article, je n'ai pas pu trouver de liste de bases de données Google Cloud spécifiques utilisées par YouTube, mais je suis presque sûr qu'elle utilise des produits spécifiques à GCP tels que Google Cloud Spanner, Cloud SQL, Cloud Datastore, Memorystore, etc. Différentes fonctionnalités des services en cours d’exécution.

Cet article détaille les bases de données utilisées par d'autres services Google, tels que Google Adwords, Google Finance, Google Trends, etc.

6.CDN

YouTube utilise le réseau mondial de Google pour diffuser du contenu à faible latence et à faible coût. Avec des points périphériques POP distribués à l’échelle mondiale, il permet aux clients d’obtenir des données plus rapidement sans avoir à les récupérer depuis le serveur d’origine.

Jusqu'à présent, j'ai parlé des bases de données, des frameworks et des technologies utilisés par YouTube. Il est désormais temps de parler de stockage.

Comment YouTube stocke-t-il une telle quantité de données (500 heures de contenu vidéo téléchargé chaque minute) ?

7. Stockage des données : Comment YouTube stocke-t-il une telle quantité de données ?

Les vidéos seront stockées sur les disques durs des centres de données Google. Ces données sont gérées par Google File System et BigTable.

GFS Google File System est un système de fichiers distribué développé par Google pour gérer des données à grande échelle dans des environnements distribués.

BigTable est un système de stockage de données distribué à faible latence construit sur Google File System, utilisé pour traiter des données au niveau PB distribuées sur des milliers de machines. Il est utilisé dans plus de 60 produits Google.

La vidéo est donc stockée sur le disque dur. Les relations, les métadonnées, les préférences utilisateur, les informations de profil, les paramètres de compte, les données associées nécessaires pour extraire la vidéo du stockage, etc. sont tous stockés dans MySQL.

7.1 Serveurs commerciaux plug-and-play

Les centres de données de Google disposent d'un matériel homogène et le logiciel est conçu en interne pour gérer des milliers de clusters de serveurs indépendants.

Les serveurs déployés par Google peuvent améliorer les capacités de stockage du centre de données. Ce sont tous des serveurs commerciaux (serveurs de base), également appelés serveurs commerciaux prêts à l'emploi (serveurs commerciaux prêts à l'emploi). Ces serveurs sont peu coûteux, largement disponibles et achetés en grandes quantités, et peuvent remplacer ou configurer le même matériel dans le centre de données à un coût et des dépenses minimes.

À mesure que le besoin de stockage supplémentaire augmente, de nouveaux serveurs de base sont connectés au système.

Après l'apparition de problèmes, les serveurs commerciaux sont généralement remplacés directement au lieu d'être réparés. Ils ne sont pas fabriqués sur mesure et leur utilisation permet aux entreprises de réduire considérablement les coûts d'infrastructure par rapport à l'utilisation de serveurs sur mesure.

7.2 Disques de stockage conçus pour les centres de données

YouTube nécessite plus d'un pétaoctet de nouveau stockage chaque jour. Les disques durs rotatifs constituent le principal support de stockage en raison de leur faible coût et de leur grande fiabilité.

Les disques SSD SSD ont des performances supérieures aux disques rotatifs car ils sont basés sur des semi-conducteurs, mais l'utilisation de SSD à grande échelle n'est pas rentable.

Ils sont assez chers et sujets à la perte de données au fil du temps. Cela les rend impropres au stockage de données d’archives.

De plus, Google développe une nouvelle série de disques adaptés aux centres de données à grande échelle.

Il existe cinq indicateurs clés qui peuvent être utilisés pour juger de la qualité du matériel conçu pour le stockage de données :

• Le matériel doit être capable de prendre en charge des opérations d'entrée et de sortie à grande vitesse de l'ordre de quelques secondes.
• Il doit être conforme aux normes de sécurité précisées par l'organisation.
• Il devrait avoir une capacité de stockage plus élevée que le matériel de stockage ordinaire.
• Le coût d'achat du matériel, le coût de l'électricité et le coût de maintenance devraient tous être acceptables.
• Les disques doivent être fiables et stables en termes de latence.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!