Data processing system, method, device, medium and product

Abstract

The embodiment of the invention provides a data processing system, method and device, a medium and a product. The system comprises a monitoring service module used for receiving a data query request sent from a vehicle end and querying target version data corresponding to the data query request from a registration list according to the data query request; the second service module is used for obtaining target version data from a target sub-server in the sub-servers according to the data query request when the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster, and sending the target version data to the target sub-server according to the target version data. And sending the target version data to the vehicle end, and storing the target version data in a data cache cluster. According to the system, whether the data processing system has the corresponding version data or not can be quickly judged through the data format service and the version data recorded in detail in the registration list, so that the use effect of the data processing system is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a data processing system, method, device, medium and product. Background Art

[0002] In today's digital mobility landscape, the cloud plays a crucial role, storing, managing, and providing a wide range of mobility-related data to support diverse functions such as map rendering and navigation. This data plays a decisive role in ensuring users have a smooth and accurate travel experience.

[0003] Currently, cloud-based data service architectures typically employ a standalone deployment model. For example, rendering data and navigation data differ significantly in format and purpose, resulting in separate data services for rendering and navigation. These services independently manage data versions and employ distinct interface styles. Without effective linkage or coordination mechanisms, these services rely solely on their own operations to ensure the fulfillment of their respective functions.

[0004] However, since each data service model is independently deployed in the prior art, when there are many independently deployed data service models, a technical problem arises that management is inconvenient and results in poor usage effects. Summary of the Invention

[0005] The embodiments of the present application provide a data processing system, method, device, medium and product to facilitate the management of various data service modes, thereby improving the use effect of cloud servers.

[0006] In a first aspect, an embodiment of the present application provides a data processing system, comprising:

[0007] The first service module is configured to receive a data query request sent from the vehicle end and, based on the data query request, query the target version data corresponding to the data query request from the registration list, where the registration list is used to record the version data in the data cache cluster and the version data in the sub-server;

[0008] The second service module is used to obtain the target version data from the target sub-server in the sub-server according to the data query request when the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster, and send the target version data to the vehicle end and store the target version data in the data cache cluster.

[0009] In a possible implementation, the method further includes:

[0010] The data cache cluster is used to send the target version data corresponding to the data query request to the vehicle end when the first service module queries the target version data corresponding to the data query request from the registration list and the target version data exists in the data cache cluster, or to send the target version data to the vehicle end through the first service module.

[0011] In a possible implementation, the first service module includes:

[0012] An interface unit, used to receive a data query request sent from the vehicle end;

[0013] a query unit, configured to determine, according to an interface type of an interface unit that receives a data query request, a target version of data corresponding to the data query request, and query the target version of data corresponding to the data query request from a registration list;

[0014] And / or, the first service module includes:

[0015] A monitoring unit, configured to send health monitoring instructions to the sub-servers according to the registration list, and receive monitoring results fed back by the sub-servers according to the health monitoring instructions, wherein if the monitoring results indicate that the sub-server is abnormal, the abnormal sub-server is controlled to restart;

[0016] And / or, the first service module includes:

[0017] The sending unit is used to feed back information indicating query failure to the vehicle end when the target version data corresponding to the data query request is not found from the registration list.

[0018] In a possible implementation, there are more than two sub-servers and they are distributed. Each sub-server includes at least one version of data. The data versions and / or data service types of the version data in different sub-servers are different.

[0019] In a possible implementation, the sub-server is connected to the first service module, wherein:

[0020] When the version data in the sub-server is updated, the first service module is used to adjust the interface information of the sub-server in the registration list according to the version update notification sent by the sub-server;

[0021] and / or,

[0022] When the sub-server registers or de-registers, the first service module is used to adjust the sub-server information in the registration list according to the registration result or de-registration result of the sub-server.

[0023] In a possible implementation, the target sub-server is determined by the second service module according to the data format corresponding to the data query request and the parsing type of the sub-server;

[0024] and / or,

[0025] When the target version data is obtained through the target sub-server, the target sub-server sends the target version data to the vehicle end, or sends the target version data to the vehicle end through the first service module, or sends it to the vehicle end through the second service module and the first service module in sequence.

[0026] In a second aspect, an embodiment of the present application provides a data processing method, the method comprising:

[0027] Receive a data query request sent from the vehicle end, and query the target version data corresponding to the data query request from the registration list according to the data query request. The registration list is used to record the version data in the data cache cluster and the version data in the sub-server module;

[0028] When the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster, the target version data is obtained from the target sub-server in the sub-server according to the data query request, and the target version data is sent to the vehicle side and stored in the data cache cluster.

