这几天打算整理一个模拟真实情景进行广告推荐的一个小Demon， 这个项目使用的阿里巴巴提供的一个淘宝广告点击率预估的数据集， 采用lambda架构，实现一个离线和在线相结合的实时推荐系统，对非搜索类型的广告进行点击率预测和推荐(没有搜索词，没有广告的内容特征信息)。这个感觉挺接近于工业上的那种推荐系统了，通过这个推荐系统，希望能从工程的角度了解推荐系统的流程，也顺便学习一下大数据的相关技术，这次会涉及到大数据平台上的数据处理， 离线处理业务和在线处理业务， 涉及到的技术包括大数据的各种技术，包括Hadoop，Spark(Spark SQL, Spqrk ML, Spark-Streaming)， Redis，Hive，HBase，Kafka和Flume等， 机器学习的相关技术（数据预处理，模型的离线训练和在线更新等。所以这几天的时间借机会走一遍这个流程，这里也详细记录一下，方便以后回看和回练， 这次的课程是跟着B站上的一个课程走的， 讲的挺详细的，就是没有课件和资料，得需要自己搞，并且在实战这次的推荐系统之前，最好是有一整套的大数据环境(我已经搭建好了）， 然后就可以来玩这个系统了哈哈， 现在开始 😉

今天是第一篇，先介绍一下个性化电商广告推荐系统的数据集和基本任务，这样能够在宏观上对整体的方向进行一个把握， 所以这篇文章相对会比较简单些，具体大纲如下：

Ok, let’s go!

本次任务是根据一个淘宝广告展示和用户点击行为的一个数据集， 来做一个这样的系统：

最后系统启动， 我们输入某个用户的ID，即给定某个用户，然后给定广告资源位的位置(就是广告放置的位置）， 推荐系统给我们返回该用户比较可能点击的10个广告回来。

所以这个系统的功能相对来说比较简单，就是一个单纯的广告推荐任务， 当然也不是那么简单， 因为这里要涉及到实时推荐，所以还需要根据之前的用户点击结果对召回的广告进行动态调整， 来更新最后的推荐列表， 比如第一次给328用户推荐了上面这10个广告， 第二次有推荐了10个， 连续五次之后发现他对某些广告并没有进行点击，可能不感兴趣，那第6次推荐的时候就要更新召回列表， 把该广告去掉， 换成新的一些，然后再根据缓存的用户特征和广告特征再进行点击率预测， 再排序和产生推荐等。 这就是实时的一种思路了，后面会具体的介绍这个。 这里做一个初步了解， 然后明白最后这个系统在干个啥事就行了。

知道了这个系统干的事情，我们在看一下这次用的数据集，这次的数据集可以在这里下载，主要有四个数据文件， 分别对应着用户的广告点击行为日志， 广告自身的特征， 用户自身的特征和用户的购物行为，下面一一来解释：

这个是从淘宝网站中随机抽样了114万用户8天内的广告展示/点击日志（2600万条记录），构成原始的样本骨架。 字段说明如下：

这份数据体现的是用户对不同位置广告点击、没点击的情况， 这份数据比较重要，也是我们模型预测的基本骨架，因为我们最后的目标是给用户推荐广告， 而这个任务我们一般是转成一个点击率预测的问题，就是对于某个广告，我们预测用户点还是不点，这是一个二分类的问题，我们最后把点击概率从大到小排序，靠前的一些广告就可以推荐给用户了。 所以单纯的基于这个数据集，其实我们就可以训练一个二分类的模型了，比如逻辑回归，只不过这里面能利用的信息有限，不准而已，所以才说这是原始数据的一个基本骨架。

这里面能用的特征有user_id, adgroup_id和pid，time_stamp当然也能用，可能用处不大。 目标也要清楚，就是用户的点击情况。 后面这两个都体现了用户是否点击的情况，这里之所以给了两个，是因为这里是真实情况的日志， 真实情况下是要同时记录点击和未点击情况的， 真实场景下，一般是给用户曝光一些广告， 然后看看用户是否点击，如果用户点击了， 那么点击那里是1， 未点击是0， 但是大部分情况下用户是不点广告的，这时候未点击是1， 点击是0，如果仅用点击情况的话，可能就不知道究竟给用户曝光了多少广告了(万一再稀疏存储，更不知道了)。 所以这两个合起来才可以标记给用户曝光的广告情况，当然制作label的时候，我们只用一个即可。

由于上面可以利用的用户特征和广告特征有限， 直接训练模型的话很可能不准，所以还需要看看其他的数据集。

本数据集涵盖了raw_sample中全部广告的基本信息(约80万条目)。字段说明如下：

这个表体现的是每个广告的类目(id)、品牌(id)、价格特征，其中一个广告ID对应一个商品（宝贝），一个宝贝属于一个类目，一个宝贝属于一个品牌。这个就是广告的特征了， 我们用的时候，可以根据广告id直接拼接到骨架上面。

本数据集涵盖了raw_sample中全部用户的基本信息(约100多万用户)。字段说明如下：

这个表体现的是用户群组、性别、年龄、消费购物档次、所在城市级别等特征，这个是用户的特征， 其中用户的性别，年龄， 消费档次，是否大学生等感觉都能关联到是否点击某广告，可能是强特。这个也是根据用户id直接拼到骨架上面去。这里还有一点需要说明就是由于这个是比赛的数据集， 有些数据特征人家已经清洗好了并进行了相关的LabelEncoder编码， 省去了我们的一些工作， 但是真实场景的数据集这些东西都是没有的，我们一般需要拿到数据后做一波数据清洗。

有了用户画像特征， 广告画像特征， 然后再基于骨架， 其实就可以训练一个逻辑回归这样的模型对点击率进行预测了，But， 真实情境中，我们的候选广告是非常多的， 动不动就是几百万几千万的规模，如果我们对于某个用户，直接就用逻辑回归模型去一个个算的话， 这个计算量可是不得了。并且还有一个弊端就是这里面可能有大量的广告压根就和用户扯不上边， 我们直接这样搞，会白白浪费时间和资源。

所以真实情况中，我们一般在精确预测之前，会加入一个召回的步骤， 就是根据用户的一些购买行为先召回回来一些和用户扯上边的广告， 这样至少扯上边，和用户发生过一些关系，这样的话，我们就可以重点考虑这样的一些商品了， 这样，往往能从几百万的规模降到几百的规模，这时候，我们再用逻辑回归等精排预测就可以了呀。 写到这里突然又让我联想起了信息熵和不确定性的关系了哈哈，有没有发现和这里很像呀， 信息的作用在于消除不确定性， 如果一开始发现不确定性很大，我们就想办法加入更多的信息，召回的作用原理也和这个原理很像呀。所以一般是先召回，再排序的流程。

那么对于这个任务应该如何召回呢？ 哈哈， 果真，这里也提供了一个用户的行为日志表， 这个表就记录了和用户的“发生过关系”的广告信息了。

本数据集涵盖了raw_sample中全部用户22天内的购物行为(共七亿条记录)。字段说明如下：

这里以user + time_stamp为key，会有很多重复的记录；这是因为我们的不同的类型的行为数据是不同部门记录的，在打包到一起的时候，实际上会有小的偏差（即两个一样的time_stamp实际上是差异比较小的两个时间）

这份数据体现用户对商品类目(id)、品牌(id)的浏览、加购物车、收藏、购买等信息，有了这个表，其实我们就可以在排序之前，先做一些召回的工作了，只不过有两点需要说明，

有用户id， 又有cat_id和评分数据， 我们其实就可以利用简单的协同过滤先做一波召回， 找到候选商品， 再映射出候选广告。 然后在考虑精排，来一个精准预测。

关于流程其实上面分析的差不多了， 这里再简单总结一下。

首先明确我们的任务是对非搜索类型的广告进行点击率预测和推荐(没有搜索词、没有广告的内容特征信息)。

我们依赖的数据骨架就是用户的点击日志行为表，为了预测的更加准确， 再拼接上用户和广告的一些信息。而由于我们的候选广告太过庞大，所以我们还要先用到用户购物的历史行为信息做召回，找一波候选广告， 然后再进行排序，最后规律和产生推荐结果。

所以这样就梳理出了， 推荐业务处理主要流程： 召回 ===> 排序 ===> 过滤。之前也接触过一个新闻推荐的项目，也是采用的这种流程，感兴趣的可以参考Datawhale组队学习的第19期内容(那次重点放在了各个流程用到的主要方法上)。 这次的推荐系统更加偏向工程化一些， 也就是用到了大数据平台，用到了离线和在线相结合的推荐方式。 用一张图来表示就是这样：

可以很清楚的看到，这次基于了大数据的框架平台，分为了离线和在线两部分，下面梳理一下离线处理业务流如下：

简单的解释就是先离线业务流走一遍上面的那个流程， 先处理用户的历史行为数据， 然后得到评分数据， 然后基于协同过滤进行召回得到候选的商品类别， 然后再去关联广告，得到候选的广告。

然后就是再基于点击日志，广告和用户特征训练点击率预测的相关模型，对于候选的广告做一个点击率的预测，得到一个点击概率（注意这里我们要软概率，不能转成0和1，毕竟对于点击广告来讲，类别会极度不平衡）， 然后根据这个点击概率从大到小排序， 形成推荐列表（注意这个是线下的推荐列表，一成不变了）

完成上面的离线之后，我们要缓存用户特征和广告特征，然后形成在线处理业务流如下：

这里也简单的说一下， 如果单纯的靠离线推荐的话，可能会忽略一些时效性的东西，毕竟离线推荐完毕之后存在数据库一成不变了，没法根据用户的行为改变或者广告的改变而改变推荐结果， 这样难免会使得结果过时。 所以在线更新的思路就是基于用户新的购买日志或者记录来更新召回的商品类别或者品牌，然后映射出新的候选广告，由于之前缓存了广告的特征和用户特征， 所以基于这些又此形成新的数据对模型测试，然后得到点击的广告概率，排序产生新的结果。这次的结果加入了新的信息， 可以对推荐结果进行实时的调整，以符合用户的兴趣和品味。 这里用《数学之美》的一句话来解释就是信息量代表着不确定性的大小，信息量越大，不确定性就越小，熵就越小，我们就越容易搞清楚。

好了， 这里已经把基本的业务流梳理清楚了， 下面就简单看一下涉及到的技术了，因为是在大数据平台上，所以用到的大部分都是大数据平台相关技术。涉及技术：Flume、Kafka、Spark-streming\HDFS、Spark SQL、Spark ML、Redis

后期会尝试对每个组件的理论进行整理， 这里就先用着了哈哈。在结束这篇文章之前，在了解一下与点击率预测的几个概念。

电商广告推荐通常使用广告点击率(CTR–Click-Through-Rate)预测来实现， 下面看几个概念之间的对比：

点击率预测需要给出精准的点击概率，比如广告A点击率0.5%、广告B的点击率0.12%等；而推荐算法很多时候只需要得出一个最优的次序A>B>C即可。

点击率预测使用的算法通常是如逻辑回归(Logic Regression)这样的机器学习算法，而推荐算法则是一些基于协同过滤推荐、基于内容的推荐等思想实现的算法， 即使用点击率预测， 这种方法也只是完成推荐的方式之一， 并不是唯一。

点击率预测是对每次广告的点击情况做出预测，可以判定这次为点击或不点击，也可以给出点击或不点击的概率

转化率指的是从状态A进入到状态B的概率，电商的转化率通常是指到达网站后，进而有成交记录的用户比率，如用户成交量/用户访问量

搜索中有很强的搜索信号-“查询词(Query)”，查询词和广告内容的匹配程度很大程度影响了点击概率，搜索广告的点击率普遍较高

非搜索广告（例如展示广告，信息流广告）的点击率的计算很多就来源于用户的兴趣和广告自身的特征，以及上下文环境。通常好位置能达到百分之几的点击率。对于很多底部的广告，点击率非常低，常常是千分之几，甚至更低

好了，关于任务数据简介和流程就到这里了，下面我们就开始推荐业务流程的第一步：基于用户的历史行为数据对候选广告进行一个召回了， 开启我们的实战之旅了， Rush 😉