320 To de données sont ajoutés quotidiennement après la migration de ClickHouse vers ByConity, les performances des requêtes sont très stables !

Wuhan Yuan Chuanghui revient, parlons de grands modèles le 20 avril »

Introduction au contexte

ByConity convient à une variété de scénarios commerciaux et offre de très bonnes performances en matière d'accès aux données en temps réel, de requêtes d'agrégation de tables volumineuses et larges, d'analyses et de calculs complexes sous des données massives et de requêtes de corrélation multi-tables. Utilisons un scénario commercial réel pour présenter ce système d'analyse du comportement. Ce système d'analyse du comportement est basé sur une plate-forme d'analyse du comportement des utilisateurs multidimensionnelle et fournit plusieurs méthodes et scénarios d'analyse tels que l'analyse des événements, l'analyse de la rétention, l'analyse des conversions, le regroupement des utilisateurs et fidélisation des utilisateurs. Cet article présentera les problèmes et les défis rencontrés par cette plateforme d'analyse multidimensionnelle du comportement des utilisateurs lors de l'utilisation du cluster ClickHouse d'origine, et comment résoudre ces problèmes et apporter des avantages à l'entreprise après la migration de ByConity.

Figure 1. Conception de l'architecture du système d'analyse du comportement

enjeux et défis

Au début, ce système était déployé dans le cluster ClickHouse. D'une part, en raison du développement rapide de l'entreprise, la quantité de données augmentait de jour en jour. Le nombre maximal de nouvelles données quotidiennes dépassait 320 To. les nouvelles lignes ont dépassé 2 300 milliards et les dimensions des données utilisateur ont dépassé 20 000. Multiples ; et fournir des résultats de réponse rapides. De plus, à mesure que la quantité de données continue d'augmenter (croissance annuelle de 35 %), nous devons non seulement être en mesure de relever les défis posés par une augmentation aussi importante des données, mais également contrôler le taux de croissance des coûts dans une certaine fourchette.

Mais il nous est difficile de faire cela sur le cluster ClickHouse existant. La raison en est que ClickHouse est basé sur une architecture Shared-Nothing. Chaque nœud est indépendant et ne partage pas les ressources de stockage. Par conséquent, les ressources informatiques et les ressources de stockage sont étroitement couplées, ce qui entraînera les problèmes suivants :

Le coût de l'augmentation et de la réduction devient plus élevé et implique une migration de données, ce qui nous empêche d'augmenter et de réduire en temps réel selon les besoins, ce qui entraîne également un gaspillage de ressources et des coûts incontrôlables.
Une architecture étroitement couplée amènera les locataires multiples à interagir les uns avec les autres dans un environnement de cluster partagé, ce qui entraînera une influence mutuelle des requêtes des utilisateurs.
Puisque la lecture et l’écriture des nœuds du cluster s’effectuent sur le même nœud, la lecture et l’écriture s’influencent mutuellement.
La prise en charge des performances pour les requêtes complexes telles que les opérations de jointure multi-tables n'est pas très bonne et ne peut pas répondre aux divers besoins des utilisateurs en matière de requêtes.

Sélection technologique

Par conséquent, début 2022, l’entreprise a commencé à utiliser ByConity avec une architecture de séparation de calcul et de stockage comme principal moteur OLAP. ByConity est un entrepôt de données cloud natif open source qui adopte une architecture de séparation du stockage informatique et prend en charge plusieurs fonctionnalités clés, telles que la séparation du stockage informatique, l'expansion et la contraction élastiques, l'isolation des ressources multi-locataires et une forte cohérence de la lecture et de l'écriture des données. . En utilisant les optimisations du moteur OLAP traditionnelles, telles que le stockage de colonnes, l'exécution vectorisée, l'exécution MPP, l'optimisation des requêtes, etc., ByConity peut fournir d'excellentes performances de lecture et d'écriture.

Figure 2 Schéma d'architecture technique à trois couches ByConity

