ToB企服应用市场:ToB评测及商务社交产业平台

标题: 及时保举算法的架构 [打印本页]

作者: 立聪堂德州十三局店 时间: 2024-11-14 14:21
标题: 及时保举算法的架构
1. 及时保举算法的架构设计

偷得浮生半日闲，跟各人一起聊一聊各人最喜欢的及时保举算法架构，具体如图1.1，架构的详解则见下一章节《2. 及时保举算法架构设计详解》。

图 1.1 及时保举算法的架构设计
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数据库。
表2.5.1 算法结果集核心数据列用户ID商品IDRank1a1zAA11a1zBB26t7uCC1 2.6 算法结果集应用

算法的最闭幕果聚集应用，自然是将算法结果通过API透传给到客户端，客户端前端根据算法给到的用户ID，商品ID，Rank(用户对商品的喜欢排名)给到每个用户对差别商品的瀑布流曝光，从而实现千人千面的保举算法结果，固然为了加快查询速度，通常假如算法结果集在MySQL的话，会再MySQL和API之间加一层Redis缓存。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)