推荐系统是基于对历史的数据进行推测。数据是推荐系统的源头，数据怎么来？要有数据就要进行数据采集，数据的采集主要来源是日志，日志是用户在网站上产生的一些行为信息，这是我们获取数据的重要来源。

1、系统架构流程图

在大数据场景中，用户在手机APP端或页面输入一个网址，是在对应的浏览器输入，这时就会向后端服务器发送一个HTTP请求。
例如，我们输入 baidu.com 网址，那浏览器就会向服务器发送我们有关于网址的HTTP请求，接着服务器接受请求会进行返回，浏览器给用户进行结果展示。在浏览器加载页面时候，会进行一个埋点。

页面展示的数据，我们是要进行记录，记录到日志服务器，服务器在后端其实就是个logs日志文件。日志会记录很多信息，例如用的浏览器、时间、网址ID，topic、用户行为等等。

事实上，我们数据来源有很多不同的结构，我们要对不同的数据进行收集、整合，我们常用Flume进行数据的传递、收集。当数据传递过来时候，我们是要进行备份的，因此 Flume的数据会备份到HDFS中，当数据存到HDFS时候，我们会进行ETL处理(常用hive、spark处理)，把处理好的、清理过的、规范化的数据存到数据仓库中。

2、离线处理

在数据仓库中，我们存储的数据是历史数据，我们要挖掘数据的价值，显示数据的作用。例如，进行数据的模型训练，进行数据分析的报表，可视化展示等等。这些操作都是离线操作。

我们通过模型训练，通过离线训练得出模型model，通过封装模型到后端服务中，进行线上应用。一般离线训练好的model放在redis，以向量形式存储；model一般会部署在后端工程(服务器) ，进行一些数据的预测，估计结果。

例如，线上来一条数据，我们放到model进行预测，进行打分，看这个数据在那个类别的分数(概率)高，就预测出这个数据属于哪一个类别。
很多数据经过model后，根据返回的概率大小进行排序，把前几\Top5，的商品结果进行返回给用户，这些Top5的商品就是用户喜好的或者是经常买的。

这就是我们数据仓库涉及到的部分。

3、实时在线

进行数据开发或者后端想做一个在线产品，那在线的数据怎么来，在数据经过Flume收集时，对刚收集到的数据我们要进行一个短期的存放—— kafka，而且，kafka的数据来源不单单从Flume，还可以从日志服务器、后端的服务器获取。

当数据到达kafka后，我们可以用 spark streaming、Flink、Storm进行一些流式处理。处理过后的数据可以存储到MySQL中，后端服务器还可以从MySQL进行数据的调用，亦然后端服务器也可以把数据存到MySQL(redis\Hbase)，这是一个双向的过程！！

Flume --> Kafka --> spark streaming --> MySQL(Redis\Hbase) <–> 服务端

这是一个数据实时处理的部分。(下图方框为蓝色部分)

我们可以理解Flume收集到数据为自来水，kafka 那就是一个蓄水池(可存可放)，可以源源不断地放水给 spark streaming使用。

4、职业定位

假如我们从事：数据仓库方向，我们要主攻离线处理部分(上图画红色区域)
假如我们从事：数据开发方向，就是在线实时处理部分。

在浏览器 ->日志服务器 ->Flume 这个一般成熟的平台是是封装好的。

模型训练 -> model ->redis <->服务器，这个是机器学习、算法涉及到的。

用户 -> 页面 ->浏览器 是前端专业涉及到的，例如埋点。

页面涉及的是UI专业涉及到的。

后端服务器开发，是后端专业涉及到的。

在我们学习的过程中，我们的侧重点要找好。

5、数据采集用途

数据采集后可以做BI报表，BI报表也就是将企业中现有数据进行整合并提供出的报表。BI报表是现在行业用的最广泛的、成熟的，一个公司报表是必须有的。

• BI报表统计出来最先给PM(产品)，PM可以通过报表推测出哪些策略行哪些效果不行，如果哪些产品通过数据发现是bad，就直接砍掉不做。
• 运营人员是对产品进行一些推广，哪类用户用哪样策略，通过报表看看这批用户能不能达到推广的预期，不行就换用户，这样通过报表就减少损失。
• leader/Boss决策，大佬通过报表进行决策，看经过一段时间的效益有没有达到期待，没有就改变策略。

数据分析：数据分析师通过报表进行数据分析，用SQL、Excel进行。

机器学习：数据挖掘，算法工程师通过报表数据，经过测试看哪些数据是有价值，哪些没价值。

最基本的数据收集，是为了统计最核心的产品指标：

