A data replay system and method for sensor stream data

Abstract

The present invention discloses a data replay system and method for sensor stream data. The system includes: a historical data storage layer, a database connection layer, a data replay execution layer, and a replay data display layer, which are arranged in order from bottom to top. The data replay method includes: (1) installing and configuring the time series database Apache IoTDB; (2) using a database connection pool and a thread pool to connect to the database and obtain replay data; (3) building a concurrent buffer pool to achieve replay of historical data; and (4) integrating the data display interface and the concurrent buffer pool module to realize a data replay Web system. Users can select the data to be replayed and set specific parameters through the system page to achieve a smooth and flexible data replay effect.

Description

Technical Field

[0001] The present invention relates to a data replay system and method for sensor stream data, in particular to a data replay system and construction method for hydrological and water quality sensor stream data, belonging to the technical field of software development and sensor data processing. Background Art

[0002] With the development of the Internet of Things and big data technologies, sensors are increasingly being used in all aspects of social life, and the data collected by various sensors contains an increasing amount of information. Since most sensor data is real-time and time-stamped, the data volume is enormous, making real-time analysis more challenging. To address the limitations of real-time data analysis when dealing with massive amounts of sensor data, data replay technology can be applied. Data replay is the process of streaming historical data to top-level applications. It is widely used in performance testing or post-mortems for many online mission-critical systems, including stock and securities systems and recommendation systems. In such scenarios, a replay service is required to query certain portions of large-scale historical data based on given conditions and then process them in a specified replay order (for example, sorted by timestamp). Data replay retrieves data that meets the query criteria from databases or files, performs analysis and computation on the replayed data in a streaming format while transmitting the data to the client. This makes up for the inability to perform real-time computation and analysis in some cases, making it highly valuable for analyzing streaming sensor data.

[0003] Replaying sensor-collected time-series streaming data effectively addresses the shortcomings of real-time analysis of time-series data, making it possible to recreate the scene in which the streaming data was generated. Existing data replay research primarily focuses on businesses such as financial securities and real-time user recommendations. This work does not address sensor-collected time-series streaming data, making it inapplicable to sectors such as industry, water conservancy, and healthcare that rely on sensor data collection. Due to the limitations of existing research and the unique temporal and structural characteristics of sensor streaming data, achieving smooth and stable replay remains challenging. Summary of the Invention

[0004] Purpose of the invention: In view of the problems and shortcomings of the prior art, the present invention provides a data replay system and method for sensor stream data, which is used to smoothly and accurately replay the historical time series data collected by the sensor, and facilitate the analysis of the historical time series data collected by the sensor.

[0005] Technical solution: A data replay system for sensor stream data, including a historical data storage layer, a database connection layer, a data replay execution layer and a replay data display layer arranged in sequence from bottom to top.

[0006] The historical data storage layer uses the Apache IoTDB time series database to store time-stamped historical stream data collected by sensors. In the Apache IoTDB time series database, data is divided into multiple time series based on the different collection sites. Each data point stored in IoTDB consists of a timestamp and the corresponding collection value, reflecting the sensor value changing over time.

[0007] The database connection layer improves the concurrency of the replay system by utilizing a database connection pool. As a mature and established technology, database connection pooling is responsible for allocating, managing, and releasing database connections. It allows applications to reuse existing database connections rather than reestablishing new ones, significantly improving the performance of database operations. The database connection layer uses a database connection pool to achieve efficient connectivity with the historical data storage layer and encapsulates SQL statements for database queries into a Java class. Furthermore, concurrency is further enhanced by coding a thread pool. The use of a thread pool enables multiple threads to simultaneously fill the buffer pool with data, enabling multiple replay requests to execute concurrently and enabling the concurrent filling of different data required by different replay requests.

