数据孤岛问题就像在线企业的关节炎，因为几乎每个人随着年龄的增长都会遇到这个问题。企业通过网站、移动应用、H5 页面和终端设备与客户互动。出于某种原因，整合所有这些来源的数据是一件很棘手的事情。数据保留在原处，无法相互关联以进行进一步分析。这就是数据孤岛的形成方式。您的业务规模越大，您拥有的客户数据源就越多样化，您就越有可能陷入数据孤岛。 这正是我在这篇文章中要讨论的保险公司所发生的情况。到2023年，他们已服务超过5亿客户，签订了570亿份保险合同。当他们开始构建客户数据平台（CDP）来适应如此大的数据规模时，他们使用了多个组件。  CDP 中的数据孤岛 与大多数数据平台一样，他们的 CDP 1.0 具有批处理管道和实时流管道。离线数据通过 Spark 作业加载到 Impala，在那里被标记并分成组。同时，Spark 还将其发送到 NebulaGraph 进行 OneID 计算（本文稍后详细阐述）。另一方面，实时数据被Flink打上标签，然后存储在HBase中，以备查询。 这导致了 CDP 中的组件密集型计算层：Impala、Spark、NebulaGraph 和 HBase。  结果，离线标签、实时标签和图形数据分散在多个组件中。由于冗余存储和大量数据传输，将它们集成以提供进一步的数据服务成本高昂。更重要的是，由于存储的差异，他们不得不扩大CDH集群和NebulaGraph集群的规模，增加了资源和维护成本。 基于 Apache Doris 的 CDP 对于CDP 2.0，他们决定引入一个统一的解决方案来收拾残局。在CDP 2.0的计算层，  承担实时和离线数据存储和计算。 Apache Doris 为了摄取 ，他们利用 方法。他们的 30 线程摄取测试表明，它每秒可以执行超过 300,000 次更新插入。为了加载 ，他们结合使用了 和 Stream Load。此外，在实时报告中，他们需要从多个外部数据源提取数据，他们利用 功能进行 。  离线数据 流加载 实时数据 Flink-Doris-Connector 多目录 联合查询 此 CDP 上的客户分析工作流程如下。首先，他们整理客户信息；然后他们给每个顾客贴上标签。他们根据标签对客户进行分组，进行更有针对性的分析和操作。 接下来，我将深入研究这些工作负载并向您展示 Apache Doris 如何加速它们。 一个ID 当您的产品和服务有不同的用户注册系统时，您是否遇到过这种情况？您可以从一个产品网页收集用户 ID A 的电子邮件，然后从另一个产品网页收集用户 ID B 的社会安全号码。然后您会发现 UserID A 和 UserID B 实际上属于同一个人，因为他们使用相同的电话号码。 这就是 OneID 作为一个想法出现的原因。就是将所有业务线的用户注册信息汇集到Apache Doris中一张大表中，进行整理，并确保每个用户拥有唯一的OneID。 这就是他们如何利用 Apache Doris 中的功能来确定哪些注册信息属于同一用户。  标签服务 该CDP容纳了 的信息，这些信息来自 ，总共附加了 。 5亿客户 500多个源表 2000多个标签 按照时效性，标签可以分为实时标签和离线标签。实时标签由 Apache Flink 计算并写入 Apache Doris 中的平面表，而离线标签由 Apache Doris 计算，因为它们源自 Doris 中的用户属性表、业务表和用户行为表。以下是该公司在数据标记方面的最佳实践：   1. 离线标签： 在数据写入高峰期，由于数据规模庞大，全量更新很容易导致OOM错误。为了避免这种情况，他们利用 Apache Doris 的 功能并启用 。这将显着减少内存消耗并在数据加载期间保持系统稳定性。 INSERT INTO SELECT 部分列更新   set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....   2.实时标签： 部分列更新也可用于实时标签，因为实时标签的更新速度不同。所需要做的就是将 设置为  。 partial_columns 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、高并发点查询： 以目前的业务规模，该公司正在以超过 5000 QPS 的并发水平接收标签查询请求。他们使用策略组合来保证高性能。首先，他们采用 来预编译和预执行SQL。其次，他们微调 Doris 后端和表的参数以优化存储和执行。最后，它们启用行 作为面向列的 Apache Doris 的补充。 Prepared Statement 缓存 微调 中的 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）： 在实践中，很多标签服务都是通过数据库中的多表连接来实现的。这通常涉及十多张桌子。为了获得最佳的计算性能，他们在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 也发布 。 在这里

This story contains new, firsthand information uncovered by the writer.

Join the Apache Doris community on Slack

Read My Stories

該音頻是用故事的原始語言製作的！

打破数据孤岛：Apache Doris 如何简化客户数据集成

About Author

註釋

標籤

这篇文章刊登在

Related Stories

看不见的层面：为什么用户访谈是不可替代的资产

扬帆起航：利用数据湖开发生产级 RAG 应用程序

比特币 UTXO 模型，为独特的生态系统提供动力

Telegram：加密岛通往大陆的桥梁

看不见的层面：为什么用户访谈是不可替代的资产

扬帆起航：利用数据湖开发生产级 RAG 应用程序

比特币 UTXO 模型，为独特的生态系统提供动力

Telegram：加密岛通往大陆的桥梁

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps