知乎舰桥平台内部营销平台如何赋能业务增长？（二）

Apache Doris 中文站 2023-12-27

246

本文导读

知乎舰桥平台是一站式内容&用户&创作者管理、运营、分析平台。它集筛选、打包、分析、监控、营销、投放、干预等多种能力，专注于内容运营、内部营销、创作者运营、内容供应链、数据中心和内容分层运营等场景。为市场感知与前瞻预判、内容和创作者生态调节、头部创作者关系维护、营销和促进公司业务发展，知识分享和交流创造无限可能。‍上篇文章介绍了舰桥产品体系的内容运营平台建设实践‍，本篇文章将深入探讨知乎舰桥平台内部营销平台的痛点问题以及基于 Apache Doris 的解决方案与性能优化策略。

作者｜知乎舰桥平台侯容、李宁宁

了解内容营销平台业务场景

这 3 个图分别为营销活动的话题页、落地页和对应的玩法（目前的这个活动是任务积分兑换玩法），与此同时连同宣传页、资源投放和对应的活动监控就形成了完整的内部营销的业务能力，这就是内部营销平台面对的业务场景。

01 内部营销的目的

目前我们接触的内部营销场景，无非是达成以上目标，促进用户增加、促进用户消费、促进内容生产、促进问题生产、促进创作者变现。

促进领域 DAU 增加：这部分通过活动的手段，定向激发用户对领域内容产生阅读消费的兴趣等，从而增加领域 DAU。其中用户来源有两种，一方面是知乎用户对该领域产生兴趣，另一方面可以借助活动让非知乎用户成为知乎用户并对该领域产生兴趣。
促进内容生产（促进创作者增加）：这部分是通过活动的手段，定向激发用户生成优质内容，如回答、短内容等。
促进创作者变现：创作者是内容生态的重要组成部分，支持并激励他们创作并从中盈利，是保持内容生态的活力和吸引力的重要方式。

02 营销和用户&创作者的生命周期的关系

营销是激励过程，通过营销过程会促进如下阶段的循环。具体描述而言就是营销相当于一个发力器，会在各个生命周期的阶段，对用户推一把。在短期促进用户向营销期望的方向产生明显的行为变化，并促进用户扭转。扭转过后，如果对应生命周期的功能能够比较好地承接，用户留存是正向的，用户就完成了该方向的转化和承接。简而言之，营销可以短期改变用户行为到我们期望的目标行为，长期需要看产品力是否能承载和留住用户。具体以下为用户各生命周期，箭头为从可通过营销动作的促进快速转变的方法。

03 内部营销的闭环逻辑

从上述观察，内部营销的本质就是抓住用户生命周期变化的路径，通过刺激、激励、营销等多种，让用户从一个生命周期的阶段，扭转到另一个生命周期的阶段。这样做一方面是通过激励手段快速改变用户行为，另一方面也是借助活动将社区的导向传递出去。与此同时，做活动也能创建一种适合分享的讨论氛围，将外部优质创作者引入参与讨论。最后通过活动定向促产内容，通过内容挖掘新的创作者。

达成以上目标的过程内部营销简化后可以描述为：通过某种触达渠道进行推广，针对目标受众，使用某种激励或营销手段，促使用户或创作者达成某个转换目的。所以触达渠道、目标受众和激励或营销手段就组成了三位一体的内部营销主逻辑。

产品功能概念

01 CDP（客户数据平台）

CDP 是一个集中式的系统，能够收集并分析所有关于客户的数据。这些数据可以来自多个来源。CDP 会对其进一步地处理和存储，生成用于制定营销策略和目标受众的有用信息。

人群圈选：在营销过程中，我们经常需要对特定的人群进行定向投放。人群圈选就是通过对用户数据分析，选出具有特定行为或特性的客户群体。根据不同的营销目标，按照地理位置、流量行为、购买行为、兴趣爱好等多种标准来进行圈选。
人群洞察：在圈选出特定人群后，人群洞察功能可以对这些人群进行深度分析。通过数据挖掘，可以了解这个人群的行为习惯、偏好、阅读兴趣等诸多有价值的信息，为制定有效的营销策略提供支持。

02 活动平台