[0029] In a third aspect, an embodiment of the present application provides a data processing method, which is applied to a vehicle side, including:

[0030] Sending a data query request to a data processing system, so that the data processing system searches for target version data corresponding to the data query request from a registration list according to the data query request; when the target version data corresponding to the data query request is found from the registration list and the target version data does not exist in a data cache cluster of the data processing system, obtaining the target version data from a target sub-server in the sub-servers according to the data query request, sending the target version data to the vehicle end, and storing the target version data in the data cache cluster;

[0031] The target version data is received and processed.

[0032] In a fourth aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor;

[0033] Memory stores computer-executable instructions;

[0034] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above second aspect and / or various possible implementations of the second aspect.

[0035] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the various possible implementation methods described above.

[0036] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements the various possible implementation methods described above when executed by a processor.

[0037] An embodiment of the present application provides a data processing system, which receives a data query request sent from a vehicle end through a first service module, and queries the target version data corresponding to the data query request from a registration list according to the data query request, and the registration list is used to record the version data in the data cache cluster and the version data in the sub-server; when the second service module queries the target version data corresponding to the data query request from the registration list and the target version data does not exist in the data cache cluster, the target version data is obtained from the target sub-server in the sub-server according to the data query request, and the target version data is sent to the vehicle end, and the target version data is stored in the data cache cluster. This makes it possible to quickly determine whether the data processing system has the corresponding version data through the data format service and version data information recorded in detail in the registration list, so as to achieve effective management and positioning of data resources, provide a clear direction for subsequent data, and after determining the target version data from the sub-server, the target version data is stored in the data cache cluster, so as to achieve a fast response when the same data is processed next time. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0039] Figure 1 A schematic diagram of a scenario for the data processing method provided in this application;

[0040] Figure 2 Schematic diagram of the data processing system provided in this application Figure 1 ;

[0041] Figure 3 Schematic diagram of the data processing method provided in this application Figure 1 ;

[0042] Figure 4 Schematic diagram of the data processing method provided in this embodiment Figure 2 ;

[0043] Figure 5a Schematic diagram of the data processing system provided in this application Figure 2 ;

[0044] Figure 5b A schematic diagram of the link for a data query request of the data processing system provided in this application;

[0045] Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application.

[0046] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0047] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0048] First, let’s explain the terms involved in this application:

[0049] Data services refer to the use of various technical means to collect, store, process, analyze, and transmit data in order to meet the data needs of different users in various scenarios and provide them with a service system with valuable data resources and related functions.

[0050] In cloud-based data service architectures, an independent deployment model is often used. For example, rendering data and navigation data have separate data services in the cloud due to their vastly different formats and uses. Each manages its own data version, has different interface styles, lacks correlation and collaboration, and relies on its own operational assurance functions. However, the independent deployment model presents multiple problems. On the one hand, although data services with different data formats are often deployed independently, their interface styles cannot be unified, and they are unrelated, in reality, many data in different formats come from the same source and are related, yet lack effective data version management and control, making it difficult to ensure data consistency. On the other hand, different data services are built independently, each with its own unique interface style and design architecture, making it impossible to achieve unified deployment and consistent interface style in the cloud to provide data services. This brings great inconvenience to both service deployment and operation, as well as to data service users.

[0051] The data processing system provided in the embodiments of the present application obtains data query requests from the target interface through a monitoring service module, determines whether corresponding version data exists based on the interface information in the data processing system registration list, and if so, feeds the target version data back to the vehicle from the data cache cluster and / or target sub-server. The detailed information recorded in the registration list enables effective management and location of data resources. Each sub-server has a clear division of labor, and data acquisition and transmission are carried out under unified cloud framework rules. New sub-servers can be embedded in the overall framework, ensuring framework uniformity while facilitating the management of various data service modes. This solves the problems of lack of data version management and control, inconsistent interface styles, and inconvenient deployment, operation, and maintenance in standalone deployment modes, thereby improving the effectiveness of the data processing system.

[0052] Figure 1 The application scenario diagram of the data processing system provided in this application is as follows: Figure 1 As shown, the specific application scenarios of this application include a data processing system and a vehicle side, wherein the data processing system can be a data processing system, and the vehicle side can be a hardware or software component installed on the vehicle, which can serve as an interface for the vehicle to interact with an external system (such as a data processing system). In the embodiment of this application, the vehicle side can be a vehicle-side server, an on-board computer or an intelligent device, etc., and the data processing system and the vehicle side can be connected via network transmission.

