铁路"买短乘长"分析 — 数据打通与防控体系搭建方案

一、现状与目标

二、数据打通方案

2.1 关联键设计

两个系统之间的关联是整个方案的核心难点。需要通过多字段组合进行模糊匹配：

票务系统 ←─────关联─────→ 闸机系统
  │                         │
  ├─ 证件号(脱敏hash)  ←→  证件号(脱敏hash)     主键
  ├─ 车次              ←→  车次                  辅助
  ├─ 乘车日期          ←→  进站日期              辅助
  └─ 票面到站          ←→  实际出站              对比字段

2.2 建表与关联SQL方案

步骤1：统一数据视图

-- 票务数据视图
CREATE VIEW v_ticket AS
SELECT
    ticket_id,
    passenger_hash,       -- 证件号脱敏hash
    train_no,             -- 车次
    travel_date,          -- 乘车日期
    from_station,         -- 票面起站
    to_station,           -- 票面到站
    seat_class,           -- 席别
    ticket_price,         -- 票价
    purchase_channel,     -- 购票渠道
    purchase_time         -- 购票时间
FROM ticket_system.tickets
WHERE status = '已出票';  -- 排除退票

-- 闸机数据视图
CREATE VIEW v_gate AS
SELECT
    gate_id,
    passenger_hash,       -- 证件号脱敏hash
    train_no,             -- 车次
    travel_date,          -- 乘车日期
    entry_station,        -- 进站
    entry_time,           -- 进站时间
    exit_station,         -- 出站
    exit_time             -- 出站时间
FROM gate_system.gate_records
WHERE entry_time IS NOT NULL
  AND exit_time IS NOT NULL;

步骤2：关联匹配

-- 通过 证件hash + 车次 + 日期 进行关联
CREATE VIEW v_ticket_gate_joined AS
SELECT
    t.ticket_id,
    t.passenger_hash,
    t.train_no,
    t.travel_date,
    t.from_station   AS ticket_from,
    t.to_station     AS ticket_to,
    g.entry_station  AS actual_from,
    g.exit_station   AS actual_to,
    t.ticket_price,
    t.seat_class
FROM v_ticket t
INNER JOIN v_gate g
    ON  t.passenger_hash = g.passenger_hash
    AND t.train_no       = g.train_no
    AND t.travel_date    = g.travel_date;

步骤3：异常行为识别

-- 买短乘长嫌疑记录
CREATE VIEW v_short_long_suspect AS
SELECT
    *,
    CASE
        WHEN actual_to != ticket_to
         AND station_order(actual_to) > station_order(ticket_to)
         AND supplement_id IS NULL          -- 无补票记录
        THEN '买短乘长嫌疑'
        ELSE '正常'
    END AS suspect_flag
FROM v_ticket_gate_joined
LEFT JOIN supplement_records s
    ON ticket_id = s.ticket_id;

station_order() 为自定义函数，根据线路方向返回站序号，用于判断实际到站是否超出票面到站。

三、识别规则引擎（从零搭建）

3.1 规则分层架构

┌─────────────────────────────────────┐
│          规则引擎（三层）              │
├─────────────────────────────────────┤
│  L1 确定性规则  → 命中即标记          │
│  L2 统计性规则  → 概率评分           │
│  L3 行为模式规则 → 画像匹配          │
└─────────────────────────────────────┘

3.2 L1 确定性规则（硬规则）

命中即判定，零误判：

3.3 L2 统计性规则（软规则）

计算嫌疑评分，设定阈值：

评分阈值：

3.4 L3 行为模式规则（画像规则）

四、防控策略优化框架

4.1 策略矩阵

4.2 防控效果评估闭环

数据打通 → 规则识别 → 策略执行 → 效果监测 → 规则迭代
   ↑                                        │
   └────────────────────────────────────────┘

关键评估指标：

五、实施路线图

六、需要进一步确认的问题

1. 两系统的证件号字段是否格式一致？ 若格式不同（如一方存明文一方存加密），需增加清洗转换步骤
2. 是否已有站序映射表？ 判断"实际到站是否超出票面到站"需要线路方向的站序信息
3. 闸机覆盖率如何？ 无闸机小站的数据缺失会直接影响L1规则的召回率
4. 是否有权限创建跨库视图？ 票务与闸机若在不同MySQL实例，需确认跨库查询或数据同步方案