🔥 热搜 🔥
上海习近平新疆鄂州父女瓜乌鲁木齐疫情H工口小学生赛高习明泽芊川一笑图包印尼排华
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
查看原文
其他

知乎 DMP/CDP 平台的应用和实践

侯容 DataFunSummit
2024-09-10

导读 本文将分享知乎舰桥平台的研发背景、组成部分，以及它是如何解决业务问题的。文中还将详细介绍 DMP/CDP 落地中遇到的难点和解决方案。

主要内容包括以下四大部分：

1. 背景介绍

2. 架构和设计

3. 难点与解决方案

4. 未来展望

分享嘉宾｜侯容 知乎 舰桥平台研发 Leader 

编辑整理｜余凡

内容校对｜李瑶

出品社区｜DataFun

01

背景介绍

1. 业务背景

知乎的社区产品系统是通过结合推荐算法和搜索引擎的方式，实现内容与用户的精准匹配。

如图右侧所示，将这一平台归纳为产品系统，它代表着市场经济的模式。在这种模式下，用户通过自身的选择来判断内容的优劣，从而体现了整体市场经济的运作。然而，在实际运行中，产品系统需要宏观政策层面的调控以及生态信号的输入。如左侧的运营系统，向产品系统传递诸如监控、促进、引导、组织以及示范等信号，使产品系统进行学习和落地。同时，左右两侧的系统都依赖于用户、创作者和内容等核心资产。运营系统对内进行界面化的投射，形成了一个终端，就是本文要介绍的舰桥平台。

我们之所以将其命名为舰桥，是因为舰桥是军舰的大脑，是操控舰艇和指挥作战的地方，而我们的产品系统也起到同样的作用。

2. 舰桥平台的能力地图

舰桥平台作为运营系统的终端，它集成了运营系统的各项功能，使得运营工作能够在一个统一的平台上高效进行。该平台包括五个核心模块：
  • 内容运营平台
    内容池：提供配置化的内容池能力，解决内容的推荐、搜索召回源和粗排场景，提高策略建设和优化的效率。
    内容榜单：生成和输出各类头部的内容和创作者的榜单，以展示优质内容和创作者。
    内容管理：管理内容从筛选、打包到导出、协作、审批、分享的全流程，确保内容质量和快速响应。
    内容干预：通过强插、提权、扶持、鼓励等手段对内容进行干预，以及进行场景化运营。
  • 内部营销平台
    核心是通过活动手段激发用户参与，包括 CDP（客户数据平台）的使用，营销内容池的管理，内部投放平台的优化，以及活动平台的构建。
  • 创作者运营平台
    专注于创作者的管理，包括社区 CRM（客户关系管理），创作者挖掘、孵化和促活等。
  • 数据中心
    包括 DMP 负责人群选择、人群洞察等能力，同时也包含数据分析能力，包括生态分析、领域分析和效果分析等。
  • 分层运营平台
    根据用户特征、需求或行为进行精细化运营和分层管理。
本文重点介绍的是内部营销平台的 CDP 模块、创作者运营平台的 CRM 模块和数据管理中台 DMP。虽然这些系统在业务流程中各有侧重，但它们的底层能力在本质上是相通的，都涉及到用户的筛选、圈选、洞察、分析和定向预估。这种通用性使得这些系统能够相互协作，为运营工作提供全面的数据支持和策略指导。

02

架构和设计

1. 业务需求

在进行架构设计前，首先要对业务需求进行梳理。

如图所示，右侧详细划分了需求端，涵盖了运营场景、广告投放以及创作者运营等多个方向的需求。在这些需求中，一个常见的场景是希望为特定用户群体举办活动。为了满足这一需求，运营团队会利用 CDP（客户数据平台）精确地圈选出符合活动目标的人群包，同时在活动过程中也会持续优化目标人群，以实现更高效的活动效果。在广告投放策略会先圈选一批大面积的 DMP 人群包进行一次投放，同时通过人群洞察分析潜力待转用户，并圈选实现二次转化，以达到提升转化效果的目标。同样地，在创作者运营方面，社区 CRM 着重于挖掘能创作出契合内容的创作者作为目标用户，并针对这些用户建立有效的沟通机制，以确保创作效果的最大化。

