一、背景：
在用户打开电商购物等app时，经常会需要给用户推荐匹配的商品。那这样一个流程是如何完成的呢？
1.离线推荐
基于hive离线表的数据，提前计算好用户的偏好信息，整理逻辑相对简单，但是推送的商品转换率会相对较差
2.实时推荐
接入用户实时点击、浏览日志信息写入到kafka，flink 接入kafka 消息数据，做一些特征的加工，结合算法模型做一个偏好识别，实时进行推荐商品
显然第二种方案：实时推荐更加精准，商品转化率也更好
能看到实时推荐对于整体的商品转换率是有一个极高的提升的，但是整体架构也比较复杂，如果当中设计到部分指标数据的计算，那更是令人头疼，因为这种推荐场景是为线上服务，对于时效性要求极高，包括数据指标计算和接口服务的输出，整体RT要求可能在几十ms以内，而且qps也不低。
那如何能在保证推荐的准确性的同时，还能满足这种高时效性、高QPS要求，对于实时数据开发人员提出了极高的要求？
二、解决方案
在京东的实时计算架构演进之路当中，已经详细介绍了三种方案的优缺点：mysql方案、flink方案、olap方案。参考：https://blog.csdn.net/weixin_43291055/article/details/105125418
这里重点探讨下Flink方案和OLAP方案。
(1)OLAP方案
支持即席查询，能够支持多维度复杂查询。
根据数据量的大小，和查询条件的复杂度，查询耗时在几十毫秒到几百毫秒，甚至秒级不等。
(2)Flink方案
直接提Kafka消息，进行计算，将计算结果redis或者Hbase当中，对线上提供服务，整体耗时可以优化到几十毫秒左右。
三、总结
对于线上推荐场景这种系统来说，高QPS、低RT的要求，显然基于Flink直接计算这种场景来说，更加合理。Flink接Kafka消息，直接进行统计，将结果指标存储在redis或者hbase 中，对外提供数据服务。
