简介这是一份面向电信运营商及宽带业务规划人员的专业PPT课件聚焦如何借助大数据技术开展家庭宽带总体规划。内容从计划、网络、市场、财务、客服等多部门需求出发梳理背景现状、需求解读、整体架构、宽带战略地图与规划目标针对成本监控缺失、资费欺诈风险、客户价值提升困难等痛点提出系统化解决方案。资源包包含1个pptx文件大小2.3MB已有92人学习。课件共27页涵盖接入层网元标准化、物理小区映射、B域/O域数据接入、24个能力模型及GIS地图应用等核心模块并围绕客户体验提升、资源优化、风险控制给出落地路径。读者可通过本课件快速理解家宽大数据规划的顶层设计思路掌握从数据接入、能力封装到平台应用的全链条方法以及网络感知、客户保有、投诉分析等实战模块适合作为企业培训、方案汇报或课程教学参考。1. 一份27页PPT把家宽规划从“拍脑袋”拉回“数据驱动”做家宽规划的人都有体会市场部要拉新策反计划部要看成本效益网运部要处理投诉财务部要算盈亏客服部要背满意度——但大家看的往往是同一张拓扑图、同一份端口利用率周报。PPT里提到的“网元地图只有文字和型号”“投资完成后无法评估资源效益”“资费欺诈识别靠事后人工对账”这些问题不是缺系统而是缺一条能把B域计费、O域网管、M域财务数据串起来的主线。这篇内容来自一份27页的总体规划课件核心思路是把大数据能力拆成“数据接入—融合模型—GIS作战地图—运营闭环”四层用常驻识别、家庭客户挖掘、8D选址、网络感知等26个模型解决“潜在客户在哪、网元该建在哪、钱花得值不值”这三个本源问题。适合正在做固网规划、大数据应用或宽带运营体系的人参考。2. 规划前的数据底盘B/O/M三域接入与标准化2.1 家宽规划到底缺哪些数据课件里的需求解读部分把家宽规划要用的数据分成四类。第一类是接入层网元信息AP、ONU、ODN、PON、OLT、BRAS这些设备的数据很多还停留在手工台账阶段ONU端口与实际账号不匹配、销户不拆线是常态。第二类是用户侧数据宽带账号、订购、鉴权、拨号日志、装维工单。第三类是网络感知数据页面访问速率、时延、成功率、视频卡顿这类质量指标。第四类是财务数据资产损益、COA科目、用户记账月报。这里有一个容易被低估的问题端口信息不准会直接污染后续所有建模。比如做网元-用户映射时如果ONU端口对应的是错误账号那么高价值用户会被归到错误的小区8D选址里的“业务承载”维度就失真了。所以课件里才把“网元信息录入规范”放在需求第一位而不是先上模型。数据接入的现状是B域和O域已有部分数据但缺少AAA日志、QoS日志、xDR话单、网元设备信息等关键来源。按课件的接口清单估算需要从BOSS/CRM、综资、DSMP、网管、ERP等系统接入至少51类接口涉及100个具体接口。这些接口的体量差异很大Radius日志和Wlan上网日志是亿级/天的记录而POS端口管理表可能是万级。如果都按同一套采集频率跑会给源系统造成不必要的压力。数据域典型接口使用场景更新频率建议B域家宽标准地址接口、宽带拨号日志、宽带资费信息表、零流量清单用户归集、套餐分析、沉默用户识别日增量同步T1O域ONU端口、OLT/BRAS配置、Radius日志、AP信息、信令数据网元地图、端口核查、网络性能分析小时级或日级M域资产损益月表、COA科目费用月表、用户记账月报、收入结算效益评估、成本核算、盈亏分析月级或按自然月触发2.2 从接口清单到数据总线100接口怎么接课件整体架构里提到“开放的数据总线”这层在工程实现上通常承担三件事接口调度、格式转换、数据质量稽核。我见到的做法是先对51类接口做分级按数据量、实时性、重要度分成三类避免所有数据都走同一套流程导致瓶颈。# 以ONU端口数据和Radius日志为例演示分级调度逻辑 import pandas as pd from datetime import datetime def load_bill_data(interface_id, data_date): 接口数据装载B域业务数据按天全量/增量拉取 - interface_id: 接口编号如 B_019 代表宽带拨号日志 - data_date: 业务日期 返回DataFrame并做基础空值校验 # 实际项目中这里会从kafka或hive分区读取此处以CSV示意 df pd.read_csv(f/data/raw/{interface_id}_dt{data_date}.csv) # 关键字段非空校验账号、小区ID、网元ID required [account, community_id, onu_id] for col in required: assert df[col].notna().all(), f字段{col}存在空值阻断装载 # 去除重复端口记录防止后续映射出现一对多 df df.drop_duplicates(subset[account, enodeb_id, port_no]) return df def load_radius_log(interface_id, data_date): Radius日志按小时分区读取数据量大且字段稀疏 只保留建模需要的字段压缩存储成本 df pd.read_parquet(f/data/raw/{interface_id}/hour{data_date}/*.parquet) cols [session_id, user_ip, account, start_time, end_time, traffic_up, traffic_down] return df[cols]上面这段逻辑说明两点。第一B域数据质量校验要前置账号、小区ID、网元ID这三个字段是后续用户映射的基础空值必须在装载阶段拦截否则到了模型层排查成本翻倍。第二Radius日志这类海量数据按小时分区只提取建模必须的流量和时长字段不要一开始就把全字段存成宽表否则一个月的日志就能占满数TB空间。2.3 网元信息标准化与小区映射的常见做法课件第4页里提到了“网元地图”“用户-住宅小区映射”“栅格化”三个动作。映射链路本质上是三级网元覆盖小区小区承载用户用户归属到家庭ID。难点在于网元LAC位置区码和住宅小区坐标之间没有现成的对应关系需要算法推算。课件里给出的是基于蒙特卡洛的面积投影算法思路是先识别用户常驻LAC取该LAC内所有住宅小区的坐标以LAC质心为圆心、300米为距离阈值生成投影面积按面积占比把LAC下的用户分摊到各小区。面积投影算完只是定了“分多少”还没定“分谁”需要再用基站的方位角与映射角的对比来随机分配具体用户。import numpy as np import pandas as pd from shapely.geometry import Point, Polygon def calculate_projection_ratio(lac_point, community_polys, distance_threshold300): 蒙特卡洛面积投影计算LAC与各住宅小区的投影面积占比 - lac_point: Point基站常驻LAC的质心坐标 - community_polys: 住宅小区多边形列表 [(id, Polygon), ...] - distance_threshold: LAC覆盖半径课件中取300米 返回各小区投影面积占比 dict # 生成LAC半径范围内的随机采样点模拟用户均匀分布 np.random.seed(42) samples [] for _ in range(10000): # 在圆内均匀采样 r distance_threshold * np.sqrt(np.random.uniform()) theta np.random.uniform(0, 2 * np.pi) x lac_point.x r * np.cos(theta) y lac_point.y r * np.sin(theta) samples.append(Point(x, y)) # 统计落在每个小区多边形内的采样点数 counts {cid: 0 for cid, _ in community_polys} for pt in samples: for cid, poly in community_polys: if poly.contains(pt): counts[cid] 1 break total sum(counts.values()) # 没有采样点落中的小区则按平均分配避免除零 if total 0: return {cid: 1.0 / len(community_polys) for cid in counts} return {cid: cnt / total for cid, cnt in counts.items()}这里要注意几个坑。第一距离阈值300不是拍脑袋它来自LAC小区半径的统计中位数实际项目里要按城区、乡镇分别标定城中村和别墅区的覆盖半径差异能达到3倍以上。第二随机采样用的是均匀分布但实际用户在LAC内并非均匀更精确的做法是先按该LAC下用户的历史位置记录生成热度分布再做重要性采样。第三方位角匹配那一步不要直接用小区中心的方位角要用基站天线的法向方向也就是课件里反复强调的Ci方位角否则朝南覆盖的基站会把用户错分到北边小区。3. 26个规划模型的选型与落地从常驻识别到8D选址3.1 五大类模型框架课件第6页把模型分成基础能力、市场运营、价值评估、规划建设、服务感知五类总共规划26个模型一期建议实现14个。这个“一期14个”的取舍值得细看优先做的都是数据基础类——用户-小区映射、常驻识别、家庭识别因为后面所有拉新、策反、选址模型都要依赖这些基础标签。相反内容推荐、产品优化这类依赖行为解析的模型被放到二期原因是页面上网日志的解析匹配非常消耗算力且涉及用户隐私授权。模型大类一期/二期典型模型主要依赖数据基础能力一期栅格-小区映射、用户-小区映射、小区信息标准化综资、信令、位置LAC市场运营一期/二期潜在客户拉新、异网宽带识别、家庭客户识别、常驻迁徙B域订购、通信行为价值评估一期单条宽带效益、风险欺诈识别M域成本、B域收入规划建设一期8D选址、网元选址评估网元性能、成本、竞争服务感知一期网络感知、投诉预测、流失后评估投诉工单、性能指标3.2 常驻客户识别与家庭客户挖掘算法常驻识别是课件里写得最细的一个模型核心逻辑不复杂但工程落地要考虑几个细节。规则分两步第一步用凌晨0-6点的驻留基站识别生活常驻用9-11点和14-17点的驻留基站识别工作常驻统计周期是一个月内生活常驻20天、工作地常驻15天。第二步针对没有明显驻留特征的用户用20-24点业务量最大的基站作为生活常驻用工作时间业务量最大的基站作为工作常驻。隐蔽的坑在于“连续2个月以上常驻基站变为N才更新”这条规则。课件刻意加了这个条件是为了防止用户临时出差、旅游带来的基站漂移。实际应用中如果月底最后几天用户常驻地从M变成N而模型立即更新就可能把一个周末回老家的人误判成常驻用户进而把这个用户错误归入老家的住宅小区导致营销资源投错地方。# 常驻基站更新的状态判断伪代码按课件规则简化 def update_resident_base(station_history, cur_station, user_id, month): station_history: 历史常驻基站记录 cur_station: 当月识别出的常驻基站 规则若当月基站由M变为N不更新连续2个月以上为N才更新 prev_station station_history.get(user_id) # 上月的常驻基站 if prev_station cur_station: return prev_station # 没变化保持 # 有变化时检查前两个月是否都是N hist_2m station_history.get(f{user_id}_last2m, None) if hist_2m cur_station: # 前两个月已经变成N且连续确认更新 station_history[user_id] cur_station else: # 第一次变化记录过渡态但不更新最终结果 station_history[f{user_id}_last2m] cur_station return station_history[user_id]家庭客户识别的思路也值得展开。课件先用交往圈模型找出与用户a连续三个月通话且通话次数TOP3的用户群然后判断这些用户之间是否也互相通话形成准家庭用户对再要求这些用户对同处一个常驻生活基站下才判定为潜在家庭。家庭ID的生成规则是“基站ID小区ID序列号”主账户的确定用主叫次数和ARPU值双重排序。这套规则在实操中会遇到一个问题现在的家庭里成员可能会用亲情网套餐套餐内通话不计费所以单纯看通话详单会漏识别。补丁方案是把亲情网群组数据也放进交往圈候选或者结合位置聚合——晚上同一时间出现在同一小区且连续超过20天这样的两个人即使通话次数少也值得打上准家庭标签。3.3 8D选址评估与AHP权重计算8D选址是规划建设类的核心模型课件的写法是AHP层次分析准则层包含位置覆盖、业务承载、网络性能、成本效益、客户投诉、终端匹配、潜在发展、区域竞争这8个维度。AHP的关键是构造判断矩阵、算权重、做一致性校验。工程上专家打分没法完全避免主观偏差所以课件里写了“专家打分迭代计算”迭代这一步通常是用熵权法修正专家打分的权重让高方差的指标比如投诉量在不同区域差异很大不会因为平均而失去区分度。import numpy as np def ahp_weights(matrix): AHP权重计算与一致性校验 matrix: 8x8判断矩阵行列顺序对应8D维度 返回权重向量若CR0.1则提示重新打分 eigvals, eigvecs np.linalg.eig(matrix) max_eig np.max(eigvals) # 权重向量为最大特征值对应的归一化特征向量 idx np.argmax(eigvals) weights np.real(eigvecs[:, idx]) weights weights / weights.sum() # 一致性指标CIRI为随机一致性指标8阶取1.41 n matrix.shape[0] CI (max_eig - n) / (n - 1) CR CI / 1.41 if CR 0.1: raise ValueError(fCR{CR:.3f}0.1判断矩阵不一致需调整打分) return weights, CR # 判断矩阵示例位置覆盖比成本效益重要投诉比终端匹配重要 judge_matrix np.array([ [1, 3, 5, 1, 3, 5, 1, 3], # 位置覆盖 [1/3, 1, 3, 1/3, 1, 3, 1/3, 1], [1/5, 1/3, 1, 1/5, 1/3, 1, 1/5, 1/3], [1, 3, 5, 1, 3, 5, 1, 3], # 成本效益 [1/3, 1, 3, 1/3, 1, 3, 1/3, 1], [1/5, 1/3, 1, 1/5, 1/3, 1, 1/5, 1/3], [1, 3, 5, 1, 3, 5, 1, 3], # 潜在发展 [1/3, 1, 3, 1/3, 1, 3, 1/3, 1] ]) weights, cr ahp_weights(judge_matrix) print(8D各维度权重:, np.round(weights, 3)) print(CR一致性指标:, round(cr, 3))AHP的结果只解决“同一批候选地址怎么排序”的问题还不能解决“候选地址从哪来”的问题。实操中我会先用小区沙盘里的高价值小区做聚类把用户密度、网元覆盖盲区、竞争小区三个图层做空间叠加圈出一批候选栅格再跑AHP排序。另外要注意判断矩阵的维度和标度8维矩阵的一致性约束很强如果专家打分的CR始终过不了优先检查是不是存在两个维度高度相关比如“业务承载”和“潜在发展”这种情况需要合并维度或者用网络层次分析法的层次结构替代平级判断。4. 宽带战略地图GIS可视化与运营作战平台4.1 功能架构与视图设计课件里的宽带战略地图功能架构核心不是地图本身而是把“监控、分析、营销、评价”四类动作收敛到一张图上。基础信息层有四种视图资源视图对应网元设备用户视图对应客户与家庭小区视图对应物理小区沙盘收益视图对应盈亏热力分布。每个视图背后都是一组指标比如小区视图要看渗透率、到期客户数、微小企业识别数收益视图要看宽带成本构成、建设投资与收入。这些指标不能全部堆到一张屏幕上需要按用户角色做页面分流市场部打开的是“运营作战地图”计划部打开的是“规划选址地图”网运部打开的是“质量保障地图”。指标的下钻链路也值得设计。比如市场部首页看到某个小区的“渗透率低于目标值10个百分点”点击小区后要能下钻到三个子页面第一是用户构成多少是本网存量、多少是异网可策反、多少是未装宽带第二是竞争情况周边竞争对手网元的覆盖距离和端口利用率第三是历史趋势近半年的渗透率变化和营销活动投放时间点。课件里提到的“指标可配置化”指的就是这套下钻模板可以按省市县自定义而不是写死在报表里。4.2 小区沙盘与栅格化小区沙盘做得好的前提是小区信息标准化。课件里提到了小区信息标准化、POI信息标准化、栅格-住宅小区映射。我遇到的常见问题是物业小区名称别名不统一比如“金色家园”和“金色家园二期”在综资里可能是两条记录但地址库里却是同一个物理空间。解决办法不是靠清洗而是在建模前就建立“标准小区ID”概念用地址分词匹配经纬度距离聚类先把别名合并。栅格化则是针对没有小区边界数据的区域。把地图按500米×500米划分栅格再把栅格与住宅小区、POI、用户分布做映射。这种做法在校园毕业用户识别、常驻迁徙分析里特别有用因为校园、工厂、城中村往往没有规范的小区边界但栅格是客观存在的空间单元。-- 栅格-小区-用户透视查询用于小区沙盘首页的“小区画像” select g.grid_id, c.community_id, count(distinct u.user_id) as user_cnt, sum(case when u.broadband_status INACTIVE then 1 else 0 end) as inactive_cnt, sum(case when u.contract_end_date date_add(current_date(), interval 15 day) then 1 else 0 end) as expire_15d from dwd_grid_community_map g join dim_community c on g.community_id c.community_id join dwd_user_community u on u.community_id c.community_id where g.grid_id G500123 group by g.grid_id, c.community_id这条SQL的逻辑说明先通过栅格网格找到对应的小区再关联用户表统计这个小区下的用户总数、沉默用户数INACTIVE和15天内到期续费用户数。这里用current_date计算是为了支持每天自动刷新的到期预警看板。expire_15d字段对应课件里“客户到期前15天”的关键维系时间点再往前追3个月、2个月、1个月可以做成四档预警避免最后两周才启动营销。4.3 投诉分析与网络感知评估课件第10页把投诉分析拆得很细从QOE指标到KQI/KPI映射再到告警TOP N聚类。实际做的时候最难的是把“用户说网卡”翻译成具体网元指标异常。我的做法是先建一张投诉-网络指标的关联宽表按小区和时间窗把投诉工单和性能指标对齐窗口取投诉发生前1小时和投诉后30分钟。# 投诉工单与性能指标关联的宽度表生成逻辑伪代码 def build_complaint_perf_wide(complaint_df, perf_df, window_min60): complaint_df: 投诉工单含小区ID、投诉时间、投诉分类 perf_df: 网元性能指标含小区ID、时间、下载速率、时延、丢包率 以小区为粒度将投诉时间窗内的性能指标聚合到同一行 # 时间窗口偏移 perf_df[start_win] perf_df[time] - pd.Timedelta(minuteswindow_min) perf_df[end_win] perf_df[time] pd.Timedelta(minutes30) merged complaint_df.merge( perf_df, left_on[community_id, time], right_on[community_id, time], howleft ) # 物化特征窗口内平均下载速率、最小成功率、卡顿次数 wide merged.groupby([complaint_id, community_id]).agg( avg_dl_rate(download_rate, mean), min_success_rate(access_success, min), video_stall_cnt(stall_count, sum) ).reset_index() return wide这段代码的关键是在关联时保留“投诉时间点”而非“性能抓取时间点”否则凌晨1点的投诉会被凌晨5点的性能数据污染。聚合粒度选小区而不是用户主要原因是个别用户终端问题会导致用户级指标噪声很大小区级指标更能反映接入网和传输网的整体健康度。有了这张宽表才能往后做投诉根因识别区分是OLT端口拥塞、ONU光衰、还是BRAS链路丢包。5. 从模型到闭环让规划数据反哺生产运营的六个技巧5.1 用“一表一告警”替代大屏堆砌把课件里的指标按“状态-原因-动作”拆成三层看板。第一层看板只保留5个红黄绿指标端口利用率、实装率、投诉比、收益覆盖比、到期客户数。第二层是点击红黄指标后的原因拆解比如端口利用率超80%的小区按“缺ONU端口/缺PON口/上联带宽不足”分类。第三层是动作链接直接跳转扩容工单或营销活动页面。别把30个指标都放首页人会盯不住。5.2 常驻模型的月度更新节奏常驻识别模型的更新建议放在每月5号跑历史两个月的数据不要在月底当天跑。因为当月最后几天的信令数据可能还有延迟补采提前跑会导致“连续2个月”的判断少几天依据。每次跑完后把新增常驻用户与当前营销清单做差集避免对已打过标的人重复推送。5.3 用户-小区映射的验证方法映射模型做完后必须抽小区核对。我常用的验证方式是取500个用户人工查他的受理地址是否落在模型归集的小区内。如果匹配率低于85%优先检查小区的边界多边形是不是太粗或者LAC的300米半径阈值偏小。另一个低成本校验是看该小区内用户的平均ARPU排名是否与小区房价排名显著相关相关性太低说明映射精度有问题。5.4 8D选址的灵敏度分析AHP权重不只是算完就固定。位置覆盖、成本效益、潜在发展这三项权重的扰动会导致同一批候选地址排序变化。在做投资决策前建议对权重做±20%的灵敏度分析看哪些地址始终排在TOP10这些地址就是稳健选址。课件里强调“调整选择地段、对比目标得分”本质就是这个动作。5.5 把投诉预测模型接到扩容预警投诉预测模型不要只算投诉概率要把预测结果和网元性能阈值联动。比如预测未来一周某个OLT下PON口投诉概率超过0.3且当前端口利用率已经到75%就自动生成“扩容预警工单”。否则预测结果只是一个分数业务部门不知道怎么处理。预警短信配置在课件里是独立模块实际可以做成规则与模型双触发。5.6 网格化运营让小区沙盘变成责任田在小区沙盘上叠加网格经理的责任田范围把端口利用率、投诉比、到期客户数按网格经理绑定每周推送排名。课件里提到“客户经理APP与统一运营平台打通根据经理实时位置圈选小区位置关系进行实时营销推送”这套逻辑落地时要注意权限控制——只推送网格经理责任田内的小区不要推送全量开放否则会造成营销资源抢单和内耗。实时位置圈选的实现可以通过APP上报经纬度与小区多边形做点面判断命中则拉取该小区的待办任务。本文还有配套的精品资源点击获取 数据驱动家宽规划：从三域融合到GIS运营闭环
简介这是一份面向电信运营商及宽带业务规划人员的专业PPT课件聚焦如何借助大数据技术开展家庭宽带总体规划。内容从计划、网络、市场、财务、客服等多部门需求出发梳理背景现状、需求解读、整体架构、宽带战略地图与规划目标针对成本监控缺失、资费欺诈风险、客户价值提升困难等痛点提出系统化解决方案。资源包包含1个pptx文件大小2.3MB已有92人学习。课件共27页涵盖接入层网元标准化、物理小区映射、B域/O域数据接入、24个能力模型及GIS地图应用等核心模块并围绕客户体验提升、资源优化、风险控制给出落地路径。读者可通过本课件快速理解家宽大数据规划的顶层设计思路掌握从数据接入、能力封装到平台应用的全链条方法以及网络感知、客户保有、投诉分析等实战模块适合作为企业培训、方案汇报或课程教学参考。1. 一份27页PPT把家宽规划从“拍脑袋”拉回“数据驱动”做家宽规划的人都有体会市场部要拉新策反计划部要看成本效益网运部要处理投诉财务部要算盈亏客服部要背满意度——但大家看的往往是同一张拓扑图、同一份端口利用率周报。PPT里提到的“网元地图只有文字和型号”“投资完成后无法评估资源效益”“资费欺诈识别靠事后人工对账”这些问题不是缺系统而是缺一条能把B域计费、O域网管、M域财务数据串起来的主线。这篇内容来自一份27页的总体规划课件核心思路是把大数据能力拆成“数据接入—融合模型—GIS作战地图—运营闭环”四层用常驻识别、家庭客户挖掘、8D选址、网络感知等26个模型解决“潜在客户在哪、网元该建在哪、钱花得值不值”这三个本源问题。适合正在做固网规划、大数据应用或宽带运营体系的人参考。2. 规划前的数据底盘B/O/M三域接入与标准化2.1 家宽规划到底缺哪些数据课件里的需求解读部分把家宽规划要用的数据分成四类。第一类是接入层网元信息AP、ONU、ODN、PON、OLT、BRAS这些设备的数据很多还停留在手工台账阶段ONU端口与实际账号不匹配、销户不拆线是常态。第二类是用户侧数据宽带账号、订购、鉴权、拨号日志、装维工单。第三类是网络感知数据页面访问速率、时延、成功率、视频卡顿这类质量指标。第四类是财务数据资产损益、COA科目、用户记账月报。这里有一个容易被低估的问题端口信息不准会直接污染后续所有建模。比如做网元-用户映射时如果ONU端口对应的是错误账号那么高价值用户会被归到错误的小区8D选址里的“业务承载”维度就失真了。所以课件里才把“网元信息录入规范”放在需求第一位而不是先上模型。数据接入的现状是B域和O域已有部分数据但缺少AAA日志、QoS日志、xDR话单、网元设备信息等关键来源。按课件的接口清单估算需要从BOSS/CRM、综资、DSMP、网管、ERP等系统接入至少51类接口涉及100个具体接口。这些接口的体量差异很大Radius日志和Wlan上网日志是亿级/天的记录而POS端口管理表可能是万级。如果都按同一套采集频率跑会给源系统造成不必要的压力。数据域典型接口使用场景更新频率建议B域家宽标准地址接口、宽带拨号日志、宽带资费信息表、零流量清单用户归集、套餐分析、沉默用户识别日增量同步T1O域ONU端口、OLT/BRAS配置、Radius日志、AP信息、信令数据网元地图、端口核查、网络性能分析小时级或日级M域资产损益月表、COA科目费用月表、用户记账月报、收入结算效益评估、成本核算、盈亏分析月级或按自然月触发2.2 从接口清单到数据总线100接口怎么接课件整体架构里提到“开放的数据总线”这层在工程实现上通常承担三件事接口调度、格式转换、数据质量稽核。我见到的做法是先对51类接口做分级按数据量、实时性、重要度分成三类避免所有数据都走同一套流程导致瓶颈。# 以ONU端口数据和Radius日志为例演示分级调度逻辑 import pandas as pd from datetime import datetime def load_bill_data(interface_id, data_date): 接口数据装载B域业务数据按天全量/增量拉取 - interface_id: 接口编号如 B_019 代表宽带拨号日志 - data_date: 业务日期 返回DataFrame并做基础空值校验 # 实际项目中这里会从kafka或hive分区读取此处以CSV示意 df pd.read_csv(f/data/raw/{interface_id}_dt{data_date}.csv) # 关键字段非空校验账号、小区ID、网元ID required [account, community_id, onu_id] for col in required: assert df[col].notna().all(), f字段{col}存在空值阻断装载 # 去除重复端口记录防止后续映射出现一对多 df df.drop_duplicates(subset[account, enodeb_id, port_no]) return df def load_radius_log(interface_id, data_date): Radius日志按小时分区读取数据量大且字段稀疏 只保留建模需要的字段压缩存储成本 df pd.read_parquet(f/data/raw/{interface_id}/hour{data_date}/*.parquet) cols [session_id, user_ip, account, start_time, end_time, traffic_up, traffic_down] return df[cols]上面这段逻辑说明两点。第一B域数据质量校验要前置账号、小区ID、网元ID这三个字段是后续用户映射的基础空值必须在装载阶段拦截否则到了模型层排查成本翻倍。第二Radius日志这类海量数据按小时分区只提取建模必须的流量和时长字段不要一开始就把全字段存成宽表否则一个月的日志就能占满数TB空间。2.3 网元信息标准化与小区映射的常见做法课件第4页里提到了“网元地图”“用户-住宅小区映射”“栅格化”三个动作。映射链路本质上是三级网元覆盖小区小区承载用户用户归属到家庭ID。难点在于网元LAC位置区码和住宅小区坐标之间没有现成的对应关系需要算法推算。课件里给出的是基于蒙特卡洛的面积投影算法思路是先识别用户常驻LAC取该LAC内所有住宅小区的坐标以LAC质心为圆心、300米为距离阈值生成投影面积按面积占比把LAC下的用户分摊到各小区。面积投影算完只是定了“分多少”还没定“分谁”需要再用基站的方位角与映射角的对比来随机分配具体用户。import numpy as np import pandas as pd from shapely.geometry import Point, Polygon def calculate_projection_ratio(lac_point, community_polys, distance_threshold300): 蒙特卡洛面积投影计算LAC与各住宅小区的投影面积占比 - lac_point: Point基站常驻LAC的质心坐标 - community_polys: 住宅小区多边形列表 [(id, Polygon), ...] - distance_threshold: LAC覆盖半径课件中取300米 返回各小区投影面积占比 dict # 生成LAC半径范围内的随机采样点模拟用户均匀分布 np.random.seed(42) samples [] for _ in range(10000): # 在圆内均匀采样 r distance_threshold * np.sqrt(np.random.uniform()) theta np.random.uniform(0, 2 * np.pi) x lac_point.x r * np.cos(theta) y lac_point.y r * np.sin(theta) samples.append(Point(x, y)) # 统计落在每个小区多边形内的采样点数 counts {cid: 0 for cid, _ in community_polys} for pt in samples: for cid, poly in community_polys: if poly.contains(pt): counts[cid] 1 break total sum(counts.values()) # 没有采样点落中的小区则按平均分配避免除零 if total 0: return {cid: 1.0 / len(community_polys) for cid in counts} return {cid: cnt / total for cid, cnt in counts.items()}这里要注意几个坑。第一距离阈值300不是拍脑袋它来自LAC小区半径的统计中位数实际项目里要按城区、乡镇分别标定城中村和别墅区的覆盖半径差异能达到3倍以上。第二随机采样用的是均匀分布但实际用户在LAC内并非均匀更精确的做法是先按该LAC下用户的历史位置记录生成热度分布再做重要性采样。第三方位角匹配那一步不要直接用小区中心的方位角要用基站天线的法向方向也就是课件里反复强调的Ci方位角否则朝南覆盖的基站会把用户错分到北边小区。3. 26个规划模型的选型与落地从常驻识别到8D选址3.1 五大类模型框架课件第6页把模型分成基础能力、市场运营、价值评估、规划建设、服务感知五类总共规划26个模型一期建议实现14个。这个“一期14个”的取舍值得细看优先做的都是数据基础类——用户-小区映射、常驻识别、家庭识别因为后面所有拉新、策反、选址模型都要依赖这些基础标签。相反内容推荐、产品优化这类依赖行为解析的模型被放到二期原因是页面上网日志的解析匹配非常消耗算力且涉及用户隐私授权。模型大类一期/二期典型模型主要依赖数据基础能力一期栅格-小区映射、用户-小区映射、小区信息标准化综资、信令、位置LAC市场运营一期/二期潜在客户拉新、异网宽带识别、家庭客户识别、常驻迁徙B域订购、通信行为价值评估一期单条宽带效益、风险欺诈识别M域成本、B域收入规划建设一期8D选址、网元选址评估网元性能、成本、竞争服务感知一期网络感知、投诉预测、流失后评估投诉工单、性能指标3.2 常驻客户识别与家庭客户挖掘算法常驻识别是课件里写得最细的一个模型核心逻辑不复杂但工程落地要考虑几个细节。规则分两步第一步用凌晨0-6点的驻留基站识别生活常驻用9-11点和14-17点的驻留基站识别工作常驻统计周期是一个月内生活常驻20天、工作地常驻15天。第二步针对没有明显驻留特征的用户用20-24点业务量最大的基站作为生活常驻用工作时间业务量最大的基站作为工作常驻。隐蔽的坑在于“连续2个月以上常驻基站变为N才更新”这条规则。课件刻意加了这个条件是为了防止用户临时出差、旅游带来的基站漂移。实际应用中如果月底最后几天用户常驻地从M变成N而模型立即更新就可能把一个周末回老家的人误判成常驻用户进而把这个用户错误归入老家的住宅小区导致营销资源投错地方。# 常驻基站更新的状态判断伪代码按课件规则简化 def update_resident_base(station_history, cur_station, user_id, month): station_history: 历史常驻基站记录 cur_station: 当月识别出的常驻基站 规则若当月基站由M变为N不更新连续2个月以上为N才更新 prev_station station_history.get(user_id) # 上月的常驻基站 if prev_station cur_station: return prev_station # 没变化保持 # 有变化时检查前两个月是否都是N hist_2m station_history.get(f{user_id}_last2m, None) if hist_2m cur_station: # 前两个月已经变成N且连续确认更新 station_history[user_id] cur_station else: # 第一次变化记录过渡态但不更新最终结果 station_history[f{user_id}_last2m] cur_station return station_history[user_id]家庭客户识别的思路也值得展开。课件先用交往圈模型找出与用户a连续三个月通话且通话次数TOP3的用户群然后判断这些用户之间是否也互相通话形成准家庭用户对再要求这些用户对同处一个常驻生活基站下才判定为潜在家庭。家庭ID的生成规则是“基站ID小区ID序列号”主账户的确定用主叫次数和ARPU值双重排序。这套规则在实操中会遇到一个问题现在的家庭里成员可能会用亲情网套餐套餐内通话不计费所以单纯看通话详单会漏识别。补丁方案是把亲情网群组数据也放进交往圈候选或者结合位置聚合——晚上同一时间出现在同一小区且连续超过20天这样的两个人即使通话次数少也值得打上准家庭标签。3.3 8D选址评估与AHP权重计算8D选址是规划建设类的核心模型课件的写法是AHP层次分析准则层包含位置覆盖、业务承载、网络性能、成本效益、客户投诉、终端匹配、潜在发展、区域竞争这8个维度。AHP的关键是构造判断矩阵、算权重、做一致性校验。工程上专家打分没法完全避免主观偏差所以课件里写了“专家打分迭代计算”迭代这一步通常是用熵权法修正专家打分的权重让高方差的指标比如投诉量在不同区域差异很大不会因为平均而失去区分度。import numpy as np def ahp_weights(matrix): AHP权重计算与一致性校验 matrix: 8x8判断矩阵行列顺序对应8D维度 返回权重向量若CR0.1则提示重新打分 eigvals, eigvecs np.linalg.eig(matrix) max_eig np.max(eigvals) # 权重向量为最大特征值对应的归一化特征向量 idx np.argmax(eigvals) weights np.real(eigvecs[:, idx]) weights weights / weights.sum() # 一致性指标CIRI为随机一致性指标8阶取1.41 n matrix.shape[0] CI (max_eig - n) / (n - 1) CR CI / 1.41 if CR 0.1: raise ValueError(fCR{CR:.3f}0.1判断矩阵不一致需调整打分) return weights, CR # 判断矩阵示例位置覆盖比成本效益重要投诉比终端匹配重要 judge_matrix np.array([ [1, 3, 5, 1, 3, 5, 1, 3], # 位置覆盖 [1/3, 1, 3, 1/3, 1, 3, 1/3, 1], [1/5, 1/3, 1, 1/5, 1/3, 1, 1/5, 1/3], [1, 3, 5, 1, 3, 5, 1, 3], # 成本效益 [1/3, 1, 3, 1/3, 1, 3, 1/3, 1], [1/5, 1/3, 1, 1/5, 1/3, 1, 1/5, 1/3], [1, 3, 5, 1, 3, 5, 1, 3], # 潜在发展 [1/3, 1, 3, 1/3, 1, 3, 1/3, 1] ]) weights, cr ahp_weights(judge_matrix) print(8D各维度权重:, np.round(weights, 3)) print(CR一致性指标:, round(cr, 3))AHP的结果只解决“同一批候选地址怎么排序”的问题还不能解决“候选地址从哪来”的问题。实操中我会先用小区沙盘里的高价值小区做聚类把用户密度、网元覆盖盲区、竞争小区三个图层做空间叠加圈出一批候选栅格再跑AHP排序。另外要注意判断矩阵的维度和标度8维矩阵的一致性约束很强如果专家打分的CR始终过不了优先检查是不是存在两个维度高度相关比如“业务承载”和“潜在发展”这种情况需要合并维度或者用网络层次分析法的层次结构替代平级判断。4. 宽带战略地图GIS可视化与运营作战平台4.1 功能架构与视图设计课件里的宽带战略地图功能架构核心不是地图本身而是把“监控、分析、营销、评价”四类动作收敛到一张图上。基础信息层有四种视图资源视图对应网元设备用户视图对应客户与家庭小区视图对应物理小区沙盘收益视图对应盈亏热力分布。每个视图背后都是一组指标比如小区视图要看渗透率、到期客户数、微小企业识别数收益视图要看宽带成本构成、建设投资与收入。这些指标不能全部堆到一张屏幕上需要按用户角色做页面分流市场部打开的是“运营作战地图”计划部打开的是“规划选址地图”网运部打开的是“质量保障地图”。指标的下钻链路也值得设计。比如市场部首页看到某个小区的“渗透率低于目标值10个百分点”点击小区后要能下钻到三个子页面第一是用户构成多少是本网存量、多少是异网可策反、多少是未装宽带第二是竞争情况周边竞争对手网元的覆盖距离和端口利用率第三是历史趋势近半年的渗透率变化和营销活动投放时间点。课件里提到的“指标可配置化”指的就是这套下钻模板可以按省市县自定义而不是写死在报表里。4.2 小区沙盘与栅格化小区沙盘做得好的前提是小区信息标准化。课件里提到了小区信息标准化、POI信息标准化、栅格-住宅小区映射。我遇到的常见问题是物业小区名称别名不统一比如“金色家园”和“金色家园二期”在综资里可能是两条记录但地址库里却是同一个物理空间。解决办法不是靠清洗而是在建模前就建立“标准小区ID”概念用地址分词匹配经纬度距离聚类先把别名合并。栅格化则是针对没有小区边界数据的区域。把地图按500米×500米划分栅格再把栅格与住宅小区、POI、用户分布做映射。这种做法在校园毕业用户识别、常驻迁徙分析里特别有用因为校园、工厂、城中村往往没有规范的小区边界但栅格是客观存在的空间单元。-- 栅格-小区-用户透视查询用于小区沙盘首页的“小区画像” select g.grid_id, c.community_id, count(distinct u.user_id) as user_cnt, sum(case when u.broadband_status INACTIVE then 1 else 0 end) as inactive_cnt, sum(case when u.contract_end_date date_add(current_date(), interval 15 day) then 1 else 0 end) as expire_15d from dwd_grid_community_map g join dim_community c on g.community_id c.community_id join dwd_user_community u on u.community_id c.community_id where g.grid_id G500123 group by g.grid_id, c.community_id这条SQL的逻辑说明先通过栅格网格找到对应的小区再关联用户表统计这个小区下的用户总数、沉默用户数INACTIVE和15天内到期续费用户数。这里用current_date计算是为了支持每天自动刷新的到期预警看板。expire_15d字段对应课件里“客户到期前15天”的关键维系时间点再往前追3个月、2个月、1个月可以做成四档预警避免最后两周才启动营销。4.3 投诉分析与网络感知评估课件第10页把投诉分析拆得很细从QOE指标到KQI/KPI映射再到告警TOP N聚类。实际做的时候最难的是把“用户说网卡”翻译成具体网元指标异常。我的做法是先建一张投诉-网络指标的关联宽表按小区和时间窗把投诉工单和性能指标对齐窗口取投诉发生前1小时和投诉后30分钟。# 投诉工单与性能指标关联的宽度表生成逻辑伪代码 def build_complaint_perf_wide(complaint_df, perf_df, window_min60): complaint_df: 投诉工单含小区ID、投诉时间、投诉分类 perf_df: 网元性能指标含小区ID、时间、下载速率、时延、丢包率 以小区为粒度将投诉时间窗内的性能指标聚合到同一行 # 时间窗口偏移 perf_df[start_win] perf_df[time] - pd.Timedelta(minuteswindow_min) perf_df[end_win] perf_df[time] pd.Timedelta(minutes30) merged complaint_df.merge( perf_df, left_on[community_id, time], right_on[community_id, time], howleft ) # 物化特征窗口内平均下载速率、最小成功率、卡顿次数 wide merged.groupby([complaint_id, community_id]).agg( avg_dl_rate(download_rate, mean), min_success_rate(access_success, min), video_stall_cnt(stall_count, sum) ).reset_index() return wide这段代码的关键是在关联时保留“投诉时间点”而非“性能抓取时间点”否则凌晨1点的投诉会被凌晨5点的性能数据污染。聚合粒度选小区而不是用户主要原因是个别用户终端问题会导致用户级指标噪声很大小区级指标更能反映接入网和传输网的整体健康度。有了这张宽表才能往后做投诉根因识别区分是OLT端口拥塞、ONU光衰、还是BRAS链路丢包。5. 从模型到闭环让规划数据反哺生产运营的六个技巧5.1 用“一表一告警”替代大屏堆砌把课件里的指标按“状态-原因-动作”拆成三层看板。第一层看板只保留5个红黄绿指标端口利用率、实装率、投诉比、收益覆盖比、到期客户数。第二层是点击红黄指标后的原因拆解比如端口利用率超80%的小区按“缺ONU端口/缺PON口/上联带宽不足”分类。第三层是动作链接直接跳转扩容工单或营销活动页面。别把30个指标都放首页人会盯不住。5.2 常驻模型的月度更新节奏常驻识别模型的更新建议放在每月5号跑历史两个月的数据不要在月底当天跑。因为当月最后几天的信令数据可能还有延迟补采提前跑会导致“连续2个月”的判断少几天依据。每次跑完后把新增常驻用户与当前营销清单做差集避免对已打过标的人重复推送。5.3 用户-小区映射的验证方法映射模型做完后必须抽小区核对。我常用的验证方式是取500个用户人工查他的受理地址是否落在模型归集的小区内。如果匹配率低于85%优先检查小区的边界多边形是不是太粗或者LAC的300米半径阈值偏小。另一个低成本校验是看该小区内用户的平均ARPU排名是否与小区房价排名显著相关相关性太低说明映射精度有问题。5.4 8D选址的灵敏度分析AHP权重不只是算完就固定。位置覆盖、成本效益、潜在发展这三项权重的扰动会导致同一批候选地址排序变化。在做投资决策前建议对权重做±20%的灵敏度分析看哪些地址始终排在TOP10这些地址就是稳健选址。课件里强调“调整选择地段、对比目标得分”本质就是这个动作。5.5 把投诉预测模型接到扩容预警投诉预测模型不要只算投诉概率要把预测结果和网元性能阈值联动。比如预测未来一周某个OLT下PON口投诉概率超过0.3且当前端口利用率已经到75%就自动生成“扩容预警工单”。否则预测结果只是一个分数业务部门不知道怎么处理。预警短信配置在课件里是独立模块实际可以做成规则与模型双触发。5.6 网格化运营让小区沙盘变成责任田在小区沙盘上叠加网格经理的责任田范围把端口利用率、投诉比、到期客户数按网格经理绑定每周推送排名。课件里提到“客户经理APP与统一运营平台打通根据经理实时位置圈选小区位置关系进行实时营销推送”这套逻辑落地时要注意权限控制——只推送网格经理责任田内的小区不要推送全量开放否则会造成营销资源抢单和内耗。实时位置圈选的实现可以通过APP上报经纬度与小区多边形做点面判断命中则拉取该小区的待办任务。本文还有配套的精品资源点击获取