Method, device and medium for storing travel task data based on hot and cold databases

Abstract

The application provides a travel task data storage method and device based on a cold-hot database, and a medium, relates to the technical field of travel task data storage, and the method comprises the following steps: migrating a specified travel task of a user in a first preset future time period WT1 from a cold database to a hot database; obtaining a pending travel task; generating a comprehensive feature vector corresponding to each pending travel task; obtaining an initial probability of change of each pending travel task; determining a change weight of each pending travel task corresponding to each aircraft task; determining an overall change probability corresponding to each aircraft task; migrating each pending travel task corresponding to an aircraft task with an overall change probability greater than a preset overall change probability threshold to the hot database; and the application can balance the storage cost of the hot database and the low-cost advantage of the cold database, and ensure the rapid retrieval of high-priority data when a payment platform processes a refund query.

Description

Technical Field

[0001] This invention relates to the field of travel task data storage technology, and in particular to a travel task data storage method, device and medium based on cold and hot databases. Background Technology

[0002] In the civil aviation passenger transport sector, after users complete ticket purchases through online platforms, their travel data (including flight information, fares, refund and change rules, user identity information, etc.) needs to be stored long-term to support the entire service process. However, users frequently make refunds or changes due to personal itinerary adjustments, sudden weather changes, flight delays, etc. Payment platforms, when processing refund requests, need to query the corresponding ticket order details and refund / change rules in real time, placing extremely high demands on the timeliness and accuracy of data access. Currently, civil aviation travel data storage often employs a single database architecture or a simple time-layered strategy. Either all ticket data is stored uniformly in a high-performance hot database to ensure query response speed, but this results in wasted costs due to long-term travel tasks (such as flights several months in advance) occupying hot storage resources for extended periods, or data is stored only according to fixed time thresholds. Migrating long-term data to a cold database fails to handle sudden refund and rebooking requests from users for long-term flights. This leads to delays in data retrieval from the cold database, impacting refund efficiency. Furthermore, in actual business operations, some long-term travel tasks (such as flights during peak tourist seasons or periods of unstable weather) have a significantly higher probability of refunds and rebookings than ordinary tasks. Current technology lacks the ability to identify these high-risk tasks, and they are still stored in the cold database along with ordinary long-term tasks. This further exacerbates the response bottleneck when the payment platform queries refunds, ultimately affecting user experience and platform service quality. Therefore, how to design a dynamic and intelligent storage strategy based on the time characteristics and risk of change of civil aviation travel tasks, and ensure fast access to high-priority data (recent tasks and high-risk change tasks) while balancing storage costs, has become an urgent problem to be solved. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0004] According to a first aspect of this application, a method for storing travel task data based on hot and cold databases is provided, the method comprising the following steps:

[0005] S100, at each preset time point, the user's designated travel task within the first preset future time period WT1 is migrated from the cold database to the hot database; the start time point of the preset future time period is the preset time point, and the designated travel task is the travel task whose execution time point is within WT1 and stored in the cold database; the travel task includes the corresponding travel task value information.

[0006] S200: Obtain the pending travel tasks of users corresponding to each aircraft task in the cold database within the second preset future time period WT2, with the execution time point of WT2 being the end time point of WT1;

[0007] S300 generates a comprehensive feature vector for each pending travel task based on user behavior characteristics, user profile characteristics, weather characteristics at the execution time, and cost change characteristics.

[0008] S400, input the comprehensive feature vector corresponding to each pending travel task into the preset first travel task change probability prediction model to obtain the initial probability of change for each pending travel task.

[0009] S500 determines the change weight of each pending travel mission corresponding to each aircraft mission based on the change rules of each pending travel mission corresponding to each aircraft mission.

[0010] S600 determines the overall change probability of each aircraft mission based on the change weight and initial probability of each pending travel mission corresponding to each aircraft mission.

[0011] S700 migrates each pending travel mission corresponding to an aircraft mission whose overall change probability is greater than a preset overall change probability threshold to a hot database.

[0012] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described method for storing travel task data based on hot and cold databases.

[0013] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0014] The present invention has at least the following beneficial effects:

[0015] The travel task data storage method based on cold and hot databases of the present invention can ensure that the data of travel tasks to be executed in the near future can be quickly accessed by migrating the specified travel tasks within the first preset future time period WT1 from the cold database to the hot database. This meets the payment platform's need for efficient response to recent refund and change inquiries and avoids the waste of storage costs caused by all data occupying the hot database for a long time. At the same time, by generating a comprehensive feature vector by integrating user behavior characteristics, weather characteristics, etc., and combining the change probability prediction model and cost change rules to determine the overall change probability of aircraft tasks, and migrating the pending travel tasks corresponding to high change probabilities to the hot database, it realizes the accurate identification and early migration of long-term travel tasks with high change risks. This solves the problem of cold database access delay caused by the inability of existing technologies to predict such tasks. Finally, through the above-mentioned hierarchical storage and dynamic migration strategy, while balancing the storage cost of the hot database and the low cost advantage of the cold database, it ensures the rapid retrieval of high-priority data (recent tasks and high change risk tasks) when the payment platform processes refund inquiries, effectively eliminating the response bottleneck in the refund process and improving user experience and platform service quality. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a method for storing travel task data based on a cold and hot database, provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0020] Example 1:

[0021] The following will refer to Figure 1 The flowchart shown illustrates a method for storing travel task data based on a hot and cold database, which introduces such a method.

[0022] The method for storing travel task data based on hot and cold databases includes the following steps:

[0023] S100, at each preset time point, the user's designated travel task within the first preset future time period WT1 is migrated from the cold database to the hot database; the start time point of the preset future time period is the preset time point, and the designated travel task is the travel task whose execution time point is within WT1 and stored in the cold database; the travel task includes the corresponding travel task value information.

[0024] The method in this embodiment is applied to the scenario of ticket refund management in the civil aviation field. There are a payment platform and a ticket purchase platform. Users usually create a travel task on the ticket purchase platform, that is, to buy a ticket, and pay for the ticket on the payment platform. When a user cancels a ticket, the specific refund amount needs to be determined according to the refund and change rules when the user bought the ticket. The payment platform does not store the user's behavior information during the ticket purchase process.

[0025] In this embodiment, the aircraft mission is a flight, and the travel mission is the ticket purchased by the user. The preset time point can be set to midnight every day (e.g., 0:00). The first preset future time period WT1 is set through a dynamic determination mechanism (e.g., based on historical data statistics of the "7-day window in which 90% of refunds and changes occur"). Every midnight, the system scans the cold database and filters out all travel missions with an execution time point within the next 7 days (WT1) (e.g., tickets purchased by the user that depart in 3 or 5 days). These missions are then migrated from the cold database (stored on a low-cost HDD) to the hot database (stored on a high-performance SSD). The value information of the travel mission, including the ticket price and refund / change fee rules, is migrated along with the mission.

[0026] By selectively migrating travel tasks that need to be executed in the near future, the payment platform can quickly retrieve data from the hot database (response time <10ms) when users initiate refunds or changes, avoiding the impact of cold database access delays on refund efficiency; at the same time, only tasks within WT1 are migrated, rather than all data, which significantly reduces the storage pressure on the hot database and balances access efficiency and storage costs.

[0027] Furthermore, WT1 and WT2 are determined through the following steps:

[0028] S110, obtain the average time interval QT between the change initiation time and the execution time of each historical travel task that has undergone changes within a preset historical time period.

[0029] The preset historical time period can be set to the most recent 6 months (taking into account both data timeliness and sample size). The system extracts all travel tasks that have "refund or change" within this time period from the historical database (such as flight orders modified by the user), calculates the time interval (unit: days) between the "change initiation time" (the time when the user submits the refund or change application) and the "execution time" (the actual flight departure time) for each task, and then calculates the arithmetic mean of all intervals to obtain QT.

[0030] S120, based on the preset time point and the preset first adjustment coefficient mapping table, determine the first adjustment coefficient α1 corresponding to the preset time point; the first adjustment coefficient mapping table includes several rows, each row including a time range and the corresponding first adjustment coefficient.

[0031] The preset time point refers to the trigger time for the system to perform migration (such as 0:00 AM every day). The "First Adjustment Coefficient Mapping Table" sets α1 according to the "time scenario" (such as holidays, workdays, special event periods) in which the preset time point is located. For example: workday (non-peak season), α1=1.0; holidays (such as Spring Festival), α1=1.2; during large-scale exhibitions, α1=1.5.

[0032] By dynamically adjusting α1 through the mapping table, WT1 can adapt to the differences in change behavior under different scenarios (such as users being more likely to change their travel plans in advance during holidays), avoiding the inability of QT's fixed values ​​to cope with sudden or periodic changes in change patterns, and improving WT1's adaptability to real-time business scenarios.

