运输时效预测模型：静态路由时效的计算与验证
运输时效预测模型：静态路由时效的计算与验证
物流行业的时效承诺，依赖的是时效预测。客户问"什么时候能到"，运营给出的时间是预测出来的。
这个预测来自数仓的静态路由时效表。
静态路由时效是什么
静态路由时效表（dw.time_rule_ewb_static_route）存储的是每个运单的计划时效。
计算逻辑：根据运单的寄件网点和派件网点，计算从收件到签收的计划时间。
一个运单从上海发到北京，经过的路径可能是：
上海网点 → 上海分拨 → 北京分拨 → 北京网点 → 签收静态路由时效会计算每一段的计划时间：
- 网点到首分拨：4小时
- 首分拨到末分拨：8小时
- 末分拨到网点：4小时
- 网点到签收：2小时
总计：18小时
这个18小时就是预测的配送时间。
预测的数据基础：时效宽表
预测需要验证，验证需要实际时效。实际时效从哪来？
从扫描轨迹表（dw.bs_tracks_inc）提取。
扫描轨迹表是长表，一个运单对应十几行扫描记录：
| waybillno | actiontype | orgcode | time |
|---|---|---|---|
| WB001 | 1100 | S001 | 2026-05-01 08:00:00 |
| WB001 | 2100 | C001 | 2026-05-01 10:00:00 |
| WB001 | 2200 | C001 | 2026-05-01 10:30:00 |
| WB001 | 1500 | D001 | 2026-05-02 09:00:00 |
时效宽表是宽表，一个运单对应一行，每个节点的时间各占一列：
| waybillno | receive_time | first_center_arr_car_time | last_center_send_car_time | sign_time |
|---|---|---|---|---|
| WB001 | 08:00 | 10:00 | 18:00 | 09:00+1d |
从长表变宽表，核心是分拨路径还原——识别首分拨、中转分拨、末分拨，提取每个节点的到车时间、发车时间。
产出表：dwd.ewb_sub_act_plan_node_time_analysis_h
预测的计算方法
静态路由时效的计算，不是简单的"点到点距离÷速度"。
实际逻辑：
- 获取运单的路由信息：寄件网点、派件网点、计划经过的分拨中心
- 查询每个节点的计划时间：从时效配置表获取每个节点的计划停留时间
- 累加计算总时效：各节点计划时间之和
数据来源：
- 运单基础信息表：获取寄件网点、派件网点
- 时效配置表（
dw.opm_qll_delivery_time）：获取各节点的计划时间 - 最优路线方案表（
dim.route_optimal_plan_details）：获取计划路由
产出表：dws.ewb_sub_act_plan_node_time_analysis
这张表在时效宽表的基础上，增加了计划时效字段：
| 字段 | 说明 |
|---|---|
| plan_route_hour_time | 计划时效（小时） |
| act_route_hour_time | 实际时效（小时） |
| plan_sign_time | 计划签收时间 |
预测的验证方式
预测准不准，需要用历史数据验证。
验证逻辑：计划时效 vs 实际时效的偏差分析
SELECTsend_site_code,dispatch_site_code,AVG(plan_route_hour_time)ASavg_plan_time,AVG(act_route_hour_time)ASavg_act_time,AVG(act_route_hour_time-plan_route_hour_time)ASavg_diffFROMdws.ewb_sub_act_plan_node_time_analysisWHEREds='${dt}'GROUPBYsend_site_code,dispatch_site_code偏差分析：
| 线路 | 计划时效 | 实际时效 | 偏差 |
|---|---|---|---|
| 上海→北京 | 18h | 20h | +2h |
| 上海→广州 | 24h | 22h | -2h |
| 北京→武汉 | 12h | 15h | +3h |
偏差为正，说明预测偏乐观（实际比计划慢）。偏差为负，说明预测偏保守（实际比计划快）。
预测准确率：
-- 准时率：实际时效 ≤ 计划时效的比例SUM(CASEWHENact_route_hour_time<=plan_route_hour_timeTHEN1ELSE0END)*100.0/COUNT(*)预测模型的局限
静态路由时效的预测，有几个局限：
1. 路由变化
计划路由和实际路由经常不一致。运单计划走上海分拨，实际走了杭州分拨。这种情况，计划时效需要重新计算。
解决：在DWS层，判断实际路由是否和计划路由一致。不一致时，用实际路由重新计算计划时效。
2. 异常事件
天气、交通、设备故障等异常事件，会影响时效。静态路由时效无法预测这些异常。
解决：在时效宽表中，标记异常运单，分析时排除异常数据。
3. 数据质量
扫描轨迹缺失、时间错误，会影响实际时效的准确性。
解决：到车和到件时间要兜底（COALESCE），同一分拨多次扫描要取min/max。
时效预测模型的数据架构
┌─────────────────────────────────────────────────────────────┐ │ 数据源层 │ ├─────────────────────────────────────────────────────────────┤ │ 扫描轨迹表 运单基础表 时效配置表 最优路由表 │ │ dw.bs_tracks dwd.ewb_basic dw.opm_qll dim.route │ │ _inc _detail_hour _delivery_time _optimal │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ DWD层 │ ├─────────────────────────────────────────────────────────────┤ │ 时效宽表（实际时效） │ │ dwd.ewb_sub_act_plan_node_time_analysis_h │ │ - 扫描轨迹 → 分拨路径还原 → 节点时间 │ │ - 实际时效：首分拨到末分拨的时间 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ DWS层 │ ├─────────────────────────────────────────────────────────────┤ │ 时效对比宽表（计划+实际） │ │ dws.ewb_sub_act_plan_node_time_analysis │ │ - JOIN静态路由时效表 → 计划时效 │ │ - 计划时效 vs 实际时效 → 偏差分析 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ ADS层 │ ├─────────────────────────────────────────────────────────────┤ │ 时效预测准确性分析 │ │ st.whole_route_via_optimal │ │ - 各线路预测准确率 │ │ - 偏差TOP N线路 │ └─────────────────────────────────────────────────────────────┘总结
时效预测模型的核心：
- 预测依据：静态路由时效表（根据运单点到点计算的计划时效）
- 验证数据：时效宽表（从扫描轨迹提取的实际时效）
- 预测准确性：计划时效 vs 实际时效的偏差分析
数仓的职责是：构建时效宽表、计算计划时效、验证预测准确性。
运营的职责是：根据预测时效给客户承诺，根据偏差分析优化调度。
时效预测不是猜测，是数据驱动的计算与验证。