1. 实时推荐算法的架构设计
偷得浮生半日闲，跟大家一起聊一聊大家最喜欢的实时推荐算法架构，具体如图1.1，架构的详解则见下一章节《2. 实时推荐算法架构设计详解》。
2. 实时推荐算法架构设计详解
2.1 数据源
推荐算法的数据源主要来源于两大部分：
- 用户行为的
埋点数据（商品的曝光，点击，喜欢，收藏，转发，加入购物车等），为了数据的高效快速处理，数据存在合理的丢包（少了一条点击并不会有多大影响），但是也要追求尽量别丢，丢多了也会引起产品侧和业务侧的质疑。 - 用交易的
落库数据（商品的咨询，购买等），通常要求遵循数据库事务，即数据一条都不能丢。
2.2 数据消费和集成
埋点数据和落库数据是技术手段上将两大类数据进行了拆分，但是在最后的数据应用侧，并不会单纯的说只用埋点数据或者说只用交易数据，因此需要根据后续投入算法计算的特征工程进行数据源消费后的数据集成；
- 埋点数据消费：依赖于埋点系统的Infrastructure建设，一般的埋点系统会将实时数据存入消息队列如Kafka，则在下游消费时只需要将Kafka的数据进行消费即可；
- 落库交易数据消费：一般的交易型数据落库后存在关系型数据库居多，通常是MySQL，则实时获取数据会用到通用的
CDC(Change Data Capture)技术，需要找一个适配你交易型数据库的CDC技术即可，如FlinkCDC消费MySQL。 - 数据集成：这一步依赖于特征工程的复杂度，如果特征工程较为复杂，则建议加一层Kafka做数据的集成，如果特征工程较为简单的计算，则可以直接数据源消费完后存入特征工程的存储。
2.3 特征工程数据存储
数据消费和集成的本质，就是为了实现特征工程的计算，常见的特征向量有用户特征表，商品特征表，实时特征表等等，特征工程存储可以分为3大类：
- 常规数据量，实时计算处理成特征表存入MySQL，再缓存到Redis，Redis的特征表作为模型训练的input，此处可以到时候做一下压测，如果用户量和商品集打破了这个平衡，则考虑第二类处理方式；
- 如果压测下来Redis满足不了，则分布式NoSQL数据库或者图数据库会是不错的选择，
-
Distribute NOSQL DB (Amazon DynamoDB/Google Cloud Bigtable/Apache Cassandra)：开源建议Apache Cassandra，公有云则Amazon DynamoDB还不错；
-
Graph DB(NebulaGraph)：图数据库运维成本较高，选型需慎重。
但是这些DB一定要适配你的实时流计算引擎，不然数据实时计算后的存储就是跟自己过不去。
- 针对实时变更高频的特征特殊场景（如果有），可以直接消费完写入Redis，不建议写入MySQL再刷缓存，中间的耗能太高；
2.4 算法模型
算法模型就是部署在算法服务器一直Running的等待特征工程输入并得出计算结果的一个或多个程序包，此处通常是用python写的一个或多个算法包，在推荐算法里面，解决的核心问题则是ReRank商品对用户的曝光排序，即将用户最喜欢的但用户自己又不知道的商品推荐给到用户，通常的算法技术有：
- 机器学习
- 深度学习
- 在线学习
- AIGC
- ……
2.5 算法结果集存储
算法集的结果最核心的字段就是：用户ID，商品ID，Rank(用户对商品的喜欢排名)；因此通常是存储在关系型数据库如MySQL即可，当然如果用户量和商品数特别庞大，也可以考虑存入特征工程中提到的分布式NoSQL数据库。
| 用户ID | 商品ID | Rank |
|---|---|---|
| 1a1z | AA | 1 |
| 1a1z | BB | 2 |
| 6t7u | CC | 1 |
2.6 算法结果集应用
算法的最终结果集合应用，自然是将算法结果通过API透传给到客户端，客户端前端根据算法给到的用户ID，商品ID，Rank(用户对商品的喜欢排名)给到每个用户对不同商品的瀑布流曝光，从而实现千人千面的推荐算法效果，当然为了加快查询速度，通常如果算法结果集在MySQL的话，会再MySQL和API之间加一层Redis缓存。
