导读：知乎基于业务需求搭建了DMP平台，本文详细的介绍了DMP的工作原理及架构演进过程，同时介绍了ApacheDoris在DMP平台的应用实践，本文对大家了解DMP工作方式很有帮助，欢迎阅读。
作者｜用户理解&数据赋能研发Leader侯容
DMP业务包含：业务模式、业务场景以及业务需求。
图1.1DMP业务
DMP平台业务模式
基于这三种业务模式，主要应用的业务场景：
基于业务模式场景，在人群方面能做的事情可以分为三类：
一般分为以下3种情况：
人群定向包括导入/导出、基于某些特征进行标签圈选、人群泛化、用户量预估等。
包括画像洞察，用户的内部画像以及两个不同人群包之间的对比分析。
图1.2DMP业务流程
人群定向。通过标签圈选，选择历史上有活动效果或导入喜欢此活动的人群，进行泛化完成基础人群包选择，以此来确定目标人群。
若此次Push的点击量达成推送目标，那么目标完成；若点击量没有达成目标，我们会进行一个假设，比如最初预测点击Push的男性＞女性，但最后得出的结果相反时，我们会通过TGI算法进行排序，找出这两次差别的典型特征，完成设计并产出AB实验。
基于已经积累的用户特征数据，找出在知乎内部有几率产生站外效果的人群，并划出该类人群的范围。再通过Mapping，可以把站内的ID转换成在三方投放平台上产出的ID并进行投放。
由于这个过程我们的站内系统不同，并不能直接拿到相应的埋点数据供我们进行数据链路建设，所以就必须要通过三方投放平台上下载相应的埋点数据，通过类似的场景完成数据导入后再进行后续流程的建设。这也就导致了整个过程的效果回收会比较长。
人群泛化会把导入人数较少的种子人群连接到知乎，这个过程可以对用户达成的所有特征在AI模型中完成训练。可以训练出种子人群在知乎所有用户特征下的模型是什么，之后再把所有用户的全部特征灌入得到的模型之中进行推理。这样得到带有置信度的目标用户。
基于上述运营流程，我们可以抽象出DMP平台最核心的功能包括洞察、定向以及IDmapping。
图1.3DMP画像特征
图1.4DMP功能梳理
接下来将为大家介绍具体功能。
图2.1DMP业务架构
我认为架构对于实现最终目标是很重要的阶段，但并不是必要阶段。只要我们把所有功能都进行完善就可以完成我们所有的业务实践，但是这样会导致在系统经过不断膨胀后，所对应的维护成本也会不断变高，稳定性变差，最后导致没有人可以维护的窘迫情况发生。架构主要可以为我们解决在多个复杂业务功能场景下，如何以低成本的方式进行维护迭代并有目标的去针对某个模块进行优化，但并不能解决实际的业务功能问题。
基于以上我对架构的认知，对业务以及整体DMP架构进行拆解：
DMP系统对接的是3类用户：
而这三部分人所对接的最前台的系统也是不一样的。
首先我们认为，平台或系统方面会与DMP的接口层对接。接口主要分为三种：
第二部分是站内与站外的人群包，该部分和上述内容也比较类似，都会对接到我们最核心的系统。一旦人群包无法圈选人群，后面整体的营销与定向投放也都会受到影响。对于DMP前台部分，该部分和接口层存在着明显区别：DMP前台主要对接的是我们的内部运营同学与销售同学。DMP前台若产生异常情况，只是会不能进行新的洞察以及人群定向的，不会影响正常使用历史人群。由于该部分会对接众多的销售和人群而不是对接重请求的接口，使用的复杂性也就必须要降到最低，减少在运营方面的培训成本，所以DMP前台就需要具备操作简单且使用成本低的特点。
第三方面是对接我们的内部系统，这部分主要会降低我们日常开发的成本。
DMP能够支持人群圈选、泛化、人群洞察的核心业务模块；支持标签生产，IDMapping还有计算任务运维和存储方面的功能。
DMP业务模块分为上下两层，向上的业务层实现新增功能的低成本化，重点在于可扩展性；向下的业务层随着人群与业务功能的增长，整体的开发或技术投入成本不会有太大的产出，也就是资源上的可扩展性。
功能盘点主要分为业务向与基础向两部分。
图2.2DMP平台功能盘点-业务向
业务向我们能够支持人群定向以及人群洞察两部分能力。
人群定向：
人群洞察：
另外DMP架构还有一些基础功能，包括了主要特征建设、IDmapping以及计算任务运维。
图2.3DMP平台功能盘点-基础向
这三个基础功能不仅可以让我们快速完成实时和批量计算，还能够帮助我们解决新老版本滚动上线的问题。因为我们当前无论是通过AI、数据采买、特征筛选，找到一个用户，即使是性别这种最基础的特征，也是在不断优化的过程，但每次优化是没有办法快速进行运营影响的评估，因此就需要做到多版本灰度上线，并进行滚动上线。
特征建设
特征整体有两部分，一种是原子特征，一种是派生特征。
特征建设可以做到能力隔离，以此来提升我们特征建设和上线效率。
Mapping能力
包括设备IDMapping、用户特征IDMapping、泛化特征IDmapping。该部分整体场景主要是统一ID,并将ID从差别较大、类型不同的不连续ID变成连续统一的int型自增ID。
计算任务运维
总结
举例：我们当前有两种特征，第一种是原子特征。在形成原子特征的过程中，写一个SQL就可以形成一个特征。分析师与业务产品均可以参与特征的建设过程。第二种是派生特征。我们在运营后台上具备派生特征的交并差的能力，一些业务上的运营动作可以直接在管理后台进行操作并完成派生特征的建设。这样主要的工作量从研发侧逐渐转移到了产品侧与业务侧，明显的提升了各种能力和特征上线的效率。
DMP核心部分有两方面：数据的写入/导入以及快查/快读。写入和导入是链路及存储的一部分，快查和快读我会在后续进行介绍。
图3.1特征数据链路及存储
基于上述三张表的部分，我们形成了三套存储：
获取到这3个存储后，可以进行多种Join和查询，为后续的洞察及人群定向提供了基础。
接下来为大家公布几个量级：用户X标签量级，为1,100亿；IDMapping是一个宽表，量级是8.5亿；ElastichSearch，量级是250万。这三个量级也是我们为什么选择ElasticSearch和Doris的原因。
图3.2人群定向流程
人群定向流程分为两种：
简单介绍一下这两个流程的过程：
整体的标签搜索。用户的前台在产出标签搜索的事件之后就会去完成标签的搜索：通过思考各种名字组合寻找想要的标签后，我们会把这个标签放在标签购物车中并立。这个过程就是不停的向人群购物车中加各种标签和组合条件后，查看人群数量的过程。
这个过程存在的原因是在日常运营使用中，我们会对每次推广或目标群体进行量级预估。如果这个事件原本只涉及200万到300万左右的人群，经过人群圈选预估出来是5,000万，那么肯定是我们圈选条件不够精准，这个情况下我们就需要逐渐添加各种精准的条件，并把圈选控制在合适范围的量级后再形成人群包，所以这个过程会不断进行循环并获取到合适的标签/特征的组合。在获取到合适的组合之后，我们需要确定这个标签的目标和人群是，这个过程就会生成人群包。生成人群包的过程会进行连表操作并关联原数据，同时也会关联IDMapping的表。若出现导出到站外的情况，则会做IDMapping的表并完成站外的ID转换。之后再把导出的人群包ID与人群ID写入Reids中，写入之后进行通知。
人群泛化。人群泛化流程最开始可能会有上传人群包的过程，也有可能没有。这个过程主要解决有些业务中，我们拥有某些历史活动的人群并需要进行人群泛化的问题。如果说它的人群包之前点击过我们的Push，可以直接筛选，筛选完成之后关联所有的用户特征进行用户训练，模型训练完成后再对全站用户进行推理，推理出一批带有置信度的人群ID的结果并返回写到Doris之中。在这个过程中会同时发起另外一个流程，此流程会对用户侧的泛化的结果进行筛选，可以根据合适的置信度选择合适的数量。
接下来为大家介绍几个常用流程：在开发完成之后，最核心的流程就是加标签和购物车并完成圈选后，传统的人群进行泛化的流程。但是经过和运营侧沟通后，我们发现日常工作中，运营侧实际上会将我们这几个流程反复进行叠加使用，实际的使用有这么几种：拿到带有历史效果的人群并进行泛化，但是完成泛化之后效果他的用户特征也会被相应被扩大，之后再叠加本次运营特点的标签后完成圈选并进行使用。
图3.3人群定向性能优化背景与难点
当前DMP系统中有两大功能，第一大功能是人群定向，另外一大功能是人群洞察。基于这两大功能会有一个底层的功能是建设各种用户方面的画像特征。当我们完成拆解之后，我们就会发现人群定向的这部分功能是运营侧或业务侧的痛点。
第一阶段优化我们通过了以下几点来解决这两个问题：
图3.3人群定向性能优化第一阶段
图3.4人群定向性能优化倒排索引及IDMapping
图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秒钟进行人群预估是不可能的。
基于仍存在的问题，我们进行了第二阶段的优化。
图3.6人群定向性能优化第二阶段
第二阶段的核心的思路是分治。当我们进行了第一波上线后，发现人群预估能力是分钟级别，圈选基本上要到10分钟开外了。分治的思路是将全站的用户全部打成连续自增ID后，按照某个程度进行分组。比如说0-100万是一组，100万-200万是一组…逐渐分为几个组别。全站用户的交并差，可以等价于分组之后的交并差结果之和。
图3.7人群定向性能优化分治
全部放到某一个物理机上之后，就可以把聚合的算子由原先bitmap_and_not的bitmapnot和bitmapcount替换成一个函数来实现。此时基于Doris团队的新版本，增加了类似bitmap_and_not_count的组合函数后，性能相对于原先的嵌套函数有了比较明显的优化。
基于上述解决思路，我们设计了新的解决方案。
新的解决方案以上3个思路进行拆分，包括查询逻辑的变更，预估变成子逻辑的求和、人群圈选变成子逻辑的合并。
下面两张截图分别是还没有进行合并之前以及合并之后的查询计划。
优化前：在查询的过程中，首先我们需要针对某一个tag做一个bitmap_and和bitmap_not或者bitmap_or，在这之后另外几个tag也会做相同的聚合，在聚合完之后再做一次Shuffle，最后进行Join。同时另外的部分也会进行聚合，经过聚合之后再进行Shuffle和Join。
这几次聚合过程中，每一个tag都有非常高的成本，都需要经过聚合—网络传输—再聚合—再网络传输的过程后再做Join。
优化后：查询计划有了非常明显的改变。只需要通过一个函数在合并的过程中进行查询，合并完成之后就可以完成最终的结果合并。无论是int类型的相加还是bitmap的合并都只有最后一层，速度有显著提升。原先人均预估可需要分钟级别完成，优化后，只需要几百毫秒便可完成，即使是复杂到上千个条件也只需要一秒就可以完成。
人群圈选也和上述过程类似：在条件复杂的情况下，可以做到一分多钟到两分多种之间完成。如果只有几十到一百个的条件的话，人群圈选都可以在一分钟左右完成。
整个过程主要对数据进行了拆分，由Doris的Colocate原理把拆分后的数据提前预置在某一台物理机上面，通过优化，可以满足大部分场景的运营要求。
图4.1未来与展望业务向
如红色框选所见，当前的系统流程是人群定向之后进行Mapping，在用户洞察上是围绕人群进行建设的，同时与各个业务侧在Mapping、洞察以及人群等环节进行对接。但是在这个流程中，如何通过运营达成目标、如何设计AB方案，两个部分是松耦合的。
图4.2未来与展望技术向
技术建设过程中，最主要的就是圈选人群。运营侧甚至会选几百个条件进行人群圈选。而这些运营人员可能分属在不同业务，这会导致他们的基础条件写得很相似。对于这种相似的基础条件我们会人工建立相应的bitmap进行预合并，再去基于此特征圈选，由于预合并的缘故会明显提升我们后续的执行速度。
Q：知乎的标签体系有多少标签？记录量是多少？后台是一张还是多张的大宽表？在人群圈选的时候进行表链接，业务人员能否实时显示圈选出的人群特征和人群数量？
A：知乎的标签体系很大，包含了用户、内容、商业以及业务方面治理与安全等很多方面的标签，DMP系统方面主要会与用户方面的标签进行对接。就单论通过认证且正在使用的标签组而言就有将近700多个，如果在加上业务方面在提未认证标签可以达到上千个。对于我们正在使用的用户方面的标签有120个标签组以及5个实时标签，总共125个标签。
记录量方面有1100亿的记录量。
后台不是一张宽表。在子标签完成生成后，会生成出独立的tag1、tag2、tag3的数据源表。经过我们将这些表写入DMP之后最终才会变成一个大宽表，在DMP中是问题中的一个大宽表，在业务中则是每个独立的标签表。多张大宽表在进行人群标签圈选时会进行连接，我们在经过数据处理后，会将数据写入到一张表中而不再是一张大宽表。
Q：人群圈选是基于经验进行标签组合圈选吗？投入后的效果如何分析？是独立的分析平台工具吗？如何知道投放人群包的转化率？转化是否回到打标签中利用另外的分析平台进行分析？
A：人群圈选可以分为两部分。第一部分是我们基于运营的经验进行圈选，这个部分中又分为已知人群圈选与未知人群圈选两个分支。
已知人群圈选，意味着运营已经对这个场景非常明确。能够熟知我们在运营的用户群体就是某个性别以及用户年龄段等，这时候我们就会基于历史经验进行圈选。对于完全未知的用户特征，我们会直接圈大盘。
这两种运营流程的区别就在于已知用户群体圈选的准确率会更高。基于已知的结果，我们几乎不再需要不用进行AB实验就可以完成本次投放。对于完全未知的用户特征而言，如果直接圈大盘的话，我们就一定需要进行小流量的AB实验发现点击Push的用户都满足某一个兴趣后，就可以基于这部分兴趣积累经验，之后再设计一个AB实验并调整人群特征至合适场景，直到效果逐渐的达到期望目标后，就会从未知的人群变为已知人群。
转化率我们在单独的地方进行查看，这也是我后期想要集成在DMP平台内做到的功能。我们在单独的页面上可以看不同Push的转化率。DMP平台上面只能通过效果回收进行查看。
Q：后台都是基于Doris吗？多少节点是一个集群呢？
A：后台主要的计算方面都是基于Doris。在高吞吐方面我们也依赖于Redis。TPP方面我们用了TiDB。当前Doris集群是6节点，64核心256g的BE；3个FE是6节点，16核心32g的集群配置。
Q：人群放大靠谱吗？所有的人群圈选占比有多大，用的是什么算法？
人群圈选业务使用占比会比一般圈选要少一些。对于一般圈选而言，我们当前历史上已有的特征也带有置信度。我们基于这些已有特征基本就可以完成绝大部分的运营工作。而人群泛化主要是用来解决的是当我对这部分客户完全没有认知，同时又想将站内全部随机大盘用户导入，进行用户群体特征探测的情况。这个过程其实对运营侧而言工作量比较大，只有在这种特定情况下才会选用泛化，所以泛化的占比按照比例来讲是不多的。比如说每天有300个基于特征和标签的定向，而每天基于算法方面的泛化是1~2次。
Q：AB如果要用Reids查标签该如何设计？要如何保持实时性呢？
A：对于问题中A表和B表要查标签，数据量会爆炸，这个情况是的确存在的。所以我建议做标签，最好所有的标签都在这一个表里。通过我们当前经历的探索得出的结论，我们对于该问题的解决方案就是每一台物理机可能会存多个100万，但是要确保每一个100万的分段都在同一台物理机上，它就可以变成这台物理机的Scan以及聚合之后进行直接运算，所以它就不存在双表的Join问题，可以直接在表内进行聚合。我们这边有好几个类似于bitmapandornot的标签的计算，但是在算子方面，算子已经是被合并在聚合算子里面并完成聚合，聚合后再做一个最终的数据合并，这样的话性能会好很多，而且也能避免A表和B表做Join的结果。
对于第二个问题，我们完成人群的ID聚合都会通过这个函数。当这个函数走完之后，它会生成当前投放特征下的人群列表，我才完成Join。在这个时候，普通的Join就不会有非常爆炸的数量，也不会涉及到上千亿的快速的查询计算。
Q：标签和特征的关系是什么？标签又是怎样建立的？
A：我们定义特征是要比较比标签大的，可以理解为我们当前的特征中90%是标签，剩下10%是用户行为的比例。
欢迎更多热爱开源的小伙伴加入ApacheDoris社区，参与社区建设，除了可以在GitHub上提PR或Issue之外，也欢迎大家积极参与到社区日常建设中来，比如：
最后，欢迎更多的开源技术爱好者加入ApacheDoris社区，携手成长，共建社区生态。
SelectDB是一家开源技术公司，致力于为ApacheDoris社区提供一个由全职工程师、产品经理和支持工程师组成的团队，繁荣开源社区生态，打造实时分析型数据库领域的国际工业界标准。基于ApacheDoris研发的新一代云原生实时数仓SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。