交通智能调度实战：Spark清洗、Hive特征工程与决策模型全解析

前年我接手一个城市交通智能调度项目，本来以为算法才是核心，真正做进去才发现，大数据在交通领域的深层难点，是把零散、脏乱的原始数据洗干净，再让它真正参与决策。项目开始第一个月，GPS轨迹在市区主干道大面积漂移，网约车订单和轨迹对不上，卡口过车数据有近15%的重复记录，调度员看大屏数据时眼神里全是怀疑。这篇就把一个完整的交通智能调度优化链路写出来，覆盖集群规划、数据接入、Spark清洗、Hive特征工程、调度决策模型和最终的可视化大屏，重点记录踩过的坑和调整过程，给正在做交通大数据、网约车数据分析或智慧城市项目的同行一份可以直接参考的实战复盘。

1. 交通调度为什么非得上大数据？传统经验模型卡在哪

1.1 传统调度的问题：固定配时与“拍脑袋”派单

先说传统交通调度是怎么工作的。绝大多数城市的公交发车间隔是固定时刻表，早晚高峰明明客流波动剧烈，车辆还是按老节奏跑，经常出现某条线路挤到人贴门、司机申请加车，调度员还在按上个星期的平均间隔做决定。信号灯配时也是固定周期，很多路口晚上十一点车流已经很稀了，依然要等90秒红灯。网约车平台早期的派单逻辑更粗暴，“谁近派谁”看似合理，实际会造成区域运力一边倒：城东爆单，城西空驶，司机在城西苦等二十分钟接不到一单。

这些问题的共性在于三个缺陷：反馈周期太长，空间粒度太粗，预测能力为零。所谓反馈周期长，指的是调度员看到的是上一个小时甚至昨天的数据；空间粒度粗，指的是一个片区几百辆车，根本看不出哪条路、哪个路口在积压；预测能力为零，就是只能对现状被动响应，没法对未来十五分钟的需求做预判。路况是会传染的，晚高峰一个路口堵住，二十分钟后相邻三个路口全部瘫痪。没有预测手段，调度只能一直追着问题跑。

1.2 城市交通数据量的真实体量

有人会问，交通调度用了这么多年经验，为什么突然需要大数据？直接看数据量就明白了。按一座中等城市估算，全市出租车加网约车约一万五千辆，GPS回传间隔三到五秒，一辆车一天产生1.7万到2.9万条轨迹点，仅浮动车数据一天就有2.5亿条左右。加上卡口过车数据、公交刷卡记录、信号灯检测器流量、气象数据、大型活动事件，一天新增的记录量能到几十亿条，原始文本落盘大约6到10TB。

这个体量，Excel肯定没戏，传统关系型数据库也不是完全不能处理，但调度决策要的是分钟级甚至秒级出结果。比如晚高峰突然下暴雨，全城叫车需求十分钟内翻倍，系统得马上重新分配运力，跑个聚合SQL要半小时，调度员早就被乘客电话淹没了。所以HDFS加Spark加Hive这套分布式组合，在这个场景下几乎是必然选择：HDFS扛存储，Spark扛清洗和实时计算，Hive扛离线特征加工。

1.3 大数据在调度里的角色：从“事后统计”到“事前决策”

我在项目里对团队强调过一句话：大数据在交通调度里不是用来做报表的，是用来做决策的。传统报表解决的是“昨天发生了什么”，智能调度要回答的是“接下来十五分钟会发生什么，我该怎么提前动”。

实际落地上，核心是两件事。第一件是预测，把过去三个月每个十五分钟粒度上的叫车需求、路况、客流数据拿来构造样本，让模型学会在什么条件下需求会涨、哪里会堵，提前分配运力和调整信号灯方案。第二件是匹配，预测之后要把决策落到具体对象上，比如哪辆车去接哪个订单、哪条线路需要临时加车、哪个路口需要延长绿灯。这两件事没有大数据基础都做不了：预测需要海量历史样本，匹配需要实时的全量运力与需求状态，而这两类数据恰好都是大数据的强项。

2. 集群规划与数据接入：从裸机到能跑Spark作业

2.1 集群部署策略：机器配置、软件栈和资源池划分

