Li Auto x JuiceFS : Évolution et réflexion de Hadoop à Cloud Native

L'architecture technique de la voiture idéale à l'ère Hadoop

Tout d'abord, passez brièvement en revue le développement de la technologie des mégadonnées. D'après ma compréhension personnelle, le développement des mégadonnées est divisé en quatre périodes :

La première période : 2006 à 2008. Vers 2008, Hadoop est devenu le projet phare d'Apache et a officiellement publié la version 1.0. Sa base est principalement définie sur la base de la troïka de Google, GFS, MapReduce et BigTable.

La deuxième période : de 2009 à 2013. Des entreprises telles que Yahoo, Alibaba et Facebook utilisent de plus en plus le Big Data. Fin 2013, Hadoop a officiellement publié la version 2.0. J'ai eu la chance d'entrer en contact avec le Big Data en 2012, et j'en ai fait l'expérience avec Hadoop 1.0 plus Hive. À ce moment-là, je me sentais incroyable. Le Big Data peut résoudre rapidement des problèmes qui ne peuvent pas être résolus avec SQL Server ou MySQL avec quelques machines. .

La troisième étape : De 2014 à 2019, durant cette période de développement très rapide, durant laquelle Spark et Flink sont devenus les meilleurs projets Apache. Pendant cette période d'escalade rapide, nous avons également essayé d'utiliser Storm, qui a ensuite été remplacé par Flink.

La quatrième étape : de 2020 à aujourd'hui, après que Hudi a obtenu son diplôme d'Apache et est devenu un projet de haut niveau en 2020, je comprends personnellement que le lac de données est entré dans la phase de maturité de l'ensemble du développement et a atteint le stade du lac de données 2.0 de données volumineuses. Le lac de données a trois caractéristiques principales, d'une part, un stockage unifié et ouvert, d'autre part, un format ouvert, et des moteurs de calcul riches.

Dans le processus global de développement, le big data a principalement plusieurs caractéristiques, qui sont les quatre « V » que tout le monde dit souvent : volume, vélocité, variété et valeur. Maintenant, il y a un cinquième "V" (véracité), l'exactitude et la fiabilité des données. La qualité des données a toujours été critiquée. J'espère qu'il y aura un ensemble de normes dans l'industrie pour améliorer la qualité du lac de données. Cela peut être la norme pour l'émergence de Data Lake 2.0, car des projets tels que Hudi et Iceberg sont tous destinés à améliorer la qualité de l'ensemble du lac de données.La gestion du lac de données est bien faite.

Je pense personnellement que Hadoop est synonyme de big data, mais le big data n'est pas seulement Hadoop. Le big data est un ensemble de solutions permettant de traiter et d'exploiter une grande quantité de données constituées après l'intégration de multiples composants au cours du processus de développement . Au cours des dernières années, tout le monde croit fondamentalement que Hadoop est en train de se détériorer. Tout d'abord, la fusion et la radiation des sociétés de commercialisation Hadoop Cloudera et Hortonworks, le modèle commercial d'origine ne peut pas continuer ; les défis d'utilisabilité et la complexité croissante de l'écosystème Hadoop lui-même.

Architecture actuelle de la plate-forme Big Data d'Ideal Automobile

À ce stade, la plate-forme de données volumineuses de Li Auto est illustrée dans la figure ci-dessus. Ideal Car utilise de nombreux composants open source.

Couche transport : Kafka et Pulsar. Kafka a été utilisé dans son ensemble lors de la phase initiale de construction de la plate-forme. Les capacités natives du cloud de Kafka sont relativement faibles. Pulsar a été conçu selon l'architecture native du cloud au début de sa conception et possède certaines fonctionnalités très adaptées à l'IoT. scénarios, et cela correspond également à nos scénarios commerciaux. Par conséquent, nous avons récemment introduit Pulsar.
La couche de stockage est HDFS + JuiceFS.
Les principaux moteurs de calcul actuels de la couche de calcul sont Spark et Flink, et ces moteurs de calcul fonctionnent sur le Yarn actuel. Les trois moteurs de calcul sont gérés par Apache Linkis, qui est open source par WeBank, et actuellement nous utilisons beaucoup Linkis.
Sur la droite se trouvent trois bases de données. La première, MatrixDB, est une version commerciale de la base de données de séries chronologiques. TiDB est principalement utilisée pour les scénarios mixtes OLTP et OLAP. Actuellement, nous l'utilisons principalement pour les scénarios TP. StarRocks est responsable du scénario OLAP.
ShardingSphere souhaite utiliser son concept Database Plus pour unifier les bases de données sous-jacentes pour la gestion au niveau de la passerelle. Il est encore au stade exploratoire, et il y a beaucoup de nouvelles fonctionnalités qui nous intéressent beaucoup.
Plus à droite, Thanos est une solution de surveillance cloud native Nous avons intégré la surveillance des composants, des moteurs et des machines dans la solution Thanos.
La couche d'application est nos quatre principaux produits intermédiaires actuels, y compris l'application de données, le développement de données, l'intégration de données et la gouvernance des données.

caractéristiques

A travers le statu quo des plateformes de big data, on retrouve quelques caractéristiques :

