Pourquoi nous sommes passés de ClickHouse à Apache Doris

Pourquoi nous utilisons ClickHouse

La bibliothèque musicale de Tencent Music contient des données de toutes formes et de tous types : musique enregistrée, musique live, audio, vidéos, etc. En tant qu’ingénieurs de la plateforme de données, notre travail consiste à distiller des informations à partir des données, sur la base desquelles nos coéquipiers peuvent prendre de meilleures décisions. pour soutenir nos utilisateurs et partenaires musicaux.

Plus précisément, nous effectuons une analyse complète des chansons, des paroles, des mélodies, des albums et des artistes, transformons toutes ces informations en actifs de données et les transmettons à nos utilisateurs de données internes pour le comptage des stocks, le profilage des utilisateurs, l’analyse des métriques et le groupe ciblage.

Nous avons stocké et traité la plupart de nos données dans Tencent Data Warehouse (TDW), une plate-forme de données hors ligne où nous avons placé les données dans divers systèmes de balises et de métriques, puis créé des tableaux plats centrant chaque objet (chansons, artistes, etc.). Ensuite, nous avons importé les tableaux plats dans ClickHouse pour l’analyse et Elasticsearch pour la recherche de données et le ciblage de groupe. Après cela, nos analystes de données ont utilisé les données sous les balises et les métriques dont ils avaient besoin pour former des ensembles de données pour différents scénarios d’utilisation, au cours desquels ils pouvaient créer leurs propres balises et métriques.

Le pipeline de traitement des données ressemblait à ceci :

Pourquoi ClickHouse n’est pas un bon choix

Lors de l’utilisation du pipeline ci-dessus, nous avons rencontré quelques difficultés :

1. Mise à jour partielle: La mise à jour partielle des colonnes n’était pas prise en charge. Par conséquent, toute latence de l’une des sources de données pourrait retarder la création de tableaux plats et ainsi nuire à l’actualité des données.
2. Coût de stockage élevé: Les données sous différentes balises et statistiques ont été mises à jour à différentes fréquences. Autant ClickHouse excellait dans le traitement des tables plates, c’était un énorme gaspillage de ressources de stockage que de simplement verser toutes les données dans une table plate et de les partitionner par jour, sans parler des coûts de maintenance qui en découlaient.
3. Coût d’entretien élevé: D’un point de vue architectural, ClickHouse se caractérisait par le fort couplage des nœuds de stockage et des nœuds de calcul. Ses composants étaient fortement interdépendants, ce qui augmentait les risques d’instabilité des clusters. De plus, pour les requêtes fédérées sur ClickHouse et Elasticsearch, nous avons dû nous occuper d’un grand nombre de problèmes de connexion. C’était juste fastidieux.

Transition vers Apache Doris

Apache Doris, une base de données analytique en temps réel, possède quelques fonctionnalités qui sont exactement ce dont nous avions besoin pour résoudre nos problèmes :

1. Mise à jour partielle: Doris prend en charge une grande variété de modèles de données, parmi lesquels le modèle agrégé prend en charge la mise à jour partielle en temps réel des colonnes. Sur cette base, nous pouvons ingérer directement des données brutes dans Doris et y créer des tableaux plats. L’ingestion se déroule comme suit : premièrement, nous utilisons Spark pour charger des données dans Kafka ; ensuite, toutes les données incrémentielles seront mises à jour vers Doris et Elasticsearch via Flink. Pendant ce temps, Flink pré-agrégera les données afin de soulager Doris et Elasticsearch.
2. Coût de stockage: Doris prend en charge les requêtes de jointure multi-tables et les requêtes fédérées sur Hive, Iceberg, Hudi, MySQL et Elasticsearch. Cela nous permet de diviser les grandes tables plates en plus petites et de les partitionner par fréquence de mise à jour. Les avantages de cette opération incluent un allègement de la charge de stockage et une augmentation du débit des requêtes.
3. Entretien coût: Doris est d’architecture simple et est compatible avec le protocole MySQL. Le déploiement de Doris n’implique que deux processus (FE et BE) sans dépendance vis-à-vis d’autres systèmes, ce qui facilite son exploitation et sa maintenance. De plus, Doris prend en charge l’interrogation des tables de données ES externes. Il peut facilement s’interfacer avec les métadonnées dans ES et mapper automatiquement le schéma de table à partir d’ES afin que nous puissions effectuer des requêtes sur les données Elasticsearch via Doris sans nous débattre avec des connexions complexes.

De plus, Doris prend en charge plusieurs méthodes d’ingestion de données, y compris l’importation par lots à partir d’un stockage distant tel que HDFS et S3, les lectures de données à partir de MySQL binlog et Kafka, et la synchronisation de données en temps réel ou l’importation par lots à partir de MySQL, Oracle et PostgreSQL. Il assure la disponibilité du service et la fiabilité des données grâce à un protocole de cohérence et est capable d’auto-débogage. C’est une excellente nouvelle pour nos opérateurs et nos mainteneurs.

Statistiquement parlant, ces fonctionnalités ont réduit nos coûts de stockage de 42 % et nos coûts de développement de 40 %.

Au cours de notre utilisation de Doris, nous avons reçu beaucoup de soutien de la communauté open source Apache Doris et une aide opportune de l’équipe SelectDB, qui exécute maintenant une version commerciale d’Apache Doris.

D’autres améliorations pour répondre à nos besoins

Introduire une couche sémantique

En parlant d’ensembles de données, du bon côté, nos analystes de données ont la liberté de redéfinir et de combiner les balises et les mesures à leur convenance. Mais du côté obscur, la grande hétérogénéité des systèmes d’étiquettes et de métriques entraîne plus de difficultés dans leur utilisation et leur gestion.