我们当时是五台服务器起家的集群，一台主节点加四台从节点。主节点32核128G内存，从节点16核64G内存，每台机器挂四块4TB数据盘，网卡万兆。这个配置对中型城市的交通数据是够用的，前三个月跑下来CPU峰值在60%左右，没有出现资源打满的情况。

软件栈选型上，Hadoop用3.x版本，Spark用3.2，Hive用3.1，ZooKeeper三节点，Kafka两台就够。这里有个容易忽略的点：YARN资源池一定要分成两条队列，离线队列占70%资源，实时队列占30%。如果混在一起，离线任务一跑起来，实时任务全被堵在队列外面，调度决策延迟直接飙到十分钟以上。我们后来给实时队列加了容量调度器配置，核心参数是capacity=30，maximum-capacity=40，保证即使离线任务再多，实时计算也有最低资源保障。

HDFS副本数我建议设置成3，小规模集群数据安全是第一位的，别为了省磁盘抠副本数。数据盘必须独立挂载，不要和系统盘混在一起，否则系统日志写满磁盘，NameNode直接进入安全模式，整个集群罢工。数据目录规划上，我把HDFS数据目录、YARN日志目录、Spark临时目录分别指向不同的磁盘分区，遇到问题排查时互不干扰。

2.2 数据接入管道：Kafka实时流与批量文件双通道

交通数据来源分两类，接入方式完全不同。

第一类是实时流数据，包括GPS定位和网约车订单状态。GPS终端通过MQTT或TCP长连接上报，后端服务统一写入Kafka，按业务拆成独立topic：gps_track存轨迹点，order_event存订单状态变更，traffic_flow存信号灯检测器流量。Kafka分区数设计上要算一下：一个分区在普通机械盘上每秒大概能写几千到一万条，GPS全城峰值每秒约五千条写入，理论上八个分区就够，我最后设了十六个分区，留出大型活动或极端天气下流量翻倍的余量。分区太少会导致单分区写入超限，分区太多又会让下游Spark并发拉取压力变大，这个平衡点要结合自己的数据量去调。

第二类是批量文件数据，比如卡口过车记录、公交刷卡数据，很多以五分钟一个文件的形式从第三方系统推送过来，先落FTP或对象存储，再用DistCp定时拉入HDFS原始目录。这里要注意文件的时间对齐问题：卡口数据是按设备本地时间生成的，不同设备时钟漂移会造成文件内数据时间戳和文件名时间不一致，落地后一定要以数据内容里的时间戳为准重新分区，不能直接看文件名时间。

2.3 数据分层：ODS、DWD、DWS怎么划分

数据进集群之后不能直接给模型用，我按标准数仓思路分了三层：

• ODS层：原始数据照单全收，JSON解析成结构化字段直接落表，GPS轨迹、订单明细、卡口数据全放这层。这一层保留全部历史，作为排查问题的底账。
• DWD层：清洗、去重、修正漂移之后的明细事实表。比如GPS轨迹清洗后的dwd_gps_track_clean，订单事实表dwd_order_fact，字段口径统一，能回答“某辆车某时刻在哪”这种明细问题。
• DWS层：按区域、时间粒度汇总的服务数据。比如每五分钟区域供需比dws_region_supply_demand_5min，路段平均速度dws_road_speed_15min，这是直接给调度模型和可视化大屏供数的层。

分层的好处很实际：调度模型不用直接面对脏数据，离线任务和实时任务共用DWS数据，口径统一。我见过一些项目为了省事，模型直接查ODS层，结果清洗逻辑改一次，模型结果变一次，根本没法上线。

3. 清洗GPS轨迹和订单数据的那些坑：Spark作业调优实录

3.1 GPS漂移清洗：先用启发式规则，别一上来就上HMM

GPS漂移是最常见也最头疼的问题。城市峡谷、隧道、地下停车场里，终端信号反射导致位置跳变，前一秒还在A路口，下一秒跳到三公里外的B路段，再下一秒又跳回来。如果不处理，后面算路段速度、算区域运力全部失真。

地图匹配（HMM）效果好，但工程复杂度高，我们第一版没有上，先用启发式规则把明显漂移过滤掉。核心规则是：用前后两个轨迹点的球面距离除以时间差计算瞬时速度，如果速度超过给定阈值且连续三个点都超，判定为漂移。城市道路正常车速基本不会超过120km/h，所以阈值设为120，高速公路场景单独放开到150。

