A method and related apparatus for querying vehicle data

Abstract

This application discloses a vehicle data query method and related apparatus, applicable to the mapping field. Instead of actively acquiring and batch-processing the location information uploaded by the device at fixed intervals, this application passively receives location information in real time and processes it line by line. If the location information determines that the vehicle of the device is within the target geographical area, the vehicle data is retrieved from the database based on the device identifier. If a query request is received at the target time, the system outputs the vehicle data acquired within a target time period (ending at the target time) for a preset duration. Based on the vehicle data acquired within the target time period, the characteristics of vehicle users are analyzed, and decisions favorable to the target geographical area at the target time are made. Therefore, by passively receiving location information and processing it in real time, there is no need to start the Spark offline program, reducing processing time.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method and apparatus for querying vehicle data. Background Technology

[0002] Vehicle data consists of multiple features of a vehicle, and the output is usually a detailed description of those features, which can also be understood as a set of labels composed of multiple tags. For example, vehicle A's data might include "mid-size car," "new," "used car," and "Beijing." Targeted geographical areas such as scenic spots can use vehicle data to identify the needs of vehicle users and then attract tourists by meeting those needs.

[0003] In related technologies, vehicle data within the scenic area is read at fixed intervals (e.g., every hour) using Spark (a computing framework), and then marketing strategies for the scenic area are dynamically optimized based on this data. However, this method is time-consuming. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a vehicle data query method and related apparatus to reduce time consumption.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] On one hand, embodiments of this application provide a vehicle data query method, the method comprising:

[0007] Real-time reception of location information, which is uploaded by the positioning device at the time of positioning;

[0008] If it is determined from the location information that the positioning device is located within the target geographical area, vehicle data is retrieved from the database based on the device identifier of the positioning device.

[0009] If a query request is received at the target time, the vehicle data obtained within the target time period is output based on the location time. The duration of the target time period is a preset duration, and the end time of the target time period is the target time.

[0010] On the other hand, embodiments of this application provide a vehicle data query device, the device comprising: a receiving unit, an acquiring unit, and an output unit;

[0011] The receiving unit is used to receive location information in real time, which is uploaded by the positioning device at the time of positioning.

[0012] The acquisition unit is configured to, if it is determined from the location information that the positioning device is located in the target geographical area, retrieve vehicle data from the database based on the device identifier of the positioning device, wherein the vehicle data is used to identify the characteristics of the user of the positioning device;

[0013] The output unit is configured to, if a query request is received at a target time, output the vehicle data obtained within a target time period based on the positioning time, wherein the duration of the target time period is a preset duration, and the end time of the target time period is the target time.

[0014] On the other hand, embodiments of this application provide a computer device, the device including a processor and a memory:

[0015] The memory is used to store program code and transmit the program code to the processor;

[0016] The processor is configured to execute the methods described above according to instructions in the program code.

[0017] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program for performing the methods described above.

[0018] On the other hand, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described above.

[0019] As can be seen from the above technical solution, instead of actively acquiring and batch-processing the location information uploaded by the positioning device at fixed intervals, the solution passively receives location information in real time and processes it one by one. If the location information determines that the vehicle of the positioning device is within the target geographical area, the vehicle data is retrieved from the database based on the device identifier of the positioning device. If a query request is received at the target time, the solution outputs the vehicle data acquired within a target time period with the target time as the end time and a preset duration. Based on the vehicle data acquired within the target time period, the characteristics of vehicle users are analyzed to make decisions that are beneficial to the target geographical area at the target time. Therefore, by passively receiving and processing location information in real time, there is no need to start the Spark offline program, thus reducing the time consumption. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of a vehicle data query method;

[0022] Figure 2 This is a schematic diagram of a vehicle data query system provided in an embodiment of this application;

[0023] Figure 3 A flowchart illustrating a vehicle data query method provided in an embodiment of this application;

[0024] Figure 4 A geofence targeting the China Technology Exchange Building;

[0025] Figure 5 A schematic diagram illustrating a statistical result provided in an embodiment of this application;

[0026] Figure 6 A schematic diagram of a real-time Flink architecture provided for an embodiment of this application;

[0027] Figure 7 A flowchart illustrating a vehicle data query method provided in an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the structure of a vehicle data query device provided in an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of the server structure provided in an embodiment of this application;

[0030] Figure 10 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0031] The embodiments of this application will now be described with reference to the accompanying drawings.