[0053] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0054] Figure 2 Schematic diagram of the data processing system provided in this application Figure 1 ,like Figure 1 As shown, the data processing system includes:

[0055] The first service module is configured to receive a data query request sent from the vehicle end and, based on the data query request, query the target version data corresponding to the data query request from the registration list, where the registration list is used to record the version data in the data cache cluster and the version data in the sub-server;

[0056] The second service module is used to obtain the target version data from the target sub-server in the sub-server according to the data query request when the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster, and send the target version data to the vehicle end and store the target version data in the data cache cluster.

[0057] Among them, the first service module can refer to a module in the data processing system for receiving data query requests sent from the vehicle end and searching for corresponding target version data in the registration list according to these requests. This module is used to manage and monitor the entire data processing system.

[0058] The vehicle side can refer to the client that sends data query requests. The client can be divided into vehicle side engine and external use according to different types. Among them, the vehicle side engine includes positioning module, rendering module and route calculation module, and external use includes web data requests, customer cloud requests and customer vehicle side requests.

[0059] When the vehicle side is in use, the requests from the vehicle side vary depending on the usage. For example, in the positioning module, the vehicle needs to update the location data in real time, and the vehicle side can send a data query request to the data processing system to obtain the latest latitude and longitude coordinates. In the rendering module, when the user switches the map perspective, the vehicle side can send a data query request to the data processing system to request high-definition map rendering data for a specific area. In the route calculation module, after the user sets the destination, the vehicle side can send a data query request to the data processing system to request the shortest path planning data. In the web page data request for external use, the vehicle side can send a data query request to the data processing system to request the web page weather data to be displayed on the in-car screen; in the customer cloud request for external use, the vehicle side can send a data query request to the data processing system for the vehicle's historical driving trajectory data; in the customer vehicle side request, the vehicle side can send a data query request to the data processing system for personal travel record data.

[0060] A data query request is an instruction sent to a data processing system to obtain specific data. The request can specify key information such as the type, scope, and purpose of the data being requested. For example, when a vehicle needs to update its software, it will send a query request to obtain the latest software version information, update instructions, and download link from the data processing system.

[0061] The registration list may refer to a database table or data structure used to record key information. The registration list may be characterized as a "data directory index" for a data processing system, which may list in detail the data format services that have been registered and stored in the data processing system. For example, for map data, it is recorded whether it is a vector map format, a tile map format, or other specific formats; for traffic data, it is noted whether it is a real-time road condition data format, a historical traffic flow data format, etc. At the same time, the registration list also registers the version data corresponding to each data format service, such as version 1.0 and version 1.1 of map data. The version information may include the update time of the data, a summary of the update content, and other content. When a data query request is received, the server can quickly search the registration list to determine whether it has the data format and version that meets the request, and then efficiently respond to the data query and provide accurate data support for the vehicle side.

[0062] In this embodiment of the present application, the first service module may include:

[0063] An interface unit, used to receive a data query request sent from the vehicle end;

[0064] The query unit is used to determine the target version data corresponding to the data query request according to the interface type of the interface unit that receives the data query request, and query the target version data corresponding to the data query request from the registration list.

[0065] The interface unit can refer to the target interface between the vehicle and the data processing system. That is, in this embodiment of the application, the vehicle can send a data query request through the target interface. The target interface can refer to the specific entrance through which the user interacts with the data processing system and initiates a data query request. This interface can be the interface corresponding to the function button set in the vehicle application specifically for initiating a data query. When the user has the need to obtain specific data, he clicks this button, and the vehicle will send a data query request to the monitoring service module in the data processing system through this interface. It can also be an interface for transmitting data query instructions pre-set in the vehicle system background according to a specific communication protocol. As long as the vehicle triggers the data query conditions, such as reaching a specific geographical location or being at a specific time, it will automatically initiate a request to the cloud through this interface. Alternatively, it can be a specific interface used when the vehicle is connected to other external devices to obtain related data. Through this interface, the query request is transmitted to the data processing system, and the required data is obtained. In this embodiment of the application, different data query requests correspond to different target interfaces, and different target interfaces correspond to different vehicle ends.

[0066] After receiving the data query request sent from the vehicle end through the interface unit, the query unit can determine the target version data corresponding to the data query request according to the corresponding target interface through the query unit, and query the target version data corresponding to the data query request from the registration list accordingly.

