Statistical storage method and system based on saas area order and transport capacity supply and demand board

By implementing distributed cache and timed batch writing technology on the saas delegate driving platform, order and capacity data are monitored and captured in real time, thermal calculation and data statistics are carried out, and the problems of supply and demand imbalance and data updates in the existing technology are solved, and efficient and accurate supply and demand matching and operation decision support are achieved.

CN119671605APending Publication Date: 2025-03-21BEIJING LONGJU YIXING TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411607415.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-12
Publication Date
2025-03-21

AI Technical Summary

Technical Problem

The existing technology is difficult to achieve real-time and accurate matching of orders and capacity supply and demand in the saas Internet driving platform, resulting in supply and demand imbalance, and the real-time data update is not high, making it difficult to meet the real-time requirements.

Method used

By implementing distributed cache and timed batch writing technology on the saas delegate driving platform, order and capacity data are monitored and captured in real time, thermal calculations and data statistics are performed, grid granularity is dynamically adjusted, and supply and demand matching is optimized.

Benefits of technology

Real-time updates and high accuracy of data are achieved, supply and demand matching efficiency is optimized, user experience and operational decision-making efficiency is improved, system pressure is reduced and performance is improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119671605A_ABST
    Figure CN119671605A_ABST
Patent Text Reader

Abstract

The invention discloses a statistical storage method and system based on saas area orders and a transport capacity supply and demand board. The invention relates to the technical field of saas internet designated driving platforms. The order monitoring module monitors a data stream at an order side and captures a passenger event in real time; a transport capacity monitoring module starts to monitor data streams of an asset side and a position side, and driver events are captured in real time; setting data types, formats and conditions required to be captured by the order monitoring module according to business requirements; by monitoring a data source in real time and capturing a dynamic event and combining an efficient data preprocessing and caching strategy, real-time updating and high accuracy of data are ensured. Therefore, instant and reliable supply and demand information is provided for the user, and a more intelligent decision can be made. Through thermodynamic calculation and dynamic data statistics, supply and demand conditions of different areas and different time periods are accurately revealed. Therefore, the platform can deploy the transport capacity more accurately, and the real-time requirements of passengers are met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of SaaS (saas) Internet designated driver platform, and in particular to a statistical storage method and system based on SaaS regional orders and transportation capacity supply and demand dashboards. Background Art

[0002] In the technical framework of Internet designated driver services, the SaaS designated driver platform plays a key role in connecting fleet service providers (i.e., transportation capacity suppliers) and passengers (i.e., demanders), forming a complex bilateral transaction platform. The platform relies on the online reservation system to realize the instant initiation of passenger orders and the effective connection with the service provider's professional designated driver. This process not only involves an efficient algorithm matching mechanism to ensure the accurate matching of orders and transportation capacity, but also integrates strict risk control measures to ensure the safety of personnel and vehicles during the service process and ensure that passengers can arrive at their destination smoothly.

[0003] One of the core challenges is the efficiency and effectiveness of matchmaking transactions, which is the pain point of the operation of the designated driver platform. The platform needs to efficiently match the capacity for passengers while maximizing the use of limited capacity resources. However, the supply and demand relationship in real scenarios shows significant time and space imbalances. In terms of time, there are obvious peak and trough cycles in the order volume, while the departure time of the capacity has great uncertainty; in terms of space, the order distribution shows a sharp contrast between hot and unpopular areas, and the capacity itself is also in a dynamic flow state. This series of factors work together to easily lead to the supply and demand imbalance problem of idle capacity and long waiting times for passengers.

[0004] To meet this challenge, existing technical systems mainly rely on two strategies: scheduled full update and real-time incremental update. However, both methods have inherent limitations. The scheduled full update strategy is difficult to meet real-time requirements due to the long data update cycle; while the real-time incremental update can improve immediacy, the data accuracy gradually decreases over time, and its incremental statistics process needs to wait for the full statistics to be completed, resulting in prominent data consistency issues in high-concurrency scenarios.

