關(guān)于電子商務(wù)大數(shù)據(jù)導(dǎo)購(gòu)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)研究

陳靜靜

（阿里巴巴集團(tuán)控股有限公司 浙江 杭州 311121）

0 引言

近年來，電子商務(wù)以極其迅猛的態(tài)勢(shì)加入了商品零售、推廣隊(duì)列中，各式網(wǎng)購(gòu)客戶端、網(wǎng)絡(luò)站點(diǎn)層出不窮，為互聯(lián)網(wǎng)業(yè)態(tài)的更新和完善注入了新活力，僅2020 年全國(guó)電子商務(wù)交易額就已達(dá)到37.21 萬億元，同比增長(zhǎng)率達(dá)到4.5%，跨境電商流水也已經(jīng)達(dá)到1.69 萬億元，經(jīng)營(yíng)規(guī)模明顯擴(kuò)張。但用戶群體的擴(kuò)大、商家總數(shù)的上升也為線上運(yùn)營(yíng)管理帶來了新的難題，商戶為盡可能提高份額占比，會(huì)在網(wǎng)頁上投放大量商品，用戶則需要費(fèi)心費(fèi)力搜集信息，對(duì)比價(jià)格、品質(zhì)等內(nèi)容，無形之中增加了線上消費(fèi)成本，如何簡(jiǎn)化篩選難度、提升導(dǎo)購(gòu)有效性，就成了諸多線上平臺(tái)關(guān)注的焦點(diǎn)問題?，F(xiàn)有的學(xué)術(shù)研究中通常將“導(dǎo)購(gòu)”問題拆分為“個(gè)性化推薦”“用戶購(gòu)買行為”“檢索模型”等[1]，導(dǎo)致研究成果較為零散，缺乏從數(shù)據(jù)采集至處理、交互的全過程內(nèi)容，無法為系統(tǒng)設(shè)計(jì)實(shí)踐提供明晰思路?；诖耍疚膮R總已有的數(shù)據(jù)庫算法、主動(dòng)推薦算法等，深入挖掘系統(tǒng)設(shè)計(jì)需求和目標(biāo)，闡述系統(tǒng)整體架構(gòu)與細(xì)節(jié)，為電商導(dǎo)購(gòu)平臺(tái)的優(yōu)化提供助力。

1 電子商務(wù)大數(shù)據(jù)導(dǎo)購(gòu)系統(tǒng)設(shè)計(jì)需求分析

從需求角度上看，電子商務(wù)大數(shù)據(jù)導(dǎo)購(gòu)系統(tǒng)實(shí)質(zhì)上是具有輔助決策功能的信息采集、處理、推送平臺(tái)，可以更加高效地過濾無關(guān)信息，提升消費(fèi)者對(duì)商品價(jià)格、品質(zhì)等的認(rèn)知程度，節(jié)約消費(fèi)時(shí)間、成本的同時(shí)促成購(gòu)買行為的發(fā)生。因此設(shè)計(jì)時(shí)應(yīng)以以下幾個(gè)目標(biāo)為指引：（1）要能夠以導(dǎo)購(gòu)咨詢?yōu)橐劳刑嵘到y(tǒng)交互性，現(xiàn)代網(wǎng)絡(luò)科技飛速發(fā)展，交互性導(dǎo)購(gòu)方式已經(jīng)進(jìn)入到多個(gè)客戶端平臺(tái)中，為消費(fèi)者在線查詢、搜集信息提供了便利，因此設(shè)計(jì)中可以將聊天工具有機(jī)植入到動(dòng)態(tài)網(wǎng)頁技術(shù)中去，用交互性能博取消費(fèi)者關(guān)注，優(yōu)化其使用體驗(yàn)；（2）要能夠以自主學(xué)習(xí)為途徑彰顯推薦智能性，這是新型導(dǎo)購(gòu)系統(tǒng)設(shè)計(jì)的關(guān)鍵所在，傳統(tǒng)導(dǎo)購(gòu)?fù)扑]之所以采納率不高，就在于其推薦邏輯較為簡(jiǎn)單、表層，忽略了動(dòng)態(tài)化、關(guān)聯(lián)化的信息挖掘。新系統(tǒng)設(shè)計(jì)時(shí)，可以基于商品內(nèi)容、關(guān)聯(lián)規(guī)則等進(jìn)行全方位、無死角的異構(gòu)數(shù)據(jù)收集、處理，最大限度提升系統(tǒng)智能化水平，保障推薦精準(zhǔn)度；（3）要能夠以主動(dòng)服務(wù)為平臺(tái)保障用戶忠誠(chéng)度，良好的導(dǎo)購(gòu)、推薦服務(wù)是維系客戶紐帶的重要手段，若推薦內(nèi)容符合消費(fèi)者預(yù)期，幫助消費(fèi)者簡(jiǎn)化挑選工序的同時(shí)滿足了用戶內(nèi)在需求，那么這種買賣關(guān)系會(huì)更加牢靠。

