ODPS-based minute-level offline driver duration calculation method

Abstract

The invention discloses an ODPS-based minute-level off-line driver duration calculation method, which collects order state data of 5-minute granularity on an ODPS platform, can perform fragmentation processing on an order state accurate to a minute level, and calculates driver receiving, waiting and driving duration by using an LEAD window function. Compared with traditional coarseness calculation, the high-frequency fragmentation method has the advantage that the service duration calculation precision is greatly improved. According to the method and the system, a bottom-taking processing mechanism is adopted to ensure the accuracy and the consistency of time length calculation when an order is processed, especially when a cross-fragment order is processed, and in addition, the load of vehicle-mounted calculation equipment is reduced by unloading a calculation-intensive task to an edge node. By using a method of combining an off-line optimization model and an on-line algorithm, the system can dynamically adjust task allocation and improve the flexibility and efficiency of task scheduling, thereby effectively solving the problems of low task processing efficiency and low resource utilization rate of a traditional online car-hailing platform.

Description

Technical Field

[0001] The present invention belongs to the field of driver duration calculation, and specifically, relates to a method for calculating offline driver duration at the minute level based on ODPS. Background Art

[0002] In the current online ride-hailing service, accurately calculating the driver's service time and optimizing the system's computing and scheduling efficiency is a key issue. Traditional service time calculation methods often rely on coarse-grained time period division, such as counting service time by hour or by shift. This method performs poorly when dealing with complex situations where orders span multiple time slices, because it may not accurately capture the actual service time of each order, especially when orders span different time slices or involve complex task scheduling, resulting in the calculation results of service time often deviating from the actual situation. This inaccurate calculation not only affects the evaluation of the driver's service quality, but may also have a negative impact on the driver's compensation calculation and the overall scheduling strategy of the system.

[0003] With the increasing computing demands of online ride-hailing platforms, especially the increasing complexity of autonomous driving tasks, traditional computing methods face more challenges. Autonomous driving systems not only involve real-time positioning of vehicles and task scheduling, but also need to process a large amount of sensor data and environmental information, which makes the calculation and scheduling of tasks more complicated. In this case, the traditional coarse-grained time segment method cannot meet the computing needs of high accuracy and high efficiency.

[0004] In view of this, the present invention is proposed. Summary of the invention

[0005] The technical problem to be solved by the present invention is to overcome the deficiencies of the prior art and provide a method for calculating offline driver duration at the minute level based on ODPS, thereby solving the problems raised in the above-mentioned background technology.

[0006] In order to solve the above technical problems, the basic concept of the technical solution adopted by the present invention is:

[0007] A method for calculating offline driver time at the minute level based on ODPS includes the following steps:

[0008] Step (1): Collect order status, event time, and business type data on the ODPS platform to form basic data with a 5-minute granularity. Then, based on the basic data, obtain the current and previous and next shard data in units of 5 minutes, and use the order status event time to filter out irrelevant data.

[0009] Step (2): Create a task to calculate the latest order status of the driver in the current shard, and use the UNION ALL function to associate the data of the current shard with the data of the previous shard to generate a complete order status detail;

[0010] Step (3): Use the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculate the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, use the shard end time for a fallback.

[0011] Step (4): Optimize the scheduling of autonomous driving tasks based on the duration calculation results, and offload computationally intensive tasks to edge nodes. Dynamically adjust task allocation through offline optimization and online algorithms;

[0012] Step (5): Dynamically manage online queues and offline waiting based on task scheduling, adopt a dual-line queueing mode, and allow customers to choose online queueing or offline waiting. Combine order status data and system load, and optimize queue and waiting time through offline waiting time prediction and Littles Law;

[0013] Step (6): Calculate and accumulate the pick-up time, waiting time and drop-off time every 5 minutes to obtain the driver's standard, serial or carpooling service time. By accumulating the time data of multiple slices, the cumulative service time of any time period is obtained.