活动平台是进行营销活动设计和运营的地方。通常会包含活动策划、执行和分析三大步骤。

活动搭建：活动搭建是指定制化设计营销活动的过程。可以根据公司的市场策略和目标客户群体，选择合适的活动形式，如瓜分获得盐粒、完成任务抽大奖、优惠券发放等，并在平台上完成活动设置。
活动玩法：活动玩法是指在活动中增加的吸引人的元素，以提高用户的参与度和活动的影响力。例如，可以设置签到抽奖、签到获奖、答题赢奖品等吸引人的环节。
抽发奖：对于涉及奖励发放的活动，抽发奖能自动抽选、发放、瓜分和兑换奖品。这样不仅能降低手工发放的错误率，提高工作效率，而且还可以增加用户参与活动的积极性。
权益：对于通过活动获取的权益，平台可以清晰地展示并发放给用户，让用户了解自己能享受到的优惠和服务，直接看到获得权益的流水，同时这个系统也会对总体权益发放金额做资金管理。
落地页：落地页是活动的展示页，一般会包含活动的详细信息，如活动规则、活动期限、奖品内容、活动玩法等。落地页的设计直接影响用户对活动的认知和参与积极性。

03 内部投放平台

内部投放平台是将设计好的营销活动推送给用户的平台，包括但不限于资源位投放、信息流内容投放、主动触达等。

资源位投放：资源位投放是以资源位的视角，如创中弹窗、首页金刚位等，针对目标资源位进行定向曝光的投放渠道。
信息流内容投放：信息流内容投放主要是依托于推荐引擎，将内容面向不同的受众通过推荐策略的方式在信息流中展示给用户。
主动触达：主动触达是通过系统发送消息、私信等，直接推送给用户，通常是以推送通知、私信，也包括短信等形式存在，比如促销活动的通知、优惠券的发放消息等。

业务架构

业务架构主要分为四层，分别是业务能力层、共享服务层、业务模型层和外部接入层。

业务能力层：这里是内部营销平台的核心业务能力，主要包括 CDP、活动平台、内部投放平台和内部营销分析&诊断。
共享服务层：这里是为了搭建上面的业务能力，所抽象出来的通用共享服务，避免在技术上和业务上重复造轮子的共享服务。
业务模型层：这里主要是隔绝了接入层和业务层，将外部的各类数据和 RPC 抽象成在内部通用的数据模型，内部开发只理解内部模型，接入层只理解如何将物理原始事实完成接入，提高了平台开发的效率。
外部接入层：这里集成了多种外部接口和协议的接入工具，以及提供低成本快速接入新的业务事实的脚手架，降低接入成本，提高接入效率。

接下来我们分别展示内部投放平台、客户数据平台 CDP、活动平台、舰桥事实共享服务、用户行为系统 UBS 以及内容事件中心 CEC 业务架构图。

左右滑动查看架构图

挑战及难点突破

01 活动平台难点突破

任务达标 -> 获得积分：可靠事件队列 + 幂等 + 最终一致

这种情况使用可靠事件队列发生任务完成下发积分的消息。积分系统监听该消息，配合积分系统和任务系统间唯一 Key 做幂等性保障了 At-Most-Once，再通过无限重试保障了 At-Least-Once。从而保障 Exactly-Once。

积分消耗 -> 获得奖励 -> 奖励到付：TCC

活动平台中存在的几个子系统：任务框架、瓜分框架、抽发刮兑奖模块、用户奖品模块、权益模块。其中最核心的一个工作是，在任务达标后产生的任务完成记录，任务完成后在用户奖品中的获得奖励记录和奖励实际下发到用户这三者全局一致，不多且不少。

针对这一问题我们的解决方案是使用 TCC 模式的分布式事务，TCC 是“Try-Confirm-Cancel”三个单词的缩写，是由数据库专家 Pat Helland 在 2007 年撰写的论文《Life beyond Distributed Transactions: An Apostate’s Opinion》中提出，具体如上。

奖品的库存上限

在整体的奖品和权益下发过程中，存在两个库存，一个是一个活动的奖品有最大上限，另一个是某权益，例如超赞包，有最大上限。为了解决在完成任务和用户兑换过程中的承载能力，我们通过预占提交 + MQ 和定时脚本同步状态的方式来保障高并发下的库存限制，具体如上。