[0032] Among related technologies, offline big data computation is performed at fixed intervals using Spark. The following section combines... Figure 1 Explanation will be provided. In Figure 1In this process, the positioning device collects the location information of the object and uploads it to the offline Hadoop Distributed File System (HDFS) for storage. Then, Spark is started every hour to perform offline big data computing. That is, based on the device ID of the positioning device, the vehicle data corresponding to the device ID is obtained from the offline vehicle database. Finally, the corresponding calculations are performed based on the vehicle data obtained in that hour, and the results are stored on disk. Finally, marketing strategies for scenic spots are formulated and dynamically optimized based on the results.

[0033] Research has revealed that while this method has the advantage of easy replay of Spark offline program failures (meaning that if the Spark offline program encounters a problem, the data will not be lost because it exists offline), starting the Spark offline program takes a significant amount of time, resulting in long query times (e.g., tens of minutes). Therefore, this application provides a vehicle data query method and related apparatus to reduce query time.

[0034] The vehicle data query method provided in this application can be applied to... Figure 2 The vehicle data query system shown in the figure includes a server and terminal devices. The server involved in this application can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, smart speakers, smartwatches, in-vehicle terminals, etc., but are not limited to these. Terminals and servers can be directly or indirectly connected via wired or wireless communication, which is not limited herein. The number of servers and terminal devices is also not limited.

[0035] For example, a terminal device, acting as a positioning device for determining a vehicle's location, collects the vehicle's location information at the positioning time and uploads it to the server. For one terminal device A, if the server determines, based on the location information uploaded by terminal device A, that the vehicle using terminal device A is within the target geographical area, it retrieves the vehicle data corresponding to device identifier A from the database. Thus, the server achieves real-time processing of each piece of location information uploaded by each terminal device. If a query request is received at the target time, based on the positioning time, it outputs the vehicle data acquired within a target time period with the target time as the end time and a preset duration. Based on the vehicle data acquired within the target time period, a decision favorable to the target geographical area at the target time is made. Therefore, by passively receiving location information and processing it in real time, there is no need to start an offline Spark program, reducing processing time.

[0036] Given that this application involves some technical terms, these terms will be introduced below.

[0037] (1) Offline computing: also known as "batch processing," refers to the processing of static data in batches with relatively high latency. Offline computing is suitable for scenarios with low real-time requirements, such as offline reporting and data analysis. Latency is generally in the minutes or hours range. In most scenarios, a job task is executed periodically at set intervals. The task cycle can be as short as minutes, such as performing statistical analysis every five minutes, or as long as monthly or yearly, such as executing a task once a month. MapReduce is an offline computing framework, and Spark SQL is also commonly used for offline computing tasks.

[0038] (2) Real-time computing: also known as "real-time stream computing" or "streaming computing," refers to real-time or low-latency streaming data processing. Real-time computing is typically used in scenarios with high real-time requirements, such as real-time ETL, where latency is generally in the millisecond range or even lower. Currently popular real-time frameworks include Spark Streaming and Flink. Spark Streaming is a micro-batch processing engine that treats streams as batches, offering very high throughput but also relatively high latency, which limits its application scenarios. Flink, on the other hand, is an event-driven stream processing engine that treats batches as finite streams, offering high throughput, low latency, and high performance.

[0039] (3) Flink: A distributed computing engine for big data. It can be used for batch processing, i.e., processing static datasets and historical datasets; it can also be used for stream processing, i.e., processing real-time data streams and generating data results in real time. In 2014, it provided a high-throughput, low-latency data stream processing engine. By supporting event-time and computation state, as well as exactly-once fault tolerance guarantee, it became a new generation of stream computing processing engine and gradually replaced JStorm and Spark Streaming as a new real-time computing framework.

[0040] (4) Flink CheckPoint technology: Unlike JStorm, Flink is a stateful real-time computation. Stateful computation can store intermediate data in memory. CheckPoint technology specifically implements this function. It will periodically synchronize the data in Flink memory to the cluster disk. When an operator fails for some reason (such as abnormal exit) or Flink restarts, it can read the data saved by CheckPoint and restore the state of the entire application flow graph to a state before the failure.

[0041] The following description, in conjunction with the accompanying drawings, uses an example of a vehicle data query method provided in an embodiment of this application executed by a server.

[0042] See Figure 3 This figure is a flowchart illustrating a vehicle data query method provided in an embodiment of this application. Figure 3 As shown, the vehicle data query method may include S301-S304.

[0043] S301: Receives location information in real time.