左侧的内部需求可以理解为组织内部对广告投放和数据利用的具体要求，面向外部的调用方则细化为三种主要类型：
  • 信息流广告投放或信息流投放：核心逻辑涉及判断特定用户行为或特征是否匹配预设的人群包。一旦匹配成功，系统将匹配的所有广告内容按照转化进行排序或者针对扶持的内容按照扶持得分排序，以确保广告能够精准触达目标用户群体。
  • 内部投放（包遍历）：此类型调用涉及对内部构建的人群包进行遍历。通过这一过程，完成对用户的投放触达，并能根据投放效果积累基础转化的数据，支持数据挖掘和用户画像构建，为后续的业务投放策略提供有力支持。
  • 内部人群包外部投放：这一类型将内部精心构建的人群包用于外部广告平台。通过与外部广告平台的数据对接和投放策略调整，我们能够充分利用这些人群包的优势，实现广告在更广泛范围内的精准投放，提升广告效果。
资产维护方在标签管理方面的需求主要是如何有效地为资产添加标签。这包括确定合适的标签分类体系，确保标签的准确性和一致性，以及构建易于管理和维护的标签系统。标签的添加应遵循明确的规则和流程，以确保标签能够准确反映资产的特征和属性，为后续的数据分析和洞察提供有力支持。在洞察方面，资产维护方需要了解如何通过数据分析来深入洞察资产的状态和表现。这包括监控资产的实时状态，识别潜在的风险和问题，以及分析资产的使用情况和性能表现。通过洞察，资产维护方可以及时发现并解决问题，优化资产的使用效率，提升资产的价值。

2. 业务架构设计

基于上述需求，我们抽象出了三个平台：CDP 平台、DMP 平台和社区 CRM 平台。尽管三个平台在应用流程和逻辑上存在差异，以满足不同需求，但它们所服务的资产和内部对接人员是一致的，包括分析师、数据运营和研发资产团队等。这种一致性促使我们思考构建一个统一的中间系统作为这些平台的共同对接点。因此我们将中心能力作为架构设计的重点。在设计过程中，做到业务解耦和资源共享。这也更有利于信息广播，当某一平台（如广告投放平台）识别并验证了一个有效的标签时，这一信息能够即时通过中间系统广播给其他两个平台，而无需每个平台都进行独立的逻辑处理。

3. 业务流程

基于上述设计思想，整体流程如上图所示，以实现精准定向的目标。首先，会进行人群的圈选和导入，这包括根据特定条件或属性筛选出目标人群。接着，选择对这些人群进行泛化，以扩大目标受众的范围，并增强投放的灵活性。在泛化完成后，用户可以选择将人群包应用于内部场景进行投放，例如将筛选出的目标人群分发到站内信息流广告中，实现精准推广。另一方面，用户也可以选择将人群包进行 ID 转化后投放到外部平台，通过 ID 映射将内部 ID 转换为外部平台可识别的设备 ID 或其他标识符，确保投放的准确性和有效性。同时在部分合作过程中，需要两家公司或多家公司的标签进行过滤，在过滤的过程中各家公司不期望自家标签泄露，这时隐私保护是至关重要的。因此，在进行这类合作的时候，会使用隐私求交的操作，确保用户数据的安全性和合规性。一旦投放完成，将与外部平台共享特征数据，并构建完成的人群包，以便后续分析和优化。随后，这些投放数据将同步回内部系统，进行深入的洞察分析。通过分析数据，可以判断投放效果是否达到预期目标，并据此进行策略优化。如果投放效果良好，将继续沿用当前策略；若效果未达预期，将根据分析结果进行相应调整，以不断提升投放效果。整个业务流程的设计旨在实现精准定向、高效投放和持续优化，以满足用户的业务需求。