[0014] Optionally, step (1) collects order status, event time, and business type data on the ODPS platform to form basic data with a 5-minute granularity. Then, based on the basic data, the data of the current and previous and next shards are obtained in units of 5 minutes. The steps of using the order status event time to filter irrelevant data are as follows:

[0015] Create a 5-minute granularity order data collection task on the ODPS platform. It will receive and store the order status data, event time data, order business type data, and order source data in real time according to the order generation time. Then, based on the collected order data, the data is logically sharded in units of 5 minutes. Each shard contains the order data within the current 5 minutes, and obtains the data of the previous 5-minute shard and the next 5-minute shard.

[0016] After obtaining the data of the current and previous and next shards, use the event time of the order status as the filtering condition, and then use the filtering mechanism to filter out the data that matches the time range of the current shard, and exclude the order status data that belongs to other time shards or is not related to the driver.

[0017] Optionally, step (2) uses the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculates the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, the specific steps of using the shard end time for bottom-up processing are as follows:

[0018] Create a computing task on the ODPS platform to calculate the order status in each time slice in units of 5 minutes, and then extract the driver-related order status data from the current 5-minute slice. This data includes the driver's order acceptance, arrival at the pick-up point, start of the trip, and end of the trip. Then, determine whether these states belong to the current 5-minute slice range based on the order event time.

[0019] Get the order status data in the previous 5-minute shard. For cross-shard orders, the order status data in the previous shard needs to be used as input. Then, use the UNION ALL function to associate the data of the current 5-minute shard with the data of the previous 5-minute shard into a continuous status sequence.

[0020] Optionally, step (3) uses the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculates the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, the specific steps of using the shard end time for bottom-up processing are as follows:

[0021] For the data in each driver group, use the LEAD window function to sort the order status in ascending order, calculate the time difference between adjacent order statuses, and then calculate the pick-up time based on the time difference between the order statuses: when the adjacent order statuses are "driver accepts the order" and "arrives at the pick-up point", the time difference is the pick-up time;

[0022] Waiting time: When the status of adjacent orders is "arrived at the pickup point" and "started the trip", the time difference is the waiting time;

[0023] Delivery time: When the status of adjacent orders are "start trip" and "end trip", the time difference is the delivery time.

[0024] If the order status time exceeds the end time of the current 5-minute slice, a fallback process will be performed, that is, the calculated order status time must not exceed the end time of the current slice. If the next status time of the order occurs in the next slice, the end time of the current slice will be used as the end time of the status. Then, the pick-up time, waiting time and drop-off time of each driver will be calculated separately, and the output is the order time data of each driver's current 5-minute slice.

[0025] Optionally, step (4) optimizes the scheduling of autonomous driving tasks based on the duration calculation results, and offloads computationally intensive tasks to edge nodes. The steps of dynamically adjusting task allocation through offline optimization and online algorithms are as follows:

[0026] Based on the previous order duration calculation steps, the calculation results of the driver's pick-up time, waiting time, and delivery time are obtained. According to the duration calculation results, the autonomous driving related tasks are divided into different categories and the priority is set for each category of tasks. For computing-intensive tasks, these tasks are offloaded from the on-board computing device to the edge node through task scheduling;

[0027] Before task offloading, an integer linear programming model is used to optimize the task offline to preliminarily determine the optimal allocation of tasks on each edge node. Then, the task allocation plan is adjusted according to the real-time network status, the computing load of the edge node, and the urgency of the task.

[0028] Optionally, step (5) dynamically manages online queuing and offline waiting according to the task scheduling situation, adopts a dual-line queuing mode, and allows customers to choose online queuing or offline waiting. Combining order status data and system load, the steps of optimizing queuing and waiting time through offline waiting time prediction and Littles Law are as follows:

[0029] According to the scheduling of autonomous driving tasks, the system load, task execution progress and computing resource usage are obtained in real time for task scheduling feedback. Then, a dual-line queuing mode is set based on the task scheduling feedback, allowing customers to choose between online queuing and offline waiting. Then, based on the order status data, system load and task scheduling feedback, the system predicts the return time of customers waiting offline.

[0030] Then, Littles Law is used to optimize the management of online queuing and offline waiting, and the queuing strategy is adjusted in combination with the offline waiting time prediction results. The expression is L=λW, where λ is the customer arrival rate and W is the average waiting time. Then, based on the queuing optimization results, combined with the current system load and task scheduling, the online queuing and offline waiting strategies are dynamically adjusted. When the load is high, the system will give priority to online queuing customers and extend the offline waiting time. When the load decreases, the offline waiting customers are notified to return to balance the service resources.

[0031] Optionally, when predicting the customer's return time, first, the system collects the customer's order status data, including the order's start time, expected end time, and current service progress. At the same time, the system collects the current system load status information, such as task scheduling, server computing resource usage, network delay, and task completion progress. Then, based on the collected system load data, the current system load is preliminarily judged, as well as the potential impact of the load on the customer's return time. Next, for customers who choose to wait offline, the system estimates the length of the offline queue and the expected processing time by analyzing the number of customers in the offline queue, the expected service time for each customer, and the current system load, and preliminarily predicts the return time of the offline customer based on this information. Subsequently, the system combines historical order data and past load changes, and uses the reflection diffusion model to make further accurate predictions on the return time of offline customers. The model infers the optimal time window for each customer to return to service by analyzing the order processing time and system load fluctuations in historical data. Finally, based on the comprehensive results of system load analysis, offline queue estimation, historical data model prediction, and Littles Law optimization, the system generates a dynamic expected return time window for each offline customer.

[0032] Optionally, step (6) calculates and accumulates the pick-up time, waiting time and drop-off time every 5 minutes to obtain the driver's standard, serial or carpooling service time. By accumulating the time data of multiple slices, the steps for obtaining the cumulative service time of any time period are as follows:

[0033] On the ODPS platform, the order status data is sliced ​​and processed in units of 5 minutes. Then, based on the order status in each 5-minute slice, the LEAD window function is used to group the drivers and arrange them in ascending order by order status time. The time difference between adjacent order statuses is calculated. Next, based on the calculated time difference, the driver's service type is identified. Then, by accumulating the duration data in each slice, the data of multiple 5-minute slices are accumulated to calculate the driver's cumulative service time in any time period. The duration accumulation process covers different types of service time. Finally, the accumulated duration data in each slice is summarized and the driver's service time result is output.

[0034] After adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art. Of course, any product implementing the present invention does not necessarily need to achieve all the advantages described below at the same time:

[0035] 1. By collecting order status data with a 5-minute granularity on the ODPS platform, the present invention can shard the order status accurately to the minute level, and use the LEAD window function to calculate the driver's pick-up, waiting and drop-off time. Compared with traditional coarse-grained calculations, this high-frequency sharding method greatly improves the accuracy of service time calculation. In particular, when processing cross-shard orders, a bottom-up processing mechanism is adopted to ensure the accuracy and consistency of time calculation. In addition, the present invention reduces the load on the on-board computing equipment by offloading computationally intensive tasks to edge nodes. Using a method that combines offline optimization models and online algorithms, the system can dynamically adjust task allocation and improve the flexibility and efficiency of task scheduling, thereby effectively solving the problems of low task processing efficiency and low resource utilization on traditional online car-hailing platforms.

[0036] 2. By combining order status data and system load, the system adopts a dual-line queuing mode based on task scheduling optimization, allowing customers to choose to queue online or offline. Based on the dynamic adjustment of system load and Littles Law for queuing time optimization prediction, the system can accurately estimate the customer's waiting time and avoid excessive queuing time, thereby improving the customer experience and avoiding customer churn.