Notre solution consiste à introduire une couche sémantique dans notre pipeline de traitement de données. La couche sémantique est l’endroit où tous les termes techniques sont traduits en concepts plus compréhensibles pour nos utilisateurs de données internes. En d’autres termes, nous transformons les balises et les métriques en citoyens de première classe pour la définition et la gestion des données.

Pourquoi cela aiderait-il ?

Pour les analystes de données, toutes les balises et mesures seront créées et partagées au niveau sémantique afin qu’il y ait moins de confusion et une plus grande efficacité.

Pour les utilisateurs de données, ils n’ont plus besoin de créer leurs propres jeux de données ou de déterminer lequel est applicable pour chaque scénario, mais peuvent simplement effectuer des requêtes sur leur jeu de balises et leur jeu de métriques spécifiés.

Mettre à niveau la couche sémantique

Définir explicitement les balises et les métriques au niveau de la couche sémantique ne suffisait pas. Afin de construire un système de traitement de données standardisé, notre objectif suivant était d’assurer une définition cohérente des balises et des métriques tout au long du pipeline de traitement des données.

Pour cela, nous avons fait de la couche sémantique le cœur de notre système de gestion de données :

Comment ça marche?

Toutes les logiques de calcul dans TDW seront définies au niveau de la couche sémantique sous la forme d’une seule balise ou métrique.

La couche sémantique reçoit les requêtes logiques du côté application, sélectionne un moteur en conséquence et génère du SQL. Ensuite, il envoie la commande SQL à TDW pour exécution. Pendant ce temps, il peut également envoyer des tâches de configuration et d’ingestion de données à Doris et décider quelles métriques et balises doivent être accélérées.

De cette façon, nous avons rendu les balises et les métriques plus gérables. Une mouche dans la pommade est que puisque chaque balise et métrique est définie individuellement, nous avons du mal à automatiser la génération d’une instruction SQL valide pour les requêtes. Si vous avez une idée à ce sujet, vous êtes plus que bienvenu pour nous en parler.

Donnez le plein jeu à Apache Doris

Comme vous pouvez le voir, Apache Doris a joué un rôle central dans notre solution. L’optimisation de l’utilisation de Doris peut grandement améliorer l’efficacité globale de notre traitement des données. Ainsi, dans cette partie, nous allons partager avec vous ce que nous faisons avec Doris pour accélérer l’ingestion et les requêtes de données et réduire les coûts.

Ce que nous voulons

Actuellement, nous avons plus de 800 balises et plus de 1300 métriques dérivées des plus de 80 tables sources dans TDW. Lors de l’importation de données de TDW vers Doris, nous espérons obtenir :

La génération de tableaux plats dans TDW présente quelques inconvénients :

• Coût de stockage élevé: TDW doit maintenir une table plate supplémentaire en dehors des tables sources discrètes 80+. C’est une énorme redondance.
• Temps réel faible: Tout retard dans les tables source sera augmenté et retardera toute la liaison de données.
• Coût de développement élevé: Pour atteindre l’actualité, il faudrait des efforts de développement et des ressources supplémentaires.

Au contraire, générer des tableaux plats dans Doris est beaucoup plus facile et moins coûteux. Le processus est le suivant :

1. Utilisez Spark pour importer de nouvelles données dans Kafka de manière hors ligne.
2. Utilisez Flink pour consommer des données Kafka.
3. Créez une table plate via l’ID de clé primaire.
4. Importez la table plate dans Doris.

Comme indiqué ci-dessous, Flink a regroupé les cinq lignes de données, dont « ID » = 1, en une seule ligne dans Doris, réduisant ainsi la pression d’écriture des données sur Doris.

Cela peut réduire considérablement les coûts de stockage puisque TDW n’a plus à conserver deux copies de données, et KafKa n’a besoin que de stocker les nouvelles données en attente d’ingestion. De plus, nous pouvons ajouter la logique ETL de notre choix dans Flink et réutiliser de nombreuses logiques de développement pour l’ingestion de données hors ligne et en temps réel.

2. Nommez les colonnes intelligemment

Comme nous l’avons mentionné, le modèle agrégé de Doris permet une mise à jour partielle des colonnes. Nous fournissons ici une introduction simple à d’autres modèles de données dans Doris pour votre référence :

• Modèle Unique: cela s’applique aux scénarios nécessitant l’unicité de la clé primaire. Il ne conserve que les dernières données du même ID de clé primaire. (Pour autant que nous le sachions, la communauté Apache Doris prévoit également d’inclure une mise à jour partielle des colonnes dans le modèle unique.)
• Modèle dupliqué: Ce modèle stocke toutes les données d’origine exactement telles qu’elles sont, sans pré-agrégation ni déduplication.

Après avoir déterminé le modèle de données, nous avons dû réfléchir à la façon de nommer les colonnes. L’utilisation des balises ou des métriques comme noms de colonne n’était pas un choix car :

1. Nos utilisateurs de données internes peuvent avoir besoin de renommer les métriques ou les balises, mais Doris 1.1.3 ne prend pas en charge la modification des noms de colonne.
2. Les balises peuvent être prises en ligne et hors ligne fréquemment. Si cela implique l’ajout et la suppression de colonnes, non seulement cela prendra du temps, mais cela nuira également aux performances des requêtes.

Au lieu de cela, nous procédons comme suit :

• Pour un renommage flexible des balises et des métriques, nous utilisons des tables MySQL pour stocker les métadonnées (nom, identifiant global unique, statut, etc.). Toute modification des noms ne se produira que dans les métadonnées mais n’affectera pas le schéma de table dans Doris. Par exemple, si un…