De Clickhouse à Apache Doris : tests de performances et vérification de la migration dans les scénarios commerciaux Youzan

Introduction à cet article :

Actuellement, les principaux problèmes des opérations de commerce électronique proviennent non seulement de l’évolution des marchés et des demandes des clients, mais également de la concurrence et des défis posés par l’accès fragmenté des utilisateurs. Afin d'explorer en profondeur la valeur utilisateur, de fidéliser les utilisateurs et d'obtenir une croissance des performances, Youzan a construit un système d'analyse OLAP complet pour les commerçants, fournissant des services SaaS tels que des rapports d'analyse en temps réel et hors ligne, un marketing intelligent et une sélection de foule. Cet article présentera en détail les pratiques de planification de migration et de comparaison des performances de Youzan de Clickhouse vers Apache Doris , et expliquera comment unifier la pile technologique OLAP basée sur Apache Doris et répondre aux besoins d'analyse en temps réel et de requêtes extrêmement rapides sous d'énormes volumes de données. Dans ce scénario, la vitesse moyenne des requêtes est augmentée de 200 % .

Auteur : Li Chuangyouzan Ingénieur R&D en données de la plateforme de base

---

Youzan est le principal fournisseur de services SaaS de commerce électronique en Chine. Il dispose actuellement de cinq systèmes commerciaux majeurs : le commerce électronique social, la nouvelle vente au détail, l'industrie de la beauté, l'éducation et l'internationalisation de Youzan. Grâce à son commerce électronique social, sa gestion de magasin, ses solutions et autres les nouveaux produits logiciels SaaS de vente au détail aident de manière globale les commerçants à résoudre des problèmes tels que la promotion et l'acquisition de clients, la conversion des transactions, la fidélisation des clients, la croissance des rachats et la fission du partage rencontrés à l'ère de l'Internet mobile, et aident chaque commerçant qui valorise les produits et services à réaliser la privatisation des actifs des clients, la base de clientèle Internet est élargie et l'efficacité opérationnelle est améliorée, aidant ainsi les commerçants à réussir.

Tout en faisant face aux besoins des commerçants et des développeurs en matière de services personnalisés, afin de mieux aider les commerçants à résoudre efficacement des problèmes tels que les systèmes d'acquisition et de distribution de clients, Youzan a construit un système d'analyse OLAP pour les commerçants et propose les scénarios de service SaaS suivants :

• Rapports back-end hors ligne des commerçants : fournissez des requêtes de rapport T+1 aux commerçants pour le B-end, ce qui nécessite une précision de calcul, des performances et une stabilité des requêtes élevées, et sera également confronté à des scénarios de requêtes complexes.
• Sélection de foule et marketing intelligent : obtenez des données utilisateur à partir de points de contact de domaine privé et de points de contact hors ligne, combinez-les avec des données utilisateur accessibles à partir de plateformes sociales couramment utilisées et utilisez la plateforme de données client (ci-après dénommée CDP) et les données en fonction des besoins de l'entreprise. La plateforme de gestion (Data Management Platform - ci-après dénommée DMP) et le système de gestion de la relation client (Customer Relationship Management - ci-après dénommé CRM) effectuent une analyse complète du portrait des différents consommateurs. Ce scénario sera confronté à une grande quantité de mises à jour de données en temps réel à haute fréquence. Dans le même temps, le volume de requêtes est important et le QPS est élevé. Des scénarios de requêtes SQL complexes se produisent souvent.
• Rapports d'analyse en temps réel pour les commerçants : fournissez une analyse et une requête de rapport en temps réel pertinentes aux commerçants pour la face B. Ce scénario est caractérisé par un QPS relativement élevé. Les commerçants peuvent choisir différentes combinaisons de dimensions pour la requête, ce qui nécessite un temps réel élevé. et la stabilité.
• Système d'analyse des journaux Skynet : fournit des services de journaux à guichet unique pour la collecte, la consommation, l'analyse, le stockage, l'indexation et les requêtes de journaux pour tous les systèmes d'entreprise. Ce scénario présente un débit d'écriture élevé, nécessitant des millions d'écritures de données par seconde ; et la fréquence des requêtes est faible, impliquant les requêtes de journaux TopN de Skynet, de sorte que le système nécessite une agrégation en temps réel et des capacités de recherche floue.

À mesure que le volume de données commerciales devient de plus en plus important, les besoins des entreprises en matière de rapidité et d'analyse des requêtes fédérées deviennent de plus en plus urgents. Les composants existants présentent certains problèmes pour le développement du personnel d'entreprise et le personnel d'exploitation et de maintenance pendant l'utilisation. Par conséquent, nous avons décidé de mettre à niveau le l'architecture des données et unifier la pile technologique OLAP basée sur Apache Doris. Cet article présentera en détail la composition de l'architecture initiale, le processus de fonctionnement du système OLAP et les problèmes pratiques des applications, et partagera la technologie et l'expérience de réglage dans le processus de migration de l'architecture système.