活动总积分下发上限 - 分而治之

分而治之，提前将积分按照号段划分成多块，每次完成任务后，随机进入一个存活号段（如果号段内无积分的话，则认为该号段失活）进行发放，如果有号段存活，完成发放；如果所有号段失活，则返回超发并拒绝。

复杂任务系统的抽象

原子任务

目前活动平台->玩法引擎->任务框架的难点是如何将复杂的任务流程和架构进行适当的抽象，从而方便配置和实现。原子任务的配置，一个原子任务的复杂性主要来自任务自身的灵活性和业务特征增多，会随着业务发展可选项和灵活程度越来越大，涉及的规则的适配性，特征的完备性就觉得了一个任务系统可扩展的上限。在这里我们将任务按照模板类型进行拆分，同时将每个模板的子模板通过可配置的规则引擎来予以解决。

任务编排

另一方面，当原子任务支持后，任务间的依赖关系以及任务的类型和性质差异性，这些都使得任务管理变得富有挑战。这也就需要我们寻找一种方法来抽象这些复杂性，使得在面对大量的具体任务时，我们可以有一个整体、宏观的角度去理解和控制这些任务。

对此，我们如上图，将不同模板类型的任务进行抽象。我们必须抽离出任务的共性元素，例如任务的分类、优先级、依赖关系，从而建立一个易于理解和操作的抽象结构。同时这种抽象结构需要能够灵活地适应新的任务类型和状况，以便于我们更好地应对未来可能出现的挑战。

通过实施这样的抽象化策略，我们能够更好地理解和掌控复杂的任务系统，并针对其共性的部分做到可扩展的、通用的涉及。同时降低了新人理解和上手整个系统，提升工作效率。

02 内部投放平台难点突破

投放渠道多

如上图的部分渠道所示，在进行内部投放过程中，所面临的一个特别复杂和棘手的问题，那就是投放的触达点散布在 APP、PC 的各个位置，同时不同资源负责人也不同，因此不可避免地在进行投放过程中，需要与各个业务线进行深入的沟通，这无疑会提高投放的成本和难度。

针对这个问题，舰桥构建了一个统一的投放中心，涵盖了所有触达点。同时借此过程，逐渐收拢和统一了一体化的审批流程，使用方可以通过系统轻松地协调各部门，快速有效地完成内部各个触达点的投放工作。进而降低了运营投放的成本，无需再花费过多的时间和精力与各个业务线持续沟通协调。有了舰桥的助力，运营团队可以把更多的专注力放在优化投放效果上，而非过程中的沟通协调，大大提高了工作效率和效益。

用户定向难

在执行具体内容投放时，寻找和匹配目标用户是一个复杂的过程。在这个过程中我们的目标是：

更多的人能看到；
看到后点击、阅读等转化高。

目前我们积累了 3 种方法：

运营人工圈人群包定向；
策略自动圈人群包定向，舰桥提供的策略，根据内容属性找到用户兴趣，快速地生成对应的人群包并进行投放。
算法内容找人定向，由推荐团队需要细致地对内容信息和用户画像进行深入分析，并完成合理匹配策略和匹配过程。

通过上述的 2 和 3 的方式，我们将 1 方法的手动匹配圈包的工作减轻，极大地缩短了每一次内容投放的时间。同时将节省出来的时间来专注于优化业务效果，并将投放效果的 Case 反馈给推荐策略，进一步提高投放效果，对工作效率带来了显著的提升。

任务链路长&状态密集

如上图所示，在内部投放平台的建设中一项复杂和具挑战性的问题就是任务链路很长和任务的状态密集型。投放的过程中，整个链路线路径需要经历多个关键步骤，包括任务的创建、目标群体的生成、投放任务的提交、任务状态的更新、投放数据的更新等等。这些步骤不仅需要在不同状态间的细致的操作和状态的扭转，还要伴随着各种子节点的降级和重试策略。

简单来说就是，当任务在链路中传递时，需要处理大量的状态转换，并且需要有可靠的方法来处理可能的失败情况。如此迂回复杂的过程，客观上加大了任务的调度难度。我们依靠舰桥提供的一整套完整任务链路，底层基于 Workflow 框架来处理这个问题。这不仅优化了工作流程，更重要的是确保了任务在传输中的可靠性，为高质量的任务完成提供了可能。