4. 功能要求

进一步拆解出如下功能要求：
  • 人群定向
    首先，系统需要能够快速计算并预估在特定标签下的人群数量。
    在预估人数之后，系统要能够根据用户选定的标签和条件，精确地圈选出目标人群，并将这些人群组合成一个可管理的“包”概念。
  • 人群洞察
    构成分析：系统需要能够深入分析构成特定人群的用户特征，如年龄、性别、兴趣等，以理解这些人群的基本属性和行为模式。
    对比分析：在投放广告或内容后，系统需要能够追踪并分析用户的点击、转化等行为数据。通过对比不同人群在相同投放策略下的表现，识别出哪些人群对广告或内容更感兴趣，哪些人群更容易产生转化。这种对比分析有助于优化未来的投放策略，提升投放效果。
  • ID Mapping
    在跨平台或跨系统投放时，不同系统可能使用不同格式的 ID 来标识用户，同时相关 ID 也只能使用密文传输。因此，系统需要能够支持大小写 ID 的转化和不同的摘要算法，通过关联导出和上传碰撞的方式，确保在不同家公司之间传递身份的一致性。
  • 特征接入
    包括实时接入和离线的接入。
接下来将基于以上技术需求来设计和构建相应的技术架构。

5. 架构设计

在架构的核心考量中，应当重点关注前台 service 所承载的核心业务功能，前台 service 在此作为共享服务层，确保了三个系统在效果投放底层逻辑上的一致性。尽管这些系统可能在表面上呈现为不同的投放系统，拥有各自的流程，但其背后的逻辑是统一的。具体而言，人群逻辑涉及如何有效地进行人群的圈选和泛化，确保能够精准地定位目标受众。洞察逻辑则侧重于分析构成这些人群的特征，以及如何通过对比分析来优化转化效果。在这两个逻辑之下，还需要关注一系列具体的实现细节，如特征的生产、ID Mapping 的实施、计算任务的运维、DAG 管理以及数据存储策略等。

基于这些核心功能和实现细节，进一步抽象出工作流和技术流。工作流描述了整个业务流程的各个环节和步骤，确保了业务的顺畅进行；技术流则关注于如何利用现有技术实现这些功能和流程，提升系统的效率和稳定性。最终，将基于这些抽象出的工作流和技术流，来设计和实现对应的系统。

6. 特征处理链路设计

在整体 DMP（数据管理平台）的架构中，离线特征写入是一个核心环节，主要包括以下两个关键部分：
  • 基于 Spark 的离线特征计算与写入：利用 Spark 进行日级别和周级别的计算，提取和生成关键特征；将这些计算得到的特征写入中间通用节点的离线 mapping，为后续的数据处理和用户画像构建提供基础。
  • 基于 Flink 的实时特征抽取与写入：Flink 实时处理系统用于捕获和处理今日的新增用户数据，如 ODA 用户（即一次性访问用户）或冷启动新用户；今日新增的各种用户特征会被实时抽取，并通过 Kafka 进行流式处理，完成实时的 mapping 操作。
在图右侧的设备与用户核心部分，主要完成的是统一 ID 的过程。这个过程可以理解为一个宽表操作，它存储了所有类型的ID，并检查这些 ID 是否已存在于系统中。如果 ID 已存在，则返回该 ID 的唯一标识；如果 ID 不存在，则系统会新增该 ID。随着时间的推移，当系统发现多个 ID 实际指向同一用户时，会进行 ID 合并操作，确保用户数据的一致性和准确性。

此外，为了支持用户特征查询和运营需求，系统还维护了一个内部 ID 与外部 ID 转换关系的表，并进行了枚举采集。用户可以通过这个表快速找到相关人群的特征。为了确保这些特征值的准确性和高效查询，系统采用 Elasticsearch（ES）作为存储后端，利用 ES 的快速搜索能力支持运营和销售团队快速定位并应用相关标签。针对可能出现的重复 value 问题，系统会实施去重逻辑，确保数据的唯一性和准确性。同时，ES 中的枚举 value 信息也会得到及时更新和维护，以满足业务团队对数据质量和使用效率的要求。

