Briser les silos de données : comment Apache Doris rationalise l'intégration des données client

Le problème des silos de données est comme l’arthrite pour les entreprises en ligne, car presque tout le monde en souffre en vieillissant. Les entreprises interagissent avec les clients via des sites Web, des applications mobiles, des pages H5 et des appareils finaux. Pour une raison ou une autre, il est délicat d’intégrer les données provenant de toutes ces sources. Les données restent là où elles se trouvent et ne peuvent pas être interconnectées pour une analyse plus approfondie. C’est ainsi que se forment les silos de données. Plus votre entreprise se développe, plus vous disposerez de sources de données clients diversifiées et plus vous risquez d’être piégé par des silos de données.

C’est exactement ce qui arrive à la compagnie d’assurance dont je vais parler dans cet article. En 2023, ils ont déjà servi plus de 500 millions de clients et signé 57 milliards de contrats d’assurance. Lorsqu'ils ont commencé à créer une plateforme de données client (CDP) pour s'adapter à une telle taille de données, ils ont utilisé plusieurs composants.

Silos de données dans CDP

Comme la plupart des plates-formes de données, leur CDP 1.0 disposait d'un pipeline de traitement par lots et d'un pipeline de streaming en temps réel. Les données hors ligne ont été chargées via des tâches Spark sur Impala, où elles ont été étiquetées et divisées en groupes. Pendant ce temps, Spark l'a également envoyé à NebulaGraph pour le calcul OneID (élaboré plus loin dans cet article). D'autre part, les données en temps réel ont été étiquetées par Flink puis stockées dans HBase, prêtes à être interrogées.

Cela a conduit à une couche de calcul lourde en composants dans le CDP : Impala, Spark, NebulaGraph et HBase.

En conséquence, les balises hors ligne, les balises en temps réel et les données graphiques étaient dispersées sur plusieurs composants. Leur intégration pour d'autres services de données était coûteuse en raison du stockage redondant et du transfert de données volumineux. De plus, en raison d'écarts de stockage, ils ont dû augmenter la taille du cluster CDH et du cluster NebulaGraph, augmentant ainsi les coûts de ressources et de maintenance.

CDP basé sur Apache Doris

Pour CDP 2.0, ils décident d’introduire une solution unifiée pour nettoyer les dégâts. Au niveau de la couche de calcul de CDP 2.0, Apache Doris assure le stockage et le calcul des données en temps réel et hors ligne.

Pour ingérer des données hors ligne , ils utilisent la méthode Stream Load . Leur test d'ingestion de 30 threads montre qu'il peut effectuer plus de 300 000 upserts par seconde. Pour charger des données en temps réel , ils utilisent une combinaison de Flink-Doris-Connector et Stream Load. De plus, dans le cadre du reporting en temps réel, où ils doivent extraire des données de plusieurs sources de données externes, ils exploitent la fonctionnalité Multi-Catalogue pour les requêtes fédérées .

Les workflows d'analyse client sur ce CDP se déroulent comme suit. Premièrement, ils trient les informations sur les clients ; puis ils attachent des étiquettes à chaque client. Sur la base des balises, ils divisent les clients en groupes pour une analyse et un fonctionnement plus ciblés.

Ensuite, je vais approfondir ces charges de travail et vous montrer comment Apache Doris les accélère.

UnID

Cela vous est-il déjà arrivé lorsque vous disposez de différents systèmes d’enregistrement des utilisateurs pour vos produits et services ? Vous pouvez collecter l'e-mail de l'ID utilisateur A à partir d'une page Web de produit et plus tard le numéro de sécurité sociale de l'ID utilisateur B à partir d'une autre. Ensuite, vous découvrez que l'ID utilisateur A et l'ID utilisateur B appartiennent en fait à la même personne car ils portent le même numéro de téléphone.

C'est pourquoi OneID est une idée. Il s'agit de regrouper les informations d'enregistrement des utilisateurs de tous les secteurs d'activité dans une grande table dans Apache Doris, de les trier et de s'assurer qu'un utilisateur dispose d'un OneID unique.

C'est ainsi qu'ils déterminent quelles informations d'enregistrement appartiennent au même utilisateur, en tirant parti des fonctions d'Apache Doris.