[0044] In practical applications, vehicles are equipped with onboard terminals and carry positioning devices such as smartphones and smart speakers. These devices continuously collect the vehicle's location information and upload it to a server. For example, vehicle A's onboard terminal (i.e., positioning device) might collect its current location (i.e., location information) at 12:00 on December 14, 2021 (the location time) and upload it to the server. Understandably, in most cases, the location of the vehicle's onboard positioning device can be considered the vehicle's actual location.

[0045] Compared to related technologies where the server actively acquires offline location information at fixed time intervals based on Spark, this embodiment passively receives location information uploaded by the positioning device and processes it in real time, or in other words, processes each piece of location information in real time. Since the real-time program runs continuously, there is no delay similar to starting an offline Spark program, thus reducing processing time.

[0046] As one possible implementation, the positioning device can upload a positioning log, which includes at least the positioning device identifier, the positioning time, and positioning information. The positioning device identifier uniquely identifies the positioning device, such as its device ID. The positioning time is the point in time when the positioning information was collected, and the positioning information identifies the current location of the positioning device, such as latitude and longitude.

[0047] Furthermore, the positioning device can upload positioning logs to a message queue, such as Kafka. Kafka is a distributed, publish / subscribe-based messaging system with powerful message processing capabilities. Compared to other messaging systems, it has the following characteristics: (1) Fast data persistence, achieving O(1) time complexity for data persistence. (2) High throughput, reaching a throughput rate of 100,000 messages per second on ordinary servers. (3) High reliability, with message persistence and replication mechanisms ensuring message reliability, allowing messages to be consumed multiple times.

[0048] Therefore, Kafka allows location logs to be stored in a message queue until they are retrieved from the queue for further processing. New location logs are continuously appended to the end of the local disk file, rather than being written randomly. The message queue uses sequential read / write to improve performance, breaking the performance bottleneck caused by random disk read / write and thus reducing processing time.

[0049] S302: If the device is determined to be within the target geographical area based on the location information, retrieve vehicle data from the database based on the device identifier of the location device.

[0050] The target geographic area is a pre-defined geofence, such as within a scenic area or a shopping mall. A geofence is a new application based on Location Based Services (LBS), which uses a virtual fence to enclose a virtual geographic boundary. It serves as a statistical record of when a location device enters, leaves, or moves within a specific geographic area. Simply put, it can be understood as a custom area on a map. Figure 4 The image shown is a geofence of the China Technology Exchange Building.

[0051] After obtaining a location information, it is determined whether the location device is within the target geographical area. If so, the vehicle using the location device can be considered to be within the target geographical area as well. This vehicle is a useful object for analyzing vehicle users within the target geographical area. Therefore, vehicle data can be obtained from the database to analyze the characteristics of vehicle users within the target geographical area and formulate marketing strategies targeting vehicle users within the target geographical area.

[0052] This application does not specifically limit the database storage medium to include hard drives or memory. Analysis revealed that other reasons for the high time consumption in related technologies include the acquisition of a large amount of location information every hour, requiring the traversal of all location information to find the device ID in the target geographical area; this data is read from the disk. As a possible implementation, if the database storage medium is memory, such as Memcached or Redis, the data reading method becomes memory reading, which is faster than disk reading and reduces time consumption.

[0053] As one possible implementation, when the database storage medium is memory, if the vehicle data query process (or real-time program) encounters an anomaly, the real-time location information receiving method is not as stable as the offline location information receiving method. The real-time location information is lost after it is consumed, resulting in the inability to trace the data. Once an abnormal interruption occurs, some location information will be lost, leading to inaccurate vehicle data query results.

[0054] Based on this, the embodiments of this application introduce a savepoint. Specifically, a savepoint period is preset, and the device identifier and vehicle data are associated and stored in an offline database according to the savepoint period. If an abnormality occurs during the vehicle data query process, the lost device identifier and vehicle data are retrieved from the offline database.

[0055] The following example uses a Redis database. If the real-time program malfunctions or encounters an error, the previously received location information cannot be retrieved upon restart, nor can the lost location information be recovered from subsequently received location information. After setting a one-minute save point period, the consumed location information will be stored in the offline database every minute. It should be noted that the consumed location information will obtain a device identifier and the corresponding vehicle data. That is, every minute, the device identifier and vehicle data are associated and stored in the offline database so that it can be traced back if the real-time program malfunctions.

[0056] One possible implementation is to use the device identifier as the key field and the corresponding vehicle data as the value field, storing them in an offline database using a hash structure. Among methods of querying the value field based on the key field, the hash structure offers the fastest query efficiency, at O(1) level. This can further improve query efficiency during backtracking.

