推荐系统三十六式学习笔记：工程篇.常见模型27|巧妇难为无米之炊：数据采集关键要素

推荐系统离不开数据，数据就是推荐系统的粮食，要有数据就得收集数据。在自己产品中收集数据，主要还是来自日志

日志和数据

数据驱动这个概念也是最近几年才开始流行起来的，在古典互联网时代，设计和开发完全侧重于功能易用和设计精巧上，并且整体驱动力受限于产品负责人的个人眼光，也因此对积累数据这件事不是很重视。

管局数据采集,按照用途分类又有三种：
1.报表统计
2.数据分析
3.机器学习

当然，这三种的用途并不冲突，反而有层层递进的关系。最基本的数据收集，是为了统计一些核心的产品指标，例如次日留存，七日留存等，一方面是为了监控产品的健康状态。一方面是为了对外秀肌肉，这一类数据使用非常浅层，对数据的采集要求也不高。

第二种就是比较常见的数据采集需求所在了。在前面第一种用途基础上，不但需要知道产品是否健康，还需要知道为什么健康、为什么不健康，做对了什么事、做错了什么事，要从数据中去找到根本的原因。

数据分析工作，最后要产生的是比较清晰直观的结论。它主要用于指导产品设计，指导商业推广、指导开发方式。走到这一步的数据采集，已经是实打实的数据驱动产品了。

第三种，就是收集数据为了机器学习应用，或者更广泛地说人工智能应用，主要在消化数据的角色是算法，是计算机而不是人。

所以在数据采集上，可以说多多益善，样本是多多益善，数据采集的维度，也就是字段数多多益善，但另一方面，数据是否适合分析，数据是否易于可视化地操作并不是核心的内容。

当然，实际上在任何一款需要有推荐系统的产品中，数据采集的需求很可能要同时满足上述三种要求。

下面我就开始给你详细剖析一下为推荐系统收集日志这件事。

数据采集

给推荐系统收集日志这件事，依次要讨论的是：日志的数据模型，收集那些日志，用什么工具收集，收集的日志怎么存储；

1.数据模型

数据模型是什么？所谓数据模型，其实就是把数据归类。不同的数据应用，数据模型略有不同。

就推荐系统而言，推荐系统要做的事情就是预测那些最终会建立的人和物之间的连接，依赖的是已有的连接，以及人和物的属性，而且，其中最主要的是已有的连接，人和物的属性只不过是更加详细描述这些连接而已。

数据模型帮助梳理日志、归类存储，以方便在使用时获取。这些推荐算法形形色色，但是他们所需要的数据可以概括为两个字：矩阵。

再细分一下，这些矩阵就分成了四种。

基于这个分析，可以给要收集的数据归纳成下面几种：

接下来就是去收集数据了。收集数据，就是把散布在各个地方的数据聚拢，也包括那些还根本没有记录的数据的地方开始记录。

2.数据在哪？

按照前面的数据模型，我们一起来看一下要收集的数据怎么产生的。主要来自两种，一种是业务运转必须要存储的记录，例如用户注册资料，如果不在数据库中记录，产品就无法正常运转。

另一种就是在用户使用产品时顺便记录下来的，这叫做埋点。第一种数据源自业务数据库，通常都是结构化存储，Mysql。第二种数据需要埋点，埋点又有几种不同方法。

第一种SDK埋点。这是最经典古老的埋点方法，就是子啊开发自己的APP或者网站时，嵌入第三方统计的sdk。sdk在要收集的数据发生点被调用，将数据发送第三方统计，第三方统计得到数据后再进一步分析展示。

这种数据收集方式对推荐系统的意义不大，因为得不到原始的数据而只是得到统计结果，我们可以将其做一些改动，或者自己仿造一些开发内部数据采集SDK，从而能够收集到鲜活的数据。

第二种，可视化埋点。可视化埋点在SDK埋点基础上做了进一步工作，埋点工作可视化配置的方式完成，一般是在APP端或者网站端嵌入可视化埋点套件SDK，然后再管理端接收前端传回的应用控件树，通过点选和配置，指令前端收集那些事件数据。

第三种，无埋点。所谓无埋点不是不埋点收集数据，而是尽可能多自动收集所有数据，但是使用方按照自己的需求去使用部分数据。

SDK埋点就是复杂度高，一旦埋点有错，需要更新客户端版本，可视化埋点的不足就是：收集数据不能收集到非界面数据，例如手机里点击事件，也仅仅能收集一个点击事件，却不能把更详细的数据一并返回。

上面是按照技术手段分，如果按照收集数据的位置分，又分为前端埋点和后端埋点。

这两个区别是这样的，举个例子，要收集用户的点击事件，前端埋点就是在用户点击时，除了响应他的点击请求，还同时发送一条数据给数据采集方。
后端埋点就不一样了，由于用户的点击需要和后端交互，后端收到这个点击请求时就会在服务端打印一条业务日志，所以数据采集就采集这条业务日志即可。

