安排！活动素材的亿级用户精准投放

随着闲鱼用户快速增长，运营活动越来越趋于精细和个性化，运营会根据用户偏好为其投放合适的活动，如下图所示在闲鱼首页商品展示时，会在商品的列表中插入活动Banner，通过这些活动banner引导用户进入到相应活动会场，实现会场导流。

闲鱼投放系统负责闲鱼运营活动的配置、管理、投放。主要解决了以下几个问题。

闲鱼投放系统是一个配置管理和配置检索的系统，换句话讲他不生产任何活动素材，他只是活动素材的搬运工。下面介绍闲鱼投放的系统设计。

如上图所示闲鱼投放系统共分为了活动素材层、投放配置层、业务流程层和应用层四个层次。

活动素材层是对在闲鱼投放系统中所有素材源的汇总，目前闲鱼投放中主要汇集了三种素材鲁班素材、马赫素材、TPP素材，鲁班素材提供了用户个性化Banner的能力，他的原理是根据用户的行为获取到偏好的商品，然后把商品图和素材模板组合为一个Banner；马赫素材提供规则圈选商品，他的原理是利用规则引擎把规则转换为SQL语句，然后利用该SQL在商品表中捞出符合规则的商品，同时马赫利用流计算能力对增量商品也实现了实时的规则圈选。TPP素材提个性化商品推荐，例如首页的商品推荐和猜你喜欢的商品推荐，TPP作为个性化推荐平台，可以根据不同的算法实现不同的推荐策略。

投放配置层是开放给运营能力的汇总，包含活动配置、环境隔离、数据报表三种能力。活动配置是对一个资源位下所有投放行为的具体配置，如下图所示，

在上文中我们提到闲鱼投放面临四个需要解决的问题，分别是环境隔离问题、活动检索问题、人群管理问题、AB能力问题。下面将分别从这几个问题出发介绍解决的方法。

人群管理使用的是集团内的奥格人群平台，他为我们提供了人群圈选和人群验证的能力，在很大程度上解放了闲鱼投放的人群管理，下面简单的介绍一下该平台的实现原理。

如上图所示展示了奥格几个核心功能点，实现原理是这样的，首先平台会提供给用户可选择的规则，然后利用规则引擎把所选的规则，生成SQL查询语句和流计算规则，SQL查询语句用来离线圈选用户和流计算规则用来实时筛选新增用户，通过离线规则和在线规则实现了奥格的人群圈选，在人群验证阶段，首先利用倒排检索的思想，用户和人群的关系利用倒排数据结构标识，该方法解决了单用户与多人群关系验证的效率问题，最后利用多级缓存和热点数据本地缓存的方式解决人群检索RT问题。

AB测试是用来验证方案的常用方法，常用的AB测试方案大多是用户唯一属性取模的方式按比例划分用户，但是会面临很多复杂的问题1.按照用户的id进行取模计算，对于未登录用户处理是一个常被忽略的问题。2.测试白名单管理，在AB测试时需要把特定人员划分到特定测试桶里。3.多个AB正交测试，如果有多个AB测试，此时需要正交测试时会出现更复杂的情况。在闲鱼投放中使用了集团的一休AB平台，一休提供基于用户、设备等多维度AB策略，同时支持白名单与正交AB测试的复杂场景，在AB基本能力的基础上提供了数据分析的能力，实现了调用到数据管理的一体化。

解决环境隔离问题主要是为了方便测试，先在线下看效果，然后再把数据配置到线上。为了实现环境隔离迭代两次技术方案。

首先介绍第一个方案，依照总体功能设计我希望平台中每个模块都可以灵活复用，可以利用已有模块，快速搭建出满足业务要求的投放活动，所以从业务角度进行了抽象，把能拆分的模块尽可能的抽象出来，最终的实体关系如下图所示。从业务逻辑角度共抽象了6个实体分别是资源位（Resource）、活动（Activity）、人群（Crowd）、素材（Data Source）、资源位和活动的关系（Resource Plan）、活动和人群素材的关系（Activity Plan）实体，每个模块之间可以按照下图的关系进行自由组合成一个投放活动。

