共计 6532 个字符，预计需要花费 17 分钟才能阅读完成。
导读：随着业务在金融、保险和商城畛域的一直扩大，众安保险建设 CDP 平台以提供自动化营销数据反对。晚期 CDP 平台依赖于 Spark + Impala + Hbase + Nebula 简单的技术组合，这不仅导致数据分析造成数据孤岛，还带来昂扬的治理及保护老本。为解决该问题，众安保险引入 Apache Doris，替换了晚期简单的技术组合，不仅升高了零碎的复杂性，突破了数据孤岛，更晋升了数据处理的效率。
众安在线财产保险股份有限公司是中国首家互联网保险公司，由蚂蚁金服、中国安全和腾讯于 2013 年联结发动设立。众安专一于利用新技术重塑保险价值链，围绕衰弱、数字生存、生产金融、汽车四大生态，以科技服务新生代，为其提供个性化、定制化、智能化的新保险。业务和关联公司的业务包含：众安保险、众安医疗、众安小贷、众安科技、众安经纪、众安国内、众安银行等。截至 2023 年中，众安服务超过 5 亿用户，累计出具约 574 亿张保单。
然而，随着业务在金融、保险和商城畛域的一直扩大，众安保险面临用户数据管理的挑战。用户信息来源于公众号、小程序和 APP 等多个渠道，这些数据不仅碎片化，而且多样化。同时，经营渠道也涵盖了自营、联营和内部投放等多种路径，导致数据进一步扩散。这种数据孤岛景象使得众安保险难以造成残缺的用户交融体系，从而无奈实现对用户的精准辨认和实时营销。
CDP 建设指标及计划
为了解决这一问题，众安保险建设了 CDP 平台。该平台的外围职责是整合所有用户数据，构建全面的用户标签和客群体系，并利用其弱小的数据分析能力为自动化营销提供数据反对。
CDP 平台的建设指标次要包含以下几点：
- 疾速数据集成：CDP 需反对集成常见的关系性数据库（如 MySQL、PG 等）和数据仓库同（如 Hive、MaxCompute 等），同时还须要整合实时数据流（如 Kafka 等）。
- 精准用户辨认：在简单的业务体系中，CDP 平台需可能灵便整合多种 ID 类型，造成对立的用户视图，为上游的实时营销场景提供撑持。
- 灵便的用户标签和弱小的分群能力：这是 CDP 平台的外围建设指标，旨在提供全面、深度的用户洞察，精准满足用户需要。
- 多维度实时剖析：反对对用户画像、用户旅程和营销成果的实时跟踪与回收。为优化营销策略和晋升用户参与度提供无力的反对。
基于上述建设指标，众安保险目前已造成了残缺的 CDP 解决方案，该计划包含以下几个关键步骤：
- 全域数据采集：CDP 平台通过实时和离线数据采集形式，实现对全域数据的整合。利用 Flink 进行实时数据采集，同时建设离线数仓以整合多渠道数据，确保高质量的数据资产积淀。
- 用户数据交融：通过 ID Mapping 技术，可将现有的用户数据进行交融，突破数据孤岛。行将用户手机、用户身份证、设施指纹、OpenID 等用户身份进行交融，造成对立的用户标识（OneID）。
- 标签和客群治理：CDP 平台反对多维度标签的建设，蕴含用户属性、用户行为、业务交易状态等。同时，通过规定客群的圈选能力实力客群的精密划分。
- 用户数据分析：基于丰盛的用户标签数据，CDP 平台提供用户画像洞察性能，反对实时成果评估和营销漏斗剖析。
- 用户数据服务：CDP 平台提供多维度的数据接口服务能力，包含用户标签、客群、分层和实时事件等，赋能用户全链路智能营销。
CDP 平台架构的演进历程
在初步理解了 CDP 平台的建设初衷和解决方案之后，咱们将深刻开掘其演进历程，摸索它如何逐渐变质为众安保险对立、高效且不可或缺的外围基础设施。本文将重点分享 CDP 平台的建设过程及其在理论生产中的利用实际。
CDP 产品架构如上图所示。全域数据接入之后，这些数据就能够搭建用户数据中心、实时事件核心、客群画像以及营销流程。用户数据中心是客群画像的基石，并与客群画像、实时事件核心一起撑持营销流程的数据需要。数据服务层则包含用户数据服务、客群圈选、营销策略、实时事件、AB 试验和实时成果剖析回收在内的全方位数据服务，满足各业务场景的数据需要。
架构 1.0：多个技术栈，造成数据孤岛
CDP 平台架构 1.0 如上图所示，离线数据和实时数据的解决流程如下：
- 离线数据：通过 ETL 形式集成各业务线的数据库数据，包含行为埋点数据、日志数据等，并将这些数据抽取数仓 DWS 层。随后，利用 Spark 作业将 DWS 层数据抽取到 Impala 中，进行离线的标签计算和客群的圈选。同时，咱们还通过 Spark 抽取 DWS 层业务体系里的用户点边关系，并将其集成到 Nebula 图数据库中，提供全面的点边关系计算、边距计算以及 One ID 计算性能。
- 实时数据：采纳 Kafka 实时回收所有的业务线的 Binlog 数据、行为埋点数据以及各业务线的事件上报数据，在 Flink 中实现实时标签的配置化计算，并通过 Flink Checkpoint 进行简单的实时指标计算和事件组合。最终将实时标签存储在 Hbase 中，以便为各业务线提供点查服务。
然而，从架构图中能够显著看出，标签计算和 ID 图谱计算这一层波及了十分多的技术栈，蕴含 Impala、Spark、Nebula 以及 Hbase。这些过多的组件导致了离线标签、实时标签以及图数据存储的不对立、各场景数据扩散存储，造成了数据孤岛。
在这种状况下，当需进行整体视图计算或为下层提供服务时，就须要买通所有的数据，这无疑减少了大量数据传输和数据反复存储的老本。此外，因为各类数据存储计划的差别，还须要应用较大的 CDH 集群和 Nebula 图数据库集群，进一步提高了集群资源与保护老本。
架构 2.0：对立技术栈，突破数据孤岛
为了解决数据存储的不一致性和昂扬老本问题，咱们决定进行架构降级，并抉择 Apache Doris 作为外围组件。咱们的降级指标是心愿通过引入 Doris 来对立技术栈，实现实时和离线数据存储和计算的整合，从而突破数据孤岛，大幅度降低数据存储和资源保护的老本。在理论的利用中，Doris 完满地满足了咱们的需要，使得整体架构变得更精简高效。
对于离线数据，咱们采纳了 Doris 的 Stream Load 性能，轻松地从离线数仓中将数据抽取到 Doris 中。而对于实时数据，则通过 Flink Connector 与 Stream Load 的联合，将实时事件和实时标签无缝导入到 Doris 中。基于 Doris 弱小的向量化计算引擎，咱们不仅实现了 One ID 计算、离线 / 实时标签的存储和计算、客群圈选、实时事件存储，还反对了实时剖析等多样化需要，真正实现了技术栈的对立。
引入 Doris 后，咱们还播种了以下显著的收益：
- 架构简洁，运维老本升高：引入 Doris 之前，咱们须要额定保护 CDH 集群和 Nebula 集群。而当初，仅凭一个 Doris 集群就能够实现所有的工作，显著升高运维老本。此外，Doris 还提供的欠缺集群监控设施也极大不便了咱们对集群的便捷治理。
- 反对 SQL，疾速上手：Doris 兼容 MySQL 协定，这意味着对于曾经相熟 MySQL 的开发者来说，无需额定的学习老本就能疾速上手操作。
- 丰盛的数据导入模式：Doris 提供了丰盛且便捷的数据导入形式，使数据库迁徙和数据导入变得高效和不便。用户能够依据理论需要抉择适宜的导入形式，以疾速实现数据迁徙和导入操作。
Doris for CDP 在业务场景中的实际
全域数据采集
为满足不同场景的数据集成需要，CDP 平台次要分为三个板块：
- 离线数据导入：针对标签计算、实时客群预估与圈选，以及标签和客群多维画像剖析等场景，咱们采纳 DataX 工具，通过 Stream Load 形式将离线数据高效写入到 Doris 里。为确保 Stream Load 的稳定性，咱们在线上对 30 多个线程并发导入进行测试，结果显示，每秒 Upsert（写入或更新）数量高达 30+ 万条。对于咱们以后的一级用户量来说，导入成果能够很好满足咱们的需要。
- 局部列更新：在实时写入场景中，当应用 Flink 实时写入标签数据时，须要准确到单个用户和标签的实时更新和插入，流程绝对简单。而 Doris Stream Load 能够开启局部列更新 partial_columns=true 来满足这一需要，确保每个用户和标签都能失去及时、精确的更新。
- 内部数据源对接：在实时剖析报表场景中，常常须要跨多个数据源的穿插剖析。Doris 的 Multi-Catalog 性能能够更不便对接内部数据目录，无需进行数据迁徙或导入，即可进行内部数据源的联邦查问。无论是基于 Hive 或 MaxCompute 的查问，还是 JDBC 业务线的数据查问，都能迅速取得精准的剖析后果，极大晋升了查问效率。
OneID
1. 构建 ID 图谱
咱们在现有零碎中配置了 ID 图谱的点关系，这些关系以用户为核心，造成了简单的网络结构。举例说明：假如某用户在体系 A 领有用户 ID，并且绑定的公众号，这样就造成了 Open ID 绑定关系。随着用户的应用，他可能注册了手机号，那么手机号跟体系 A 用户 ID 之间便建设了绑定关系。如果用户在体系 A 也进行了实名，那么身份证和注册手机号也会建设绑定关系。
随着工夫的推移，该用户可能进入到体系 B 中，并注册体系 B 账户。这时，与该用户相干的体系 A 用户 ID、手机号、身份证和体系 B 账户之间都会造成关联。在如上图右侧零碎里，咱们能够配置用户 ID、OpenID、手机号、身份证这些点的属性、物理表及关联关系，造成 ID 图谱。那么联合 ID 图谱，就能够基于 Doris 进行 OneID 的构建。
2. 构建 OneID
基于用户各个业务线之间点和边的关系，咱们会将用户在不同业务线中的信息全副抽取进去，放入一张大表外面进行 Union All 操作。这张表蕴含了手机号、体系 A 用户 ID、体系 B 用户 ID、身份证号和 Open ID 要害信息。OneID 的构建流程如下：
- 首先，利用 Doris 提供的
row number窗口函数生成残缺的全局行程序。而后对所有 ID 关系数据进行 Union All 操作。 - 接着，应用窗口函数
dense rank和row number的复数生成为空 / 不为空时的首列 Rank 值。 - 最初，通过循环迭代计算每一列最小间隔，并一直迭代 Rank 值，直到当前列与上一迭代后果全局匹配。当所有数据间断匹配满 5 次后，就以最终 Rank 值为准进行用户分组，从而得用户惟一标识 OneID。
联合上图以及构建流程，能够得出结论：1 – 4 行是用户 1，5 – 6 行是用户 2。
标签体系
咱们的标签体系由实时标签和离线标签两局部组成，目前该体系领有超过 2000 个标签，波及 50 余张起源表，服务用户量已达亿级。
在标签体系中，有一些简略的配置规定：
- 离线标签：在 Doris 中形象出三种业务类型表，别离是用户数据表、业务明细表和行为事件表。依据上方标签配置规定，通过 DSL 动静语义生成 SQL，而后在 Doris 中进行计算，并将计算结果存储在 Doris 中，造成一张离线标签宽表。
- 实时标签：基于 Flink 接管 Kafka、CDC 音讯，并依据实时标签配置元数据，在 Flink 中计算出实时标签，并将最终后果写入 Doris 的实时标签宽表中。
Apache Doris 在标签体系中的利用次要蕴含以下四个方面：
1. 离线标签解决： 因为领有 2000+ 较大量级的标签一级用户，当遇到高峰期并发宽表写入时，全量更新所有列可能会呈现内存不足的问题。为防止该问题，咱们利用 Doris 的 Insert Into Select 性能，在 session 变量中关上局部列更新开关，只更新指标表中须要批改的列，这样可显著缩小内存耗费，以晋升全量导入的稳定性。
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 Column，并将其设置为 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 标签申请的挑战。为满足这一需要，咱们采纳多种策略来确保高效的点查性能。首先，通过利用 PrepareStatement 技术，预编译和执行 SQL 查问，从而进步查问效率。其次，精密调整了 Backend（BE）参数和表参数，以优化数据存储和查问性能。同时，咱们关上了行存，进一步晋升零碎在高并发场景下的解决能力。
- 在 be.conf 中调整 BE 参数：
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. 标签计算 ：为了满足用户对于标签配置的灵便需要，零碎容许在 DSL 生成的语义中进行多表 Join 操作，而这就可能会波及十几张表的 Join 操作。为了确保标签计算性能最优，咱们充分运用 Doris Colocation Group 策略，对所有分桶列的类型、数量和正本进行对立，并优先满足 Colocation Join 和本地的 Hash Join。在线上环境中，也能够关上Colocate With 开关，指定一个 Group，确保全局表的分片与正本策略统一。
客群圈选
在架构 1.0 中，客群服务学生成动静 SQL，而后将其传输到 Impala 中进行客群圈选。实现圈选后，后果集需被从新读取回客群服务，并由其上传到对象存储中。这一连串的操作使得数据处理链路绝对简短，影响了整体效率。而在架构 2.0 中，咱们能够在 Doris 中应用基于 Select 语句的后果集，并通过 Select Into Outfile 性能，将数据无缝导入到 S3 协定的对象存储中，这种形式极大缩短了数据处理链路。
在理论的业务中，线上约有 100 万个客群，单个客群生成所需工夫从 50 秒缩短至 10 秒，极大晋升了客群圈选效率。 若须要进一步提高性能，能够抉择关上并发导出开关，进一步提高数据导出性能。
客群归属
在咱们的业务零碎中，客群归属扮演着至关重要的角色，特地是在实时智能营销和千人千面的辨认场景中。咱们常常须要判断某个用户是否隶属于特定的客群，或者确定其属于哪些客群。这种全局性的判断有助于咱们深刻了解多个客群之间的用户重叠关系。
为了满足这一需要，咱们能够借助 Bitmap 来实现。在 Bitmap 中，应用 Bitmap Contains 能够疾速辨认某个用户是否存在于特定客群中，也能够通过 Bitmap OR、Bitmap Intersect 或 Bitmap XOR 来实现客群全量、多版本之间的交并叉剖析，从而提供更为精准和高效的营销策略。
总结与瞻望
在架构 1.0 中采纳了简单的技术组合，以实现标签、客群以及 OneID 的计算。这一架构组件泛滥，导致数据处理链路简短、造成数据孤岛，且有着较高的治理和保护老本。通过引入 Apache Doris，替换了 Spark + Impala + Hbase + Nebula，胜利实现存储与计算的对立，简化了数据处理的流程，不仅升高了零碎的复杂性，更晋升了数据处理的效率，满足了更丰盛的数据处理需要。随着业务的倒退，实时营销场景对实时性的要求日益晋升。将来，咱们打算在 3.0 版本中，实现离线标签和实时标签的混合圈选性能，并依靠 Doris 进行 OneID 实时计算。这将使咱们可能更疾速、精确地辨认增量的用户，并在多用户体系中实现精准的用户辨认，以满足一直变动的业务需要，推动实时智能营销和个性化辨认场景的继续翻新与倒退。最初，咱们衷心感谢 SelectDB 技术团队 所提供的技术支持，将来咱们期待与社区更严密的单干，为社区奉献力不从心的力量，独特推动技术的倒退与提高。