[0033] S130, based on QT and α1, determine WT1 = QT × α1.

[0034] WT1 combines historical average patterns with real-time scenario adjustments, ensuring the basic rationality of the time period (aligning with users' historical behavior) while also expanding or narrowing the scope through α1 (such as extending WT1 during holidays), ensuring that WT1 can accurately cover "the recent window in which users are most likely to initiate changes in the current scenario," providing precise time boundaries for subsequent migrations.

[0035] S140, based on WT1, determine WT2 = α2 × WT1; α2 is the preset second adjustment coefficient; α2 < 1.

[0036] The second adjustment coefficient α2 is a preset fixed value (e.g., 0.8, satisfying α2 < 1). Based on WT1 obtained in step S130, the length of the second preset future time period is calculated using the formula WT2 = α2 × WT1.

[0037] Setting α2 < 1 ensures that the length of WT2 is shorter than that of WT1. This ensures that WT2 can connect with WT1 to cover long-term tasks, while avoiding the inclusion of too many low-risk long-term tasks due to its excessive length. At the same time, by calculating in conjunction with WT1 (rather than setting it independently), the ratio of WT2 to WT1 is adapted to the business scenario (e.g., when WT1 is extended, WT2 is extended synchronously but is always shorter), balancing the coverage of long-term risks and the consumption of storage resources.

[0038] S200: Obtain the pending travel tasks of users corresponding to each aircraft task in the cold database within the second preset future time period WT2, with the execution time point of WT2 being the end time point of WT1.

[0039] For example, a certain flight FW is scheduled to take off in the next 20 days. The cold database stores 100 tickets for this flight, all of which are pending travel assignments to be screened.

[0040] Focusing on long-term tasks within WT2 lays the foundation for subsequent risk assessment of their changes, avoids ineffective processing of tasks that are too far in the future (such as six months later) or have a very low probability of change, and improves the efficiency of system resource utilization; at the same time, by associating aircraft tasks (flights) with travel tasks (tickets), batch assessment can be achieved "by flight", simplifying the subsequent processing procedures.

[0041] S300 generates a comprehensive feature vector for each pending travel task based on user behavior characteristics, user profile characteristics, weather characteristics at the execution time, and cost change characteristics.

[0042] Furthermore, step S300 includes the following steps:

[0043] S310, for any pending travel task RW, obtain several user behavior features and several user profile features corresponding to RW; user behavior features include the percentage of historical travel task changes, the time interval between the travel task change time and the travel task execution time, whether there are repeated changes to the same travel task, and whether there are changes abandoned due to cost; user profile features include several user attributes, destination, and seat type corresponding to historical travel tasks.

[0044] Two types of features can be extracted from user historical data and order information:

[0045] User behavior characteristics:

[0046] Percentage of changes in historical travel tasks: The percentage of all travel tasks a user has changed in the past year (e.g., 3 changes out of 10 trips, accounting for 30%).

[0047] Change time interval: The average interval between the application time and the flight execution time when the user makes a change in the past (e.g., an average of 5 days in advance).

[0048] Whether the same task has been changed repeatedly: Whether the user has made multiple changes to the same flight (e.g., if the flight date has been changed twice, it is marked as "yes").

[0049] Whether the change was abandoned due to the cost: Does the user have a record of "initiating a change process but canceling it due to high handling fees" (e.g., abandoning the change due to a 30% handling fee is recorded as "yes").

[0050] User profile characteristics:

[0051] User attributes: Age (35 years old), Occupation (corporate executive), Membership level (Platinum member).

[0052] Destination: Shanghai, the destination of this trip.

[0053] Historical seat type: User's ticket purchase preference over the past six months (70% chose first class).

[0054] By collecting user behavior and profile features, we can accurately capture users' change habits (such as whether they change frequently and their sensitivity to costs) and identity attributes (such as business users being more likely to change), providing the core basis of "user dimension" for subsequent prediction of their change probability to RW, and avoiding prediction bias caused by ignoring individual user differences.

[0055] S320, perform feature encoding on several user behavior features and several user profile features corresponding to RW to obtain the first feature vector XL1 corresponding to RW.

[0056] In this embodiment, continuous features (historical change percentage, change time interval) can be mapped to the [0,1] interval using min-max normalization; discrete features (whether the change is repeated, whether the change is abandoned due to cost) can be encoded using labels ("yes"=1, "no"=0); categorical features (occupation, seat type) can be encoded using one-hot encoding (e.g., "corporate executives" corresponds to [1,0,0], "first class" corresponds to [1,0]).

[0057] Through standardization and encoding, heterogeneous features (continuous values, categorical values, and Boolean values) are converted into unified numerical vectors, eliminating dimensional differences (such as "age 35 years old" and "change rate 30%" can be directly used in calculations), providing a standardized format for subsequent feature fusion and model input, and improving the consistency and efficiency of feature processing.

[0058] S330, obtain several weather characteristics and cost value change characteristics at the execution time of RW; weather characteristics include weather type, the probability of aircraft mission delays in the same weather type during the same period in history, and the degree of weather difference between the destination and the departure point; cost value change characteristics include the difference between the current cost value and the initial cost value, the cost value loss curve corresponding to the change of RW, and the cost value and remaining number of other travel missions on the same route as RW.

[0059] For the execution time of RW (e.g., 8:00 AM 15 days later), two types of external features are collected:

[0060] Weather characteristics:

[0061] Weather type: Obtain the forecast weather for the execution day through the meteorological interface (e.g., "heavy rain").

[0062] Historical delay rate: The probability of flight delays during the same period (e.g., the same month) of the past 3 years when "heavy rain" occurred (15%).

[0063] Weather difference: The quantitative value of the weather difference between the departure point (Beijing) and the destination (Shanghai) on the execution date (e.g., heavy rain vs. light rain, difference 0.7, range 0-1).

[0064] Characteristics of changes in value:

[0065] Current and initial cost difference: The difference between the current ticket price (800 yuan) and the ticket price when the user purchased the ticket (1000 yuan) (-200 yuan, i.e., a price reduction).

[0066] Change loss curve: the percentage of cancellation and change fees at different times from the execution date (e.g., 5% 15 days ago, 10% 7 days ago, and 20% 3 days ago).

[0067] Information on other flights on the same route: current ticket price (750 yuan) and remaining tickets (10 tickets) for other flights on the same route.

[0068] By introducing weather features (external environmental factors) and cost-value features (economic driving factors), the changes that were not covered by the "user dimension" are supplemented (such as severe weather may force users to change their subscriptions, and a drop in ticket prices may encourage users to cancel and repurchase). This makes the feature system more comprehensive and avoids the one-sidedness of prediction caused by relying solely on user features.

[0069] S340, perform feature encoding on several weather features and cost change features at the execution time of RW to obtain the second feature vector XL2 corresponding to RW.

[0070] Weather characteristics: Weather type is coded using unique thermal codes ("rainstorm" corresponds to [1,0,0,0], covering sunny, rainy, snowy, and foggy); the historical delay rate (15%) is normalized to 0.15; the weather difference (0.7) is directly retained.

[0071] Cost characteristics: The difference between the current and initial values ​​(-200 yuan) is normalized to 0.3 within the range of -500 to 500 yuan; the handling fees (5%, 10%, 20%) for extracting key time points of the change loss curve are normalized to [0.05, 0.1, 0.2]; the other fares on the same route (750 yuan) and the remaining number of tickets (10 tickets) are normalized to 0.75 and 0.2 respectively (assuming a maximum of 50 remaining tickets). After concatenation, XL2 is obtained, for example: XL2=[1,0,0,0 (rainstorm),0.15 (delay rate),0.7 (difference),0.3 (price difference),0.05,0.1,0.2 (loss curve),0.75 (fare on the same route),0.2 (remaining tickets)] (12-dimensional vector).

[0072] By encoding the heterogeneous features of weather and cost values ​​into a unified vector, the model can effectively identify external environmental and economic factors (e.g., the model can capture the impact of "rainstorm" on changes through the unique thermal encoding value). At the same time, the standardization process allows features of different magnitudes (e.g., a delay rate of 15% and 10 remaining tickets) to participate fairly in the model calculation, thereby improving the effectiveness of features.

[0073] S350, fuse XL1 and XL2 to obtain the comprehensive feature vector XL corresponding to RW. z = (XL1, XL2).

[0074] By simply splicing together features to achieve the fusion of multi-dimensional characteristics, the model retains all key information affecting changes, such as users, environment, and economy, providing "all-round input" for subsequent change probability prediction models (the model can simultaneously learn the interaction between user habits and external factors, such as the superimposed impact of the combination of "business users + rainstorm" on changes). Compared with single-dimensional features, this significantly improves the model's ability to capture complex change patterns and lays the foundation for accurate prediction.

[0075] S400, input the comprehensive feature vector corresponding to each pending travel task into the preset first travel task change probability prediction model to obtain the initial probability of change for each pending travel task.

[0076] The preset prediction model for the probability of change of the first travel task is preferably a gradient boosting tree model (such as XG Boost), which has been trained using historical data (including "whether it has changed" labels). The comprehensive feature vector generated in step S300 is input into the model, and the initial probability of change for each pending travel task is output. For example, for a business traveler who purchased a ticket with a rainstorm warning on the departure date and a current price reduction, the model predicts a 65% probability of change.

[0077] By leveraging the model's strong nonlinear fitting capabilities, the likelihood of changes to a single travel task can be accurately quantified, providing greater objectivity compared to manual rule-based judgments. The probability values ​​output by the model provide a quantifiable basis for subsequent decision-making regarding "whether to migrate to a hot database," avoiding misjudgments caused by subjective experience.

[0078] S500 determines the change weight of each pending travel task corresponding to each aircraft mission based on the change rules of each pending travel task corresponding to each aircraft mission.

[0079] Furthermore, step S500 includes the following steps:

[0080] S510, for any aircraft mission FW whose execution time point is within WT2, determine the loss value corresponding to the change of each pending travel mission according to the change rules when each pending travel mission is established, so as to obtain the loss value list SW=(SW1, SW2, ..., SW3, ..., SWi, ..., SWn) corresponding to FW, i=1, 2, ..., n; SWi is the loss value corresponding to the change of the i-th pending travel mission corresponding to FW, and n is the number of pending travel missions corresponding to FW.

[0081] In this embodiment, the "change rules for each pending travel task corresponding to FW" are the standards for calculating refund and change losses agreed upon between the user and the platform when purchasing tickets. The rule amount varies depending on the time and channel of ticket purchase. Common types include: a percentage-based handling fee (e.g., 10% for refunds / changes 7 days before departure, 20% within 7 days), a fixed-amount handling fee (e.g., a fixed fee of 50 yuan for domestic flight refunds / changes), and tiered losses (the closer to the execution time, the higher the loss percentage). The system extracts this rule from the historical agreement data of each pending travel task (e.g., user ticket orders) corresponding to FW, and calculates the corresponding loss value SW for changes based on the task's cost information (e.g., ticket price). i .

[0082] The loss value is calculated based on the original change rules at the time of ticket purchase to ensure SW iThe accuracy and objectivity of the rules are as follows: the rules are an agreement between the users and the platform and will not change due to subsequent changes in the scenario, thus avoiding deviations caused by subjective estimation of losses. At the same time, the generated SW list provides a quantitative basis for subsequent change weight calculations, so that the weight allocation can be directly related to the "actual economic cost of user changes", which is in line with the core principle in the business that "users are sensitive to the cost of loss".

[0083] S520, based on SW, determine the change weight of each pending travel task corresponding to FW, so as to obtain the change weight list A = (A1, A2, ..., A3, ..., A...) for FW. i A n A i Let A be the change weight for the i-th pending travel task corresponding to FW; i =(1 / SW i ) / ∑ n i=1 (1 / SW) i ).

