基于Python + PySpark的物流行业运力数据分析与优化平台设计毕设源码

博主介绍：✌ 专注于Java,python,✌关注✌私信我✌具体的问题，我会尽力帮助你。

一、研究目的

物流行业在全球供应链体系中占据核心地位，其运力调度与资源配置直接影响整体运营效率与成本结构。随着电商平台爆发式增长及跨境贸易频繁，物流数据量呈指数级扩张，传统单机或小规模数据库已难以满足实时查询与大规模分析需求。与此同时，数据来源多样化——包括车辆GPS轨迹、订单管理系统、仓储管理平台以及天气预报服务——导致数据格式、粒度与质量参差不齐，进一步加剧了信息融合与处理的复杂性。为此，构建一个能够统一采集、清洗、存储并高效分析海量运力数据的技术平台显得尤为迫切。该平台不仅需支持批处理与流式处理，还应具备灵活的模型扩展与可视化展示功能，以满足不同业务场景下的决策支持需求。

本研究旨在基于Python语言与PySpark框架，设计并实现一套面向物流运力数据的全流程分析与优化平台。首先，通过对多源异构数据进行统一抽象与标准化，构建可扩展的数据仓库模型，以保证后续计算任务的输入一致性与可追溯性；其次，利用PySpark的分布式计算优势，实现对历史订单、车辆轨迹及实时传感器数据的批量预处理与特征工程，从而为后续预测与优化算法提供高质量训练样本；再次，在平台核心模块中集成基于机器学习与运筹学的运力需求预测模型、路径规划算法以及资源分配优化器，以实现从需求预判到调度执行的闭环闭合；最后，借助Python生态中的可视化库和Web框架，搭建交互式仪表盘，为运营管理者提供实时监控、异常告警与决策建议的多维度展示。

通过上述平台的构建与应用，本研究期望实现物流运力管理的显著提升。首先，准确的需求预测将降低库存积压与运输空载率，从而减少运营成本并提升资产利用率；其次，优化后的路径规划与调度方案能够缩短配送时效、降低碳排放，为企业可持续发展提供技术支撑；再次，平台的模块化设计与开放接口将促进多业务线之间的数据共享与协同创新，提升整体供应链的韧性与响应速度；最后，本研究所提出的方法与实现方案具有一定的推广价值，可为其他行业在大数据分析与优化决策方面提供参考和借鉴。

二、研究意义

物流行业作为全球供应链体系的关键节点，其运力调度与资源配置直接决定了商品流通效率与成本结构。近年来，随着跨境电商与即时配送需求的激增，物流数据规模呈指数增长，单机数据库已无法满足实时查询与大规模分析的需求。与此同时，多源异构数据的出现——包括车辆GPS轨迹、订单管理系统、仓储信息平台以及气象预报服务——导致数据格式、粒度与质量参差不齐，进一步加剧了信息融合与处理的复杂性。基于此，构建一个统一采集、清洗、存储并高效分析海量运力数据的平台具有重要意义。该平台能够实现批处理与流式处理的无缝切换，为运营决策提供实时且精准的数据支持。通过对历史订单与实时轨迹数据进行特征工程，平台可为需求预测模型与路径规划算法提供高质量训练样本，从而提升调度精度与资源利用率。进一步地，集成运筹学优化器能够在多目标约束下求解最优调度方案，显著降低空载率与运输成本。平台的模块化设计与开放接口将促进跨业务线的数据共享与协同创新，为企业实现数字化转型提供技术支撑。与此同时，可视化仪表盘的搭建将使管理者能够直观监控运营状态、识别异常并及时调整策略，提升供应链韧性与响应速度。总之，本研究所提出的基于Python与PySpark的物流运力分析与优化平台，不仅能够解决大数据时代物流行业面临的技术瓶颈，还将为行业可持续发展、碳排放治理以及服务质量提升提供重要支撑。

三、国内外研究现状