资源管理

在投放过程中进行有效的资源管理，一方面提升资源投放的转换效果，另一方面也能控制资源使用，以防止资源的过度使用或滥用。如何通过一种机制来保证资源的合理分配，也是这一业务建设的难题。

针对此问题，我们运用舰桥建立的一套虚拟组作为唯一标志。在这套机制中，我们提供了针对不同虚拟组赋予各个不同的资源量的能力，并由资源负责人和资源申请人拉齐资源配比。同时，我们还引入了成本和效果分析，并辅以奖惩机制，仅将资源分配给那些能够有效使用它的团队，确保资源得到最有效的利用。

这套策略不仅使资源的使用变得更为高效，还通过奖惩机制对利用效率的监控，使得价值观正确，更加符合公司需要的内容得以被分发。我们会定期分析资源使用的实际效果，以此作为评估和调整我们的资源分配策略，进而促进资源的有效利用和优化。

借助这套机制，解决资源配置的问题，以便我们可以专注于优化投放效果，消除资源滥用的可能性，使得我们的资源得到最有效的利用。

03 CDP（客户数据平台）查询性能调优

当前 CDP 系统中有两大功能，第一大功能是人群定向，另外一大功能是人群洞察，这两部分的功能是基于 Apache Doris 构建的。基于这两大功能会有一个底层的功能是建设各种用户方面的画像特征。当我们完成拆解之后，我们就会发现人群定向的这部分功能是运营侧或业务侧的痛点。

人群预估，针对投放和营销场景，运营侧会有人数预期，那么会构建相应规模的购物车，持续在购物车中加入新的特征，需要立即看到新的特征加入之后会圈选出多少人，而不是每次加入新的特征后都需要很长时间的等待。
人群圈选，针对热点运营。运营侧在日常工作中会持续跟进发生的各种热点事件，当发生了某些热点事件后，要快速地圈选出人群包发布 Push 和推荐。如果圈选过程需要好几分钟，就会错过热点事件。

以上场景场景数据量极大，如上图标注。同时对查询响应时效要求非常高，人群预估期望在 1s 内响应，人群圈选期望在 1 分钟内响应。

性能优化（1）

第一阶段优化我们通过了以下几点来解决这两个问题：

倒排索引和按条件查询

首先，倒排索引方面，我们将查询条件由原先的 and or not 改成了 Bitmap 函数的交并差；同时我们把连续数值打散成为离散标签。举例：用户的年龄是大于 0，小于 100 的 int 型，如果按照数字顺序进行筛选，运营侧是不好把控的，圈选的过程中也会导致使用效果不理想。因此我们把按照顺序排列的年龄打上另外的标签，称为年龄段，比如 18-25，0-18 等。

接着，把原先的 and or not 的查询转换为了倒排索引的相关查询，原先建立的表就会变成按照 tag_group 、tag_value_id 、置信区间的标识、Bitmap 的顺序排序。同时基于这部分我们也需要进行 ID Mapping，ID Mapping 在导入的过程中的核心就是要把用户 ID 变成连续自增的。

查询逻辑变更

原先的查询条件是 where 条件中的 and、or、not，现在经过复杂的手段，把原先的查询条件修改成bitmap_and
，bitmap_or，bitmap_not
，我们通过业务代码，将外部运营通过可视化后台配置的 and、or、not 的逻辑全部改为函数式的逻辑，相当于把 where 条件放到了函数和聚合逻辑之中。

但经过优化之后还会存在 2 个问题：

第一个问题是单一的 Bitmap 过大，第二个问题是 Bitmap 的空间分散。这两个问题集中导致每次进行交并差聚合时网络 IO 特别高。

底层 Doris 中用的是 bRPC。在数据交换的过程中，因为每一个单一的 Bitmap 都很大，就会导致 bRPC 传输拥堵，有时甚至会出现上百兆的 Bitmap 进行交换的情况。上百兆的 Bitmap 进行交并差计算时性能很低，基本上我们想要达它达到 1 分钟圈选人群，1 秒钟进行人群预估是不可能的。