2 電子商務(wù)大數(shù)據(jù)導(dǎo)購(gòu)系統(tǒng)整體框架與結(jié)構(gòu)

為保證導(dǎo)購(gòu)系統(tǒng)運(yùn)行順暢度、完整度，需要從全流程角度出發(fā)，對(duì)其框架結(jié)構(gòu)進(jìn)行分析優(yōu)化，根據(jù)職責(zé)、性能不同大致可以分為4 個(gè)部分，見圖1。

（1）數(shù)據(jù)采集模塊。該模塊是大數(shù)據(jù)導(dǎo)購(gòu)平臺(tái)的精髓所在，能夠通過海量、異構(gòu)數(shù)據(jù)的分析處理挖掘出有用信息，為推薦結(jié)果準(zhǔn)確性提供保證，因此，數(shù)據(jù)來源地梳理是該板塊的重要分析對(duì)象，除平臺(tái)網(wǎng)頁中已有的商品信息、用戶信息外，還包含用戶各式各樣的行為記錄，比如瀏覽歷史、購(gòu)買評(píng)分以及商品好評(píng)率、暢銷度、回購(gòu)率等。類似商品、用戶等的靜態(tài)信息，系統(tǒng)會(huì)直接從平臺(tái)中搜集獲取，并定期更新和刪改，行為數(shù)據(jù)則需要從用戶日志中篩選和提取，因此模塊中需要設(shè)置不同類型的公共接口，方便數(shù)據(jù)流通順暢。

（2）導(dǎo)購(gòu)引擎模塊。主要以算法集成的形式存在，可以根據(jù)實(shí)際情況協(xié)調(diào)、配合，并計(jì)算出差異化的導(dǎo)購(gòu)結(jié)果，考慮到數(shù)據(jù)本身較為復(fù)雜，硬件消耗成本可能會(huì)由此上升，因此采用Spark 結(jié)構(gòu)，結(jié)果無需直接綁定導(dǎo)購(gòu)目標(biāo)，而是可以在離線計(jì)算支持下，現(xiàn)行存儲(chǔ)到數(shù)據(jù)庫之中，并在后續(xù)的搜索推薦中提取和應(yīng)用，用戶喜好相近程度、商品評(píng)分預(yù)測(cè)等均在引擎處理范圍之內(nèi)。

（3）導(dǎo)購(gòu)處理模塊。前述的引擎處理較為基礎(chǔ)、粗略，必須經(jīng)過細(xì)化處理才能夠饋回前端以供使用。分析后發(fā)現(xiàn)導(dǎo)購(gòu)系統(tǒng)的核心實(shí)質(zhì)上在于推薦優(yōu)質(zhì)商品、節(jié)省挑選時(shí)間和縮小查詢范圍，因此引擎得出具體方向后，還需要進(jìn)行過濾、排名處理，最后生成完整、精準(zhǔn)的推薦結(jié)果，所有不符合預(yù)期目標(biāo)的、消費(fèi)者已經(jīng)瀏覽過的，或者整體評(píng)分極低的商品則會(huì)被處理模塊過濾出去，綜合指標(biāo)最高的條目排在首位，最大限度提升用戶接受度和采納率。

（4）用戶交互模塊。這是數(shù)據(jù)采集的必要來源途徑，用戶會(huì)話、反饋信息等均以此模塊為依托生成并傳輸給數(shù)據(jù)庫平臺(tái)，處理完成后一并反饋，提供多個(gè)公共接口以便調(diào)用。

3 電子商務(wù)大數(shù)據(jù)導(dǎo)購(gòu)系統(tǒng)設(shè)計(jì)細(xì)節(jié)與實(shí)現(xiàn)策略

3.1 數(shù)據(jù)采集模塊設(shè)計(jì)

采集模塊的運(yùn)行主要針對(duì)3 個(gè)不同的數(shù)據(jù)集，即商品內(nèi)容信息、用戶行為信息以及評(píng)價(jià)預(yù)測(cè)信息等，處理、存儲(chǔ)環(huán)節(jié)主要有以下兩種可用思路。