Points faibles de l’architecture initiale

L'architecture initiale est illustrée dans la figure. Les données proviennent principalement de données originales telles que la base de données d'entreprise Binlog et les journaux d'utilisateurs, et les données sont traitées via deux liens, en temps réel et hors ligne. Les données originales sont d'abord importées dans le middleware de messages Apache Kafka et NSQ. Certaines des données seront traitées et calculées via Apache Flink et associées à la table de détails des dimensions stockée dans HBase. L'autre partie des données sera stockée dans Apache Hive. et HDFS en tant que données hors ligne. , écrites dans le moteur OLAP via le calcul Apache Spark.

L'architecture de données Youzan utilise principalement les trois moteurs OLAP suivants. Chaque composant fournit des requêtes et des analyses dans différents scénarios pour les applications en amont en fonction des caractéristiques et des besoins du scénario métier :

• Apache Kylin : créez un backend de reporting hors ligne pour les commerçants basé sur Apache Kylin afin de fournir aux commerçants des requêtes de rapport T+1. À l'heure actuelle, il y a plus de 5 millions de commerçants dans le backend. Pour certains grands commerçants, le nombre de membres uniques peut atteindre des dizaines de millions, les SKU de produits peuvent atteindre des centaines de milliers et le nombre de cubes construits sur la plate-forme atteint 400. +.
• Clickhouse : basé sur Clickhouse, les services de sélection de foule et de requête de journaux TopN sont effectués. La sélection de foule aide principalement à l'analyse des données sur le comportement des utilisateurs grâce à une requête détaillée en temps réel.
• Apache Druid : visant des scénarios de rapports d'analyse en temps réel pour les commerçants du côté B, un système de requête dimensionnelle est construit sur la base de Druid pour fournir des services de requête d'indicateurs en temps réel aux commerçants.

Cependant, en raison de problèmes tels qu'un trop grand nombre de composants et une architecture redondante, cette architecture a apporté une série de défis en matière de maintenance, de développement, d'applications métiers, etc., comme suit :

01 Clickhouse : performances de requête insuffisantes

Pour les scénarios de requêtes à haute concurrence et à QPS élevé dans certains scénarios SaaS, les capacités de requête de Clickhouse ne sont pas idéales. En raison des problèmes de conception du composant Clickhouse lui-même, il ne peut pas prendre en charge les scénarios de requête de jointure multi-tables ou de grandes tables. Cela signifie qu'une fois qu'un scénario de requête associé se produit, le côté commercial doit trouver une nouvelle solution, ce qui rend l'efficacité globale de la requête faible.

02 Apache Druid : le traitement de la réparation des données est difficile

• La réparation des données est difficile : lorsque la propre tolérance aux pannes d'Apache Flink provoque la duplication des données, Druid s'appuie entièrement sur le côté écriture pour effectuer des opérations idempotentes. Comme il ne prend pas en charge la mise à jour ou la suppression des données, il ne peut que remplacer les données dans leur intégralité, ce qui entraîne un faible niveau de données. précision. , difficile à réparer.
• Problème de cohérence des données : pour Druid, après l'importation des données, le segment doit être construit avant de pouvoir répondre aux résultats de la requête. Une fois qu'il y a un retard de données dans le processus d'écriture de Flink en amont sur Kafka, elles ne peuvent pas être écrites sur Druid comme prévu, et les données de l'indicateur fluctuent considérablement et la cohérence des données ne peut pas être garantie.
• Le lien de réparation des données est trop long et le coût est trop élevé : Afin de résoudre certains problèmes temporaires de réparation des données, nous devons d'abord passer des heures à sauvegarder les données Apache Kafka sur HDFS. Une fois la sauvegarde terminée, nous devons également re -importer les données dans Druid pour réparation. , le lien de réparation global est trop long et le temps d'investissement et les coûts de R&D augmenteront en conséquence.

03 Apache Kylin : T+1 faible rapidité

Apache Kylin adopte une méthode de pré-calcul dans le processus de traitement des données, effectue des calculs d'agrégation pendant le processus de construction du Cube multidimensionnel et génère des rapports de données T+1. Pour certaines entreprises qui opèrent la nuit, elles doivent attendre une journée pour afficher les données du rapport de la veille, ce qui ne peut pas répondre aux besoins des utilisateurs en matière de rapidité.

04 Architecture globale : coûts d'exploitation et de maintenance élevés, faible efficacité en R&D et faible flexibilité architecturale