性能优化（2）

基于仍存在的问题，我们进行了第二阶段的优化。

分而治之

第二阶段的核心的思路是分治。当我们进行了第一波上线后，发现人群预估能力是分钟级别，圈选基本上要到 10 分钟开外了。分治的思路是将全站的用户全部打成连续自增 ID 后，按照某个程度进行分组。比如说 0-100 万是一组，100 万 -200 万是一组...逐渐分为几个组别。全站用户的交并差，可以等价于分组之后的交并差结果之和。

数据预置

当我们发现这个规律之后，通过分而治之可以做相关的数据预置。利用 Doris 中 Colocate Group 特性，把每个分组内 100 万人全部放到某一台物理机上，避免网络的开销。

算子优化

全部放到某一个物理机上之后，就可以把聚合的算子由原先 bitmap_and_not 的 bitmap not 和 bitmap count 替换成一个函数来实现。此时基于 Doris 团队的新版本，增加了类似 bitmap_and_not_count 的组合函数后，性能相对于原先的嵌套函数有了比较明显的优化。

04 舰桥共享事实服务离线事实导入性能提升 9 倍

在应对标签数据的更新时，主要分为离线和实时两条链路的更新：

离线批量更新：数据源 -> Spark -> Broker Load -> Doris。
实时流式更新：数据源 -> Flink -> Routine Load -> Doris。

其中离线批量更新的数据量较大，每天 1100+ 亿条，更新时间为 8+ 小时。随着业务的发展，离线批量更新的数据量不断增加，更新时间也在不断延长，导致每天下午离线批量画像才更新，影响运营投放，用户体验不佳。从而进行解决。

原始数据存储在 Hive 表中，用 Doris 来做实时数据分析工具， Doris 本身支持 Hive 外表，但性能存在瓶颈，为了提升 Doris 分析性能，初期的方案是定期把 Hive 表的数据，通过 Broker Load 把数据从 HDFS 导入到 Doris 中，过程如图：

这个方案开始运行还算平稳，后期随着数据量的增加和导入任务数变多，问题逐渐出现。直接表现就是：

查询变慢：很多业务的查询对延迟敏感，影响使用体验。
导入变慢：很多耗时在小时级别，时效性满足不了业务的要求。

观察监控可以发现：导入任务运行时 CPU 下降的比较明显，同时磁盘 I/O 保持在低水平（ SSD 盘），说明在导入时 CPU 算力是个瓶颈，因为导入时需要排序、解压缩、分桶计算，这些都是 CPU 密集型的操作。同时 Yarn 集群算力存在潮汐现象，空闲可以成长导入过程的计算卸载到 Spark 上，充分发挥各自的优势。

上面关键问题解决后跑了一个全量的任务，数据 1.2 TB，数据行数：1100 亿+，再看下整体耗时缩短至 55 分钟，相比之前 Broker Load 需要 8 小时，整体导入性能提升 9 倍以上，数据导入的时效性问题得到解决，同时降低了集群的负载。

05 CDP 圈人&活动分析&投放诊断场景，极限压榨集群性能 -全局向量化

使用场景

CDP（客户数据平台）人群定向。筛选、圈选、打包场景：

OLAP 引擎 Bitmap 倒排表，通过交并差，快速预估并完成筛选、打包能力。

活动监控、营销监控、投放诊断。分析&诊断场景：

维度&指标汇总宽表：较短时间多数据分析看板，或最新日期聚合数据看板。
多日期指标窄表：较长时间（一年）指标变化趋势图。

效果分析、成本监控。追踪、分析、报警场景：

追踪明细表：每一时刻的数据明细，用于浏览和异常异动报警计算使用。
多日期指标宽表：追踪时间内的细粒度数据趋势波动，同时可用于异常波动报警。

集群配置

集群	配置
旧集群（未开向量化 1.0.0 ）	3FE+32BE 内存 256G；CPU 64 核；磁盘：32*4T HDD
新集群（向量化 1.1.2 版本）	3FE+19BE 内存 256G；CPU 64 核；磁盘：19*4T HDD

两个除 BE 个数外其他配置均保持一致

核心场景查询耗时对比