[0067] That is, in this embodiment of the present application, the registration list may include interface information of the target interface. This interface information may refer to key details used to describe and locate the data service entry in the data processing system. This interface information may include the interface name, interface address, data formats supported by the interface, and interface version number. This interface information is recorded in the registration list. When the data processing system receives a data query request, it can accurately match the request content with the interface information in the registration list and quickly find the corresponding service interface, preparing for the subsequent determination of whether the corresponding version data exists and data transmission.

[0068] For example, when the interface name is "MapDataQueryAPI", the name can be used to determine that the interface is related to map data query; when the interface address is "https: / / xxxxx.com / api / mapdata", the address can be used to clearly indicate where the request should be sent; when the data format supported by the interface is "JSON" or "XML", the format specifications for data transmission and reception are specified; when the interface calling method is GET or POST, it determines how the data query request interacts with the interface; when the interface version number is "v2.0", it can reflect the iteration status of the interface function, among which different versions may differ in functions and data return formats.

[0069] In an embodiment of the present application, by parsing the data query request, key information such as the type, format, and expected version of the data required in the request is clarified. The relevant interfaces are then filtered out from the registration list based on the interface name, and the interface addresses and supported data formats are checked to determine the interface that meets the format requirements. The interface version number is then compared with the expected version number in the request. If they are identical, it can be determined that the data processing system where the interface is located has version data corresponding to the data query request. If no match is found after a series of screening and comparisons, it indicates that the data processing system does not have the corresponding version data.

[0070] In this embodiment of the present application, the first service module may further include a sending unit configured to, when the target version data corresponding to the data query request is not found from the registration list, provide feedback to the vehicle-side indicating a query failure. In this embodiment of the present application, the data cache cluster is configured to, when the first service module finds the target version data corresponding to the data query request from the registration list and the target version data exists in the data cache cluster, send the target version data to the vehicle-side, or send the target version data to the vehicle-side via the first service module.

[0071] A data cache cluster refers to a system consisting of a group of collaborative servers designed to efficiently store and quickly provide copies of frequently accessed data. This means that when a large number of vehicles frequently request certain specific data, such as map data for popular areas or real-time traffic flow data, retrieving it from the original storage location each time would consume significant time and resources. The data cache cluster pre-stores this popular data, as well as frequently queried data in the past, according to specific strategies. For example, map data tiles that have been queried more than a certain number of times in the past week are cached based on factors such as data access frequency and timeliness. When a new data query request arrives and the registration list indicates that the data processing system has the corresponding version of data, the data processing system first searches the data cache cluster. If a matching target version of data is found, it can be directly and quickly fed back to the vehicle. This significantly improves data response speed, reduces vehicle-side waiting time, and enhances the user experience.

[0072] After the target version data corresponding to the data query request is found in the registration list, the data query request can be searched in the data cache cluster and the sub-server in sequence. When the target version data is found in the data cache cluster, the target version data can be sent to the vehicle end.

[0073] When the target version data does not exist in the data cache cluster, the target sub-server that contains the target version data can be determined from multiple sub-servers based on the version information of the requested data in the data query request, and the target version data in the target sub-server can be sent to the vehicle side and stored in the data cache cluster.

[0074] The second service module may refer to a module in the data processing system for processing data query requests and sending data corresponding to the data query requests to corresponding sub-servers. The module is connected to each sub-server so that the corresponding data can be sent to the sub-server for processing.

[0075] A subserver may refer to an independent unit within a data processing system that is used to perform specific data processing and supply tasks. In the data processing system architecture, to meet diverse data format service requirements, in this embodiment, there are two or more subservers distributed across the system. Each subserver includes at least one version of data, and the data version and / or data service type of the version data in different subservers may differ.

[0076] Distributing sub-servers within a data processing system can mean distributing them across different physical locations or virtual spaces within the system, allowing them to collaborate over a network. This distributed setup enhances the flexibility and scalability of the data processing system, enabling it to better handle large-scale data requests.

[0077] And because each sub-server has storage capabilities, that is, it contains at least one version of data, different versions of data can meet the diverse needs of different vehicle terminals in different scenarios. When the vehicle terminal initiates a data query request, the data processing system can quickly call the matching version data from the corresponding distributed sub-server based on the request content, providing accurate and efficient data services for the vehicle terminal.

[0078] The target subserver is a subserver in the data processing system that provides data format services corresponding to data query requests. For example, in the case of map data services, if a user requests high-definition map data for a specific area, the subserver responsible for storing, managing, and providing map data format services is the target subserver.

[0079] When storing the target version data in the data cache cluster, if the data in the data cache cluster is full, it can be updated based on the usage of the data in the data cache cluster, replacing the data with the lowest usage rate or the data with the earliest usage time.