[0005] In addition, the current solution uses a unified grid granularity when collecting data, without fully considering regional differences, market competition trends, and specific strategic requirements of operators in different cities. Therefore, the calculation of order thermal value, capacity thermal value, and comprehensive thermal value lacks the ability to flexibly adjust according to the characteristics of different regions. In view of this, it is particularly important to build a supply and demand analysis model that can dynamically adjust the grid granularity. The model should be able to automatically optimize the grid division according to the actual situation of each region, such as competition intensity, market demand changes, and operator strategy adjustments, so as to achieve more refined supply and demand matching and prediction, thereby effectively improving the overall efficiency and user experience of the designated driver service.

[0006] To this end, the present invention proposes a statistical storage method and system based on SaaS regional orders and transportation capacity supply and demand dashboard. Summary of the invention

[0007] In view of this, the embodiment of the present invention hopes to provide a statistical storage method and system based on SaaS regional orders and transportation supply and demand dashboards to solve or alleviate the technical problems existing in the prior art, namely, the problem of volatile data and low real-time data update, and at least provide a beneficial option for this; the technical solution of the present invention is implemented as follows:

[0008] First, the statistical storage method based on SaaS regional orders and transportation supply and demand:

[0009] 1. Overview:

[0010] The present invention aims to build an efficient and real-time data processing system for the designated driver platform to optimize the matching of supply and demand and enhance the user experience. By monitoring the data streams on both the order and capacity sides, the dynamic events of passengers and drivers are captured in real time, providing a basis for subsequent data processing and analysis. The solution adopts the technology of distributed caching and timed batch writing, which not only ensures the real-time performance of data processing, but also reduces the writing pressure of the database. Through thermal calculation and data statistics, the solution can accurately reflect the supply and demand situation in different regions and time periods, and provide strong support for operational decisions. At the same time, the calculation of the supply and demand gap further reveals the unbalanced state of the market, and provides a basis for adjusting the distribution of capacity and formulating marketing strategies. Finally, through the data query and display module, users can intuitively understand the real-time supply and demand market information of the entire city or nearby, so as to make more informed decisions.

[0011] (II) Technical solution:

[0012] To achieve the above technical goals, enter the SaaS platform data processing activation command, which is issued by the system administrator or automated script, marking the official start of the data processing process. Then start the following operation process.

[0013] 2.1 Step S1, data source monitoring and data capture:

[0014] The order monitoring module monitors the data stream on the order side and captures passenger events in real time;

[0015] The capacity monitoring module starts monitoring the data streams on the asset side and the location side, capturing driver events in real time;

[0016] 2.1.1 Step S100, initialization and configuration of order monitoring module:

[0017] According to business needs, set the data type, format, and conditions that the order monitoring module needs to capture, including passenger order placement and cancellation events; establish a stable connection with the order-side data source.

[0018] 2.1.2 Step S101, real-time capture of passenger events:

[0019] When a passenger order placement or order cancellation event is identified, it is captured; the captured passenger event data is preliminarily processed, including format conversion and deduplication, for subsequent processing.

[0020] 2.1.3 Step S102, initialization and configuration of the capacity monitoring module:

[0021] According to the needs of capacity management, set the data type, format and conditions that the capacity monitoring module needs to capture, including drivers’ dispatching, collecting and reporting locations; establish connections with data sources on the asset side and location side to ensure that capacity data can be obtained in real time.

[0022] 2.1.4 Step S103, real-time capture of driver events:

[0023] When the driver is identified as leaving, returning or reporting a location, the capture is performed.

[0024] 2.2 Step S2, data caching and writing:

[0025] The preprocessed data is first written into the JVM cache for the first partitioning in the city dimension; the data in the JVM cache is periodically written into the Redis cache pool in batches and stored in the order cache pool and the transportation capacity cache pool respectively.

[0026] 2.2.1 Step S200, data is written into JVM cache and first partition:

[0027] When data is written to the JVM cache, it is first partitioned according to the city dimension; data belonging to the same city is classified and stored so that it can be quickly retrieved and processed according to the city later.

[0028] 2.2.2 Step S201, write batches into the Redis cache pool at regular intervals:

[0029] Configure scheduled tasks and set a reasonable write frequency based on business needs. For example, you can set it to perform a write operation every 5 minutes, 10 minutes, or a longer time interval.