• 常规数据指标的监测：用户量，新用户量，UGC（社交产品），销量，付费量，推广期间各种数据等；
• 渠道分析/流量分析：分析/监控引流渠道优劣；
• 用户的核心转化率：统计付费率，购买率；
• 用户使用时长的监测：用户活跃度，产品验证 ；
• 用户流失情况：监控用户的流失率(1，3，7，30；
• 活跃用户动态：关注活跃用户动态。

这些指标有什么用？
了解指标是最基本的数据采集需求：1、业绩的衡量；2、对接业务的核心点；3、知道经过你手的数据最终有什么用。

报表统计作用：1、为了监控产品的健康状况；2、为了对外展示公司实力(拉投资)。

5.1 数据分析

• 数据分析是比较常见的数据采集需求；
• 对比报表统计的区别：不但需要知道产品是否健康，还需要知道为什么健康、为什么不健康，做对了什么事情、做错了什么事情，要从数据中去找到根本原因。
• 驱动了很多多维分析软件应运而生。
• 数据分析工作，最后要产出的是比较简明清晰直观的结论，这是数据分析师综合自己的智慧加工出来的，是由人产生的。
• 主要用于产品设计、指导商业推广、指导开发方式。
• 实打实的数据驱动产品。

5.2 机器学习

• 收集数据为了机器学习应用，更广泛地说人工智能应用；
• 区别于数据分析：主要在消化数据的角色是算法、是计算机，而不是人；
• 在采集的维度（字段），样本数量都希望越多越好；
• 注意：这里的数据是否适合分析，数据是否易于可视化地操作并不是核心内容；
• 指标举例：用户(物品)特征描述：算法建模上，和产品上使用，用户(物品) 生命周期的监测：在建模上需要考虑。

6、数据采集日志

6.1 数据模型

• 数据模型，其实就是把数据归类。产品越负责，业务线越多，产生的日志就越复杂。
• 不同业务关心的数据不一样，就推荐系统业务来说，关心的是人与物之间的连接，需要依赖已经有的人与物的连接，以及人和物的属性（详细描述）。
• 数据模型有助于梳理日志、归类存储，以方便在使用时获取。
• 数据可以看。

6.2 数据的产生

主要来自两种：

1. 业务运转必须要存储的记录，如：用户填写的注册信息，一般存储在线上的业务数据库 中，通常都是结构化存储，Mysql。
2. 用户在使用产品时顺便记录下来的，这叫埋点。埋点按照技术手段分有几种：
   1、SDK埋点。 这是最古老的埋点方法，就是在开发APP和网站，嵌入第三方统计，第三方统计得到数据后再进一步分析展示。
   2、可视化埋点。 在SDK埋点基础上组做了进一步工作，埋点工作可通过可视化配置。就是在APP或者网站嵌入可视化埋点套件的SDK。
   3、无埋点。 谓无埋点不是不埋点收集数据，而是尽可能多自动收集所有数据，但是使用方按照自己的 需求去使用部分数据。

埋点位置可以分为前端埋点和后端埋点。两者区别在于：

1. 前端埋点： 要收集用户的点击事件，前端埋点就是在用户点击时，除了响应他的点击请求，还同时发送一 条数据给数据采集方。
2. 后端埋点： 由于用户的点击 需要和后端交互，后端收到这个点击请求时就会在服务端打印一条业务日志， 所以数据采集就是采集这条业务日志就可以。
3. 埋点十分复杂，国内有专门解决埋点的公司，比如神策数据，有些工作已经做得很傻瓜化了。
4. 前端埋点的成本高，后端埋点的成本低。

对于推荐业务来说，数据基本上可以从后端收集，采集成本较低（为什么？）

• 后端数据需要有两个要求：
  1、要求所有的时间都需要和后端交互；
  2、要求所有业务响应都要有日志记录。
• 后端收集日志有很多好处，比如：
  1、实时性。由于业务响应是实时的，所以日志打印也是实时的，因此可以做到实时收集；
  2、可及时更新。由于日志记录都发生在后端，所以需要更新时可以及时更新，而不用重新发布客户端版本；
  3、开发简单。不需要单独维护一套SDK。
• Event事件类别的数据从后端各个业务服务器产生的日志来，Item和User类型数据，从业务数据库来，还有一些特殊的数据就是Relation类别从业务数据库来。

6.3 数据源的划分

• 稳定的网络服务器日志：Nginx或者Apache产生的日志。在PC互联网时代，有一种事件收集方式是，放一个一像素的图片在某个要采集数据的位置。这个图片被点击时，向服务端发送一个不做什么事情的请求，只是为了在服务端的网络服务器哪里产生一条系统日志。这类日志用Logstash收集。
• 业务服务器：这类服务器会处理具体场景的具体业务，自不同的日志记录方式。例如Java是Log4j，Python是Logging等等，还有RPC服务。这些业务服务器通常会分布在多台机器上，产生的日志需要用Flume汇总。
• Kafka是一个分布式消息队列，按照Topic组织队列，订阅消息模式，可以横向水平扩展，非常适合作为日志清洗计算层和日志收集之间的缓冲区。不论是Logstash还是Flume，都会发送到Kafka指定的topic中。
• 处理完采集到的数据，会送往分布式的文件系统中永久存储，一般是HDFS，为了后续抽取方便快速，一般要把日志按照日期分区。

6.4 数据采集的质量检测

1. 是否完整？事件数据至少要有用户ID、物品ID、事件名称三元素才算完整。
2. 是否一致？同一个事实的不同方面会表现不同数据，这些数据需要相互佐证。
3. 是否正确？该记录的数据一定是取自对应的数据源，不能满足则应该属于Bug级别，记录了错误的数据。
4. 是否及时？虽然一些客户端埋点数据，为了降低网络消耗，会积累一定时间打包上传数据，但是数据的及时性直接关系到数据质量。

6.5 日志传输

• 无线端产生日志，不是产生一条日志上传一条，而是先存储在客户端（手机）， 然后再伺机上传（会有机制） ；
• 客户端数据上传：
  1、向服务器发送POST请求；
  2、服务器端处理上传请求，做相关校验；
  3、将数据追加到本地文件中进行存储；
  4、存储方式使用Nginx的access_log；
  5、access_log的切分维度为天。

通过文章我们了解：

1. 系统的流程架构，通过架构的模块可以知道职业主攻方向，有利于规划未来。
2. 数据采集的用途，有数据分析、机器学习；
3. 了解数据的模型，日志产生的来源、数据源的划分、质量检查、日志传输等。