[0057] It should be noted that an offline database can be an independent database or a sub-database of a database whose storage medium is memory; this application does not make any specific limitations on this.

[0058] S303: If a query request is received at the target time, output the vehicle data obtained within the target time period based on the positioning time.

[0059] The target time period is a preset duration, and the end time of the target time period is the target time.

[0060] For example, to obtain user demand for a target geographic area, a query request can be sent through a vehicle data query system. The server receives the query request at 11:38 and, based on the location time, outputs all vehicle data obtained by the server between 10:38 and 11:38. Based on the vehicle data within this one-hour period, the characteristics of vehicle users in the target geographic area can be analyzed, and targeted marketing strategies suitable for the target geographic area at 11:38 can be developed. It is understood that in this embodiment, the preset duration is one hour, and the target time is 11:38.

[0061] It should be noted that in the specific embodiments of this application, data such as vehicle data, location information, and location logs are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0062] As can be seen from the above technical solution, the vehicle data query method provided in this application no longer actively acquires the location information uploaded by the positioning device at fixed intervals for batch processing. Instead, it passively receives the location information in real time and processes it one by one. If the positioning information determines that the vehicle of the positioning device is in the target geographical area, the vehicle data is retrieved from the database based on the device identifier of the positioning device. If a query request is received at the target time, the vehicle data obtained within the target time period with the target time as the end time and a preset duration is output. Based on the vehicle data obtained within the target time period, the characteristics of the vehicle users are analyzed, and a decision favorable to the target geographical area at the target time is made. Thus, by passively receiving the location information and processing it in real time, there is no need to start the Spark offline program, reducing the time consumption.

[0063] As one possible implementation, in step S302, if the device is determined to be within the target geographical area based on the location information, before retrieving vehicle data from the database based on the device identifier of the location device, it can be first determined whether vehicle data has been retrieved based on that device identifier. Specifically, if it is determined based on the device identifier of the location device that it does not exist in the association set, step S302 is executed; if it is determined based on the device identifier of the location device that it exists in the association set, step S302 is not executed, and the process ends. Thus, the already associated device identifier and vehicle data are cached in the association set. If a device identifier already stored in the association set is subsequently received, since the vehicle data corresponding to that device identifier has already been retrieved, there is no need to query the database for vehicle data again, further reducing processing time.

[0064] It should be noted that the associated set can store only device identifiers and their corresponding vehicle data obtained within a preset time period. This not only saves storage resources but also allows the cached vehicle data in the associated set to be directly output upon receiving subsequent query requests. For example, the associated set can cache not only the received device identifiers and their corresponding vehicle data, but also, if the preset time period is one hour and the current time is 12:00, the associated set can clear the device identifiers and their corresponding vehicle data stored before 11:00 based on the location time.

[0065] One possible approach is to perform statistical analysis based on the output vehicle data, and even visualize the results. For example, based on the vehicle data, the ratio of commercial vehicles to private cars within the target geographical area at a target time could be 40%:60%. Figure 5As shown. It should be noted that this application does not specifically limit the statistical results obtained. Taking scenic spots as an example, it is possible to obtain statistics on the top 20 cities of origin for tourists nationwide, analysis of the hometowns of tourists, the top 20 cities outside the province of origin for tourists, analysis of the city of origin for tourists, or age analysis of tourist data, etc.

[0066] Next, we will combine Figure 6 and Figure 7 Taking an application scenario as an example, the vehicle data query method provided in this application embodiment will be described. In this application embodiment, the server continues to be the execution entity, and the server includes a Flink real-time architecture for executing the vehicle data query method provided in this application embodiment.

[0067] See Figure 6 This figure is a schematic diagram of a real-time Flink architecture provided in an embodiment of this application. Figure 6 As shown, the Flink real-time architecture includes a real-time message channel layer, a real-time computing layer, and a storage layer, which will be described below.

[0068] In practical applications, tourists in scenic areas may drive to the area. The vehicle terminal (positioning device) will upload the vehicle's positioning information through the Global Positioning System (GPS). Alternatively, vehicle users may carry smartphones (positioning devices). When the smartphone has a positioning software development kit (SDK) application (APP) installed, if there is a positioning scenario (such as arriving at the scenic area through map navigation), it will call the SDK to collect the vehicle's current positioning information through the positioning service and upload the generated positioning log to the server in real time.

[0069] The real-time message channel layer in the Flink real-time architecture of the server is responsible for receiving location logs uploaded by the location device in real time. After receiving the location logs, it stores them in a message queue and continuously pushes new location logs to the real-time computing layer (or the Flink program). The format of the location log is <Device ID, Location Latitude and Longitude, Location Time>.