7. 人群定向流程

人群定向流程链路的抽象主要涵盖以下两个关键部分：
  • 首先，是标签的筛选与优化。通过标签搜索功能精准定位目标用户，例如母婴高转化人群，需要细致选择标签，如一线城市、女性、年轻等。接着，对潜在投放规模进行快速预估，如设定 200 万的投放预算。通过不断尝试添加或移除标签，观察投放效果的变化，从而优化标签组合，直至完成目标人群的精准圈选。
  • 其次，是人群包的生成与泛化。此过程涉及收集站内历史表现良好的用户包，并利用这些数据进行模型训练。具体操作为，将用户 ID 与知乎平台上的所有相关特征进行关联，利用这些特征数据训练模型。随后，将训练好的模型应用于全站用户，为每个用户生成智能评分，从而形成一个全站用户智能评分模型。在此基础上，对模型进行泛化，生成代表不同评分段的全站人群标签，如 50 分、80 分、90 分的用户群体。销售投放团队可根据实际业务需求，选择不同的人群包进行投放试验，并根据效果反馈调整策略。
在实际工作中，通常需要对上述流程进行组合，如将站外用户引入系统，与站内用户数据结合使用，以形成更丰富的用户画像和更精准的定向策略。整个流程以人群包为中间节点，以各种用户特征为外部输入，形成了完整的业务闭环。

03

难点与解决方案

接下来介绍三个阶段中遇到的难题，和我们的解决方案。

1. 难点一：查不动

第一阶段上线初期，由于数据规模变大之后对人群预估时间是 1S，对圈选时间要求为 1Min，查不动，导致圈选不出来。

早期用户标签为 240 万，用户规模为 1 千亿多一点。在这样的数量级之下时间预期比较低，希望 1s 内知道标签交并差等各种标签组合之后的人数是多少，并且希望一分钟圈出来。

传统的解决方式是拉散成一个宽表，对标签进行按照 where in，or 的逻辑查询，但始终无法满足要求。

因为用位图计算速度会快很多，于是在这个过程中做成 bitmap 的倒排。

直接使用 Doris 中的 bitmap，可以看到上图中的 members 就是 bitmap，上下对应的分区和分区 Id 有两个，第一个分区是性别，分区 id 中有男女，置信分是为了人均扩散做的补充的信息。

Id mapping 之前是导出宽表，每一行是一个用户的所有信息。之后改成了男性的所有用户做一个bitmap 倒排作为一行，女性的所有用户做一个 bitmap 倒排作为一行。

查询逻辑也随之发生改变，由之前的 AND、OR、NOT 直接查询，变为在 bitmap方法中加入 AND、OR、NOT。然而这一改动之后的计算速度仍然很慢。如查询 18-25 岁的男性，首先所有男性用户 bitmap 是一行，18-25 岁 bitmap 也是一行，两个 bitmap 求交，逻辑是从 a 机器取出男性的 bitmap，b 机器取出18-25 岁的 bitmap 进行一次 shuffle 合并，合并之后去求交男性和 18-25。这个过程并没有发挥出 MPP 架构的优势。

因此我们采取了分片存储策略，不再是基于性别来存储数据，而是按照如 0-100 万、100-200 万的用户 ID 范围进行分片。虽然这样的分片策略可以发挥多机器并行计算的潜力，但在某些计算场景下，如查询男性 18-25 岁用户群体时，仍可能面临性能瓶颈。

假设我们有一个计算节点需要处理这个特定的用户群体，其中 0-100 万的男性用户数据存储在 A 机器上，而 0-100 万中 18-25 岁的用户数据则位于 B 机器。为了执行这个计算，我们需要从 A 机器中提取男性用户数据，并通过数据交换（exchange）和数据流接收（data stream sink）将其推送至 B 机器（或可能被重新 shuffle 到 C 机器，甚至仍然在 A 和 B 机器之间）。这样的过程涉及网络 I/O 和 Shuffle 操作，可能导致性能下降。