• Coûts de R&D élevés : les entreprises doivent apprendre à utiliser chaque composant (Clickhouse, Druid, Apache Kylin) et les normes SQL de requête sont différentes, ce qui augmentera les coûts d'apprentissage et nécessitera plus tard de la R&D, de la surveillance, de l'exploitation et de la maintenance, ainsi que des périphériques. Au cours du processus de développement d'outils écologiques et d'autres outils, une grande quantité de main-d'œuvre et des coûts d'accès au développement doivent être investis, ce qui réduit l'efficacité du développement.
• Goulot d'étranglement d'exploitation et de maintenance : pendant la période d'expansion et de contraction, le côté commercial doit arrêter d'écrire pour l'ajustement du cluster, et une seule expansion nécessite la migration de toutes les tables de base de données. Non seulement le coût du temps d'exploitation et de maintenance ne peut pas être garanti, mais il augmentera également des coûts de main-d'œuvre excessifs. Actuellement, Youzan a une forte demande d'extension de capacité, et les coûts d'exploitation et de maintenance de l'architecture existante sont devenus un problème majeur pour le système.
• Mauvaise flexibilité de l'architecture : Apache Kylin ne peut fonctionner normalement que dans des scénarios où les dimensions et les indicateurs sont définis à l'avance et la structure de la table est fixe. Une fois les dimensions et les indicateurs ajoutés, il est nécessaire de créer un nouveau Cube et de recharger les données historiques ; Clickhouse aura besoin à ajouter lorsque des tables larges sont ajoutées. Si toutes les données sont réimportées, ces défauts architecturaux entraîneront une utilisation accrue des ressources, une augmentation des coûts d'exploitation et de maintenance et une diminution de l'efficacité de la R&D pendant les opérations commerciales.

Recherche technique et évaluation avantages-coûts

Sur la base des problèmes architecturaux ci-dessus, nous avons mené des recherches et une sélection d'architectures sur le marché, dans l'espoir de choisir un moteur capable de simplifier l'architecture complexe actuelle et d'unifier la pile technologique OLAP. En plus d'analyser l'aide des performances OLAP elles-mêmes pour l'entreprise, nous devons également évaluer le rapport avantages-coûts apporté par la transformation de l'architecture et déterminer si le retour sur investissement apporté par la migration et la reconstruction de l'architecture répond aux attentes.

En termes d'avantages, nous devons évaluer si les performances après l'introduction de la nouvelle architecture s'améliorent comme prévu, et comparer et évaluer Apache Doris avec Clickhouse, Druid et Kylin respectivement.

En termes de coût, nous considérerons d'abord le coût de développement d'outils périphériques au cours du processus de remplacement, qui implique la construction, la recherche et le développement d'une série d'outils tels que la surveillance, l'alarme et les plates-formes dépendantes en amont et en aval ; deuxièmement, la migration d'entreprise. impliquera beaucoup de transformation et de coordination de l'entreprise, comment motiver les parties commerciales à mener à bien la transformation, fournir des outils de transformation plus abondants et réduire autant que possible les coûts d'investissement sont également nos principales considérations.

Après une série d'évaluations, nous avons constaté que l'itération de l'architecture basée sur Apache Doris peut résoudre efficacement les problèmes de l'architecture actuelle en termes de responsabilisation des entreprises et de coûts, et atteindre dans une large mesure l'objectif de réduction des coûts et d'amélioration de l'efficacité. itération Les bénéfices attendus sont nettement supérieurs au coût de la transformation, nous avons donc décidé de construire un entrepôt de données unifié en temps réel basé sur Apache Doris. L'évaluation et l'analyse spécifiques sont les suivantes :

• Excellentes performances de requête : il résout les lacunes de Clickhouse dans les scénarios de requêtes à QPS élevé et de grandes tables, et offre d'excellentes capacités de requêtes simultanées. De plus, après la sortie d'Apache Doris 2.0, la fonction d'index inversé prend en charge la récupération rapide dans n'importe quelle dimension et la récupération de texte intégral par segmentation de texte. L'amélioration des performances des requêtes dans les scénarios de journaux est particulièrement évidente.
• Mise à jour efficace des données : la clé unique d'Apache Doris prend en charge les mises à jour de données par lots importants et l'écriture en temps réel de données par petits lots, couvrant 90 % de nos scénarios commerciaux. Ses modèles de clé dupliquée et de clé agrégée peuvent également prendre en charge les mises à jour partielles des colonnes et le modèle de données global. est riche et utile. Améliorez l’efficacité de l’écriture et des requêtes.
• Garantir l'exactitude des données : Apache Doris prend en charge l'importation de transactions et la fonction Bitmap prend en charge une déduplication précise pour garantir que les données ne sont pas perdues ou dupliquées ; elle prend également en charge une écriture précise pour garantir une forte cohérence entre les tables de base de données et les vues matérialisées, ainsi qu'une forte cohérence des données de copie. .
• Facile à utiliser et faible coût de développement : Apache Doris est hautement compatible avec MySQL, ce qui abaisse le seuil de facilité de développement et d'utilisation. Les coûts de migration et d'expansion de Doris sont faibles et ses opérations d'exploitation et de maintenance telles que l'expansion horizontale sont particulièrement simples. L'accès à ses composants périphériques et la surveillance sont relativement simples. La communauté Doris fournit des outils d'accès tels que Flink & Doris Connector, Spark & ​​​​​​Doris Connector, et le modèle de surveillance est directement accessible sans développement supplémentaire.
• Forte activité communautaire : parmi les communautés open source que j'ai rejointes dans le passé, la communauté Apache Doris est très active. Elle compte de nombreux développeurs dans la communauté et itère et met à jour rapidement. Elle est également très active pour répondre aux questions de la communauté et a apporté beaucoup d’aide pendant le processus de développement.