[0037] The specific implementation modes of the present invention are further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The drawings described below are only some embodiments. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0039] In the figure:

[0040] Figure 1 It is a structural diagram.

[0041] It should be noted that these drawings and textual descriptions are not intended to limit the conceptual scope of the present invention in any way, but are intended to illustrate the concept of the present invention for those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0042] The present invention will now be described in further detail with reference to the accompanying drawings.

[0043] See also Figure 1 As shown, in this embodiment, a method for calculating the offline driver duration at the minute level based on ODPS is provided, including the following steps:

[0044] Step (1): Collect order status, event time, and business type data on the ODPS platform to form basic data with a 5-minute granularity. Then, based on the basic data, obtain the current and previous and next shard data in units of 5 minutes, and use the order status event time to filter out irrelevant data.

[0045] Step (2): Create a task to calculate the latest order status of the driver in the current shard, and use the UNION ALL function to associate the data of the current shard with the data of the previous shard to generate a complete order status detail;

[0046] Step (3): Use the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculate the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, use the shard end time for a fallback.

[0047] Step (4): Optimize the scheduling of autonomous driving tasks based on the duration calculation results, and offload computationally intensive tasks to edge nodes. Dynamically adjust task allocation through offline optimization and online algorithms;

[0048] Step (5): Dynamically manage online queues and offline waiting based on task scheduling, adopt a dual-line queueing mode, and allow customers to choose online queueing or offline waiting. Combine order status data and system load, and optimize queue and waiting time through offline waiting time prediction and Littles Law;

[0049] Step (6): Calculate and accumulate the pick-up time, waiting time and drop-off time every 5 minutes to obtain the driver's standard, serial or carpooling service time. By accumulating the time data of multiple slices, the cumulative service time of any time period is obtained.

[0050] By collecting 5-minute granularity order status data on the ODPS platform, the present invention can accurately slice the order status to the minute level, and use the LEAD window function to calculate the driver's pick-up, waiting and delivery time. Compared with traditional coarse-grained calculations, this high-frequency slicing method greatly improves the accuracy of service time calculation. In particular, when processing cross-slice orders, a bottom-up processing mechanism is used to ensure the accuracy and consistency of time calculation.

[0051] The present invention reduces the load on vehicle computing devices by offloading computationally intensive tasks to edge nodes. By combining offline optimization models with online algorithms, the system can dynamically adjust task allocation and improve the flexibility and efficiency of task scheduling, thereby effectively solving the problems of low task processing efficiency and low resource utilization in traditional online car-hailing platforms.

[0052] By combining order status data and system load, the system adopts a dual-line queuing mode based on task scheduling optimization, allowing customers to choose to queue online or offline. Based on the dynamic adjustment of system load and combined with LittlesLaw to optimize the queue time prediction, the system can accurately estimate the customer's waiting time and avoid excessively long queues, thereby improving the customer experience and avoiding customer churn.

[0053] In this embodiment, step (1) collects order status, event time, and business type data on the ODPS platform to form basic data with a 5-minute granularity. Then, based on the basic data, the data of the current and previous and next shards are obtained in units of 5 minutes. The steps of using the order status event time to filter irrelevant data are as follows:

[0054] Create a 5-minute granularity order data collection task on the ODPS platform. It will receive and store the order status data, event time data, order business type data, and order source data in real time according to the order generation time. Then, based on the collected order data, the data is logically sharded in units of 5 minutes. Each shard contains the order data within the current 5 minutes, and obtains the data of the previous 5-minute shard and the next 5-minute shard.

[0055] After obtaining the data of the current and previous and next shards, use the event time of the order status as the filtering condition, and then use the filtering mechanism to filter out the data that matches the time range of the current shard, and exclude the order status data that belongs to other time shards or is not related to the driver.

[0056] In this embodiment, step (2) uses the LEAD window function to calculate the time difference of adjacent order statuses by driver group, and calculates the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, the specific steps of using the shard end time for bottom-up processing are as follows:

[0057] Create a computing task on the ODPS platform to calculate the order status in each time slice in units of 5 minutes, and then extract the driver-related order status data from the current 5-minute slice. This data includes the driver's order acceptance, arrival at the pick-up point, start of the trip, and end of the trip. Then, determine whether these states belong to the current 5-minute slice range based on the order event time.

[0058] Get the order status data in the previous 5-minute shard. For cross-shard orders, the order status data in the previous shard needs to be used as input. Then, use the UNION ALL function to associate the data of the current 5-minute shard with the data of the previous 5-minute shard into a continuous status sequence.

[0059] In this embodiment, step (3) uses the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculates the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, the specific steps of using the shard end time for bottom-up processing are as follows:

[0060] For the data in each driver group, use the LEAD window function to sort the order status in ascending order, calculate the time difference between adjacent order statuses, and then calculate the pick-up time based on the time difference between the order statuses: when the adjacent order statuses are "driver accepts the order" and "arrives at the pick-up point", the time difference is the pick-up time;

[0061] Waiting time: When the status of adjacent orders is "arrived at the pickup point" and "started the trip", the time difference is the waiting time;

[0062] Delivery time: When the status of adjacent orders are "start trip" and "end trip", the time difference is the delivery time.

[0063] If the order status time exceeds the end time of the current 5-minute slice, a fallback process will be performed, that is, the calculated order status time must not exceed the end time of the current slice. If the next status time of the order occurs in the next slice, the end time of the current slice will be used as the end time of the status. Then, the pick-up time, waiting time and drop-off time of each driver will be calculated separately, and the output is the order time data of each driver's current 5-minute slice.

[0064] In this embodiment, step (4) optimizes and schedules the autonomous driving tasks according to the duration calculation results, unloads the computationally intensive tasks to the edge nodes, and dynamically adjusts the task allocation through offline optimization and online algorithms as follows:

[0065] Based on the previous order duration calculation steps, the calculation results of the driver's pick-up time, waiting time, and delivery time are obtained. According to the duration calculation results, the autonomous driving related tasks are divided into different categories and the priority is set for each category of tasks. For computing-intensive tasks, these tasks are offloaded from the on-board computing device to the edge node through task scheduling;

[0066] Before task offloading, an integer linear programming model is used to optimize the task offline to preliminarily determine the optimal allocation of tasks on each edge node. Then, the task allocation plan is adjusted according to the real-time network status, the computing load of the edge node, and the urgency of the task.

[0067] In this embodiment, step (5) dynamically manages online queuing and offline waiting according to the task scheduling situation, adopts a dual-line queuing mode, and allows customers to choose online queuing or offline waiting. Combining order status data and system load, the steps of optimizing queuing and waiting time through offline waiting time prediction and Littles Law are as follows:

[0068] According to the scheduling of autonomous driving tasks, the system load, task execution progress and computing resource usage are obtained in real time for task scheduling feedback. Then, a dual-line queuing mode is set based on the task scheduling feedback, allowing customers to choose online queuing and offline waiting. When system resources are sufficient, customers queuing online can get services immediately. When the system load is high, customers are advised to choose offline waiting. Customers will receive service notifications when the task scheduling situation eases. Then, based on order status data, system load and task scheduling feedback, the system predicts the return time of customers waiting offline.