其一是Hadoop 大數(shù)據(jù)平臺(tái)自帶的MapReduce 框架，優(yōu)點(diǎn)是編程簡(jiǎn)單易學(xué)，可以遵循集群運(yùn)行的基本秩序，提高系統(tǒng)整體的容錯(cuò)能力，且滿足TB 級(jí)以上數(shù)據(jù)的并行運(yùn)算需求。對(duì)于進(jìn)入MapReduce 框架的數(shù)據(jù)，系統(tǒng)會(huì)依次執(zhí)行Job 運(yùn)行、請(qǐng)求作業(yè)、復(fù)制資源文件等步驟，對(duì)作業(yè)ID以及復(fù)制所需資源等均會(huì)有細(xì)致的檢查和分析，完成后放入作業(yè)隊(duì)列，轉(zhuǎn)交給Job scheduler（作業(yè)調(diào)度器）進(jìn)行初始化[2]，并根據(jù)相應(yīng)的任務(wù)槽開展后續(xù)的本地化處理，完成后匯總為完整數(shù)據(jù)集。整個(gè)過程全部在JobTracker的監(jiān)控之下，任務(wù)完成反饋回相關(guān)信號(hào)，其優(yōu)點(diǎn)是可以提高并行處理能力，但所有結(jié)果存放于磁盤之中，明顯增大了I/O 占用率，運(yùn)行速度很容易受到影響，同時(shí)處理過程也僅限Map 和Reduce 兩種，兼容性略有局限。

其二是Spark 框架結(jié)構(gòu)，其核心概念為彈性分布式數(shù)據(jù)集，以若干個(gè)portion 為依托構(gòu)成只讀對(duì)象，并分布存在于各個(gè)集群中，可以靈活布局在磁盤、內(nèi)存等空間之中，并且滿足自由化構(gòu)造轉(zhuǎn)換需求，轉(zhuǎn)換失敗后還可以自我修復(fù)。它通常具備3 種分布式部署方法，其中standalone代表獨(dú)立模式，可以單獨(dú)部署至一個(gè)集群中，對(duì)其他資源的依賴性較小，spark on mesas 以及spark on YARN 則屬于變式部署方案，可以顯著降低運(yùn)維成本、提升資源利用效率。與MapReduce 相比，該種方式綜合運(yùn)用磁盤、內(nèi)存路徑，支持高效并行運(yùn)算，彈性分布式數(shù)據(jù)集降低了數(shù)據(jù)丟失風(fēng)險(xiǎn)，可以支持Filter、Join 以及Collect 等多種處理方式，兼容性更有保障。

因此設(shè)計(jì)中選用HDFS 文件系統(tǒng)構(gòu)建數(shù)據(jù)庫，其中原始數(shù)據(jù)層負(fù)責(zé)獲取用戶信息、商品信息，中間結(jié)果處理層可以對(duì)已有數(shù)據(jù)開展離線計(jì)算，導(dǎo)購(gòu)結(jié)果層采用實(shí)時(shí)化運(yùn)轉(zhuǎn)方式，可以將數(shù)據(jù)饋回會(huì)話窗口，所有數(shù)據(jù)設(shè)置為列式Parquet 文件類型，采用sparkSQL 查詢方式，方便上層引擎調(diào)用。

3.2 導(dǎo)購(gòu)?fù)扑]引擎組模塊設(shè)計(jì)

為滿足不同場(chǎng)景下的導(dǎo)購(gòu)?fù)扑]需求，系統(tǒng)中分別設(shè)置了在線、離線兩種推薦引擎，其中離線引擎處于更加基礎(chǔ)的地位，可以對(duì)原始數(shù)據(jù)集進(jìn)行清晰、規(guī)約等預(yù)處理，可采用的方案共有3 種，分別以關(guān)聯(lián)規(guī)則、商品內(nèi)容以及人口統(tǒng)計(jì)學(xué)為依托，能夠同時(shí)獲取靜態(tài)、動(dòng)態(tài)信息，并將之傳輸回?cái)?shù)據(jù)庫中。在線引擎組則以之為平臺(tái)，對(duì)數(shù)據(jù)進(jìn)行調(diào)取和加載，所有活動(dòng)在內(nèi)存之中完成，完成處理后直接反饋回客戶頁面（圖2），本文重點(diǎn)論述離線數(shù)據(jù)庫不同方案的設(shè)計(jì)細(xì)節(jié)。