[0070] It should be noted that the location logs are approximately 1 million per second, and around 100 billion per day. The advantage of the real-time message channel layer built using Kafka is that it provides message persistence with a time complexity of O(1), ensuring constant-time access performance even for data exceeding terabytes; its distributed architecture supports online horizontal scaling. It can support high queries per second (QPS) and high scalability, suitable for the current situation of receiving a large number of location logs.

[0071] The real-time computing layer built with Flink also includes five sub-layers, which are described below. Figure 7 Each sub-layer will be explained separately.

[0072] See Figure 7 The figure is a flowchart of a real-time calculation provided in an embodiment of this application.

[0073] After receiving a new location log, the first sub-layer determines whether the vehicle is within the scenic area. Specifically, when the vehicle is parked in or near the scenic area, the onboard terminal uploads a location log, and the latitude and longitude coordinates included in the log are used for determination. It can be understood that the target geographic area can be set as the scenic area, or an area within three kilometers of the scenic area. This embodiment uses the scenic area as the target geographic area. If the vehicle is within the scenic area, the calculation of the second sub-layer continues; if the vehicle is not within the scenic area, the location log is discarded and no further processing is performed. It should be noted that there are many methods in GIS for determining whether a point is within a region, such as the traditional ray casting method.

[0074] The second sub-layer determines whether the location device ID (the ID of the vehicle terminal) is in the associated set, that is, whether the vehicle data of the vehicle has been obtained based on the location device ID. If yes, the location log is discarded to reduce the time spent on the query; otherwise, the calculation of the third sub-layer continues.

[0075] It should be noted that the associated set maintains a<key,value> The hash structure uses the location device ID as the key and the corresponding vehicle data as the value, such as {"Device ID1": "Commercial vehicle, around 1 million, from Lüliang City, Shanxi Province, ..."; "Device ID2": "Family vehicle, around 100,000, from Huangpu District, Shanghai Province, ..."}. This structure is maintained for each region within each statistical period and is cleared when it becomes outdated.

[0076] The third sub-layer determines whether vehicle data corresponding to the location device ID is found. That is, it retrieves the vehicle data corresponding to the location device from the real-time Redis database based on the location device ID obtained from the second sub-layer. If yes, the calculation of the fourth sub-layer continues; otherwise, the location log is discarded.

[0077] It should be noted that the real-time Redis database uses memory as its storage medium, and it retrieves vehicle data from an offline vehicle database that uses disk storage, and updates it periodically.

[0078] The fourth sub-layer updates the association set, that is, it associates the location device ID and its corresponding vehicle data obtained from the third sub-layer and stores them in the association set.

[0079] It's worth noting that the system can also determine if a savepoint period has arrived. If so, it saves the associated set. Specifically, at each savepoint period (e.g., once every minute), the obtained hash structure data is checked and saved to HDFS on the Flink cluster. This solves the problem of not being able to retrieve consumed data when real-time computing restarts.

[0080] The fifth sub-layer determines whether the statistical period has arrived. This period can be set according to a preset duration, such as triggering the server to receive query requests at preset intervals. If so, it outputs the vehicle data acquired within the statistical period. Furthermore, it can output the required statistical results based on preset settings. For example, when the one-hour statistical period arrives, it only needs to iterate through the corresponding associated set once, calculate the data for all vehicles (e.g., 10 commercial vehicles and 100 family cars), obtain the statistical results, and display them.

[0081] The storage layer is used to store the results of real-time calculations, ensuring the results are written to disk. For example, a scenic spot can be used as a storage unit, with the storage format being data category: <Label 1, Quantity 1>, <Label 2, Quantity 2>, etc. For example, vehicle type data: <Commercial Vehicle, 10 people>, <Family Vehicle, 100 people>.

[0082] The drawback of offline big data computing is its long processing time. If the volume of location logs or vehicle data is large, it can often take tens of minutes or even hours to output the data from the previous hour. This solution utilizes Flink for real-time computing, caching intermediate results every second, allowing the output of the previous hour's data to be completed within seconds. Specifically, experiments show that for one hour of vehicle data acquired from a scenic area, related technologies typically take about 10 minutes to provide the previous hour's vehicle data. The technical solution provided in this application can provide the previous hour's vehicle data in approximately 3-5 seconds.

