关于电子商务大数据导购系统设计与实现研究
2022-08-19陈静静
陈静静
（阿里巴巴集团控股有限公司 浙江 杭州 311121）
0 引言
近年来，电子商务以极其迅猛的态势加入了商品零售、推广队列中，各式网购客户端、网络站点层出不穷，为互联网业态的更新和完善注入了新活力，仅2020 年全国电子商务交易额就已达到37.21 万亿元，同比增长率达到4.5%，跨境电商流水也已经达到1.69 万亿元，经营规模明显扩张。但用户群体的扩大、商家总数的上升也为线上运营管理带来了新的难题，商户为尽可能提高份额占比，会在网页上投放大量商品，用户则需要费心费力搜集信息，对比价格、品质等内容，无形之中增加了线上消费成本，如何简化筛选难度、提升导购有效性，就成了诸多线上平台关注的焦点问题。现有的学术研究中通常将“导购”问题拆分为“个性化推荐”“用户购买行为”“检索模型”等[1]，导致研究成果较为零散，缺乏从数据采集至处理、交互的全过程内容，无法为系统设计实践提供明晰思路。基于此，本文汇总已有的数据库算法、主动推荐算法等，深入挖掘系统设计需求和目标，阐述系统整体架构与细节，为电商导购平台的优化提供助力。
1 电子商务大数据导购系统设计需求分析
从需求角度上看，电子商务大数据导购系统实质上是具有辅助决策功能的信息采集、处理、推送平台，可以更加高效地过滤无关信息，提升消费者对商品价格、品质等的认知程度，节约消费时间、成本的同时促成购买行为的发生。因此设计时应以以下几个目标为指引：（1）要能够以导购咨询为依托提升系统交互性，现代网络科技飞速发展，交互性导购方式已经进入到多个客户端平台中，为消费者在线查询、搜集信息提供了便利，因此设计中可以将聊天工具有机植入到动态网页技术中去，用交互性能博取消费者关注，优化其使用体验；（2）要能够以自主学习为途径彰显推荐智能性，这是新型导购系统设计的关键所在，传统导购推荐之所以采纳率不高，就在于其推荐逻辑较为简单、表层，忽略了动态化、关联化的信息挖掘。新系统设计时，可以基于商品内容、关联规则等进行全方位、无死角的异构数据收集、处理，最大限度提升系统智能化水平，保障推荐精准度；（3）要能够以主动服务为平台保障用户忠诚度，良好的导购、推荐服务是维系客户纽带的重要手段，若推荐内容符合消费者预期，帮助消费者简化挑选工序的同时满足了用户内在需求，那么这种买卖关系会更加牢靠。
2 电子商务大数据导购系统整体框架与结构
为保证导购系统运行顺畅度、完整度，需要从全流程角度出发，对其框架结构进行分析优化，根据职责、性能不同大致可以分为4 个部分，见图1。
（1）数据采集模块。该模块是大数据导购平台的精髓所在，能够通过海量、异构数据的分析处理挖掘出有用信息，为推荐结果准确性提供保证，因此，数据来源地梳理是该板块的重要分析对象，除平台网页中已有的商品信息、用户信息外，还包含用户各式各样的行为记录，比如浏览历史、购买评分以及商品好评率、畅销度、回购率等。类似商品、用户等的静态信息，系统会直接从平台中搜集获取，并定期更新和删改，行为数据则需要从用户日志中筛选和提取，因此模块中需要设置不同类型的公共接口，方便数据流通顺畅。
（2）导购引擎模块。主要以算法集成的形式存在，可以根据实际情况协调、配合，并计算出差异化的导购结果，考虑到数据本身较为复杂，硬件消耗成本可能会由此上升，因此采用Spark 结构，结果无需直接绑定导购目标，而是可以在离线计算支持下，现行存储到数据库之中，并在后续的搜索推荐中提取和应用，用户喜好相近程度、商品评分预测等均在引擎处理范围之内。
（3）导购处理模块。前述的引擎处理较为基础、粗略，必须经过细化处理才能够馈回前端以供使用。分析后发现导购系统的核心实质上在于推荐优质商品、节省挑选时间和缩小查询范围，因此引擎得出具体方向后，还需要进行过滤、排名处理，最后生成完整、精准的推荐结果，所有不符合预期目标的、消费者已经浏览过的，或者整体评分极低的商品则会被处理模块过滤出去，综合指标最高的条目排在首位，最大限度提升用户接受度和采纳率。
（4）用户交互模块。这是数据采集的必要来源途径，用户会话、反馈信息等均以此模块为依托生成并传输给数据库平台，处理完成后一并反馈，提供多个公共接口以便调用。
3 电子商务大数据导购系统设计细节与实现策略
3.1 数据采集模块设计
采集模块的运行主要针对3 个不同的数据集，即商品内容信息、用户行为信息以及评价预测信息等，处理、存储环节主要有以下两种可用思路。
其一是Hadoop 大数据平台自带的MapReduce 框架，优点是编程简单易学，可以遵循集群运行的基本秩序，提高系统整体的容错能力，且满足TB 级以上数据的并行运算需求。对于进入MapReduce 框架的数据，系统会依次执行Job 运行、请求作业、复制资源文件等步骤，对作业ID以及复制所需资源等均会有细致的检查和分析，完成后放入作业队列，转交给Job scheduler（作业调度器）进行初始化[2]，并根据相应的任务槽开展后续的本地化处理，完成后汇总为完整数据集。整个过程全部在JobTracker的监控之下，任务完成反馈回相关信号，其优点是可以提高并行处理能力，但所有结果存放于磁盘之中，明显增大了I/O 占用率，运行速度很容易受到影响，同时处理过程也仅限Map 和Reduce 两种，兼容性略有局限。
其二是Spark 框架结构，其核心概念为弹性分布式数据集，以若干个portion 为依托构成只读对象，并分布存在于各个集群中，可以灵活布局在磁盘、内存等空间之中，并且满足自由化构造转换需求，转换失败后还可以自我修复。它通常具备3 种分布式部署方法，其中standalone代表独立模式，可以单独部署至一个集群中，对其他资源的依赖性较小，spark on mesas 以及spark on YARN 则属于变式部署方案，可以显著降低运维成本、提升资源利用效率。与MapReduce 相比，该种方式综合运用磁盘、内存路径，支持高效并行运算，弹性分布式数据集降低了数据丢失风险，可以支持Filter、Join 以及Collect 等多种处理方式，兼容性更有保障。
因此设计中选用HDFS 文件系统构建数据库，其中原始数据层负责获取用户信息、商品信息，中间结果处理层可以对已有数据开展离线计算，导购结果层采用实时化运转方式，可以将数据馈回会话窗口，所有数据设置为列式Parquet 文件类型，采用sparkSQL 查询方式，方便上层引擎调用。
3.2 导购推荐引擎组模块设计
为满足不同场景下的导购推荐需求，系统中分别设置了在线、离线两种推荐引擎，其中离线引擎处于更加基础的地位，可以对原始数据集进行清晰、规约等预处理，可采用的方案共有3 种，分别以关联规则、商品内容以及人口统计学为依托，能够同时获取静态、动态信息，并将之传输回数据库中。在线引擎组则以之为平台，对数据进行调取和加载，所有活动在内存之中完成，完成处理后直接反馈回客户页面（图2），本文重点论述离线数据库不同方案的设计细节。
3.2.1 以关联规则为思路的设计
以关联规则为思路进行引擎设计时，重点在于挖掘目标商品与相似商品之间的关联数据项，通过配对和筛选找到相近的商品类别，并实时推荐给消费者，以提升导购成功率和采纳率。相似商品的信息来源是非常多样的，可以是用户购物车信息、浏览记录信息，也可以是收藏夹中的商品品类。离线引擎组设计过程中，需要事先对用户选购行为进行数据采集，生成相应的事务关联集，并在离线计算的基础上，计算出相关度结果，得到relevance_pro 关联度表，用Apriori 算法分析不同来源的关联规则，核心算法罗列如下：
SparkConf sparkconf=new SparkConf().setAppName(＂relevancy recommendation＂).setMaster(＂local[4]＂);
JavaSparkContext ctx=new JavaSparkContext(sparkConf);
JavaRDD
该步骤主要是为了获取用户选购记录，并将之预处理、转化为RDD 形式，方便后续进行spark 处理。在此基础上设计频繁项集寻找算法，采用逐级扫描、统计以及比较的方式，确定候选集并计算出相应的支持度，最后不断分析和更新，找到频繁集最大的对象。目标频繁集找到之后，收集和处理商品间的支持度，并生成相应的关联规则，计算公式为：
计算得出相关度列表后，以Parquet 的形式存储，为后续的引擎调用提供便利。在线分析环节，首先找到explorerInfo 表，并获取相应的浏览记录、加购商品和评分情况，接着调取relevance_pro 表[3]，比较获得相关度较大的设定值组合，经过join 操作后产生RDD3，并进行group 操作，获得详细度、精确度更高的RDD4，处理生成完整的导购推荐列表。
3.2.2 以商品内容为蓝本的设计
商品内容是用户挑选过程中最先考虑的基础性信息，包含商品属性信息、评分信息等，系统会根据静态化的消费记录信息挖掘、摸索其兴趣取向，并以固定算法为工具寻找匹配度较高的目标商品，该方式对用户行为信息依赖性较小，不存在冷启动制约稳定性的问题，但对信息的结构性、完整性有着较高要求。系统获取记录后计算商品相似度，并得到相应的same_content 表，根据表中所列内容，生成相似度较高的粗略性列表，即Shop1={s1,s2,s3,...}，接着采集用户以往的评价信息和推荐情况，预测用户可能的消费满意度。离线分析设计环节，引入了简化后的余弦相似度公式：
其中Wuv代表u商品及V商品之间的相似度，N(u) 、N(v)则代表不同商品的内容，比如A 类商品类型为服饰，风格为韩版、休闲，则推荐的C 类商品必然也是具备此类特征的。离线分析过程中，所有余弦相似度计算结果均需要留存副本，以Parquet 形式存储在HDFS 平台之中。在线分析过程中，同样需要找到数据库explorerInfo表，从中获取用户浏览、购买记录，得到RDD 结果后与离线seme_content 汇合，计算相似度并开展join 计算，生成相应商品的评分表，按照一定顺序输出和馈回前端，帮助用户更加快捷地完成购买决策。其中的关键参数共两个：（1）商品相似度限值（Content.score.same_threshold），本系统中设置为0.75，当运算结果小于该数值时，则直接被过滤排除，不计入导购推荐列表之中。（2）相似商品个数最大值（Content.score.same_goodsMAx），默认值设定为10，高于该数值的列表将最先被采纳推荐。
3.2.3 以人口统计学为依托的设计
人口统计学理论通常与协同过滤算法并行融合、应用在导购系统推荐板块中，前者主要通过人口信息，比如年龄、性别、受教育程度等，来确定消费者个体之间的相异度，明确不同个体间的关系、距离等，所获取的信息为静态，不存在冷启动问题，可以适用于各种目标群体之中。后者则通过用户主动行为的统计计算相似度，并预测、推算目标客户可能的消费倾向、使用评价等。算法设计时主要依靠“用户相异度表differ_pop”，当消费者发出登录请求时，系统会运算并统计用户相异度情况，通过比较发掘出相异度最小用户U1={u1,u2,u3...}，据此推测消费者可能采纳的商品列表。离线设计过程中，主要借助sparkSQL框架进行数据调取，并生成基础的RDD 结果，在此基础上运行笛卡尔积运算[4]，产生更加细化的RDD2，经过处理的RDD2 通常包含2 组任意用户信息，经过相异度计算处理后，得到RDD3 并计入differ_pop 表中。相似度计算节选如下：
for (Map.Entry
String vid1=e.getKey();
List
在线分析过程同样以离线分析逻辑为基础，需要从数据库相异度表中获取信息，并生成RDD，设定值应当低于相似阈值，接着从原始数据集中或缺RDD，并开展相应的join 操作和group 操作，生成内容更加具体、完善的RDD4，在此基础上逐行开展flatMap 运算，得出最终的导购预测、评估分数。
3.3 导购结果处理模块设计
导购结果处理模块中，需要借助一定的规则进行优化细分，为保证准确性本次设计采用加权混合模型，算法可简化为如下公式：
其中的Score(i,s)代表推荐评分标准化运算结果，i和s分别表示推荐引擎、推荐评分，R（max）则代表组内评分最高的对象，r表示每条推荐分数，N表示引擎系数，为提前设置好的固定值。这里为了优化加权混合模型适宜性，还额外设置了深度处理逻辑，分别计算单一推荐引擎下物品的推荐评分，并带入公式计算标准化评分，比如A 物品基于内容的推荐评分为5.2，那么标准化评分就是（5.2/5.2）*0.32=0.32，若消费者选取了任何一个引擎的推荐结果，则说明该引擎是比较适合当前场景的，分值提高20%，剩余两项结果会进一步调准，权重相应降低20%。这种方式运算简单，基本可以满足不同场景下的引擎选择、加权设置需求，但准确度和智能性仍有待考量。
3.4 用户交互搜索模块设计
用户交互搜索模块设计时，务必要突出人性化、便捷化特征，支持关键词快速搜索的基础上，还应当满足高级搜索需求，比如分类检索、时间检索等。因此实践过程中对离线网页进行了抽取和处理，形成索引后存储到相应的数据库中，方便用户准确搜索，涉及的核心业务也非常多样，其中messageQO 主要面向条件封装类信息，比如起始时间、排序字段等[5]；SearchFatory 主要面向工厂类信息，比如初始化配置信息等；VisuaozationDataController 则面向业务处理逻辑类信息，可以在接收到用户信息后，把相应的结果数据反馈给用户，据此实现精确查询、模糊查询、统计查询一体的交互界面。
4 电子商务大数据导购系统运行测试与评估
除系统设计外，运行验证与测试也是开发过程中必不可少的环节，只有在实践运行中观察系统表现和效果，才能最大限度规避潜在风险，保障后期平稳运行。此次测试环境设定时，采用8 核2.4 G 储存CPU，内存及硬盘容量分别为32 G 和2 T，操作系统为cantos7。使用导购推荐准确率、覆盖率作为衡量指标，前者指用户点击列表与推荐列表重合数，后者指推荐商品数占总点击数比重，结果发现准确率可以达到62.56%，覆盖率可以达到87.61%，基本符合预期目标。
5 结语
综上所述，本文聚焦大数据技术发展普及趋势，对现有电子商务导购平台进行优化设计，系统运行可靠性、精准性较高，能够较好地洞悉用户购买意愿，分析其购物倾向、趋势等。与现有研究成果相比，该设计思路更加有条理、完整，覆盖了从数据采集、处理至结果生成、用户交互的全过程，但受现有算法、技术的局限，推荐引擎智能化选取仍旧未能完全实现，系统很难根据应用场景灵活选择基于关联规则、基于商品内容以及基于人口统计学的推荐方案，对推荐准确性的提升造成了较大制约，未来仍需要进一步研究和突破。
