共计 15268 个字符，预计需要花费 39 分钟才能阅读完成。
导读：知乎基于业务需要搭建了 DMP 平台，本文具体的介绍了 DMP 的工作原理及架构演进过程，同时介绍了 Apache Doris 在 DMP 平台的利用实际，本文对大家理解 DMP 工作形式很有帮忙，欢送浏览。
作者 | 用户了解 & 数据赋能研发 Leader 侯容
DMP 业务背景
DMP 平台是大家陈词滥调的话题。在晚期广告零碎呈现之后就领有了相似的 DMP 平台，比方：腾讯的广点通、阿里巴巴的达摩盘等都是业界做的比拟好的 DMP 平台典型。而知乎搭建属于本人的 DMP 平台，一方面是因为知乎有相干的站内经营业务；另一方面也是因为咱们能够通过搭建 DMP 平台反对外部零碎对接、同时还能够帮助实现相干业务倒退以及定制化需要建设的目标。
DMP 业务蕴含：业务模式、业务场景以及业务需要。
图 1.1 DMP 业务
DMP 平台设计的方向：为了找到咱们的外围客户，并在后续对咱们的外围客户实现如广告投放等营销操作，让外围客户跟咱们的内容之间可能有更好的匹配。
业务模式
DMP 平台业务模式
- 从站外转站内。典型场景是广告主在进行广告投放的过程中，如何通过 Mapping 将可能呈现的站外人群转到站内，并在站内的零碎上承接这些用户包。
- 从站内转站外。 在知乎内先找到定向用户后再去用这些用户在三方投广告。
- 站内经营。 包含内容经营，用户经营以及流动经营。一方面能够减少知乎相干内容的宣传，另一方面进行客户定位并精准解决某些客户的问题与需要。与此同时，咱们也能够通过流动设计来晋升业务成果。
业务场景
基于这三种业务模式，次要利用的业务场景：
- 信息流方面。 拿举荐场景举例：举荐场景中会有定向举荐以及定向提权两种诉求。定向举荐是咱们把推送内容定向推送给某些用户，而定向提权是咱们把推送内容在被推送的用户身上实现提权并从新打分。
- 广告侧实时竞价。 得悉该用户身上挂了哪些广告之后能够进行实时竞价，通过排序选出最适宜该用户的广告。
- 详情页。 详情页中会有弹窗提醒：比如说某个用户点击某个详情之后，若该用户没有达到目标条件，会弹窗疏导来该用户达到条件。
- 流动平台。 设置流动的指标用户。针对不一样的目标群体，展现不同的流动信息。
- 触达零碎。 比方在推送音讯、弹窗和短信时，能够拿到一类具体的用户，之后向该类用户进行公布相应的 Push 和站内信等。
- 站外投放。 找到适合的用户群并在站外为其投放相应的广告。
业务需要
基于业务模式场景，在人群方面能做的事件能够分为三类：
对接零碎
个别分为以下 3 种状况：
- 该用户命中了哪些人群包。拿广告零碎为例，该人群包 ID 能够 Mapping 成一个广告，也就是该用户命中了哪些广告。
- 外部人群包。人群包对外部而言就是把内容举荐给谁，或者给谁公布内容的 Push。
- 对外部的广告。当咱们筛选出一类用户须要投放在站外时，这时候就是在应用对外部的人群包。对于这两个人群包之间的区别而言，人群 ID 会有不同：一种是站内的通用 ID，另外一种是基于不同投放平台上对应的对外 ID。
人群定向
人群定向包含导入 / 导出、基于某些特色进行标签圈选、人群泛化、用户量预估等。
- 人群泛化，拿到比拟小的种子人群包后，基于规定寻找类似特色，再通过对类似特色的置信度进行调整，扩大更多的人群。
- 用户量预估，选中一批用户后须要立刻理解这批用户的数量有多少。
人群洞察
包含画像洞察，用户的外部画像以及两个不同人群包之间的比照剖析。
业务流程
因为以后 DMP 业务的三种场景面向人群不同，会提供向站内与站外不同零碎来实现这批人群相干的经营动作。
据此状况，咱们组织人群定向性能、获取到指标用户之后进行 Mapping，拿到用户在站内或站外投放的成果回收之后，获取指标用户进行形成剖析与比照剖析，进行用户洞察。若指标达成，那么本次投放顺利达成；若指标未达成，经营侧会做相干假如：是否能够再加一个特色或非凡操作进一步晋升业务？提出假如之后，设计 AB 试验，通过 AB 试验后，咱们又会对指标人群进行一些调整。以上就是咱们的经营流程。
图 1.2 DMP 业务流程
站内经营自闭环
人群定向。 通过标签圈选，抉择历史上有流动成果或导入喜爱此流动的人群，进行泛化实现根底人群包抉择，以此来确定指标人群。
进行投放。 因为很多业务在举荐侧的信息流、触达零碎、详情零碎以及广告引擎等零碎中进行对接，能够利用以上零碎和业务来实现对指标用户在站内不同流量场景投放。
投放之后。 获取本次投放的成果并进行剖析。比方咱们做的操作是发 Push，谁点击了 Push、浏览工夫等行为，能够剖析有哪些用户更喜爱咱们此次公布的 Push，从而取得指标用户的典型特色。
若此次 Push 的点击量达成推送指标，那么指标实现；若点击量没有达成指标，咱们会进行一个假如，比方最后预测点击 Push 的男性>女性，但最初得出的后果相同时，咱们会通过 TGI 算法进行排序，找出这两次差异的典型特色，实现设计并产出 AB 试验。
通过 AB 试验咱们能够对前后的人群包再做一次比照并公布相干的 Push。如果点击量有所晋升，咱们在后续过程中就会一直的实现循环，最终找到基于咱们经营场景的畛域的精准用户。
站外向站外投放
基于曾经积攒的用户特色数据，找出在知乎外部有几率产生站外成果的人群，并划出该类人群的范畴。再通过 Mapping，能够把站内的 ID 转换成在三方投放平台上产出的 ID 并进行投放。
因为这个过程咱们的站内零碎不同，并不能间接拿到相应的埋点数据供咱们进行数据链路建设，所以就必须要通过三方投放平台上下载相应的埋点数据，通过相似的场景实现数据导入后再进行后续流程的建设。这也就导致了整个过程的成果回收会比拟长。
站外转站内
如果我是一名知乎站外的广告主，我要投放一个牙膏类的产品，然而我对知乎的用户并不是特地理解。通过后期所做的经营调研，能够发现历史购买牙膏的人群包是什么样子。那么就能够把后期调研所失去的人群包通过 ID Mapping 转换为知乎 ID 并导入生成指标人群。然而广告主拿到购买牙膏的人群可能存在与知乎用户重合度较低的状况。这时候启用第二个性能，也就是人群泛化性能。
人群泛化会把导入人数较少的种子人群连贯到知乎，这个过程能够对用户达成的所有特色在 AI 模型中实现训练。能够训练出种子人群在知乎所有用户特色下的模型是什么，之后再把所有用户的全副特色灌入失去的模型之中进行推理。这样失去带有置信度的指标用户。
若广告主认为基于之前的调研后果来看，相干指标人群在知乎中为 1,000 万左右，此时咱们就能够抉择对于指标用户的置信度。比如说当置信度为 0.7 时，失去后果为 2,000 万；之后咱们把置信度调整为 0.8 时，失去后果为 1,000 万，此时咱们就能够抉择 0.8 的置信度实现广告引擎的对接并进行投放后剖析成果。
基于上述经营流程，咱们能够形象出 DMP 平台最外围的性能包含洞察、定向以及 ID mapping。
画像特色
图 1.3 DMP 画像特色
咱们根据上述的用户画像，构建出了画像特色。其中标签是最重要的局部，也是离散局部。间断局部包含了用户的停留时长以及相干的用户行为，比方：某人在某地做了什么事等，这些都属于间断特色。特色方面，在该特色还没有打上标签之前，咱们会统称为一般特色。
性能梳理
图 1.4 DMP 性能梳理
基于 DMP 平台的性能，向右侧拓展为业务性能。业务性能会服务于经营、销售或站内的利用零碎，包含人群定向、人群洞察以及相干的 ID Mapping。向左侧拓展是信息量微小且非常重要的特色接入局部。
以后 DMP 平台因为单从标签方面就有 250 万的标签量级，在用户 X 标签也有 1100 亿相干用户数据，同时业务方面对局部标签具备实时性要求。这也就导致在特色接入过程中须要做很多事件。
接下来将为大家介绍具体性能。
- 人群定向。 人群定向方面整体上分为导入与导出、特色圈选以及人群泛化这三个性能。
- 人群洞察。 包含形成剖析和比照剖析两种性能。形成剖析局部咱们能够简略了解为一个饼图或柱状图。比照剖析是多个人群比照剖析。
- ID Mapping。 整体上将无论是 oai、idfa、手机号，全副硬生成知乎的间断对立 ID，而且这个间断 ID 根本是严格自增的。
- 特色接入
-
- 建设形式分为实时特色及离线特色
- 标签组方面有离线和实时两种接入形式。其中树状标签次要用来应答简单场景，如用户对某话题在浏览和互动方面的是多选的树形构造。
DMP 架构与实现
图 2.1 DMP 业务架构
我认为架构对于实现最终目标是很重要的阶段，但并不是必要阶段。只有咱们把所有性能都进行欠缺就能够实现咱们所有的业务实际，然而这样会导致在零碎通过一直收缩后，所对应的保护老本也会一直变高，稳定性变差，最初导致没有人能够保护的困顿状况产生。架构次要能够为咱们解决在多个简单业务性能场景下，如何以低成本的形式进行保护迭代并有指标的去针对某个模块进行优化，但并不能解决理论的业务性能问题。
基于以上我对架构的认知，对业务以及整体 DMP 架构进行拆解：
DMP 应用用户
DMP 零碎对接的是 3 类用户：
- 平台方面，包含广告平台、信息流、广告引擎以及触达零碎。
- 操作人员，包含经营、投放以及销售等业务相干操作人员。
- 诸如特色开发的产品及相干外部产品。
而这三局部人所对接的最前台的零碎也是不一样的。
首先咱们认为，平台或零碎方面会与 DMP 的接口层对接。接口次要分为三种：
第一种接口是诸如广告引擎和信息流常常申请用户命中了哪些人群包列表。 在广告引擎内，实现申请之后就能够间接把人群包列表变成某个广告 ID 并实现竞价。信息流与广告引擎相似：以后用户若命中了咱们要提权某内容或畛域标签时，咱们就会进行提权。该接口的设计就是典型的高稳定性、高并发、高吞吐。咱们能够通过线上数据来进行该接口与其余接口的承载差异比照：该接口以后承载了 10 万 qps，因为接口对接了公司的外围零碎，因而不能有任何抖动与故障，对它的稳定性要求达到 S 级，所以该接口也有多机缓存和高并发方面的相干设计，须要可能达到高稳定性、高并发、高吞吐的指标。
第二局部是站内与站外的人群包，该局部和上述内容也比拟相似，都会对接到咱们最外围的零碎。一旦人群包无奈圈选人群，前面整体的营销与定向投放也都会受到影响。对于 DMP 前台局部，该局部和接口层存在着显著区别：DMP 前台次要对接的是咱们的外部经营同学与销售同学。DMP 前台若产生异常情况，只是会不能进行新的洞察以及人群定向的，不会影响失常应用历史人群。因为该局部会对接泛滥的销售和人群而不是对接重申请的接口，应用的复杂性也就必须要降到最低，缩小在经营方面的培训老本，所以 DMP 前台就须要具备操作简略且应用成本低的特点。
第三方面是对接咱们的外部零碎，这部分次要会升高咱们日常开发的老本。
DMP 外围性能
DMP 可能反对人群圈选、泛化、人群洞察的外围业务模块；反对标签生产，ID Mapping 还有计算工作运维和存储方面的性能。
DMP 业务模块
DMP 业务模块分为高低两层，向上的业务层实现新增性能的低成本化，重点在于可扩展性；向下的业务层随着人群与业务性能的增长，整体的开发或技术投入老本不会有太大的产出，也就是资源上的可扩展性。
DMP 基础设施
最下方是基础设施，须要保障基础设施相干的稳定性。
咱们判断接口的根据是申请的接口次要承载是 Redis；Doris 次要承载了 DMP 前台和整体业务性能；后盾局部次要承载是 MySQL 与 TiDB。以上是咱们以后具体底层数据库的相干承载方面。
有人会问 Redis 老本是否会太高？不会的。因为 外围的圈选人群逻辑都是在 Doris 上实现的，寄存的大量相干标签都是通过 Doris 进行寄存，只有在某个广告要指定某指标人群的某几个特色进行排列组合并且实现泛化时，咱们会圈选出某个人群包 ID 对应的后果，最初才导出寄存到 Redis 中。因而 Redis 的次要目标是用来扛高并发，理论的寄存量很少。
DMP 平台性能盘点
性能盘点次要分为业务向与根底向两局部。
图 2.2 DMP 平台性能盘点 - 业务向
业务向
业务向咱们可能反对人群定向以及人群洞察两局部能力。
人群定向：
- 人群预估：比如说对性别、年龄、感兴趣的话题、该用户手机品牌是等多个条件进行排列组合，要求可能在 1 秒内实现准确构造的人群特色量级预估。
- 人群圈选：通过准确构造的人群数量预估后，能够在分钟级别内将预估后果转化为要进行投放和应用的相干人群包。
- 人群包泛化：泛化的能力要求尽可能简略，比如说我抉择有历史的人群包后，就能够进行人群泛化并有具体的执行度抉择。
人群洞察：
- 能够摸索以后流动入口画像，并实现流量回收。比如说我向 100 万人公布了推送，其中有 3 万人点击，那么能够对这 3 万人进行流量回收，与已推送的 100 万人进行比照，就能够这 3 万人显著的用户特色，不便咱们后续提取出更精准的用户群体。
根底向
另外 DMP 架构还有一些根底性能，包含了次要特色建设、ID mapping 以及计算工作运维。
图 2.3 DMP 平台性能盘点 - 根底向
这三个根底性能不仅能够让咱们疾速实现实时和批量计算，还可能帮忙咱们解决新老版本滚动上线的问题。因为咱们以后无论是通过 AI、数据采买、特色筛选，找到一个用户，即便是性别这种最根底的特色，也是在一直优化的过程，但每次优化是没有方法疾速进行经营影响的评估，因而就须要做到多版本灰度上线，并进行滚动上线。
特色建设
特色整体有两局部，一种是原子特色，一种是派生特色。
- 在建设原子特色时，咱们就须要从离线或实时数据中生产大量雷同基准的特色。
- 对于派生特色，会基于已生产的特色再生产一个特色。举例：如果咱们认为某群体是高生产能力群体，放在一个简略的场景中，咱们可能会圈选出一位在 18-25 岁之间并在一二线城市的女性，并认为这样的特色可能是对化妆品生产能力比拟高的群体特色。之后咱们就会把该特色作为派生特色进行存储并去放慢后续计算速度并升高经营筛选的老本。
特色建设能够做到能力隔离，以此来晋升咱们特色建设和上线效率。
Mapping 能力
包含设施 ID Mapping、用户特色 ID Mapping、泛化特色 ID mapping。该局部整体场景次要是对立 ID, 并将 ID 从差异较大、类型不同的不间断 ID 变成间断对立的 int 型自增 ID。
计算工作运维
工作运维次要是实现 DAG 的调度与计算资源管理。如果大家用过 Doris 的话，就会晓得 Doris 会应用最快的速度实现每一个 SQL 的执行。因而在进行人群预估时就须要做好排队的速度，否则忽然有一波经营动作或热点事件时，可能会呈现预估出多个人群包的情况并把所有资源都占满，这样都会相互受到影响，所以就须要通过工作运维进行资源的优先级排队，逐个执行相干人群包的圈选工作。
总结
- 特色建设能够做到能力隔离，以此来晋升咱们特色建设和上线效率。
- ID Mapping 屏蔽了咱们 ID Mapping 的艰难老本。咱们会分为实现原子特色建设、实现派生特色建设以及进行基础设施的建设这三局部。当基础设施建设同学实现屏蔽或在架构上隔离之后，特色建设的同学就不须要管 ID Mapping 方面的问题，只须要管专一于建设特色即可。
- 计算工作运维局部，对于业务开发同学并不需要晓得底层到底产生了什么，为此咱们要有一个同学实现对底层的封装后向下层提供一个接口，业务侧能够间接应用底层的性能的同时屏蔽了底层的复杂性。通过形象与屏蔽，能够显著的晋升最终上线与建设的效率，并能让其余某些工作从研发侧转移到经营侧。
举例： 咱们以后有两种特色，第一种是原子特色。在造成原子特色的过程中，写一个 SQL 就能够造成一个特色。分析师与业务产品均能够参加特色的建设过程。第二种是派生特色。咱们在经营后台上具备派生特色的交并差的能力，一些业务上的经营动作能够间接在治理后盾进行操作并实现派生特色的建设。这样次要的工作量从研发侧逐步转移到了产品侧与业务侧，显著的晋升了各种能力和特色上线的效率。
DMP 外围介绍
DMP 外围局部有两方面：数据的写入 / 导入以及快查 / 快读。写入和导入是链路及存储的一部分，快查和快读我会在后续进行介绍。
特色数据链路及存储
图 3.1 特色数据链路及存储
写入局部流程首先是离线链路：离线链路会从各个业务的 Hive 存储上跑相干的 SQL 并生成一个 Tag 表。咱们会在 Hive 上落一份 Tag 表后实现离线 Mapping。这个离线 Mapping 过程会申请通过用户设施外围主动生成对立间断的用户 ID，同时在离线 Mapping 的过程会把 imei、idfa、oaid 等数据进行转换和惟一绑定，若过程完结后发现新用户，则生成新 ID，若是老用户则获取用户 ID。通过这个过程，生成 ID mapping 的表，再进行大小写等简单流程就能够失去用户惟一 ID 与映射 ID 的 Mapping 表，这就是咱们失去的第一个表。
接着咱们会在 ID Mapping 后进行枚举采集：以后标签组是 125 个，由 120 个离线特色和 5 个施行特色组成。当咱们实现这 125 个相干数据的开发之后，数据相应的原子特色就能够通过 Mapping 间接拿进去。之所以要进行枚举采集是因为用户在应用过程中须要标签的搜寻性能，当用户搜寻标签时，250 万人工录入的老本过高，因而咱们在离线和实时处理的过程中会将枚举采集进去，并且通过 Bulk Load 的写到 ElasticSearch 中。在这个过程也会生成间断的自增 ID 去映射用户标签的倒排表，也就是 tag_map 表，这是咱们失去的第二个表。另外还存在第三个表用户行为表，这张表是咱们在实时数仓方面构建的，因而没有独自强调那一部分。
基于上述三张表的局部，咱们造成了三套存储：
- 第一套是在 ElasticSearch 上的搜寻标签存储。
- 第二套是在 Doris 上，也是最外围的存储。
- 第三套是整体 ID Mapping 的存储。
获取到这 3 个存储后，能够进行多种 Join 和查问，为后续的洞察及人群定向提供了根底。
接下来为大家颁布几个量级：用户 X 标签量级，为 1,100 亿；ID Mapping 是一个宽表，量级是 8.5 亿；ElastichSearch，量级是 250 万。这三个量级也是咱们为什么抉择 ElasticSearch 和 Doris 的起因。
人群定向流程
上述的数据导入后造成 3 张表，这里是利用这 3 张表产生人群相干定向和人群包。
图 3.2 人群定向流程
人群定向流程分为两种：
- 第一个是通过购物车筛选人群标签后进行人群预估，最初实现人群圈选回写到 Redis 的流程。
- 第二个是人群泛化，通过 AI 平台实现 AI 模型的整体训练及人群的推理，再回写到 Doris 中，通过置信度进行抉择并打上标签。
简略介绍一下这两个流程的过程：
整体的标签搜寻。 用户的前台在产出标签搜寻的事件之后就会去实现标签的搜寻：通过思考各种名字组合寻找想要的标签后，咱们会把这个标签放在标签购物车中并立。这个过程就是不停的向人群购物车中加各种标签和组合条件后，查看人群数量的过程。
这个过程存在的起因是在日常经营应用中，咱们会对每次推广或目标群体进行量级预估。如果这个事件本来只波及 200 万到 300 万左右的人群，通过人群圈选预估进去是 5,000 万，那么必定是咱们圈选条件不够精准，这个状况下咱们就须要逐步增加各种精准的条件，并把圈选管制在适合范畴的量级后再造成人群包，所以这个过程会一直进行循环并获取到适合的标签 / 特色的组合。在获取到适合的组合之后，咱们须要确定这个标签的指标和人群是，这个过程就会生成人群包。生成人群包的过程会进行连表操作并关联原数据，同时也会关联 ID Mapping 的表。若呈现导出到站外的状况，则会做 ID Mapping 的表并实现站外的 ID 转换。之后再把导出的人群包 ID 与人群 ID 写入 Reids 中，写入之后进行告诉。
如果只须要提供人群包来公布推送和短信等的业务就不须要写到 Redis 之中，这样能够大量开释存储并写到离线存储上。比如说一方面是 HDFS，另外一方面是咱们对接的对象存储就会写到这些存储之中。由这些存储间接传给推动零碎后，信息系统就能够间接拿到人群包并批量的给相干人群公布相干 Push 或推送。
人群泛化。 人群泛化流程最开始可能会有上传人群包的过程，也有可能没有。这个过程次要解决有些业务中，咱们领有某些历史流动的人群并须要进行人群泛化的问题。如果说它的人群包之前点击过咱们的 Push，能够间接筛选，筛选实现之后关联所有的用户特色进行用户训练，模型训练实现后再对全站用户进行推理，推理出一批带有置信度的人群 ID 的后果并返回写到 Doris 之中。在这个过程中会同时发动另外一个流程，此流程会对用户侧的泛化的后果进行筛选，能够依据适合的置信度抉择适合的数量。
接下来为大家介绍几个罕用流程： 在开发实现之后，最外围的流程就是加标签和购物车并实现圈选后，传统的人群进行泛化的流程。然而通过和经营侧沟通后，咱们发现日常工作中，经营侧实际上会将咱们这几个流程重复进行叠加应用，理论的应用有这么几种：拿到带有历史成果的人群并进行泛化，然而实现泛化之后成果他的用户特色也会被相应被扩充，之后再叠加本次经营特点的标签后实现圈选并进行应用。
第二种是获取到历史成果后进行洞察和剖析。 包含查看用户的画像后再从新依据标签关系圈选，之后又叠加了一次历史正向人群包后再去进行泛化。泛化之后再实现散发条件，最初再进行圈选，将该人群包给广告与相干的投放业务。经营侧会做很多基于原子能力以外更简单的一些组合后再进行应用。
人群定向性能优化
背景
图 3.3 人群定向性能优化 背景与难点
以后 DMP 零碎中有两大性能，第一大性能是人群定向，另外一大性能是人群洞察。基于这两大性能会有一个底层的性能是建设各种用户方面的画像特色。当咱们实现拆解之后，咱们就会发现人群定向的这部分性能是经营侧或业务侧的痛点。
场景要求
- 人群预估，针对投放和营销场景，经营侧会有人数预期，那么会构建相应规模的购物车，继续在购物车中退出新的特色，须要立刻看到新的特色退出之后会圈选出多少人，而不是每次退出新的特色后都须要很长时间的期待。
- 人群圈选，针对热点经营。经营侧在日常工作中会继续跟进产生的各种热点事件，当产生了某些热点事件后，要疾速的圈选出人群包公布 Psuh 和 举荐。如果圈选过程须要好几分钟，就会错过热点事件。
难点
- 第一个数据量极大，如上图标注。
- 第二个冀望工夫很短，人群预估与人群筛选别离可能在一秒钟内和一分钟内实现。
性能优化（1）
第一阶段优化咱们通过了以下几点来解决这两个问题：
图 3.3 人群定向性能优化 第一阶段
倒排索引和按条件查问
图 3.4 人群定向性能优化 倒排索引及 ID Mapping
- 首先，倒排索引方面，咱们将查问条件由原先的 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 变成间断自增的。
查问逻辑变更
图 3.5 人群定向性能优化 查问逻辑变更
原先的查问条件是 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）
基于仍存在的问题，咱们进行了第二阶段的优化。
图 3.6 人群定向性能优化 第二阶段
分而治之
第二阶段的外围的思路是分治。当咱们进行了第一波上线后，发现人群预估能力是分钟级别，圈选基本上要到 10 分钟开外了。分治的思路是将全站的用户全副打成间断自增 ID 后，依照某个水平进行分组。比如说 0-100 万是一组，100 万 -200 万是一组 … 逐步分为几个组别。全站用户的交并差，能够等价于分组之后的交并差后果之和。
图 3.7 人群定向性能优化 分治
数据预置
当咱们发现这个法则之后，通过分而治之能够做相干的数据预置。利用 Doris 中 Colocate group 个性，把每个分组内 100 万人全副放到某一台物理机上，防止网络的开销。
算子优化
全副放到某一个物理机上之后，就能够把聚合的算子由原先 bitmap\_and\_not 的 bitmap not 和 bitmap count 替换成一个函数来实现。此时基于 Doris 团队的新版本，减少了相似 bitmap\_and\_not_count 的组合函数后，性能绝对于原先的嵌套函数有了比拟显著的优化。
解决方案
基于上述解决思路，咱们设计了新的解决方案。
新的解决方案以上 3 个思路进行拆分，包含查问逻辑的变更，预估变成子逻辑的求和、人群圈选变成子逻辑的合并。
- 因为把原先几个 bitmap 的计算变成了多个小组 bitmap 计算，能进一步的晋升多线程的并行度，使计算速度晋升；同时也对代码进行了优化，将可复合的 bitmap\_and\_or_not 函数在提交时合并成同一个函数；在写入过程中把分组 ID 和相应的百万分组进行写入调整。
- 离线和实时之中都会写相应的 tag 表。在实现 tag 表的写入之后能够把每一个 tag 之中不同的 user tag 写到不同的物理机上：比方能够将 300 万拆开别离写在三台不同的物理机上，实现物理机方面的区隔。这里借助了 Colocate group 以及 Group key 进行设置。实现写入之后，计算过程从原先的整体计算变成独立依照每一个 Group 进行计算。因为整体的 bitmap 很大，每一个独立的 Group 又都在一台物理机下面进行计算，速度有非常明显的晋升。
- 在每一个 Group 计算之后进行合并，合并之后，人群预估变成了不同物理机下面的数字简略加和，后果根本达到秒出。人群圈选也就变成了不同物理机下面的 bitmap，再 Shuffle 进来做最初的合并，这个过程量级很小，能够做到 1 分钟之内输入后果。
优化后果
上面两张截图别离是还没有进行合并之前以及合并之后的查问打算。
图 2.7 人群定向性能优化 数据预置
优化前： 在查问的过程中，首先咱们须要针对某一个 tag 做一个 bitmap\_and 和 bitmap\_not 或者 bitmap_or，在这之后另外几个 tag 也会做雷同的聚合，在聚合完之后再做一次 Shuffle，最初进行 Join。同时另外的局部也会进行聚合，通过聚合之后再进行 Shuffle 和 Join。
这几次聚合过程中，每一个 tag 都有十分高的老本，都须要通过聚合—网络传输—再聚合—再网络传输的过程后再做 Join。
优化后： 查问打算有了非常明显的扭转。只须要通过一个函数在合并的过程中进行查问，合并实现之后就能够实现最终的后果合并。无论是 int 类型的相加还是 bitmap 的合并都只有最初一层，速度有显著晋升。原先人均预估可须要分钟级别实现，优化后，只须要几百毫秒便可实现，即便是简单到上千个条件也只须要一秒就能够实现。
人群圈选也和上述过程相似：在条件简单的状况下，能够做到一分多钟到两分多种之间实现。如果只有几十到 一百个的条件的话，人群圈选都能够在一分钟左右实现。
整个过程次要对数据进行了拆分，由 Doris 的 Colocate 原理把拆分后的数据提前预置在某一台物理机下面，通过优化，能够满足大部分场景的经营要求。
将来及瞻望
业务向
图 4.1 将来与瞻望 业务向
如红色框选所见，以后的零碎流程是人群定向之后进行 Mapping，在用户洞察上是围绕人群进行建设的，同时与各个业务侧在 Mapping、洞察以及人群等环节进行对接。然而在这个流程中，如何通过经营达成指标、如何设计 AB 计划，两个局部是松耦合的。
将来咱们心愿 DMP 经营平台不光是松耦合的模式，而且可能在在业务上执行强耦合、强绑定的模式。这样的经营模式在应用过程中会更难受，能够齐全在 DMP 平台上实现了整体经营流程，并能够依据经营成果设计相干的 AB 试验，一直优化。
技术向
图 4.2 将来与瞻望 技术向
技术建设过程中，最次要的就是圈选人群。经营侧甚至会选几百个条件进行人群圈选。而这些经营人员可能分属在不同业务，这会导致他们的根底条件写得很类似。对于这种类似的根底条件咱们会人工建设相应的 bitmap 进行预合并，再去基于此特色圈选，因为预合并的缘故会显著晋升咱们后续的执行速度。
第一个是查问效率。 对所有经营的人群圈选进行定期扫描及 SQL Parser。通过解析主动设计 SQL 的聚合条件进行预聚合，合成相应的 bitmap 的同时注册到相干的特色。在人群圈选时咱们也会通过雷同的 SQL Parser 主动将原先圈选的 SQL 改写，在改写之前可能会有好几十个特色，而他们又正好等于某一个派生特色的后果，此时就能够间接替换成派生特色。这个行动能进一步的晋升咱们查问的圈选速率。
第二个是导入速度。 咱们通过五天的工夫，每天须要导入大略 2TB 的数据量，存储了 11TB 的数据，数据量比拟大，咱们心愿在导入的过程中能够进一步的提速。以后咱们理解到业界有做 Spark 间接撰写具体 OLAP 引擎文件，咱们也在思考是否能够通过 Spark 间接撰写 Doris Tablet 文件并挂载到 FE 下面，让咱们可能疾速实现导入或写入。
Q&A 环节
Q：知乎的标签体系有多少标签？记录量是多少？后盾是一张还是多张的大宽表？在人群圈选的时候进行表链接，业务人员是否实时显示圈选出的人群特色和人群数量？
A：知乎的标签体系很大，蕴含了用户、内容、商业以及业务方面治理与平安等很多方面的标签，DMP 零碎方面次要会与用户方面的标签进行对接。就单论通过认证且正在应用的标签组而言就有将近 700 多个，如果在加上业务方面在提未认证标签能够达到上千个。对于咱们正在应用的用户方面的标签有 120 个标签组以及 5 个实时标签，总共 125 个标签。
记录量方面有 1100 亿的记录量。
后盾不是一张宽表。在子标签实现生成后，会生成出独立的 tag1、tag2、tag3 的数据源表。通过咱们将这些表写入 DMP 之后最终才会变成一个大宽表，在 DMP 中是问题中的一个大宽表，在业务中则是每个独立的标签表。多张大宽表在进行人群标签圈选时会进行连贯，咱们在通过数据处理后，会将数据写入到一张表中而不再是一张大宽表。
因为咱们的优化，在这一张表中的存储的文件曾经不会再依照 Tag ID 这种查问进度缓慢的形式进行扩散。咱们会依照存储的 Key，比如说 0~100 万的 ID 都会分在雷同的中央进行存储。咱们在计算的过程会在同一台物理机扫描进去，在通过聚合逻辑后就能够拿到后果。所以也就可能做到实时圈选相干数量的后果。
Q：人群圈选是基于教训进行标签组合圈选吗？投入后的成果如何剖析？是独立的剖析平台工具吗？如何晓得投放人群包的转化率？转化是否回到打标签中利用另外的剖析平台进行剖析？
A：人群圈选能够分为两局部。第一局部是咱们基于经营的教训进行圈选，这个局部中又分为已知人群圈选与未知人群圈选两个分支。
已知人群圈选，意味着经营曾经对这个场景十分明确。可能熟知咱们在经营的用户群体就是某个性别以及用户年龄段等，这时候咱们就会基于历史教训进行圈选。对于齐全未知的用户特色，咱们会间接圈大盘。
这两种经营流程的区别就在于已知用户群体圈选的准确率会更高。基于已知的后果，咱们简直不再须要不必进行 AB 试验就能够实现本次投放。对于齐全未知的用户特色而言，如果间接圈大盘的话，咱们就肯定须要进行小流量的 AB 试验发现点击 Push 的用户都满足某一个趣味后，就能够基于这部分趣味积攒教训，之后再设计一个 AB 试验并调整人群特色至适合场景，直到成果逐步的达到冀望指标后，就会从未知的人群变为已知人群。
还存在另外一种教训。比如说广告主的教训，广告主可能在知乎中并没有历史投放教训，然而广告主晓得购买过我的产品人群有哪些，比如说他们手机号的加密 MD5 或手机 idfa 的加密 MD5 等，这样就能够将其余站投放过的成果实现导入，造成根本的人群。通过人群泛化，和站内所有的特色进行 Join 后去训练模型，通过 AI 的能力主动寻找到我的历史购买人群有怎么样的显著特色，之后就能够实现这部分泛化的全选。基于泛化的全选后，还是会通过雷同的链路并实现这部分的数次循环循，之后就能够晓得我这个场景下应该投放给哪些用户。
转化率咱们在独自的中央进行查看，这也是我前期想要集成在 DMP 平台内做到的性能。咱们在独自的页面上能够看不同 Push 的转化率。DMP 平台下面只能通过成果回收进行查看。
Q：后盾都是基于 Doris 吗？多少节点是一个集群呢？
A：后盾次要的计算方面都是基于 Doris。在高吞吐方面咱们也依赖于 Redis。TPP 方面咱们用了 TiDB。以后 Doris 集群是 6 节点，64 外围 256g 的 BE；3 个 FE 是 6 节点，16 外围 32g 的集群配置。
Q：人群放大靠谱吗？所有的人群圈选占比有多大，用的是什么算法？
A：人群放大是比拟靠谱的。从经营侧的反馈能够得悉：如果只通过广告主或只通过基于列入历史经营成果拿到的数据基本上无奈反对实现本次经营，然而如果把咱们所有的特色都退出并进行训练的话，根本每次都会有比拟显著的晋升，在 CTR 方面，可能达到 80%-90%。置信度调整为了 80%。
人群圈选业务应用占比会比个别圈选要少一些。对于个别圈选而言，咱们以后历史上已有的特色也带有置信度。咱们基于这些已有特色根本就能够实现绝大部分的经营工作。而人群泛化次要是用来解决的是当我对这部分客户齐全没有认知，同时又想将站内全副随机大盘用户导入，进行用户群体特色探测的状况。这个过程其实对经营侧而言工作量比拟大，只有在这种特定状况下才会选用泛化，所以泛化的占比依照比例来讲是不多的。比如说每天有 300 个基于特色和标签的定向，而每天基于算法方面的泛化是 1~2 次。
用的是什么算法我还没有细看过。以后咱们会通过数据来调用 AI 同学的相干的算法。咱们以后提供的就是将用户的所有特色都筹备好后灌入到 AI 的主动训练的模型之中。在实现训练之后，咱们再调用这个模型并把所有特色都灌入进行推理。
Q：AB 如果要用 Reids 查标签该如何设计？要如何放弃实时性呢？
A：对于问题中 A 表和 B 表要查标签，数据量会爆炸，这个状况是确实存在的。所以我倡议做标签，最好所有的标签都在这一个表里。通过咱们以后经验的摸索得出的论断，咱们对于该问题的解决方案就是每一台物理机可能会存多个 100 万，然而要确保每一个 100 万的分段都在同一台物理机上，它就能够变成这台物理机的 Scan 以及聚合之后进行间接运算，所以它就不存在双表的 Join 问题，能够间接在表内进行聚合。咱们这边有好几个相似于 bitmap and or not 的标签的计算，然而在算子方面，算子曾经是被合并在聚合算子外面并实现聚合，聚合后再做一个最终的数据合并，这样的话性能会好很多，而且也能防止 A 表和 B 表做 Join 的后果。
对于第二个问题，咱们实现人群的 ID 聚合都会通过这个函数。当这个函数走完之后，它会生成以后投放特色下的人群列表，我才实现 Join。在这个时候，一般的 Join 就不会有十分爆炸的数量，也不会波及到上千亿的疾速的查问计算。
Q：能够解读一下对于 250 万个标签的相干内容吗？
A：大家能够在图 1.3 中看到, 呈现像 250 万个标签次要是因为一个性别在标签组内算作 1，而在标签方面则会领有男、女、其余 3 个标签。在手机品牌中，一个标签组下咱们以后也是收录了将近 20 多个手机品牌的标签。之后还有话题趣味的标签组中相当多的话题趣味的标签数量。比如说知乎站内其实有很多话题，某些用户可能对影视内容感兴趣，也可能对母婴内容感兴趣，同时也可能对教育或学生内容感兴趣，以上的话题趣味有具备间断的共性点。间断标签方面咱们会在后续的文章中持续为大家介绍。以后用户画像的内容方面，如果从标签进行分组，都是属于离散标签。间断标签更多的是用户行为或者是操作数值等。
Q：标签和特色的关系是什么？标签又是怎么建设的？
A：咱们定义特色是要比拟比标签大的，能够了解为咱们以后的特色中 90% 是标签，剩下 10% 是用户行为的比例。
退出社区
欢送更多酷爱开源的小伙伴退出 Apache Doris 社区，参加社区建设，除了能够在 GitHub 上提 PR 或 Issue 之外，也欢送大家积极参与到社区日常建设中来，比方：
加入社区征文活动，进行技术解析、利用实际等文章产出；作为讲师参加 Doris 社区的线上线下流动；积极参与 Doris 社区用户群的发问与解答等。
最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。
SelectDB 是一家开源技术公司，致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。
相干链接：
SelectDB 官方网站：
https://selectdb.com
Apache Doris 官方网站：
http://doris.apache.org
Apache Doris Github：
https://github.com/apache/doris
Apache Doris 开发者邮件组：
dev@doris.apache.org
我要投稿：https://jinshuju.net/f/nEPj5W