[0080] In this embodiment of the present application, the target sub-server is determined by the second service module according to the data format corresponding to the data query request and the parsing type of the sub-server;

[0081] When the target version data is obtained through the target sub-server, the target sub-server sends the target version data to the vehicle end, or sends the target version data to the vehicle end through the first service module, or sends it to the vehicle end through the second service module and the first service module in sequence.

[0082] The data format corresponding to the data query request can refer to the requested data version, that is, it can refer to the specific version identifier of the data specified in the data query request. It represents the state, structure, content specifications and processing logic of the data at a certain point in time. In different business scenarios and data uses, specific versions of data are required to ensure accuracy and compatibility. For example, in travel data services, early map data may only contain basic road information. With the expansion of map service functions, such as the addition of real-time traffic conditions and street view data, new map data versions will be generated. When the vehicle requests map data, the requested data version will specify the specific status of the required map data, such as whether it contains real-time traffic information and what map rendering style is used, to ensure that the acquired data can meet the specific needs of the vehicle-side application and adapt to the vehicle-side software functions, display interface, etc., so as to provide users with an accurate and expected travel service experience.

[0083] The request data version can be determined by checking the interface documentation to clarify the supported versions and features, checking the version parameters that may be carried in the request header, and analyzing historical request records for reference.

[0084] After determining the requested data version, the data processing system first checks its own data cache cluster. If the data cache cluster contains data of the target version that matches the previously determined requested data version, this target version data is directly fed back to the vehicle, enabling a quick response to the vehicle's request and improving data acquisition efficiency.

[0085] However, if the target version of the data is not found in the data cache cluster, the data processing system will retrieve the target version of the data that matches the requested data from the target sub-server responsible for the corresponding data format service. This ensures that even if the data is not available in the cache cluster, the correct data can be obtained from the source.

[0086] Finally, after obtaining the target version data, the data processing system stores it in the data cache cluster, enabling subsequent requests for the same version to be quickly responded to directly from the cache cluster. Simultaneously, the target version data is fed back to the vehicle through the data cache cluster, completing the entire data query request processing process. This not only ensures that the vehicle's data needs are met, but also optimizes data caching strategies and improves overall service performance.

[0087] After determining the target version of data corresponding to the requested data version from the data processing system's data cache cluster or target sub-server, the data processing system can package and send this data to the vehicle via a stable and reliable network connection in accordance with the established data transmission protocol. After receiving the data, the vehicle will process it according to its own application logic and data parsing rules. For example, in a map application, it will render the received map data on the screen, or in a navigation application, it will use the received road condition data to plan a better route, allowing users on the vehicle to smoothly carry out corresponding travel service operations based on this data.

[0088] In this embodiment of the present application, the sub-server is connected to the first service module, wherein:

[0089] When the version data in the sub-server is updated, the first service module is used to adjust the interface information of the sub-server in the registration list according to the version update notification sent by the sub-server;

[0090] When the sub-server registers or de-registers, the first service module is used to adjust the sub-server information in the registration list according to the registration result or de-registration result of the sub-server.

[0091] When the version data on a sub-server is updated, the sub-server sends a version update notification to the data processing system. Upon receiving the notification, the data processing system adjusts the interface information for the sub-server in the registration list so that when processing subsequent data query requests, it can accurately know the data version and related features currently available on the sub-server.

[0092] When a sub-server in the data processing system is registered or de-registered, the data processing system adjusts the sub-server information in the registration list according to the registration result or de-registration result of the sub-server.

[0093] Sub-server registration refers to the addition of a new sub-server to the data processing system. New sub-servers are deployed when new functional modules or data processing requirements arise. For example, as the Internet of Vehicles (IoV) business expands, a sub-server dedicated to processing vehicle health monitoring data will be needed. After completing initial configuration, it will send a registration request to the data processing system, along with information such as the data format services it can provide, hardware resource availability, and the types of tasks it can handle. The data processing system receives and verifies this information and incorporates it into the management system, completing the registration process.

[0094] Deregistration of a subserver refers to the removal of an existing subserver from the data processing system. This occurs when a subserver is no longer in use due to hardware aging or other reasons. For example, a subserver previously used to process an outdated map data format, when this format is no longer used by the vehicle, will initiate a deregistration request to the data processing system. Upon confirmation, the data processing system removes the subserver from the management list, stops assigning tasks to it, completes the deregistration, and releases related resources.