[0030] When the scheduled task is triggered, the data that needs to be written to the Redis cache pool is read from the JVM cache. In order to improve the writing efficiency, the data can be processed in batches, that is, multiple data are processed at one time instead of one at a time.

[0031] According to the data type (order data or transport data), the data is stored in the order cache pool and transport cache pool in the Redis cache pool. This helps with data classification management and quick retrieval. After the data is written to the Redis cache pool, the Redis persistence mechanism (such as RDB snapshots or AOF logs) is used to ensure data security and reliability. Even if the system fails, the data can be restored through Redis's persistent files.

[0032] 2.3 Step S3, thermal calculation and data statistics:

[0033] The scheduled task triggers the thermal calculation module to perform thermal calculation on the data in the Redis cache pool.

[0034] According to cells of different granularities and 5-minute time slices, the total number of orders issued, the total number of canceled orders, the total number of unaccepted orders, and the total capacity are counted.

[0035] 2.3.1 Step S300, scheduled task triggering:

[0036] Set the trigger frequency of the scheduled task (for example, trigger it every 5 minutes).

[0037] 2.3.2 Step S301, triggering the thermal calculation module:

[0038] Call the interface or function of the thermal calculation module, passing the time range and cell granularity.

[0039] 2.3.3 Step S302, data acquisition:

[0040] Establish a connection with the Redis cache pool;

[0041] Get relevant order and capacity data from the Redis cache pool according to the predefined key and value format;

[0042] 2.2.4 Step S303, thermal calculation:

[0043] Call to pre-define different cellular granularities (geographical areas or time periods) based on business needs;

[0044] Traverse the acquired data and make statistics based on the cell granularity and time slice (5 minutes);

[0045] Calculate the total number of orders issued, the total number of canceled orders, the total number of unaccepted orders, and the total capacity for each cell in each time slice.

[0046] 2.2.5 Step S304, data statistics and storage:

[0047] The calculated statistical data are summarized according to the cell granularity and time slice.

[0048] Store the aggregated statistical results in a specified database or cache for subsequent query and analysis.

[0049] 2.4 Step S4, calculation of supply and demand difference:

[0050] Based on the statistical results, the supply and demand difference of each cellular area is calculated;

[0051] Write the statistical results and supply-demand difference data in batches to the ElasticSearch engine and create corresponding indexes for subsequent queries.

[0052] 2.4.1 Step S400, obtaining statistical results:

[0053] According to the location of the statistical results stored in the previous step, the total number of orders issued, the total number of canceled orders, the total number of unaccepted orders and the total capacity of each cellular area are retrieved from the database or cache; according to business needs, the difference between demand and supply is calculated.

[0054] 2.4.2 Step S401, write ElasticSearch engine data:

[0055] The calculated supply-demand gap data is integrated with the previous statistical results to form a complete data set. The data set is given a timestamp, cell area identifier, and metadata of the data source for subsequent query and analysis.

[0056] Establish a connection with the ElasticSearch engine to ensure that the connection is stable and data can be written normally;

[0057] Use the batch write API or tools provided by ElasticSearch to write the sorted data sets into the ElasticSearch engine in batches.

[0058] 2.5 Step S5, data query and display:

[0059] When a user queries the real-time supply and demand information of the entire city or nearby through the query interface, the relevant data is retrieved from ElasticSearch and displayed to the user.

[0060] (III) Mechanism for solving technical problems:

[0061] 3.1 Real-time data source monitoring and capture:

[0062] Through the order monitoring module and the transportation capacity monitoring module, the data flow from the order side and the transportation capacity side can be monitored and captured in real time. Any passenger order, cancellation of order or driver dispatching or collecting vehicles can be captured instantly, thus ensuring the real-time and accuracy of the data.

[0063] 3.2 Scheduled batch writing and Redis cache pool:

[0064] The present invention adopts a timed batch writing method to transfer the data in the JVM cache to the Redis cache pool. The Redis cache pool is divided into an order cache pool and a transportation capacity cache pool, which store order data and transportation capacity data respectively. This strategy not only ensures the real-time update of data, but also avoids the performance overhead caused by frequent writing to the database.