[0083] As can be seen from the above technical solution, firstly, by leveraging Flink's real-time big data computing capabilities and location log analysis from LBS location big data, real-time computing replaces the previous offline computing. Combined with Kafka message channels and Redis databases, the real-time performance of data computing is significantly improved, enabling hourly data statistics to be output at the second level. The optimization is mainly done in three aspects: First, because the real-time program runs continuously, there is no latency like that of offline service startup. Second, location logs are received from Kafka in real-time, processed in a streaming manner, and the location device IDs within the scenic area are retained for the next layer, while those outside the scenic area are discarded. Third, offline vehicle data files are cached in Redis, allowing real-time retrieval of Redis data results for each location device ID received from the previous step, avoiding the long latency caused by disk reads. Secondly, through Flink and CheckPoint technology, the cached data results within the hour are periodically saved from memory to the cluster disk. When the Flink program restarts normally or abnormally, the state before the restart can be instantly restored, ensuring data continuity. Finally, combined with visualization components, it is possible to quickly gain insights into the origin, gender, age, preferences, and other attributes of most tourists within the scenic area, which plays a very important role in determining the placement of advertisements within the scenic area and the location of services around the park.

[0084] In addition to the vehicle data query method provided in the above embodiments, this application also provides a vehicle data query device.

[0085] See Figure 8 This figure is a schematic diagram of a vehicle data query device provided in an embodiment of this application. Figure 8 As shown, the vehicle data query device 800 includes: a receiving unit 801, an acquiring unit 802, and an output unit 803;

[0086] The receiving unit 801 is used to receive positioning information in real time, the positioning information being uploaded by the positioning device at the positioning time;

[0087] The acquisition unit 802 is used to acquire vehicle data from the database based on the device identifier of the positioning device if it is determined from the positioning information that the positioning device is located in the target geographical area.

[0088] The output unit 803 is configured to, if a query request is received at a target time, output the vehicle data obtained within a target time period based on the positioning time, wherein the duration of the target time period is a preset duration, and the end time of the target time period is the target time.

[0089] As one possible implementation, the receiving unit 801 is configured to:

[0090] The system receives location logs actively pushed from a message queue in real time. The location logs include the location device identifier, the location time, and the location information.

[0091] As one possible implementation, the database is stored in memory.

[0092] As one possible implementation, the device further includes a setting unit, a storage unit, and a backtracking unit;

[0093] The setting unit is used to set the save point period;

[0094] The storage unit is used to associate and store the device identifier and the vehicle data in an offline database according to the storage point period;

[0095] The backtracking unit is used to backtrack the lost device identifier and vehicle data from the offline database if an anomaly occurs during the vehicle data query process.

[0096] As one possible implementation, the storage unit is used for:

[0097] The device identifier is used as the key field, and the vehicle data corresponding to the device identifier is used as the value field. These are then stored in the offline database using a hash structure.

[0098] As one possible implementation, the device further includes a deduplication unit for:

[0099] If it is determined that the device identifier of the positioning device does not exist in the association set, the step of retrieving vehicle data from the database based on the device identifier of the positioning device is executed. The association set caches the device identifier and the corresponding vehicle data of the vehicle data retrieved from the database.

[0100] If it is determined that the device identifier of the positioning device exists in the association set based on the device identifier of the positioning device, the step of retrieving vehicle data from the database based on the device identifier of the positioning device will no longer be executed.

[0101] As can be seen from the above technical solution, the vehicle data query method provided in this application no longer actively acquires the location information uploaded by the positioning device at fixed intervals for batch processing. Instead, it passively receives the location information in real time and processes it one by one. If the positioning information determines that the vehicle of the positioning device is in the target geographical area, the vehicle data is retrieved from the database based on the device identifier of the positioning device. If a query request is received at the target time, the vehicle data obtained within the target time period with the target time as the end time and a preset duration is output. Based on the vehicle data obtained within the target time period, the characteristics of the vehicle users are analyzed, and a decision favorable to the target geographical area at the target time is made. Thus, by passively receiving the location information and processing it in real time, there is no need to start the Spark offline program, reducing the time consumption.

[0102] This application also provides a computer device, which is the aforementioned computer device. This computer device can be a server or a terminal device. The aforementioned vehicle data query device can be built into the server or terminal device. The computer device provided in this application will be described below from a hardware implementation perspective. Figure 9 The diagram shown is a structural schematic of the server. Figure 10 The diagram shown is a structural schematic of the terminal device.