[0008] The data replay execution layer designs and implements a concurrent buffer pool to enable smooth and accurate replay of historical sensor data. The concurrent buffer pool is the core component of the entire replay system architecture. The core data structure of the concurrent buffer pool module is a Java ConcurrentHashMap class that supports efficient queries and safe concurrency. In this ConcurrentHashMap, the key is the time series name, and the value is the time series data corresponding to that time series name. The value in the ConcurrentHashMap itself is a data container composed of a queue structure. This container is a multi-level priority queue composed of multiple priority queues connected in sequence. Due to its inherent buffering properties, a multi-level priority queue can also be called a multi-level buffer queue. It stores the hotspot time series data to be replayed. During the replay of historical time series, eligible data is retrieved in batches from the underlying database and cached in this buffer before being provided to the upper-level replay interface. When a user requests data replay, the replay interface requests data from the concurrent buffer pool. While providing data to the replay interface, the concurrent buffer pool interacts with the database of the underlying historical data storage layer through a thread pool and connection pool to populate its own data.

[0009] The replay data display layer is a front-end display page that directly interacts with users. Users select and set replay data and related parameters through the front-end page, and the data display layer retrieves replay data from the buffer pool in the execution layer through the replay interface. The replay front-end page is divided into a replay parameter selection area and a replay data curve display area. The replay parameter selection area provides time, speed, and time series name for user selection, while the replay data curve display area presents the replay data in the form of dynamic curves, allowing users to conduct more intuitive and convenient analysis.

[0010] A data replay method for sensor stream data, and also a method for implementing a data replay system for sensor stream data, comprises the following steps:

[0011] Step 1: Install and configure Apache IoTDB. IoTDB is a time series database used to store and query time series data with timestamps, so that historical data with replay value can be well preserved and easily retrieved.

[0012] Step 2: At the database connection layer, various query operations on the database are encapsulated into a Java class, including: querying based on the start and end time of the timestamp of the data to be replayed, querying based on the time series name, querying based on the sensor, and querying based on the data collection site; in addition, a database connection pool is implemented through coding. When connecting to the database, the upper structure only needs to request a new connection from the connection pool without re-establishing the connection, which improves the speed of the system when requesting data. Finally, a thread pool is implemented through Java multi-threaded programming to achieve concurrent filling when filling the buffer pool, further improving the concurrency of the system.

[0013] Step 3: Design and implement a concurrent buffer pool in the data replay execution layer. The concurrent buffer pool is connected to the IoTDB database below and the replay system data display layer above. While continuously obtaining replay data from the IoTDB database, it also provides the data to the front-end page for display. The two processes of obtaining replay data and providing data to the front-end page are connected through the buffer pool set in the middle, so that the two processes of obtaining and providing data do not interfere with each other and are carried out simultaneously.

[0014] Step 4: In the data replay execution layer, use buffering technology and priority queues to ensure the normal operation of the concurrent buffer pool. Use the Java language's ConcurrentHashMap data structure to design a concurrent buffer pool for data replay. The corresponding key values ​​are the time series name and a multi-level buffer queue composed of priority queues. This complex data structure composed of priority queues is named TimeSeriesPool, that is, the concurrent buffer pool. It internally defines the multi-level buffer queues and the order of each buffer task to ensure the normal operation of the concurrent buffer pool.

[0015] Step 5: In the replay data display layer, the connection with the database and concurrent buffer pool is realized through coding, so that the user can easily select the replay data and set different replay parameters.

[0016] In step 2, the class that encapsulates multiple query operation methods calls different methods based on different inputs and returns the corresponding time series data. The specific steps are as follows:

[0017] Input: start and end time, time series name, sensor name, data collection site name;

[0018] Output: time series data that meets the above input conditions after screening;

[0019] First, the query operation on the IoTDB database is implemented by obtaining a connection from the connection pool; then different query methods are used according to the input parameters to obtain data that meets the query conditions; finally, the obtained data is provided to the concurrent buffer pool, and the next data acquisition process is started according to the requirements of the concurrent buffer pool.