Services de marquage

Ce CDP héberge les informations de 500 millions de clients , provenant de plus de 500 tables sources et attachées à plus de 2 000 balises au total.

En termes d'actualité, les balises peuvent être divisées en balises en temps réel et en balises hors ligne. Les balises en temps réel sont calculées par Apache Flink et écrites dans la table plate d'Apache Doris, tandis que les balises hors ligne sont calculées par Apache Doris car elles sont dérivées de la table d'attributs utilisateur, de la table métier et de la table de comportement utilisateur dans Doris. Voici les meilleures pratiques de l'entreprise en matière de marquage des données :

1. Balises hors ligne :

Pendant les pics d'écriture de données, une mise à jour complète peut facilement provoquer une erreur MOO, étant donné l'énorme quantité de données. Pour éviter cela, ils utilisent la fonction INSERT INTO SELECT d'Apache Doris et activent la mise à jour partielle des colonnes . Cela réduira considérablement la consommation de mémoire et maintiendra la stabilité du système pendant le chargement des données.

 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....

2. Balises en temps réel :

Des mises à jour partielles des colonnes sont également disponibles pour les balises en temps réel, car les balises en temps réel sont mises à jour à des rythmes différents. Il suffit de définir partial_columns sur true .

 curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. Requêtes ponctuelles à haute concurrence :

Compte tenu de la taille actuelle de son entreprise, l'entreprise reçoit des requêtes de requêtes pour des balises à un niveau de simultanéité de plus de 5 000 RPS. Ils utilisent une combinaison de stratégies pour garantir des performances élevées. Premièrement, ils adoptent une instruction préparée pour la pré-compilation et la pré-exécution de SQL. Deuxièmement, ils affinent les paramètres de Doris Backend et des tables pour optimiser le stockage et l'exécution. Enfin, ils activent le cache de lignes en complément d'Apache Doris orienté colonnes.

• Affinez les paramètres Doris Backend dans be.conf :

 disable_storage_row_cache = false storage_page_cache_limit=40%

• Affinez les paramètres de la table lors de la création de la table :

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. Calcul des balises (joindre) :

En pratique, de nombreux services de marquage sont implémentés par des jointures multi-tables dans la base de données. Cela implique souvent plus de dix tables. Pour des performances de calcul optimales, ils adoptent la stratégie de groupe de colocation dans Doris.

Regroupement de clients

Le pipeline de regroupement de clients dans CDP 2.0 ressemble à ceci : Apache Doris reçoit le SQL du service client, exécute le calcul et envoie l'ensemble de résultats au stockage d'objets S3 via SELECT INTO OUTFILE. L'entreprise a divisé ses clients en 1 million de groupes. La tâche de regroupement de clients qui prenait auparavant 50 secondes dans Impala ne nécessite désormais plus que 10 secondes dans Doris .

En plus de regrouper les clients pour une analyse plus fine, ils effectuent parfois des analyses dans le sens inverse. Autrement dit, cibler un certain client et découvrir à quels groupes il appartient. Cela aide les analystes à comprendre les caractéristiques des clients ainsi que la façon dont les différents groupes de clients se chevauchent.

Dans Apache Doris, ceci est implémenté par les fonctions BITMAP : BITMAP_CONTAINS est un moyen rapide de vérifier si un client fait partie d'un certain groupe, et BITMAP_OR , BITMAP_INTERSECT et BITMAP_XOR sont les choix pour l'analyse croisée.

Conclusion

Du CDP 1.0 au CDP 2.0, la compagnie d'assurance adopte Apache Doris, un entrepôt de données unifié, pour remplacer Spark+Impala+HBase+NebulaGraph. Cela augmente l’efficacité du traitement des données en éliminant les silos de données et en rationalisant les pipelines de traitement des données. Dans CDP 3.0 à venir, ils souhaitent regrouper leurs clients en combinant des balises en temps réel et des balises hors ligne pour une analyse plus diversifiée et flexible. La communauté Apache Doris et l'équipe VeloDB continueront d'être un partenaire de soutien pendant cette mise à niveau.

Également publié ici .