国内外学术界对物流运力数据分析与优化的研究已形成多条主线，主要包括基于大数据的需求预测、车辆路径规划与调度优化、以及端到端物流可视化与监控系统。国外研究在需求预测方面，已将传统统计方法与深度学习模型相结合，例如利用长短期记忆网络（LSTM）对订单量进行时序预测，并通过集成学习提升预测精度；在车辆路径规划方面，学者们提出了多目标动态车辆路径问题（Dynamic VRP）的求解框架，采用强化学习与遗传算法相结合的方法，在考虑实时交通信息与时间窗约束的情况下实现近最优解；此外，针对大规模数据处理，Spark及其Python接口PySpark已被广泛应用于物流数据的批处理与流式分析，实现了对数十亿条轨迹记录的高效聚合与特征提取。国内研究则侧重于物流行业的数字化转型与信息系统建设，已有多家高校与企业开展基于物联网传感器的数据采集平台，利用Kafka、Spark Streaming实现车辆实时位置与状态监控；在需求预测方面，研究者们尝试将XGBoost、LightGBM等梯度提升树模型应用于订单量预测，并结合天气、节假日等外部因素构建多维特征；在路径规划与调度优化方面，国内学者提出了基于蚁群算法与粒子群优化的多仓库配送模型，并通过仿真验证其在实际场景中的可行性；同时，随着区块链技术的引入，一些研究探索了基于智能合约的物流信息共享机制，以提升数据可信度与透明度。总体来看，国外在算法创新与大规模分布式计算框架方面具有较为成熟的理论体系，而国内则在行业应用场景、系统集成与技术落地方面取得显著进展。然而，现有研究多聚焦于单一环节或单一数据源，缺乏完整的端到端平台架构；同时，在多源异构数据融合、实时预测与动态调度的协同优化方面仍存在技术瓶颈。为填补上述空白，亟需构建一个统一的数据采集、清洗、存储与分析框架，并在此基础上集成多模型预测与优化算法，实现从需求预判到调度执行的闭环闭合。

四、预期达到目标及解决的关键问题

本研究的首要目标是构建一套完整的物流运力数据分析与优化平台，该平台能够实现多源异构数据的统一采集、清洗与标准化，并通过分布式计算框架高效处理海量轨迹与订单信息；其次，平台需集成基于机器学习与运筹学的需求预测模型与路径规划算法，实现从需求预判到调度执行的闭环闭合；再次，通过可视化仪表盘为运营管理者提供实时监控、异常告警与决策建议，从而提升物流调度效率与资源利用率；最后，平台应具备模块化设计与开放接口，以支持后续功能扩展与多业务线协同。

在实现上述目标的过程中，研究面临若干关键问题。首先，多源异构数据的质量参差不齐导致特征工程与模型训练难度显著增加；其次，实时预测与动态调度需要在毫秒级延迟内完成计算，传统批处理框架难以满足此需求；再次，预测模型与优化算法在高维空间下易出现过拟合或局部最优，需要有效的正则化与全局搜索策略；此外，Spark集群的资源调度与容错机制需针对物流业务特性进行定制，以保证系统稳定性；最后，平台需兼顾可解释性与可视化需求，使非技术决策者能够理解模型输出并快速做出响应。

五、研究内容

本研究围绕物流行业运力数据的全流程处理与优化展开，旨在构建一套基于Python与PySpark技术栈的端到端平台。首先，在数据采集层面，平台将统一对来自车辆GPS、订单管理系统、仓储信息系统以及外部气象服务等多源异构数据进行实时拉取与批量导入，采用Kafka或Flume等流式消息中间件实现高吞吐量的数据接入；随后，在数据清洗与标准化层面，利用Spark SQL与DataFrame API对缺失值、异常值与格式不一致的记录进行统一处理，并通过自定义UDF完成业务字段映射与时间戳标准化，最终形成可供后续分析的统一数据仓库。接下来，在特征工程层面，平台将基于车辆轨迹信息提取空间特征（如停留时长、转向频率）、基于订单数据构造时间序列特征（如周段波动、节假日影响）以及融合外部环境变量（如天气、交通拥堵指数），并通过Spark MLlib实现特征选择与降维，以提升模型训练效率与泛化能力。随后，平台将集成多种需求预测模型，包括传统ARIMA、LSTM深度网络以及集成学习方法（如XGBoost、LightGBM），通过交叉验证与网格搜索自动调参，最终选取在历史数据上表现最优的模型进行在线预测。与此同时，在路径规划与调度优化层面，平台将实现多目标动态车辆路径问题（Dynamic VRP）的求解框架，采用强化学习与遗传算法相结合的方法，在考虑实时交通信息、时间窗约束以及车辆容量限制的前提下，生成近最优的调度方案，并通过Spark Streaming实现对实时订单与车辆状态的增量更新。系统架构层面，平台将采用微服务化设计，将数据处理、模型推理与优化计算分别封装为独立服务，并通过Docker容器化部署，利用Kubernetes实现弹性伸缩与故障恢复。最后，在可视化与决策支持层面，平台将利用Python的Plotly Dash或Bokeh框架构建交互式仪表盘，展示实时运力状态、预测误差分布、调度执行进度以及关键绩效指标，并通过阈值告警与推送机制实现异常检测与快速响应。通过上述多层次、多技术融合的整体研究内容，本平台将实现从数据采集到决策支持的闭环闭合，为物流企业提供高效、可扩展且易于维护的运力分析与优化解决方案。