[0020] In the step (3), while the concurrent buffer pool provides data to the data presentation layer, it continuously obtains new data from the database of the historical data storage layer and fills the empty queues. The specific steps are as follows: when replaying data, the replay framework designed based on the concurrent buffer pool will first use the input time series name to search the concurrent buffer pool for the corresponding time series data. If the multi-level buffer queue returned after the search is not empty, it means that the time series has been buffered before, and the returned data can also be used directly. If the returned multi-level buffer queue is empty, it means that the time series has never been buffered before. At this time, the initialization method should be called to initialize the multi-level buffer queue; when initializing the multi-level buffer queue, the filling method of the multi-level buffer queue will be triggered. Filling the multi-level buffer queue involves two parameters: the multi-level buffer queue size and the priority queue size; when filling the buffer queue, the thread pool is used to fill the buffer queue to improve the efficiency of the system. In order to ensure the order between queues in the multi-level buffer queue, a task queue is used to identify the order of filling tasks; it can be divided into the following parts:

[0021] (a) Initialize the multi-level buffer queue

[0022] The initialization method first attempts to initialize the multi-level buffer queue corresponding to the specified time series. If the multi-level buffer queue is not empty, it is placed into the concurrent buffer pool. The core logic of initializing the multi-level buffer queue can be described as follows: First, the number of rows in the time series within the specified time range is queried. If the number of rows is 0, it returns. Otherwise, the multi-level buffer queue is initialized and the multi-level buffer queue's fill method is triggered.

[0023] (b) Parameters involved in filling a multi-level buffer queue

[0024] The filling method involves two parameters: the multi-level buffer queue size and the priority queue size. The multi-level buffer queue size can be configured based on the server. In theory, given sufficient resources, a larger multi-level buffer queue size results in higher replay efficiency. The priority queue can be considered a single-level buffer queue. Its size is determined based on a specified time range. Since the sampling interval of time series data is fixed, time series should have the same amount of data within the same time interval.

[0025] (c) Multi-level buffer queue workflow

[0026] Once initialized, the multi-level buffer queue can be used in subsequent steps: First, the buffer queue at the head of the multi-level buffer queue (the priority queue) is retrieved. This is the buffer queue that should be accessed at the current time point. After retrieving the specified buffer queue, the elements in the time series are evaluated, and the data that meets the given conditions is filtered and returned. After the filtering is completed, the start and end times of the data to be retrieved from the database are recorded. Finally, a buffer queue is added to the end of the queue to ensure efficient system replay.

[0027] (d) Specific method of filling multi-level buffer queue (task queue)

[0028] When filling the buffer queue, a thread pool is used to improve system efficiency. To ensure order between queues in the multi-level buffer queue, a task queue is used to identify the order in which tasks are filled. The task queue is a data structure defined by the ConcurrentLinkedQueue class in the Java language. It is a thread-safe blocking queue. Each element stored in it corresponds to the size of the buffer pool at a specific moment. Whenever the upper-level replay interface requests data, the system obtains the current buffer pool size and adds it to the task queue. After the replay interface receives the replay data, the buffer pool needs to fill the empty portion of the buffer queue. At this time, the system obtains the value of the head element in the current task queue and compares it with the current buffer pool size. Only when the two match will the data filling process begin. When filling the buffer queue, the system utilizes multithreading technology. Using Java's multithreaded programming techniques, multiple threads concurrently retrieve corresponding data from the database within their own specified time ranges. This concurrent operation avoids serial interaction with the database, reducing the time consumption that serial interaction would otherwise incur. After multiple task threads retrieve the corresponding data from the database, the task queue taskOrder is used to ensure that the retrieved data is placed into the multi-level buffer queue in a certain order. taskOrder is a thread-safe blocking queue. This operation ensures efficient concurrent execution of filling tasks and maintains order between queues.