[0095] In an embodiment of the present application, the first service module may further include a monitoring unit for sending health monitoring instructions to the sub-server according to the registration list, and receiving monitoring results fed back by the sub-server according to the health monitoring instructions, wherein if the monitoring result indicates that the sub-server is abnormal, the abnormal sub-server is controlled to restart. The monitoring unit may send health monitoring instructions to each sub-server based on the sub-server information recorded in the registration list. After receiving the health monitoring instruction, the sub-server will perform a self-check, and the inspection content may include the server's hardware status (such as CPU usage, memory usage, disk space, etc.) and software operation status (such as whether the service process is normal, whether the data processing is accurate and efficient, etc.).

[0096] When monitoring results indicate a sub-server anomaly, such as a persistently high CPU load or a service process crash, the system will restart the abnormal sub-server. This attempt aims to restore the sub-server to normal operation, allowing it to continue providing stable data format services to the vehicle, thus ensuring the stable operation of the entire cloud-vehicle data interaction system.

[0097] In this embodiment of the present application, the target version data obtained from the target sub-server is data converted by the target sub-server through a data converter and adapted to the target interface.

[0098] When obtaining target version data from a target sub-server, the original data in the target sub-server may have format incompatibility or structural mismatches, making it impossible to directly connect to the target interface to respond to data query requests. Therefore, the original data can be processed using a data converter. The data converter converts the format and structure of the original data according to specific rules and algorithms, making it compatible with the data format and parameter settings required by the target interface. This allows the data obtained after the conversion operation to be transmitted through the target interface and can be correctly processed and utilized by subsequent systems, thereby meeting the needs of data query requests initiated by the vehicle end, etc.

[0099] The data processing system provided in the embodiment of the present application can accurately locate the requested data version through the registration list, thus laying a solid foundation for data acquisition. At the same time, by first caching the cluster and then responding to the data in the sub-server, the data transmission efficiency is greatly improved, the waiting time on the vehicle side is reduced, and the integrity and availability of the data are ensured. At the same time, the acquired data is stored in the cache, which optimizes the subsequent query process and further improves the overall performance. Therefore, through the close collaboration of the entire process, the rapid and accurate processing of vehicle-side data requests is achieved, which effectively ensures that the data processing system provides stable and efficient data services to the vehicle side, and significantly improves the user experience of using related data services on the vehicle side.

[0100] Furthermore, the registration list details data format services and version data, enabling quick determination of whether the corresponding version data exists within the data processing system. This enables efficient management and location of data resources, providing clear guidance for subsequent data processing. Version data updates and adjustments ensure data timeliness and accuracy; registration and deregistration expand or streamline data processing system functionality and optimize resource allocation; and health monitoring ensures stable sub-server operation. Each sub-server in the data processing system has a clear division of labor, and data acquisition and transmission adhere to unified cloud framework rules. Based on this foundation, the new data conversion sub-service can be conveniently integrated as a component within the overall conversion service framework. Each sub-service independently handles specific data format services without interfering with each other, yet all adhere to the unified cloud framework management. This not only ensures the integrity of the overall cloud framework, allowing sub-services to focus on their own services while delegating other management operations to the framework, significantly facilitating the management of individual data service models and significantly improving the performance of the data processing system.

[0101] Figure 3 Schematic diagram of the data processing method provided in this application Figure 1 ,like Figure 3 As shown, the data processing method may include:

[0102] S301: Receive a data query request sent from the vehicle end, and query the target version data corresponding to the data query request from the registration list according to the data query request. The registration list is used to record the version data in the data cache cluster and the version data in the sub-server module;

[0103] S302. When the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster, the target sub-server where the target version data exists is determined from multiple sub-servers based on the version information of the requested data in the data query request, and the target version data in the target sub-server is sent to the vehicle end, and the target version data is stored in the data cache cluster.

[0104] The data processing method provided in this embodiment has similar implementation principles and technical effects to those of the above-mentioned system embodiment, and will not be described in detail in this embodiment.

[0105] Figure 4 Schematic diagram of the data processing method provided in this embodiment Figure 2 ,like Figure 4 As shown, the execution subject of the method is the vehicle end of the vehicle, and the data processing method may include:

[0106] S401: Send a data query request to the data processing system, so that the data processing system searches for target version data corresponding to the data query request from a registration list according to the data query request. When the target version data corresponding to the data query request is found in the registration list and the target version data does not exist in the data cache cluster of the data processing system, the target version data is obtained from a target sub-server in the sub-servers according to the data query request, and the target version data is sent to the vehicle end and stored in the data cache cluster.

[0107] S402: Receive and process target version data.