然而，如果我们能在数据写入时就进行智能分片，将具有相同属性（如年龄、性别、兴趣等）的用户数据存储在同一台机器上，就可以极大地减少跨机器计算和数据传输的需求。例如，如果 0-100 万 ID 范围内的男性用户、女性用户以及 18-25 岁对美妆感兴趣的用户数据都存储在 A 机器上，那么我们就可以直接在该机器上进行高效的计算，无需任何网络 IO 或 Shuffle 操作。

这种智能分片策略的核心逻辑类似于位图的乘法分配律。通过确保相关数据在同一位置，可以将整体的交并差操作简化为各个 ID 段内的独立操作，从而显著提高计算效率。为了实现这一点，需要在数据写入时就考虑好分片策略，确保所有相关的数据都被写入到同一台机器上。

Doris 的 colocate join 功能原本是为了解决 join 操作时的性能问题而设计的，然而，在实际使用中，与 Doris 团队深入交流后，确定采用 Collocate group 能够满足具体场景。通过这一功能，只需标记一个唯一的 key，Doris 便会在内部自动处理这个 key，并将其相关的数据写入特定的机器。

观察优化前后的对比，可以清晰地看到优化方案在层级结构上有了显著的简化。原本涉及复杂网络交换的 scan 算子、aggregation 算子和 data stream sink exchange 等组件，在优化后都得到了精简。在右侧的优化方案中，所有的计算任务都在本机完成，包括从 0 到 100 万、再到从 100 万到 200 万的数据处理。直到最终 hash join 阶段（即七号节点），才出现 data stream sink 和 exchange 算子，用于合并不同机器上的计算结果。

通过这一优化，成功消除了中间 shuffle 节点的网络开销，从而极大地提高了计算效率。优化后的结果令人瞩目，预估任务能够在 1 秒内完成。这是因为每台机器只需计算局部的 bitmap count，并将这些 count 以 int64 的形式 shuffle 到最终节点进行汇总。与原先需要将整个 bitmap 进行 shuffle 和合并的方式相比，这种优化方法极大地加快了计算速度。Collocate group 和相应的优化策略成功解决了面临的计算效率问题，能够在短时间内完成复杂的计算任务。

在优化过程中也尝试了算子合并。这一步骤是并行进行的，因为当时还发现了一个计算效率的问题。具体来说，当想要查询某个特定标签的情况时，例如涉及 bitmap 和 bitmap node 的 bitmap count 操作，通常这个过程会分为三个阶段：首先将数据传递给第一个函数，然后存储中间结果，接着将数据传递给第二个函数，再次存储中间结果，最后传递给第三个函数并输出结果。这种频繁的数据进出和中间存储过程无疑增加了时间上的损耗。

因此，通过与 Doris 团队紧密合作，共同探索了解决方案。最终，我们采用了一种类似于“bitmap and not count”的算子。这种算子只需一次数据输入，所有的计算都在其内部完成，然后直接输出结果。这一优化显著减少了数据进出和中间存储的步骤，从而在一定程度上提高了查询速度。虽然这种优化带来的速度提升有限，但仍然是一个有意义的进步，尤其是在针对特定查询的优化上。

以上就是查询优化方面的工作。

2. 难点二：写不动

离线特征部分数据量比较大，每天一次更新，常遇到写不动的问题，写的过程中 CPU 打满，导致在线业务出现抖动。

从架构图来看，左侧部分涉及通过 Spark 进行离线写入。早期，数据首先通过Spark 计算后写入 Hive，并生成文件，随后这些文件再通过 Broker 进行加载。而右侧的 Flink 逻辑则保持不变。