[0084] In this embodiment, the loss cost SW i The larger, 1 / SW i The smaller, A i The smaller the weight, the higher the economic loss when a user makes a change, and the lower the weight of this task in the overall change probability calculation (because users are more likely to abandon the change due to high losses).

[0085] The formula achieves SW through "reciprocal normalization". i With A i The reverse correlation enables the weight allocation to accurately match the user's willingness to change (higher weight for smaller losses, requiring more attention; lower weight for larger losses, reducing impact), avoiding misjudgment of the overall change probability caused by "treating high-loss and low-loss tasks equally"; at the same time, the total weight is 1, ensuring that the initial probabilities of each task can be reasonably aggregated when calculating the overall change probability (such as the weighted average of S600), improving the accuracy of the overall probability and providing a reliable basis for subsequent migration decisions.

[0086] S600 determines the overall change probability for each aircraft mission based on the change weight and initial probability of each pending travel mission corresponding to each aircraft mission.

[0087] Furthermore, step S600 includes the following steps:

[0088] S610, obtain the initial probability of each pending travel task change corresponding to FW, so as to obtain the initial probability list B = (B1, B2, ..., B3, ..., B i B n ); B iLet FW be the initial probability of changing the i-th pending travel task.

[0089] The initial probability B for each pending travel task corresponding to FW i The prediction results are directly derived from step S400; the model prediction results from step S400 are directly reused as B. i This eliminates the need for repeated feature extraction and model calculations, significantly reducing system computing power consumption and improving overall process efficiency; meanwhile, B i Based on multi-dimensional comprehensive feature prediction, it can objectively reflect the possibility of changes in a single task, providing accurate "basic data" for subsequent overall probability calculations and avoiding the need to re-estimate B. i The resulting error.

[0090] S620, Based on B and A, determine the overall change probability η corresponding to FW = ∑ n i=1 (A) i ×B i ).

[0091] Calculating the overall probability using a "weighted average" rather than a "simple arithmetic average" can highlight "tasks with high willingness to change" (such as low loss, high B). i The task, corresponding to A1=0.54, B1=0.6), is affected to avoid the impact of "high loss, low B". i The task-level probabilities (e.g., A3=0.12, B3=0.1) are lowered to make η more closely match the actual change behavior patterns of users in real business. At the same time, the scattered "task-level probabilities" are aggregated into "flight-level probabilities" to provide a unified and quantifiable decision standard for step S700 "whether to migrate the entire FW's tasks to the hot database", simplifying batch migration operations and avoiding the tedious process of judging each individual task one by one.

[0092] S700 migrates each pending travel mission corresponding to an aircraft mission whose overall change probability is greater than a preset overall change probability threshold to a hot database.

[0093] In this embodiment, the preset overall change probability threshold can be determined in the following way:

[0094] Historical data filtering: Extract FW data from the past 6 months that were executed within WT2 and have been completed, and filter out two key types of samples:

[0095] Sample 1: FWs whose overall change probability was predicted (regardless of whether they migrated).

[0096] Sample 2: The actual change rate corresponding to these FWs (i.e., the number of travel tasks that actually changed after execution ÷ the total number of tasks).

[0097] Threshold candidate interval analysis: Divide the predicted overall change probability of sample 1 into intervals of 10% (e.g., 0-10%, 11-20%...91-100%), calculate the average actual change rate of FW in each interval, find the critical interval of "sudden increase in average actual change rate", and obtain the preset overall change probability threshold.

[0098] This step allows for the early migration of high-risk long-term tasks to the hot database, avoiding delays caused by the need to retrieve data from the cold database when users experience sudden cancellations or changes. Only flight tasks with an overall probability exceeding the threshold are migrated, rather than all long-term tasks. This ensures access efficiency while controlling the storage costs of the hot database, achieving "precise migration at the best cost."

[0099] In this embodiment, by migrating designated travel tasks within the first preset future time period WT1 from the cold database to the hot database, it is possible to ensure that travel task data to be executed in the near future can be accessed quickly, meeting the payment platform's need for efficient response to recent refund and change inquiries, and avoiding the waste of storage costs caused by all data occupying the hot database for a long time. At the same time, by generating a comprehensive feature vector by integrating user behavior characteristics, weather characteristics, etc., and combining the change probability prediction model and cost change rules to determine the overall change probability of aircraft tasks, and migrating the pending travel tasks corresponding to high change probabilities to the hot database, it is possible to accurately identify and migrate high-change-risk long-term travel tasks in advance, solving the problem of cold database access delay caused by the inability of existing technology to predict such tasks. Finally, through the above-mentioned hierarchical storage and dynamic migration strategy, while balancing the storage cost of the hot database and the low-cost advantage of the cold database, it ensures the rapid retrieval of high-priority data (recent tasks, high-change-risk tasks) when the payment platform processes refund inquiries, effectively eliminating the response bottleneck in the refund process, and improving user experience and platform service quality.

[0100] Example 2:

[0101] Based on the method of Embodiment 1 above, there is still a situation where the remaining storage space of the hot database is insufficient. In this case, the following method is provided:

[0102] Q100: If the remaining storage space of the hot database is less than the preset remaining storage space threshold, then obtain several task features of each flight mission corresponding to each aircraft mission in the hot database.

[0103] In this embodiment, a preset threshold for remaining storage space is set (usually 20% of the total capacity of the hot database, which can be adjusted according to business needs). The system monitors the remaining space of the hot database in real time. If the remaining space is less than the threshold (e.g., if the total capacity of the hot database is 100GB, and the remaining space is 15GB < 20GB), the feature acquisition process is triggered.