Premièrement, il existe de nombreux composants dans l'ensemble de la solution, les utilisateurs dépendent fortement de ces composants et la dépendance mutuelle entre les composants est également relativement forte. Il est recommandé d'essayer de choisir des composants cloud natifs plus matures lors de la sélection de composants à l'avenir .
Deuxièmement, nos données ont des pics et des vallées clairs. La scène de voyage est généralement en pointe du matin et en pointe du soir, et il y aura plus de monde les samedis et dimanches.
La troisième caractéristique est que la popularité de nos données est fondamentalement la plus chaude, et nous n'accédons généralement qu'aux données des derniers jours ou de la semaine dernière. Cependant, une grande quantité de données est générée, et parfois une grande quantité de retour en arrière peut être nécessaire, de sorte que les données doivent également être stockées pendant une longue période, de sorte que le taux d'utilisation des données est bien pire.

Enfin, l'ensemble du système de données manque actuellement de méthodes de gestion efficaces au niveau des fichiers. De la construction à aujourd'hui, il est essentiellement basé sur HDFS, et il y a une grande quantité de données inutiles, ce qui entraîne un gaspillage de ressources.C'est un problème que nous devons résoudre de toute urgence.

Points faibles des plates-formes Big Data

Premièrement, il existe de nombreux composants, ce qui rend le déploiement difficile et inefficace . Il existe plus de 30 composants Big Data autour de Hadoop, et il y en a plus de 10 couramment utilisés. Il existe des dépendances fortes et faibles entre certains composants, et la configuration et la gestion unifiées deviennent très compliquées.
Deuxièmement, le coût de la machine et le coût de maintenance sont relativement élevés . Pour le fonctionnement stable de l'entreprise, les clusters hors ligne et en temps réel sont déployés séparément. Cependant, en raison des caractéristiques commerciales mentionnées ci-dessus, les hauts et les bas de notre activité sont évidents et le taux d'utilisation global n'est pas élevé. Un grand nombre de composants du cluster nécessitent du personnel spécialisé pour les gérer et les entretenir.
Troisièmement, les capacités de partage de données multiplateforme . Actuellement, les données partagées entre les clusters ne peuvent être synchronisées avec d'autres clusters Hadoop que via DistCp. Il ne peut pas être facilement et rapidement synchronisé avec d'autres plates-formes et serveurs.
Quatrièmement, la sécurité des données et le respect de la vie privée . Sur la base de différentes exigences de sécurité des données, les utilisateurs ordinaires sont gérés via Ranger, et les exigences de sécurité spéciales ne peuvent être satisfaites qu'en créant différents clusters et en définissant des politiques VPC distinctes, ce qui entraîne de nombreux îlots de données et des coûts de maintenance.

L'évolution et la pensée de l'idéal car cloud native

Tout d'abord, permettez-moi de partager brièvement ma compréhension personnelle du cloud natif :

Premièrement, le cloud native est dérivé du cloud computing. Désormais, tout le monde utilise des fournisseurs de cloud tels qu'Alibaba Cloud, AWS, Tencent Cloud, Baidu Cloud, etc., fournissant initialement des services techniques au niveau de la couche IaaS pour aider les entreprises à regrouper les éléments les plus élémentaires tels que le stockage, l'informatique et les réseaux pour une gestion unifiée. il suffit de demander un serveur dessus. Après avoir demandé des serveurs, ces serveurs sont toujours gérés par des fournisseurs de cloud, ce qui est notre opération cloud traditionnelle.

Le cloud natif est indissociable du cloud computing De manière générale, le cloud natif appartient au service de couche PaaS du cloud computing, qui est principalement un type d'application pour les développeurs. Le cloud natif doit être installé sur le cloud, et il s'agit d'une méthode de développement et d'application de logiciel basée sur le cloud. Cloud + natif, le cloud est le cloud computing, le natif consiste à abandonner le cadre de développement d'exploitation et de maintenance traditionnel, grâce à la conteneurisation, au DevOps et à l'architecture de micro-services pour obtenir une mise à l'échelle élastique et un déploiement automatique des applications, en utilisant pleinement les ressources du cloud computing pour atteindre dans le moindre espace faire la plus grande chose. Cela peut également résoudre certains problèmes de notre système de données volumineux actuel, tels que l'évolutivité et la maintenabilité médiocres, nécessitant beaucoup de main-d'œuvre et de temps.

La figure ci-dessus répertorie brièvement plusieurs points temporels de cloud natif

Dans une première étape, AWS a proposé le concept de cloud native, et a lancé EC2 en 2006. Cette étape est l'étape serveur, l'étape de cloud computing évoquée plus haut.
La deuxième étape, l'étape de cloudisation, se situe principalement après la sortie de l'open source Docker et de l'open source Kubernetes de Google. Kubernetes est une plate-forme open source légère et extensible pour la gestion des applications et des services conteneurisés. Le déploiement et la mise à l'échelle automatiques des applications peuvent être effectués via Kubernetes.
Dans la troisième étape, la Fondation CNCF a été créée en 2015 pour promouvoir les concepts cloud-native et aider le développement cloud-native dans son ensemble. Le dernier est l'open source de Knative.Un objectif très important de Knative est de développer des normes d'orchestration cloud-native et multiplateforme sans serveur. Dérivé jusqu'à présent, c'est déjà le stade du cloud natif 2.0, c'est-à-dire le stade du sans serveur. Personnellement, je comprends que le développement du big data doit également évoluer dans le sens du Serverless . Par exemple, l'ensemble du service en ligne d'AWS est essentiellement sans serveur.