from pyspark.sql import functions as F def haversine_distance(lat1, lon1, lat2, lon2): # 球面距离计算，返回米 ... df = df.withColumn("prev_lat", F.lag("lat").over(Window.partitionBy("device_id").orderBy("ts"))) df = df.withColumn("prev_lon", F.lag("lon").over(Window.partitionBy("device_id").orderBy("ts"))) df = df.withColumn("prev_ts", F.lag("ts").over(Window.partitionBy("device_id").orderBy("ts"))) df = df.withColumn( "instant_speed", haversine_distance(F.col("lat"), F.col("lon"), F.col("prev_lat"), F.col("prev_lon")) / ((F.col("ts") - F.col("prev_ts")).cast("long") / 1000.0) ) df = df.withColumn( "is_drift", F.when(F.col("instant_speed") > 120, 1).otherwise(0) ) # 连续3个漂移点则过滤整段 df.createOrReplaceTempView("gps_with_flag") cleaned = spark.sql(""" SELECT * FROM ( SELECT *, SUM(is_drift) OVER (PARTITION BY device_id ORDER BY ts ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS drift_cnt FROM gps_with_flag ) t WHERE drift_cnt < 2 """)

跑完这版规则，GPS数据量减少了约7%，抽查结果里明显跳变基本消失。启发式规则的优势是快、可解释、易调参，等业务稳了再考虑上地图匹配提高精度。

3.2 Spark任务资源调优：从跑一个多小时到十几分钟

第一版清洗任务全量跑历史数据，一个多小时才能跑完，根本没法支撑每天增量处理。后来看Spark UI定位问题，发现shuffle量异常大，数据倾斜明显，某些executor处理的数据量是其他的五倍以上。

调优做了三件事。第一，重新设置executor规格，driver内存2G，executor内存8G，每个executor四个core。第二，把spark.sql.shuffle.partitions从默认200调到600，让shuffle后的分区更均匀，减少单分区数据量。第三，开启Spark 3.0之后的AQE（Adaptive Query Execution），spark.sql.adaptive.enabled=true，让Spark在运行时自动合并小分区、优化join策略。

调优前后的对比很直观：

这里说个心得：不要一上来就堆内存，先看Spark UI里每个stage的耗时和shuffle量，找到瓶颈再针对性调。有一次我们以为内存不够，把executor加到16G，结果GC时间反而变长，任务更慢了，后来才知道是分区数太少导致单分区数据量过大，加大分区数就解决了。

3.3 订单轨迹匹配与状态码口径统一

订单表和轨迹表的关联也踩了坑。一开始直接按订单ID和时间窗口join，结果一单匹配出十几条轨迹，或者明明有轨迹却匹配不到，问题出在订单跨天和设备换绑上。后来统一规则：订单表关联轨迹表必须同时满足device_id一致、时间在订单开始和结束时间之间，并加上订单状态字段过滤，只保留载客状态下的轨迹点，用于后续的路径还原。

更隐蔽的问题是状态码口径。网约车平台不同业务线的订单状态码定义不一致，有的用1代表接单、2代表载客，有的用10、20，还有的是英文枚举。如果不做映射统一，算出来的区域供需比会直接错。我们在DWD层建了一张状态码映射维度表，把所有来源的原始状态码统一转为内部标准码，再往下游分发。这个动作看起来不起眼，但直接影响最终指标的正确性，比算法调参重要得多。

4. 离线特征工程与Hive优化：调度决策的“数据底子”

4.1 调度特征表怎么设计：用一张主宽表承载80%的查询

调度模型和可视化大屏需要用到的特征，主要集中在区域和时间维度上。我设计DWS层时没有做成一大堆分散的窄表，而是用一张主宽表加少量维度表的结构。主宽表按dt + hour + region_id分区，每一行代表一个区域在一个十五分钟窗口内的完整特征：

• 需求侧特征：叫车请求量、完成订单量、取消订单量、平均响应时长
• 供给侧特征：活跃车辆数、空驶车辆数、平均接驾距离
• 路况特征：区域内路段平均速度、拥堵里程占比、排队长度均值
• 外部环境特征：天气编码、温度、降雨量、是否节假日、周边POI密度

建表时存储格式很关键，我用ORC加SNAPPY压缩，比纯文本格式查询速度快好几倍，磁盘占用也小很多。