ByConity est une mise à niveau basée sur l'architecture open source ClickHouse. Elle introduit une architecture qui sépare l'informatique et le stockage. Elle transforme l'architecture d'origine dans laquelle l'informatique et le stockage sont gérés localement sur chaque nœud en une gestion unifiée de toutes les tâches dans l'ensemble du cluster. Stockage distribué. L'architecture de données fait de chaque nœud informatique un nœud informatique pur et sans état et utilise les capacités d'expansion du stockage distribué et les caractéristiques sans état des nœuds informatiques pour réaliser une expansion et une contraction dynamiques. C’est précisément grâce à cette amélioration que ByConity présente les fonctionnalités importantes suivantes :

Isolation des ressources : isolez les ressources des différents locataires afin que les locataires ne soient pas affectés les uns par les autres.
Séparation de lecture et d'écriture : les ressources de calcul et les ressources de stockage sont découplées pour garantir que les opérations de lecture et d'écriture ne s'affectent pas.
Expansion et contraction élastiques : prend en charge l'expansion et la contraction élastiques et peut étendre et contracter les ressources informatiques en temps réel et à la demande pour garantir une utilisation efficace des ressources.
Forte cohérence des données : Une forte cohérence de la lecture et de l'écriture des données garantit que les données sont toujours à jour et qu'il n'y a pas d'incohérence entre la lecture et l'écriture.
Hautes performances : adopte l'optimisation du moteur OLAP grand public, telle que le stockage de colonnes, l'exécution vectorisée, l'exécution MPP, l'optimisation des requêtes, etc. pour fournir d'excellentes performances de lecture et d'écriture.

Revenu d'entreprise

Après avoir introduit ByConity, les performances globales peuvent atteindre 91 % et toutes les requêtes des utilisateurs peuvent être complétées en 10 secondes grâce à la recherche des commentaires des utilisateurs, cet indicateur de performance se situe également dans la plage acceptable des utilisateurs. Voici un résumé des avantages globaux et de l’expérience apportés par notre migration vers ByConity :

Évitez la préemption des ressources et assurez-vous que les performances des requêtes sont stables à 100 % :

Sur le cluster ClickHouse d'origine, nous avons souvent rencontré le problème de l'encombrement des ressources. Étant donné que ClickHouse n'a pas réussi à isoler les ressources et les locataires, lorsque plusieurs utilisateurs partageaient le cluster pour une requête, lorsqu'un utilisateur interrogeait des ressources, la surcharge serait très élevée, ce qui serait très élevé. impliquer La préemption des ressources rend toutes les requêtes des utilisateurs partagées sur ce cluster instables et la qualité du service ne peut pas être satisfaite. Cependant, après la migration vers ByConity, étant donné que le groupe informatique est complètement isolé physiquement, l'isolation des ressources naturelles et l'isolation des locataires peuvent être obtenues. Les requêtes des différents utilisateurs ne sont pas affectées les unes par les autres. Les performances globales des requêtes peuvent atteindre 91 %. peut être complété en 10 secondes. De plus, ByConity fournit des liens de requêtes complexes auto-développés, un cache disque auto-développé pour réduire la lecture de données à froid et des index de tableaux fréquemment utilisés. De plus, l'efficacité de la lecture à chaud est également meilleure que celle du cluster ClickHouse d'origine par rapport au cluster ClickHouse d'origine. Cluster ClickHouse, ByConity La perte de performances sur le cluster est inférieure à 10 %.

De faibles coûts d'exploitation et de maintenance, et les nœuds défectueux peuvent être remplacés en quelques secondes :