Architecture native du cloud Big Data

Ensuite, permettez-moi de vous présenter les changements apportés aux composants de la plate-forme de big data automobile idéale après la nativeisation du cloud :

Au niveau de la couche de stockage, tout le stockage après la nativeisation du cloud est essentiellement un stockage d'objets. Le schéma d'architecture ci-dessus conduit à Lustre, qui sera décrit en détail ci-dessous. Vous pouvez comprendre que la couche "stockage cloud" utilise principalement JuiceFS pour gérer le stockage d'objets et le système de fichiers distribué parallèle Lustre (Remarque : en raison du problème de copie unique de Lustre, nous envisageons actuellement d'utiliser des systèmes de fichiers parallèles fournis par le produit des fournisseurs de services cloud).
La couche de conteneur, principalement au-dessus de l'informatique, du stockage et du réseau, est entièrement remplacée par Kubernetes plus Docker, et tous les composants y sont développés.
Pour la partie composant, le premier est le cadre de calcul du Big Data. Nous pouvons abandonner Hive, utiliser directement Spark et Flink, utiliser Hudi comme support de capacité sous-jacent de Data Lake 2.0 et remplacer progressivement HDFS.
Dans la partie middleware, en plus de Pulsar, il y a Kafka. Actuellement, la nativeisation cloud de Kafka n'est pas particulièrement bonne. Personnellement, je préfère remplacer Kafka par Pulsar. À l'heure actuelle, Linkis a été utilisé en ligne pour adapter tous les moteurs Spark, et Flink sera adapté et intégré ultérieurement. ShardingSphere vient de prendre en charge le cloud natif dans la version 5.1.2, et nous procéderons à la vérification des scénarios et à l'exploration des capacités comme prévu.
La couche de base de données est toujours TiDB, StarRocks et MatrixDB. À l'heure actuelle, ces trois bases de données ont déjà des capacités cloud natives et elles prennent toutes en charge le stockage d'objets. Mais cette pièce n'a pas été testée séparément, et nous utilisons toujours des machines physiques. Parce que pour la base de données, les capacités d'E/S fournies par le stockage d'objets actuel ne peuvent pas répondre aux exigences de performances de la base de données, ce qui réduira considérablement les performances globales de la base de données.
En termes d'exploitation et de maintenance, un Loki supplémentaire est ajouté à la solution Thanos, principalement pour la collecte de journaux native dans le cloud. Mais Loki et Thanos ne sont que deux d'entre eux. À l'avenir, je comprends qu'ils s'aligneront sur les capacités SREWorks open source d'Ali et scelleront la qualité, la rentabilité et la sécurité dans les capacités complètes d'exploitation et de maintenance, de sorte que l'ensemble la gestion cloud native peut être gérée de manière autonome.
L'observabilité, un concept récemment populaire dans le domaine du cloud natif. Certains des composants que tout le monde fabrique aujourd'hui commencent à se développer dans le cloud une fois qu'ils sont devenus populaires. Ils ne sont pas nés sur le cloud au départ, mais ils espèrent simplement se développer sur le cloud plus tard. Dans ce cas, il rencontrera quelques problèmes.Le premier problème est qu'il n'y a pas de surveillance complète de la visibilité. Nous examinons comment développer un plan pour ces composants dans leur ensemble à l'avenir, afin que tous les composants puissent être surveillés efficacement une fois qu'ils sont natifs du cloud.

Pour résumer, je pense personnellement que le futur cloud natif du big data c'est essentiellement :

Utilisation unifiée du stockage cloud natif comme stockage sous-jacent pour tous les composants (y compris les bases de données)
Tous les composants fonctionnent dans des conteneurs
Utiliser l'architecture sans serveur pour servir les applications de couche supérieure

Mais cela pose également des défis aux produits de plate-forme de données actuels, c'est-à-dire comment concevoir des produits avec des capacités sans serveur que les utilisateurs peuvent utiliser.

Avantages du Big Data Cloud Native

Le premier point est la séparation du stockage et du calcul, et de la dilatation et de la contraction élastiques . Après avoir utilisé des machines physiques pour déployer Hadoop, si vous avez besoin d'étendre ou de réduire la capacité, vous devez contacter l'opérateur, et le cycle peut être long. La séparation du stockage et du calcul résout bien ce problème. La seconde est la facturation à l'utilisation, sans acheter de ressources inutilisées. À l'heure actuelle, les données de l'ensemble de notre scénario d'entreprise connaissent des pics et des creux. Pendant les pics, les machines doivent être préparées et les machines doivent être retirées pendant les creux, mais ce n'est plus possible maintenant. Maintenant, nous empilons essentiellement toutes les machines jusqu'au pic. Pendant le pic, il peut répondre à la demande et est stable sans panne. Mais il est inactif pendant au moins 12 heures pendant la vallée. Dans ce cas, les ressources sont également facturées. Après le cloud natif, nous n'avons plus à payer pour cela.