CREATE TABLE dws.dws_region_supply_demand_15min ( region_id STRING COMMENT '区域编码', hour STRING COMMENT '小时', window_start STRING COMMENT '窗口开始时间', demand_cnt BIGINT COMMENT '需求订单数', finish_cnt BIGINT COMMENT '完成订单数', cancel_cnt BIGINT COMMENT '取消订单数', avg_response_sec DOUBLE COMMENT '平均响应秒数', active_vehicle_cnt BIGINT COMMENT '活跃车辆数', idle_vehicle_cnt BIGINT COMMENT '空驶车辆数', avg_speed_kmh DOUBLE COMMENT '平均速度', congestion_ratio DOUBLE COMMENT '拥堵里程占比', weather_code STRING COMMENT '天气编码', is_holiday INT COMMENT '是否节假日' ) PARTITIONED BY (dt STRING) STORED AS ORC TBLPROPERTIES ('orc.compress'='SNAPPY');

宽表的好处是调度模型取特征时只查一张表，不需要频繁join，查询效率高。代价是每次写入要做大量的汇总计算，但这个成本在离线环节是可接受的。如果业务后期加了新的特征维度，再单独扩展维度表，不要轻易动主宽表结构。

4.2 Hive小文件问题：写任务一小时，读任务一下午

项目推进到第三周，团队成员反馈Hive查询越来越慢，一个简单的count都要跑十几分钟。我一看HDFS目录，整个人都麻了——一个分区下躺着几万个小文件，每个才几十KB。这是Spark写入Hive时的典型问题：shuffle分区过多，每个分区写出的数据量太小，目录下全是小零碎文件。文件一多，NameNode内存压力大，任务启动时要扫描的元数据量也大，查询自然慢。

解决分两步走。第一步是治本，控制写入时的分区大小。Spark写入Hive前设置合理的spark.sql.shuffle.partitions，并加一个DISTRIBUTE BY让数据按目标分区字段聚类，减少跨分区小文件。

INSERT OVERWRITE TABLE dws.dws_region_supply_demand_15min PARTITION (dt='2024-06-01') SELECT ... FROM dwd.dwd_order_fact DISTRIBUTE BY region_id;

第二步是治标，对已经产生的小文件做合并。ORC格式的表直接执行ALTER TABLE ... CONCATENATE，不需要重写数据，几分钟就能把几万个小文件合并成几百个。如果表不是ORC格式，就用INSERT OVERWRITE重写一次，顺便把格式转成ORC。这里提醒一句：小文件问题是Hive性能最大的隐形杀手之一，处理完文件合并后，同一张表的count查询从十五分钟降到了一分半，效果立竿见影。

4.3 Join倾斜的排查与治理：一个从4小时到20分钟的案例

还有一个印象深刻的慢SQL优化案例。一张订单事实表Join区域维度表，任务跑了四个小时都没结束，明显不正常。我先跑了一个统计SQL，按join key分组计数，发现其中一个区域key的数据量占全表的40%——热门商圈的数据量是普通区域的几十倍，这就是典型的join数据倾斜。

处理方法是用两阶段join。先把倾斜key的数据单独拎出来，用广播方式和小表维度表直接join，因为单个热门区域的数据量即使倾斜，也远小于全表；其余非倾斜key的数据走正常的shuffle join。最后把两部分结果union all起来。

-- 第一阶段：倾斜key单独join INSERT INTO temp_result_skew SELECT /*+ BROADCAST(dim) */ t.*, dim.region_name FROM (SELECT * FROM order_fact WHERE region_id = 'HOT_SPOT') t JOIN dim_region dim ON t.region_id = dim.region_id; -- 第二阶段：非倾斜key正常join INSERT INTO temp_result_normal SELECT t.*, dim.region_name FROM (SELECT * FROM order_fact WHERE region_id != 'HOT_SPOT') t JOIN dim_region dim ON t.region_id = dim.region_id;

同时开启hive.optimize.skewjoin=true作为兜底。经过这个拆分，任务从四个多小时降到二十分钟以内，之后我把所有关键join任务都检查了一遍，凡是涉及热门区域的都不再直接join，而是提前加这种拆分逻辑。排查思路可以复制：先group by看分布，再针对性拆，不要盲目加大资源。

5. 智能调度决策模型：从“经验派”到“数据派”

