1. 先说清楚这个出行推荐系统到底“推”什么去年帮一家区域出行平台做数据中台项目时对方提了个很典型的需求“我们每天能产生几十万条订单和轨迹数据现在这些数据大部分躺在数据库里睡大觉。能不能做一个可视化大屏让管理层一眼看清城市出行态势同时我们的App路线推荐一直被人吐槽‘只会走主路不知道避开拥堵’你们能不能一起解决”这就是“基于大数据的出行路线规划与推荐系统 数据分析可视化大屏系统”这个项目的由来。严格说它并不是一个单点功能而是把一条完整链路串了起来出行数据的采集与清洗 → 数仓分层加工 → 路线规划与个性化推荐 → 指标可视化呈现。任何一个环节掉链子整个系统都会显得“很傻”。文章适合三类人看一是正在做大数据课程设计或毕业设计、想找一个完整项目作为参照的学生二是公司里有大量出行/轨迹数据、想做可视化大屏但不知道怎么落地的开发三是对路线推荐算法感兴趣、想了解“导航软件的推荐到底怎么实现”的产品或后端工程师。全文会按我在项目里的实际操作顺序来讲不绕弯子尽量把每一步的“为什么这么做”也交代清楚。2. 数据层是整个系统的地基采集、清洗、入库路线推荐、大屏可视化表面上是算法和前端的事但实际开发中八成的时间都耗在数据上。数据不对后面全是白搭。这一章我把数据链路上最容易出问题的三个环节拆开说。2.1 数据源与采集通道出行类系统的数据源大体分四类缺了哪一类推荐和大屏都做不完整订单数据用户从下单到完单的全程记录包含上下车经纬度、里程、时长、实付金额、司机ID等。这是付费分析的核心。GPS轨迹数据司机端/用户端上报的经纬度点序列通常每3~5秒上报一次。原始格式一般是device_id, longitude, latitude, timestamp, speed, direction。路况数据道路拥堵等级、平均通行速度。可以采购第三方接口也可以自己根据历史GPS轨迹反推。项目前期预算有限我们用了后者。辅助数据天气雨雪天对出行需求峰值影响极大、区域POI商圈、车站、学校、节假日日历。这些主要用于特征工程和后续推荐排序。采集通道上订单数据走业务库的Binlog订阅Canal比较成熟轨迹数据则走消息队列。我们用的是Kafka上游SDK直推Topic下游挂消费者做实时清洗。早期图省事让轨迹数据直接写MySQL结果单表两千万行之后查询都开始飘后来才老老实实迁到HDFS。这个教训后面细讲。2.2 轨迹数据的清洗与地图匹配GPS轨迹数据是最容易“骗人”的。实际拿到手的轨迹里有漂移点隧道里、高架下、小区里定位点可能突然跳到几百米外的马路上。这种点不处理算出来的平均车速能直接污染整个路段数据。有重复点设备重传导致同一时间戳出现多条数据需要去重按device_id timestamp做聚合取最新。有乱序点上报链路延迟后发的点反而时间戳更早。处理办法是按时间戳排序而不是按到达顺序。清洗之后还有一步关键操作地图匹配Map Matching。因为GPS点是散的而路线规划是在“路网图”上做的必须把这些点“贴”到对应的道路上。最简单的策略是找最近路段并做投影但容易在高架桥上下层道路上弄错。项目里我们采用了基于隐马尔可夫模型的成熟思路不只是看单点最近路还考虑前后点之间的路网连通性用维特比算法求出最可能的道路序列。实测在立交桥密集的区域匹配正确率从83%提升到94%左右。提示如果你的项目只是做统计级大屏比如算区域平均车速粗匹配就够了。但如果要做路线推荐和导航地图匹配这一关过不去后面推荐的路线会直接“穿楼飞河”非常露怯。2.3 数仓分层不要把所有数据堆在一张表里这个项目的数据加工沿用了数仓分层的经典思路虽然听起来有点传统但它是保证“大屏数据快”和“推荐特征全”的基础ODS层原始数据层按天分区存放清洗后的订单、轨迹、路况原始数据。保留全量不删。DWD层明细数据层做维度补全——把订单表关联上司机、车辆、区域、天气等维度把轨迹点聚合成“某辆车某天某路段上的平均速度”这类明细事实。DWS层汇总数据层按城市、行政区、小时、路段等维度预先聚合指标比如每小时各区域订单量、高峰时段最堵的TOP10路段。这一层是直接供可视化大屏查询的。ADS层应用数据层面向具体业务主题的宽表比如“个性化推荐候选集”“用户偏好标签表”。计算引擎选了Hive做离线批量加工、Spark做复杂特征工程。Hive负责每天凌晨把ODS推进到DWSSpark则跑那些需要复杂逻辑的推荐特征。这套组合的好处是生态成熟、招聘容易、出问题能在网上查到一堆解决方案。对于同体量的项目我建议不要一上来就上Flink做全链路实时除非你对流计算团队有把握。3. 路线推荐的核心逻辑从最短路径到个性化排序大屏是给管理层看的而真正每天被用户感知的是App里的路线推荐。这一章讲推荐引擎怎么设计。它分为两层底层是“路网级路线规划”上层是“用户级个性化排序”。3.1 路线规划引擎动态权重下的路径搜索经典的路线规划可以直接套Dijkstra或A*算法在静态路网上找最短路径。但真实出行场景里“最短”不等于“最快”更不等于“用户愿意走”。我们的做法是把路径搜索的代价函数从“距离”换成“综合时间成本”cost(edge) freeSpeedTime(edge) * congestionFactor(edge, timeBucket) penalty(level) preferencePenalty(userType)这个公式是整条路线推荐的灵魂。拆开看freeSpeedTime(edge)自由流时间即道路限速条件下通过该路段的分钟数。congestionFactor(edge, timeBucket)拥堵系数由历史路况数据按“星期几小时”统计得出。比如工作日晚高峰某条主干道的平均车速只有自由流的一半那系数就是2。penalty(level)道路等级惩罚。用户普遍不太喜欢小路非铺装路、胡同即使距离近走起来也不舒服。我们给不同等级道路加了不同的惩罚系数。preferencePenalty(userType)用户偏好项。后面讲个性化时细说。搜索算法上用了A*加双向搜索配合路网层级收缩contraction hierarchies的思路但实现简化了城市级路由平均耗时能控制在30毫秒左右。这个性能对实时性要求高的场景是必要的——用户可等不了三秒才出路线。为什么不用“实时路况”我们做了一个折中用户点“开始导航”时用当天已经积累的实时GPS数据修正历史拥堵系数没有实时数据的路段回退到历史预测值。这套“实时历史”的融合策略既避免了冷启动时段凌晨、清晨没有实时数据的问题又能在早晚高峰捕捉到突发拥堵。3.2 个性化推荐用户偏好、相似人群与热门兜底路径搜索能给出三条候选路线推荐路线、备选一、备选二。但候选路线怎么排序就看个性化推荐了。用户偏好维度我们做了三类都能落地到具体特征历史路线记忆同一个用户从家到公司通勤连续三周都走同一条路说明他对这条路有路径依赖。在候选路线中识别出“与用户历史常走路线重合度高”的路线加权上浮。风格偏好有些用户喜欢走高速时间优先有些用户宁可慢十分钟也不愿意多交过路费成本敏感有些用户明确选择“少走红绿灯”的路线。这些偏好从历史订单和用户画像里提取反映到排序函数上。协同过滤核心思想是“和你行为相似的人可能也会喜欢同样的路”。我们把用户按通勤区域、出发时段、车型、常走路线类型聚类计算相似用户群对不同候选路线的选择比例作为排序特征之一。排序层用了轻量级的LR GBDT模型特征包括路线预计时间、距离、步行距离、红绿灯数量、历史选择概率、与用户偏好的匹配度等。训练数据来自用户真实的选择行为——用户看了三条路线最终点了哪一条这就是天然的标注样本。注意算法不是越复杂越好。我们最早尝试过上深度排序模型效果提升很有限但训练和上线成本翻了几倍。GBDT这种树模型的解释性还更好——你至少能告诉业务方“为什么用户看到的是这条路线”。3.3 冷启动与稀疏数据的兜底策略推荐系统最怕的就是“新用户没有历史行为”。路线推荐也不例外。我们准备了三级兜底热门路线兜底城市级统计“该OD出发地—目的地对出行需求最高、被选次数最多”的路线作为默认候选。新用户直接看到大众选择冷启动问题就解决了一大半。区域统计兜底如果具体OD对的历史数据太少比如出发地是新开的小区就把粒度放宽到“同行政区”的历史路线选择统计挑出区域内高频路线模式作为候选。规则保底极端情况下完全无历史、无区域数据直接按路程最短出三条路线不做个性化排序。这三个策略是分级的优先级从高到低依次是热门路线→区域统计→纯规则。逻辑上用if-else就可以实现我们当时担心写得太简单不够体面试图做成自动化调度结果反而维护成本高、线上问题多。后来全部退化成配置化规则反而稳定了。在大数据系统里规则和算法从来不是互斥的该上规则兜底就上规则兜底。4. 可视化大屏把数据变成可决策的视图大屏是这个项目里“最容易被看见”的部分。老板们可能看不懂算法但一定看得懂大屏。看起来是前端活实际上大屏设计的关键在于“指标和数据的组织方式”。4.1 大屏指标设计先回答“给谁看”动笔画大屏之前先搞清楚观看场景。同一个城市出行主题给高管看和给运营看内容完全不一样给管理层看城市实时出行总单量、今日营收、峰值时段、各区单量占比、城际对比。图要少、字要大、一眼能读出“今天好还是不好”。给运营调度看实时单量热力图、区域运力供需比订单量/在线车辆数、拥堵路段TOP10、异常区域。这张屏的作用是“哪里缺车、哪里堵了赶紧调”。我们最终实现的是一个双模式大屏默认展示管理层视角点击进入运营调度模式。数据指标分三层布局——顶部为全局核心指标今日单量、在线车辆、完单率、平均应答时长中部为地图主视觉区订单热力图 轨迹流向底部为榜单类图表拥堵路段TOP10、热门商圈、司机效率分布。4.2 地图轨迹与热力图的实现细节主视觉区是整个大屏的技术重点我们基于ECharts的geoscatterlinesheatmap能力做了组合实现处理了三个细节问题地图底图使用GeoJSON格式的行政区边界数据。地图缩放级别控制在城市—区县两级太细的街道级别在大屏上没有意义反而增加渲染压力。轨迹线渲染大量轨迹线同时绘制会很卡。我们的做法是聚合对OD起终点做网格聚合比如把全城划分成1km×1km的格子统计格子间的出行量只渲染Top N条OD线路线的粗细和透明度表示流量大小。视觉信息密度足够性能也能稳定在30帧以上。热力图用ECharts的heatmap图层数据是“区域订单量”。注意热力图默认是连续渐变颜色需要手动调色板避免红绿对比红绿色盲用户看不清推荐蓝→黄→橙的渐变。4.3 数据刷新策略定时轮询还是WebSocket大屏数据不可能是一张静态图必须持续刷新。当时我们对比了三种方案方案延迟复杂度适用场景前端定时轮询每30秒请求一次30秒级低业务指标变化不频繁的大屏WebSocket实时推送秒级中实时订单单量展示、运力调度监控定时轮询 局部推送混合10~15秒级中高预算有限但想兼顾实时性的折中方案我们最终选的是混合方案关键指标订单量、在线车辆走WebSocket实时推送榜单类图表走30秒轮询。原因是WebSocket全链路改造成本不低而且不是所有指标都需要秒级更新——拥堵路段TOP10这种榜单每30秒刷新完全够用没必要给后端造不必要的压力。提示大屏前端还有一个坑是“内存泄漏”。ECharts实例在数据频繁setOption且图表数量多时会导致内存持续上涨。后来我们加了严格的dispose和clear逻辑并做了定时器统一管理问题才解决。这个问题在开发环境看不出来连续运行几天后才会暴露。5. 全链路架构选型复盘从采集到展示的每一层整个项目的架构按数据流向可以梳理成五层。我画不了图但用文字描述链路全貌采集层业务库Binlog订阅Canal→ 轨迹SDK上报 → Kafka。存储层原始数据入HDFSParquet格式业务维表入MySQL聚合结果入ClickHouse大屏查询用和Redis推荐服务缓存用。计算层Hive跑离线批量任务Spark跑复杂特征工程路线规划服务是Java后端独立部署推荐排序模型是Python服务提供HTTP接口。服务层路线推荐API、大屏数据API、运营后台API三个服务。展示层Vue ECharts做的可视化大屏App端推荐结果通过接口输出。选择这套组合的核心原因说白了就是**“用大家都会的组件解决业务问题而不是为了技术而技术”**。这套组合还有一个附加好处市面上相关文档极多团队换人成本低出了问题能快速定位。毕业设计或者简历项目用这套架构面试官看着也眼熟聊起来不费劲。5.1 为什么选HiveSpark这套组合离线报表和统计聚合这类任务Hive的SQL表达能力完全够用而且稳定。但推荐系统的特征计算里有很多“表关联自己”的复杂场景比如“统计某个用户过去30天每天同一时段走某条路的次数”这种逻辑用Hive SQL写起来别扭用Spark的DataFrame API和UDF会更顺手。Spark还有一个重要用途跑机器学习流水线。我们把GBDT模型的离线训练放在Spark上每周训练一次训练好的模型导出为文件线上Python服务加载做实时预测。这个流程用Spark天然的分布式能力解决了训练数据量大、单机内存不够的问题。5.2 大屏数据查询为什么放ClickHouse大屏SQL查询有一个共同特点查询条件固定、聚合维度和时间范围可变、要求返回快。比如“查询2024年5月20日每个小时的各区订单量”这种SQL用MySQL也不是不能跑但数据量到了千万行级别聚合耗时可能从几百毫秒涨到几秒用户感官上会觉得很卡。ClickHouse的列式存储和向量化执行能力正好匹配这种场景。我们实际测试中千万行级别的数据做GROUP BY聚合ClickHouse耗时大概是MySQL的十分之一左右。迁移之后大屏所有接口的P95延迟控制在300毫秒以内完全满足体验要求。如果你也想复现这个项目ClickHouse是性价比很高的选择。5.3 资源规划与性能预估给一个参考值我们项目中期日均新增原始数据约5000万条主要是轨迹单日原始数据体积约15GBParquet压缩后约3GB。集群用了6台8核32G的服务器搭建HDFS存储用3副本总可用存储约3TB。这样的资源规模处理当前数据量绰绰有余还留了两倍的余量。性能层面的三个关键指标可以作为自测参考路线规划API单次耗时平均30msP95不超过60ms。大屏数据APIP95不超过300ms。每日数据从采集到DWS层可用凌晨2点前全部跑完留给白天查询充足的时间窗口。6. 实测踩坑记录最花时间的不是写代码最后这部分说说我真正踩过的坑。很多坑在写代码时根本想不到只有数据量上来、线上跑起来才会炸。6.1 GPS漂移点把平均车速带偏了第一次算区域平均车速时结果出现了“某条高架平均车速120km/h”的离谱数据。排查后发现是漂移点没清干净——一辆车在高架下行驶GPS点飘到了高架上方两个相距只有几米的位置点之间时间间隔只有5秒算出来的瞬时速度却显示为80km/h。而我们统计平均车速时没有做范围的截断过滤。修复方案加了多重校验——瞬时速度超过道路限速1.5倍的点直接剔除连续两个点的“直线距离/时间”超过120km/h的剔除与所在路段不连通地图匹配失败的轨迹点单独标记不参与速度聚合。这套规则上线后平均车速数据的可信度高了很多。6.2 用户偏好表的更新被全量重算拖垮个性化推荐刚上线时用户偏好表是每天全量重算的。数据量大了之后这个任务从凌晨跑到早上八点还跑不完直接顶到业务高峰把推荐服务的数据库连接池耗尽。修复方案改成增量更新——每天晚上只处理“24小时内有新订单/新选择行为”的用户约占总用户的10%不到。存量用户的偏好特征保留在Redis里增量任务只更新有变化的key。任务耗时从6小时降到40分钟资源占用也大幅下降。这就是典型的“不要总想着全量重算增量才是生产环境的常态”。6.3 大屏首次加载白屏了整整8秒大屏上线前一天联调打开页面白屏了8秒才出内容。排查下来有三个叠加问题一是主视觉区的GeoJSON地图数据文件太大整个市的边界文件3MB网络加载慢二是所有图表第一次请求没有做缓存接口数据全部冷启动三是大屏页面没有拆组件首屏渲染要等所有图表初始化完成。修复方案地图GeoJSON压缩到300KB削减了精度从5位小数降到3位小数实际视觉几乎无差异接口层加了Redis缓存缓存命中后响应时间12ms页面组件按区域拆分懒加载。修复后首屏时间控制在2.5秒以内图表逐个出现视觉上也不会那么生硬。6.4 路线推荐结果抖动的处理用户反馈“为什么同样的出发地和目的地昨天推荐这条今天推荐了另一条后天又变回昨天那条”。这是推荐系统里典型的“结果抖动”问题。抖动不代表推荐错但会让用户觉得系统不稳定、糊涂。处理方式在排序函数中引入了“上一周期选择稳定性”正则项——如果用户短期内选择过某条路线该路线获得一个额外的稳定性加分。同时对规划引擎的拥堵系数做时间平滑同一个时段的历史数据用7天移动平均而不是只看最近一天。这样能避免因为某一天的路况极端情况导致整体推荐路线“跳变”。上线后抖动投诉率下降了七成。回归到整个项目我最大的体会是大数据系统能不能落地七分靠数据治理两分靠工程架构一分靠算法模型。可视化大屏只是“让数据被看见”的最后一公里路线推荐算法再漂亮喂给它的数据是脏的用户看到的依然是一条不靠谱的路线。如果你也想做类似的项目我的建议是先把数据的采集、清洗、分层做扎实了再去追算法和前端特效——这个顺序反了后面全是要还的。
大数据出行推荐系统实战：从路线规划到可视化大屏
1. 先说清楚这个出行推荐系统到底“推”什么去年帮一家区域出行平台做数据中台项目时对方提了个很典型的需求“我们每天能产生几十万条订单和轨迹数据现在这些数据大部分躺在数据库里睡大觉。能不能做一个可视化大屏让管理层一眼看清城市出行态势同时我们的App路线推荐一直被人吐槽‘只会走主路不知道避开拥堵’你们能不能一起解决”这就是“基于大数据的出行路线规划与推荐系统 数据分析可视化大屏系统”这个项目的由来。严格说它并不是一个单点功能而是把一条完整链路串了起来出行数据的采集与清洗 → 数仓分层加工 → 路线规划与个性化推荐 → 指标可视化呈现。任何一个环节掉链子整个系统都会显得“很傻”。文章适合三类人看一是正在做大数据课程设计或毕业设计、想找一个完整项目作为参照的学生二是公司里有大量出行/轨迹数据、想做可视化大屏但不知道怎么落地的开发三是对路线推荐算法感兴趣、想了解“导航软件的推荐到底怎么实现”的产品或后端工程师。全文会按我在项目里的实际操作顺序来讲不绕弯子尽量把每一步的“为什么这么做”也交代清楚。2. 数据层是整个系统的地基采集、清洗、入库路线推荐、大屏可视化表面上是算法和前端的事但实际开发中八成的时间都耗在数据上。数据不对后面全是白搭。这一章我把数据链路上最容易出问题的三个环节拆开说。2.1 数据源与采集通道出行类系统的数据源大体分四类缺了哪一类推荐和大屏都做不完整订单数据用户从下单到完单的全程记录包含上下车经纬度、里程、时长、实付金额、司机ID等。这是付费分析的核心。GPS轨迹数据司机端/用户端上报的经纬度点序列通常每3~5秒上报一次。原始格式一般是device_id, longitude, latitude, timestamp, speed, direction。路况数据道路拥堵等级、平均通行速度。可以采购第三方接口也可以自己根据历史GPS轨迹反推。项目前期预算有限我们用了后者。辅助数据天气雨雪天对出行需求峰值影响极大、区域POI商圈、车站、学校、节假日日历。这些主要用于特征工程和后续推荐排序。采集通道上订单数据走业务库的Binlog订阅Canal比较成熟轨迹数据则走消息队列。我们用的是Kafka上游SDK直推Topic下游挂消费者做实时清洗。早期图省事让轨迹数据直接写MySQL结果单表两千万行之后查询都开始飘后来才老老实实迁到HDFS。这个教训后面细讲。2.2 轨迹数据的清洗与地图匹配GPS轨迹数据是最容易“骗人”的。实际拿到手的轨迹里有漂移点隧道里、高架下、小区里定位点可能突然跳到几百米外的马路上。这种点不处理算出来的平均车速能直接污染整个路段数据。有重复点设备重传导致同一时间戳出现多条数据需要去重按device_id timestamp做聚合取最新。有乱序点上报链路延迟后发的点反而时间戳更早。处理办法是按时间戳排序而不是按到达顺序。清洗之后还有一步关键操作地图匹配Map Matching。因为GPS点是散的而路线规划是在“路网图”上做的必须把这些点“贴”到对应的道路上。最简单的策略是找最近路段并做投影但容易在高架桥上下层道路上弄错。项目里我们采用了基于隐马尔可夫模型的成熟思路不只是看单点最近路还考虑前后点之间的路网连通性用维特比算法求出最可能的道路序列。实测在立交桥密集的区域匹配正确率从83%提升到94%左右。提示如果你的项目只是做统计级大屏比如算区域平均车速粗匹配就够了。但如果要做路线推荐和导航地图匹配这一关过不去后面推荐的路线会直接“穿楼飞河”非常露怯。2.3 数仓分层不要把所有数据堆在一张表里这个项目的数据加工沿用了数仓分层的经典思路虽然听起来有点传统但它是保证“大屏数据快”和“推荐特征全”的基础ODS层原始数据层按天分区存放清洗后的订单、轨迹、路况原始数据。保留全量不删。DWD层明细数据层做维度补全——把订单表关联上司机、车辆、区域、天气等维度把轨迹点聚合成“某辆车某天某路段上的平均速度”这类明细事实。DWS层汇总数据层按城市、行政区、小时、路段等维度预先聚合指标比如每小时各区域订单量、高峰时段最堵的TOP10路段。这一层是直接供可视化大屏查询的。ADS层应用数据层面向具体业务主题的宽表比如“个性化推荐候选集”“用户偏好标签表”。计算引擎选了Hive做离线批量加工、Spark做复杂特征工程。Hive负责每天凌晨把ODS推进到DWSSpark则跑那些需要复杂逻辑的推荐特征。这套组合的好处是生态成熟、招聘容易、出问题能在网上查到一堆解决方案。对于同体量的项目我建议不要一上来就上Flink做全链路实时除非你对流计算团队有把握。3. 路线推荐的核心逻辑从最短路径到个性化排序大屏是给管理层看的而真正每天被用户感知的是App里的路线推荐。这一章讲推荐引擎怎么设计。它分为两层底层是“路网级路线规划”上层是“用户级个性化排序”。3.1 路线规划引擎动态权重下的路径搜索经典的路线规划可以直接套Dijkstra或A*算法在静态路网上找最短路径。但真实出行场景里“最短”不等于“最快”更不等于“用户愿意走”。我们的做法是把路径搜索的代价函数从“距离”换成“综合时间成本”cost(edge) freeSpeedTime(edge) * congestionFactor(edge, timeBucket) penalty(level) preferencePenalty(userType)这个公式是整条路线推荐的灵魂。拆开看freeSpeedTime(edge)自由流时间即道路限速条件下通过该路段的分钟数。congestionFactor(edge, timeBucket)拥堵系数由历史路况数据按“星期几小时”统计得出。比如工作日晚高峰某条主干道的平均车速只有自由流的一半那系数就是2。penalty(level)道路等级惩罚。用户普遍不太喜欢小路非铺装路、胡同即使距离近走起来也不舒服。我们给不同等级道路加了不同的惩罚系数。preferencePenalty(userType)用户偏好项。后面讲个性化时细说。搜索算法上用了A*加双向搜索配合路网层级收缩contraction hierarchies的思路但实现简化了城市级路由平均耗时能控制在30毫秒左右。这个性能对实时性要求高的场景是必要的——用户可等不了三秒才出路线。为什么不用“实时路况”我们做了一个折中用户点“开始导航”时用当天已经积累的实时GPS数据修正历史拥堵系数没有实时数据的路段回退到历史预测值。这套“实时历史”的融合策略既避免了冷启动时段凌晨、清晨没有实时数据的问题又能在早晚高峰捕捉到突发拥堵。3.2 个性化推荐用户偏好、相似人群与热门兜底路径搜索能给出三条候选路线推荐路线、备选一、备选二。但候选路线怎么排序就看个性化推荐了。用户偏好维度我们做了三类都能落地到具体特征历史路线记忆同一个用户从家到公司通勤连续三周都走同一条路说明他对这条路有路径依赖。在候选路线中识别出“与用户历史常走路线重合度高”的路线加权上浮。风格偏好有些用户喜欢走高速时间优先有些用户宁可慢十分钟也不愿意多交过路费成本敏感有些用户明确选择“少走红绿灯”的路线。这些偏好从历史订单和用户画像里提取反映到排序函数上。协同过滤核心思想是“和你行为相似的人可能也会喜欢同样的路”。我们把用户按通勤区域、出发时段、车型、常走路线类型聚类计算相似用户群对不同候选路线的选择比例作为排序特征之一。排序层用了轻量级的LR GBDT模型特征包括路线预计时间、距离、步行距离、红绿灯数量、历史选择概率、与用户偏好的匹配度等。训练数据来自用户真实的选择行为——用户看了三条路线最终点了哪一条这就是天然的标注样本。注意算法不是越复杂越好。我们最早尝试过上深度排序模型效果提升很有限但训练和上线成本翻了几倍。GBDT这种树模型的解释性还更好——你至少能告诉业务方“为什么用户看到的是这条路线”。3.3 冷启动与稀疏数据的兜底策略推荐系统最怕的就是“新用户没有历史行为”。路线推荐也不例外。我们准备了三级兜底热门路线兜底城市级统计“该OD出发地—目的地对出行需求最高、被选次数最多”的路线作为默认候选。新用户直接看到大众选择冷启动问题就解决了一大半。区域统计兜底如果具体OD对的历史数据太少比如出发地是新开的小区就把粒度放宽到“同行政区”的历史路线选择统计挑出区域内高频路线模式作为候选。规则保底极端情况下完全无历史、无区域数据直接按路程最短出三条路线不做个性化排序。这三个策略是分级的优先级从高到低依次是热门路线→区域统计→纯规则。逻辑上用if-else就可以实现我们当时担心写得太简单不够体面试图做成自动化调度结果反而维护成本高、线上问题多。后来全部退化成配置化规则反而稳定了。在大数据系统里规则和算法从来不是互斥的该上规则兜底就上规则兜底。4. 可视化大屏把数据变成可决策的视图大屏是这个项目里“最容易被看见”的部分。老板们可能看不懂算法但一定看得懂大屏。看起来是前端活实际上大屏设计的关键在于“指标和数据的组织方式”。4.1 大屏指标设计先回答“给谁看”动笔画大屏之前先搞清楚观看场景。同一个城市出行主题给高管看和给运营看内容完全不一样给管理层看城市实时出行总单量、今日营收、峰值时段、各区单量占比、城际对比。图要少、字要大、一眼能读出“今天好还是不好”。给运营调度看实时单量热力图、区域运力供需比订单量/在线车辆数、拥堵路段TOP10、异常区域。这张屏的作用是“哪里缺车、哪里堵了赶紧调”。我们最终实现的是一个双模式大屏默认展示管理层视角点击进入运营调度模式。数据指标分三层布局——顶部为全局核心指标今日单量、在线车辆、完单率、平均应答时长中部为地图主视觉区订单热力图 轨迹流向底部为榜单类图表拥堵路段TOP10、热门商圈、司机效率分布。4.2 地图轨迹与热力图的实现细节主视觉区是整个大屏的技术重点我们基于ECharts的geoscatterlinesheatmap能力做了组合实现处理了三个细节问题地图底图使用GeoJSON格式的行政区边界数据。地图缩放级别控制在城市—区县两级太细的街道级别在大屏上没有意义反而增加渲染压力。轨迹线渲染大量轨迹线同时绘制会很卡。我们的做法是聚合对OD起终点做网格聚合比如把全城划分成1km×1km的格子统计格子间的出行量只渲染Top N条OD线路线的粗细和透明度表示流量大小。视觉信息密度足够性能也能稳定在30帧以上。热力图用ECharts的heatmap图层数据是“区域订单量”。注意热力图默认是连续渐变颜色需要手动调色板避免红绿对比红绿色盲用户看不清推荐蓝→黄→橙的渐变。4.3 数据刷新策略定时轮询还是WebSocket大屏数据不可能是一张静态图必须持续刷新。当时我们对比了三种方案方案延迟复杂度适用场景前端定时轮询每30秒请求一次30秒级低业务指标变化不频繁的大屏WebSocket实时推送秒级中实时订单单量展示、运力调度监控定时轮询 局部推送混合10~15秒级中高预算有限但想兼顾实时性的折中方案我们最终选的是混合方案关键指标订单量、在线车辆走WebSocket实时推送榜单类图表走30秒轮询。原因是WebSocket全链路改造成本不低而且不是所有指标都需要秒级更新——拥堵路段TOP10这种榜单每30秒刷新完全够用没必要给后端造不必要的压力。提示大屏前端还有一个坑是“内存泄漏”。ECharts实例在数据频繁setOption且图表数量多时会导致内存持续上涨。后来我们加了严格的dispose和clear逻辑并做了定时器统一管理问题才解决。这个问题在开发环境看不出来连续运行几天后才会暴露。5. 全链路架构选型复盘从采集到展示的每一层整个项目的架构按数据流向可以梳理成五层。我画不了图但用文字描述链路全貌采集层业务库Binlog订阅Canal→ 轨迹SDK上报 → Kafka。存储层原始数据入HDFSParquet格式业务维表入MySQL聚合结果入ClickHouse大屏查询用和Redis推荐服务缓存用。计算层Hive跑离线批量任务Spark跑复杂特征工程路线规划服务是Java后端独立部署推荐排序模型是Python服务提供HTTP接口。服务层路线推荐API、大屏数据API、运营后台API三个服务。展示层Vue ECharts做的可视化大屏App端推荐结果通过接口输出。选择这套组合的核心原因说白了就是**“用大家都会的组件解决业务问题而不是为了技术而技术”**。这套组合还有一个附加好处市面上相关文档极多团队换人成本低出了问题能快速定位。毕业设计或者简历项目用这套架构面试官看着也眼熟聊起来不费劲。5.1 为什么选HiveSpark这套组合离线报表和统计聚合这类任务Hive的SQL表达能力完全够用而且稳定。但推荐系统的特征计算里有很多“表关联自己”的复杂场景比如“统计某个用户过去30天每天同一时段走某条路的次数”这种逻辑用Hive SQL写起来别扭用Spark的DataFrame API和UDF会更顺手。Spark还有一个重要用途跑机器学习流水线。我们把GBDT模型的离线训练放在Spark上每周训练一次训练好的模型导出为文件线上Python服务加载做实时预测。这个流程用Spark天然的分布式能力解决了训练数据量大、单机内存不够的问题。5.2 大屏数据查询为什么放ClickHouse大屏SQL查询有一个共同特点查询条件固定、聚合维度和时间范围可变、要求返回快。比如“查询2024年5月20日每个小时的各区订单量”这种SQL用MySQL也不是不能跑但数据量到了千万行级别聚合耗时可能从几百毫秒涨到几秒用户感官上会觉得很卡。ClickHouse的列式存储和向量化执行能力正好匹配这种场景。我们实际测试中千万行级别的数据做GROUP BY聚合ClickHouse耗时大概是MySQL的十分之一左右。迁移之后大屏所有接口的P95延迟控制在300毫秒以内完全满足体验要求。如果你也想复现这个项目ClickHouse是性价比很高的选择。5.3 资源规划与性能预估给一个参考值我们项目中期日均新增原始数据约5000万条主要是轨迹单日原始数据体积约15GBParquet压缩后约3GB。集群用了6台8核32G的服务器搭建HDFS存储用3副本总可用存储约3TB。这样的资源规模处理当前数据量绰绰有余还留了两倍的余量。性能层面的三个关键指标可以作为自测参考路线规划API单次耗时平均30msP95不超过60ms。大屏数据APIP95不超过300ms。每日数据从采集到DWS层可用凌晨2点前全部跑完留给白天查询充足的时间窗口。6. 实测踩坑记录最花时间的不是写代码最后这部分说说我真正踩过的坑。很多坑在写代码时根本想不到只有数据量上来、线上跑起来才会炸。6.1 GPS漂移点把平均车速带偏了第一次算区域平均车速时结果出现了“某条高架平均车速120km/h”的离谱数据。排查后发现是漂移点没清干净——一辆车在高架下行驶GPS点飘到了高架上方两个相距只有几米的位置点之间时间间隔只有5秒算出来的瞬时速度却显示为80km/h。而我们统计平均车速时没有做范围的截断过滤。修复方案加了多重校验——瞬时速度超过道路限速1.5倍的点直接剔除连续两个点的“直线距离/时间”超过120km/h的剔除与所在路段不连通地图匹配失败的轨迹点单独标记不参与速度聚合。这套规则上线后平均车速数据的可信度高了很多。6.2 用户偏好表的更新被全量重算拖垮个性化推荐刚上线时用户偏好表是每天全量重算的。数据量大了之后这个任务从凌晨跑到早上八点还跑不完直接顶到业务高峰把推荐服务的数据库连接池耗尽。修复方案改成增量更新——每天晚上只处理“24小时内有新订单/新选择行为”的用户约占总用户的10%不到。存量用户的偏好特征保留在Redis里增量任务只更新有变化的key。任务耗时从6小时降到40分钟资源占用也大幅下降。这就是典型的“不要总想着全量重算增量才是生产环境的常态”。6.3 大屏首次加载白屏了整整8秒大屏上线前一天联调打开页面白屏了8秒才出内容。排查下来有三个叠加问题一是主视觉区的GeoJSON地图数据文件太大整个市的边界文件3MB网络加载慢二是所有图表第一次请求没有做缓存接口数据全部冷启动三是大屏页面没有拆组件首屏渲染要等所有图表初始化完成。修复方案地图GeoJSON压缩到300KB削减了精度从5位小数降到3位小数实际视觉几乎无差异接口层加了Redis缓存缓存命中后响应时间12ms页面组件按区域拆分懒加载。修复后首屏时间控制在2.5秒以内图表逐个出现视觉上也不会那么生硬。6.4 路线推荐结果抖动的处理用户反馈“为什么同样的出发地和目的地昨天推荐这条今天推荐了另一条后天又变回昨天那条”。这是推荐系统里典型的“结果抖动”问题。抖动不代表推荐错但会让用户觉得系统不稳定、糊涂。处理方式在排序函数中引入了“上一周期选择稳定性”正则项——如果用户短期内选择过某条路线该路线获得一个额外的稳定性加分。同时对规划引擎的拥堵系数做时间平滑同一个时段的历史数据用7天移动平均而不是只看最近一天。这样能避免因为某一天的路况极端情况导致整体推荐路线“跳变”。上线后抖动投诉率下降了七成。回归到整个项目我最大的体会是大数据系统能不能落地七分靠数据治理两分靠工程架构一分靠算法模型。可视化大屏只是“让数据被看见”的最后一公里路线推荐算法再漂亮喂给它的数据是脏的用户看到的依然是一条不靠谱的路线。如果你也想做类似的项目我的建议是先把数据的采集、清洗、分层做扎实了再去追算法和前端特效——这个顺序反了后面全是要还的。