[0065] 3.3 Thermal calculation and dynamic data statistics:

[0066] Through the timed triggered thermal calculation module, the present invention performs thermal calculation on the data in the Redis cache pool to evaluate the supply and demand heat in different regions. At the same time, key indicators such as the total number of orders issued, the total number of cancelled orders, the total number of unaccepted orders, and the total capacity are counted according to different granularity cells and time slices. These dynamic data provide real-time and accurate information support for operational decisions.

[0067] 3.4 Efficient data retrieval supported by ElasticSearch:

[0068] The present invention writes the statistical results and supply-demand difference data into ElasticSearch in batches, and uses its powerful search engine function to support efficient data retrieval. This enables users to quickly query the real-time supply and demand information of the entire city or nearby, which greatly facilitates decision-making.

[0069] Secondly, a statistical storage system based on SaaS regional orders and transportation supply and demand:

[0070] like Figure 6 As shown, the system is used to execute the statistical storage method as described above, including:

[0071] (1) A data source monitoring module responsible for monitoring the data flow on the order side and capturing passengers’ order placement and order cancellation events in real time.

[0072] (2) A capacity monitoring module that monitors the data streams on the asset side and the location side and captures the driver's departure, return, and reporting events in real time.

[0073] (3) Data caching and writing module, including:

[0074] JVM cache: used to temporarily store preprocessed data and support fast access.

[0075] Redis cache pool: As a high-performance distributed cache solution, it is used to persist batch data in the JVM cache. The Redis cache pool is further divided into the order cache pool and the transport capacity cache pool, which store order data and transport capacity data respectively.

[0076] (4) Timing triggers the thermal calculation of the data in the Redis cache pool, and at the same time, the thermal calculation and data statistics module counts the total number of orders issued, the total number of canceled orders, the total number of unaccepted orders, and the total capacity according to different granularity cells and time slices.

[0077] (5) A supply-demand difference calculation module that calculates the supply-demand difference of each cellular area based on the results of the data statistics module.

[0078] (6) The output data of the supply-demand difference calculation module and other statistical results are stored based on the ElasticSearch engine, and a corresponding index data persistence and retrieval module is established.

[0079] (7) Provide a user query interface, allowing users to query the data query and display module for real-time supply and demand information in the entire city or nearby.

[0080] Compared with the prior art, the present invention has the following beneficial effects:

[0081] 1. Improve data real-time and accuracy: By monitoring data sources in real time and capturing dynamic events, combined with efficient data preprocessing and caching strategies, the present invention ensures real-time data updates and high accuracy. This provides users with instant and reliable supply and demand information, helping them make more informed decisions.

[0082] 2. Optimize supply and demand matching: This invention accurately reveals the supply and demand situation in different regions and time periods through thermal calculation and dynamic data statistics. This enables the platform to allocate transportation capacity more accurately to meet the immediate needs of passengers, thereby improving the efficiency of supply and demand matching and user satisfaction.

[0083] 3. Reduce system pressure and improve performance: By adopting the technology of distributed caching and timed batch writing, the present invention effectively reduces the writing pressure of the database and improves the overall performance of the system, making the system able to easily cope with high-concurrency scenarios and ensuring the stability and availability of services.

[0084] 4. Improve operational decision-making efficiency: The real-time supply and demand information provided by the present invention provides intuitive and comprehensive data support for operators, which enables them to quickly identify market trends, formulate and adjust operational strategies, thereby improving decision-making efficiency and operational results.

[0085] 5. Enhanced user experience: By optimizing supply and demand matching and providing real-time supply and demand information, the present invention significantly improves user experience. Passengers can find suitable designated drivers more quickly, and drivers can receive orders more efficiently, thus achieving a win-win situation. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0087] Figure 1 It is a schematic diagram of the method of the present invention;

[0088] Figure 2 It is a schematic diagram of the execution flow of the method of the present invention;

[0089] Figure 3 This is a schematic diagram of step S1 of the present invention;

[0090] Figure 4 This is a schematic diagram of step S2 of the present invention;