[0069] Then, Littles Law is used to optimize the management of online queuing and offline waiting, and the queuing strategy is adjusted in combination with the offline waiting time prediction results. The expression is L = λW, where λ is the customer arrival rate and W is the average waiting time. Then, according to the queuing optimization results, combined with the current system load and task scheduling, the online queuing and offline waiting strategies are dynamically adjusted. When the load is high, the system will give priority to online queuing customers and extend the offline waiting time. When the load decreases, the offline waiting customers will be notified to return to balance the service resources. Adjustments are made based on real-time task scheduling feedback and system load conditions, and two options of online queuing and offline waiting are provided through a dual-line queuing mode to ensure the effective use of resources. This dynamic adjustment helps to optimize service quality and resource allocation. By analyzing order status data, system load, and task scheduling feedback, the return time of offline customers is predicted, so that customers can obtain accurate service expectations, optimize service plans and customer experience. According to the queuing optimization results and the current load conditions, the online queuing and offline waiting strategies are dynamically adjusted. When the load is high, online customers are given priority and the offline waiting time is extended; when the load decreases, offline customers are notified to return to the service. This method helps balance service resources and loads, improve customer satisfaction and system operation efficiency.

[0070] In this embodiment, when predicting the customer's return time, first, the system collects the customer's order status data, including the start time, expected end time and current service progress of the order. At the same time, the system collects the current system load status information, such as task scheduling, server computing resource usage, network delay and task completion progress. Then, based on the collected system load data, the current system load is preliminarily judged, as well as the potential impact of the load on the customer's return time. Next, for customers who choose to wait offline, the system estimates the length and expected processing time of the offline queue by analyzing the number of customers in the offline queue, the expected service time of each customer and the current system load, and preliminarily predicts the return time of the offline customer based on this information. Subsequently, the system combines historical order data and past load changes, and uses the reflection diffusion model to make further accurate predictions on the return time of offline customers. The model infers the optimal time window for each customer to return to service by analyzing the order processing time in the historical data and the system load fluctuation. Finally, based on the comprehensive results of system load analysis, offline queue estimation, historical data model prediction and Littles Law optimization, the system generates a dynamic expected return time window for each offline customer. This time window is a dynamic prediction interval, indicating when the customer can return to receive service. By preliminarily judging the level of system load and the potential impact of load on customer return time, we can better understand and foresee the bottleneck of system resources, thereby providing customers with more appropriate return time predictions. The system takes into account the number of offline customers, the expected service time, and the system load. By analyzing the length of the offline queue and the expected processing time, it provides a preliminary prediction of the return time of offline customers, which helps optimize service scheduling and customer experience.

[0071] By considering the number of offline customers, the expected service time and the system load, the system can make a more accurate preliminary prediction of the return time of offline customers. This accurate prediction helps to better manage and arrange resources, reduce waiting time and improve service efficiency.

[0072] In this embodiment, step (6) calculates and accumulates the pick-up time, waiting time and drop-off time every 5 minutes to obtain the standard, serial or carpooling service time of the driver. By accumulating the time data of multiple slices, the steps of obtaining the accumulated service time of any time period are as follows:

[0073] On the ODPS platform, the order status data is sliced ​​and processed in units of 5 minutes. Then, based on the order status in each 5-minute slice, the LEAD window function is used to group the drivers and arrange them in positive order according to the order status time. The time difference between adjacent order statuses is calculated. Then, based on the calculated time difference, the driver's service type is identified, including standard service, serial service and carpooling service. Then, by accumulating the duration data in each slice, the data of multiple 5-minute slices are accumulated to calculate the driver's cumulative service time in any time period, where the duration accumulation process covers different types of service time (such as standard service time, serial service time or carpooling service time). According to actual needs, the system can calculate the service time for 5 minutes, 30 minutes, 1 hour or longer time periods. Finally, the accumulated duration data in each slice is summarized, and the driver's service time results are output to provide basic data support for the driver's performance evaluation and refined operation.

[0074] The present invention is not limited to the above-mentioned embodiments. Anyone should be aware that any structural changes made under the enlightenment of the present invention, and any technical solutions that are the same or similar to the present invention, fall within the protection scope of the present invention. The technology, shape, and structural parts not described in detail in the present invention are all well-known technologies.

Claims