[0029] Beneficial effects: According to the characteristics of sensor stream data and the practical significance of data replay, a data replay system for sensor stream data and its construction method are proposed. Based on this replay system, users can flexibly select the time series data that needs to be replayed and set different replay parameters to meet different data analysis needs; the good concurrency performance of the system enables users to replay multiple time series data at the same time, improving replay efficiency; the concurrent buffer pool is developed using multi-level queues, which minimizes the time consumption when interacting with the database and replay interface, improves the smoothness of replay, and uses priority queues to ensure the accurate order of the replay process. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 Schematic diagram of the system structure of an embodiment of the present invention;

[0031] Figure 2 Schematic diagram of the data playback system interface according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] The present invention is further illustrated below with reference to specific examples. It should be understood that these examples are only used to illustrate the present invention and are not used to limit the scope of the present invention. After reading the present invention, modifications of various equivalent forms of the present invention made by those skilled in the art all fall within the scope defined by the claims attached to this application.

[0033] like Figure 1 As shown, a data replay system for sensor stream data includes: a historical data storage layer, a database connection layer, a data replay execution layer and a replay data display layer.

[0034] At the historical data storage layer, the system uses the Apache IoTDB time series database to store historical sensor data. IoTDB provides the replay system with all available time series data for replay and is deployed on a cluster of virtual machines, all of which have identical configurations. In the Apache IoTDB time series database, data is divided into multiple time series based on the different collection sites. Each data point stored in IoTDB consists of a timestamp and the corresponding value, reflecting the sensor value over time.

[0035] The database connection layer connects to IoTDB and retrieves data through a database connection pool. It also uses a thread pool to improve the concurrency of the replay system. The database connection layer encapsulates SQL statements for database queries into a Java class. It further improves concurrency by implementing a thread pool, enabling multiple replay requests to execute concurrently. Finally, the replay of time series data is implemented using a concurrent buffer pool mechanism.

[0036] The data replay execution layer uses a custom concurrent buffer pool to retrieve replay data from the underlying database and simultaneously provide data to the replay interface. These two processes operate independently and without interfering with each other. When a user requests replay data, they request data from the concurrent buffer pool through the replay interface. While providing data to the replay interface, the concurrent buffer pool interacts with the database of the underlying historical data storage layer through a thread pool and connection pool to populate its own data.

[0037] The replay data display layer provides users with convenient and concise operation methods. The replay front-end page is divided into a replay parameter selection area and a replay data curve display area. The replay parameter selection area provides time, speed, and time series name for users to select, while the replay data curve display area presents the replay data in the form of a dynamic curve, allowing users to conduct more intuitive and convenient analysis.

[0038] Before replaying, perform a connection test on the IoTDB database to ensure database availability. To actually replay, first select the time series name from the drop-down box, select the start and end times, and choose different parameters to achieve different replay rates. Finally, click Start to view the dynamically changing replay data curve in the data display area below.

[0039] The present invention discloses a data replay system for sensor stream data and a construction method thereof, comprising the following steps:

[0040] (1) Install and configure the Apache IoTDB database:

[0041] Install and configure the IoTDB database on the server cluster, and store the historical time series data collected by the sensors in the IoTDB database. Each data consists of a timestamp and the specific value corresponding to that moment.

[0042] (2) Connect to the database:

[0043] The database connection pool is used to realize the replay system's connection to the database and obtain data. The connection pool and thread pool are used to make the replay system have good concurrent replay performance.

[0044] Various query operations on the database are encapsulated into a Java class, including: querying based on start and end time, querying based on time series name, querying based on sensor, and querying based on data collection site; in addition, a database connection pool is implemented through coding to improve system speed and concurrency, and a thread pool is implemented through Java multi-threaded programming to further improve the concurrency of the system.

[0045] The class that encapsulates multiple query operation methods calls different methods based on different inputs and returns the corresponding time series data. The specific steps are:

[0046] Input: start and end time, time series name, sensor name, data collection site name;

[0047] Output: time series data that meets the above input conditions after screening;