[0091] Figure 5 This is a schematic diagram of step S3 of the present invention;

[0092] Figure 6 It is a schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0093] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0094] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0095] Terminology explanation:

[0096] "Passenger events" and "driver events" refer to passenger actions such as placing and canceling orders and driver status changes such as dispatching and receiving vehicles.

[0097] "JVM cache" is a memory area used to temporarily store preprocessed data, enabling fast access;

[0098] "Partition" refers to the preliminary division of cache data by city dimension;

[0099] "Redis cache pool" is a high-performance storage middleware used to persist batch data in the JVM cache. It is divided into "order cache pool" and "shipping cache pool";

[0100] "Thermal calculation" is the process of evaluating the heat of regional supply and demand based on cached data;

[0101] "Cell" is the smallest unit of geographical division and is used for detailed statistics;

[0102] "Total number of orders issued", "total number of cancelled orders", "total number of unaccepted orders" and "total capacity" are key indicators for measuring the supply and demand status;

[0103] "ElasticSearch" is used as a search engine to efficiently store and retrieve the above statistical data;

[0104] "Market Information" comprehensively displays the real-time supply and demand overview of the entire city or a specific area.

[0105] Embodiment 1: Figures 1 to 5 As shown, this embodiment will disclose a statistical storage method based on SaaS regional orders and transportation supply and demand. Assume a SaaS online car-hailing platform, which covers multiple cities, each of which is divided into multiple honeycomb areas. In order to grasp the order and transportation supply and demand of each region in real time, it is necessary to implement the following efficient data processing process.

[0106] In this embodiment, regarding step S1: data source monitoring and data capture:

[0107] S100: Order monitoring module initialization and configuration: Deploy the order monitoring module in the system and configure its monitoring rules. For example, set the data types to be captured as "passenger order" and "cancel order" events, the data format is JSON, and the conditions are event occurrence timestamp and order ID, etc.

[0108] Connection establishment: Establish a stable connection with the order-side data source (such as database, message middleware, etc.) through API interface or message queue.

[0109] S101: Real-time capture of passenger events:

[0110] Event recognition: When the order monitoring module recognizes the passenger's order placement or order cancellation event, it captures it immediately.

[0111] Data preprocessing: Convert the format of the captured data (such as converting a JSON string into an object) and remove duplicates (avoiding repeated capture of the same event).

[0112] S102: Initialization and configuration of the capacity monitoring module: Similarly, deploy the capacity monitoring module and configure its monitoring rules. For example, set the data types to be captured as "driver dispatch", "receive vehicle" and "report location" events, and set the data format and conditions according to actual needs. Establish connections with data sources on the asset side and location side (such as driver-side APP, GPS positioning system, etc.).

[0113] S103: Real-time capture of driver events: When the transport monitoring module identifies an event in which the driver leaves the vehicle, returns the vehicle, or reports a location, it is captured immediately.

[0114] Specifically, by monitoring and capturing the data streams on the order and transport sides in real time, we can obtain the latest passenger and driver event information in a timely manner. This approach solves the problem of data volatility and low real-time data updates in traditional technologies, because we obtain real-time data directly from the data source instead of relying on regular batch data imports.

[0115] In this embodiment, regarding step S2: data caching and writing:

[0116] S200: Data is written into JVM cache and first partitioned: The pre-processed data is written into JVM cache (i.e., a temporary storage area in memory). When writing, the first partition is performed according to the city dimension, and the data belonging to the same city is classified and stored.

[0117] S201: Scheduled batch writing to Redis cache pool: Set a scheduled task, such as triggering it every 5 minutes. When the scheduled task is triggered, read the data to be written to the Redis cache pool from the JVM cache and perform batch processing to improve writing efficiency.

[0118] According to the data type (order data or transport data), the data is stored in the order cache pool and transport cache pool in the Redis cache pool respectively. The persistence mechanism of Redis (such as RDB snapshot or AOF log) is used to ensure the security and reliability of the data.

[0119] Specifically, through the two-level cache mechanism of JVM cache and Redis cache pool, we can quickly access and process data while ensuring data security and reliability. The method of regularly writing batches to the Redis cache pool also improves the efficiency of data writing and reduces the system load.