5.1 15分钟粒度需求预测：先用GBDT跑稳，再谈深度学习

调度决策的第一步是预测未来十五分钟每个区域的需求量。我们没有一开始就上LSTM、Transformer这些东西，而是先用GBDT模型跑稳，因为业务上首先要的不是模型多新，而是结果稳定、特征可控、出了问题能解释。

特征来自DWS宽表：历史同时段需求量、前一小时需求趋势、当前在途车辆数、天气、节假日、周边POI密度。训练样本按时间序列构造，用过去九十天的数据训练，预测未来十五分钟每个区域的需求区间。GBDT对这类表格数据的拟合能力很强，训练速度快，特征重要性可以直接输出，方便跟业务解释为什么某个区域预测值高——是因为历史同时段高，还是因为雨天叠加了晚高峰。后期验证稳定后，再考虑用序列模型提升精度也不迟。

实际运行中，模型每天离线训练一次，预测结果写入Redis，供在线调度服务读取，预测值配合实际值做滚动校验，如果预测偏差连续三天超阈值，就触发重新训练。

5.2 车辆派单的供需匹配：把派单问题建模成线性分配

预测出需求之后，要把空闲车辆分配到需求订单上。这个问题的本质是一个线性分配问题：有M个空闲司机，N个待服务订单，目标是最小化乘客平均等待时间，同时控制司机的接驾距离，避免为了接一单让司机跑六公里空驶。

核心上用的是匈牙利算法的变体。构造一个代价矩阵，每个单元格表示司机i接到订单j的代价，代价包括预估接驾时间、空驶距离惩罚、区域供需失衡惩罚。如果司机和订单不在同一个网格内，且距离超过阈值，直接把代价设成无穷大，避免出现跨半个城去接人的情况。

from scipy.optimize import linear_sum_assignment cost_matrix = build_cost_matrix(idle_drivers, pending_orders) row_ind, col_ind = linear_sum_assignment(cost_matrix) assignments = [(idle_drivers[row_ind[i]], pending_orders[col_ind[i]]) for i in range(len(row_ind))]

这个匹配策略上线后，平均接驾时间下降约9%，同时司机的平均空驶里程没有上升，说明匹配不是单纯“就近”，而是综合考虑了区域供需。这里要注意的是代价矩阵的规模，全城同时有上千个空闲司机和订单时，直接调linear_sum_assignment几千乘几千的矩阵性能不够，需要先按网格分区做预聚类，每个区内部再做匹配，减少矩阵规模。

5.3 信号灯配时优化：用排队长度和流量比替代固定配时

常规信号灯配时是固定周期，各相位绿灯时长按历史经验分配。我们接入信号灯检测器数据后，发现一个路口在一天内不同方向的流量比例变化极大，早高峰南向北流量是北向南的两倍，晚高峰正好反过来。固定配时在这种路口表现很差，排队长的方向绿灯不够用，排队短的方向绿灯空放。

数据驱动的思路是：每个控制周期开始时，根据各方向实时排队长度和到达流量，动态计算最优周期和绿信比。简化公式是：周期时长依据路口总流量和饱和度计算，各相位绿灯时间按流量比分配，再叠加排队长度修正项。排队超过阈值的相位额外增加绿灯，排队为空的方向压缩绿灯。

实际改造了三个路口做试点，其中一个路口早高峰南进口排队原本经常溢到上游路口，调整后排队长度下降18%左右，北进口车辆延误增加控制在5%以内，整体通行效率是提升的。这个方向项目周期较长，涉及路口控制器的协议对接，但验证了同一套数据基础设施可以复用到不同调度场景。

5.4 实时决策链路：模型结果怎么送到调度员手里

离线预测是在T-1日晚上跑完，产生次日全天的分时预测方案，但交通状况随时在变，决策链路必须支持实时修正。我们在离线预测的基础上叠加了一整套实时监测：Kafka里的GPS和订单流通过Spark Streaming实时计算当前各区域供需比，和预测值做偏差比较。偏差超过阈值的区域，自动触发调度建议，比如向该区域推送空驶车辆、调整公交发车间隔、通知信号灯系统增大某个方向绿信比。