Le deuxième point est le déploiement et l'opérabilité automatisés . Kubernetes prend en charge les solutions de déploiement intégré DevOps. De cette façon, nos composants dans leur ensemble peuvent être rapidement déployés (par exemple, via le graphique Helm), et les capacités d'exploitation et de maintenance des composants sont réduites à la plate-forme cloud native, de sorte que le Big Data n'a pas besoin de prendre en compte l'exploitation et la maintenance des composants. scénarios.

Le troisième point est le stockage d'objets . Le stockage d'objets est le produit de base et le plus important lancé par le cloud computing. Les avantages du stockage d'objets sont évidents, faciles à étendre, espace de stockage illimité, prix unitaire relativement bas, et le stockage d'objets est également divisé en stockage à basse fréquence, stockage d'archives et autres types de stockage, réduisant encore les coûts de stockage, les données peuvent être stocké plus longtemps. Dans le même temps, un coût contrôlable, une grande fiabilité et une faible complexité de fonctionnement sont également des avantages du stockage d'objets.

Le quatrième point est la sécurité et la conformité . Après le cloud natif, l'espace de noms dédié, l'isolement multi-locataire et l'authentification à distance peuvent être réalisés. À l'heure actuelle, ce que nous avons réalisé est essentiellement une isolation au niveau du réseau.La solution largement reconnue pour la gestion de fichiers HDFS est Ranger. L'utilisation de Ranger pour gérer les autorisations de répertoire HDFS peut également gérer certaines autorisations telles que le serveur Hive, HBase et Kafka, mais ces autorisations sont relativement faibles.

Une autre solution est Kerberos, la sécurité de l'ensemble du composant big data sera grandement améliorée, mais cela a beaucoup de coûts, et toute demande doit être vérifiée. Nous n'avons pas utilisé cette solution jusqu'à présent, et cela a quelque chose à voir avec notre environnement de cluster et nos scénarios.Nous sommes essentiellement sur l'intranet et ne fournissons pas de services externes. Si votre projet Big Data doit fournir certains services au réseau externe, vous devez toujours disposer d'une authentification forte, sinon les données seront facilement divulguées.

Les difficultés du Big Data Cloud Native

La difficulté du big data cloud native existe aussi.

Tout d'abord, il existe de nombreux composants liés au big data. Parallèlement, la mise à jour de Kubernetes est relativement rapide. Une fois les composants croisés, il y aura des problèmes de compatibilité, de complexité et d'évolutivité.

Deuxièmement, l'allocation et la réallocation des ressources. Kubernetes est un outil de planification des ressources de conteneur à usage général, et il est difficile de répondre aux scénarios d'utilisation des ressources des différents composants de Big Data. Dans un scénario Big Data, l'utilisation des ressources sera relativement importante, la fréquence des demandes sera élevée et le nombre de pods sera relativement important à chaque fois.Dans ce cas, il n'existe actuellement aucune bonne solution. Actuellement, nous examinons la solution de Fluid. Fluid implémente également le runtime de JuiceFS. C'est ce que nous étudierons plus tard. Fluid affirme actuellement qu'il peut prendre en charge le Big Data et l'IA, pas seulement les scénarios d'IA, car le Big Data et l'IA Les scénarios sont similaires, et ce sont toutes des opérations gourmandes en données. Fluid a fait quelques percées dans l'efficacité informatique et la gestion de l'abstraction de données.

Troisièmement, le stockage d'objets présente également certains inconvénients. Les inconvénients du stockage d'objets sont de faibles performances de fonctionnement des métadonnées, une mauvaise compatibilité avec les composants Big Data et une éventuelle cohérence.

Le dernier point concerne les applications gourmandes en données. Le mode de séparation stockage-informatique ne peut pas répondre aux exigences des applications gourmandes en données telles que les mégadonnées et l'IA en termes d'efficacité des opérations informatiques et de gestion de l'abstraction des données.

L'exploration et la mise en œuvre de JuiceFS dans les solutions cloud natives de big data

Avant l'open source de JuiceFS, nous avons prêté attention et effectué quelques tests d'atterrissage. Après le lancement de la version open source, nous l'utiliserons immédiatement. Lors de sa mise en ligne, j'ai également rencontré quelques problèmes d'autorisation et quelques petits bugs, la communauté m'a beaucoup soutenu et nous a aidé à les résoudre rapidement.

HDFS se déconnecte en raison de sa faible évolutivité, et en même temps, notre volume de données est relativement important et le coût de stockage de HDFS est relativement élevé. Après avoir stocké plusieurs lots de données, l'espace sur la machine physique n'est plus suffisant et de nombreux calculs sont nécessaires. A cette époque, notre développement commercial n'en était encore qu'à ses balbutiements, et afin de valoriser au maximum les données, nous souhaitions conserver le maximum de données. De plus, HDFS nécessite trois copies, nous l'avons changé plus tard en deux copies, mais deux copies sont toujours risquées.