[0103] See Figure 9 , Figure 9 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1400 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 1422 (e.g., one or more processors) and a memory 1432, and one or more storage media 1430 (e.g., one or more mass storage devices) for storing application programs 1442 or data 1444. The memory 1432 and storage media 1430 can be temporary or persistent storage. The program stored in the storage media 1430 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the server. Furthermore, the CPU 1422 may be configured to communicate with the storage media 1430 and execute the series of instruction operations in the storage media 1430 on the server 1400.

[0104] Server 1400 may also include one or more power supplies 1426, one or more wired or wireless network interfaces 1450, one or more input / output interfaces 1458, and / or one or more operating systems 1441, such as Windows Server. TMMac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0105] The steps performed by the server in the above embodiments can be based on this Figure 9 The server structure shown.

[0106] CPU 1422 is used to perform the following steps:

[0107] Real-time reception of location information, which is uploaded by the positioning device at the time of positioning;

[0108] If it is determined from the location information that the positioning device is located within the target geographical area, vehicle data is retrieved from the database based on the device identifier of the positioning device.

[0109] If a query request is received at the target time, the vehicle data obtained within the target time period is output based on the location time. The duration of the target time period is a preset duration, and the end time of the target time period is the target time.

[0110] Optionally, CPU 1422 may also execute method steps of any specific implementation of the vehicle data query method in the embodiments of this application.

[0111] See Figure 10 , Figure 10 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Figure 10 This diagram illustrates a partial structure of a smartphone related to the terminal device provided in this embodiment. The smartphone includes components such as a radio frequency (RF) circuit 1510, a memory 1520, an input unit 1530, a display unit 1540, a sensor 1550, an audio circuit 1560, a Wi-Fi module 1570, a processor 1580, and a power supply 1590. Those skilled in the art will understand that... Figure 10 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0112] The following is combined Figure 10 A detailed introduction to the various components of a smartphone:

[0113] RF circuit 1510 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 1580; additionally, it transmits uplink data to the base station. Typically, RF circuit 1510 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), and a duplexer. Furthermore, RF circuit 1510 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Messaging Service (SMS).

[0114] The memory 1520 can be used to store software programs and modules. The processor 1580 executes the software programs and modules stored in the memory 1520 to realize various functions and data processing of the smartphone. The memory 1520 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1520 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0115] The input unit 1530 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the smartphone. Specifically, the input unit 1530 may include a touch panel 1531 and other input devices 1532. The touch panel 1531, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 1531), and drive the corresponding connected devices according to a pre-set program. Optionally, the touch panel 1531 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1580, and can also receive and execute commands sent by the processor 1580. In addition, the touch panel 1531 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1531, the input unit 1530 may also include other input devices 1532. Specifically, other input devices 1532 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0116] Display unit 1540 can be used to display information input by the user or information provided to the user, as well as various menus of the smartphone. Display unit 1540 may include display panel 1541, optionally configured as a Liquid Crystal Display (LCD), Organic Light-Emitting Diode (OLED), or similar display panel 1541. Further, touch panel 1531 may cover display panel 1541. When touch panel 1531 detects a touch operation on or near it, it transmits the information to processor 1580 to determine the type of touch event. Subsequently, processor 1580 provides corresponding visual output on display panel 1541 based on the type of touch event. Although in Figure 10 In this embodiment, the touch panel 1531 and the display panel 1541 are two separate components to realize the input and output functions of the smartphone. However, in some embodiments, the touch panel 1531 and the display panel 1541 can be integrated to realize the input and output functions of the smartphone.

[0117] Smartphones may also include at least one sensor 1550, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 1541 according to the ambient light level, and the proximity sensor can turn off the display panel 1541 and / or the backlight when the smartphone is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes) and can detect the magnitude and direction of gravity when stationary. It can be used for applications that recognize the smartphone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometers, taps), etc. Other sensors that smartphones may also be equipped with, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0118] Audio circuit 1560, speaker 1561, and microphone 1562 provide an audio interface between the user and the smartphone. Audio circuit 1560 converts received audio data into electrical signals and transmits them to speaker 1561, where speaker 1561 converts them into sound signals for output. On the other hand, microphone 1562 converts collected sound signals into electrical signals, which are received by audio circuit 1560, converted into audio data, and then processed by processor 1580 before being transmitted via RF circuit 1510 to, for example, another smartphone, or the audio data can be output to memory 1520 for further processing.

[0119] WiFi is a short-range wireless transmission technology. Smartphones using the WiFi module 1570 can help users send and receive emails, browse web pages, and access streaming media, providing wireless broadband internet access. Although Figure 10 WiFi module 1570 is shown, but it is understood that it is not an essential component of a smartphone and can be omitted as needed without changing the nature of the invention.