对于推荐系统来说，所需要的数据基本上都可以从后端收集，采集成本较低，但是有两个要求：要求所有的事件都需要和后端交互，要求所有业务响应都要有日志记录。这样才能做到在后端收集日志。

后端收集日志好处很多，比如下面几种：
1.实时性。由于业务响应是实时的，所以日志打印也是实时的，因此可以做到实时收集。
2.可及时更新。由于日志记录都发生在后端。所以需要更新可以及时更新，而不用重新发布客户端版本。
3.开发简单。不需要单独维护一套SDK.

归纳一下，Event类别的数据从后端各个业务服务器产生的日志来，item和user类型数据，从业务数据库来，还有一类特殊的数据就是Relation类别，也从业务数据库来。

3.元素有哪些？

后端收集事件数据需要业务服务器打印日志。需要打印哪些信息才算是一条完整的事件数据呢？大致要包含下面几类元素。

1.用户id,唯一标识用户身份。
2.物品id,唯一标识物品。这个粒度在某些场景中需要注意，例如电商，物品的id就不是真正去区别物和物之间的不同，而是指同一类，比如我指的不是区分这本三国演义和那本三国演义的不同，只需要区分开三国演义和红楼梦不同就可以。
3.事件名称，每一个行为一个名字。
4.事件发生时间，时间非常重要。

以上是基本的内容，下面再说说加分项。
1.事件发生时的设备信息和地理位置信息等等；
2.从什么事件而来；
3.从什么页面而来；
4.事件发生时用户的相关属性；
5.事件发生时物品的相关属性。

把日志记录想象成一个live快照，内容越丰富越能还原当时的场景。

4.怎么收集？

一个典型的数据采集架构如下图所示：

下面描述一下这个图。最左边就是数据源，有两部分，一个是来自非常稳定的网络服务器日志，nginx或者Apache产生的日志。这类日志对推荐系统的作用是什么呢？

因为有一类埋点，在pc互联网时代，有一种事件数据收集方式是，放一个一像素的图片在某个要求采集数据的位置。这个图片被点击时，向服务端发送一个不做什么事情的请求，只是为了在服务端的网络服务器那里产生一条系统日志。这类日志用logstash收集。

左边另外的数据源就是业务服务器，这类服务器会处理具体场景的具体业务，甚至推荐系统本身也是一个业务服务器。

这类服务器有各自不同的日志记录方式，例如java是log4j,python是logging等等，还有RPC服务。这些业务服务器通常会分布在多台机器上，产生的日志需要用Flume汇总。

kafka是一个分布式消息队列，按照Topic组织队列，订阅消费模式，可以横向水平拓展，非常适合作为日志清洗计算层和日志收集之间的缓冲层。

所以一般日志收集后，不论是Logstash还是Flume，都会发送到kafka指定的Topic中。

在kafka后端一般是一个流计算框架，上面有不同的计算任务去消费kafka的数据Topic，流计算框架实时地处理完采集到的数据，会发往分布式的文件系统中永久存储，一般是HDFS.

日志的时间属性非常重要。因为在HDFS中存储日志时，为了后续抽取方便快捷，一般是要把日志按照日期分区，当然，在存储时，按照前面介绍的数据模型分不同的库表存储也能够方便在后续构建推荐模型时准备数据。

5.质量检测

数据采集，日志收集还需要对采集到的数据质量做监控。推荐系统作为数据的使用方，虽然不同重点关注如何保证数据质量，但是需要能都发现数据质量问题。

关注数据质量，大致徐璈关注以下几个内容。
1.是否完整？事件数据至少要有用户id、物品id,事件名称三元素才算完整，才有意义。
2.是否一致？一致是一个广泛的概念。数据就是事实，同一个事实的不同方面会表现成不同数据，这些数据需要互相佐证，逻辑自洽。
3.是否正确？该记录的数据一定是取自对应的数据源，这个标准不能满足则应该属于Bug级别，记录了错误的数据。
4.是否及时？虽然一些客户端埋点数据，为了降低网络消耗，会积攒一定时间打包上传数据，但是数据的及时性直接关系到数据质量。由于推荐系统所需的数据通常会来自后端埋点，所以及时性还可以保证。

总结

数据是推荐系统做饭的米，没有数据就没有推荐策略的落地，因此采集数据是一个非常重要的工作。

采集数据需要首先梳理好自己的数据有哪些，是看推荐系统需要哪些数据。

我把这些数据全部看成了矩阵，有了矩阵，无论是内容推荐还是系统过滤，矩阵分解，还是机器学习深度学习，就都有了输入。

我总结了推荐系统需要的四种矩阵，对应四种数据，列表如下：