Sur cette base, nous avons testé JuiceFS en profondeur. Une fois le test terminé, nous avons rapidement introduit JuiceFS dans notre environnement en ligne. La migration de certaines tables relativement volumineuses de HDFS vers JuiceFS a soulagé notre besoin urgent.

Nous apprécions trois points de JuiceFS :

Tout d'abord, JuiceFS est compatible multi-protocoles . Il est entièrement compatible avec les protocoles POSIX, HDFS et S3, et il est 100% compatible en utilisation courante sans aucun problème.
Deuxièmement, la capacité de traverser les nuages . Lorsqu'une entreprise a une certaine taille, afin d'éviter les risques systémiques, elle n'utilisera pas qu'un seul fournisseur de services cloud. Il ne sera pas lié à un seul cloud, il s'agira d'opérations multi-cloud. Dans ce cas, la capacité de JuiceFS à synchroniser les données entre les clouds joue un rôle.
Troisièmement, les scénarios natifs du cloud . JuiceFS prend en charge CSI. À l'heure actuelle, nous n'avons pas utilisé CSI dans ce scénario. Nous utilisons essentiellement POSIX pour le montage, mais l'utilisation de CSI sera plus simple et plus compatible. Nous développons également vers le cloud natif maintenant, mais l'ensemble du composant n'a pas vraiment arrivé à Kubernetes encore.

Application de JuiceFS dans Ideal Car

Conserver les données de HDFS vers le stockage d'objets

Après que JuiceFS soit devenu open source, nous avons commencé à essayer de synchroniser les données sur HDFS avec JuiceFS. Au début de la synchronisation, DistCp a été utilisé, il est très pratique de se synchroniser avec le SDK Hadoop de JuiceFS, et la migration globale est relativement fluide. La raison de la migration des données de HDFS vers JuiceFS est due à certains problèmes.

La première est que la conception de couplage stockage-informatique de HDFS a une faible évolutivité, et il n'y a aucun moyen de résoudre ce problème. Ma compréhension personnelle du big data depuis le tout début est que le big data doit être déployé sur des machines physiques, et non sur des hôtes cloud. Y compris les différents systèmes EMR lancés par les fournisseurs de cloud plus tard, ils encapsulent en fait Hadoop.Au cours des deux dernières années, ces systèmes EMR se sont progressivement dé-Hadoop.

La seconde est que HDFS est difficile à adapter à la nativeisation du cloud. Le HDFS actuel est difficile à adapter au cloud natif, car il est relativement lourd. Bien que la communauté se soit concentrée sur le cloud natif, je pense personnellement que la tendance de développement d'Hadoop est à la baisse, et que l'avenir devrait être basé sur le stockage d'objets.

Troisièmement, le stockage d'objets présente également certains inconvénients. Il ne peut pas être bien adapté à l'API HDFS. En raison du réseau et d'autres raisons, les performances sont également très différentes de celles des disques locaux. De plus, les opérations de métadonnées telles que les répertoires de liste sont également très lent. Nous utilisons JuiceFS pour faire quelques accélérations, et les performances mesurées sont très impressionnantes. C'est fondamentalement comparable au disque local dans le cas du cache. Sur cette base, nous basculons rapidement la scène actuelle directement vers JuiceFS.

Partage de fichiers au niveau de la plateforme

Le deuxième scénario est le partage de fichiers au niveau de la plate-forme. Toutes les données de fichiers partagés de notre système de planification actuel, de notre système en temps réel et de notre plate-forme de développement sont stockées sur HDFS. Si nous arrêtons d'utiliser HDFS plus tard, nous devrons migrer ces données. La solution actuelle est d'utiliser JuiceFS pour se connecter au stockage d'objets.Grâce au service de la couche application, tous sont montés en mode POSIX, et chacun peut demander les fichiers dans JuiceFS sans se sentir.

JuiceFS répond à la plupart des exigences de notre application dans ce scénario, mais il existe encore quelques petits scénarios qui posent problème. L'idée originale était d'y mettre tout l'environnement Python et autres. Plus tard, j'ai trouvé que l'opération réelle était trop difficile, car il y avait beaucoup de petits fichiers dans l'environnement Python, et il y avait encore des problèmes lors du chargement. Les scénarios tels que l'environnement Python qui contiennent un grand nombre de fichiers fragmentés doivent toujours être stockés sur le disque local pour fonctionner. À l'avenir, nous allons accrocher un morceau de stockage en bloc spécifiquement pour ce faire.

Partagez quelques problèmes que nous avons rencontrés avec HDFS auparavant :

Premièrement, lorsque le NameNode est sous forte pression ou Full GC, il y aura des échecs de téléchargement, et il n'y a actuellement pas de solution parfaite. Notre solution est d'augmenter la mémoire au maximum, ou d'ajouter quelques tentatives lors du téléchargement du package pour éviter sa période de pointe, mais il est difficile de résoudre complètement le problème de HDFS dans ce cas, car il est écrit en Java après tout, et le GC Il n'y a aucun moyen d'éviter la scène.