[0048] First, the query operation on the IoTDB database is implemented by obtaining a connection from the connection pool; then different query methods are used according to the input parameters to obtain data that meets the query conditions; finally, the obtained data is provided to the concurrent buffer pool, and the next data acquisition process is started according to the requirements of the concurrent buffer pool.

[0049] (3) Execute data replay:

[0050] The replay system achieves smooth data replay through a custom-designed concurrent buffer pool module. This module, connected to the replay client and the IoTDB database, is key to the replay system. The concurrent buffer pool continuously sends replay data to the replay data requesting client through the replay client's interface, ensuring the performance and efficiency of the replay interface when acquiring time series data. Simultaneously, the concurrent buffer pool continuously retrieves upcoming time series data from the underlying database to promptly fill any vacant buffers.

[0051] While providing data to the data presentation layer, the concurrent buffer pool continuously obtains new data from the database of the historical data storage layer and fills the empty queues. The specific steps are as follows: when replaying data, the replay framework will first use the passed time series name to search the concurrent buffer pool for the corresponding time series data. If the multi-level buffer queue returned after the search is not empty, it means that the time series has been buffered before, and the returned data can be used directly. If the returned multi-level buffer queue is empty, it means that the time series has never been buffered before. At this time, the initialization method should be called to initialize the multi-level buffer queue; when initializing the multi-level buffer queue, the filling method of the multi-level buffer queue will be triggered. Filling the multi-level buffer queue involves two parameters: the multi-level buffer queue size and the priority queue size; when filling the buffer queue, the thread pool is used to fill the buffer queue to improve the efficiency of the system. In order to ensure the order between queues in the multi-level buffer queue, a task queue is used to identify the order of filling tasks; it can be divided into the following parts:

[0052] (a) Initialize the multi-level buffer queue

[0053] The initialization method first attempts to initialize the multi-level buffer queue corresponding to the specified time series. If the multi-level buffer queue is not empty, it is placed into the concurrent buffer pool. The core logic of initializing the multi-level buffer queue can be described as follows: First, the number of rows in the time series within the specified time range is queried. If the number of rows is 0, it returns. Otherwise, the multi-level buffer queue is initialized and the multi-level buffer queue's fill method is triggered.

[0054] (b) Parameters involved in filling a multi-level buffer queue

[0055] The filling method involves two parameters: the multi-level buffer queue size and the priority queue size. The multi-level buffer queue size can be configured based on the server. In theory, given sufficient resources, a larger multi-level buffer queue size results in higher replay efficiency. The priority queue can be considered a single-level buffer queue. Its size is determined based on a specified time range. Since the sampling interval of time series data is fixed, time series should have the same amount of data within the same time interval.

[0056] (c) Multi-level buffer queue workflow

[0057] Once initialized, the multi-level buffer queue can be used in subsequent steps: First, the buffer queue at the head of the multi-level buffer queue (the priority queue) is retrieved. This is the buffer queue that should be accessed at the current time point. After retrieving the specified buffer queue, the elements in the time series are evaluated, and the data that meets the given conditions is filtered and returned. After the filtering is completed, the start and end times of the data to be retrieved from the database are recorded. Finally, a buffer queue is added to the end of the queue to ensure efficient system replay.

[0058] (d) Specific method of filling multi-level buffer queue (task queue)

[0059] When filling the buffer queue, a thread pool is used to improve system efficiency. To ensure order between queues in the multi-level buffer queue, a task queue is used to identify the order in which tasks are filled. The task queue is a data structure defined by the ConcurrentLinkedQueue class in the Java language. It is a thread-safe blocking queue. Each element stored in it corresponds to the size of the buffer pool at a specific moment. Whenever the upper-level replay interface requests data, the system obtains the current buffer pool size and adds it to the task queue. After the replay interface receives the replay data, the buffer pool needs to fill the empty portion of the buffer queue. At this time, the system obtains the value of the head element in the current task queue and compares it with the current buffer pool size. Only when the two match will the data filling process begin. When filling the buffer queue, the system utilizes multithreading technology. Using Java's multithreaded programming techniques, multiple threads concurrently retrieve corresponding data from the database within their own specified time ranges. This concurrent operation avoids serial interaction with the database, reducing the time consumption that serial interaction would otherwise incur. After multiple task threads retrieve the corresponding data from the database, the task queue taskOrder is used to ensure that the retrieved data is placed into the multi-level buffer queue in a certain order. taskOrder is a thread-safe blocking queue. This operation ensures efficient concurrent execution of filling tasks and maintains order between queues.

