简介这是一份面向数据挖掘与机器学习初学者的电商实战资料围绕电子商务网站用户行为分析及服务推荐展开帮助学习者把Python数据处理、可视化与建模能力应用到真实业务场景。压缩包共5个文件以两个Jupyter Notebook代码为主体辅以Excel数据表、SQL查询脚本与使用说明整体仅79KB结构紧凑非常适合快速下载研读。代码覆盖NumPy数值计算、Pandas清洗聚合、数据可视化与探索性分析并实现协同过滤、矩阵分解SVD等经典推荐算法同时包含模型评估与参数调优思路自带数据库查询文件与Excel原始数据可配合代码动手实践理解从数据清洗到推荐结果输出的完整流程。学习者既能获得可复用的代码框架与数据集也能掌握电商场景下推荐系统的基本实现方法。已有419人学习适合具备Python基础、希望快速入门数据挖掘实战的读者。1. 数据挖掘和机器学习实战项目从用户行为日志到推荐服务拿到一个电子商务网站的用户行为日志怎么把它变成推荐列表这是数据挖掘和机器学习实战里最经典的一段流程。这份资料不是干讲算法的教程而是直接把一份带数据的电商行为分析项目拆给你里面有 7law.sql 这种数据库导出的原始数据也有 .ipynb 的 Jupyter Notebook 脚本和配套代码目录。它的价值在于把数据清洗、探索性分析、推荐模型、评估指标四件事串成了一条完整链路适合刚学完 Python 基础、想用 Pandas 和 sklearn 跑通真实数据集的读者也适合手里有类似行为日志、想参考同行特征处理方式的一线数据分析师。看完这份项目你能回答一个问题一个用户从浏览到购买中间到底经历了什么系统又是依据哪些行为把他想要的商品排到前面的。2. 环境准备和数据加载先把 SQL 和 Excel 变成可分析的 DataFrame2.1 解压后的文件清单先认清四类资产压缩包里的内容表面看是 data、7law.sql、readme.txt、Untitled.ipynb、123.xls、code 这些文件和目录。我通常把它们分成四类readme.txt 是说明文档第一步先读它7law.sql 是数据库导出的结构加数据属于行为明细数据123.xls 是另一份表格数据一般是商品信息或补充行为数据Untitled.ipynb 和 code 目录是代码资产。真正开始写代码之前把每一类的格式和用途确认清楚能避免后面一半时间在猜字段含义。先用文本方式打开 readme.txt再在命令行里看一下 7law.sql 的头部确认它是不是 MySQL dump 文件建的是哪几张表。这两步不用写 Python但能让你对接下来的数据规模有数。常见的情况是行为表有用户 id、商品 id、行为类型、时间戳四个核心字段外加一张商品表存类目和品牌信息。导入前把表结构和字段类型都打印一遍后面 Pandas 读取就不用来回试错。代码环境建议用 conda 或 venv 单独建一个项目环境别直接装进系统级的 Python。项目里既然带 ipynb说明作者就是在 Jupyter 里跑的你也应该先装好 Jupyterpip install pandas numpy matplotlib seaborn scikit-learn pymysql xlrd jupyter jupyter notebook参数说明pymysql 是用来连 MySQL 读 7law.sql 的驱动xlrd 是读老 .xls 格式的引擎新版 pandas 不内置必须手动补。装完以后我把 Untitled.ipynb 重命名成自己的项目名——这种默认文件名第一次打开能跑第二次你自己都分不清存的是哪个版本。2.2 用 Pandas 加载 7law.sql 和 123.xls两种数据源两种读法7law.sql 是 MySQL 导出文件推荐流程是先用命令行把 sql 导入本地数据库再用 pymysql 连上去读。不要试图用 Python 直接解析 sql 文件投资回报率太低。导入命令一般是mysql -u root -p 7law.sql导入成功后用下面的代码读行为表。如果你的 sql 里表名不叫 user_behavior先去数据库里 show tables 看一眼再替换import pandas as pd import pymysql conn pymysql.connect( hostlocalhost, # 本机 MySQL port3306, # MySQL 默认端口 userroot, password你的密码, databaseecommerce, # 7law.sql 导入后所在的库名 charsetutf8mb4 # 关键指定 utf8mb4避免中文乱码 ) df pd.read_sql(SELECT * FROM user_behavior, conn) conn.close() print(df.shape) print(df.dtypes) print(df.head())这段代码的作用是把整张行为表读进 DataFrame。charset 参数我每次都写 utf8mb4因为老 MySQL 库默认可能是 latin1一旦出现中文编码问题后面重新导数据成本很高。read_sql 支持直接写 SQL 语句所以你可以先在 SQL 里做过滤比如只查最近 30 天减少传输量。123.xls 那份表格数据读取方式完全不同。老格式 Excel 必须指定 xlrd 引擎否则大概率报错df_items pd.read_excel(123.xls, sheet_name0, enginexlrd) print(df_items.head()) print(df_items.columns.tolist())参数说明sheet_name0 表示读第一个 sheet也可以传 sheet 名enginexlrd 强制用 xlrd 解析 .xls 老格式新版 pandas 默认用 openpyxl 处理 .xlsx但对 .xls 兼容性反而不如 xlrd 稳定。如果读进来中文列名乱码多半是 Excel 文件本身的编码问题第五章有排查方法。行为表和商品表读进来以后下一步用 item_id 做关联行为分析才有业务含义。2.3 数据清洗时间戳、重复行为和缺失值一起处理电商行为数据最常见的问题有三类重复记录、时间戳格式不统一、用户或商品字段缺失。先把这三件事处理掉后面 EDA 和建模才不会反复返工。注意清洗不是把异常值删光而是要记录清洗前后行数变化心里有数。# 1) 对同一用户、同一商品、同一行为、同一时间点去重 df df.drop_duplicates( subset[user_id, item_id, behavior_type, timestamp] ) # 2) Unix 时间戳转成可读日期 df[datetime] pd.to_datetime(df[timestamp], units) df[date] df[datetime].dt.date df[hour] df[datetime].dt.hour # 3) 缺失值检查 print(df.isnull().sum()) df df.dropna(subset[user_id, item_id]) # 4) 基本异常值过滤 df df[df[user_id] 0] df df[df[item_id] 0]说明units 表示 timestamp 字段是以秒为单位的 Unix 时间戳常见 10 位数字如果原始值类似 1609459200000 这种 13 位数字要把参数改成 unitms。这一步没对齐日期会整体偏移是所有后续分析的第一个坑。dropna 只删掉 user_id 和 item_id 为空的记录因为这两个字段没值就没办法做用户或商品维度的聚合。清洗之后建议把结果落一份副本df.to_parquet(behavior_cleaned.parquet, indexFalse)不推荐存 CSV中文和数据类型容易二次出错parquet 保留类型、压缩率高后面反复读也不会撑爆内存。3. EDA 和特征工程把行为日志变成推荐模型的输入3.1 用户活跃度和转化漏斗三张图看清业务在碰模型之前先回答三个业务问题用户每天活跃在哪些时段从浏览到购买每一步转化率是多少哪些商品类目贡献了大部分购买这三个问题决定了后面特征工程怎么做也决定了推荐列表的排序目标。import matplotlib.pyplot as plt import seaborn as sns # 图 1按小时统计行为量 hourly df.groupby(hour).size().reset_index(namecount) plt.figure(figsize(8, 4)) sns.lineplot(datahourly, xhour, ycount) plt.title(按小时行为量分布) plt.show() # 图 2行为转化漏斗 behavior_counts df[behavior_type].value_counts().reindex([pv, fav, cart, buy]) plt.figure(figsize(6, 4)) sns.barplot(xbehavior_counts.index, ybehavior_counts.values) plt.title(浏览-收藏-加购-购买漏斗) plt.show() # 图 3Top 类目购买人数 top_cats df_items.merge(df, onitem_id) \ .query(behavior_type buy) \ .groupby(category)[user_id].nunique() \ .sort_values(ascendingFalse).head(10) top_cats.plot(kindbar) plt.title(Top 10 类目购买人数) plt.show()逻辑说明第一张图帮你判断流量高峰时段特征工程里可以加「是否晚间活跃」这类特征第二张图是漏斗电商里 pv 到 buy 的转化一般在 1%~3%如果明显偏高或偏低要去核对数据口径第三张图看类目集中度如果购买集中在前 10 个类目推荐排序时可以给这些类目更高权重。参数说明value_counts().reindex 是为了保证图上顺序是 pv、fav、cart、buy而不是按出现次数乱排。groupby 之后用 nunique 统计购买人数比 count 更能排除同一用户反复购买对类目活跃度的影响。3.2 用户-商品行为矩阵协同过滤的基础输入长什么样推荐模型的输入不是长表格而是矩阵。用户做行、商品做列、行为加权值做单元格。大多数推荐算法都吃这个结构只是内部实现不同。先把行为映射成数值才是关键一步# 行为加权浏览 1 分收藏 1 分加购 1 分购买 2 分 behavior_score {pv: 1, fav: 1, cart: 1, buy: 2} df[score] df[behavior_type].map(behavior_score) # user 行、item 列的稀疏矩阵 user_item df.pivot_table( indexuser_id, columnsitem_id, valuesscore, aggfuncsum, # 同一用户对同一商品多次行为score 累加 fill_value0 ) print(user_item.shape) # 稀疏度非零元素占比 nonzero_ratio (user_item 0).sum().sum() / (user_item.shape[0] * user_item.shape[1]) print(f稀疏度: {nonzero_ratio:.6f})逻辑说明aggfuncsum 的含义是如果同一个用户对同一个商品点击过 3 次又买了那么这个格子得分就是 3×125。如果换成 max则更多反映有没有发生过强行为事件而不是次数。稀疏度这一行长什么样直接决定后面用 ItemCF 还是 SVD稀疏度低于万分之几是正常现象不用慌。参数说明pivot_table 返回的 DataFrame 行数等于用户数列数等于商品数。几万个用户乘几万个商品就是几亿个格子这个矩阵在内存里会比较占地方所以我一般先按「行为次数不低于 2 次」过滤一遍用户把极少活跃的噪声用户去掉矩阵能小一圈。3.3 特征工程把行为日志变成可输入模型的 Feature从行为表构造用户画像特征可以喂给逻辑回归、随机森林这类模型做购买预测也可以直接拿来做人货匹配规则。这里的核心是聚合窗口的选择用全量历史聚合容易产生数据泄漏后面第四章评估一节会详细说明为什么。user_feat df.groupby(user_id).agg( total_actions(behavior_type, count), buys(behavior_type, lambda x: (x buy).sum()), carts(behavior_type, lambda x: (x cart).sum()), favorites(behavior_type, lambda x: (x fav).sum()), unique_items(item_id, nunique), last_active_hour(hour, max), active_days(date, nunique) ).reset_index() user_feat[purchase_rate] user_feat[buys] / user_feat[total_actions] user_feat[cart_to_buy_rate] user_feat[buys] / (user_feat[carts] 1e-6) user_feat.head()这段的产出是用户维度特征表每行一个用户每列一个特征。purchase_rate 和 cart_to_buy_rate 都是比率类特征加 1e-6 是防止除零报错。活跃天数 active_days 用来区分一次性用户和回头客在很多商业推荐里活跃用户数本身就应该作为人群分层的依据。特征构造好之后再配合第四章的标签列就能训练一个「是否购买」的分类模型这也是摘要里提到的逻辑回归常见切入点。4. 推荐模型与评估ItemCF、SVD 和离线指标一次跑通4.1 ItemCF 协同过滤候选集怎么来ItemCF 的基本假设是用户对和自己之前买过的东西相似的商品感兴趣。相似不看商品属性而看行为——两个商品经常被同一批用户交互就认为是相似的。下面这段是完整可跑的 ItemCF 实现import numpy as np from sklearn.metrics.pairwise import cosine_similarity # 转成 item-user 矩阵行商品列用户 item_user user_item.T # shape (n_items, n_users) # 余弦相似度矩阵 item_sim cosine_similarity(item_user, item_user) np.fill_diagonal(item_sim, 0) # 自己和自己不算相似 item_sim_df pd.DataFrame(item_sim, indexitem_user.index, columnsitem_user.index)逻辑说明cosine_similarity 逐对计算商品向量计算公式是点击交集除以两个向量的模长。两个商品相似度高是因为它们的共同用户多、向量夹角小。np.fill_diagonal 把对角线上的 1 置 0避免推荐出自己的 id。这里有一个容易被忽略的问题如果某个商品只有一两个用户交互过它的向量和谁都算不出相似度这部分商品天然会被 ItemCF 忽略第四章最后会讲怎么兜底。接着给目标用户生成推荐列表def recommend_by_itemcf(user_id, top_n10): interacted user_item.loc[user_id] acted_items interacted[interacted 0].index.tolist() score np.zeros(len(item_sim_df)) for item in acted_items: # 取出该商品与其他商品的相似度向量 score item_sim_df[item].values # 已经交互过的商品不重复推荐 score[user_item.columns.get_indexer(acted_items)] 0 top_idx np.argsort(-score)[:top_n] return user_item.columns[top_idx].tolist()逻辑说明score 向量长度等于商品数遍历用户交互过的商品把这些商品在相似度矩阵里的行向量累加得到的 score 表示候选商品与用户历史行为的总体相似度。复杂度是「交互商品数 × 商品总数」这个量级几万商品可以忍受如果是百万级商品这段循环就要改成矩阵向量乘法否则跑起来够你喝一壶的。给已经交互过的商品强制置 0是推荐系统必做的防重复动作。4.2 SVD 矩阵分解给稀疏矩阵降维找隐藏向量第二类方案是矩阵分解。SVD 把 user_item 矩阵拆成三个矩阵的乘积再取前 k 个奇异值就得到了用户向量和商品向量。原始矩阵里没观测到的格子在降维后的向量空间中能获得预测值这就是它比 ItemCF 更擅长发现「远亲」商品的原因。from sklearn.decomposition import TruncatedSVD svd TruncatedSVD(n_components30, random_state42) item_factors svd.fit_transform(item_user) # 商品向量shape (n_items, 30) # 预测行为分数用 inverse_transform 做近似回代 reconstructed svd.inverse_transform(item_factors) # 对某个用户排序出 TopN user_id 10086 user_row user_item.loc[user_id].values pred reconstructed.dot(user_row) # (n_items,) 预测分 pred[user_item.loc[user_id].values 0] 0 # 屏蔽已有交互 top_n user_item.columns[np.argsort(-pred)[:10]] print(top_n)n_components 是降维维度经验取值 20 到 50。太小向量表达不了多个兴趣主题太大降维失去意义内存和训练时间也会涨。TruncatedSVD 和 PCA 的区别在于PCA 要先减均值而 TruncatedSVD 直接对稀疏矩阵做部分奇异值分解所以更适合 user_item 这种大部分为 0 的矩阵。预测分数是通过重构矩阵点乘用户行为向量得到的哪个商品得分高实质是它的隐向量和用户历史行为的隐向量更匹配。ItemCF 和 SVD 的取舍我一般看两个点如果业务方要求推荐理由可解释说「因为你看过 A所以推荐 A 的相似款」就选 ItemCF如果数据非常稀疏而且更看重召回精度就选 SVD。SVD 有个代价是结果不可解释给业务宣讲时会被问「为什么推荐这个」你要提前准备措辞。4.3 模型评估精确率、召回率、覆盖率一次算清推荐系统的离线评估和分类模型有区别不能只看准确率。购买行为在总体行为里占比极低如果模型永远推荐热卖品准确率也能很好看但用户根本不买账。所以评估要同时看精确率、召回率和覆盖率# 按时间切分最后一天做测试之前做训练 test_date df[date].max() train_df df[df[date] test_date] test_df df[df[date] test_date] # 测试集里真正购买的商品作 ground truth test_buy test_df[test_df[behavior_type] buy] test_user_actual test_buy.groupby(user_id)[item_id].apply(set).to_dict() # 用 train_df 重算 user_item再对测试用户推荐 top_u list(test_user_actual.keys())[:200] precisions [] recalls [] for u in top_u: rec_list recommend_by_itemcf(u, 10) act_set test_user_actual[u] if not act_set: continue hit len(set(rec_list) act_set) precisions.append(hit / 10) recalls.append(hit / len(act_set)) print(平均精确率 Precision10:, sum(precisions) / len(precisions)) print(平均召回率 Recall10:, sum(recalls) / len(recalls))参数说明top_n10 表示推荐列表长度精确率是推荐列表里真正命中的比例召回率是用户实际购买里有几个被推荐到。这两个指标一个看准不准一个看全不全。注意这里必须按时间切分而不是随机切分随机切分会把未来信息泄漏到训练集里的模型学到「答案」线下指标虚高上线立刻打回原形。覆盖率也要算all_rec [] for u in top_u: all_rec.extend(recommend_by_itemcf(u, 10)) coverage len(set(all_rec)) / user_item.shape[1] print(商品覆盖率:, coverage)覆盖率表示推荐列表覆盖了多少商品。如果覆盖率只有个位数百分比说明推荐结果全压在少数爆款上长尾商品完全没有曝光机会。电商场景覆盖率太低的系统短期指标好看长期会让流量越来越极端品牌方的腰部商品没人理的。项目里如果还有逻辑回归做购买预测的代码记得配套算一下 ROC 曲线二分类问题只看准确率在这个场景里基本没有参考价值。5. 常见问题与避坑乱码、内存溢出与稀疏矩阵三个坑5.1 Excel 和 SQL 读进来全是乱码现象用 read_excel 读 123.xls中文列名变成乱码用 read_sql 从 MySQL 读行为表中文变成 ???。原因连接 MySQL 时没有指定 charset或者导入 7law.sql 时表默认字符集不是 utf8mb4老版 .xls 文件内部编码常常是 GBKpandas 没做自动识别。解决MySQL 连接参数强制写 charsetutf8mb4导入 sql 后先 show create table 检查表定义发现有 latin1 就重新建表导一次。xls 文件用 enginexlrd 打开如果还乱码先读取原始字节用 chardet 检测编码再处理import chardet with open(123.xls, rb) as f: raw f.read(1000) print(chardet.detect(raw))这个检测结果告诉你文件实际编码再在后续读取或转码时对症下药。别在同一个乱码上反复重跑每次浪费时间半小时。5.2 全表读入内存就爆现象notebook 执行 read_sql(SELECT * FROM user_behavior, conn)内核直接崩了或者等很久才出结果。原因行为数据动辄几百万行全字段全行加载pandas 自动推断 dtype 会把 user_id 读成 int64白白多用一倍内存。解决先在 SQL 里做列裁剪和时间过滤再在 read_sql 时指定 dtypesdf pd.read_sql( SELECT user_id, item_id, behavior_type, timestamp FROM user_behavior, conn, dtype{user_id: int32, item_id: int32} )int32 能撑到 21 亿对用户 id 和商品 id 来说完全够用。聚合结果存 parquet清洗阶段的中间结果不要反复读原表。5.3 Unix 时间戳单位搞错日期全乱现象datetime 转出来是 1970-01-01 附近的时间或者发现日期整体差了一天。原因把毫秒时间戳当秒用了或者反过来。10 位数字是秒对应 units13 位数字一般是毫秒对应 unitms。解决拿到 timestamp 先看位数别靠猜sample_ts df[timestamp].iloc[0] if sample_ts 1e12: df[datetime] pd.to_datetime(df[timestamp], unitms) else: df[datetime] pd.to_datetime(df[timestamp], units)这段逻辑放在数据清洗开头能省掉后面所有时间相关分析的返工。这个坑我栽过一次后再也没跳过属于典型的血泪经验。5.4 稀疏矩阵算出来的相似度全是 0现象item_sim 矩阵里大部分值趋近于 0cosine_similarity 输出一堆警告推荐列表全是热门商品。原因用户、商品粒度太细两个商品同时被同一用户交互的样本太少全量行为矩阵太稀疏相似度信号被噪声淹没。解决先过滤掉交互次数少于阈值的商品再算相似度item_cnt df.groupby(item_id).size() valid_items item_cnt[item_cnt 5].index df_filt df[df[item_id].isin(valid_items)]阈值可以从 3 试到 10看推荐结果覆盖面变化。如果过滤完还是稀疏把 ItemCF 换成 SVDSVD 对冷门物品更友好因为向量空间是压缩过的不会出现「分母为零」的尴尬。5.5 只盯准确率推荐结果却被用户无视现象离线报告里准确率 90% 以上上了线点击率却很难看。原因行为数据极端不平衡购买行为只占极小比例准确率被多数类主导模型学到的其实是「什么都不推也是对的」这个结论。解决离线评估把精确率、召回率、覆盖率放一起看再加一道多样性检查看推荐列表里是否只包含少数热门商品from collections import Counter rec_items [item for u in top_u for item in recommend_by_itemcf(u, 10)] size_dist Counter(rec_items).most_common(10) print(出现最多的 10 个商品占比:, sum(v for k, v in size_dist) / len(rec_items))如果前 10 个商品占掉了一半推荐位说明多样性出问题了纯度太高的推荐会让人审美疲劳。加一个规则兜底每个用户的推荐列表里至少保留两三个非热门商品通常能改善体验。6. 进阶验证时间切分、冷启动兜底与推荐多样性6.1 时间切分必须强制做推荐模型的离线评估时间切分不是可选项是必须项。随机切分的问题在于同一用户的行为被拆到训练集和测试集模型在训练时已经见过测试集里的商品交互评估自然虚高。正确做法是按日期排序前 80% 时间窗口做训练后 20% 做测试。如果项目里行为记录跨越了多个自然周我倾向直接用最后一周做测试集这样更能模拟线上真实场景也能顺带看出推荐结果有没有明显的时效性偏差。6.2 冷启动兜底策略新用户没有历史行为ItemCF 和 SVD 都算不出分数。这是推荐系统绕不开的冷启动问题。项目里常见做法是对新用户直接推全局热榜等他有了一次浏览行为再切换成个性化推荐。热榜可以按「购买人数 × 行为加权」来算比如买过的人权重高、加购的人次之、点击的人再次之。另一条路是基于商品属性的召回新商品进来时没有行为数据就用它的类目、品牌去匹配老商品这个效果通常比纯热榜好但前提是商品维度表得干净类目字段不能有大量空值。6.3 我的验证习惯我把离线评估跑完一圈之后还会做一遍覆盖率和多样性检查然后手动抽查十个测试用户的推荐列表看看推荐理由是否说得通。Model 打分是一回事推荐列表看起来是不是符合常识是另一回事——有些模型指标挺好推荐出来的商品却是用户根本不感兴趣的品类。从那以后我每次拿到电商行为数据集都会强制走一遍时间切分 覆盖率 人工抽检这三个步骤顺序固定的不做完不算模型跑通。数据挖掘和机器学习实战最容易翻车的地方不在模型而在数据口径和数据泄漏希望你跑这个项目的时候能少踩我当时踩过的那些坑。希望帮到你。本文还有配套的精品资源点击获取