实时链路的关键是控制延迟。Kafka消费者如果处理不过来，事件堆积，等计算结果出来时现场状况早就变了。我们的监控告警是：Kafka消费延迟超过三分钟就报警，超过五分钟触发自动扩容。调度员的工作台页面五秒刷新一次区域状态，模型建议以“可执行任务”的形式推送给调度员，而不是自动执行——在交通调度里，人的确认环节还是很有必要的，尤其涉及跨区域协调时，机器建议容易忽略一些文档之外的现实约束。

6. 调度效果监控大屏：用Flask+ECharts把优化结果摆出来

6.1 大屏指标设计：展示之外还要能指导调度

项目做到后半段，业务方提出要一个可视化大屏，把调度效果展示出来。大屏设计上我坚持一个原则：不只是给领导看的漂亮图表，更要能辅助调度员日常工作。所以大屏选了三块核心内容：左侧是区域运力热力图，实时展示各区域供需比；中间是地图轨迹图层，展示活跃车辆分布和订单流向；右侧是时序指标卡，展示平均接驾时间、响应时长、优化前后对比折线。

指标口径是重点。比如“平均接驾时间”，必须明确是从乘客下单到司机接单的时间，还是从司机接单到上车的时间，两个口径差好几倍。我们和大屏团队成员对了三遍口径，再找业务方确认，最终统一了所有指标的定义和计算SQL。这里建议所有做数据大屏的人，上线前列一份指标口径清单，和业务方逐条确认，避免大屏上线后被质疑数据不对。

6.2 Flask接口与ECharts渲染的落地细节

技术实现上，后端用Flask，前端用ECharts，这是做数据大屏最顺手的组合之一。Flask负责从DWS表和Redis读数据，封装成JSON接口。实时刷新分成两种：不需要秒级变化的数据用前端定时轮询，三秒一次；需要实时推送的数据用WebSocket，比如当前供需比的变化。

from flask import Flask, jsonify import redis app = Flask(__name__) r = redis.Redis(host='10.0.0.8', port=6379, decode_responses=True) @app.route('/api/supply_demand') def supply_demand(): data = r.hgetall('dws:region_supply_demand') return jsonify(data)

ECharts渲染时使用geo地图加scatter图层，区域聚合值用visualMap做颜色映射，红色代表供不应求，绿色代表运力充足。地图JSON使用城市geojson文件，坐标要和GPS数据的坐标系保持一致，这里坑过我们一次：GPS数据是WGS84坐标，地图底图用的是GCJ02，偏移一两公里，热力点全飘到隔壁区。后来统一在数据清洗层做了坐标转换，问题消失。

6.3 大屏数据正确性验证：别让业务方看到错误数字

大屏数据最容易翻车的是实时刷新环节。某次上线后，业务方反馈“区域红色报警了，但实际路口明明很空”，排查发现是实时任务重跑导致Redis被写入了一批重复数据。后来我们在写入链路加了一个窗口去重逻辑，同一条事件只允许进一次实时聚合，并且大屏展示的数据每天凌晨和离线DWS表的批统计做一次对账，数字偏差超过1%就告警。

另外前端渲染性能也踩过坑。ECharts地图上直接在scatter图层画全量几十万个GPS点，直接卡爆浏览器，实测五万点以上时帧率掉到20，页面操作卡顿。解决方案是网格聚合：把全城按1公里网格切分，每个网格只展示聚合后的车辆数和供需比，点数压缩到两千以内，大屏刷新瞬间恢复流畅。这个方案对调度员看区域状态没有任何损失，反正他们也不会去数单个车辆。

最后一个建议是：大屏上线后一定要让调度员实际用起来，并根据他们的反馈迭代。我们第二批迭代就是根据调度员意见加的“拥堵趋势预测”面板——他们不满足于看当前状态，还想知道接下来半小时哪里会堵。这个需求倒逼我们把离线预测模型的结果同步到大屏上，产品的价值也上了一个台阶。

回看这个项目，最大的体会是算法没有想象中重要，数据质量和工程链路才是决定成败的环节。我一度花了三周调派单算法，提升不到5%，后来回头修了一个GPS漂移过滤逻辑，调度响应时间反而下降了12%。对刚入行做交通大数据的人，我的建议是先把数据链路打通、指标口径统一，再谈模型。这个领域不是靠一个黑盒模型通吃的，它需要把数据、算法和业务场景揉在一起，最后所有技术都要回答一个问题：调度员愿不愿意用你给的建议。