À l'origine, dans le cluster Clickhouse, si un nœud du cluster s'avère cassé, la machine entière doit être démontée pour réparation. En effet, les ressources informatiques, les ressources de stockage et les informations de métadonnées de ClickHouse se trouvent toutes sur ce nœud, qui. équivaut à un petit cluster. Une ressource informatique est perdue et une copie de stockage est perdue. Avant de remplacer un nouveau nœud, le disque local du nœud cassé doit être sauvegardé et migré vers le nouveau nœud. élevé et la cohérence des données est difficile à garantir. Pour ByConity, si le groupe informatique est cassé, puisque le groupe informatique ne stocke pas de données et ne contient que des nœuds informatiques sans état, il suffit de le remplacer par un nouveau groupe informatique. La fiabilité et la cohérence des données sont assurées par HDFS. Pour garantir que la perte du cache local de données de lecture à chaud est contrôlable sur les performances des requêtes métier, cette partie bénéficie principalement de l'architecture de stockage et de séparation informatique ByConity.

Expansion et contraction sans capteur , économisant les coûts des ressources :

ByConity peut réaliser une expansion et une contraction transparentes. Il s'agit d'un déploiement modulaire et conteneurisé basé sur l'évolutivité élastique de Kubernetes. S'il y a suffisamment de machines, il peut être étendu indéfiniment. En même temps, si le serveur tombe en panne, nous n'en avons pas. Il ne faut pas s'inquiéter car le nœud de ByConity n'est qu'un nœud informatique sans état, et sa suppression directe aura peu d'impact sur l'ensemble du cluster. De plus, la planification adaptative est utilisée pour éviter les nœuds lents, améliorer les capacités de débit et améliorer l'utilisation des ressources des nœuds. Dans le même temps, le taux de compression de ByConity est extrêmement élevé. En prenant l'exemple d'une de ses activités, 460 To de données sont ajoutés chaque jour, atteignant 100 To après compression, avec un taux de compression de 65 %. ZSTD et autres méthodes de compression, qui consomment plus de stockage dans les cas extrêmes, moins que le parquet.

La cohérence des données est fortement garantie, et la complexité de maintenance est proche de zéro :

Après la migration vers ByConity, nous avons complètement résolu le problème de cohérence des données, car ByConity n'a pas de problème de synchronisation maître-esclave local et le problème de cohérence des données est directement résolu par le stockage d'objets sous-jacent, tel que HDFS/S3, etc. De cette manière, la complexité de la maintenance de la cohérence est considérablement réduite et la probabilité d'erreur est également plus faible. Actuellement, peu d'utilisateurs signalent des problèmes de cohérence des données. Mais cela a été souvent rencontré auparavant, car le cluster ClickHouse est maintenu par plusieurs copies via la communication entre les nœuds et les problèmes de cohérence sont maintenus via des files d'attente de cohérence. La mise en œuvre est également très compliquée et sujette aux erreurs. De plus, ByConity peut accéder directement aux fichiers de données via HDFS. Différents moteurs informatiques s'adaptent à différents connecteurs pour lire les données et disposent de capacités universelles.

perspectives d'avenir

Après un an et demi d'exploration pratique, ByConity est devenu le principal moteur OLAP utilisé en interne. Un grand nombre d'utilisateurs et de données seront transférés plus tard, et il remplacera à terme le cluster ClickHouse d'origine. On peut voir que ByConity, en tant que moteur OLAP avec calcul et stockage séparés, présente les avantages de hautes performances, d'une grande évolutivité et d'une grande stabilité, et peut répondre aux besoins de traitement et d'analyse de données à grande échelle. Dans le même temps, grâce à la communication au sein de la communauté et à la discussion sur la feuille de route publiée par la communauté https://github.com/ByConity/ByConity/issues/26, ByConity se concentrera principalement sur les orientations suivantes à l'avenir :

Prend en charge l'exécution en plusieurs étapes, les capacités ETL, etc. de la couche d'exécution
Prend en charge les requêtes fédérées de lac de données telles que Hudi, Iceberg, etc.

La communauté ByConity compte un grand nombre d'utilisateurs et est une communauté très ouverte. Nous invitons tout le monde à discuter de co-construction avec nous sur Github. Vous pouvez également rejoindre notre groupe WeChat, Feishu ou Discord pour participer à la communication.

GitHub：https://github.com/ByConity/ByConity