Créez un entrepôt de données unifié en temps réel basé sur Apache Doris

Comme le montre la figure ci-dessus, la nouvelle architecture construira un entrepôt de données unifié en temps réel basé sur Apache Doris, remplaçant les trois composants OLAP de l'architecture d'origine et résolvant des problèmes tels que les coûts d'accès élevés, l'utilisation accrue des ressources et la longueur des données. liens causés par un trop grand nombre de composants, ce qui peut en fin de compte réduire la charge du côté commercial, réduire le coût matériel du cadre global et atteindre les objectifs d'unification du moteur et de la pile technologique.

Dans la plupart des scénarios d'application de Youzan, l'architecture d'origine présente des duplications de données et des retards de données qui doivent être réparés. Après avoir présenté Apache Doris, nous utiliserons ses fonctions de modèle de clé unique, de clé en double et de clé agrégée pour obtenir des mises à jour efficaces des données afin de garantir l'écriture. L'efficacité et l'architecture Doris ont des capacités d'évolutivité élastiques.Après son introduction, il peut réduire considérablement la probabilité de panne et l'efficacité de la récupération des données en cas de panne.

De plus, nous présenterons les fonctionnalités suivantes d'Apache Doris :

• Index inversé : la fonction d'index inversé d'Apache Doris version 2.0 optimise le système d'analyse des journaux Skynet, permet une récupération rapide multidimensionnelle et accélère les performances d'analyse des requêtes dans les scénarios de journaux.
• Fusion sur écriture du modèle de clé primaire (Merge-on-Write) : Apache Doris fournit une variété de méthodes d'importation, qui peuvent importer de petits lots de données dans Doris en temps réel, fournissant ainsi une requête de rapport en temps réel pour les activités ultérieures du magasin. avec la structure de prix originale, Doris peut considérablement maximiser la rapidité d'importation.

Expérience de migration de Clickhouse vers Apache Doris

Après avoir déterminé la migration de l'architecture, nous avons d'abord choisi d'utiliser Apache Doris pour remplacer le composant Clickhouse.Cela était principalement dû à des problèmes tels que l'important goulot d'étranglement des performances des requêtes Clickhouse et les opérations d'expansion et de contraction de cluster trop complexes lorsque l'entreprise se développait, ce qui a grandement a augmenté la charge de travail de l'équipe d'exploitation et de maintenance. De plus, une série de problèmes tels qu'une mauvaise capacité de jointure de grandes tables et de mauvaises performances de requête à QPS élevé ne peuvent pas répondre aux besoins du côté commercial. De plus, la fonction Clickhouse est similaire à Apache Doris, facilitant la migration du côté commercial, nous donnons donc la priorité au remplacement du composant Clickhouse.

Ensuite, nous partagerons le plan de migration de Doris pour remplacer Clickhouse. Le rythme global de l'itération de l'architecture est divisé en réécriture des instructions SQL pour réaliser l'importation automatique (y compris la réécriture des instructions de création de table et des instructions de requête), tests de performances des requêtes, tests de stabilité. , importez les tests de performances et optimisez, et enfin migrez les données commerciales globales après avoir effectué une série de tests.

01 Instruction de création de table SQL et réécriture d'instructions de requête

Actuellement, nous avons produit un outil de réécriture d'instructions de création de table SQL pour le modèle Unique Key et le modèle Duplicate Key. Comme le montre la figure ci-dessus, il prend en charge la conversion automatique des instructions de création de table Clickhouse en instructions de création de table Doris via des paramètres de configuration. Les principales fonctions de cet outil est le suivant :

• Mappage de type de champ : En raison de l'incohérence entre les champs Doris et Clickhouse, il existe des exigences particulières pour la conversion. Par exemple, le type de valeur clé String doit être converti en Varchar et la longueur correspondante doit être définie, et le champ de partition String doit être converti en Date V2, etc. ;
• Déterminez le nombre de partitions historiques d'une table partitionnée dynamiquement : étant donné que certaines tables ont des partitions historiques, vous devez spécifier le nombre de partitions lors de la création de la table, sinon une exception Aucune partition se produira lors de l'insertion de données ;
• Le nombre de compartiments est déterminé : bien que la table de partition historique puisse être configurée de manière uniforme, le volume de données de la partition historique n'est souvent pas complètement cohérent. Par conséquent, nous pouvons calculer le nombre de compartiments de la partition historique en fonction du volume de données réel de la partition historique. Dans le même temps, pour les tables non partitionnées, le nombre de compartiments peut être calculé en fonction des données historiques. Définissez les propriétés pour configurer le compartimentage automatique ;
• Détermination du cycle TTL : vous pouvez définir le cycle de conversion de la table de partition dynamique et définir le temps de rétention avant la conversion ;
• Paramètre de séquence du modèle unique : vous pouvez spécifier l'ordre d'importation de la colonne Séquence lors de l'importation, ce qui résout le problème de l'impossibilité de déterminer l'ordre d'importation et garantit efficacement l'ordre pendant le processus d'importation des données.