Deuxièmement, lors de l'utilisation de HDFS sur plusieurs systèmes, par exemple, si nous avons deux clusters, il est fondamentalement irréaliste d'utiliser un cluster pour partager des fichiers, car le réseau doit être ouvert pour connecter les deux clusters Ou passer par l'application, il y a donc aucun moyen de garantir la sécurité. À l'heure actuelle, nous avons essentiellement deux clusters qui gèrent indépendamment leurs propres fichiers partagés. Maintenant, la plate-forme en temps réel (telle que la plate-forme Flink) a été basculée sur JuiceFS, et elle est toujours très fluide et n'a rencontré aucun problème.

Troisièmement, nous avons actuellement un grand nombre de déploiements de machines physiques, qui sont toutes en cluster unique, sans stratégie de reprise après sinistre. Si un problème catastrophique survient dans la salle informatique, l'ensemble de notre service sera indisponible. Mais le stockage d'objets lui-même est inter-salle informatique, dans la même région, il devrait y avoir au moins trois copies, les fournisseurs de cloud nous aident à faire la sauvegarde. À l'avenir, nous pourrions développer plusieurs clouds, dans l'espoir d'utiliser JuiceFS pour partager des fichiers de haut niveau, des bases de données principales, y compris certains fichiers de sauvegarde principaux, et effectuer des sauvegardes dans plusieurs clouds. De cette manière, le multi-cloud, le multi-région et le multi-région sont réalisés, ce qui peut résoudre le problème de la reprise après sinistre à un seul point.

Utilisation multiplateforme de données massives

Dans un autre scénario, toutes les plates-formes partagent des données massives via JuiceFS. Le premier type de données partagées de notre côté sont les données d'essai routier. Il y aura une grande quantité de données vidéo, audio et image téléchargées pour l'essai routier. Après le téléchargement, ces données entreront directement dans JuiceFS, ce qui est pratique pour l'aval. Synchronisation et partage.Y compris un certain filtrage des données, puis obtenir PFS est un système de fichiers parallèle, sous lequel est monté SSD. Cela peut rendre l'utilisation du GPU plus élevée, car la capacité de stockage d'objets est relativement faible, sinon la capacité du GPU sera beaucoup gaspillée.

Les types de données restants comprennent certains journaux signalés par des véhicules pour analyse, des données de points enterrés et des données de signaux liés aux véhicules requises par certaines plates-formes nationales. Ces données seront saisies dans l'entrepôt de données pour une analyse. Nous effectuerons également une extraction de données de caractéristiques sur ces données, effectuerons une formation de modèle pour l'équipe d'algorithmes, ou effectuerons une récupération NLP et d'autres scénarios.

Cloud Native Storage Acceleration - Lustre en tant que cache de lecture (en cours de test)

Nous testons maintenant un autre scénario, qui consiste à accrocher un Lustre sur la couche de stockage d'objets pour servir de cache de lecture pour JuiceFS, et d'utiliser le cache de Lustre pour aider JuiceFS à améliorer la vitesse de lecture et le taux de réussite du cache.

L'un des avantages de cela est que nous utilisons maintenant des machines physiques, qui ont des disques physiques, qui peuvent être utilisés pour mettre en cache des données. Mais comme les tâches informatiques sont exécutées sur plusieurs nœuds, le taux de succès du cache n'est pas très élevé. En effet, la version communautaire de JuiceFS ne prend pas encore en charge la mise en cache distribuée P2P et ne prend en charge que la mise en cache locale à nœud unique, et chaque nœud peut lire beaucoup de données. Dans ce cas, une certaine pression disque est également causée sur le nœud de calcul, car le cache occupera une certaine quantité d'espace disque.

Notre solution actuelle consiste à utiliser Lustre comme cache de lecture de JuiceFS. Plus précisément, selon la taille des données à mettre en cache, montez un système de fichiers Lustre d'une capacité d'environ 20 à 30 To sur le nœud informatique local, puis utilisez ce point de montage Lustre comme répertoire de cache de JuiceFS. Dans ce cas, après que JuiceFS a lu les données, il peut les mettre en cache de manière asynchrone dans Lustre. Cette solution peut résoudre efficacement le problème du faible taux de réussite du cache et améliorer considérablement les performances de lecture.

Si nous écrivons des données directement dans le stockage d'objets dans le scénario Spark, il y aura des limitations de bande passante et de QPS. Si l'écriture est trop lente, les tâches en amont peuvent trembler. Dans ce cas, la fonction de cache d'écriture de JuiceFS peut être utilisée. vers Lustre d'abord, puis en écrivant de manière asynchrone vers le stockage d'objets, cette solution est applicable dans certains scénarios. Mais il y a un problème que Lustre n'est pas une solution cloud native, il est perçu par l'utilisateur, et l'utilisateur doit écrire explicitement une commande pour le monter lors du démarrage du pod. Par conséquent, nous espérons également apporter des modifications à JuiceFS à l'avenir, identifier automatiquement le stockage d'objets et Lustre, puis implémenter automatiquement certains mécanismes de mise en cache, afin que les utilisateurs n'aient pas besoin de percevoir l'existence de Lustre.

À l'heure actuelle, le PoC de cette solution est terminé et a passé le test de base. Ensuite, nous ferons de nombreux tests de pression dans l'environnement de production. Il est prévu qu'il soit officiellement lancé au troisième trimestre de cette année pour couvrir certains services de pointe. .

