实时系统搭建方案

实时系统对一个业务成熟的大公司来说是必不可少的，当离线特征做到一定程度后，效果就很难提升了，当离线模型做到一定程度后，效果也是一样，所以实时特征、实时模型(在线模型)都是后续的一个产物，对提升业务效果有着很大的作用

一、实时系统的两大分类、意义

实时系统一般分为两大类

1：其中一类是实时特征组成的实时系统

2：另一类是实时特征可有可无，但是线上预估系统的模型在一天中会间隔一小段时间就进行更新一次，也叫实时预估

这两种架构各有优点，也各有适用范围，需要根据不同的业务进行选择。如果是像外卖系统，比如我们国内三个外卖APP，饿了么、美团，这种业务场景下实时特征 + 在线更新模型 就都是需要的，因为外卖这种业务是一种实时行为非常强的业务，用户在一小段时间可能就想吃什么东西，很容易在系统中的行为反应出来，要是我们能够拿到这样的行为特点，用一些实时特征进行表达，那么预测效果会非常的好，并且如果能够让预估模型也能实时进行拟合这种行为，那么预估模型将表现得非常好。

如果像是电商这种业务，比如现在很火的拼多多的搜索业务中的一些特定版块，那么就只有实时特征的需求，而不用做到实时更新模型，不像大版块里面的业务变动情况很快，特定版块里面进去的人很少、产生的用户行为也少，而且商品的变换情况不是那么快，那么实时特征就够用了。

二、我重点介绍一些公司级别实时系统中-实时特征是如何产生的

这一部分-从0到1的一个构建过程，下面我用淘宝、天猫电商里面的一个简单实时特征来举例 --- 提取用户过去1小时、24小时XX特征来进行举例

举例：用户过去1小时、过去24小时购买了多少次的商品

1：离线调研阶段

因为设计到过去1小时，过去24小时用户的行为数据，在线下拼接含有实时特征的样本时，一般是要按照天进行拼接，一天的数据中存在0点的数据，这些0点的数据也要提取过去1 24小时的，所以需要多加1天，也就是需要连着存两天的用户购买序列

具体的存法应该是userid作为key，这个用户这两天的点击序列为value，存在hive表中

在设计离线方案的时候，还需要兼顾到线上的方案，线上的时候也需要保证同样的格式在redis中存储。这样线上线下可以用同一套的“特征处理”函数

2：上面的redis里的数据如何产生

3：离线快照阶段

之所以需要离线快照阶段，是因为上面的离线方案是一个实时行为非常强的一个行为，在时间上不会存在误差，但是线上一般会有几秒的延迟，所以线下就相当于穿越了

还有一点是因为用户可能在打开某个页面之后停留一段时间才发生点击行为，如果点击、购买数据的时间戳用的是点击、购买时间的话，这样就导致线上、线下同一条样本的实时特征不一致

这些问题都可以用离线快照的方式进行解决

那么离线快照是什么？

就是在落日志的时候，将线上的实时特征随着样本日志一起写到hdfs中！

4: 什么是实时系统中的热启动和冷启动

冷启动：就是上面说的先离线探索特征，拼样本 做模型 看效果，然后再在线上实时做出来进行打分预测

热启动：省略上面的离线探索，直接在线上预估打分的时候就把这次要加的“新的实时特征”拼出来，只不过模型中没有这个特征，所以不影响打分，然后把这些实时特征离线快照下去，，，之后再用这些特征训练模型

未完待续.....