A method for caching massive trajectory data, a method for querying massive trajectory data and a device for caching massive trajectory data
By partitioning the key fields and time fields of massive trajectory data and cacheing the data to multiple partitions of the hbase database, the problems of high cost of cached massive trajectory data and low query efficiency in the existing technology are solved, and efficient and low-cost cache and query of massive trajectory data is achieved.
Patent Information
- Application Number
- CN202411940617.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-26
- Publication Date
- 2025-04-08
AI Technical Summary
In the prior art, massive trajectory data is cached into memory, which has high caching costs and low efficiency in querying cached data.
By obtaining the key fields and time fields of massive trajectory data, the hbase database is partitioned and the data is cached to multiple partitions. The distributed cache characteristics of the hbase database are used to realize the distributed cache of massive trajectory data.
It reduces the cache cost, improves the cache efficiency of massive trajectory data, supports PB-level data caching, and saves data cache costs.
Smart Images

Figure CN119782369A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of data access technology, and in particular to a massive trajectory data caching method, query method and device. Background Art
[0002] With the advancement of positioning technology, such as the popularity of mobile phones that support GPS positioning, a large amount of trajectory data is generated. Trajectory data involves multiple types of data, such as railway passenger transport, air passenger transport, rail transit, etc. Different types of data involve different business departments, which will generate different tables, and trajectory data is constantly generated, so when querying specified trajectory data, a large amount of real-time calculation is required to obtain data. In order to obtain the specified trajectory data faster, the data of the last query can be cached for the convenience of the next query.
[0003] The traditional data caching method is to use the redis database to cache massive trajectory data. This has the following technical problems: the redis database caches data in memory, but since the amount of trajectory data is too large, if all of it is cached in memory, the caching cost is high and the cached data query efficiency is low.
[0004] Therefore, there is an urgent need to provide a massive trajectory data caching method, query method and device to achieve fast query of massive trajectory data and reduce caching costs. Summary of the invention
[0005] In view of this, it is necessary to provide a massive trajectory data caching method, query method and device to solve the technical problems existing in the prior art of caching massive trajectory data into memory, high caching cost and low cache data query efficiency.
[0006] On the one hand, in order to solve the above technical problems, the present invention provides a method for caching massive trajectory data, comprising: Acquire massive trajectory data, and determine key fields and time fields of the massive trajectory data; The HBase database is partitioned based on the key field and the time field to obtain multiple partitions, and the massive trajectory data is cached in the multiple partitions.
[0007] In a possible implementation, partitioning the HBase database based on the key field and the time field to obtain multiple partitions includes: Generate a row key based on the key field and the time field; Determine the data volume of the massive trajectory data and the cluster performance value of the Hadoop cluster, and determine the partition key byte in the row key based on the data volume and the cluster performance value; The hbase database is partitioned based on the partition key byte to obtain multiple partitions.
[0008] In a possible implementation, the partition key byte includes a first byte and a second byte having different numbers of partitions, and the number of partitions corresponding to the first byte is greater than the number of partitions corresponding to the second byte. Then, determining the partition key byte in the row key based on the data volume and the cluster performance value includes: Determine whether the data volume is greater than a quantity threshold and whether the cluster performance value is greater than a cluster performance threshold; If the data volume is greater than the quantity threshold and the cluster performance value is greater than the cluster performance threshold, the partition key byte is the first byte; If the data volume is less than or equal to the quantity threshold or the cluster performance value is less than or equal to the cluster performance threshold, the partition byte is the second byte.
[0009] In a possible implementation, the massive trajectory data is user trajectory data, the key field is the user's unique identity, and the time field is the time when the activity is generated; The partition key byte is the year byte, the year-month byte, or the year-month-day byte in the user unique identity; then determining the partition key byte in the row key based on the data volume and the cluster performance value includes: Determining whether the data volume is greater than a high volume threshold and whether the cluster performance value is greater than a high cluster performance threshold; If the data volume is greater than a high volume threshold and the cluster performance value is greater than a high cluster performance threshold, the partition key byte is the year-month-day byte; If the data volume is less than or equal to the high quantity threshold or the cluster performance value is less than or equal to the high cluster performance threshold, determine whether the data volume is less than the low quantity threshold and whether the cluster performance value is less than the low cluster performance threshold; the high quantity threshold is greater than the low quantity threshold, and the high cluster performance threshold is greater than the low cluster performance threshold; If the data volume is less than a low quantity threshold and the cluster performance value is less than a low cluster performance threshold, the partition byte is the year byte; If the data volume is greater than or equal to a low quantity threshold or the cluster performance value is greater than or equal to a low cluster performance threshold, the partition byte is the year-month byte.
[0010] In a possible implementation, determining a cluster performance value of a Hadoop cluster includes: Obtain the number of nodes in the Hadoop cluster, the memory of each node, and the CPU performance of each node; The cluster performance value is determined based on the number of nodes, the memory, the CPU performance and a preset weight.
[0011] In a possible implementation, the massive trajectory data includes a plurality of trajectory data; and the method further includes: Obtain the cache duration of each piece of the trajectory data in the hbase database; When the cache time is longer than the preset cache time, the trajectory data is deleted from the hbase database.
[0012] In a possible implementation, caching the massive trajectory data to the multiple partitions based on the partition key bytes includes: Determining whether there is historical trajectory cache data in the multiple partitions; If so, updating the historical trajectory cache data based on the massive trajectory data; If not, the massive trajectory data is directly cached to the multiple partitions.
[0013] On the other hand, the present invention also provides a method for querying massive trajectory data, comprising: Build index statements based on the row key format of the hbase database; The hbase database is traversed based on the index statement to obtain target trajectory data matching the index statement from the massive trajectory data in the hbase database.
[0014] On the other hand, the present invention also provides a massive trajectory data caching device, comprising: A massive trajectory data acquisition unit, used to acquire massive trajectory data and determine key fields and time fields of the massive trajectory data; A partition cache unit is used to partition the HBase database based on the key field and the time field to obtain multiple partitions, and cache the massive trajectory data to the multiple partitions.
[0015] On the other hand, the present invention also provides a massive trajectory data query device, comprising: Index statement building unit, used to build index statements based on the row key format of the HBase database; The trajectory query unit is used to traverse the hbase database based on the index statement to obtain target trajectory data matching the index statement from the massive trajectory data in the hbase database.
[0016] The beneficial effects of the present invention are as follows: the method for caching massive trajectory data provided by the present invention can realize distributed caching of massive trajectory data by setting the database for caching massive trajectory data as an HBase database, and can utilize the characteristic of HBase database to cache massive trajectory data in a Hadoop cluster, and can realize caching of massive trajectory data without using too much memory, thus saving data caching cost. At the same time, HBase database supports PB-level data caching, which improves the caching efficiency of massive trajectory data. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.
[0018] Figure 1 A schematic diagram of a flow chart of an embodiment of a method for caching massive trajectory data provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of a flow chart of obtaining multiple partitions in step S102; Figure 3 For the present invention Figure 2 A schematic diagram of an embodiment of determining a partition key byte in step S202; Figure 4 For the present invention Figure 2 A schematic diagram of another embodiment of the process of determining the partition key node in step S202; Figure 5 For the present invention Figure 2 A schematic diagram of an embodiment of determining the cluster performance value in step S202; Figure 6 A schematic diagram of the structure of an embodiment of deleting expired data provided by the present invention; Figure 7 A schematic diagram of a flow chart of an embodiment of a method for querying massive trajectory data provided by the present invention; Figure 8 A schematic diagram of the structure of an embodiment of a massive trajectory data caching device provided by the present invention; Fig. 9 A schematic diagram of the structure of an embodiment of a massive trajectory data query device provided by the present invention. DETAILED DESCRIPTION
[0019] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0020] It should be understood that the schematic drawings are not drawn to scale. The flowchart used in the present invention shows the operations implemented according to some embodiments of the present invention. It should be understood that the operations of the flowchart can be implemented out of order, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art, under the guidance of the content of the present invention, can add one or more other operations to the flowchart, and can also remove one or more operations from the flowchart. Some of the block diagrams shown in the accompanying drawings are functional entities, which do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor systems and / or microcontroller systems.
[0021] Reference to an "embodiment" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0022] The present invention provides a massive trajectory data caching method, a query method and a device, which are described below respectively.
[0023] Figure 1 A flow chart of an embodiment of a method for caching massive trajectory data provided by the present invention is shown as follows: Figure 1 As shown, the massive trajectory data caching method includes: S101, obtaining massive trajectory data, and determining key fields and time fields of the massive trajectory data; S102, partitioning the hbase database based on the key field and the time field to obtain multiple partitions, and caching the massive trajectory data into the multiple partitions.
[0024] The massive trajectory data includes but is not limited to pedestrian trajectory and vehicle trajectory, and the data types of the massive trajectory data include but are not limited to railway passenger transport, aviation passenger transport, rail transit and other data.
[0025] Compared with the prior art, the method for caching massive trajectory data provided by the embodiment of the present invention can realize distributed caching of massive trajectory data by setting the database for caching massive trajectory data as an HBase database, and can utilize the characteristic of HBase database to cache massive trajectory data in the Hadoop cluster, and can realize caching of massive trajectory data without using too much memory, thus saving data caching cost. At the same time, HBase database supports PB-level data caching, which improves the caching efficiency of massive trajectory data.
[0026] In some embodiments of the present invention, Figure 2 As shown, obtaining multiple partitions in step S102 includes: S201. Generate a row key (RowKey) based on the key field and the time field; S202, determining the data volume of the massive trajectory data and the cluster performance value of the Hadoop cluster, and determining the partition key byte in the row key based on the data volume and the cluster performance value; S203. Partition the hbase database based on the partition keyword byte to obtain multiple partitions.
[0027] It should be noted that the row key in step S201 is a field obtained by merging the key field and the time field, and the merging method can be to concatenate the key field and the time field, or to connect the key field and the time field using a connector, wherein the connector can be an underscore.
[0028] For example: if the key field is A and the time field is B, the row key can be AB or A_B.
[0029] The embodiment of the present invention determines the partitioning strategy based on the data volume of the massive trajectory data and the cluster performance value of the Hadoop cluster, that is, partitioning the key node, so as to realize accurate partitioning of the HBase database, make the partitions obtained by the division more adaptable to the massive trajectory data, and avoid resource waste while further improving the data cache efficiency.
[0030] In some embodiments of the present invention, the partition key byte includes a first byte and a second byte with different partition numbers, and the partition number corresponding to the first byte is greater than the partition number corresponding to the second byte.
[0031] By setting the partition key byte to the first byte or the second byte, the hbase database can be divided into different numbers of partitions based on the first byte and the second byte to improve the adaptability of the number of partitions to the massive trajectory data, avoiding the problem of resource waste caused by dividing too many partitions, or low cache efficiency of massive trajectory data caused by dividing too few partitions.
[0032] From the above description, it can be seen that the reasonable confirmation of the first byte and the second byte has a great influence on improving the cache efficiency of massive trajectory data. Therefore, based on the above first byte and the second byte, in a specific embodiment of the present invention, Figure 3 As shown, determining the partition key byte in the row key based on the data volume and the cluster performance value in step S202 includes: S301, determining whether the data volume is greater than a quantity threshold and whether the cluster performance value is greater than a cluster performance threshold; S302: If the data volume is greater than the quantity threshold and the cluster performance value is greater than the cluster performance threshold, the partition key byte is the first byte; S303: If the data volume is less than or equal to the quantity threshold or the cluster performance value is less than or equal to the cluster performance threshold, the partition byte is the second byte.
[0033] The embodiment of the present invention determines whether the partition byte is the first byte or the second byte based on the two dimensions of data volume and cluster performance value, thereby ensuring the accuracy of the first byte and the second byte, thereby improving the rationality and accuracy of the partition.
[0034] It should be understood that the quantity threshold and the cluster performance threshold can be calibrated according to actual application scenarios or experience values, and are not specifically limited here.
[0035] In a specific application scenario of the present invention, the massive trajectory data is user trajectory data, the key field is the user's unique identity, and the time field is the time when the activity is generated.
[0036] Specifically, the user's unique identity identifier may be an ID number.
[0037] The activity generation time can be accurate to seconds. For example, the time field can be: "20240410153246", which means the trajectory data generated at 15:32:46 on April 10, 2024.
[0038] When the user's unique identity is an ID number, since the ID number includes the user's year, month, and date of birth, three partition key bytes can be set based on these three time parameters to further refine the partition strategy and improve the degree of partition refinement.
[0039] Specifically, the partition key byte is the year byte, the year-month byte, or the year-month-day byte in the user's unique identity.
[0040] For example: if the user's unique identity is 110215200808081210, the year byte is 08, the month byte is 08, and the date byte is 08, then the year-month byte is 0808, and the year-month-day byte is 080808.
[0041] Based on the above partition key bytes, in some embodiments of the present invention, such as Figure 4 As shown, determining the partition key byte in the row key based on the data volume and the cluster performance value in step S202 includes: S401, determining whether the data volume is greater than a high volume threshold and whether the cluster performance value is greater than a high cluster performance threshold; S402, if the data volume is greater than the high volume threshold and the cluster performance value is greater than the high cluster performance threshold, the partition key byte is the year-month-day byte; S403: If the data volume is less than or equal to the high quantity threshold or the cluster performance value is less than or equal to the high cluster performance threshold, determine whether the data volume is less than the low quantity threshold and whether the cluster performance value is less than the low cluster performance threshold; the high quantity threshold is greater than the low quantity threshold, and the high cluster performance threshold is greater than the low cluster performance threshold; S404, if the data volume is less than the low quantity threshold and the cluster performance value is less than the low cluster performance threshold, the partition byte is the year byte; S405: If the data volume is greater than or equal to the lower quantity threshold or the cluster performance value is greater than or equal to the lower cluster performance threshold, the partition bytes are the year-month bytes.
[0042] The embodiment of the present invention sets three partition key bytes with different granularities based on the characteristics of the unique identity identification code, namely, year byte, year-month byte or year-month-day byte, thereby realizing partitioning of the HBase database at three different scales, improving the refinement of the partition, and further achieving improved resource utilization while ensuring the efficiency of caching massive trajectory data.
[0043] In some embodiments of the present invention, Figure 5 As shown, determining the cluster performance value of the Hadoop cluster in step S202 includes: S501, obtaining the number of nodes in the Hadoop cluster, the memory of each node, and the CPU performance of each node; S502: Determine a cluster performance value based on the number of nodes, memory, CPU performance, and preset weights.
[0044] The embodiment of the present invention determines the cluster performance value based on parameters of three dimensions, namely, the number of nodes, the memory and the CPU performance of each node, thereby improving the accuracy of the determined cluster performance value and further improving the rationality of the partitioning strategy.
[0045] Specifically, step S502 includes: determining the number of nodes, memory, and the number factor, memory factor, and CPU factor of CPU performance based on preset weights, and taking the sum of the three factors as the cluster performance value.
[0046] Since trajectory data is continuously generated, old data is of little significance to trajectory analysis. Therefore, in some embodiments of the present invention, Figure 6 As shown, the massive trajectory data caching method also includes: S601, obtaining the cache duration of each track data in the hbase database; S602: When the cache duration is greater than the preset cache duration, the trajectory data is deleted from the hbase database.
[0047] The embodiment of the present invention can reduce the amount of cached data without affecting subsequent analysis by deleting trajectory data whose cache duration is longer than a preset cache duration from the hbase database.
[0048] In a specific embodiment of the present invention, the preset cache time is determined according to the amount of cache space of the hbase database. Specifically: when the data volume is at the TB or even PB level and the disk space is not very sufficient, the expiration time of the cached data can be set to 7 days; if the data volume is large but the disk space is also sufficient, the expiration time of the cached data can be set to 30 days or even 90 days; if the data volume is at the GB level and the disk space is sufficient, it can be considered that the cached data will not expire and will be cached all the time to facilitate quick query of the data.
[0049] In some application scenarios, the hbase database caches other data, such as historical trajectory cache data. When the massive trajectory data obtained in step S101 needs to be cached in the hbase database, it is necessary to avoid cache conflicts between the massive trajectory data and the historical trajectory cache data. To achieve this purpose, in some embodiments of the present invention, the massive trajectory data is cached in multiple partitions in step S202, including: Determine whether there is historical trajectory cache data in multiple partitions; If it exists, the historical trajectory cache data is updated based on the massive trajectory data; If it does not exist, the massive trajectory data will be directly cached into multiple partitions.
[0050] In the embodiment of the present invention, when there is no data in the HBase database before, the massive trajectory data can be directly cached to multiple partitions. When there is data in the HBase database before, the historical trajectory cache data is updated based on the massive trajectory data, that is, the previous historical trajectory cache data is overwritten, so as to avoid data conflicts, ensure that the data cached in the HBase database is the latest trajectory data, and improve the efficiency of the next data query.
[0051] Since it is necessary to query and analyze the massive trajectory data later, the present invention also provides a massive trajectory data query method, such as Figure 7As shown, the massive trajectory data query includes: S701, constructing an index statement based on the row key format of the hbase database; S702: traverse the HBase database based on the index statement to obtain target trajectory data matching the index statement from the massive trajectory data in the HBase database.
[0052] It should be noted that: when the target trajectory data cannot be obtained from the hbase database based on the index statement, it means that there is no target trajectory data in the hbase database. At this time, the trajectory data can be obtained in real time through the trajectory acquisition device, and the trajectory data is cached in the hbase database, and then steps S701-S702 are executed.
[0053] The embodiment of the present invention realizes the query of trajectory data by setting up an HBase database, and improves the query efficiency of target trajectory data by utilizing the high performance query capability of the HBase database.
[0054] In order to better implement the massive trajectory data caching method in the embodiment of the present invention, based on the massive trajectory data caching method, the embodiment of the present invention also provides a massive trajectory data caching device, such as Figure 8 As shown, the massive trajectory data caching device 800 includes: A massive trajectory data acquisition unit 801 is used to acquire massive trajectory data and determine key fields and time fields of the massive trajectory data; The partition cache unit 802 is used to partition the HBase database based on the key field and the time field to obtain multiple partitions, and cache the massive trajectory data into the multiple partitions.
[0055] The massive trajectory data caching device 800 provided in the above embodiment can implement the technical solution described in the above massive trajectory data caching method embodiment. The specific implementation principles of the above modules or units can refer to the corresponding contents in the above massive trajectory data caching method embodiment, which will not be repeated here.
[0056] In order to better implement the massive trajectory data query method in the embodiment of the present invention, based on the massive trajectory data query method, the embodiment of the present invention also provides a massive trajectory data query device, such as Fig. 9 As shown, the massive trajectory data query device 900 includes: An index statement building unit 901 is used to build an index statement based on the row key format of the hbase database; The trajectory query unit 902 is used to traverse the HBase database based on the index statement and obtain the target trajectory data matching the index statement from the massive trajectory data in the HBase database.
[0057] The massive trajectory data query device 900 provided in the above embodiment can implement the technical solution described in the above massive trajectory data query method embodiment. The specific implementation principles of the above modules or units can refer to the corresponding contents in the above massive trajectory data query method embodiment, which will not be repeated here.
[0058] Those skilled in the art will appreciate that all or part of the processes of the above-mentioned embodiments can be implemented by instructing related hardware (such as a processor, a controller, etc.) through a computer program, and the computer program can be stored in a computer-readable storage medium, wherein the computer-readable storage medium is a disk, an optical disk, a read-only storage memory, or a random access memory, etc.
[0059] The above is a detailed introduction to a massive trajectory data caching method, query method and device provided by the present invention. In this article, specific examples are used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method and core idea of the present invention; at the same time, for those skilled in the art, according to the idea of the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as limiting the present invention.
Claims
1. A method for caching massive trajectory data, characterized in that: include: Acquire massive trajectory data, and determine key fields and time fields of the massive trajectory data; The HBase database is partitioned based on the key field and the time field to obtain multiple partitions, and the massive trajectory data is cached in the multiple partitions.
2. The method for caching massive trajectory data according to claim 1, characterized in that: The partitioning of the HBase database based on the key field and the time field to obtain multiple partitions includes: Generate a row key based on the key field and the time field; Determine the data volume of the massive trajectory data and the cluster performance value of the Hadoop cluster, and determine the partition key byte in the row key based on the data volume and the cluster performance value; The hbase database is partitioned based on the partition key byte to obtain multiple partitions.
3. The method for caching massive trajectory data according to claim 2, characterized in that: The partition key byte includes a first byte and a second byte with different partition numbers, the number of partitions corresponding to the first byte is greater than the number of partitions corresponding to the second byte, and determining the partition key byte in the row key based on the data volume and the cluster performance value includes: Determine whether the data volume is greater than a quantity threshold and whether the cluster performance value is greater than a cluster performance threshold; If the data volume is greater than the quantity threshold and the cluster performance value is greater than the cluster performance threshold, the partition key byte is the first byte; If the data volume is less than or equal to the quantity threshold or the cluster performance value is less than or equal to the cluster performance threshold, the partition byte is the second byte.
4. The method for caching massive trajectory data according to claim 1, characterized in that: The massive track data is user track data, the key field is the user's unique identity, and the time field is the time when the activity is generated; The partition key byte is the year byte, the year-month byte or the year-month-day byte in the user unique identity; Then, determining the partition key byte in the row key based on the data volume and the cluster performance value includes: Determining whether the data volume is greater than a high volume threshold and whether the cluster performance value is greater than a high cluster performance threshold; If the data volume is greater than a high volume threshold and the cluster performance value is greater than a high cluster performance threshold, the partition key byte is the year-month-day byte; If the data volume is less than or equal to the high quantity threshold or the cluster performance value is less than or equal to the high cluster performance threshold, determine whether the data volume is less than the low quantity threshold and whether the cluster performance value is less than the low cluster performance threshold; the high quantity threshold is greater than the low quantity threshold, and the high cluster performance threshold is greater than the low cluster performance threshold; If the data volume is less than a low quantity threshold and the cluster performance value is less than a low cluster performance threshold, the partition byte is the year byte; If the data volume is greater than or equal to a low quantity threshold or the cluster performance value is greater than or equal to a low cluster performance threshold, the partition byte is the year-month byte.
5. The method for caching massive trajectory data according to claim 1, characterized in that: Determine the cluster performance values of the Hadoop cluster, including: Obtain the number of nodes in the Hadoop cluster, the memory of each node, and the CPU performance of each node; The cluster performance value is determined based on the number of nodes, the memory, the CPU performance and a preset weight.
6. The method for caching massive trajectory data according to claim 1, characterized in that: The massive trajectory data includes a plurality of trajectory data; the method further includes: Obtain the cache duration of each piece of the trajectory data in the hbase database; When the cache time is longer than the preset cache time, the trajectory data is deleted from the hbase database.
7. The method for caching massive trajectory data according to claim 1, characterized in that: The caching the massive trajectory data to the multiple partitions includes: Determining whether there is historical trajectory cache data in the multiple partitions; If so, updating the historical trajectory cache data based on the massive trajectory data; If not, the massive trajectory data is directly cached to the multiple partitions.
8. A method for querying massive trajectory data, characterized in that: include: Build index statements based on the row key format of the hbase database; The hbase database is traversed based on the index statement to obtain target trajectory data matching the index statement from the massive trajectory data in the hbase database.
9. A massive trajectory data caching device, characterized in that: include: A massive trajectory data acquisition unit, used to acquire massive trajectory data and determine key fields and time fields of the massive trajectory data; A partition cache unit is used to partition the HBase database based on the key field and the time field to obtain multiple partitions, and cache the massive trajectory data to the multiple partitions.
10. A massive trajectory data query device, characterized in that: include: Index statement building unit, used to build index statements based on the row key format of the HBase database; The trajectory query unit is used to traverse the hbase database based on the index statement to obtain target trajectory data matching the index statement from the massive trajectory data in the hbase database.