Briser les silos de données grâce à un entrepôt de données unifié : CDP basé sur Apache Doris

À mesure que les sources de données des entreprises se diversifient de plus en plus, le problème des silos de données est devenu courant. Lorsque les compagnies d’assurance créent des plates-formes de données clients (CDP), elles sont confrontées au problème des couches informatiques à forte intensité de composants et du stockage des données dispersées causé par les silos de données. Afin de résoudre ces problèmes, ils ont adopté CDP 2.0 basé sur Apache Doris, en utilisant les capacités d'entrepôt de données unifiées de Doris pour briser les silos de données, simplifier les pipelines de traitement des données et améliorer l'efficacité du traitement des données.

Le problème des silos de données est comme l'arthrite pour les entreprises en ligne, car presque tout le monde y est confronté en vieillissant. Les entreprises interagissent avec les clients via des sites Web, des applications mobiles, des pages HTML5 et des appareils finaux. Pour une raison quelconque, l’intégration des données provenant de toutes ces sources est délicate. Les données restent là où elles se trouvent et ne peuvent pas être corrélées entre elles pour une analyse plus approfondie. C’est ainsi que se forment les silos de données. Plus votre entreprise grandit, plus vous disposez de sources de données client diversifiées et plus vous risquez de vous retrouver piégé dans des silos de données.

C’est exactement ce qui se passe avec les compagnies d’assurance dont je vais parler dans cet article. D’ici 2023, ils ont servi plus de 500 millions de clients et signé 57 milliards de contrats d’assurance. Lorsqu'ils ont commencé à créer leur plateforme de données client (CDP) pour s'adapter à une telle échelle 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 dispose à la fois de pipelines par lots et de pipelines de streaming en temps réel. Les données hors ligne sont chargées dans Impala via une tâche Spark, où elles sont étiquetées et divisées en groupes. Dans le même temps, Spark l'envoie également à NebulaGraph pour le calcul OneID (nous en parlerons plus loin dans cet article). D'autre part, les données en temps réel sont étiquetées par Flink puis stockées dans HBase pour requête.

Cela se traduit par une couche informatique à forte intensité de composants dans CDP : Impala, Spark, NebulaGraph et HBase.

En conséquence, les étiquettes hors ligne, les étiquettes en direct et les données graphiques sont dispersées sur plusieurs composants. Leur intégration pour fournir des services de données supplémentaires est coûteuse en raison du stockage redondant et des transferts de données volumineux. Plus important encore, en raison des différences de stockage, ils ont dû étendre l'échelle 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 ont décidé d'introduire une solution unifiée pour nettoyer les dégâts. Dans la couche informatique de CDP 2.0, Apache Doris est responsable du stockage et du calcul des données en temps réel et hors ligne.

Afin d'ingérer des données hors ligne, ils utilisent la méthode de chargement en streaming. Leur test d'ingestion de 30 threads a montré qu'il peut effectuer plus de 300 000 insertions de mises à jour par seconde. Pour charger des données en temps réel, ils ont utilisé une combinaison de Flink-Doris-Connector et Stream Load. De plus, dans le cadre des rapports en temps réel qui nécessitent d'extraire des données de plusieurs sources de données externes, ils exploitent les capacités multi-catalogues pour les requêtes fédérées.

Le workflow d'analyse client sur ce CDP est le suivant. Tout d’abord, ils organisent les informations sur les clients, puis étiquetent chaque client. Ils regroupent les clients selon des balises pour une analyse et des actions plus ciblées.

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

One ID

Avez-vous déjà rencontré cette situation lorsque vos produits et services ont différents systèmes d'enregistrement des utilisateurs ? Vous pouvez collecter l'e-mail de l'ID utilisateur A à partir d'une page produit, puis collecter le numéro de sécurité sociale de l'ID utilisateur B à partir d'une autre page produit. Vous découvrirez alors que UserID A et UserID B appartiennent en réalité à la même personne car ils utilisent le même numéro de téléphone.

C’est pourquoi OneID est né de l’idée. Il s'agit de collecter les informations d'enregistrement des utilisateurs de tous les secteurs d'activité dans un grand tableau dans Apache Doris, de les organiser et de garantir que chaque utilisateur dispose d'un OneID unique.

C'est ainsi qu'ils exploitent les fonctionnalités d'Apache Doris pour déterminer quelles inscriptions appartiennent au même utilisateur.

Tag Service

Ce CDP héberge 500 millions d'informations clients provenant de plus de 500 tables sources avec un total de plus de 2000 balises attachées.

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

1. Étiquetage hors ligne

Pendant la période de pointe d'écriture de données, en raison de la grande échelle des données, les mises à jour complètes peuvent facilement entraîner des erreurs de MOO. Pour éviter cela, ils ont exploité la fonctionnalité INSERT INTO SELECT d'Apache Doris et activé les mises à jour partielles 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. Live Labels

Des mises à jour partielles des colonnes sont également disponibles pour les étiquettes en direct, car même les étiquettes en direct se mettent à jour à des vitesses différentes. 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ête de point de concurrence élevée

以目前的业务规模，该公司正在以超过 5000 QPS 的并发水平接收标签查询请求。他们使用策略组合来保证高性能。首先，他们采用Prepared Statement来预编译和预执行SQL。其次，他们微调 Doris 后端和表的参数以优化存储和执行。最后，它们启用行缓存作为面向列的 Apache Doris 的补充。

微调 Doris 的后端参数be.conf：

disable_storage_row_cache = false                      
storage_page_cache_limit=40%

创建表时微调表参数：

enable_unique_key_merge_on_write = true
store_row_column = true
light_schema_change = true

4.标签计算（Join）

在实践中，很多标签服务都是通过数据库中的多表连接来实现的。这通常涉及 10 多个表。为了获得最佳的计算性能，他们在Doris中 采用了共置组策略。

客户分组

CDP 2.0 中的客户分组管道是这样的：Apache Doris 从客户服务接收 SQL，执行计算，并通过 SELECT INTO OUTFILE 将结果集发送到 S3 对象存储。该公司已将其客户分为100万组。过去在 Impala 中需要50 秒才能完成的客户分组任务，现在在 Doris 中只需要10 秒。 

除了对客户进行分组进行更细粒度的分析外，有时他们还会进行反向分析。即针对某个客户，找出他/她属于哪些群体。这有助于分析师了解客户的特征以及不同客户群体的重叠情况。

在 Apache Doris 中，这是通过 BITMAP 函数实现的：BITMAP_CONTAINS是检查客户是否属于某个组的快速方法， 、BITMAP_OR、BITMAP_INTERSECT和BITMAP_XOR是交叉分析的选择。 

结论

从CDP 1.0到CDP 2.0，保险公司采用统一数据仓库Apache Doris替代Spark+Impala+HBase+NebulaGraph。通过打破数据孤岛和简化数据处理管道，提高了数据处理效率。在CDP 3.0中，他们希望通过结合实时标签和离线标签来对客户进行分组，以进行更加多样化和灵活的分析。Apache Doris 社区和VeloDB团队将继续作为此次升级期间的支持合作伙伴。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!