在该方案中利用每个实体中的env字段解决环境隔离问题，无论是在投放活动配置还是在检索过程中，只可以利用相同env字段的实体，该方法完全实现了环境隔离，但是在实际的应用中效果却不是很好，因为利用一份数据表中的env字段实现环境隔离，所以线上和线下对应的Resource Plan和Activity Plan关系表中关联的实体ID不同，那么将无法实现线下配置直接拷贝到线上，此时需要在线下和线上两次配置，由于配置过于复杂增加错误风险。

下面介绍第二个方案，第二个技术方案中对方案一中提出的问题进行优化。具体的设计如下图所示：

如上图所示，实体对象由6个转换为4个，下面一次介绍这些实体和如何解决环境隔离问题。

首先介绍新引入的Data Schema实体，DataSchema是由开发同学负责，提供了一个配置好的JSON配置模板，他与Resource进行关联，意味着当前Resource下的所有DataSource都将按照该DataSchema提供的JSON模板进行配置，同时在解析时也按照当前的DataSchema进行解析。

Resource不再区分线上和线下环境，因为Resource无论是线上和线下他总是存在的并且不会改变的，所以区分线上和线下是没有必要的。

DataSource不再用env字段区分线上和线下环境，利用preData和onlineData进行区分线上和线下配置，由于引入了DataSchema模板，所以彻底解放了DataSource，他不再需要进行繁琐的配置，只需按照DataSchema把所有的需要字段都配置到对应的Schema中即可。这样在线上和线下DataSource是一条数据主键不再改变。

Activity实体是DataSource和Resource的关系实体，同时包括活动的人群、起止时间等属性。由于DataSource和Resource实体线上和线下环境中主键ID都不会改变，那么意味着Activity可以把线下的配置直接同步到线上，在同步过程中需要做的是如果线上没有配置就插入一条如果存在就更新。那么怎么映射Activity线下和线上的关系呢，在Activity里面引入了mapId字段，线下的Activity实体在mapId中存储线上Activity实体的主键Id，利用这种映射关系实现了线下和线上的映射。

具体的如上图所示，通过这种表和表之间映射关系，实现了环境隔离问题，同时简化了业务中的实体，让配置更简单更易用。

在实际应用中，我们遇到了检索能力的性能瓶颈，根据每次检索时都需要拉出当前资源位下的全部活动，然后按照起止时间、人群作为过滤条件，筛选出满足当前用户的活动列表。以上过程中每次检索都会发生与数据库的IO操作。当资源位和访问QPS增多时，数据库IO操作将成倍数增长，此时会成为检索的瓶颈，所以在以上的技术方案中，需要一个完备的缓存方案支撑检索的正常运行。按照常规的缓存设计方案进行了如下的缓存方案设计。

所有的查询都是先进行缓存查询，如果未命中再查询数据库，把查询到的数据回写到缓存中。对于所有的更新操作，都是先更新数据库，然后再失效缓存，在更新活动时，需要在失效活动缓存的同时，也要失效该活动对应资源位下活动列表的缓存。

但是在使用过程中遇到了一个问题，资源位下的活动列表存储采用了kv结构，key为资源位ID，value为活动列表的JSON序列化，当资源位下的活动增多时value也会随着膨胀最后超出阈值，所以把活动对象进行了简化仅存储活动Id和人群Id。优化后检索过程将有所变化如下图所示：

通过以上的整体功能设计、技术方案设计、代码实现，介绍了一个投放平台从设计到实现过程中遇到的问题点和解决方案。目前投放平台已经在闲鱼的用户实时触达、首页feeds投放、淘宝闲鱼小程序投放中使用，完美支持运营根据人群精准投放活动。

闲鱼素材投放平台但仍有需要持续完善的地方，首先是精准人群的个性化，例如在首页的投放中，针对圈选的人群透出的Banner图片都是一样的，目前我们的投放最小粒度是人群未来将会做到个人。然后是投放能力自优化，目前活动针对资源位的争夺还是利用权重、人群、起止时间作为前置条件，未来将会通过投放数据回流利用算法计算其关键指标实现投放的自优化。同时闲鱼素材投放将对接集团内部的更多优秀的素材提供源丰富闲鱼的活动。