[0104] This step is performed by the payment platform, which extracts only the core mission features of each aircraft mission (e.g., a flight) corresponding to each travel mission (e.g., a flight ticket) from the hot database. These features must meet the principles of "easy to obtain and low computational cost," specifically including: travel mission execution time, user's frequency of refunds and changes in the past 3 months, travel mission value, and whether it includes special services (e.g., baggage allowance). There is no need to extract complex external features (e.g., weather, available tickets on the same route), thus avoiding increasing the computational burden on the payment platform.

[0105] By using a spatial threshold triggering mechanism, the payment platform is prevented from performing ineffective calculations when there is sufficient hot storage space. The process is only initiated when migration is required, reducing daily computing power consumption. At the same time, only core and easily accessible features are extracted, rather than all features, further controlling the amount of computing power of the payment platform and focusing it on trigger judgment and basic data extraction, which is in line with the lightweight computing positioning.

[0106] Q200 determines the initial travel task difference degree corresponding to each aircraft mission based on several mission characteristics of each travel mission corresponding to each aircraft mission.

[0107] Furthermore, step Q200 includes the following steps:

[0108] Q210, for any aircraft mission GA in the hot database, generate a travel mission feature vector for each travel mission corresponding to GA based on several mission features of each travel mission corresponding to GA, so as to obtain a list of travel mission feature vectors C = (C1, C2, ..., C...). p C q ), p=1,2,…,q; C p Let q be the p-th travel task feature vector corresponding to GA, and q be the number of travel task feature vectors corresponding to GA; the task features include travel task creation time, cost value at the time of travel task creation, loss cost value of travel task change, whether the travel task has been changed, and whether it includes special services.

[0109] For any aircraft mission GA (such as a flight) in the hot database, each corresponding travel mission (such as the flight ticket) needs to generate a feature vector C based on 5 types of mission features. p :

[0110] Continuous features: the time of the trip task establishment (e.g., "2025-09-01" is converted to the number of days from the current time, and then normalized to [0,1] by min-max), the cost of establishment (e.g., 1000 yuan, normalized to [0,1]), and the cost of change loss (e.g., 200 yuan, normalized to [0,1]).

[0111] Discrete features: whether changes have occurred ("Yes"=1, "No"=0), whether special services are included (e.g., baggage allowance is 1 if included, 0 if not included).

[0112] The processed five features are concatenated in a fixed order to form the feature vector C for a single travel task. p For example, after feature processing, a certain ticket might have the following characteristics: [0.3 (creation time), 0.6 (cost value), 0.2 (loss cost value), 1 (changed), 0 (no special services)], i.e., C. p =(0.3,0.6,0.2,1,0). The feature vectors of all q travel tasks under GA are arranged in order, forming a list C = (C1,C2,…,C…). q (e.g., if q=50, C contains 50 5-dimensional vectors).

[0113] By standardizing the data, heterogeneous features (time, amount, Boolean value) are converted into a unified numerical vector, eliminating the difference in units and providing a comparable basis for subsequent similarity calculations. At the same time, the vectors are generated based only on the five core features extracted by Q100, without the need to introduce complex external features. The calculation logic is simple, which is in line with the "lightweight computing" positioning of the payment platform and avoids adding extra computing power burden.

[0114] Q220, obtain the similarity D(C) between the x-th and y-th travel task feature vectors in C. x C y ); x=1, 2,..., q-1, y=2, 3,..., q; 1≤x<y≤q.

[0115] For all eigenvector pairs of x < y in list C (C x C y The similarity D(C) is calculated using cosine similarity. x C y (Values ​​range [0,1], where 1 indicates complete similarity and 0 indicates complete dissimilarity).

[0116] Cosine similarity is calculated using only the dot product and modulus, which is logically simple and fast, making it suitable for payment platforms to quickly process batches of vector pairs. At the same time, it is not sensitive to vector length and can effectively measure the "directional consistency" of feature vectors (such as two tasks having the same change status or service type, even if the cost value is different, they can still be judged as highly similar), which fits the core need of "judging whether task features are similar".

[0117] Q230, according to D(C) x C y ), determine the difference value Diff (C) between the x-th and y-th travel task feature vectors in C. x C y ) = 1 - D(C xC y ).

[0118] The conversion from "similarity to difference" is achieved through simple subtraction, with almost zero computational cost, which meets the lightweight computing requirements of payment platforms. At the same time, the difference value is positively correlated with the degree of feature dispersion (the larger the value, the higher the dispersion), providing an intuitive and accumulative quantitative indicator for subsequent aggregation of the overall difference.

[0119] Q240, according to Diff(C) x C y Determine the initial travel task difference τ corresponding to GA. GA =(2 / q(q-1))×∑ q-1 x=1， ∑ q y=x+1 D(C) x C y ).

[0120] In this embodiment, τ GA In the formula, the denominator "q(q-1) / 2" represents the total number of vector pairs where x < y. The formula is equivalent to "the sum of all discrepancies divided by the total number of logarithms". By averaging the discrepancies of all vector pairs, the overall characteristic dispersion (τ) of all travel tasks under GA is quantified. GA The larger the value, the more dispersed the feature distribution, providing a quantitative basis for subsequent screening of flights with "dispersed features and more likely to contain low-value tasks"; at the same time, the calculation only involves summation and division, the logic is simple, and the payment platform can quickly complete the difference calculation of batch flights, taking into account both accuracy and efficiency.

[0121] Q300, based on the time interval between the execution time point corresponding to each aircraft mission and the current time point, corrects the initial travel mission difference of each aircraft mission to obtain the target travel mission difference of each aircraft mission.

[0122] Furthermore, step Q300 includes the following steps:

[0123] Q310, obtain the time interval between the execution time point corresponding to each aircraft mission in the hot database and the current time point, so as to obtain the time interval list ΔT = (ΔT1, ΔT2, ..., ΔT...). j , …, ΔT m ), j=1,2,…,m; ΔT j Let m be the time interval between the execution time of the j-th aircraft mission in the hot database and the current time, and m be the number of aircraft missions in the hot database.

[0124] For each aircraft mission (e.g., flight) in the hot database, the system extracts its "execution time point" (e.g., 2025-10-15 08:00) and "current time point" (e.g., 2025-10-01 00:00), and calculates the time interval ΔT between the two. j .

[0125] By directly calculating the interval between the execution time and the current time, the method is simple and efficient (only the task time field needs to be read and subtracted), without the need to call external data or perform complex calculations, which is in line with the "lightweight processing" positioning of the payment platform; at the same time, the time interval directly reflects the "proximity" of the task, providing a core basis for "amplifying the difference between long-term tasks" in the future, and ensuring that the correction logic is in line with the business goal of "prioritizing the migration of long-term tasks".

[0126] Q320, normalize the time intervals in ΔT to obtain a normalized time interval list ΔGT = (ΔGT1, ΔGT2, ..., ΔGT...). j , …, ΔGT m ); ΔGT j For ΔT j The corresponding normalized time interval; ΔGT j =ΔT j / MAX(ΔT); MAX() is the function to find the maximum value.

[0127] Normalization eliminates the absolute numerical differences in time intervals (such as the difference in magnitude between 4 days and 19 days), mapping all intervals to a uniform [0,1] interval, so that subsequent correction coefficient calculations are not affected by specific time units (whether it is a day or an hour, it can be handled uniformly); at the same time, the normalized ΔGT j It can intuitively reflect "relative distance" (e.g., ΔGT) j =1 indicates the farthest point, ΔGT j =0.21 indicates a relatively close value, providing a comparable basis for the linear amplification of the correction factor.

[0128] Q330, according to ΔGT j Determine the correction factor K corresponding to the j-th spacecraft mission. j =1+δ×ΔGT j .

[0129] The correction factor uses linear amplification logic (1+δ×ΔGT). j The calculations consist only of multiplication and addition, allowing the payment platform to process them quickly in batches, meeting the requirements of lightweight computing; simultaneously, the amplification intensity is controlled by δ (the larger δ is, the greater the K value of long-term and short-term tasks). j The more significant the difference, the more accurately the core objective of "the larger the time interval, the larger the correction coefficient" is achieved, providing a controllable adjustment mechanism for subsequent amplification of differences.

[0130] Q340, according to K j The initial difference τ for the j-th spacecraft mission j After correction, the target travel task difference ε corresponding to the j-th spacecraft mission is obtained. j =τ j ×K j .

[0131] By using a simple calculation of "initial difference × correction coefficient", the difference of long-term tasks can be amplified in a targeted manner, ensuring that "when the feature dispersion is similar, long-term tasks are more likely to be selected for migration", which meets the business need to "release the hot storage space occupied by low-value long-term tasks". At the same time, the calculation logic is simple, and the payment platform does not need to deal with complex scenario variables. The correction can be completed with just one multiplication, balancing efficiency and accuracy.

[0132] Q400 defines aircraft missions whose target travel mission difference is greater than or equal to a preset travel mission difference threshold as target aircraft missions.