3.2.1 以關(guān)聯(lián)規(guī)則為思路的設(shè)計(jì)

以關(guān)聯(lián)規(guī)則為思路進(jìn)行引擎設(shè)計(jì)時(shí)，重點(diǎn)在于挖掘目標(biāo)商品與相似商品之間的關(guān)聯(lián)數(shù)據(jù)項(xiàng)，通過配對(duì)和篩選找到相近的商品類別，并實(shí)時(shí)推薦給消費(fèi)者，以提升導(dǎo)購(gòu)成功率和采納率。相似商品的信息來源是非常多樣的，可以是用戶購(gòu)物車信息、瀏覽記錄信息，也可以是收藏夾中的商品品類。離線引擎組設(shè)計(jì)過程中，需要事先對(duì)用戶選購(gòu)行為進(jìn)行數(shù)據(jù)采集，生成相應(yīng)的事務(wù)關(guān)聯(lián)集，并在離線計(jì)算的基礎(chǔ)上，計(jì)算出相關(guān)度結(jié)果，得到relevance_pro 關(guān)聯(lián)度表，用Apriori 算法分析不同來源的關(guān)聯(lián)規(guī)則，核心算法羅列如下：

SparkConf sparkconf=new SparkConf().setAppName(＂relevancy recommendation＂).setMaster(＂local[4]＂);

JavaSparkContext ctx=new JavaSparkContext(sparkConf);

JavaRDDlines=ctx.textFile(args[0],1).

該步驟主要是為了獲取用戶選購(gòu)記錄，并將之預(yù)處理、轉(zhuǎn)化為RDD 形式，方便后續(xù)進(jìn)行spark 處理。在此基礎(chǔ)上設(shè)計(jì)頻繁項(xiàng)集尋找算法，采用逐級(jí)掃描、統(tǒng)計(jì)以及比較的方式，確定候選集并計(jì)算出相應(yīng)的支持度，最后不斷分析和更新，找到頻繁集最大的對(duì)象。目標(biāo)頻繁集找到之后，收集和處理商品間的支持度，并生成相應(yīng)的關(guān)聯(lián)規(guī)則，計(jì)算公式為：

計(jì)算得出相關(guān)度列表后，以Parquet 的形式存儲(chǔ)，為后續(xù)的引擎調(diào)用提供便利。在線分析環(huán)節(jié)，首先找到explorerInfo 表，并獲取相應(yīng)的瀏覽記錄、加購(gòu)商品和評(píng)分情況，接著調(diào)取relevance_pro 表[3]，比較獲得相關(guān)度較大的設(shè)定值組合，經(jīng)過join 操作后產(chǎn)生RDD3，并進(jìn)行g(shù)roup 操作，獲得詳細(xì)度、精確度更高的RDD4，處理生成完整的導(dǎo)購(gòu)?fù)扑]列表。

3.2.2 以商品內(nèi)容為藍(lán)本的設(shè)計(jì)

商品內(nèi)容是用戶挑選過程中最先考慮的基礎(chǔ)性信息，包含商品屬性信息、評(píng)分信息等，系統(tǒng)會(huì)根據(jù)靜態(tài)化的消費(fèi)記錄信息挖掘、摸索其興趣取向，并以固定算法為工具尋找匹配度較高的目標(biāo)商品，該方式對(duì)用戶行為信息依賴性較小，不存在冷啟動(dòng)制約穩(wěn)定性的問題，但對(duì)信息的結(jié)構(gòu)性、完整性有著較高要求。系統(tǒng)獲取記錄后計(jì)算商品相似度，并得到相應(yīng)的same_content 表，根據(jù)表中所列內(nèi)容，生成相似度較高的粗略性列表，即Shop1={s1,s2,s3,...}，接著采集用戶以往的評(píng)價(jià)信息和推薦情況，預(yù)測(cè)用戶可能的消費(fèi)滿意度。離線分析設(shè)計(jì)環(huán)節(jié)，引入了簡(jiǎn)化后的余弦相似度公式：