[0120] In this embodiment, regarding step S3: thermal calculation and data statistics

[0121] S300: Scheduled task triggering: Set a scheduled task, such as triggering the thermal calculation module every 5 minutes.

[0122] S301: triggering the thermal calculation module: calling the interface or function of the thermal calculation module, and passing parameters such as time range and honeycomb granularity.

[0123] S302: Data acquisition:

[0124] Connect to Redis cache pool: Establish a connection with the Redis cache pool.

[0125] Data retrieval: Get relevant order and capacity data from the Redis cache pool according to the predefined key and value format.

[0126] S303: Thermal calculation: Define different cell granularities (such as geographical areas or time periods) according to business needs. Traverse the acquired data, perform statistics based on the cell granularity and time slice (5 minutes), and calculate the total number of orders issued, the total number of cancelled orders, the total number of unaccepted orders, and the total capacity of each cell in each time slice.

[0127] S304: Data statistics and storage: The calculated statistical data are aggregated according to the cell granularity and time slices, and the aggregated statistical results are stored in a designated database or cache for subsequent query and analysis.

[0128] Specifically, through thermal calculation and data statistics, we can grasp the order and transportation supply and demand situation of each cellular area in real time. This method solves the problem of data statistics lag and inability to reflect supply and demand changes in real time in traditional technologies. At the same time, through reasonable cellular granularity and time slicing settings, we can more finely characterize the supply and demand situation and provide more accurate data support for operational decisions.

[0129] In this embodiment, regarding step S4: supply-demand difference calculation:

[0130] S400: Obtain statistical results: retrieve the total number of orders issued, the total number of cancelled orders, the total number of unaccepted orders, and the total number of transport capacity in each cellular area from the database or cache. Calculate the difference between demand and supply (i.e., the supply-demand difference) based on business needs.

[0131] S401: Write ElasticSearch engine data: Integrate the calculated supply-demand difference data with the previous statistical results to form a complete data set. Add metadata such as timestamp, cell area identifier, and data source to the data set.

[0132] Establish a connection with the ElasticSearch engine and use the batch write API or tools it provides to write the data set to the ElasticSearch engine. At the same time, create the corresponding index for subsequent queries.

[0133] Specifically, by calculating the difference between supply and demand and writing data into the ElasticSearch engine, we can grasp the difference between supply and demand in each cellular area in real time, and provide support for subsequent data analysis and operational decisions. The efficient retrieval capability of the ElasticSearch engine also ensures that we can quickly respond to user query needs.

[0134] Step S5: Data query and display: When the user queries the real-time supply and demand information of the whole city or nearby through the query interface, the system will retrieve relevant data from the ElasticSearch engine.

[0135] The retrieved data is presented to users in the form of charts, lists, etc., so that users can intuitively understand the supply and demand situation in each region.

[0136] It is understandable that through the data query and display steps, we can present the supply and demand information calculated in real time to users. This method improves the transparency and traceability of information, which helps to improve user experience and operational efficiency. At the same time, using the efficient retrieval capabilities of the ElasticSearch engine, we can ensure the response speed and accuracy of the query.

[0137] Embodiment 2: This embodiment further provides a Python execution program of the method described in Embodiment 1:

[0138]

[0139]

[0140]

[0141]

[0142]

[0143]

[0144]

[0145] #Query

[0146] results=query_supply_demand("cityA")

[0147] for result in results:

[0148] print(result["_source"])

[0149] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0150] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0151] The above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A statistical storage method based on SaaS regional orders and transportation supply and demand dashboard, characterized in that: After receiving the data processing activation instruction from the user, the following operation flow is executed: S1, monitors the data stream on the order side and captures passenger events in real time; monitors the data stream on the asset side and the location side and captures driver events in real time; S2, writes to the JVM cache and performs the first partitioning of the city dimension; writes the data in the JVM cache in batches to the Redis cache pool regularly, and stores them in the order cache pool and the transportation capacity cache pool respectively; S3, regularly performs thermal calculations on the data in the Redis cache pool; according to different granularity cells and time slices, counts the total number of orders issued, the total number of canceled orders, the total number of unaccepted orders, and the total capacity; S4, based on the statistical results, calculate the supply and demand difference of each cellular area; write the statistical results and supply and demand difference data into the ElasticSearch engine in batches and establish the corresponding index.