具体到如上图所示的场景，从早上 10:35 开始写入，直到实际完成的 18:00，整个过程耗时超过八个小时。在实际业务中，这样的写入时间延迟意味着我们的离线标签从 t-1 变为了 t-2，这无疑对时效性产生了影响。然而，更关键的问题在于，这段时间恰好是在线业务的高峰期。我们发现，每当进行这样的离线数据加载时，在线集群就会出现抖动，进而影响到在线业务的稳定运行，并引发了一系列客户投诉。

为了解决这个问题，我们深入分析了整个导入过程。最初认为导入应该是一个 I/O 操作，但经过与相关团队的深入讨论和大量资料研究后发现，这实际上是一个CPU 密集型操作，尤其是在使用 bitmap 倒排索引后，CPU 负载显著增加。具体来说，一个 Broker load 任务会经历分桶、数据传输、排序、聚合和压缩等多个阶段，而在 bitmap 处理过程中，CPU 占用率特别高。由于这种大量的 CPU 消耗，导致在线集群资源紧张，从而引发了各种性能抖动问题。

在深入研究这个问题时，发现了 Spark Load 这一解决方案，它巧妙地解决了在线CPU 资源紧张的问题。通过将原本在线集群上的 CPU 计算任务转移到 Spark 集群上执行，Spark Load 有效地减轻了在线集群的负担。原因在于整体调度安排，前置数据调度通常在早上六点结束，而实际业务使用则通常在九点之后开始。这意味着在早上六点到九点之间，YARN 集群存在长达三个小时的空闲时段。

在这一空档期，可以充分利用 YARN 集群的空闲资源，执行大规模的 Spark 调度任务，而不会对在线业务产生任何影响。这不仅避免了资源浪费，还提高了资源利用效率。因此，将所有的离线计算逻辑都安排在这个时间段内执行。这类似于早期使用HBase 时直接通过 Spark 写入 HFile 的逻辑，让 Spark 直接生成所需的数据文件，最后再推送到目标系统中。

Doris 的 Spark Load 在执行过程中，与企业版 Spark 作业环境的对接、以及对公司内部各种集群的兼容性等问题，成为了面临的主要痛点。通过不断尝试、调试和解决问题，我们逐步克服了这些障碍。为了方便大家参考和借鉴，上图中列出了我们遇到的问题以及相应的解决方法。

经过解决这些挑战后，来看 Spark Load 的实际效果。在最终测试中，对于 1100 亿行数据的处理，Spark Load 仅用了 35 分钟。在这 35 分钟内，观察到 Doris 集群的性能没有受到任何影响，既无 CPU 压力，也无 I/O 瓶颈，因为它处于等待状态，直到 Spark Load 任务完成。

而在大约二十分钟内，Doris 的 ETL 过程就能将处理好的数据写入到 Doris 中。这一步骤主要涉及到将文件传输到 Doris 本地，因此只有 I/O 操作，几乎不占用 CPU 资源。随后将这一方案部署到线上环境，安排在早上六点进行。由于此时是用户使用的低峰期，I/O 操作对在线业务几乎没有影响。直到早上九点之后，随着业务使用量的逐渐增加，我们的系统依然能够保持高效稳定的运行。

这一方案成功地解决了两个问题：首先，通过将离线标签的延迟从 t-2 缩短到 t-1，提高了数据的时效性；其次，通过将 CPU 密集型任务转移到 Spark 集群上执行，减轻了 Doris 集群的压力，从而避免了影响在线业务的问题。

3. 难点三：在线接口流量大

上线一段时间之后，查用户是否在某个包里面的接口流量 QPS 增大非常多。

假设计划投放 40 个广告时，每个广告都针对特定的目标人群包。当用户在浏览信息流页面时，系统会使用用户的 member ID 去查询该用户是否存在于这 40 个目标人群包中。如果存在，就会拉取这些广告的元数据，进行相关的得分排序，并将排名最高的广告展示给用户。这是信息流广告投放的核心逻辑。对于信息流中的强制插入和扶持逻辑，也采用了类似的策略。关键在于判断用户是否属于特定的人群包，这些人群包与投放任务一一对应，再进行二次排名，返回最终结果。