La solution globale de JuiceFS en cloud natif big data

Comme le montre le diagramme d'architecture de la solution globale, nous utilisons actuellement les trois méthodes fournies par le client JuiceFS.

Comme indiqué dans la moitié gauche de la figure ci-dessus, nous aurons des clusters Spark et Flink indépendants, et nous monterons directement JuiceFS sur l'ensemble du cluster via le pilote CSI, de sorte que lorsque les utilisateurs démarreront Spark et Flink, ils ne seront pas conscients de JuiceFS existe, et la lecture et l'écriture des tâches informatiques se font toutes via le stockage d'objets.

Cette section contient actuellement une question sur la lecture aléatoire. Étant donné que la tâche Spark nécessite l'écriture d'une grande quantité de données sur le disque pendant la phase de lecture aléatoire du processus de calcul, un grand nombre de demandes de lecture et d'écriture de fichiers générées pendant cette période ont des exigences de performances plus élevées pour le stockage sous-jacent. Flink est relativement meilleur car il est en streaming et ne nécessite pas un grand nombre de disques. À l'avenir, nous espérons que JuiceFS pourra écrire directement dans Lustre, mais cela nécessite quelques modifications dans JuiceFS. Grâce à l'intégration du client, JuiceFS peut directement lire et écrire Lustre. Cela ne sera pas perçu par les utilisateurs, et cela peut également améliorer la lecture aléatoire des étapes. et écrire des performances.

L'application dans la moitié droite de la figure ci-dessus comporte deux scénarios. La première consiste à interroger simplement les données JuiceFS, telles que la prévisualisation des données via HiveJDBC.Dans ce scénario, JuiceFS est accessible via la passerelle S3.

Le second est le scénario où la plateforme de big data et la plateforme d'IA sont liées. Par exemple, les collègues de la plate-forme d'IA ont souvent besoin de lire des exemples de données, des données de caractéristiques, etc. dans leur travail quotidien, et ces données sont généralement générées par des tâches Spark ou Flink sur la plate-forme Big Data, et ont été stockées dans JuiceFS. . Afin de partager des données entre différentes plates-formes, lorsque le pod de la plate-forme AI est démarré, JuiceFS sera directement monté sur le pod via FUSE, afin que les collègues de la plate-forme AI puissent accéder directement aux données dans JuiceFS via Jupyter pour créer des modèles La formation, au lieu de copier les données à plusieurs reprises entre différentes plates-formes comme l'architecture traditionnelle, améliore l'efficacité de la collaboration inter-équipes.

Parce que JuiceFS utilise des utilisateurs et des groupes d'utilisateurs standard POSIX pour le contrôle des autorisations, et que le conteneur démarre par défaut en tant qu'utilisateur root, ce qui rend difficile le contrôle des autorisations. Par conséquent, nous avons apporté une modification à JuiceFS pour monter le système de fichiers via un jeton d'authentification, qui contient les informations de connexion du moteur de métadonnées et d'autres informations de contrôle des autorisations. Dans certains scénarios où plusieurs systèmes de fichiers JuiceFS doivent être accessibles en même temps, nous utilisons la passerelle JuiceFS S3 combinée à des politiques IAM pour une gestion unifiée des autorisations.

Quelques difficultés rencontrées dans l'utilisation de JuiceFS à l'heure actuelle

Le premier point est que la fonction de gestion des autorisations basée sur les utilisateurs et les groupes d'utilisateurs est relativement simple.Dans certains scénarios, le conteneur démarre en tant qu'utilisateur root par défaut et les autorisations ne sont pas faciles à contrôler.

Le deuxième point concerne l'optimisation de la configuration de JuiceFS Hadoop SDK. À l'heure actuelle, nous avons principalement trois configurations pour optimiser le SDK JuiceFS Hadoop : juicefs.prefetch, juicefs.max-uploadset juicefs.memory-size. Certains problèmes ont été rencontrés lors du processus de réglage juicefs.memory-sizede la configuration La valeur par défaut de cette configuration est de 300 Mo. La suggestion officielle est de définir une mémoire hors tas qui est 4 fois la taille de la valeur par défaut, qui est de 1,2 Go. À l'heure actuelle, la plupart de nos tâches sont configurées sur 2 Go de mémoire hors tas, mais certaines tâches échouent parfois à écrire même si plus de 2 Go de mémoire sont configurés (HDFS peut écrire de manière stable). Cependant, ce n'est pas nécessairement un problème avec JuiceFS, il peut également être causé par Spark ou le stockage d'objets. Par conséquent, à l'heure actuelle, nous prévoyons également d'adapter en profondeur Spark et JuiceFS, puis d'en découvrir les raisons étape par étape, en essayant de surmonter tous ces pièges et de réduire la mémoire tout en assurant la stabilité des tâches.