Semblable à l'outil de réécriture d'instructions de création de table, la réécriture d'instructions de requête SQL peut convertir automatiquement les instructions de requête Clickhouse en instructions de requête Doris, principalement pour la vérification en double exécution de l'exactitude et de la stabilité des données. Au cours du processus de réécriture, nous avons réglé les considérations suivantes :

• Conversion du nom de la table de requête : Il existe certaines règles de mappage lors du processus de création de table de Clickhouse et Doris.Pendant le test en double exécution, nous pouvons effectuer directement la conversion selon les règles de mappage.
• Conversion de fonctions : étant donné que les fonctions utilisées par Clickhouse et Doris sont assez différentes, la conversion du mappage de fonctions doit être effectuée en fonction de la relation de mappage de fonctions entre Doris et Clickhouse. Parmi eux, nous avons rencontré des conversions de fonctions spéciales qui nécessitent un traitement spécial. Par exemple, dans Clickhouse, COUNTIF()doit être converti en pour SUM（CASE WHEN _ THEN 1 ELSE 0) obtenir le même effet ORDER BYet GROUP BYdoit être converti à l'aide de la fonction de fenêtrage Doris. De plus, Clickhouse utilise pour Array Joineffectuer des conversions de colonnes transfert, et Doris doit utiliser Explode, Lateral Viewpour se développer ;
• Incompatibilité au niveau de la syntaxe : étant donné que Clickhouse n'est pas compatible avec le protocole MySQL et que Doris est hautement compatible, des paramètres d'alias sont requis dans la sous-requête. En particulier dans le scénario commercial de sélection de foule, il existe plusieurs sous-requêtes.Par conséquent, lors de la conversion après-vente, les sous-requêtes correspondantes doivent être vérifiées de manière récursive pour sqlparsevérifier toutes les sous-requêtes à définir.

02 Test de résistance aux performances d'Apache Doris et Clickhouse

Le test de performances des requêtes compare principalement les performances d'Apache Doris et des composants de l'architecture d'origine Clickhouse dans trois scénarios commerciaux principaux (CDP, DMP, CRM). Nous avons choisi la taille de cluster équivalente en ligne et effectué des tests de résistance comparatifs en comparant les performances des requêtes SQL et les performances de jointure des grandes tables . Nous avons également testé la consommation du processeur et de la mémoire de Doris pendant la requête. Ensuite, nous présenterons le processus de test de résistance et comparerons en détail les données de performance spécifiques. La taille du cluster de test est de 3 FE + 16 BE, et la configuration BE à nœud unique est (32C 128 G 7T SSD).

Comparaison des performances des requêtes SQL dans les scénarios principaux

Dans le test de performances des requêtes SQL, nous avons principalement effectué des requêtes basées sur les trois principaux systèmes avec les scénarios d'application réels les plus récents, à savoir la comparaison des scénarios CDP, DMP et CRM. Au final, 16 instructions SQL ont été effectivement interrogées. Les caractéristiques spécifiques des requêtes SQL dans les scénarios en ligne sont les suivantes :

Comme le montre le tableau, nous avons comparé le temps de 16 requêtes SQL entre Doris et Clickhouse, parmi lesquelles les performances de 10 requêtes SQL de Doris étaient meilleures que celles de Clickhouse. De plus, nous avons comparé le temps total de requête de Doris et Clickhouse.Après avoir optimisé la conception de la structure de la table Doris, la vitesse globale de requête de Doris est 2 à 3 fois plus rapide que celle de Clickhouse.

Test de performances des requêtes de jointure de grande table

Dans le test de requête associé, sur la base des tables de données pertinentes dans le scénario CDP, nous avons sélectionné des données de table principale et de table de dimension de différentes ampleurs de données. Les volumes de données de test de la table principale étaient respectivement de 4 milliards de tables de comportement des utilisateurs et de 25 milliards d'utilisateurs. Attribut supplémentaire tables, 96 milliards de tables d'attributs supplémentaires d'utilisateurs ; les tables de dimension sont basées sur kdt_id + user_id, et les niveaux de test sont respectivement de 1 million, 10 millions, 50 millions, 100 millions, 500 millions, 1 milliard et 2,5 milliards de volumes de données de table de dimension. Afin de tester de manière plus complète, le test de requête d'association est divisé en deux types : association complète et association filtrée. L'association complète consiste à joindre directement la table principale et la table de dimension. L'association filtrée consiste à rejoindre le même niveau de table principale, en ajoutant des conditions pour le WHEREfiltre spécifié par deux identifiants de magasin.