[0060] (4) User display interface:

[0061] Users can select and set playback data and related parameters through the front-end page. The playback front-end page is divided into a playback parameter selection area and a playback data curve display area. The playback parameter selection area provides time, speed, and time series name for users to select, while the playback data curve display area presents the playback data in the form of a dynamic curve, allowing users to conduct more intuitive and convenient analysis.

Claims

1. A data replay method for sensor stream data, characterized in that: The steps include: Step 1: Install and configure Apache IoTDB. Step 2: Connect to IoTDB through the database connection pool and obtain data, and use the thread pool to enable multiple replay requests to be executed concurrently; Step 3: Data replay execution: Implement a concurrent buffer pool. The concurrent buffer pool is connected to the IoTDB database and the replay system data display layer. It continuously retrieves replay data from the IoTDB database and provides the data to the front-end page for display. The two processes of replay data retrieval and data provision to the front-end page are connected through the buffer pool in the middle, so that the two processes do not interfere with each other and can be carried out simultaneously. Step 4: During data replay, buffering technology and priority queues are used to ensure the normal operation of the concurrent buffer pool. The concurrent buffer pool used for data replay has corresponding keys: the time series name and a multi-level buffer queue composed of priority queues. This concurrent buffer pool composed of priority queues is named TimeSeriesPool. It internally defines the multi-level priority queues and the order of each buffer task to ensure the normal operation of the concurrent buffer pool. Step 5: In the replay data display layer, the front-end display page is used to interact directly with the user. The user selects and sets the replay data and related parameters through the front-end page, and the data display layer obtains the replay data from the buffer pool in the execution layer through the replay interface.

2. The data replay method for sensor stream data according to claim 1, characterized in that: In step 2, at the database connection layer, various query operations on the database are encapsulated into a Java class, including: querying according to start and end time, querying according to time series name, querying according to sensor, and querying according to data collection site; in addition, a database connection pool is implemented through coding, and a thread pool is implemented through Java multi-threaded programming.

3. The data replay method for sensor stream data according to claim 2, characterized in that: In step 2, the class that encapsulates multiple query operation methods calls different methods according to different inputs and returns corresponding time series data. The specific steps are: Input: start and end time, time series name, sensor name, data collection site name; Output: time series data that meets the above input conditions after screening; First, the query operation on the IoTDB database is implemented by obtaining a connection from the connection pool; then different query methods are used according to the input parameters to obtain data that meets the query conditions; finally, the obtained data is provided to the concurrent buffer pool, and the next data acquisition process is started according to the requirements of the concurrent buffer pool.

4. The data replay method for sensor stream data according to claim 1, characterized in that: In step 2, in step (3), while the concurrent buffer pool provides data to the data presentation layer, it continuously obtains new data from the database of the historical data storage layer and fills the empty queues. The specific steps are as follows: when replaying data, the data replay overall framework based on the concurrent buffer pool will first use the input time series name to search the concurrent buffer pool for the corresponding time series data. If the multi-level buffer queue returned after the search is not empty, it means that the time series has been buffered before, and the returned data can also be used directly; if the returned multi-level buffer queue is empty, it means that the time series has never been buffered before, and the initialization method should be called to initialize the multi-level buffer queue; when initializing the multi-level buffer queue, the filling method of the multi-level buffer queue will be triggered. Filling the multi-level buffer queue involves two parameters: the multi-level buffer queue size and the priority queue size; when filling the buffer queue, the thread pool is used to fill the buffer queue to improve the efficiency of the system. In order to ensure the order between queues in the multi-level buffer queue, a task queue is used to identify the order of filling tasks.