六、需求分析

用户需求方面，首先需要满足物流企业运营管理者对实时运力监控的迫切需求，系统应能够在数秒内呈现各车辆当前位置、状态与预计到达时间，并通过地图可视化展示车队整体分布与拥堵热点；其次，决策层希望通过历史数据与预测模型获取未来一段时间内的订单需求分布，从而提前进行车辆调度与仓储资源配置；再次，运营人员需在异常事件发生时获得即时告警，例如车辆偏离预定路线、延误或设备故障等，并能够快速定位问题原因与影响范围；此外，系统应支持多维度报表与指标分析，包括运力利用率、配送时效、空载率与成本消耗等，以便进行绩效评估与持续改进；最后，鉴于物流业务的多变性与跨区域特性，用户期望平台能够灵活配置不同业务线或地区的规则与参数，并支持多租户使用场景，以降低系统维护成本。

功能需求方面，系统首先需实现多源数据采集与接入模块，支持Kafka、Flume等流式消息中间件以及批量文件导入，能够对GPS轨迹、订单信息、仓储状态与天气预报等进行统一接收；其次，数据清洗与标准化模块应具备缺失值填补、异常检测与时间同步功能，并通过Spark SQL完成字段映射与格式统一；随后，特征工程模块需要自动提取空间特征（如停留时长、转向次数）、时间序列特征（如周段波动、节假日影响）以及外部环境特征，并提供降维与特征选择工具；在预测层面，平台应集成多种需求预测模型（ARIMA、LSTM、XGBoost等），并通过自动调参与模型融合实现高精度预测；路径规划与调度模块需支持动态车辆路径问题求解，结合强化学习或遗传算法，在考虑实时交通、时间窗与车辆容量的前提下生成最优调度方案；系统还应提供实时更新机制，利用Spark Streaming对新增订单与车辆状态进行增量计算；在可视化层面，平台需提供交互式地图与仪表盘，展示运力状态、预测结果、调度执行进度与关键绩效指标，并支持自定义报表与导出功能；最后，系统架构应采用微服务化设计，利用Docker容器化部署，并通过Kubernetes实现弹性伸缩与高可用；同时提供RESTful API接口，以便第三方系统或移动端调用，实现业务协同与数据共享。

七、可行性分析

经济可行性方面，本平台的建设成本主要包括硬件采购、软件授权与开发人员工资等，其中服务器集群与存储设备占比约为总成本的四成，数据传输与网络安全设施占比约为三成，软件开发与系统集成费用占比约为二成，其余成本主要用于运维与培训。通过对物流企业日均订单量、车辆调度频次以及现有系统维护费用进行量化分析，可预估平台实施后每年可节约的人工成本、燃油消耗与设备维护费用合计超过五百万人民币；同时，精准需求预测与动态调度将提升运力利用率至八成以上，进一步降低空载率与配送时效，从而在三年内实现投资回收并产生可观利润。考虑到国内物流行业的快速发展与数字化转型需求，本平台具有广阔的市场前景，预计可在五年内实现累计用户数突破千家，并形成稳定的服务收入与增值业务模式。

社会可行性方面，平台的实施将提升物流行业整体运营效率，减少运输过程中的碳排放与能源消耗，对环境保护具有积极意义；同时，通过优化调度与路径规划，可降低车辆拥堵与道路事故风险，提升城市交通安全水平。平台所需的技术人才主要为数据工程师、算法工程师与运维专家，其技术门槛相对较低，能够在现有行业人才储备中快速补充；此外，平台提供的可视化报表与决策支持功能将帮助企业提升管理透明度与服务质量，为消费者提供更准时、可靠的物流体验，从而增强社会信任度。平台在数据安全与隐私保护方面将严格遵守国家相关法规，采用加密存储与访问控制机制，确保用户信息不被泄露，进一步提升社会接受度。