[0133] In this embodiment, when flight missions with large differences in target travel missions undergo travel mission changes, there will not be a large number of travel mission changes, but only individual travel mission changes. Therefore, flight missions with a target travel mission difference greater than or equal to a preset travel mission difference threshold are identified as target flight missions.

[0134] A preset threshold for the difference in travel missions is established (based on historical migration results, such as 0.5, meaning flights with a difference ≥ 0.5 are considered "candidates for migration"). The payment platform compares the "target difference" obtained in step Q300 with this threshold: if a flight's target difference is ≥ 0.5 (e.g., 0.70 ≥ 0.5), it is identified as a "target aircraft mission"; if the target difference is < 0.5 (e.g., 0.35 < 0.5), it is retained in the hot database. For example, out of 10 flights in the hot database, 4 flights have a target difference ≥ 0.5 after screening, becoming target aircraft missions.

[0135] Beneficial effects: The payment platform only needs to execute the simple logic of "threshold comparison" to complete the candidate task screening without performing complex sorting or probability prediction, with minimal computational load; at the same time, threshold screening can quickly narrow down the subsequent migration scope, avoid sending all flights to the travel task establishment server, reduce data transmission volume, and lay the foundation for accurate sorting of the server in the future with a "small range of candidates".

[0136] Q500 sends each travel task corresponding to the target aircraft mission to a preset travel task creation server; the travel task creation server is used to sort each received target aircraft mission in descending order of travel task change probability according to the target travel task difference degree and several different dimensions of features corresponding to each travel task, to obtain the aircraft mission list YA.

[0137] In this embodiment, the payment platform only needs to send all travel mission data (including the core features extracted in Q100 + the target difference in Q300) corresponding to the "target aircraft mission" selected in step Q400 to the travel mission creation server, without participating in subsequent calculations. The travel mission creation server then performs precise sorting based on "multi-dimensional features".

[0138] Furthermore, YA is obtained through the following steps:

[0139] Q510, obtain each trip mission corresponding to each target aircraft mission to obtain the target aircraft mission list MF = (MF1, MF2, ..., MF3). a , ..., MF b ), a=1,2,…,b;MF a Let a be the target spacecraft mission and b be the number of target spacecraft missions.

[0140] In this embodiment, the travel task creation server receives the identification information (such as flight number and task ID) of these tasks from the payment platform and organizes them into a list MF in the order of receipt.

[0141] Q520, according to MF a For each travel task, user behavior characteristics, user profile characteristics, and weather characteristics at the execution time are used to generate MF (User Data). a The fused feature vector for each corresponding travel task.

[0142] Furthermore, the user behavior characteristics include the percentage of historical travel task changes, the time interval between the travel task change time and the travel task execution time, whether there are repeated changes to the same travel task, and whether changes are abandoned due to cost. The user profile characteristics include several user attributes, destination, and seat type corresponding to historical travel tasks. The weather characteristics include weather type, the probability of aircraft mission delays during the same historical period under the same weather type, and the degree of weather difference between the destination and departure point.

[0143] In this embodiment, the travel task establishment server targets MF. a For each travel task (ticket) corresponding to (e.g., flight A), three types of features are collected and fused to generate a fused feature vector:

[0144] User behavior characteristics: percentage of historical travel task changes (e.g., 3 changes in 3 out of the user's past 10 trips, normalized to 0.3), change time interval (average 5 days in advance, normalized to 0.5), whether the change was repeated (yes = 1), whether the change was abandoned due to cost (yes = 1).

[0145] User profile features: user attributes (age 35 years old, normalized to 0.35, occupation is business person, unique hot code [1,0,0]), destination (Shanghai unique hot code [1,0]), historical seat type (first class = 1).

[0146] Weather characteristics: weather type on the execution day (rainstorm unique heat code [1,0,0]), historical delay rate with the same weather (15% normalized to 0.15), and weather difference between departure point and destination (0.7).

[0147] After standardizing all features (normalizing continuous features and one-hot encoding categorical features), they are concatenated into a fused feature vector (e.g., a 20-dimensional vector) in the order of "user behavior → user profile → weather".

[0148] This step integrates three core influencing factors—user habits, identity attributes, and external environment—into the feature vector, providing more comprehensive information compared to the five simple features used by the payment platform. The server supplements the complex features not processed by the payment platform (such as weather differences and occupational profiles) to provide richer input for subsequent probability prediction, improving prediction accuracy from a data perspective, which aligns with the division of labor where "the server is responsible for accurate calculations."

[0149] Q530, MF a The fused feature vector for each corresponding travel task is input into a pre-defined second travel task change probability prediction model to obtain the MF. a The probability of change for each corresponding travel task.

[0150] The pre-set second travel task change probability prediction model is a well-trained machine learning model (such as Gradient Boosting Tree (XG Boost) or a deep learning model). This model has been trained on historical data (including "change status" labels) and can learn the correlation between fused features and change behavior. The server inputs the fused feature vector generated in step Q520 into the model and outputs the change probability for each travel task (values ​​range from 0 to 1, e.g., a change probability of 0.25 for a certain ticket, representing a 25% chance of change). For example, if flight A contains 100 tickets, the model outputs 100 probability values ​​(0.1, 0.25, 0.3, ...).

[0151] The second model, run on a server, can utilize more computing power to process complex features and model calculations. Compared to the lightweight logic of the payment platform, it can more accurately capture change patterns (such as the strong impact of the combination of "business users + heavy rain" on changes). The output probability values ​​quantify the likelihood of changes for each travel mission, providing quantifiable basic data for the overall ranking of subsequent aircraft missions.

[0152] Q540, based on the change probability of each travel mission corresponding to each target aircraft mission in MF, sort the target aircraft missions in MF to obtain YA.

[0153] Furthermore, step Q540 includes the following steps:

[0154] Q541, according to MF a The probability of change for each corresponding travel task is used to determine MF. a The corresponding average probability of change.

[0155] For MF a (For example, the arithmetic mean of the change probabilities of all travel missions corresponding to flight A is used to obtain the average change probability of the target aircraft mission.)

[0156] By aggregating "mission-level change probability" into "aircraft mission-level overall change risk" through average probability, the judgment of the entire flight is avoided due to individual extreme values ​​(such as a single high-probability ticket); the average probability can comprehensively reflect the overall change level of the flight and provide a unified and comparable indicator for ranking different flights.

[0157] Q542, sort the target aircraft missions in MF in ascending order of average change probability to obtain YA.

[0158] The target aircraft missions in MF are sorted in order of "average change probability from smallest to largest", that is, the lower the average probability (the lower the overall change risk), the higher the flight is ranked.

[0159] The sorting results ensure that aircraft tasks with the "lowest overall change probability" are placed at the top, providing a clear basis for the subsequent migration steps of Q600—migrating the top 1% of tasks in YA (such as the top 30%), that is, prioritizing the migration of tasks with the lowest change risk to the cold database. This can effectively free up space in the hot database while maximizing the retention of high change risk tasks in the hot database to ensure the efficiency of user cancellation and rescheduling. At the same time, the sorting logic is simple and intuitive, and the server can complete it quickly, balancing accuracy and efficiency.

[0160] Q600 sends each flight mission corresponding to the first preset proportion of aircraft missions in YA to the cold database.

[0161] The system presets a "first preset ratio" (based on the amount of space to be released from the hot database, such as 30%, which means migrating the first 30% of flights in YA). The system then selects the aircraft missions with this ratio from the list YA and migrates all their corresponding travel missions from the hot database to the cold database.

[0162] By using "proportional filtering" instead of "full migration," we avoid blindly migrating all target flights and ensure that only a small portion of tasks with the "lowest probability of change" are migrated. This frees up hot data storage space while maximizing the retention of tasks with a high probability of change (such as the last 70% of flights in YA) in the hot data storage, ensuring the efficiency of users' refund and change query. At the same time, the migration logic is simple, requiring only the selection of the top N tasks based on the sorting results, without the need for additional calculations, thus balancing space release and service quality.

[0163] In this embodiment, when the remaining storage space of the hot database is less than a preset threshold, the initial travel task difference is first determined by acquiring the task characteristics of the travel task corresponding to each aircraft mission. Then, the target difference is obtained by combining the interval between the task execution time and the current time. Subsequently, the travel task creation server sorts the aircraft missions according to the travel task change probability and migrates the first preset proportion of tasks to the cold database. This can accurately identify travel tasks in the hot database with relatively low change probability and less impact on the efficiency of refund and change query for migration, effectively avoiding the situation of mistakenly migrating high change probability tasks and ensuring efficient response of refund and change query. At the same time, the hot database storage space is reasonably released through targeted migration, avoiding low-value data from occupying valuable hot storage resources, realizing the optimized utilization of hot database storage resources, and successfully balancing the core needs of data access efficiency and storage space management.

[0164] Example 3:

[0165] Based on the methods of Embodiment 1 and Embodiment 2 described above, there are also cases where a preset event occurs in the cold database for a spacecraft mission. In this case, the following method is provided:

[0166] R100: For any aircraft mission HW in the cold database, if a mission change event RH occurs in HW, then obtain the number of travel missions corresponding to HW, NUM1.

[0167] In this embodiment, a mission change event refers to an event in the cold database that may trigger a user's cancellation or rebooking for an aircraft mission (HW) (such as a long-term flight). This includes adjustments to the departure time (e.g., moving it forward by 2 hours), route changes (e.g., changing from "Beijing-Shanghai" to "Beijing-Hangzhou"), and aircraft type changes. The system monitors the status of all HWs in the cold database in real time. If a certain HW triggers a weather warning (RH), the system extracts the number of all travel missions associated with that HW (i.e., the number of tickets purchased by the user for that flight) from the database, denoted as NUM1. For example, if a flight HW (departing in 10 days) in the cold database has its departure time adjusted due to a weather warning (RH), and the system finds 120 tickets already sold for that flight, then NUM1 = 120.

[0168] By using the "event-triggered" mechanism, subsequent processes are only initiated when there is an actual risk of change in HW, avoiding invalid processing of long-term tasks without change events and reducing the daily computing power consumption of the system; at the same time, NUM1 is prioritized to provide a quantitative basis for subsequent "whether to continue processing", avoiding complex processes for HW with very few travel tasks (such as only 5 tickets), saving resources from the source.

[0169] R200, if NUM1≥NUM Y Then, the features of each travel task corresponding to HW in different dimensions are obtained to generate a comprehensive feature vector of each travel task corresponding to HW.

[0170] Furthermore, the comprehensive feature vector for each travel task corresponding to HW is obtained through the following steps:

[0171] R210 obtains user behavior characteristics, user profile characteristics, weather characteristics at the execution time, and cost change characteristics for each travel task corresponding to HW.

[0172] R220 encodes the user behavior features, user profile features, weather features at the execution time, and cost change features for each travel task corresponding to HW, resulting in a comprehensive feature vector for each travel task corresponding to HW.

[0173] In this embodiment, a preset quantity threshold NUMY is used (based on business efficiency, such as 50, meaning that resources are only worth investing in processing when the number of travel tasks is ≥ 50). If NUM1 ≥ NUM Y If 120 ≥ 50, then feature extraction is initiated; if NUM1 < NUM Y If the process is terminated, the process will be terminated directly. It should be noted that the method for generating the comprehensive feature vector in steps R210 and R220 is the same as the method in step S300 in Example 2, and will not be described again here.

[0174] Through NUM YThe system filters out low-value, small-batch task processing needs, ensuring that system resources are focused on high-impact, large-batch tasks. The comprehensive feature vector integrates multi-dimensional information from users, tasks, and the environment, providing comprehensive input for subsequent probability prediction, avoiding prediction bias caused by single-dimensional features, and laying the foundation for accurate prediction.

[0175] R300 inputs the comprehensive feature vector of each travel task corresponding to HW into the preset general travel task change probability prediction model to obtain the task change probability of each travel task corresponding to HW.

[0176] In this embodiment, the preset general travel task change probability prediction model is preferably a gradient boosting tree model (such as XGBoost or LightGBM). This model has been trained using historical data (including travel task samples labeled "whether it has changed") and can capture the nonlinear relationships between features (such as the cumulative effect of the combination of "high membership level + high ticket price + rainstorm warning" on the change probability). The system inputs each comprehensive feature vector generated by R200 into the model and outputs the corresponding travel task change probability (value range 0-1, or 0%-100%). For example, after inputting the comprehensive feature vector of a certain air ticket into the model, the output change probability is 65%; another air ticket has a low historical cancellation and change rate, and the output probability is 20%.

[0177] The general model is trained on a large amount of historical data and has stable generalization ability. It can quickly output change probabilities in batches and is more objective and accurate than manual rule judgment. The model has mature processing logic and does not require repeated training for a single RH, reducing development and maintenance costs. At the same time, it provides a basic quantitative basis for possible subsequent probability adjustments.

[0178] In R400, if the change information of RH indicates that there is a preset adjustment weight algorithm for RH, then obtain the specified information for each trip task corresponding to HW; otherwise, proceed to R700; the specified information and the change information of RH have a preset association relationship.

[0179] In this embodiment, if the current RH (e.g., the departure time is 1 hour earlier) has a corresponding algorithm in the mapping table, then the "specified information" (e.g., the purchase location of each ticket) of each travel task under the HW is extracted from the database; if the RH does not have a corresponding algorithm, then the adjustment process is skipped and directly enters R700.

[0180] The dynamic matching algorithm of the mapping table ensures that probability adjustments are made only for the RH with significant impact, avoiding meaningless calculations; the specified information is strongly correlated with the RH, providing targeted data for subsequent weight calculations, making the adjustment logic fit the impact pattern of specific events, while the "skip if no algorithm" design improves the flexibility of the process and adapts to RHs of different complexities.

[0181] Furthermore, step R400 includes the following steps:

[0182] R410, retrieve the event change type LX corresponding to RH.

[0183] Event Change Type (LX) is a standardized classification of task change events (RH) used to clarify the core impact characteristics of the event. The system extracts LX by parsing RH metadata (such as the "Type Identifier" field in the event log). Common types include:

[0184] LX1: Departure time adjustment (e.g., earlier / later by ≥1 hour);

[0185] LX2: Route change (e.g., destination changed from city A to city B);

[0186] LX3: Aircraft model change (e.g., changing from a wide-body aircraft to a narrow-body aircraft, which affects seat comfort);

[0187] LX4: Airline policy adjustments (such as increased refund and change fees).

[0188] For example, if RH is "the departure time of flight HW is postponed from 10:00 to 12:30", then its type identifier is parsed as LX1 (departure time adjustment).

[0189] By standardizing classification, complex RHs are transformed into clear LXs, providing a unified basis for judgment in subsequent "algorithm matching" and avoiding ambiguity in identification caused by vague event descriptions (such as "flight changes"). At the same time, LXs are directly associated with the core impact dimensions of the event (such as time, space, and comfort), laying the foundation for precise matching and algorithm adjustment, and ensuring the targeted nature of subsequent processes.

[0190] R420 determines whether there is a corresponding adjustment weight algorithm for LX based on LX and the preset adjustment weight algorithm mapping table. The adjustment weight algorithm mapping table includes several rows, each of which includes an event change type and the corresponding adjustment weight algorithm.

[0191] The preset weight adjustment algorithm mapping table is a predefined "event type-algorithm" association rule base, and its structure is shown in Table 1:

[0192] Table 1

[0193]

[0194] The system matches the LX extracted from R410 with the "Event Change Type" column in the mapping table to determine if a corresponding adjustment weight algorithm exists. For example, if LX1 (departure time adjustment) has a corresponding algorithm in the table, it is determined to "exist"; if the LX of a certain RH is "meal standard reduction" (not defined in the table), it is determined to "not exist".

[0195] The mapping table achieves rapid matching of "event type - algorithm" through preset rules, avoiding the subjectivity and delay of manual judgment and improving the degree of process automation. At the same time, the association between the algorithm and LX in the table is designed based on business experience (such as the greater impact of route changes on high-fare users), ensuring that the matching algorithm can accurately capture the differentiated impact of events and provide reasonable logic for subsequent weight calculation.

[0196] In R430, if the weight adjustment algorithm mapping table includes LX, then it is determined that RH has a preset weight adjustment algorithm, and the specified information for each trip task corresponding to HW is obtained according to the change information of RH; otherwise, it is determined that LX does not have a corresponding weight adjustment algorithm, the task change probability of each trip task is not adjusted, and the process proceeds to R700.

[0197] If an algorithm corresponding to LX exists in the mapping table (e.g., LX1 matches the "booking location weight algorithm"), the system extracts "specified information" from the travel task data corresponding to HW. This information is directly related to the change information of RH and is the core input for algorithm calculation. For example, the specified information for LX1 (departure time adjustment) is "the booking location of each travel task" (because users with distant booking locations may cancel or change their bookings due to time changes); the specified information for LX2 (route change) is "the ticket price of each travel task" (because users with higher ticket prices are more sensitive to route changes).

[0198] If the mapping table does not contain an algorithm corresponding to LX (such as "meal standard reduction"), it is determined that no weight adjustment is needed, and R500-R600 is skipped directly to R700 to count the number of high-risk tasks.

[0199] By using the logic of "retrieve specified information if it exists, and jump if it does not exist", we ensure that only events with clear impact patterns are weighted, avoiding invalid calculations for low-impact events (such as changes in meals) and reducing system resource consumption. At the same time, the specified information is strongly correlated with LX (such as time adjustment being associated with the booking location), providing targeted data for the weighting algorithm, ensuring that the adjustment logic fits the actual impact of the event, and improving the accuracy of subsequent probability corrections.

[0200] R500 determines the adjustment weight of each trip task corresponding to HW based on the specified information of each trip task and the corresponding adjustment weight algorithm.

[0201] The weights are calculated based on the specified information obtained from R400 and the corresponding algorithm (the value ranges from 0 to 1; the higher the weight, the greater the impact of RH on the task, and the more important it is to adjust the probability). For example, if RH is "takeoff time 1 hour earlier", the corresponding algorithm is "the farther the pre-location, the higher the weight".

[0202] The weights quantify the differences in sensitivity of different tasks to RH (e.g., users with more distant booking locations are more likely to cancel or change their bookings due to earlier departure times), avoiding a "one-size-fits-all" probability adjustment and making subsequent corrections more accurate. The weight calculation logic is closely integrated with the specified information, without the need to introduce additional data, ensuring efficient calculation and alignment with business scenarios. At the same time, the weight normalization process facilitates subsequent probability adjustment operations.

[0203] Furthermore, if RH is a preset time change event, step R500 includes the following steps:

[0204] R510, obtain the original planned execution time point t corresponding to RH. y .

[0205] When RH is a time-change event (such as a flight departure time adjustment), the system extracts the original planned execution time point t of the corresponding aircraft mission HW from the cold database. y (For example, if the original scheduled departure time was 14:00 on October 15, 2025), this will serve as a benchmark for subsequently assessing the impact of the time change. For instance, if RH indicates "Flight HW's departure time has been moved from 14:00 to 13:30," then t... y =2025-10-15 14:00.

[0206] By clearly defining the original planned time t y For subsequent comparison of "adjusted time t" h "Differences from the original plan provide a basis for ensuring that only changes with a real impact, such as 'time ahead,' are addressed in a targeted manner, avoiding complex processes for minor time adjustments with no substantial impact (such as delaying by 5 minutes), and improving the accuracy of system processing."

[0207] R520, if t y Within the preset time period and the adjusted planned execution time point t corresponding to RH h Earlier than t y Then, the predicted departure point of the user corresponding to each travel task is obtained.

[0208] In this embodiment, the start time of the preset time period can be 19:00 and the end time can be 22:00. During this time period, users usually leave for the airport after get off work. Adjusting the flight departure time forward may cause users to be unable to arrive at the airport before the flight takes off.

[0209] Furthermore, step R520 includes the following steps:

[0210] R521, for any travel task HV corresponding to HW, obtain every historical query location of the user corresponding to HV before HV was created.

[0211] For any travel task HV corresponding to HW (such as a user's purchased flight ticket), the system extracts all historical query locations from the user's behavior log "before the creation of HV" (such as within one month before the ticket purchase). These locations are usually departure-related locations queried when the user plans their trip (such as the Chaoyang District location in "the route from Chaoyang District, Beijing to Shanghai Hongqiao Airport"), in latitude and longitude coordinates (such as 39.9042°N, 116.4074°E). For example, if the user queried three locations before purchasing the HV ticket: A (home), B (company), and C (friend's house), then the latitude and longitude of these three locations will be extracted.

[0212] Historical location queries directly reflect the potential departure point when users plan their trips. Compared to default addresses (such as place of residence), they are closer to actual travel habits, providing a real behavioral basis for subsequent predictions of departure points and avoiding misjudgments of departure points due to assumption bias.

[0213] R522, if the area of ​​the smallest circular region corresponding to the historical query location is less than the preset area threshold, then the center point of the smallest circular region corresponding to the historical query location is determined as the predicted departure point of the user corresponding to HV.

[0214] The smallest circular region refers to the smallest circle that can cover all historical query locations. The area can be obtained by calculating the radius of this circle (the distance from the farthest location to the center of the circle). A preset area threshold (e.g., 10 square kilometers, corresponding to a small area within a city) is used. If the area of ​​the smallest circular region is less than the threshold (e.g., if all three query locations of the user are in Chaoyang District, Beijing, the area is 5 square kilometers), then the center point of the circle (e.g., the geometric center of Chaoyang District) is determined as the predicted origin of the user corresponding to HV.

[0215] For users with concentrated locations, the smallest circle center point is directly selected. The calculation logic is simple (only geometric calculation is required) and can accurately reflect the core starting range of users (such as within the same administrative region), avoiding overly complex processing and improving prediction efficiency.

[0216] R523: If the area of ​​the smallest circular region corresponding to the historical query location is greater than or equal to the preset area threshold, then the historical query locations are clustered to obtain several clusters.

[0217] R524 determines the center point of the smallest circular region corresponding to the two clusters with the most historical query locations within a cluster as the predicted origin of the user corresponding to HV.

[0218] If the area of ​​the smallest circular region is greater than or equal to a threshold (e.g., the user's query location is distributed in Chaoyang District, Haidian District, and Fengtai District of Beijing, with an area of ​​50 square kilometers), then the DBSCAN clustering algorithm is used to group the historical query locations into clusters. The number of clusters is automatically determined based on the degree of location dispersion (e.g., divided into 2 clusters). In R524, the number of locations contained in each cluster is counted, and the center points of the smallest circular regions corresponding to the two clusters with the most locations (e.g., the Chaoyang District cluster contains 5 locations, and the Haidian District cluster contains 3 locations) are determined as the user's two predicted starting points (e.g., the center of Chaoyang District and the center of Haidian District).

[0219] By clustering scattered locations, multiple common departure points of users (such as home and office) can be identified, avoiding misjudgment of a single departure point due to location dispersion; selecting the two clusters with the most numbers ensures coverage of the user's most likely departure scenarios and improves the comprehensiveness of prediction.

[0220] R530 determines the adjustment weight of each travel task corresponding to HW based on the predicted departure point of the user and th for each travel task.

[0221] Furthermore, step R530 includes the following steps:

[0222] R531, if the user corresponding to HV has only one departure point, then the travel time from the departure point to the execution point of the travel task is determined as the user's travel time TU corresponding to HV.

[0223] If a user has only one predicted departure point (such as the center of Chaoyang District), the "typical travel time" from that point to the destination of the travel task (such as Beijing Capital Airport) is calculated through the map service API (considering the characteristics of time periods such as morning rush hour, such as 1 hour), and is used as the TU.

[0224] R532, if the user corresponding to HV has two departure points, then the longest travel time from the two departure points to the execution point of the travel task will be used to determine the user's travel time TU corresponding to HV.

[0225] If a user has two predicted departure points (such as the center of Chaoyang District and the center of Haidian District), calculate the travel time from each point to the execution point (1 hour and 1.5 hours respectively), and take the longest value (1.5 hours) as the TU (a conservative estimate of the maximum time the user may need).

[0226] The calculation of TU combines actual geographical distance and time period characteristics to ensure that the real time cost of users from the point of origin to the execution point is quantified; when there are multiple points of origin, the longest value is taken to avoid underestimating the degree of time pressure, and to provide a conservative and reliable basis for subsequent weight calculation.

[0227] R533, based on the preset departure time t c and t h Determine the first duration TD=th -t c .

[0228] In this embodiment, the preset departure time point t c It could be 18:00, which is the approximate time when the user gets off work; TD is the time required for the user to travel to the airport.

[0229] TD quantifies the interval between a user's "planned departure time and the adjusted execution time," directly relating it to the user's time sufficiency after the time change, providing a core indicator for judging "whether a user may miss the trip due to the earlier departure time."

[0230] R534, if TU≥TD, then determine the adjustment weight λ corresponding to HV. HV The preset adjustment weight α is used; otherwise, λ is determined. HV =1+β×(1 / TU+1 / TD); β is a preset coefficient.

[0231] If TU ≥ TD (e.g., TU = 1.5 hours, TD = 1 hour, the user's travel time exceeds the planned available time), it means the user is likely to miss the trip due to early arrival, and the weight λ should be adjusted. HV Set it to a preset high weight α (e.g., 1.5, to amplify the probability of change).

[0232] If TU < TD (e.g., TU = 1 hour, TD = 2 hours), then use formula λ. HV =1+β×(1 / TU+1 / TD) is used to calculate (β is a preset coefficient, such as 0.2), i.e., λ HV =1+0.2×(1 / 1+1 / 2)=1+0.2×1.5=1.3, the smaller TU (the tighter the time) or the smaller TD (the shorter the planning interval), the higher the weight.

[0233] By dynamically determining the weights through the comparison of TU and TD, the impact of time changes on users is accurately quantified (high weight is used if the user cannot make it, and the weight is calculated according to the degree of urgency if there is enough time), avoiding a "one-size-fits-all" weight setting. The formula design ensures that the weights are positively correlated with the degree of time urgency, ensuring that the adjusted change probability can truly reflect the possibility of users changing their plans due to the earlier time, providing a more accurate basis for subsequent migration decisions.

[0234] R600 adjusts the probability of change for each task based on the adjustment weight of each trip task corresponding to HW.

[0235] In this embodiment, after obtaining the adjusted weights in the above steps, the probability is adjusted using a weighted correction logic. The formula is: Adjusted change probability = Initial predicted probability × Adjusted weight. For example, if the initial probability of a certain air ticket is 65%, the adjusted weight is 1.5, and the adjusted probability is 65% × (1.5) = 97.5%.

[0236] By amplifying the change probability of tasks heavily affected by RH, the bias of the general model that ignores the special nature of events (such as the general model not considering the strong impact of "earlier takeoff time" on old users) is corrected, making the adjusted probability more in line with the real change risk after RH occurs, and providing a more accurate basis for subsequent migration judgment.

[0237] R700, obtain the number of tasks with a probability of change greater than the preset task change probability threshold, NUM2.

[0238] The preset task change probability threshold is set based on hot database storage and service requirements, such as 40%. Tasks with a probability ≥ 40% are considered high-risk. The system iterates through all travel tasks under HW (adjusted or initial) to count the number of tasks with a probability ≥ the threshold, denoted as NUM2. For example, if HW has 120 tickets, and 72 of them have a change probability ≥ 40%, then NUM2 = 72.

[0239] By using threshold filtering, the dispersed probability values ​​are transformed into a statistically significant indicator of "the number of high-risk tasks," thus avoiding the influence of extreme probabilities of individual tasks (such as a task with a 100% probability) on the overall decision. At the same time, NUM2 directly reflects the scale of high-risk tasks under HW, providing core data support for the subsequent judgment on the proportion of "whether to migrate."

[0240] R800, if NUM2 / NUM1≥ω, then each trip task corresponding to HW will be migrated to the hot database; ω is a preset proportional threshold.

[0241] A preset ratio threshold ω (based on hot database space and service priority, such as 50%, meaning that the entire database will only be migrated when the proportion of high-risk tasks is ≥50%) is used to calculate the ratio of NUM2 / NUM1. If the ratio is ≥ω (e.g., 72 / 120=60%≥50%), then all 120 travel tasks corresponding to HW will be migrated from the cold database to the hot database; if the ratio is <ω, then no migration will be performed.

[0242] By using proportions to ensure that only the HW task set that is "overall high-risk" is migrated, we can avoid wasting hot storage space due to blindly migrating a small number of high-risk tasks (such as NUM2=20, NUM1=120, accounting for 17% < 50%), or affecting the efficiency of refunds and changes due to the high proportion of high-risk tasks not being migrated. At the same time, "overall migration" rather than "single task migration" simplifies the operation process, improves data migration efficiency, and balances hot storage costs and user service quality.

[0243] In this embodiment, firstly, the number of travel tasks is used to filter out the aircraft tasks that need to be prioritized for processing, avoiding invalid calculations for aircraft tasks with very few travel tasks and improving processing efficiency. Secondly, based on the change probability prediction of the general model, if there is a corresponding adjustment weight algorithm for the task change event, the adjustment weight is calculated and the probability is corrected by combining the specified information of the travel tasks associated with the task change event, so that the change probability prediction result is more in line with the actual impact of the task change event and improves the prediction accuracy. Finally, the proportion of travel tasks with a high change probability is used to determine whether to migrate, ensuring that all travel tasks corresponding to the task change event are migrated to the hot database only when the proportion of high change probability travel tasks is high enough. This avoids the waste of hot database space caused by blindly migrating all tasks, and can accurately cover tasks with high change demand to ensure the efficiency of refund and change query. It effectively solves the problems of low efficiency, inaccurate prediction and resource waste in the prior art, and realizes the accuracy and efficiency of travel task storage under event triggering.

[0244] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0245] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0246] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0247] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0248] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0249] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0250] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0251] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0252] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0253] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0254] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0255] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0256] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0257] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0258] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0259] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0260] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for storing travel task data based on hot and cold databases, characterized in that, The method includes the following steps: S100, at each preset time point, the user's designated travel task within the first preset future time period WT1 is migrated from the cold database to the hot database; the start time point of the preset future time period is the preset time point, and the designated travel task is the travel task whose execution time point is within WT1 and stored in the cold database; the travel task includes the corresponding travel task value information. S200: Obtain the pending travel tasks of users corresponding to each aircraft task in the cold database within the second preset future time period WT2, with the execution time point of WT2 being the end time point of WT1; S300 generates a comprehensive feature vector for each pending travel task based on user behavior characteristics, user profile characteristics, weather characteristics at the execution time, and cost change characteristics. S400, input the comprehensive feature vector corresponding to each pending travel task into the preset first travel task change probability prediction model to obtain the initial probability of change for each pending travel task. S500 determines the change weight of each pending travel mission corresponding to each aircraft mission based on the change rules of each pending travel mission corresponding to each aircraft mission. S600 determines the overall change probability of each aircraft mission based on the change weight and initial probability of each pending travel mission corresponding to each aircraft mission. S700 migrates each pending travel mission corresponding to an aircraft mission whose overall change probability is greater than a preset overall change probability threshold to a hot database.

