1. 项目概述与核心价值去年带队参加MathorCup大数据竞赛的经历至今记忆犹新。当时我们选的就是B题——北京移动用户体验影响因素研究。这个题目非常“接地气”它把我们从纯理论的算法世界一下子拉到了真实的商业场景里。问题二作为整个赛题承上启下的关键一环其核心任务是基于海量的用户信令数据构建一个能够量化评估北京移动网络用户体验的指标体系并对不同区域、不同时段的用户体验进行精细化画像与归因分析。简单来说我们手里有北京移动用户几个月内产生的、以TB计的信令数据XDR里面包含了用户何时何地使用了什么业务、网络质量如何等海量信息。问题二就是要求我们从这片数据的“海洋”里提炼出能代表“用户体验好与坏”的关键信号并回答北京的移动网络体验整体怎么样哪里好哪里差为什么差这不仅仅是一个数据分析或建模问题更是一个典型的“业务驱动型”数据科学项目。它要求参赛者不仅要有扎实的机器学习、统计分析功底更要有将技术指标如下载速率、时延转化为业务语言如视频卡顿、网页打开慢的能力并最终给出具有可操作性的洞察。对于从事数据分析、通信优化、甚至产品运营的同学来说这类问题的解决思路具有很高的普适性和参考价值。接下来我将详细拆解我们当时针对问题二的完整分析框架、实操步骤以及那些“踩过坑”才得来的经验。2. 问题二的整体分析框架与设计思路面对“用户体验评估”这样一个宏大且略显模糊的目标第一步也是最关键的一步就是建立清晰、可量化的分析框架。直接扎进数据里跑模型很容易迷失方向。2.1 核心目标拆解从“评估”到“归因”我们首先将问题二的目标拆解为三个递进的层次量化评估Measurement定义并计算出一套能够代表用户体验的量化指标。这是所有后续分析的基础。现状画像Profiling利用这些指标对全北京不同维度如行政区、商圈、时间段的网络体验进行“扫描”和“打分”形成一份体验“地图”。根因分析Root Cause Analysis针对画像中发现的“体验洼地”即体验差的区域深入分析其背后的可能原因是容量不足、干扰太大还是覆盖太差这个“评估-画像-归因”的三段式框架确保了整个分析过程逻辑严密、目标明确。2.2 指标体系构建连接数据与业务的桥梁信令数据字段繁多如何选取和构造指标是核心挑战。我们的设计原则是全面性、可解释性、可获取性。我们构建了一个三层指标体系第一层核心体验指标What - 用户感知层这一层直接对应用户可感知的业务体验。我们主要聚焦于最主流的业务类型视频业务体验采用“视频初始缓冲时长”和“视频播放卡顿占比”作为核心指标。前者影响打开速度后者影响观看流畅度。网页浏览体验采用“页面首屏时延”作为核心指标即从发起请求到首屏内容加载完成的时间。即时通信体验采用“消息发送成功率”和“端到端时延”作为核心指标。注意指标定义必须与数据字段严格对齐。例如“视频播放卡顿占比”不能简单用“速率低”来代表而是需要根据信令数据中的“缓冲事件”或“吞吐量骤降”记录来精确定义。我们当时就花了大量时间与数据字典“死磕”确保每个指标的计算逻辑无歧义。第二层网络质量指标Why - 网络性能层这一层用于解释核心体验指标好坏的原因。它是连接用户感知与网络状态的桥梁。覆盖与接入质量RSRP参考信号接收功率、SINR信号与干扰加噪声比、接入成功率。容量与速率平均吞吐率Downlink/Upload Throughput、PRB物理资源块利用率。移动性与保持性切换成功率、掉线率。第三层维度指标Where/When - 空间与时间层这一层用于对上述指标进行切片分析形成画像。空间维度基于基站Cell的经纬度聚合到不同地理层级如行政区海淀区、重点商圈国贸CBD、交通干线地铁10号线、甚至自定义的栅格500m*500m。时间维度小时级早高峰、晚高峰、日级工作日、周末、节假日。通过这个三层指标体系我们就能清晰地回答在国贸CBD工作日的晚高峰维度视频卡顿率体验很高可能原因是该区域平均SINR较低且PRB利用率过高网络质量。2.3 技术选型与工具栈考虑到数据量巨大TB级且分析维度复杂我们选择了以下技术栈数据处理PySpark。这是处理海量信令数据的绝对主力。Pandas在单机处理千万级数据时已力不从心而Spark的分布式计算能力可以轻松应对。我们将原始XDR数据存储在HDFS上使用Spark SQL进行数据清洗、过滤和初步聚合。指标计算与画像SQLSpark SQL PythonPandas。在Spark中完成粗粒度的指标计算和按区域、时间的初步聚合将结果数据通常降至GB级导出到本地或数据库再用Pandas进行更灵活、更复杂的多维分析和交叉计算。空间分析GeoPandas。用于将基站经纬度与地理边界如行政区划Shapefile文件进行关联实现“点”基站到“面”区域的映射这是绘制体验地图的关键。可视化Matplotlib/Seaborn Plotly可选 高德/百度地图API。静态图表用于展示趋势和分布交互式地图结合地图API用于直观展示体验的地理分布热力图。归因分析统计学方法相关性分析、假设检验 机器学习聚类分析、决策树/随机森林。先用相关性分析找出与差体验强相关的网络指标再用聚类对差小区进行分群最后用树模型如随机森林对关键影响因素进行排序和解释。这个工具链的核心思想是“分而治之”用Spark解决“量”的问题用Python生态解决“质”深度分析的问题。3. 核心细节解析与实操要点有了框架和工具接下来就是落地。这个过程充满了细节挑战。3.1 数据预处理脏数据是最大的“坑”信令数据是出了名的“脏”。直接用于计算结果必然失真。预处理是关键的第一步我们建立了严格的数据清洗流水线无效记录过滤字段缺失关键字段如时间戳、用户标识、基站标识、业务类型为空或无效的记录直接丢弃。异常值处理对于速率、时延等连续变量我们使用“分位数法”结合业务常识进行截断。例如下载速率大于1Gbps或小于1kbps的记录在物理上几乎不可能视为异常值。# 示例使用Spark SQL过滤异常速率记录 clean_df spark.sql( SELECT * FROM raw_xdr_table WHERE dl_throughput IS NOT NULL AND dl_throughput 10 -- 假设小于10kbps为异常 AND dl_throughput 1000000 -- 假设大于1Gbps为异常 )业务场景关联与切片信令数据中的“业务类型”字段需要映射到具体的体验场景视频、网页、微信等。我们维护了一个映射字典。一次完整的业务会话如下载一个文件可能由多条信令记录组成。需要通过“会话ID”或“流程ID”将这些记录关联起来才能计算会话级的体验指标如总下载时长、平均速率。用户与基站画像关联数据中通常包含用户等级如VIP用户、终端类型iPhone 14 vs 千元机、以及基站的基础信息频段、设备型号。务必在预处理阶段就将这些维度属性关联到每条记录上。后续分析“高端用户 vs 普通用户”、“5G终端 vs 4G终端”在不同区域的体验差异时这将无比重要。实操心得预处理阶段建议投入总时间的40%以上。建立一个可复用的、模块化的数据清洗脚本或Pipeline。清洗规则要记录在案因为任何规则的调整都可能显著影响最终结果。我们曾因为一个异常值阈值设得过于宽松导致某个区域的“平均速率”虚高差点误导了分析方向。3.2 指标计算从原始信令到体验分数指标计算不是简单的求平均值需要精细的设计。聚合层级的选择用户级聚合先计算单个用户在某个时间窗口内如1小时的体验指标如该用户本小时的平均视频卡顿率。这能反映个体体验分布。小区级/区域级聚合将用户级指标在某个地理区域如一个基站覆盖范围或一个行政区内进行二次聚合。这里的关键是选择正确的聚合函数。对于速率类指标我们采用用户感知平均先计算每个用户的平均速率再对所有用户的平均值求平均。这比直接对所有速率记录求平均更能代表用户的真实感受。对于时延、卡顿率类指标我们同时关注平均值和差体验比例如时延大于5秒的会话占比。后者往往更能揭示问题。体验综合评分 为了得到一个直观的、可横向比较的分数我们将多个体验指标合成一个“用户体验指数”。我们采用了加权TOPSIS法。步骤一指标归一化。将速率效益型越大越好、时延成本型越小越好等不同量纲的指标归一化到[0,1]区间。步骤二确定权重。我们通过熵权法结合专家打分来确定权重。熵权法基于数据本身的离散程度给指标赋权区分度大的指标权重高专家打分则引入了业务重要性如“视频卡顿率”比“消息时延”对整体体验影响更大。两者结合更为客观。步骤三计算得分。计算每个评价对象如每个小区与正理想解最优体验和负理想解最差体验的距离从而得到一个相对接近度分数0-100分。这个综合分数就是我们绘制“北京移动网络体验地图”的底色。3.3 空间分析与可视化让数据“说话”将数字转化为直观的地图是向评委或业务方呈现结论的最有力方式。地理栅格化 直接按行政区分析可能颗粒度太粗。我们将北京地图划分为500m*500m的规则栅格将所有信令事件根据其经纬度分配到对应的栅格中再计算每个栅格内的体验指标。这种方法能更精细地定位问题点不受行政边界的限制。热力图绘制 使用Python的folium或kepler.gl库将栅格化的体验分数如综合得分、卡顿率以热力图形式叠加在高德地图底图上。颜色从绿好到红差渐变问题区域一目了然。import folium from folium.plugins import HeatMap # 假设grid_data是一个DataFrame包含‘lat’ ‘lon’ ‘score’列 m folium.Map(location[39.9, 116.4], zoom_start11) heat_data [[row[lat], row[lon], row[score]] for index, row in grid_data.iterrows()] HeatMap(heat_data, radius15, blur10, max_zoom1).add_to(m) m.save(beijing_experience_heatmap.html)多维度联动下钻 一张静态热力图不够。我们使用Plotly Dash搭建了一个简单的交互看板。可以筛选时间查看早高峰vs晚高峰、筛选业务只看视频体验、点击某个红色栅格下钻查看该区域具体的指标明细如各小区的RSRP、利用率情况。这种交互性在答辩展示时极具说服力。4. 实操过程与核心环节实现这里以“定位视频业务体验洼地并归因”为例展示一个完整的分析闭环。4.1 步骤一数据准备与指标计算假设我们已经完成了清洗得到了干净的会话级数据表video_sessions。-- Spark SQL 示例计算每个小区cell_id每小时的视频体验指标 CREATE OR REPLACE TEMP VIEW cell_hourly_video_stats AS SELECT cell_id, DATE_TRUNC(HOUR, start_time) as hour_bucket, COUNT(*) as session_count, AVG(initial_buffering_delay) as avg_buffering_delay, SUM(CASE WHEN stalling_ratio 0.05 THEN 1 ELSE 0 END) / COUNT(*) as high_stalling_session_ratio, -- 卡顿率5%视为差体验会话 AVG(dl_throughput) as avg_dl_throughput, APPROX_PERCENTILE(rsrp, 0.5) as median_rsrp, -- 使用中位数更抗干扰 AVG(prb_utilization) as avg_prb_util FROM video_sessions WHERE start_time BETWEEN ‘2022-xx-xx’ AND ‘2022-xx-xx’ GROUP BY cell_id, DATE_TRUNC(HOUR, start_time) HAVING COUNT(*) 10 -- 过滤样本量过少的小区-小时避免统计噪声4.2 步骤二识别体验洼地我们将“高卡顿会话占比”大于15%的小区-小时对定义为“体验洼地”。import pandas as pd # 将Spark结果转为Pandas DataFrame数据量已大幅减少 df_cell_stats spark.table(cell_hourly_video_stats).toPandas() # 识别洼地 problem_spots df_cell_stats[df_cell_stats[‘high_stalling_session_ratio’] 0.15].copy() print(f识别出体验洼地记录数{len(problem_spots)})4.3 步骤三关联网络质量数据进行归因分析现在我们需要看看这些“洼地”的网络质量指标有什么共同特征。# 1. 描述性统计对比对比“洼地”和“非洼地”的网络指标分布 non_problem_spots df_cell_stats[df_cell_stats[‘high_stalling_session_ratio’] 0.15] comparison_summary pd.DataFrame({ ‘指标’: [‘平均PRB利用率’, ‘RSRP中位数’, ‘平均下行速率’], ‘洼地均值’: [ problem_spots[‘avg_prb_util’].mean(), problem_spots[‘median_rsrp’].mean(), problem_spots[‘avg_dl_throughput’].mean() / 1000, # 转换为Mbps ], ‘非洼地均值’: [ non_problem_spots[‘avg_prb_util’].mean(), non_problem_spots[‘median_rsrp’].mean(), non_problem_spots[‘avg_dl_throughput’].mean() / 1000, ] }) print(comparison_summary) # 2. 相关性分析 import seaborn as sns import matplotlib.pyplot as plt # 计算洼地数据中卡顿率与各网络指标的相关性 correlation_matrix problem_spots[[‘high_stalling_session_ratio’, ‘avg_prb_util’, ‘median_rsrp’, ‘avg_dl_throughput’]].corr() sns.heatmap(correlation_matrix, annotTrue, cmap‘coolwarm’, center0) plt.title(‘体验洼地内指标相关性热图’) plt.show()通过这一步我们可能发现在体验洼地中“高卡顿率”与“高PRB利用率”呈现强正相关而与“RSRP中位数”相关性较弱。这初步暗示容量拥塞可能是主因而非单纯的覆盖差。4.4 步骤四深入诊断与问题分群为了进一步验证我们可以对“洼地”进行聚类分析看看是否存在不同的问题类型。from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler # 选择用于聚类的特征 features_for_clustering problem_spots[[‘avg_prb_util’, ‘median_rsrp’, ‘avg_dl_throughput’]].fillna(0) # 标准化 scaler StandardScaler() features_scaled scaler.fit_transform(features_for_clustering) # 使用肘部法则或轮廓系数确定K值这里假设K3 kmeans KMeans(n_clusters3, random_state42) problem_spots[‘cluster_label’] kmeans.fit_predict(features_scaled) # 分析每个簇的特征 cluster_profile problem_spots.groupby(‘cluster_label’)[[‘avg_prb_util’, ‘median_rsrp’, ‘avg_dl_throughput’, ‘high_stalling_session_ratio’]].mean() print(cluster_profile)假设我们得到三个簇簇APRB利用率极高80%RSRP尚可速率极低。典型特征容量瓶颈。簇BPRB利用率中等RSRP极低-110dBm速率低。典型特征弱覆盖。簇CPRB利用率高RSRP也低速率低。典型特征覆盖差容量不足的综合症。这样的分群结果使得后续的优化建议可以非常有针对性对簇A的小区建议扩容增加载波对簇B的小区建议补点新建基站或调整天线对簇C的小区则需要综合施策。5. 常见问题与排查技巧实录在实际操作中我们遇到了不少坑也总结了一些排查技巧。5.1 数据代表性偏差问题分析发现某个偏远区域体验分数奇高不符合常识。排查检查该区域的样本量。发现总会话数很少100且大部分是深夜的低流量业务。这属于样本偏差少量“好”的记录拉高了平均值。解决在区域聚合时必须设置最小样本量阈值如我们设置的HAVING COUNT(*) 10。同时在呈现结论时对样本量不足的区域要标注“数据仅供参考”或直接灰度显示。5.2 指标“打架”与矛盾问题某个区域RSRP信号强度很好但速率和体验分数却很差。排查检查SINR信号质量RSRP好不代表SINR好。可能存在强干扰源如私装放大器导致信噪比差速率上不去。检查PRB利用率可能该小区用户数不多但个别用户在进行大流量业务如BT下载占满了资源导致其他用户排队。检查传输层问题可能是基站到核心网的回传链路Backhaul存在瓶颈或故障。这需要关联传输网管数据在纯无线侧数据中很难直接发现。解决建立多指标联合诊断矩阵。例如绘制“RSRP-SINR-吞吐率”的三维散点图或制定如下诊断规则表场景RSRPSINRPRB利用率可能根因建议措施场景1优优高容量拥塞扩容、负载均衡场景2优差低存在干扰扫频排查干扰源场景3差差低弱覆盖工程优化、补点场景4优优低但速率差传输/核心网问题联合传输专业排查5.3 时间周期带来的误导问题整体日平均体验不错但用户投诉集中在晚高峰。排查只做了日级聚合掩盖了时段差异。解决必须进行多时间粒度分析。除了日级一定要做小时级甚至更细的分析。绘制24小时指标趋势曲线并与话务量曲线叠加可以清晰看到“潮汐效应”对体验的影响。优化资源调度策略如在晚高峰开启更多载波往往能取得立竿见影的效果。5.4 模型过拟合与解释性问题在归因分析中使用复杂的深度学习模型如神经网络虽然预测准确率高但无法解释到底是哪个因素最重要。解决在竞赛和实际运维中解释性往往比绝对的预测精度更重要。我们优先使用随机森林或XGBoost这类树模型它们既能提供不错的精度又能输出特征重要性Feature Importance直观地告诉我们“PRB利用率”比“RSRP”对卡顿率的贡献度大多少。这比黑盒模型给出的结论更有说服力和指导意义。完成问题二的分析我们得到的不只是一份报告或几个模型而是一套完整的、从数据到洞察的方法论。它告诉我们好的数据分析始于对业务的深刻理解构建正确的指标体系成于对细节的严谨把控数据清洗与计算终于对结果的清晰呈现和合理解释可视化与归因。这套思路对于任何希望通过数据驱动体验优化、运营提效的领域都具有很高的借鉴价值。