其中Wuv代表u商品及V商品之間的相似度，N(u) 、N(v)則代表不同商品的內(nèi)容，比如A 類商品類型為服飾，風(fēng)格為韓版、休閑，則推薦的C 類商品必然也是具備此類特征的。離線分析過程中，所有余弦相似度計(jì)算結(jié)果均需要留存副本，以Parquet 形式存儲(chǔ)在HDFS 平臺(tái)之中。在線分析過程中，同樣需要找到數(shù)據(jù)庫explorerInfo表，從中獲取用戶瀏覽、購(gòu)買記錄，得到RDD 結(jié)果后與離線seme_content 匯合，計(jì)算相似度并開展join 計(jì)算，生成相應(yīng)商品的評(píng)分表，按照一定順序輸出和饋回前端，幫助用戶更加快捷地完成購(gòu)買決策。其中的關(guān)鍵參數(shù)共兩個(gè)：（1）商品相似度限值（Content.score.same_threshold），本系統(tǒng)中設(shè)置為0.75，當(dāng)運(yùn)算結(jié)果小于該數(shù)值時(shí)，則直接被過濾排除，不計(jì)入導(dǎo)購(gòu)?fù)扑]列表之中。（2）相似商品個(gè)數(shù)最大值（Content.score.same_goodsMAx），默認(rèn)值設(shè)定為10，高于該數(shù)值的列表將最先被采納推薦。

3.2.3 以人口統(tǒng)計(jì)學(xué)為依托的設(shè)計(jì)

人口統(tǒng)計(jì)學(xué)理論通常與協(xié)同過濾算法并行融合、應(yīng)用在導(dǎo)購(gòu)系統(tǒng)推薦板塊中，前者主要通過人口信息，比如年齡、性別、受教育程度等，來確定消費(fèi)者個(gè)體之間的相異度，明確不同個(gè)體間的關(guān)系、距離等，所獲取的信息為靜態(tài)，不存在冷啟動(dòng)問題，可以適用于各種目標(biāo)群體之中。后者則通過用戶主動(dòng)行為的統(tǒng)計(jì)計(jì)算相似度，并預(yù)測(cè)、推算目標(biāo)客戶可能的消費(fèi)傾向、使用評(píng)價(jià)等。算法設(shè)計(jì)時(shí)主要依靠“用戶相異度表differ_pop”，當(dāng)消費(fèi)者發(fā)出登錄請(qǐng)求時(shí)，系統(tǒng)會(huì)運(yùn)算并統(tǒng)計(jì)用戶相異度情況，通過比較發(fā)掘出相異度最小用戶U1={u1,u2,u3...}，據(jù)此推測(cè)消費(fèi)者可能采納的商品列表。離線設(shè)計(jì)過程中，主要借助sparkSQL框架進(jìn)行數(shù)據(jù)調(diào)取，并生成基礎(chǔ)的RDD 結(jié)果，在此基礎(chǔ)上運(yùn)行笛卡爾積運(yùn)算[4]，產(chǎn)生更加細(xì)化的RDD2，經(jīng)過處理的RDD2 通常包含2 組任意用戶信息，經(jīng)過相異度計(jì)算處理后，得到RDD3 并計(jì)入differ_pop 表中。相似度計(jì)算節(jié)選如下：

for (Map.Entrye:userMap.entrySet()){

String vid1=e.getKey();

Listlist1=e.getValue();

在線分析過程同樣以離線分析邏輯為基礎(chǔ)，需要從數(shù)據(jù)庫相異度表中獲取信息，并生成RDD，設(shè)定值應(yīng)當(dāng)?shù)陀谙嗨崎撝?，接著從原始?shù)據(jù)集中或缺RDD，并開展相應(yīng)的join 操作和group 操作，生成內(nèi)容更加具體、完善的RDD4，在此基礎(chǔ)上逐行開展flatMap 運(yùn)算，得出最終的導(dǎo)購(gòu)預(yù)測(cè)、評(píng)估分?jǐn)?shù)。

3.3 導(dǎo)購(gòu)結(jié)果處理模塊設(shè)計(jì)

導(dǎo)購(gòu)結(jié)果處理模塊中，需要借助一定的規(guī)則進(jìn)行優(yōu)化細(xì)分，為保證準(zhǔn)確性本次設(shè)計(jì)采用加權(quán)混合模型，算法可簡(jiǎn)化為如下公式：

