数据孤岛问题就像在线企业的关节炎，因为几乎每个人随着年龄的增长都会遇到这个问题。企业通过网站、移动应用、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 也发布 。 在这里