Les performances spécifiques des tests de requêtes sont les suivantes :

• 4 milliards entièrement liés : dans la requête entièrement liée de 4 milliards de tables principales, les performances de requête de Doris sont meilleures que celles de Clickhouse . À mesure que la taille des données de la table de dimension augmente, la différence de temps de requête entre Doris et Clickhouse devient plus grande. Doris peut atteindre un maximum de 5 Double amélioration des performances ;
• Filtrer l'association de magasin spécifiée à 4 milliards : dans la requête d'association de condition de filtre, WHERE les données filtrées par la table principale selon les conditions sont de 41 millions. Par rapport à Clickhouse, Doris peut obtenir une amélioration des performances 2 à 3 fois lorsque le volume de données de la table de dimension est petit., lorsque le volume de données de la table de dimension est important, les performances sont améliorées de plus de 10 fois. Lorsque la table de données de dimension dépasse 100 millions, Doris peut toujours interroger de manière stable, tandis que Clickhouse provoque un échec de requête en raison des conditions du MOO.
• 25 milliards entièrement liés : lorsque la table de 25 milliards de 50 champs est entièrement liée en tant que table principale, les performances de requête de Doris sont toujours meilleures que celles de Clickhouse. Doris peut surpasser dans toutes les tailles de table de dimension, tandis que Clickhouse connaîtra un MOO après dépassant 50 millions. ;
• 25 milliards associés au magasin spécifié filtré : dans la requête d'association conditionnelle, la table principale filtre les données en fonction de l'ID du magasin à 570 millions. Le temps de réponse à la requête de Doris atteint le deuxième niveau et le temps de réponse le plus rapide de Clickhouse prend également quelques minutes . est encore plus impossible à manquer lorsque la quantité de données est importante.
• La corrélation et le filtrage complets spécifient une corrélation de magasin de 96 milliards : qu'il s'agisse d'une requête de corrélation de table principale ou d'une requête de corrélation conditionnelle, Doris peut exécuter et répondre rapidement, tandis que Clickhouse ne peut pas manquer dans tous les niveaux de table de dimension.

En plus des performances de réponse, nous avons également testé la consommation du processeur et de la mémoire de Doris et avons constaté que la charge du cluster de Doris restait stable malgré des dizaines de milliards de requêtes liées aux tables volumineuses. En résumé, la vitesse de réponse aux requêtes d'Apache Doris est plus rapide que celle de Clickhosue dans la plupart des scénarios. Surtout dans le scénario de jointure de grandes tables, les performances d'Apache Doris sont complètement meilleures que celles de Clickhouse .

03 Test de stabilité de la lecture du trafic en ligne Clickhouse

Une fois le test de résistance des requêtes terminé, nous avons commencé à exécuter Doris et Clickhouse en ligne pour vérifier davantage la stabilité de Doris. Les étapes spécifiques sont les suivantes :

1. Collectez des informations de requête valides de Clickhouse dont le statut de requête est QueryFinish au cours de la dernière minute grâce à une collecte régulière.
2. Signalez les informations de la requête à Kafka, puis consommez le sujet Kafka via Flink pour obtenir la requête SQL Clickhouse et compiler des statistiques sur les résultats.
3. L'implémentation d'UDF dans Flink convertit la requête SQL Clickhouse en requête SQL Doris et l'exécute par JDBC.
4. Obtenez les résultats d'exécution et les résultats statistiques, comparez-les avec les informations d'exécution de Clcikhouse et enfin stockez-les dans RDS.
5. Enfin, grâce aux statistiques de lecture du trafic des requêtes Clickhouse en ligne, les performances des requêtes Doris et l'exactitude des données des requêtes sont analysées.

04 Test et optimisation des performances d'importation de données Apache Doris

Les tests de performances d'importation de données sont l'un de nos principaux domaines de préoccupation. Apache Doris lui-même fournit une méthode d'importation relativement riche pour l'importation de données en temps réel et de données hors ligne. La méthode d'importation de données en temps réel consiste principalement à utiliser Apache Flink pour importer NSQ. et les données Apache Kafka en temps réel. Écrivez sur Apache Doris via la méthode Stream Load. Doris propose plusieurs méthodes d'importation pour les données hors ligne :

• Prend en charge la lecture de données externes via Spark SQL et l'écriture sur Apache Doris via Stream Load ;
• Prend en charge la méthode Spark Load , en utilisant les ressources du cluster Spark pour terminer l'opération de tri des données dans HDFS, puis écrit les données dans Doris via Broker Load ;
• Prend en charge la fonction Doris Multi-Catalog pour lire directement des sources de données externes et écrire dans Doris via Insert Into.

En raison de la grande quantité de données hors ligne, nous avons effectué des tests de performances et des comparaisons de plusieurs méthodes d'importation de données pour ce type de données, et testé le temps d'importation en comparant différents niveaux de données détaillées. Taille du cluster de test 3 FE + 16 BE, configuration à nœud unique BE (32C 128 G 7T SSD) résultats des tests :

Le degré de parallélisme de l'importation au format Spark Doris Connector est de 80 et le lot unique est de 1 million. La charge du cluster est la suivante :

Sur la base des résultats des tests ci-dessus, nous analysons plus en détail les avantages des différentes méthodes d'importation et des solutions de réglage ultérieures. Nous espérons que les pratiques de réglage suivantes pourront aider les développeurs ayant des besoins similaires :

Doris Insérer Dans

La méthode Insert Into peut fournir des performances dérivées rapides et est relativement simple à utiliser. Actuellement, les performances d'importation de cette méthode sont suffisantes pour répondre aux besoins de notre entreprise.

Spark Doris Connector prend en charge le blocage des écritures

La méthode d'importation du connecteur Spark Doris est plus polyvalente et peut résoudre le problème de l'importation de grandes quantités de données. Les performances d'importation sont relativement stables. Pendant le processus d'importation, nous devons contrôler raisonnablement le taux d'importation et le parallélisme des importations. Étant donné que notre scénario commercial implique des centaines de milliards de données chaque jour et que l'importation prend 5 à 6 heures, si l'importation de données de table aussi volumineuses échoue parce que les écritures BE sont rejetées, cela entraînera des retards dans la sortie des données en aval, ainsi que d'autres problèmes. De plus, dans la version 2.0, des erreurs telles que -235 et -238 ont été résolues au niveau du noyau Apache Doris, éliminant ainsi le besoin pour les utilisateurs de résoudre manuellement ces problèmes.

Nous commençons principalement par contrôler la vitesse d'écriture.Le principe général de la transformation est de retarder le blocage grâce à un intervalle d'écriture exponentiel et d'utiliser des paramètres de configuration pour attendre une nouvelle tentative lorsqu'une exception d'importation se produit dans de grandes quantités de données, afin d'éviter l'échec de la tâche. Les trois paramètres de temps de blocage maximum, de temps de blocage maximum unique et de mots-clés de capture d'exceptions de blocage sont utilisés pour capturer les exceptions de blocage et implémenter la fonction d'attente de blocage. Enfin, dans ce paramètre, notre taux de réussite en matière d'importation de données dans de grandes tables a atteint plus de 95 %.

[1] Relations publiques associées : https://github.com/apache/doris-spark-connector/pull/117

Spark Doris Connector prend en charge l'importation de données Bitmap

En lisant la documentation officielle d'Apache Doris, nous avons constaté que la méthode Spark Load peut importer des données Bitmap, et en même temps, le calcul des données Bitmap peut être placé dans le cluster Spark pour le calcul. Dans la pratique commerciale, nous utilisons Spark Doris Connector plus couramment, nous avons donc commencé à explorer l'importation de données Bitmap via Spark Doris Connector.

Comme le montre la figure ci-dessus, l'instruction de création de table Bitmap est principalement divisée en trois champs, dont le dernier champ est le calcul Bitmap de CASE_ID. Après avoir communiqué avec les membres de la communauté, nous proposons une option pour définir Doris Read Field, écrire d'autres colonnes à l'exception des colonnes Bitmap et effectuer le traitement de mappage dans Doris Write Field. L'implémentation finale est celle illustrée dans la figure ci-dessus, en important directement les données détaillées d'Apache Hive dans les données Bitmap d'Apache Doris via Spark Doris Connect.

Optimisation de l'importation au format CSV du connecteur Spark Doris

Dans notre processus d'importation, qu'il s'agisse de Spark Doris Connector ou de Flink Doris Connector, ils sont finalement importés à l'aide de Stream Load. Les fichiers d'importation CSV et JSON ont deux formats d'importation, et la sélection de formats différents entraînera une perte de performances d'importation. est également différent de la vitesse.

Avant l'optimisation, nous avons effectué un test de performances d'importation sur une table métier avec des milliards de données et 26 champs. Nous avons constaté que le format CSV est près de 40 % plus rapide que JSON en termes de vitesse d'importation et que sa consommation de mémoire est inférieure. C'est aussi pourquoi Apache Doris recommande officiellement d'utiliser le format CSV.

Il convient de noter que lors de l'importation au format CSV, la définition de délimiteurs de champs et de sauts de ligne raisonnables est cruciale pour l'efficacité de la reconnaissance du lecteur CSV. Dans le même temps, le délimiteur n'est pas reconnu.

