作者介绍：雷小平，腾讯神盾推荐系统负责人，带领神盾团队多次获得公司级各种奖项。
本次分享是神盾推荐系统中针对快数据应用场景的架构介绍，分为数据计算和数据分发两个部分。
第一部分：综述
QQ大数据团队服务于QQ生态里种类繁多的产品，在这些产品中存在大量的个性化推荐场景。以下图左边的页面为例，在手Q安卓某版本上有超过600个类似这样的页面可以做个性化推荐；除此之外，腾讯云还对接了非常多的企业客户，而这些客户也有大量的个性化推荐的诉求。
基于这样的背景，团队以通用和开放的出发点打造了神盾通用开放推荐系统。它的目标是让业务工程人员可以更快的接入推荐系统，让业务算法人员可以更快进行新算法/特征的迭代。
下面是一些典型接入产品的效果展示
本文主要介绍的是神盾推荐上快数据计算的实现。
那什么是快数据计算呢？我们最近在孵化一个短视频的产品，相信有同学也有听过：微视。比如小明在微视上看了一个小鲜肉土豪在撒钱的视频，这个对推荐系统来说意味着什么？首先，这个视频不能再推给小明了，其次小明可能会喜欢类似的视频，这个响应需要是秒级的。如果这个视频之前不在推荐列表里面，可以把这个视频添加到推荐列表里面，另外这个视频也可以推给类似兴趣的用户，这个响应需要是分钟级别的。这些场景都是快数据计算中的应用场景。
所以快数据计算在推荐系统中，就是实时推荐 近线推荐。因为在架构设计中，很多的服务都可以共用，所以把这两块放到了一起，统称快数据计算。
下面是两个快数据计算应用的效果展示：
第二部分：快数据计算平台
神盾推荐的数据训练模式由于是周期性，对于数据和模型的更新都没法满足实时性。
所以针对快数据应用的场景，设计并开发了quicksilver系统。下面这张图是快数据计算的架构图，按照数据的流转流程把整个计算分成了“收，算，存，用”四个子的模块。
最左边的是“收”，它主要考虑的是协议标准化，这样可以自动化的做很多事情，比如自动构建特征，甚至是模型。其次是数据的复用，如果是要做多件事情，比如既要做实时训练，又要曝光衰减，都由它统一转化，数据始终只有一份。
往右边走的第二个模块是“算”，这个也是整个快数据计算中最核心的模块，算指的是从原始数据流到有效数据的处理过程，大致可以分为三种类型，第一种是推荐池子的计算，也可以说是召回层，现在的推荐产品一般比较复杂，可供推荐的物品也会比较多，所以需要通过召回做一层初筛，这里面有很多种策略，比如通过用户行为，搜索关键字，热度，相似度等等。第二种是对特征的实时计算，一般分为行为类的特征和统计型的特征，而为了让系统的灵活性更高，这里也可以支持规则引擎，对特征生成的规则做自定义。只要把输入输出的格式规定好，这里可以做得非常灵活。第三种就是训练的实时化，这块下面我会详细介绍。
第三个模块是“存”，我们把一些读写频率稍低，并且数据大小非常大的数据类型存在远程的KV，比如redis这种系统，而把一些size不太大，并且数据相对比较小的数据类型放到计算机器的本地cache。这套系统的设计还有一个好处，就是通过存这个模块，把计算和应用接耦合，相互之间可以灵活替换。
最右边的就是“用”了，在召回，精排和重排中，都会应用起来。
最后，最下面还有一个管理系统的模块，整套快数据的交互都可以通过一个可视化的页面来操作，降低用户的使用门槛。
讲完整个快数据计算的架构，接下来会给大家介绍最重要的一个模块，实时训练。实时训练主要包含三个流程：simpleserver负责样本的处理，joinserver负责特征的拼接，生成训练所需要的输入数据，给到trainningserver训练，然后训练结果给到模型评估，当评估结果达到上线标准，再将模型输入到线上。
实时训练中的，首先要解决的是采样，这里选用了lex/yacc作为规则引擎，用于自定义样本生产规则，方便灵活扩展。
在正负样本选取上面有三个trick。在样本存储之后，将存储结果拆分成有三个单元的滑动窗口，分别负责样本判断，样本输出和模型评估；而样本输出的时候，需要控制速度匀速。
第二步是特征拼接，将用户，物品和特征链接起来。
特征拼接方面做了两个主要的优化，分别针对同一个场景有多个模型训练，以及同一个用户多次拼接。
数据准备好了之后，第三步就是训练。选用的是常用的FTRL作为优化器，除了基本的训练流程之外，在结果上线之前还增加了一个模型评估的模块，尽量不让坏模型对线上造成影响。
针对原始的FTRL，我们做了一些优化，首先是保证模型有更好的稀疏性：
其次是解决模型启动时收敛过慢，以及模型抖动的问题：
还有增加新样本对模型影响的权重:
最后还有一些训练时的trick，比如增加正样本的权重等。
实时的模型还可以用在重排层，比如多臂老虎机以及强化学习等场景
另外，还尝试了FTRL作为DNN的输入的方式，对效果也有一定的提升
第三部分：快数据分发SSM
快数据分发主要指的是大小在K到M级别的一些计算过程中需要使用的数据，而且访问频次非常高，不适合放到远程的nosql，所以针对这个场景实现了一个快数据分发系统SSM。解决5个主要的问题：
（1） 满足高频读写的需求
（2） 数据格式不一致兼容
（3） 数据快速下发
（4） 计算节点中数据版本的一致性
（5） 模型回滚
整个系统的架构图如下：所有数据存在HDFS中；将更新任务的元数据存储在一个分布式的mysql系统CDB中；由server集群负责所有数据更新任务的调起；每个计算节点上有一个数据同步的AGENT，负责从server接受数据，最后把数据放到本地共享内存，供模型计算进程使用。Server跟agent都是无状态的，可以任意重启，所以整个系统没有单点，比较好的解决了上面遇到的这些问题。
以上是神盾在快数据处理上的经验和沉淀，希望未来得到更多的建议，帮助我们更好改进工作。