技术可行性方面，Python语言与PySpark框架已在大数据处理与机器学习领域得到广泛验证，其生态系统成熟且社区活跃；利用Spark SQL与DataFrame API可实现高效的数据清洗与转换，支持PB级别数据的分布式计算；在需求预测层面，LSTM、XGBoost等模型已被证明能够处理时序与非线性特征，且可通过Spark MLlib实现分布式训练；路径规划与调度优化可借助强化学习或遗传算法实现近最优解，并通过Spark Streaming完成实时更新；系统架构采用微服务化设计，容器化部署与Kubernetes编排能够满足弹性伸缩与高可用需求。鉴于上述技术组件均为开源或商业成熟产品，且已有多家物流企业在类似场景中成功部署，平台的技术实现具有高度可行性。

八、功能分析

系统功能模块可划分为七大核心层面，分别对应数据采集、预处理、特征构造、预测与优化、实时监控、可视化与决策支持以及系统管理与安全。每一层面均由若干子模块组成，彼此协同完成从原始数据到业务决策的闭环闭合。

首先，数据采集层包括多源接入子模块和流式消息队列子模块。多源接入子模块负责与车辆GPS、订单管理系统、仓储信息平台及外部气象服务进行接口对接，支持RESTful API、WebSocket以及文件上传等多种方式；流式消息队列子模块基于Kafka或Flume实现高吞吐量的数据流转发，并提供主题订阅与消息确认机制，以保证数据完整性与实时性。其次，数据预处理层由清洗与标准化子模块和元数据管理子模块组成。清洗与标准化子模块利用Spark SQL对缺失值、异常值进行填补或剔除，并统一时间戳格式、坐标系及字段命名；元数据管理子模块维护数据字典、版本信息与数据血缘关系，支持后续查询与审计。随后，特征构造层包含空间特征提取子模块、时序特征生成子模块以及外部环境融合子模块。空间特征提取子模块从轨迹数据中计算停留时长、转向次数与速度分布；时序特征生成子模块利用滑动窗口技术提取订单量的季节性与周期性指标；外部环境融合子模块将天气、交通拥堵指数等外部变量与内部业务指标进行关联，形成统一特征矩阵。接下来，预测与优化层由需求预测子模块和调度优化子模块构成。需求预测子模块集成ARIMA、LSTM与XGBoost等模型，并通过交叉验证与网格搜索自动调参，输出未来一段时间内的订单量分布；调度优化子模块实现多目标动态车辆路径问题求解，采用强化学习或遗传算法在考虑实时交通、时间窗与车辆容量约束的前提下生成近最优调度方案，并通过Spark Streaming实现增量更新。随后，实时监控与告警层包含状态跟踪子模块和异常检测子模块。状态跟踪子模块实时聚合车辆位置、速度与订单进度，并在地图上可视化展示；异常检测子模块基于阈值和模型预测误差识别偏离预定路线、延误或设备故障等事件，并通过短信、邮件或企业微信推送即时告警。随后，可视化与决策支持层由仪表盘子模块、报表生成子模块和决策建议子模块组成。仪表盘子模块利用Plotly Dash或Bokeh构建交互式地图与指标面板；报表生成子模块支持自定义维度与周期的报表导出；决策建议子模块根据预测结果与优化方案提供车辆调度、仓储分配及成本控制建议。最后，系统管理与安全层包括用户权限管理子模块、API接口子模块和安全审计子模块。用户权限管理子模块实现基于角色的访问控制；API接口子模块提供RESTful服务，支持第三方系统或移动端调用；安全审计子模块记录数据访问日志、操作日志并支持合规性报告。

通过上述七大层面及其子模块的协同工作，系统能够实现从多源异构数据的实时采集与高效处理，到精准需求预测与动态调度优化，再到直观可视化与即时告警，最终为物流企业提供完整的数据驱动决策支持。

九、数据库设计

表：Vehicle  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
vehicle_id 车辆编号 10 VARCHAR(10) PK 主键，唯一标识车辆  
license_plate 车牌号 15 VARCHAR(15) — 车辆注册信息  
vehicle_type 车型类别 20 VARCHAR(20) — 如“卡车”“轻型货车”等  
capacity_kg 载重（千克） 10 INT — 车辆最大载重  
status_flag 状态标识（0：空闲，1：调度中，2：维护中） 1 TINYINT(1) —  

