28. 巧妇难为无米之炊：数据采集关键要素.pdfVIP

推荐系统离不开数据，数据就是推荐系统的粮食，要有数据就得收集数据。在自 己产品中收集数据，主要还是来自日志。 日志和数据 数据驱动这个概念也是最近几年才开始流行起来的，在古典互联网时代，设计和 开发产品完全侧重于功能易用和设计精巧上，并且整体驱动力受限于产品负责人 的个人眼光，这属于是一种感性的把握，也因此对积累数据这件事就不是很重视。 在我经手的产品中，就有产品上线很久，需要搭建推荐系统时，却发现并没有收 集相应的数据，或者收集得非常杂乱无章。 关于数据采集，按照用途分类又有三种： 1. 报表统计； 2. 数据分析； 3. 机器学习。 当然，这三种的用途并不冲突，而且反而有层层递进的关系。最基本的数据收集， 是为了统计一些核心的产品指标，例如次日留存，七日留存等，一方面是为了监 控产品的健康状况，另一方面是为了对外秀肌肉，这一类数据使用非常浅层，对 数据的采集要求也不高。 第二种就是比较常见的数据采集需求所在了。在前面第一种用途基础上，不但需 要知道产品是否健康，还需要知道为什么健康、为什么不健康，做对了什么事、 做错了什么事，要从数据中去找到根本的原因。 这种数据采集的用途，驱动了很多多维分析软件应运而生，也驱动了多家大数据 创业公司应运而生。 数据分析工作，最后要产出的是比较简明清晰直观的结论，这是数据分析师综合 自己的智慧加工出来的，是有人产出的。 它主要用于指导产品设计、指导商业推广、指导开发方式。走到这一步的数据采 集，已经是实打实的数据驱动产品了。 第三种，就是收集数据为了机器学习应用，或者更广泛地说人工智能应用。那么 机器学习应用，主要在消化数据的角色是算法、是计算机，而不是人。 这个观点是我在专栏写作之初，讲解用户画像相关内容时就提到的，再强调一遍 就是，所有的数据，不论原始数据还是加工后的数据都是给机器“看”的，而不是 给人“看”的。 所以在数据采集上，可以说多多益善，样本是多多益善，数据采集的维度，也就 是字段数多多益善，但另一方面，数据是否适合分析，数据是否易于可视化地操 作并不是核心的内容。 当然，实际上在任何一款需要有推荐系统的产品中，数据采集的需求很可能要同 时满足上述三种要求。 本文为了讨论方便，不会重点讨论多维数据分析的用途，而是专门看看为了满足 推荐系统，你需要怎么收集日志、采集数据。 因为推荐系统就是一个典型的人工智能应用，数据是要喂给机器“吃”的。 下面我就开始给你详细剖析一下为推荐系统收集日志这件事。 数据采集 给推荐系统收集日志这件事，依次要讨论的是：日志的数据模型，收集哪些日志， 用什么工具收集，收集的日志怎么存储。 1. 数据模型 数据模型是什么？所谓数据模型，其实就是把数据归类。产品越负责，业务线越 多，产生的日志就越复杂。 如果看山是山，一个数据来源一个数据来源地去对待的话，那将效率非常低下， 因此需要首先把要收集的日志数据归入几个模型。不同的数据应用，数据模型略 有不同。 就推荐系统而言，推荐系统要做的事情就是预测那些最终会建立的人和物之间的 连接，依赖的是已有的连接，以及人和物的属性，而且，其中最主要的是已有的 连接，人和物的属性只不过是更加详细描述这些连接而已。 数据模型帮助梳理日志、归类存储，以方便在使用时获取。你可以回顾一下在前 面讲过的推荐算法，这些推荐算法形形色色，但是他们所需要的数据可以概括为 两个字：矩阵。 再细分一下，这些矩阵就分成了四种。 基于这个分析，可以给要收集的数据归纳成下面几种。 有了数据模型，就可以很好地去梳理现有的日志，看看每一种日志属于哪一种。 并且，在一个新产品上线之初，该如何为将来的推荐系统记录日志也比较清楚了。 这个数据模型当然不能概括全部数据，但是用来构建一个推荐系统就绰绰有余了。 接下来就是去收集数据了。收集数据，就是把散布在各个地方的数据聚拢，也包 括那些还根本没有记录的数据的地方要开始记录。 2. 数据在哪？ 按照前面的数据建模，我们一起来看一下要收集的数据会怎么产生。主要来自两 种，一种是业务运转必须要存储的记录，例如用户注册资料，如果不在数据库中 记录，产品就无法正常运转。 另一种就是在用户使用产品时顺便记录下来的，这叫做埋点。第一种数据源来自 业务数据库，通常都是结构化存储，MySQL。第二种数据需要埋点，埋点又有几 种不同方法。 第一种，SDK 埋点。这个是最经典古老的埋点方法，就是在开发自己的 App 或 者网站时，嵌入第三方统计的 SDK ，App 如友