Le troisième point est qu'à mesure que l'architecture globale (JuiceFS + stockage d'objets + Lustre) devient plus complexe, il y a plus de points de défaillance possibles, et la stabilité des tâches peut diminuer, ce qui nécessite d'autres mécanismes tolérants aux pannes pour garantir. Par exemple, pendant la phase d'écriture aléatoire de la tâche Spark, une erreur similaire à "tâche perdue" peut être signalée et la cause spécifique de l'erreur n'a pas encore été localisée.

La combinaison d'architecture de JuiceFS + stockage d'objets + Lustre mentionnée ci-dessus améliore les performances de lecture et d'écriture dans une certaine mesure, mais elle rend également l'architecture plus complexe et augmente en conséquence certains points de défaillance possibles. Par exemple, Lustre n'a pas une forte capacité de copie de reprise après sinistre. Si Lustre raccroche soudainement un nœud, les tâches en cours d'exécution peuvent-elles continuer à lire et écrire des données dans Lustre de manière stable, ou les données dans Lustre sont-elles accidentellement perdues ? Peut-il encore être stable Il est actuellement incertain d'aller à JuiceFS et de le réextraire via le stockage d'objets, et nous effectuons actuellement ce type de test catastrophique.

avenir et perspectives

Solution de lac de données en temps réel basée sur Flink + Hudi + JuiceFS

L'une des choses que nous ferons dans un avenir proche est la solution de lac de données en temps réel de Flink + Hudi + JuiceFS. Le côté gauche de la figure ci-dessus est la source de données. Via Flink, Kafka/Pulsar, les données sont écrites sur Hudi en temps réel. En même temps, les données de Hudi tomberont dans JuiceFS pour remplacer nos données en temps réel actuelles entrepôt.

Planification à long terme du big data cloud native

Enfin, je voudrais présenter le plan à long terme du cloud natif de big data idéal pour la voiture, qui est également une perspective.

Le premier point est un système unifié de gestion et de gouvernance des données. Nous pensons qu'à l'ère du lac de données 2.0, le plus gros problème à résoudre est de résoudre le problème du marais de données dans le scénario du lac de données 1.0. Mais maintenant, il semble qu'il n'y ait pas de meilleur produit open source pour la gestion unifiée des métadonnées, la gestion des répertoires de données et le contrôle de la sécurité des données, similaire à AWS Glue et AWS Lake Formation. Nous travaillons actuellement sur un projet de "système d'origine". La première étape de ce système consiste à gérer toutes les métadonnées dans la base de données ci-dessus et le stockage d'objets dans une gestion d'annuaire unifiée, un contrôle de sécurité unifié et une gestion des données unifiée. Nous tâtonnons notre chemin à suivre.

Le deuxième point concerne les capacités de stockage sous-jacentes plus rapides, plus stables et moins coûteuses. À l'heure actuelle, la plus grande difficulté dans tous les scénarios est le stockage d'objets. Les avantages du stockage d'objets sont la stabilité et le faible coût. Dans le même temps, le stockage d'objets est en constante itération. Pour l'instant, je pense que si le cloud natif du big data doit se développer, le stockage objet doit offrir de meilleures performances sous la prémisse d'assurer la stabilité.

Dans le même temps, S3 peut prétendre prendre en charge une cohérence forte, mais à l'heure actuelle, je comprends que la conception d'architecture basée sur le stockage d'objets peut être difficile à atteindre une cohérence forte, ou pour atteindre une cohérence forte, il est obligé de sacrifier certaines choses. Cela peut être un besoin Une question d'équilibre. JuiceFS prend en charge nativement une cohérence forte, ce qui est très convivial pour les plateformes de Big Data.

Le troisième point est un moteur de requête plus intelligent, plus efficace et plus facile à utiliser. Pour prolonger la réflexion sur l'intégration des lacs et des entrepôts mentionnée ci-dessus, l'intégration des lacs et des entrepôts en est encore aux premiers stades de développement, et cela peut prendre 5 à 10 ans de développement. Databricks et Microsoft tentent de construire un moteur MPP vectorisé sur le lac de données, espérant promouvoir l'architecture intégrée du lac et de l'entrepôt. Cela peut être une future direction de développement, mais il semble qu'il n'y ait aucun moyen d'utiliser un moteur pour répondre aux besoins de tous les scénarios en peu de temps.

Notre architecture actuelle est essentiellement équipée de tous les moteurs de requête, tels que Spark, Flink, une base de données relationnelle (pour les scénarios OLTP), une base de données de séries chronologiques et une base de données OLAP. En principe, il vaut mieux utiliser celui qui est le meilleur, et notre couche supérieure le gérera via un middleware unifié. Un autre exemple est Snowflake. Bien qu'il prenne déjà en charge la requête de données structurées et semi-structurées en même temps, on ne sait toujours pas comment prendre en charge les données non structurées (telles que les images, la voix et la vidéo) impliquées dans l'intelligence artificielle à l'avenir. clair. Cependant, je pense qu'il s'agit certainement d'une future direction de développement. Li Auto a également un scénario d'intelligence artificielle similaire, nous allons donc explorer et construire avec diverses parties commerciales.

Enfin, l'objectif ultime de l'ensemble du développement du Big Data est de réaliser l'analyse des données au moindre coût et avec les meilleures performances, afin de réaliser une véritable valeur commerciale .

Si vous êtes utile, veuillez prêter attention à notre projet Juicedata/JuiceFS ! (0ᴗ0✿)