表：Order  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
order_id 订单编号 20 VARCHAR(20) PK 主键，唯一标识订单  
pickup_latitude 取货纬度 10.6 DECIMAL(10,6) —  
pickup_longitude 取货经度 10.6 DECIMAL(10,6) —  
drop_latitude 送达纬度 10.6 DECIMAL(10,6) —  
drop_longitude 送达经度 10.6 DECIMAL(10,6) —  
scheduled_time 计划到达时间（取货） 19 DATETIME —  
actual_time 实际到达时间（取货） 19 DATETIME —  
order_status 订单状态（0：待派送，1：已派送，2：已完成） 1 TINYINT(1) —  

表：GPS_Record  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
record_id 记录编号 20 VARCHAR(20) PK 主键，唯一标识轨迹记录  
vehicle_id 车辆编号 10 VARCHAR(10) FK（Vehicle.vehicle_id） 关联车辆  
timestamp_utc 时间戳（UTC） 19 DATETIME —  
latitude 纬度 10.6 DECIMAL(10,6) —  
longitude 经度 10.6 DECIMAL(10,6) —  
speed_kmh 速度（公里/小时） 5.2 DECIMAL(5,2) —  

表：Weather_Observation  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
weather_id 观测编号 20 VARCHAR(20) PK 主键，唯一标识观测记录  
region_code 地区编码（如城市或区县） 10 VARCHAR(10) —  
observation_time 观测时间（UTC） 19 DATETIME —  
temperature_celsius 温度（摄氏度） 5.2 DECIMAL(5,2) —  
humidity_percent 湿度（%） 5.2 DECIMAL(5,2) —  
wind_speed_kmh 风速（公里/小时） 5.2 DECIMAL(5,2) —  

表：Traffic_Observation  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
traffic_id 观测编号 20 VARCHAR(20) PK 主键，唯一标识观测记录  
region_code 地区编码（如城市或区县） 10 VARCHAR(10) —  
observation_time 观测时间（UTC） 19 DATETIME —  
congestion_level 拥堵等级（0：无拥堵，1：轻度，2：中度，3：重度） 1 TINYINT(1) —  

表：Demand_Prediction  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
prediction_id 预测编号 20 VARCHAR(20) PK 主键，唯一标识预测记录  
region_code 地区编码（如城市或区县） 10 VARCHAR(10) —  
forecast_time_utc 预测时间点（UTC） 19 DATETIME —  
predicted_order_count 预测订单数目（整数） 10 INT —  

表：Optimization_Plan  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
plan_id 计划编号 20 VARCHAR(20) PK 主键，唯一标识调度计划  
vehicle_id 车辆编号（参与调度） 10 VARCHAR(10) FK（Vehicle.vehicle_id） 关联车辆  
start_time_utc 计划开始时间（UTC） 19 DATETIME —  
end_time_utc 计划结束时间（UTC） 19 DATETIME —  
route_polyline 路线多边形字符串（WKT或GeoJSON） 5000 VARCHAR(5000) —  
plan_status 计划状态（0：待执行，1：执行中，2：已完成，3：已取消） 1 TINYINT(1) —  

表：Alarm  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
alarm_id 告警编号 20 VARCHAR(20) PK 主键，唯一标识告警记录  
vehicle_id 车辆编号（可为空） 10 VARCHAR(10) FK（Vehicle.vehicle_id） 关联车辆  
order_id 订单编号（可为空） 20 VARCHAR(20) FK（Order.order_id） 关联订单  
alarm_type 告警类型（如“偏离路线”“延误”“设备故障”） 20 VARCHAR(20) —  
alarm_time_utc 告警时间（UTC） 19 DATETIME —  
description 告警描述信息 2000 VARCHAR(2000) —  

表：User  
字段名(英文) 说明(中文) 大小 类型 主外键 备注  
user_id 用户编号 20 VARCHAR(20) PK 主键，唯一标识系统用户  
username 用户名（登录名） 30 VARCHAR(30) —  
password_hash 密码哈希值（加密后存储） 64 CHAR(64) —  
role_name 角色名称（如“管理员”“调度员”“分析师”） 20 VARCHAR(20) —  

上述表结构遵循第一范式，主键唯一标识每条记录；通过外键关联实现第二范式；所有非主属性均完全函数依赖于主键，避免第三范式违例。字段类型与长度选取兼顾存储效率与业务需求，支持后续扩展与索引优化。

十、建表语句