Grâce aux invites de la documentation officielle, nous avons constaté que Stream Load peut prendre en charge la configuration des paramètres pour supprimer les guillemets doubles les plus externes du champ. Sur cette base, nous avons décidé d'ajouter la configuration des paramètres utilisateur pendant la phase d'écriture de Spark Doris Connector et d'épisser les guillemets doubles. sur la couche externe du champ pour garantir qu'ils ne sont pas utilisés. Les caractères spéciaux sélectionnés peuvent toujours être efficacement séparés, et une configuration pour supprimer les guillemets les plus externes est ajoutée pendant la phase d'écriture de Stream Load. Grâce à la configuration aux deux extrémités, on peut garantir que même si les données commerciales sont très complexes, il n'y a pas lieu de s'inquiéter de l'identification des symboles de champ, garantissant ainsi que les champs peuvent être segmentés normalement.

[2] Relations publiques associées : https://github.com/apache/doris-spark-connector/pull/119

Charge d'étincelle

La caractéristique de la méthode d'importation Spark Load est d'effectuer des tâches de lecture aléatoire, de tri et d'autres tâches basées sur les ressources Spark et de sortir les fichiers au format HDFS. Après cela, le nœud BE peut directement lire les fichiers sur HDFS et les écrire au format Doris. Sur la base de cette méthode, au cours du processus de test, nous avons constaté que lorsque la quantité de données est plus importante, la vitesse d'importation est plus rapide et les ressources du cluster de Doris peuvent être économisées sans entraîner de pertes de performances importantes.

Étant donné que Spark Load est fréquemment utilisé dans des scénarios de données de réparation temporaires, nous l'avons également optimisé sur la base de tests. Grâce à la documentation du site officiel et à l'aide de la communauté, nous avons constaté que le taux d'importation dans l'étape Spark Load est principalement affecté par deux paramètres : la simultanéité d'importation unique et le volume de traitement des données d'importation BE unique, et les deux paramètres sont étroitement liés à la source. taille du fichier et nœud BE. . Lors du contrôle d'autres variables, plus le fichier source est petit, plus la vitesse d'importation est lente. Par conséquent, nous pensons qu'utiliser pleinement les ressources d'exploitation de Spark et définir raisonnablement le nombre de buckets pendant la phase ETL peut effectivement accélérer la vitesse d'importation.

Planification et perspectives futures

Dans le processus de test global, le test de performances basé sur la version officielle d'Apache Doris 2.0 est terminé. Nous sommes très satisfaits des performances des requêtes de Doris. De plus, pour les performances d'importation, nous avons d'abord utilisé la version Doris 2.0-Alpha pendant les tests et avons constaté qu'il y avait des goulots d'étranglement occasionnels du processeur pendant le processus d'importation. Par exemple, lors de l'utilisation du connecteur Spark Doris, Spark utilisait des ressources et Doris pour importer des données CPU Il existe certains goulots d'étranglement. Dans le même temps, nous avons également signalé le problème à la communauté. Après l'optimisation de la communauté et la sortie de la version 2.0-Beta, la stabilité a été améliorée.

Actuellement, nous travaillons avec Clickhouse pour vérifier davantage la stabilité de Doris grâce à une double exécution en ligne. Dans le même temps, nous optimisons les performances de la méthode d'importation du connecteur Spark Doris et développons des outils d'importation de périphériques pour terminer le remplacement des composants et d'autres travaux de mise en œuvre. . Après avoir progressivement terminé la migration commerciale de Clickhouse, sur la base de l'expérience de migration de Clickhouse, nous avons progressivement achevé la migration des deux composants Druid et Kylin pour les activités de stock non migrées, et avons finalement construit une analyse extrêmement rapide et un entrepôt de données unifié en temps réel basé sur Apache Doris.

Je suis très reconnaissant à l'équipe technique de SelectDB pour sa réponse positive et ses réponses professionnelles, qui ont accéléré le processus de migration de l'entreprise Youzan.J'espère également que cet article pourra fournir une expérience pratique pertinente et une référence de sélection OLAP aux entreprises qui se préparent à migrer leur architecture . Enfin, nous continuerons à participer aux activités de la communauté et à apporter des résultats pertinents à la communauté. Nous espérons qu'Apache Doris se développera rapidement et s'améliorera de plus en plus !

Référence GitHub PR :

[1] Spark Doris Connector prend en charge le blocage des écritures

https://github.com/apache/doris-spark-connector/pull/117

[2] Optimisation de l'importation au format CSV du connecteur Spark Doris

https://github.com/apache/doris-spark-connector/pull/119

[3] Spark Load crée l'apparence Hive pour prendre en charge le paramètre de version Hive

https://github.com/apache/doris/pull/20622

[4] Optimisation de l'acquisition de variables de l'environnement du système Spark Load

https://github.com/apache/doris/pull/21837

[5] Les attributs d'apparence HIve ne prennent pas effet dans l'optimisation Spark Load

https://github.com/apache/doris/pull/21881