5. The data replay method for sensor stream data according to claim 4, characterized in that: The process of initializing the multi-level buffer queue is: The initialization method will first try to initialize the multi-level buffer queue corresponding to the specified time series. If the multi-level buffer queue is not empty, it will be placed in the concurrent buffer pool. The core logic of initializing the multi-level buffer queue can be described as follows: first query the number of rows of the time series within the specified time range. If the number of rows is 0, it will return; otherwise, the multi-level buffer queue will be initialized and the filling method of the multi-level buffer queue will be triggered.

6. The data replay method for sensor stream data according to claim 4, characterized in that: The parameter process involved in filling the multi-level buffer queue is: The filling method involves two parameters: the multi-level buffer queue size and the priority queue size. The multi-level buffer queue size is configured according to different servers; the priority queue size is determined according to the specified time range. Since the sampling time interval of time series data is fixed, the time series should have the same amount of data within the same time interval. The multi-level buffer queue workflow is: After the multi-level buffer queue is initialized, it can be used in subsequent steps: first, the buffer queue at the head of the queue is retrieved from the multi-level buffer queue. The buffer queue at the head of the queue is the buffer queue that should be accessed at the current time node. After the specified buffer queue is retrieved, the elements in the time series are judged, and the data that meets the given conditions in the time series is filtered out and returned. After the screening is completed, it is necessary to record the start time and end time of the data that should be retrieved from the database in the next step; finally, a buffer queue should be filled at the end of the queue.

7. The data replay method for sensor stream data according to claim 4, characterized in that: The specific method of filling the multi-level buffer queue is: When filling the buffer queue, a thread pool is used to fill the buffer queue; in order to ensure the order between queues in the multi-level buffer queue, a task queue is used to identify the order of filling tasks; when filling the buffer queue, multi-threading technology is adopted to allow multiple threads to retrieve the corresponding data from the database according to their own given time range; after multiple task threads retrieve the corresponding data from the database, the task queue taskOrder is used to ensure that multiple threads put the data into the multi-level buffer queue in a certain order after retrieving the data. TaskOrder is a thread-safe blocking queue.

8. A data replay system for sensor stream data implemented according to the method of any one of claims 1 to 7, characterized in that: It includes the historical data storage layer, database connection layer, data replay execution layer and replay data display layer arranged in sequence from bottom to top; The historical data storage layer uses the time series database Apache IoTDB to store historical stream data with timestamps collected by sensors; The database connection layer connects to IoTDB through the database connection pool and obtains data, and enables multiple replay requests to be executed concurrently through the thread pool; The data replay execution layer replays the sensor's historical data through a concurrent buffer pool. When a user requests data replay, the concurrent buffer pool is requested through the replay interface. The concurrent buffer pool provides data to the replay interface and interacts with the database of the underlying historical data storage layer through the thread pool and connection pool to fill its own data. The replay data display layer is a front-end display page that directly interacts with the user. The user selects and sets the replay data and related parameters through the front-end page, and the data display layer obtains the replay data from the buffer pool in the execution layer through the replay interface.

9. The data replay system for sensor stream data according to claim 8, characterized in that In the time series database Apache IoTDB, data is divided into multiple time series according to different collection sites. Each data stored in IoTDB consists of a timestamp and the collection value corresponding to that time, reflecting the sensor value that changes over time.

10. The data replay system for sensor stream data according to claim 8, characterized in that: The replay front-end page is divided into a replay parameter selection area and a replay data curve display area. The replay parameter selection area provides time, speed and time series name for users to select, while the replay data curve display area presents the replayed data in the form of a dynamic curve.

Images