2. The statistical storage method according to claim 1, characterized in that: The execution process of S1 includes: S100, according to business requirements, set the data type, format and conditions that the order monitoring module needs to capture, including passenger order placement and order cancellation events; establish a connection with the order side data source; S101, when a passenger order placement or order cancellation event is identified, capture is performed; the captured passenger event data is preliminarily processed, including format conversion and deduplication; S102, according to the needs of capacity management, set the data type, format and conditions that the capacity monitoring module needs to capture, including the driver's dispatching, collecting and reporting points; establish connections with the data sources on the asset side and the location side; S103, when it is identified that the driver is leaving the vehicle, returning the vehicle, or reporting the location, the driver is captured.

3. The statistical storage method according to claim 1, characterized in that: The execution process of S2 includes: S200, when data is written into the JVM cache, the data is first partitioned according to the city dimension; the data belonging to the same city is classified and stored; S201, configure the scheduled task and set the writing frequency according to business needs.

4. The statistical storage method according to claim 3, characterized in that: In S201, when the scheduled task is triggered, the data to be written into the Redis cache pool is read from the JVM cache; according to the type of data, the data is stored in the order cache pool and the transportation capacity cache pool in the Redis cache pool respectively.

5. The statistical storage method according to claim 1, characterized in that: The execution process of S3 includes: S300, setting the trigger frequency of the scheduled task; S301, calling the interface or function of the thermal calculation module, passing the time range and honeycomb granularity; S302, establishing a connection with a Redis cache pool; obtaining relevant order and capacity data from the Redis cache pool according to a predefined key and value format; S303, calling different cellular granularities predefined according to business requirements; traversing the acquired data, and performing statistics according to the cellular granularity and time slices; S304, summarizing the calculated statistical data according to the cell granularity and time slice.

6. The statistical storage method according to claim 5, characterized in that: In the S303, it also includes calculating the total number of orders issued, the total number of canceled orders, the total number of unaccepted orders and the total capacity of each cell in each time slice.

7. The statistical storage method according to claim 1, 2 or 5, characterized in that: The execution process of S4 includes: S400, according to the location of the statistical results stored in the previous step, the total number of orders issued, the total number of cancelled orders, the total number of unaccepted orders and the total number of transport capacity in each cellular area are retrieved from the database or cache; according to the business demand, the difference between demand and supply is calculated; S401, integrating the calculated supply-demand difference data with the previous statistical results to form a complete data set; adding a timestamp, a cell area identifier, and metadata of the data source to the data set; Use the batch write API or tools provided by ElasticSearch to write the sorted data sets into the ElasticSearch engine in batches.

8. The statistical storage method according to claim 1, 2 or 5, characterized in that: It also includes S5. When users query the real-time supply and demand information of the entire city or nearby through the query interface, relevant data is retrieved from ElasticSearch and displayed to the user.

9. A system for implementing the statistical storage method according to any one of claims 1 to 8, characterized in that: The system comprises: A data source monitoring module responsible for monitoring the data flow on the order side and capturing passengers' order placement and order cancellation events in real time; The transport monitoring module is responsible for monitoring the data streams on the asset side and the location side, and capturing the drivers' dispatching, receiving, and reporting of location events in real time; Data cache and writing module; The module is triggered regularly to perform thermal calculation on the data in the Redis cache pool, and also counts the total number of orders, the total number of cancelled orders, the total number of unaccepted orders, and the total capacity according to different granularity cells and time slices; A supply-demand difference calculation module for calculating the supply-demand difference of each cell area based on the result of the data statistics module; The output data of the supply-demand difference calculation module and other statistical results are stored based on the ElasticSearch engine, and a data persistence and retrieval module with corresponding indexes is established.

10. The statistical storage system according to claim 9, characterized in that: The data caching and writing module includes: JVM cache: used to temporarily store preprocessed data; Redis cache pool: used to persist batch data in the JVM cache.