2. The method for storing travel task data based on cold and hot databases according to claim 1, characterized in that, Step S300 includes the following steps: S310, for any pending travel task RW, obtain several user behavior features and several user profile features corresponding to RW; user behavior features include the percentage of historical travel task changes, the time interval between the travel task change time and the travel task execution time, whether there are repeated changes to the same travel task, and whether there are changes abandoned due to value; user profile features include several user attributes, destination, and seat type corresponding to historical travel tasks. S320, Encode the several user behavior features and several user profile features corresponding to RW to obtain the first feature vector XL1 corresponding to RW; S330, obtain several weather characteristics and cost value change characteristics of the execution time of RW; the weather characteristics include weather type, the probability of aircraft mission delay in the same weather type in the same period of history, and the weather difference between the destination and the departure point; the cost value change characteristics include the difference between the current cost value and the initial cost value, the cost value loss curve corresponding to the change of RW, and the cost value and the number of remaining travel missions of other travel missions on the same route as RW. S340, perform feature encoding on several weather features and cost change features at the execution time of RW to obtain the second feature vector XL2 corresponding to RW; S350, fuse XL1 and XL2 to obtain the comprehensive feature vector XL corresponding to RW. z = (XL1, XL2).

3. The method for storing travel task data based on cold and hot databases according to claim 1, characterized in that, Step S500 includes the following steps: S510, for any aircraft mission FW whose execution time point is within WT2, determine the loss value corresponding to the change of each pending travel mission according to the change rules established when each pending travel mission is established, so as to obtain the loss value list SW = (SW1, SW2, ..., SW3, ..., SW4) corresponding to FW. i , ...,SW n ), i=1,2,…,n;SW i Let n be the loss cost corresponding to the i-th pending travel task change for FW, and n be the number of pending travel tasks corresponding to FW. S520, based on SW, determine the change weight of each pending travel task corresponding to FW, so as to obtain the change weight list A = (A1, A2, ..., A3, ..., A...) for FW. i A n A i Let A be the change weight for the i-th pending travel task corresponding to FW; i =(1 / SW i ) / ∑ n i=1 (1 / SW) i ).