根据以上线上真实结果所示，Doris 1.1.2 版本相比 Doris 1.0.0 版本性能提升显著，对于大部分场景有 2 倍以上提升，少部分查询有近 14 倍的性能提升，效果好于预期。

调优实践

FE 下发 Fragment 超时问题

send fragment timeout. backend id: xx, host: x.x.x.x

向量化版本上线后，Frgment Timeout 超时报错显著增加，报错发生时间段具有高 QPS 或者数据导入较频繁，排查发现，查询计划的两阶段执行机制中存在 Bug，如果执行计划被 FE 取消，BE 上已经完成 Fragment 准备工作并休眠等待的线程就不会被唤醒，导致 BE 上的 Fragment 线程池被耗尽，后续所有查询任务的 Fragment 下发到 BE 节点之后，因为没有线程资源都会等待直到 RPC 超时，社区已对该 Bug 进行修了修复，同时我们还调大了 bRPC Worker 线程池的大小，默认 bRPC 初始化 Pthread 线程数等于 CPU 核数，我们线上机器 CPU 配置是 64 核，初始化线程数 64 个，后面我们调整到了 128 个后，效果显著。

支持返回二进制 Bitmap 数据

圈人成功后，结果存储在 Bitmap 中，业务侧需要判断某个 UID 是否在 Bitmap 中的，这个场景特点是高 QPS，如果在 Doris 中处理，会对 Doris 增加较大压力，影响服务，所以这个判断逻辑由上层来处理，需要 Doris 返回二进制的 Bitmap 数据，上层缓存 Bitmap，在线的 QPS 直接访问缓存，然后根据 Doris 提供的文档，直接解析二进制 Bitmap，不再走 Doris。所以需要在向量化版本支持返回二进制内容能力，目前相关 PR 已合入社区

GitHub 链接：

https://github.com/apache/doris/pull/15224

https://github.com/apache/doris/pull/15273

未来展望

内部营销平台发展的大方向是：营销数字化 -> 营销自动化（MA）-> 营销智能化。

01 内部营销全面数字化

我们现阶段正积极地发展和完善我们的系统以及系统的业务数据，包括详细深入的分析活动效果、营销效果和相关成本等。在完善过程中，我们也发现日常活动建设过程中可能存在的具有挑战性的问题，例如活动样式的确定，文案的撰写，营销权益的分配等方面，都需要精确的归因和量化。

为应对这些问题，我们采用了 AB 实验这一数据驱动的归因工具。举例来说，如果我们在两种 UI 设计之间无法抉择，那么我们便可以通过 AB 实验来确定到底是设计 A 更优秀，还是设计 B 更出色。

为了实现此目标，我们计划将 AB 实验功能整合到了我们的内部营销平台的活动平台和内部投放平台中，从而增强了我们的活动页、文案等的 AB 测试能力。这一集成不仅将提升我们的系统效能、为我们提供科学的决策依据，而且将为我们未来的目标定制化营销方案提供强大的支持和保障。

02 内部营销自动化

在营销之父科特勒 2022 的演讲：剧变时代，好营销的 27 条准则中，其中第一条就是：未来的营销会越来越自动化，人工智能也会更多地参与到市场营销之中。但最好的营销方式仍然是人与人之间的沟通，我仍会用 H2H（Human to Human）来表达这一概念。人与人之间的表达才是最关键的，无论是与物流、消费者、生产者或分销商沟通。他强调了营销自动化和人工智能在未来营销中的重要地位，但我们明白，即使在高度自动化的背景下，H2H（Human to Human）也是不可忽视的。舰桥平台一直以来的策略是将高科技融入人际互动中的。

在内部营销平台中，我们已经将一系列的流程和任务抽象成标准化的节点。在未来我们计划将这些节点编排形成自动化的流程和任务。同时根据对应流程的数据反馈，按照运营同学配置的策略，自动的执行促产活动、流式召回等内部营销任务，这些自动化的策略降低了运营办理营销活动的成本，无须再花费过多的时间和精力对各个节点进行操作。有了舰桥的助力，运营团队可以把更多的专注力放在活动效果上，而非过程中，大大提高了工作效率和效益。

- END-

文章转载自Apache Doris 中文站，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。