CREATE TABLE Vehicle (
    vehicle_id     VARCHAR(10)   NOT NULL,
    license_plate  VARCHAR(15),
    vehicle_type   VARCHAR(20),
    capacity_kg    INT,
    status_flag    TINYINT(1)   DEFAULT 0,
    PRIMARY KEY (vehicle_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='车辆基本信息表';

CREATE TABLE Order (
    order_id        VARCHAR(20)   NOT NULL,
    pickup_latitude  DECIMAL(10,6),
    pickup_longitude DECIMAL(10,6),
    drop_latitude   DECIMAL(10,6),
    drop_longitude  DECIMAL(10,6),
    scheduled_time  DATETIME,
    actual_time     DATETIME,
    order_status    TINYINT(1)   DEFAULT 0,
    PRIMARY KEY (order_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单信息表';

CREATE TABLE GPS_Record (
    record_id      VARCHAR(20)   NOT NULL,
    vehicle_id     VARCHAR(10)   NOT NULL,
    timestamp_utc  DATETIME      NOT NULL,
    latitude       DECIMAL(10,6),
    longitude      DECIMAL(10,6),
    speed_kmh      DECIMAL(5,2),
    PRIMARY KEY (record_id),
    INDEX idx_gps_vehicle (vehicle_id),
    INDEX idx_gps_time   (timestamp_utc),
    CONSTRAINT fk_gps_vehicle
        FOREIGN KEY (vehicle_id) REFERENCES Vehicle(vehicle_id)
        ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='车辆轨迹记录表';

CREATE TABLE Weather_Observation (
    weather_id          VARCHAR(20)   NOT NULL,
    region_code         VARCHAR(10),
    observation_time    DATETIME      NOT NULL,
    temperature_celsius DECIMAL(5,2),
    humidity_percent    DECIMAL(5,2),
    wind_speed_kmh      DECIMAL(5,2),
    PRIMARY KEY (weather_id),
    INDEX idx_weather_region (region_code),
    INDEX idx_weather_time   (observation_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='天气观测表';

CREATE TABLE Traffic_Observation (
    traffic_id          VARCHAR(20)   NOT NULL,
    region_code         VARCHAR(10),
    observation_time    DATETIME      NOT NULL,
    congestion_level    TINYINT(1)    DEFAULT 0,
    PRIMARY KEY (traffic_id),
    INDEX idx_traffic_region (region_code),
    INDEX idx_traffic_time   (observation_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='交通拥堵观测表';

CREATE TABLE Demand_Prediction (
    prediction_id      VARCHAR(20)   NOT NULL,
    region_code        VARCHAR(10),
    forecast_time_utc  DATETIME      NOT NULL,
    predicted_order_count INT,
    PRIMARY KEY (prediction_id),
    INDEX idx_pred_region (region_code),
    INDEX idx_pred_time   (forecast_time_utc)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='需求预测表';

CREATE TABLE Optimization_Plan (
    plan_id            VARCHAR(20)   NOT NULL,
    vehicle_id         VARCHAR(10),
    start_time_utc     DATETIME      NOT NULL,
    end_time_utc       DATETIME      NOT NULL,
    route_polyline     VARCHAR(5000),
    plan_status        TINYINT(1)    DEFAULT 0,
    PRIMARY KEY (plan_id),
    INDEX idx_plan_vehicle (vehicle_id),
    INDEX idx_plan_start   (start_time_utc),
    CONSTRAINT fk_plan_vehicle
        FOREIGN KEY (vehicle_id) REFERENCES Vehicle(vehicle_id)
        ON UPDATE CASCADE ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='调度优化方案表';

CREATE TABLE Alarm (
    alarm_id          VARCHAR(20)   NOT NULL,
    vehicle_id        VARCHAR(10),
    order_id          VARCHAR(20),
    alarm_type        VARCHAR(20),
    alarm_time_utc    DATETIME      NOT NULL,
    description       VARCHAR(2000),
    PRIMARY KEY (alarm_id),
    INDEX idx_alarm_vehicle (vehicle_id),
    INDEX idx_alarm_order   (order_id),
    CONSTRAINT fk_alarm_vehicle
        FOREIGN KEY (vehicle_id) REFERENCES Vehicle(vehicle_id)
        ON UPDATE CASCADE ON DELETE SET NULL,
    CONSTRAINT fk_alarm_order
        FOREIGN KEY (order_id) REFERENCES Order(order_id)
        ON UPDATE CASCADE ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='告警信息表';

CREATE TABLE User (
    user_id   VARCHAR(20)   NOT NULL,
    username  VARCHAR(30)   NOT NULL,
    password_hash CHAR(64),
    role_name VARCHAR(20),
    PRIMARY KEY (user_id),
    UNIQUE KEY uk_user_username (username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