4. The method for storing travel task data based on cold and hot databases according to claim 3, characterized in that, Step S600 includes the following steps: S610, obtain the initial probability of each pending travel task change corresponding to FW, so as to obtain the initial probability list B = (B1, B2, ..., B3, ..., B i B n ); B i Let FW be the initial probability of changing the i-th pending travel task. S620, Based on B and A, determine the overall change probability η corresponding to FW = ∑ n i=1 (A) i ×B i ).

5. The method for storing travel task data based on cold and hot databases according to claim 1, characterized in that, The preset first travel task change probability prediction model is a gradient boosting tree model.

6. The method for storing travel task data based on cold and hot databases according to claim 1, characterized in that, WT1 and WT2 are determined through the following steps: S110, obtain the average time interval QT between the change initiation time and the execution time of each historical travel task that has undergone changes within a preset historical time period; S120, based on the preset time point and the preset first adjustment coefficient mapping table, determine the first adjustment coefficient α1 corresponding to the preset time point; the first adjustment coefficient mapping table includes several rows, each row including a time range and the corresponding first adjustment coefficient; S130, based on QT and α1, determine WT1 = QT × α1; S140, based on WT1, determine WT2 = α2 × WT1; α2 is the preset second adjustment coefficient; α2 < 1.

7. The method for storing travel task data based on cold and hot databases according to claim 1, characterized in that, The preset first travel task change probability prediction model is obtained by training on historical travel tasks.

8. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the travel task data storage method based on cold and hot databases as described in any one of claims 1-7.

9. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 8.

Images