1. A method for calculating offline driver time at the minute level based on ODPS, characterized in that: The following steps are involved: Step (1): Collect order status, event time, and business type data on the ODPS platform to form basic data with a 5-minute granularity. Then, based on the basic data, obtain the current and previous and next shard data in units of 5 minutes, and use the order status event time to filter out irrelevant data. Step (2): Create a task to calculate the latest order status of the driver in the current shard, and use the UNION ALL function to associate the data of the current shard with the data of the previous shard to generate a complete order status detail; Step (3): Use the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculate the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, use the shard end time for a fallback. Step (4): Based on the duration calculation results, optimize the scheduling of autonomous driving tasks, offload computationally intensive tasks to edge nodes, and dynamically adjust task allocation through offline optimization and online algorithms; Step (5): Dynamically manage online queuing and offline waiting based on task scheduling, adopt a dual-line queuing mode, allow customers to choose online queuing or offline waiting, combine order status data and system load, and optimize queuing and waiting time through offline waiting time prediction and Littles Law; Step (6): Calculate and accumulate the pick-up time, waiting time and drop-off time every 5 minutes to obtain the driver's standard, serial or carpooling service time. By accumulating the time data of multiple slices, the cumulative service time of any time period is obtained.

2. According to the method for calculating the offline driver duration in minutes based on ODPS in claim 1, it is characterized in that: Step (1) collects order status, event time, and business type data on the ODPS platform to form basic data with a 5-minute granularity. Then, based on the basic data, obtain the current and previous and next shard data in units of 5 minutes. The steps of using the order status event time to filter irrelevant data are as follows: Create a 5-minute granularity order data collection task on the ODPS platform. It will receive and store the order status data, event time data, order business type data, and order source data in real time according to the order generation time. Then, based on the collected order data, the data is logically sharded in units of 5 minutes. Each shard contains the order data within the current 5 minutes, and obtains the data of the previous 5-minute shard and the next 5-minute shard. After obtaining the data of the current and previous and next shards, use the event time of the order status as the filtering condition, and then use the filtering mechanism to filter out the data that matches the time range of the current shard, and exclude the order status data that belongs to other time shards or is not related to the driver.

3. According to the method for calculating the offline driver duration in minutes based on ODPS in claim 1, it is characterized in that: Step (2) uses the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculates the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, the specific steps of using the shard end time for bottom-up processing are as follows: Create a computing task on the ODPS platform to calculate the order status in each time slice in units of 5 minutes, and then extract the driver-related order status data from the current 5-minute slice. This data includes the driver's order acceptance, arrival at the pick-up point, start of the trip, and end of the trip. Then, determine whether these states belong to the current 5-minute slice range based on the order event time. Get the order status data in the previous 5-minute shard. For cross-shard orders, the order status data in the previous shard needs to be used as input. Then, use the UNION ALL function to associate the data of the current 5-minute shard with the data of the previous 5-minute shard into a continuous status sequence.

4. According to the method for calculating the offline driver duration in minutes based on ODPS in claim 1, it is characterized in that: Step (3) uses the LEAD window function to calculate the time difference between adjacent order statuses by driver group, and calculates the pick-up time, waiting time, and delivery time respectively. If the order status time exceeds the current shard end time, the specific steps of using the shard end time for bottom-up processing are as follows: For the data in each driver group, use the LEAD window function to sort them in ascending order according to the time of the order status, calculate the time difference between adjacent order statuses, and then calculate the pick-up time, waiting time, and drop-off time based on the time difference between the order statuses. If the order status time exceeds the end time of the current 5-minute slice, a fallback process will be performed, that is, the calculated order status time must not exceed the end time of the current slice. If the next status time of the order occurs in the next slice, the end time of the current slice will be used as the end time of the status. Then, the pick-up time, waiting time and drop-off time of each driver will be calculated separately, and the output is the order time data of each driver's current 5-minute slice.