[0108] The data processing method provided in this embodiment has similar implementation principles and technical effects to those of the above-mentioned system embodiment, and will not be described in detail in this embodiment.

[0109] Figure 5a Schematic diagram of the data processing system provided in this application Figure 2 , Figure 5b A schematic diagram of the link for data query requests of the data processing system provided in this application.

[0110] like Figure 5a As shown, the data processing system includes a service and version monitoring unit (first service unit), a data cache cluster, a data adaptation service unit (second service unit), and a data parsing service unit (sub-server), wherein:

[0111] The data parsing service units can be deployed independently on their respective servers. Under the service and version monitoring service system, when a new sub-server is deployed, it is necessary to call the registration interface to complete the registration in the service and version monitoring service; when the old sub-server goes offline, it is necessary to call the corresponding interface to deregister and then go offline. If the sub-server uploads new data, it is necessary to call the registration interface to register the new data version; when the old data version goes offline, it is also necessary to deregister. Because sub-server deployment and data upload involve registration and deregistration operations, the service and version monitoring service can uniformly manage all service and data versions. After the sub-server or data deployment is completed, it can be released uniformly at a specific time point. In this way, multiple sub-services and data versions deployed within a period of time can be synchronized, the deployment and release of services and data can be separated, and different sub-services or data can be uniformly released online according to the progress nodes to provide services to the outside world.

[0112] Since the sub-servers are deployed independently, multiple versions of sub-services can exist at the same time. For example, the rendering data parsing sub-service can have sub-service version 1 and sub-service version 2 at the same time. The advantage is that it can implement blue-green deployment of multiple versions of sub-services in the cloud, and can support multiple versions of sub-services at the same time, avoiding the disadvantage of the old service becoming invalid immediately after the new service is launched.

[0113] Each sub-server includes a data parsing service interface, a data parser, a format converter, and data version management. In the data parsing sub-service, the data parser reads data from the corresponding DB according to the requested data version. The read DB data is deserialized by the format converter to convert the compressed and stored original data into a data format consistent with the cloud interface style and then returned. Deserialization is because the data is compressed into a binary bit stream during storage and needs to be parsed into a readable format. Serialization and deserialization technologies are customized according to the data format, and self-developed tools are usually used. The tool generates code according to the data format structure for data processing. Finally, the converted data is stored in the data cache cluster so that the next same request can hit the cache.

[0114] The deployment of new sub-servers and new data needs to be registered and unregistered in the service and version monitoring service. Therefore, each registered version will be recorded and managed in the service and version monitoring service. The service and version monitoring service will maintain a version management table. When a request reaches the server, it will check whether there is corresponding version information in the table.

[0115] The data cache cluster is a Redis service cluster. Within this cluster, each data format is represented as a library, the data version as a page table, and the layer as the key in each page table. Data retrieved from each sub-cluster is stored as a value. When a request reaches the server, it finds the corresponding data format based on the requested data interface. It then searches the data format library based on the requested data version and primary key. If a corresponding value is found, it is directly returned. If not, the data adapter service is invoked and the request is dispatched to the corresponding sub-service for data parsing.

[0116] The service and version monitoring unit monitors the status of each data parsing sub-service in real time to ensure its healthy operation. New sub-service deployments or the release of new data versions for sub-services are all monitored and managed. When a sub-service is deployed, launched, or taken offline, registration and unregistration are completed by calling the service and version monitoring service's interface to allow for monitoring. After a sub-service is registered, the service and version monitoring service continuously monitors its memory, CPU, and other resource usage. If abnormal resource usage or abnormal termination of a sub-service is detected, the sub-service is immediately restarted or re-started to ensure that the service remains healthy at all times.

[0117] like Figure 5b As shown, the data processing system features a unified data request interface. Upon reaching the cloud, data query requests are first verified by the service and version monitoring system for both the version and the data request format. Format verification is determined by the service interface being called. For example, when requesting a rendering data interface, the data format automatically matches the rendering data format. If the format exists in the management table, verification succeeds; otherwise, it fails. After verification, the data is entered into the cloud data cache cluster and queried using the key-value format of the Redis relational database. If a cache hit is found, the result is directly delivered; otherwise, it is forwarded to the data adaptation service.

[0118] The data adaptation service distributes the request to the corresponding data parsing sub-service according to the request data format.