在实现这一逻辑时，考虑了方案一和方案二。最终，由于方案二在处理大量人群包时同步到 Redis 的成本过高，因此选择了方案一。在方案一中，对缓存和容器内存进行了优化，确保它们主要用于存储 bitmap 对象。当用户请求到达容器节点时，系统会迅速判断该用户的 ID 是否存在于相应的 bitmap 中，从而快速返回结果，避免了不必要的回源和后续处理流程。

在业务持续扩张的过程中，原本预计，当需要判断一个 member ID 是否存在于四五百个目标人群包中时，已经是业务的极限情况了。然而，随着业务量的不断增长，需要处理的是成员是否属于一千多个目标人群包的情况。

为了应对这一挑战，核心优化在容器的内存使用上。传统的缓存方式是将 bitmap 以二进制形式存储，每次使用 bitmap 时都需要进行序列化和反序列化操作，这带来了不小的性能开销。为了优化这一过程，采取了创新的策略：缓存整个 bitmap 对象，并通过技术手段让垃圾回收机制（GC）绕开这些对象。这样，每次判断member ID 是否存在于某个 bitmap 中时，只需直接操作这个对象，而无需进行序列化和反序列化操作。

为了实现这一优化，进行了两项关键的重写工作。首先，重新设计了 message pack 的 on marshall 处理逻辑，以更有效地处理 bitmap 对象的缓存和读取。其次，对 local cache 进行了重写，以支持这种新的缓存策略。经过这些优化和重写后，之前遇到的性能问题得到了有效解决，显著提升了系统的处理能力和响应速度。

改造之后，原本需要 20 毫秒的查询（P95 响应时间）直接降低了一半至 16.69 毫秒。接下来，又进行了第二个关键的改造。

考虑到 GC（垃圾回收）机制会定期清理内存中序列化后的对象，以防止大 GC 问题的出现。然而，在本场景中，只有在换包时才会出现大量的清理操作。

因此，重写了底层代码，绕过 bitmap 从内存中读取并清理的逻辑，让数据保持在内存中不被清理。通过这一改造，实现了从传统处理逻辑到新策略的转变，直接缓存了 bitmap 对象。这样做之后，“read from”的操作基本上消失了。同时，并行处理了其他常规逻辑，并进行了统一优化。

最终，实现了在单次请求中判断一个人是否存在于 3000+ 目标人群包的功能。与之前相比，这不仅是规模上的巨大提升（从原先的 600 个包增加到 3000 个包），而且 P95 响应时间也显著降低，降至 4 至 11 毫秒。这一性能提升是非常显著的，同时也极大地降低了换包的频率。

虽然 3000QPS（每秒查询率）的调用量看似不大，但在这里，每次请求都需要判断一个人是否存在于 3000 多个包中，相当于进行了大量计算。因此，对于底层系统来说，这种压力是非常大的。正是通过上述的各种优化措施，才成功解决了这一问题。

现在，当单机容器内存较高时，只需处理 3000 个包就能满足很长一段时间的业务需求。

针对后续人群规模可能进一步增大的情况，提出了一项前瞻性的技术方案。虽然这一方案目前尚未正式实施，但已经经过验证，证明其可行性和有效性。

该方案的核心思想是分而治之，它与之前讨论的策略逻辑上是一致的。具体而言，设想将人群包分散到不同的处理单元（unit）中，每个单元能够处理大约 3000 个包。通过在代理层（proxy）进行聚合，能够同时处理高达 9000 个包，可以显著提升系统的整体承载能力。然而，要实现这一方案，分流逻辑至关重要。必须确保数据在分发过程中尽可能保持均衡，避免出现倾斜现象。因为一旦某个节点承受了超过其处理能力的数据包（例如超过 3000 个包），该节点就可能无法再处理更多的请求，从而导致整个系统的性能下降。因此，在实施这一方案时，需要精心设计分流策略，确保数据能够在各个处理单元之间均匀分布，从而充分发挥系统的整体性能优势。