其中的Score(i,s)代表推薦評(píng)分標(biāo)準(zhǔn)化運(yùn)算結(jié)果，i和s分別表示推薦引擎、推薦評(píng)分，R（max）則代表組內(nèi)評(píng)分最高的對(duì)象，r表示每條推薦分?jǐn)?shù)，N表示引擎系數(shù)，為提前設(shè)置好的固定值。這里為了優(yōu)化加權(quán)混合模型適宜性，還額外設(shè)置了深度處理邏輯，分別計(jì)算單一推薦引擎下物品的推薦評(píng)分，并帶入公式計(jì)算標(biāo)準(zhǔn)化評(píng)分，比如A 物品基于內(nèi)容的推薦評(píng)分為5.2，那么標(biāo)準(zhǔn)化評(píng)分就是（5.2/5.2）*0.32=0.32，若消費(fèi)者選取了任何一個(gè)引擎的推薦結(jié)果，則說明該引擎是比較適合當(dāng)前場(chǎng)景的，分值提高20%，剩余兩項(xiàng)結(jié)果會(huì)進(jìn)一步調(diào)準(zhǔn)，權(quán)重相應(yīng)降低20%。這種方式運(yùn)算簡(jiǎn)單，基本可以滿足不同場(chǎng)景下的引擎選擇、加權(quán)設(shè)置需求，但準(zhǔn)確度和智能性仍有待考量。

3.4 用戶交互搜索模塊設(shè)計(jì)

用戶交互搜索模塊設(shè)計(jì)時(shí)，務(wù)必要突出人性化、便捷化特征，支持關(guān)鍵詞快速搜索的基礎(chǔ)上，還應(yīng)當(dāng)滿足高級(jí)搜索需求，比如分類檢索、時(shí)間檢索等。因此實(shí)踐過程中對(duì)離線網(wǎng)頁進(jìn)行了抽取和處理，形成索引后存儲(chǔ)到相應(yīng)的數(shù)據(jù)庫中，方便用戶準(zhǔn)確搜索，涉及的核心業(yè)務(wù)也非常多樣，其中messageQO 主要面向條件封裝類信息，比如起始時(shí)間、排序字段等[5]；SearchFatory 主要面向工廠類信息，比如初始化配置信息等；VisuaozationDataController 則面向業(yè)務(wù)處理邏輯類信息，可以在接收到用戶信息后，把相應(yīng)的結(jié)果數(shù)據(jù)反饋給用戶，據(jù)此實(shí)現(xiàn)精確查詢、模糊查詢、統(tǒng)計(jì)查詢一體的交互界面。

4 電子商務(wù)大數(shù)據(jù)導(dǎo)購(gòu)系統(tǒng)運(yùn)行測(cè)試與評(píng)估

除系統(tǒng)設(shè)計(jì)外，運(yùn)行驗(yàn)證與測(cè)試也是開發(fā)過程中必不可少的環(huán)節(jié)，只有在實(shí)踐運(yùn)行中觀察系統(tǒng)表現(xiàn)和效果，才能最大限度規(guī)避潛在風(fēng)險(xiǎn)，保障后期平穩(wěn)運(yùn)行。此次測(cè)試環(huán)境設(shè)定時(shí)，采用8 核2.4 G 儲(chǔ)存CPU，內(nèi)存及硬盤容量分別為32 G 和2 T，操作系統(tǒng)為cantos7。使用導(dǎo)購(gòu)?fù)扑]準(zhǔn)確率、覆蓋率作為衡量指標(biāo)，前者指用戶點(diǎn)擊列表與推薦列表重合數(shù)，后者指推薦商品數(shù)占總點(diǎn)擊數(shù)比重，結(jié)果發(fā)現(xiàn)準(zhǔn)確率可以達(dá)到62.56%，覆蓋率可以達(dá)到87.61%，基本符合預(yù)期目標(biāo)。

5 結(jié)語

綜上所述，本文聚焦大數(shù)據(jù)技術(shù)發(fā)展普及趨勢(shì)，對(duì)現(xiàn)有電子商務(wù)導(dǎo)購(gòu)平臺(tái)進(jìn)行優(yōu)化設(shè)計(jì)，系統(tǒng)運(yùn)行可靠性、精準(zhǔn)性較高，能夠較好地洞悉用戶購(gòu)買意愿，分析其購(gòu)物傾向、趨勢(shì)等。與現(xiàn)有研究成果相比，該設(shè)計(jì)思路更加有條理、完整，覆蓋了從數(shù)據(jù)采集、處理至結(jié)果生成、用戶交互的全過程，但受現(xiàn)有算法、技術(shù)的局限，推薦引擎智能化選取仍舊未能完全實(shí)現(xiàn)，系統(tǒng)很難根據(jù)應(yīng)用場(chǎng)景靈活選擇基于關(guān)聯(lián)規(guī)則、基于商品內(nèi)容以及基于人口統(tǒng)計(jì)學(xué)的推薦方案，對(duì)推薦準(zhǔn)確性的提升造成了較大制約，未來仍需要進(jìn)一步研究和突破。