[0119] For example, Figure 5a As shown, the data processing system has deployed a subservice for rendering data parsing and a subservice for route calculation data parsing. Both subservices have been deployed and registered with the service and version monitoring service. Since data requests are automatically converted to the corresponding data format based on the corresponding data processing system interface after reaching the data processing system, the data adaptation service can directly distribute the data to the corresponding subservice based on the corresponding data format. In other words, if the data request is for the rendering data interface, the data adaptation service will assign it to the rendering data parsing subservice because it is in the rendering format. Each subservice is responsible for parsing different data formats, such as the rendering data parsing and route calculation data parsing subservices that have been deployed in the cloud and registered with the service and version monitoring service.

[0120] Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.

[0121] During the specific implementation process, at least one processor 601 executes the computer-executable instructions stored in the memory 602, so that the at least one processor 601 performs the above method.

[0122] The specific implementation process of the processor 601 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0123] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly executed by a hardware processor or by a combination of hardware and software modules in the processor.

[0124] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk memory.

[0125] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified into address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0126] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0127] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0128] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0129] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in a device as discrete components.

[0130] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0131] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0132] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0133] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0134] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0135] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A data processing system, characterized in that: include: A first service module is configured to receive a data query request sent from a vehicle terminal and, based on the data query request, query a registration list for target version data corresponding to the data query request. The registration list is configured to record version data in the data cache cluster and version data in the sub-server. The second service module is used to obtain the target version data from the target sub-server in the sub-server according to the data query request, send the target version data to the vehicle side, and store the target version data in the data cache cluster when the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster.

2. The system according to claim 1, wherein: Also includes: The data cache cluster is used to send the target version data to the vehicle end, or to send the target version data to the vehicle end through the first service module when the first service module queries the target version data corresponding to the data query request from the registration list and the target version data exists in the data cache cluster.

3. The system according to claim 1, wherein: The first service module includes: An interface unit, configured to receive a data query request sent from the vehicle end; a query unit, configured to determine, according to an interface type of an interface unit that receives the data query request, target version data corresponding to the data query request, and query the target version data corresponding to the data query request from the registration list; And / or, the first service module includes: a monitoring unit, configured to send a health monitoring instruction to the sub-server according to the registration list, and receive a monitoring result fed back by the sub-server according to the health monitoring instruction, wherein if the monitoring result indicates that the sub-server is abnormal, controlling the abnormal sub-server to restart; And / or, the first service module includes: The sending unit is configured to feed back information indicating query failure to the vehicle end when the target version data corresponding to the data query request is not found in the registration list.

4. The system according to any one of claims 1 to 3, characterized in that There are more than two sub-servers and they are distributed. Each sub-server includes at least one version of data. The data versions and / or data service types of the version data in different sub-servers are different.

5. The system according to any one of claims 1 to 3, characterized in that The sub-server is connected to the first service module, wherein, When the version data in the sub-server is updated, the first service module is used to adjust the interface information of the sub-server in the registration list according to the version update notification sent by the sub-server; and / or, When the sub-server is registered or de-registered, the first service module is used to adjust the sub-server information in the registration list according to the registration result or de-registration result of the sub-server.

6. The system according to any one of claims 1 to 3, characterized in that The target sub-server is determined by the second service module according to the data format corresponding to the data query request and the parsing type of the sub-server; and / or, When the target version data is obtained through the target sub-server, the target sub-server is used to send the target version data to the vehicle end, or send the target version data to the vehicle end through the first service module, or send it to the vehicle end through the second service module and the first service module in sequence.

7. A data processing method, characterized in that: The method comprises: Receive a data query request sent from the vehicle end, and query the target version data corresponding to the data query request from the registration list according to the data query request, wherein the registration list is used to record the version data in the data cache cluster and the version data in the sub-server module; When the target version data corresponding to the data query request is queried from the registration list and the target version data does not exist in the data cache cluster, the target version data is obtained from the target sub-server in the sub-server according to the data query request, and the target version data is sent to the vehicle end, and the target version data is stored in the data cache cluster.

8. A data processing method, characterized in that: Applied to vehicle side, including: Sending a data query request to a data processing system, so that the data processing system searches for target version data corresponding to the data query request from a registration list according to the data query request; when the target version data corresponding to the data query request is found from the registration list and the target version data does not exist in a data cache cluster of the data processing system, obtaining the target version data from a target sub-server in the sub-servers according to the data query request, sending the target version data to the vehicle end, and storing the target version data in the data cache cluster; The target version data is received and processed.

9. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to claims 7-8.

10. A computer-readable storage medium / computer program product, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to claims 7-8 when executed by a processor; and / or, The computer program product comprises a computer program, which implements the method according to claims 7-8 when executed by a processor.

Images