5. According to the method for calculating the offline driver duration in minutes based on ODPS according to claim 1, it is characterized in that: Step (4) optimizes the scheduling of autonomous driving tasks based on the duration calculation results, unloads computationally intensive tasks to edge nodes, and dynamically adjusts task allocation through offline optimization and online algorithms as follows: Based on the previous order duration calculation steps, the calculation results of the driver's pick-up time, waiting time, and delivery time are obtained. According to the duration calculation results, the autonomous driving related tasks are divided into different categories and the priority is set for each category of tasks. For computing-intensive tasks, these tasks are offloaded from the on-board computing device to the edge node through task scheduling; Before task offloading, an integer linear programming model is used to optimize the task offline to preliminarily determine the optimal allocation of tasks on each edge node. Then, the task allocation plan is adjusted according to the real-time network status, the computing load of the edge node, and the urgency of the task.

6. According to the method for calculating the offline driver duration in minutes based on ODPS according to claim 1, it is characterized in that: Step (5) dynamically manages online queuing and offline waiting according to the task scheduling situation, adopts a dual-line queuing mode, allows customers to choose online queuing or offline waiting, combines order status data and system load, and optimizes queuing and waiting time through offline waiting time prediction and Littles Law. The steps are as follows: According to the scheduling of autonomous driving tasks, the system load, task execution progress and computing resource usage are obtained in real time for task scheduling feedback. Then, a dual-line queuing mode is set based on the task scheduling feedback, allowing customers to choose between online queuing and offline waiting. Then, based on the order status data, system load and task scheduling feedback, the system predicts the return time of customers waiting offline. Then, Littles Law is used to optimize the management of online queuing and offline waiting, and the queuing strategy is adjusted in combination with the offline waiting time prediction results. The expression is L=λW, where λ is the customer arrival rate and W is the average waiting time. Then, based on the queuing optimization results, combined with the current system load and task scheduling, the online queuing and offline waiting strategies are dynamically adjusted. When the load is high, the system will give priority to online queuing customers and extend the offline waiting time. When the load decreases, the offline waiting customers are notified to return to balance the service resources.

7. According to claim 6, a method for calculating offline driver duration in minutes based on ODPS is characterized in that: When predicting the customer's return time, first, the system collects the customer's order status data, including the order's start time, expected end time, and current service progress. At the same time, it collects the current system load status information, such as task scheduling, server computing resource usage, network delay, and task completion progress. Then, based on the collected system load data, it preliminarily determines the current system load and the potential impact of the load on the customer's return time. Next, for customers who choose to wait offline, the system estimates the length of the offline queue and the expected processing time by analyzing the number of customers in the offline queue, the expected service time for each customer, and the current system load. Based on this information, it preliminarily predicts the return time of offline customers. Subsequently, the system combines historical order data and past load changes, and uses the reflection diffusion model to further accurately predict the return time of offline customers. The model analyzes the order processing time and system load fluctuations in historical data to infer the optimal time window for each customer to return to service. Finally, based on the comprehensive results of system load analysis, offline queue estimation, historical data model prediction, and Littles Law optimization, the system generates a dynamic expected return time window for each offline customer.

8. According to the method for calculating the offline driver duration in minutes based on ODPS in claim 1, it is characterized in that: Step (6) calculates and accumulates the pick-up time, waiting time and drop-off time every 5 minutes to obtain the standard, serial or carpooling service time of the driver. By accumulating the time data of multiple slices, the steps for obtaining the cumulative service time of any time period are as follows: On the ODPS platform, the order status data is sliced ​​and processed in units of 5 minutes. Then, based on the order status in each 5-minute slice, the LEAD window function is used to group the drivers and arrange them in ascending order by order status time. The time difference between adjacent order statuses is calculated. Next, based on the calculated time difference, the driver's service type is identified. Then, by accumulating the duration data in each slice, the data of multiple 5-minute slices are accumulated to calculate the driver's cumulative service time in any time period. The duration accumulation process covers different types of service time. Finally, the accumulated duration data in each slice is summarized and the driver's service time result is output.

Images