[0120] The processor 1580 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1520 and by accessing data stored in the memory 1520. Optionally, the processor 1580 may include one or more processing units; preferably, the processor 1580 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1580.

[0121] The smartphone also includes a power supply 1590 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 1580 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0122] Although not shown, smartphones may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0123] In this embodiment of the application, the memory 1520 included in the smartphone can store program code and transmit the program code to the processor.

[0124] The processor 1580 included in the smartphone can execute the vehicle data query method provided in the above embodiments according to the instructions in the program code.

[0125] This application also provides a computer-readable storage medium for storing a computer program for executing the vehicle data query method provided in the above embodiments.

[0126] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle data query method provided in the various optional implementations of the above aspects.

[0127] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium can be at least one of the following media: read-only memory (ROM), RAM, magnetic disk, or optical disk, etc., and other media capable of storing program code.

[0128] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the 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 the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0129] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for querying vehicle data, characterized in that, The method, applied to real-time reception of location information and real-time subsequent processing, includes: Through the real-time information channel layer in the Flink real-time architecture, location logs actively pushed from the message queue are received in real time. The location logs include the location device identifier, the location time, and the location information, which is uploaded by the location device at the location time. If the positioning device is determined to be within the target geographical area based on the positioning information, the device identifier is used to determine whether the device identifier exists in the association set. The association set caches the device identifier and the corresponding vehicle data obtained from the database. The storage medium of the database is memory. The target geographical area is used as a statistical carrier when the positioning device enters or leaves a specific geographical area, or when it is active in the area. If so, discard the location information; If not, retrieve vehicle data from the database based on the device identifier of the positioning device; If a query request is received at the target time, the vehicle data obtained within the target time period is output based on the location time. The characteristics of vehicle users in the target geographical area are analyzed based on the vehicle data within the target geographical area during the target time period. The duration of the target time period is a preset duration, and the end time of the target time period is the target time.

2. The method according to claim 1, characterized in that, The method further includes: Set the savepoint cycle; Based on the storage point period, the device identifier and the vehicle data are associated and stored in an offline database; If an anomaly occurs during the vehicle data query process, the lost device identifier and vehicle data will be retrieved from the offline database.

3. The method according to claim 2, characterized in that, The step of associating and storing the device identifier and the vehicle data in an offline database includes: The device identifier is used as the key field, and the vehicle data corresponding to the device identifier is used as the value field. These are then stored in the offline database using a hash structure.

4. A vehicle data query device, characterized in that, The device is used for real-time reception of location information and real-time subsequent processing, and includes: a receiving unit, an acquisition unit, and an output unit; The receiving unit is used to receive location logs actively pushed from the message queue in real time through the real-time information channel layer in the Flink real-time architecture. The location logs include the location device identifier, the location time, and the location information, which is uploaded by the location device at the location time. The acquisition unit is configured to, if the positioning device is determined to be within a target geographical area based on the positioning information, determine whether the device identifier exists in an association set based on the device identifier, wherein the association set caches device identifiers and corresponding vehicle data obtained from the database; if yes, discard the positioning information; otherwise, obtain vehicle data from the database based on the device identifier of the positioning device, wherein the vehicle data is used to identify the characteristics of the user of the positioning device, the database is stored in memory, and the target geographical area is used as a statistical carrier when the positioning device enters or leaves a specific geographical area, or is active within that area; The output unit is configured to, if a query request is received at a target time, output vehicle data obtained within a target time period based on the location time, so as to analyze the characteristics of vehicle users in the target geographical area based on the vehicle data in the target geographical area within the target time period. The duration of the target time period is a preset duration, and the end time of the target time period is the target time.

5. The apparatus according to claim 4, characterized in that, The device further includes a setting unit, a storage unit, and a backtracking unit; The setting unit is used to set the save point period; The storage unit is used to associate and store the device identifier and the vehicle data in an offline database according to the storage point period; The backtracking unit is used to backtrack the lost device identifier and vehicle data from the offline database if an anomaly occurs during the vehicle data query process.

6. The apparatus according to claim 5, characterized in that, The storage unit is used for: The device identifier is used as the key field, and the vehicle data corresponding to the device identifier is used as the value field. These are then stored in the offline database using a hash structure.

7. A computer device, characterized in that, The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the method according to any one of claims 1-3 according to the instructions in the program code.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method according to any one of claims 1-3.

9. A computer program product comprising instructions that, when run on a computer, cause the computer to perform the method of any one of claims 1-3.

Images