04

未来展望

展望未来，有如下一些重要方向值得期待。

1. Doris+ES->Doris2.0

目前，同时使用了 Elasticsearch（ES）进行文本处理，并结合 Doris 和 ES 进行 join 操作以实现人群包的圈选。值得一提的是，随着 Doris 2.0 的发布，它提供了倒排索引的功能，这将提供一个绝佳的机会来迁移并优化现有的解决方案。通过利用 Doris 2.0 的倒排索引，可以更加高效地进行人群包的圈选，从而进一步提升系统的性能和效率。

2. 结合大模型

第二个方向是与大模型的结合。

第一个场景是利用大模型生成人群条件。比如通过输入一段文字，模型能直接生成相应的人群包圈选条件，一键确认即可完成人群筛选。然而，在与销售和广告优化师沟通时，这种自动生成的圈选条件并未完全满足他们的需求。他们渴望的是精准定位到如“母婴产品高转化用户”这样的特定目标群体。为了实现这一目标，可能需要补充大量的训练数据和微调条件，使模型能够学会识别并圈选出这些特定人群。

此外，大模型在实际应用中存在的“幻觉问题”也是一个痛点。由于人群包圈选直接关系到最终的资金消耗，一旦模型圈选错误，将带来极大的风险。我们期望的是，大模型在不确定时能够坦诚地表达其不确定性，而不是自信地给出错误的结果。目前，大模型的自信错误输出是面临的一大挑战，因为难以验证其准确性。这也是未来技术有望解决的关键问题。一旦解决，大模型在人群包圈选等领域将具有巨大的应用潜力和价值。

第二个场景聚焦于运营自动化的全面实现。目前运营过程中仍存在多个关键节点，如投放策略和人群圈选，这些操作很大程度上依赖于人工进行。尽管我们已经通过流程编排的方式，尝试实现一定程度的自动化，如先执行某个任务，随后进行人群圈选，但这种模式仍然缺乏足够的灵活性。OpenAI 的 Assistant API 和之前的 Auto GPT 技术都指明了一个潜在的方向，即利用大模型来编排这些运营流程。在这种模式下，大模型可以像编排师一样，基于功能调用（function calls）或原子算子（operators）来自动构建和执行复杂的运营任务。如果老板要求大模型为母婴人群制定一套完整的投放方案，包括投放计划和其他相关配置，大模型能够迅速、准确地完成这些任务，这将极大地提高工作效率。然而，目前我们在这方面的实践效果尚未达到理想状态，但随着技术的不断进步，我们期待能够逐步实现这一愿景。

以上就是本次分享的内容，谢谢大家。


分享嘉宾

INTRODUCTION


侯容

知乎

舰桥平台研发 Leader

知乎舰桥平台研发 Leader，知乎舰桥平台是：面向内容运营、用户运营、活动运营、创作者运营、场景运营（热点&热榜&话题&推送等）、生态分析等业务场景搭建的一站式平台。其中包含内容&用户管理和运营平台、内部营销平台（活动引擎&搭建&分析&投放平台）、内部投放和资源管理平台、创作者管理平台、DMP 平台、内容池平台、经营分析平台、场景运营平台等等，全方位赋能业务运营和业务发展。

往期推荐


Alluxio：面向 AI 计算的高性能数据访问平台

基于深度学习多实验叠加效果因果推断

Alluxio 在携程大数据平台的探索与优化

GraphGPT: 大语言模型的图结构指令微调

锁定营销敏感人群：因果推断在智能营销中的关键作用

B 站的数据治理运营框架实践「 内有案例分享 」

云器Lakehouse：Multi-Cluster弹性架构如何实现湖上高并发低延迟分析

大模型百度数据科学领域典型应用

ClickHouse 在 58 同城画像系统的应用

华为实时入湖 Hudi 应用解决方案

点个在看你最好看

SPRING HAS ARRIVED


继续滑动看下一个
DataFunSummit
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题？点此查看未经处理的缓存