Metacosmic data management method, apparatus and device, and storage medium

Abstract

The invention relates to the field of data management, in particular to a meta-universe data management method and device, equipment and a storage medium. The method comprises the following steps: performing periodic clock synchronization detection and delay compensation calculation on a plurality of meta universe platforms to generate a dynamic delay compensation function; business data streams uploaded by multiple platforms in parallel are collected, platform delay compensation and causal depth analysis are carried out based on a dynamic delay compensation function, and a data stream causal dependency graph is constructed; performing update sequence conflict detection based on the data flow causal dependency graph, and constructing a conflict database; carrying out self-adaptive resolution processing and data synchronous convergence on the conflict database to generate a data synchronous processing record; and carrying out platform synchronization performance analysis one by one based on the data synchronization processing record, and executing calculation and storage resource redistribution management of each platform. According to the invention, the overall synchronization efficiency improvement and the management response capability of a plurality of meta universe platforms are realized.

Description

Technical Field

[0001] This invention relates to the field of data management, and more particularly to a metaverse data management method, apparatus, device, and storage medium. Background Technology

[0002] As the concept of the Metaverse deepens and its practical application advances, it is gradually constructing a highly immersive, real-time interactive virtual world driven by the integration of various cutting-edge technologies such as virtual reality, augmented reality, blockchain, and artificial intelligence. Within the Metaverse, users can transcend physical space limitations, achieving data sharing, content collaboration, and real-time interaction across multiple platforms and scenarios, with wide applications in social entertainment, digital twins, remote work, virtual conferencing, and smart manufacturing. Against this backdrop, the number of Metaverse platforms is rapidly increasing, and collaboration and data interaction between different platforms are frequent, driving the rapid development of cross-platform data management and synchronization technologies.

[0003] The metaverse involves massive amounts of data, complex structures, and frequent updates. Due to differences in physical location, network environment, and system architecture, different platforms exhibit significant differences in timestamps during data generation and processing. This temporal heterogeneity not only affects the consistency of data across multiple platforms but also severely restricts the smoothness of user interaction and immersive experience in virtual scenarios. It can even lead to business logic errors caused by disordered data causality, reducing the reliability and stability of the entire metaverse system.

[0004] Some metaverse platforms employ timing synchronization mechanisms that rely primarily on simple timestamps, periodic data retrieval, or global logical clocks. While these methods can achieve basic data synchronization to some extent, they still have significant limitations when faced with complex data streams that are running concurrently across multiple platforms and are dynamically changing. For example, traditional mechanisms struggle to accurately identify data out-of-order issues caused by network fluctuations or processing delays, lack the ability to model causal relationships in data, and cannot dynamically adjust synchronization strategies to adapt to constantly changing business scenarios and platform performance. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention proposes a metaverse data management method, apparatus, device, and storage medium to resolve at least one of the aforementioned technical problems.

[0006] To achieve the above objectives, the present invention provides a metaverse data management method, comprising the following steps: Step S1: Perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate a dynamic delay compensation function; Step S2: Collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and causal depth analysis based on the dynamic latency compensation function, and construct a data stream causal dependency graph; Step S3: Detect update order conflicts based on the data flow causal dependency graph and build a conflict database; Step S4: Adaptively resolve and synchronize the conflict database, and generate data synchronization processing records; Step S5: Perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and perform reallocation management of computing and storage resources on each platform.

[0007] This specification provides a metaverse data management device for performing the metaverse data management method described above, comprising: The delay compensation calculation unit is used to perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate dynamic delay compensation functions. The causal analysis unit is used to collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and in-depth causal analysis based on the dynamic latency compensation function, and construct a causal dependency graph of the data stream. The conflict detection unit is used to detect update order conflicts based on the causal dependency graph of the data flow and to build a conflict database. The conflict resolution unit is used to adaptively resolve and synchronize data in the conflict database, and generate data synchronization processing records. The synchronization data management unit is used to perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and to perform reallocation management of computing and storage resources for each platform.

[0008] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the metaverse data management method described in any of the above claims.

[0009] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the metaverse data management method described in any of the preceding claims.

[0010] The specific benefits of this invention are as follows: By periodically probing clock synchronization, it solves the clock deviation problem between different metaverse platforms, ensuring all platforms operate under a unified time reference. The delay compensation function dynamically adjusts based on real-time probe data, adapting to network latency fluctuations and significantly improving synchronization accuracy and real-time performance. Precise clock synchronization and delay compensation effectively reduce the risk of data asynchrony caused by latency differences, improving cross-platform data consistency. Through delay compensation and causal depth analysis, the causal order of business data flows between different platforms can be clearly identified, avoiding confusion of causal relationships due to network latency. The causal dependency graph provides structured support for subsequent data consistency verification and conflict detection, improving the accuracy and efficiency of analysis. It effectively manages parallel data uploads from multiple platforms, ensuring the logical integrity and sequence of data flows and improving cross-platform business collaboration capabilities. Utilizing causal dependencies, it accurately identifies sequential conflicts in data updates across multiple platforms, preventing data inconsistencies caused by ignored conflicts. Centralized management of conflict information through a conflict database supports subsequent automated conflict resolution and decision-making, improving the intelligence level of synchronization processing. Early detection and recording of potential conflicts helps prevent data error propagation, ensuring the overall stability and security of the system. The adaptive conflict resolution mechanism flexibly adjusts processing strategies based on conflict type and business scenario, reducing manual intervention and improving efficiency. Through conflict resolution and synchronization convergence, it achieves eventual data consistency across multiple platforms, enhancing the reliability of cross-platform collaboration. Detailed records of the synchronization and conflict handling process facilitate subsequent auditing, backtracking, and optimization, improving system transparency and maintainability. Analysis of synchronization processing records accurately identifies performance bottlenecks on each platform during synchronization, supporting targeted optimization. Based on performance analysis results, it dynamically adjusts the allocation of computing and storage resources, improving overall synchronization efficiency and system responsiveness. Reasonable resource allocation ensures stable system operation under high load and multi-platform expansion, meeting the complex business needs of Metaverse. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the steps of a metaverse data management method according to the present invention. Figure 2 This is a flowchart illustrating the detailed implementation steps of step S1. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] This application provides a metaverse data management method, apparatus, device, and storage medium. The execution entities of the method, apparatus, device, and storage medium include, but are not limited to, mechanical equipment, data processing platforms, cloud server nodes, network upload devices, etc., which can be considered general computing nodes of this application. The data processing platform includes, but is not limited to, at least one of an audio / image management system, an information management system, and a cloud-based data management system.

[0014] Please see Figures 1 to 2 This invention provides a metaverse data management method, comprising the following steps: Step S1: Perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate a dynamic delay compensation function; Step S2: Collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and causal depth analysis based on the dynamic latency compensation function, and construct a data stream causal dependency graph; Step S3: Detect update order conflicts based on the data flow causal dependency graph and build a conflict database; Step S4: Adaptively resolve and synchronize the conflict database, and generate data synchronization processing records; Step S5: Perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and perform reallocation management of computing and storage resources on each platform.

[0015] In the embodiments of the present invention, see Figure 1 The diagram below illustrates the steps of a metaverse data management method according to the present invention. In this example, the steps of the metaverse data management method include: Step S1: Perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate a dynamic delay compensation function; In this embodiment, accurate clock synchronization is crucial for ensuring data synchronization across multiple platforms. By periodically performing clock synchronization probes on each platform, the deviation data between the local clock timestamps of each platform and a unified standard time source (such as GPS or the Network Time Protocol NTP) is collected. This process employs distributed clock synchronization technology, combining timestamp capture and bidirectional delay measurement methods. By periodically sending synchronization requests and receiving response packets, round-trip delay and one-way transmission time are extracted to achieve accurate measurement of the clock status of each platform. The collected clock data undergoes multiple sampling and statistical filtering (such as Kalman filtering or moving median filtering) to eliminate occasional errors and the impact of network fluctuations, ensuring data stability and accuracy.

[0016] Based on the timestamp differences between the standard time source and the clocks of each platform, the current clock offset and latency are calculated. Subsequently, according to a predefined time offset calculation period, difference analysis and trend fitting are performed on the time series of latency for each platform. The clock drift rate is then calculated using linear regression or autoregressive models, forming a dynamic clock drift curve. Furthermore, latency fluctuation characteristics are identified through a probability distribution model, and a dynamic latency compensation function is designed based on the clock drift data. This function possesses time-varying adaptive capabilities, enabling real-time adjustment of latency compensation parameters to adapt to network fluctuations and platform state changes. This provides a high-precision time reference for the timing synchronization of subsequent business data streams, significantly improving data consistency across multiple platforms.

[0017] Step S2: Collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and causal depth analysis based on the dynamic latency compensation function, and construct a data stream causal dependency graph; In this embodiment, business data streams uploaded in parallel from different metaverse platforms are continuously collected. Each data stream contains a timestamp, event type, and related business information. During initial processing, the dynamic delay compensation function generated in step S1 is used to adaptively correct the original reporting timestamps of each data packet, eliminating time errors caused by network latency and clock drift, thereby obtaining a delay-corrected timestamp. The delay correction process employs a timestamp adjustment algorithm to ensure a unified time baseline for data streams across multiple platforms, improving the timing accuracy of the data.

[0018] The delayed-corrected data stream is sequentially sorted to generate a global business event sequence. To delve deeper into the causal relationships between these events, causal inference and graph modeling techniques are employed, combined with event semantic parsing, to classify and label events (e.g., user behavior, asset flow, virtual scene status). Through multi-dimensional association analysis based on time and semantic tags, causal links and concurrency relationships between events are extracted, constructing a data stream causal dependency graph based on a directed acyclic graph (DAG). This graph model not only reveals the temporal dependencies of events but also characterizes the semantic coupling between them, providing a structured causal foundation for subsequent conflict detection and synchronization management.

[0019] Step S3: Detect update order conflicts based on the data flow causal dependency graph and build a conflict database; In this embodiment, after establishing a complete data flow causal dependency graph, conflict detection is further carried out. The core of update order conflict detection lies in identifying conflict types such as time sequence reversal, duplicate modifications, and link interruptions caused by parallel or delayed business operations between different platforms. The detection process is based on the causal dependency graph structure, traversing each event node and its causal path, and using time sequence constraint verification and event consistency rules to determine conflict points. The specific detection method combines time window sliding scan, event version number comparison, and data object state comparison to ensure accurate location of conflict nodes.

[0020] Identified conflict nodes are categorized and labeled based on conflict characteristics, forming a structured conflict database. This database records multi-dimensional attributes such as conflict type, conflict data objects, involved platforms, occurrence time, and conflict severity, supporting subsequent conflict analysis and resolution. Through multi-dimensional indexing and query optimization techniques, efficient management and rapid access to large-scale conflict data are achieved. As a core data asset for multi-platform synchronization and coordination, the conflict database ensures the comprehensiveness and timeliness of conflict information, serving as a key support for improving synchronization accuracy and stability.

[0021] Step S4: Adaptively resolve and synchronize the conflict database, and generate data synchronization processing records; In this embodiment, after conflict detection is completed, the conflict resolution phase begins, aiming to restore data consistency and synchronization. Resolution is based on calculating the actual execution order using a data flow causal dependency graph. Timing replay technology is used to correct data for conflict nodes with reversed timing sequences, ensuring logical consistency of the event sequence. For conflict nodes with repeated modifications, a conflict merging algorithm is used, combining business semantic analysis and data priority strategies, to merge multiple versions of modifications into a unified version, reducing redundancy and conflict frequency. For conflict nodes with broken links, missing data flow parsing and simulated replay are used to complete the broken link, achieving event flow closure.

[0022] The digestion process dynamically adjusts parameters, supporting feedback-based adaptive optimization to improve digestion efficiency and accuracy. Digestion results are aggregated to form a complete data synchronization processing record, including digestion time, strategy type, involved data, and performance metrics (such as edit distance changes and fusion validation pass rate). This record provides detailed evidence for subsequent performance evaluation and synchronization optimization, promoting closed-loop management and continuous improvement of the synchronization process.

[0023] Step S5: Perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and perform reallocation management of computing and storage resources on each platform.

[0024] In this embodiment, synchronization performance analysis is conducted platform by platform based on key performance data in the synchronization processing records. Through statistical analysis and aggregation calculations, multi-dimensional performance indicators such as average resolution latency, conflict rate, and fusion verification pass rate are extracted for each platform to construct platform performance benchmark curves, reflecting the dynamic changes in synchronization efficiency and quality over time. The benchmark curves identify performance degradation nodes through anomaly detection algorithms, and, combined with data volume distribution and resource consumption data, provide in-depth analysis of performance bottleneck factors.

[0025] Based on the bottleneck analysis results, a resource reallocation strategy for computing and storage was designed. An optimized scheduling algorithm was used to dynamically adjust resource quotas across platforms to alleviate bottleneck pressure. The resource adjustment scheme combines load prediction and business priority to ensure maximum resource utilization and business continuity. After simulation verification, the reallocation strategy was deployed. Combined with real-time monitoring and an adaptive synchronization strategy adjustment mechanism, continuous optimization of synchronization performance and efficient collaborative management of multi-platform resources were achieved, ensuring the stable and efficient operation of the Metaverse service.

[0026] In this embodiment, see Figure 2 The diagram below illustrates the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: Periodic clock synchronization detection is performed on multiple metaverse platforms to extract clock information from multiple platforms; Based on a standard time source, timestamp differences are calculated for clock information from multiple platforms, and time delay values ​​for each platform are extracted. Define the time offset calculation period; Based on the time offset calculation period, the delay difference change of time delay values ​​of each platform is analyzed to generate clock drift rate; Timing evolution analysis is performed based on clock drift rate to generate clock drift curves for multiple platforms; Delay distribution is identified based on the clock drift curve, and delay compensation calculations are performed to generate a dynamic delay compensation function.

[0027] In this embodiment, to achieve data synchronization between multiple platforms in the metaverse, it is necessary to periodically collect the current time status of each platform. Since the clocks of each platform operate on different physical servers or virtual environments, inconsistencies exist; therefore, a periodic clock synchronization probe mechanism needs to be constructed. The probe method employs a fixed-interval active request strategy, using standard time communication protocols (such as NTP or PTP) or platform-supported interfaces (such as APIs or WebSocket timestamp fields) as the basis, sending a time synchronization request to the target platform every 60 seconds. Each request records three key time points: the time the request was sent locally (T_send), the timestamp returned by the platform (T_platform), and the local time of receiving the response (T_receive). Through continuous requests and time recording, clock status data for each platform at a specific moment can be constructed. Within each cycle, it is recommended to perform at least three independent probes and average the returned timestamps to reduce the impact of network jitter and platform fluctuations on the collected data. The collection results are saved in a unified UTC format to ensure data timezone consistency. This periodic probing process allows for the continuous acquisition of time trajectory data for each platform over 24 hours, laying the data foundation for subsequent time deviation analysis and drift modeling. After collecting clock information from each platform, the timestamps of each platform need to be compared against a unified standard time source to extract the relative delay value. The standard time source should possess stability and high accuracy, typically using a globally trusted NTP server (such as ntp.pool.org) or an authoritative time service interface provided by an international time service center. For each set of collected data, the difference ΔT between the platform's returned time (T_platform) and the standard time (T_standard) is calculated, representing the time delay value. To improve accuracy, the symmetry of network transmission delay and the impact of request round-trip time need to be considered simultaneously. A commonly used estimation method is: Delay = [(T_receive...]] T_send) [Processing time estimate] ÷ 2 yields the actual clock offset for each request. All delay data is structured by platform and sampling time to form a time delay sequence. Through continuous acquisition, the range, direction (advanced or delayed), and trend of delay fluctuation between each platform and standard time can be observed. These delay values ​​not only reflect the instantaneous synchronization of the platform clock but also provide a continuous input data stream for subsequent offset cycle modeling and compensation function construction.

[0028] Time offset analysis must be based on a clearly defined period division to effectively model the platform's clock variation behavior. The time offset calculation period is defined as dividing the time axis into fixed intervals to calculate the average latency and trend within each period. A dual-period structure is recommended: a short period of 10 minutes to capture fine-grained clock fluctuations; and a long period of 1 hour to identify the stability and offset of the platform clock. Within each period, the collected latency values ​​are statistically processed to calculate the average, standard deviation, and maximum and minimum values, forming a time offset characteristic description for that period. This method effectively smooths outliers caused by network fluctuations at individual moments, ensuring the statistical reliability of the data. After forming a continuous offset period sequence across the entire time axis, accurate basic data can be provided for subsequent drift rate calculations. Simultaneously, by setting the period, the platform clock can be monitored to identify time periods with significant drift tendencies, which helps in the dynamic adjustment and response scheduling of subsequent latency compensation strategies. After defining the time offset calculation period, it is necessary to further analyze the differences in latency values ​​between adjacent periods to calculate the clock drift rate. Drift rate is defined as the rate of change of the platform clock relative to its offset per unit time, commonly expressed in milliseconds per minute or seconds per hour. The specific calculation method is as follows: between two consecutive time periods, take the average time delay value for each period, calculate the difference, and finally divide by the period length. For example, if the average offset of a platform in the first period is... 0.95 seconds, in the next cycle If the time is 1.05 seconds, then the drift rate is ( 1.05 ( 0.95)) ÷ 10 minutes = 0.01 seconds / 10 minutes, that is 1 millisecond / minute. This metric reflects the acceleration or deceleration trend of the platform clock; negative values ​​indicate a lagging trend, while positive values ​​indicate a gradual advancement. To further improve the analysis quality, it is recommended to use a moving average or exponentially weighted method to process the raw drift rate, thereby mitigating the impact of abnormal fluctuations caused by occasional offsets. By constructing a clock drift rate sequence, the platform clock state can be classified and identified at different time periods, such as into status labels like "stable drift period," "violent fluctuation period," and "clock callback period," forming a dynamic assessment of the platform clock behavior.

[0029] Based on the clock drift rate, it can be further accumulated over time to generate a complete clock drift curve. This curve shows the cumulative change trajectory of the platform's clock offset relative to standard time over time. The construction method involves multiplying the drift rate of each time offset period by the period duration to obtain the offset within that time period, and then continuously accumulating these values. For example, if the drift rates of a platform for three consecutive periods are... 0.001 0.002 0.0015 seconds / minute corresponds to a cumulative offset of [value] over a 10-minute period. 0.01 0.02 The total offset curve is obtained by accumulating 0.015 seconds. This method provides a visual indication of whether the platform clock tends to advance or delay, and whether it maintains a linear trend, exhibits periodic oscillations, or shows abrupt changes. The slope of the drift curve can be used to determine the operational status of the clock synchronization strategy, whether there are frequent callbacks, synchronization failures, or the platform entering a high-load operation state within a specific time period. Comparative analysis of drift curves from different platforms can identify which platforms have higher time stability, thereby optimizing the allocation priority of synchronization resources. During continuous sampling and curve generation, it is recommended to perform polynomial fitting or trend decomposition on the drift curve to extract long-term offset trends and short-term disturbance information. Analysis of the clock drift curves can identify the statistical distribution pattern of delay offset for each platform, and a dynamic delay compensation function can be constructed accordingly. Distribution fitting is performed on the delay data for each platform to identify whether it conforms to a normal, log-normal, gamma, or skewed distribution. Different distribution forms reflect the platform's behavioral characteristics at the time synchronization level, such as stability and susceptibility to severe random fluctuations. After identifying the distribution pattern, a compensation function D(t) is constructed based on the distribution parameters. The input to this function is the current time t or the identifier of the time offset period, and the output is the compensation value to be applied to the platform timestamp. The core calculation logic of the compensation function can be based on the derivative or difference form of the drift curve, for example, using the average drift rate within a sliding window, multiplied by the time interval from the current time to the data usage point, as the delay compensation amount. The final corrected timestamp can be expressed as T_corrected = T_original + D(t). This function can be called in real time before data interaction between platforms to dynamically adjust the original data timestamp, ensuring that data generated by multiple platforms are aligned on the timeline. This dynamic compensation mechanism not only improves the accuracy of data synchronization but also provides a solid timing guarantee foundation for multi-platform joint computing, real-time collaborative rendering, and cross-platform state consistency. By continuously optimizing the compensation function structure and update frequency, the time robustness under multi-platform and cross-regional conditions can be further enhanced.

[0030] In this embodiment, step S2 includes the following steps: Collect business data streams uploaded in parallel from multiple platforms; Calculate and mark the reporting timestamp for the business data stream; Based on the dynamic delay compensation function, adaptive platform delay compensation is performed on the reported timestamp to obtain the delay correction timestamp; The business data stream is sorted in time sequence according to the delay correction timestamp to generate a global business event sequence; Perform event semantic parsing on the global business event sequence to identify multiple event semantic tags; The multiple event semantic table bridges include user behavior class, asset flow field class and virtual scene state class; Based on multiple event semantic tags, perform in-depth causal analysis to extract causal links and concurrency relationships in data streams; Semantic association topology fitting is performed on delay correction timestamps, causal links of data streams, and concurrency relationships to construct a causal dependency graph of data streams.

[0031] In this embodiment, within the metaverse multi-platform architecture, different platforms continuously generate a large volume of business data streams in parallel, including user operation records, asset change events, and scene status updates. To achieve global data synchronization, a unified data acquisition mechanism needs to be built to provide real-time access to business data streams from multiple platforms. The key to this step is establishing a multi-platform data reporting channel that supports high concurrency and low latency parallel data reception. Each platform sends business data to the unified data access layer through standardized transmission protocols (such as gRPC, Kafka, MQTT, or HTTP / 2 push interfaces). The data stream contains necessary fields, such as the data source platform identifier, original business content, timestamp field, and event ID. The design requires the acquisition system to have platform access adapters to unify the format of data structures from different platforms and perform preprocessing, including field parsing, encoding conversion, and data integrity verification. Data from each platform is concurrently received in an event-driven manner, and the acquisition system needs to support millisecond-level precision for receiving and marking data to ensure a unified time base for subsequent processing. During continuous operation throughout the day, this mechanism can stably access tens of millions of event data points, providing a data foundation for multi-platform event fusion and unified time series construction. After multi-platform business data streams are collected, each data item must be immediately marked with a "reporting timestamp." This timestamp represents the local reception time of the data upon access and is one of the core parameters for constructing a unified time series. Because platform business data may have upload delays or local time errors, this reporting timestamp should not rely on the time field in the original data but should be recorded locally by the receiving entity, with an accuracy of at least milliseconds. For each received data stream, a reporting timestamp T_report is automatically added upon access, serving as the benchmark for subsequent delay compensation and sorting processing. To improve processing efficiency, the entire process should be completed through an asynchronous non-blocking mechanism, using message queues or streaming processing engines for data buffering and timestamp marking. Platform source information should also be recorded during the marking process for association with the dynamic compensation function. Once marked, the reporting timestamp becomes the primary time reference value for business events and remains unchanged throughout the entire data synchronization process. This step ensures that all business data has a time stamp with the same time zone, format, and recording accuracy before entering the unified processing flow, laying the foundation for eliminating clock differences between platforms and achieving unified global event sorting.

[0032] Due to differences in physical server location, network paths, and local clock offsets, the upload times of data vary across different metaverse platforms. To ensure that data is logically ordered according to its actual occurrence sequence, delay compensation is required for the reported timestamps. This delay compensation is based on a previously generated dynamic delay compensation function. Each platform has an independent function model, with the current upload time as input and the delay value to be compensated at that moment as output. Specifically, for each data entry, its upload time T_report and platform identifier are read, the corresponding compensation function D(t) is called, the compensation value ΔT = D(T_report) is calculated, and a corrected timestamp T_corrected = T_report + ΔT is generated. This compensation method supports adaptive updates; the compensation function is dynamically adjusted based on a drift curve, ensuring that the compensation value changes in real time. The call and calculation of the compensation function should be integrated into the data stream processing chain, performing the time correction operation in a streaming manner to ensure low-latency processing capabilities under high concurrency. The corrected timestamp serves as the primary time key for subsequent sorting and event modeling, providing global time alignment capabilities and forming the foundation for achieving time sequence consistency across platforms and identifying causal relationships between events. The delayed corrected timestamp provides a unified time base for data from all platforms. Next, all collected business data streams need to be sorted to reconstruct the event occurrence order chronologically, generating a global business event sequence. The sorting logic is based on ascending order of the corrected T_corrected timestamps, ensuring that even if multiple platforms report events almost simultaneously, their logical positions within the global event stream can still be determined. To support real-time requirements, sorting should employ a streaming sorting engine or an event time window mechanism; frameworks such as Apache Flink and Spark Streaming can serve as foundational support. During processing, issues such as timestamp duplication and precision conflicts also need to be addressed. For example, when multiple events are reported within the same millisecond, event priority, platform ID, or event type can be introduced as secondary sorting conditions to ensure global order stability. Ultimately, all events form an ordered, continuous, and cross-platform unified event sequence, capable of causal reconstruction and time sequence logic analysis.

[0033] After sorting the global business event sequence, each event needs semantic recognition to clarify its actual meaning within the metaverse environment. Event semantic parsing involves analyzing event content fields, operation types, context parameters, and other information, combined with the business rules and data structure of the metaverse platform, to assign semantic tags to events. The classification of semantic tags should cover the main interaction domains of the metaverse, primarily divided into three categories: user behavior (e.g., login, movement, interaction), asset transfer (e.g., item trading, resource transfer), and virtual scene state (e.g., environmental changes, area updates). The parsing process can be based on rule matching engines (e.g., DSL parsing), machine learning models (e.g., sequence classifiers), or multi-label classification technology to assign structured tags to event content. During processing, a one-to-one mapping relationship between events and their semantic tags must be established to ensure the tags are traceable and interpretable. All semantic tags are attached to the corresponding business events, forming structured data records that provide a semantic foundation for subsequent processing such as event causal analysis, behavior modeling, and trend prediction. This process elevates the semantic level of the data flow, transforming raw data into understandable and analyzable structured knowledge units. In the event semantic annotation system, to ensure coverage of core interactive scenarios within the metaverse, the semantic tag system design should possess both completeness and scalability. The main tag types can be categorized into three main types: user behavior tags, asset transfer tags, and virtual scene state tags. User behavior tags identify individual user actions on the platform, such as "entering a scene," "clicking an object," "voice communication," and "path movement." Asset transfer tags identify resource or item state change events, such as "NFT transactions," "item crafting," "currency payment," and "permission transfer." Virtual scene state tags focus on dynamic scene changes, such as "scene day / night switching," "map reconstruction," "multi-user collaborative editing," and "scene crash." Each tag type can be further refined into multiple sub-tags, supporting complex behavior recognition. During tag assignment, a unified tag ontology library should be constructed, defining the semantic boundaries, triggering conditions, and interrelationships for each tag type. Simultaneously, the platform needs to output event semantic metadata to improve tag recognition accuracy.

[0034] Causal analysis identifies direct, indirect, or concurrent influences between events based on multiple dimensions, including time sequence, event type, participating entities, and triggering mechanisms. For example, if a user triggers an "asset transaction" event immediately after clicking on an asset, a causal chain is formed; if two users simultaneously trigger an "enter scene" operation, causing a change in scene capacity, a concurrent relationship is established. The analysis process can be modeled using causal inference models (such as Granger causality and Bayesian Networks), time window dependency graphs, and event attribution mechanisms. Each event in the data stream is analyzed into causal nodes based on its semantic label, occurrence time, and context, connecting to form an event chain structure. Concurrency relationships are identified by comparing the overlap of events from different platforms or user behaviors within the same time window. A semantic data stream causal dependency graph is constructed by uniformly modeling the delay-corrected time information, causal relationships, and concurrency relationships between events. This graph uses "events" as nodes and "causal relationships" or "concurrent paths" as edges, forming a directed graph or time-series graph structure. Nodes are accompanied by metadata such as timestamps, semantic labels, and platform information. During topology fitting, the sequential dependency paths of events are first established based on timestamps and causal chains. Then, concurrent nodes are identified and marked as special topological connections using logical judgment or concurrency weight estimation. Finally, all nodes and edge structures are uniformly stored and indexed to construct a cross-platform, cross-user, and cross-semantic data flow knowledge network. This dependency graph can be used for advanced functional scenarios such as real-time data playback, behavior prediction, anomaly detection, and policy rollback, serving as a core carrier for multi-platform integration and collaborative data analysis. This structure is continuously expandable and dynamically updated, supporting the rapid integration of newly accessed event streams into the graph according to rules, forming the core causal model in metaverse data management.

[0035] In this embodiment, step S3 includes the following steps: Incremental update identification is performed on the business data stream, and incremental update data packets are extracted; Data update traceability is performed on incremental update data packets to obtain the data update chain; Based on the causal dependency graph of the data flow, update order conflict detection is performed on the data update chain, and conflicting nodes in the data update are marked. Data update conflict nodes are classified and labeled to obtain multiple types of conflict nodes, including time sequence reversal conflict nodes, repeated modification conflict nodes, and interrupted link conflict nodes. Identify data objects and conflict platforms of multiple types of conflict nodes; Statistical analysis is performed on the data objects and conflict platforms to construct a conflict database.

[0036] In this embodiment, during the business interaction process across multiple platforms in the metaverse, platform business data exhibits high-frequency changes. To avoid repeatedly processing the entire data stream, an incremental update identification mechanism must be introduced to capture new, changed, and removed information in the business data of each platform in real time. The core objective of incremental identification is to extract update data packets containing only the changed data from continuous business data streams. This process relies on a comparison mechanism, requiring the maintenance of historical snapshot versions of each data object and comparing the currently reported data with historical versions at the field level. The comparison scope includes key business fields such as object status, location information, owner identifier, and attribute values. If there are field differences between the current data object and the previous state, it is marked as an incremental change, and the changed fields and related meta-information are extracted to form a structured "incremental update data packet." This data packet contains data object ID, change time, changed fields, source platform, version number, etc., possessing a complete update context. This mechanism effectively reduces data synchronization redundancy, improves subsequent processing efficiency, and provides smaller-granular basic data units for update chain construction and conflict detection. After obtaining the incremental update data packet, it is necessary to perform update tracing processing to identify the continuous change process of the same data object at different times and platforms, constructing the update chain of the data object. Update tracing groups incremental data belonging to the same object based on its unique identifier (such as resource ID, user ID, or scene node ID), sorting and associating them chronologically. The update chain structure resembles a time-series linked list, with nodes representing each change and edges indicating temporal and causal relationships between changes. Each update node records information such as change time, platform origin, modified content, version number, and operation type. During tracing, special handling is required for concurrent updates and cross-platform writes; each change record should be assigned a logical version number to identify the order of modifications during sorting. The update chain not only fully displays the evolution path of a data object's lifecycle but also provides causal context for subsequent update order conflict detection. Through continuous tracing, the global change process of data objects and their consistency across multiple platforms can be identified, providing fundamental support for maintaining data consistency.

[0037] After establishing the data update chain, it is necessary to perform sequence conflict detection to identify version overwriting, concurrency conflicts, or update disorder issues that occur in multi-platform environments. This detection is based on a "data flow causal dependency graph," comparing the causal path of events to determine whether update operations violate sequential logic. In the dependency graph, if node A is a causal predecessor of node B, then any change operation of B should not be earlier than the completion time of A's change; if an operation violating this causal order is detected in the update chain, it is determined to be an "update order conflict." The conflict detection logic needs to combine the logical relationship between timestamps, platform versions, semantic tags, and update paths for judgment. The detection process traverses the update chain on a data object-by-data basis, comparing each node with its predecessor node. If time inversion, duplicate field rewriting, or disjointed jumps are found, it is marked as a conflict node. Each marked conflict node is accompanied by the conflict type, affected fields, platform source, and its position index in the causal graph, providing a processing entry point for subsequent classification labeling and compensation mechanisms. All update nodes marked as conflicts need to be classified in detail to adopt targeted processing strategies for different conflict types. Conflict nodes can be categorized into three main types based on their causes and manifestations: time-sequence reversal conflicts, duplicate modification conflicts, and broken link conflicts. Time-sequence reversal conflicts occur when an update operation happens before its logically dependent nodes, violating the causal order of events; this is commonly seen in overwriting behavior caused by concurrent writes across multiple platforms. Duplicate modification conflicts refer to multiple platforms making repeated or invalid modifications to the same field within a short period, resulting in uncertain data status or wasted resources. Broken link conflicts occur when certain change nodes fail to effectively connect with their preceding and following nodes in the update chain, resulting in logical breaks or version jumps, causing the link to fail to fully express the data evolution path. During the classification and labeling process, each conflict node needs to be labeled according to factors such as the update chain context, time logic, and platform write records, and its conflict dimensions (time, field, dependency relationship) and severity level should be recorded. This process forms structured conflict labels, providing data support for conflict statistics, automatic repair, and manual intervention.

[0038] After classifying the conflicts, it is necessary to further identify the data object identifiers corresponding to each conflict node and the conflicting platforms involved. Data object identification relies on the object ID information recorded in the update chain, while the conflicting platforms are extracted from the source platform field of each node. By aggregating all conflict nodes and their associated information, a mapping structure can be generated: each data object corresponds to several conflict types, and each conflict type involves one or more platforms. The identification process requires traversing all conflict node records, classifying and aggregating conflict events for the same data object, and marking conflict pairs between platforms. For example, if an asset object is modified simultaneously on Meta and The Sandbox and there is a time sequence issue, the object will be marked as a "time sequence reversal conflict" object, and the conflicting platforms will be Meta and The Sandbox. This identification process constructs a multi-dimensional mapping of object—conflict type—platform, providing a basic data structure for subsequent conflict impact assessment, platform collaboration optimization, and responsibility attribution. Through this identification step, the distribution patterns of conflicts and the structural characteristics of inter-platform collaboration issues can be fully grasped. After completing the identification and classification of conflict nodes, a comprehensive statistical analysis of all relevant data objects and conflicting platforms is required to construct a comprehensive conflict database. This database centers on conflict events, recording detailed information for each conflict, including data object ID, conflict type, involved platforms, conflict time, affected fields, conflict frequency, and link location. Statistical analysis dimensions cover multiple levels: by platform, it tracks conflict frequency and distribution trends to identify which platforms are more prone to triggering conflicts during specific time periods or operation types; by conflict type, it tracks the proportion of various conflict types across different platforms to assess the stability and consistency of platform write behavior; and by data object, it tracks conflict concentration to identify high-risk or frequently modified objects as key areas for subsequent optimization and auditing. The conflict database not only supports structured queries but also time-series playback, conflict tracing, and impact analysis. The database design should support continuous updates and cross-batch comparisons, enabling long-term tracking of conflict evolution trends during multi-platform operation, forming a dynamic data consistency governance mechanism, and providing a data foundation for automatic repair strategies and platform write optimization.

[0039] In this embodiment, step S4 includes the following steps: Adaptive resolution processing is applied to the conflict database to generate conflict resolution data and conflict resolution strategies. Based on the conflict resolution data, the original data edit distance of the conflict database is calculated to generate fusion verification indicators; Data synchronization and aggregation are performed on fusion verification indicators, conflict resolution data and conflict resolution strategies to generate synchronization processing records; The adaptive digestion process specifically includes; Calculate the actual execution order of data streams based on the causal dependency graph of the data stream; Based on the actual execution order of the data stream, the time-reversed conflict nodes are replayed and modified to obtain a time-consistent data stream. For nodes that are repeatedly modified and conflict, business semantics and data priority are adjusted, and duplicate merging is performed to generate a fused data stream. Missing data streams are parsed based on the causal dependency graph of the data stream to obtain the missing data streams; The closed link data stream is obtained by simulating and replaying the conflict nodes of the interrupted link based on the missing data stream.

[0040] In this embodiment, after the conflict database is established, an adaptive conflict resolution process needs to be executed for each type of conflict entry recorded within it. This process is not a one-size-fits-all uniform rule, but rather a dynamic generation of processing solutions based on conflict type, platform behavior patterns, data priority, and semantic context to achieve personalized conflict repair. First, the conflict database is traversed, categorized by conflict type, and the key fields involved in each type of conflict and their platform behavior characteristics are extracted. Based on this, a conflict resolution strategy is generated by combining a rule engine with dynamic strategy templates. For example, for time-reversal conflicts, the strategy might be to reorder based on causal order; for repeated modification conflicts, the strategy might be to merge fields according to weight priority; for interrupted link conflicts, data simulation recovery or inference patch generation is attempted. Each strategy corresponds to one or more conflict nodes, and simultaneously generates a set of "conflict resolution data," which is the structured content expected to replace the original data after repair. During strategy generation, metadata such as platform reputation, write frequency, and data sensitivity also needs to be considered to improve the rationality of processing decisions. Before executing the conflict resolution strategy, the differences between the resolved data and the original conflict data need to be quantified to assess the impact and rationality of data modification. This process is achieved by calculating edit distance. Specifically, the conflict resolution data is used as the "target state," and the original conflict node data is used as the "current state." The minimum number of operation steps required to transition from the current state to the target state is calculated at the field level. Operation types include field insertion, deletion, and modification. The structured data is matched using the general Levenshtein distance or an improved multidimensional edit distance model. A larger edit distance indicates greater data modification and may involve more complex semantic adjustments; a smaller distance indicates more conservative data changes, meeting stability requirements. In addition to the basic distance value, a set of fusion verification indicators can be derived, including modification intensity coefficient, field conflict ratio, and semantic consistency score, to comprehensively assess the rationality and potential risks of the current conflict resolution strategy. These indicators not only provide a basis for credibility assessment of subsequent resolution execution but can also be used to adjust strategy parameters and achieve iterative optimization, making them a key technical link in ensuring the credibility of resolution decisions.

[0041] After completing the edit distance calculation and fusion metric evaluation, the conflict resolution data, resolution strategies, and their verification results are centrally summarized to generate a complete synchronization processing record. This record serves as the core execution credential for the conflict remediation process, recording the conflict cause, data modification suggestions, remediation strategy logic, and verification evaluation metrics. The structure of the synchronization processing record must include: conflict node ID, data object ID, involved platforms, conflict type, original field content, resolved field content, strategy description, execution timestamp, edit distance, and fusion score. All information is uniformly stored in the resolution log database, supporting backtracking auditing, version management, and synchronization rollback. This processing record also serves as the basis for multi-platform collaborative synchronization, and can be synchronized to relevant platforms via data interfaces to notify them to execute corresponding data modification actions or accept remediation suggestions. Simultaneously, this recording mechanism also supports result comparison, i.e., after actual remediation, monitoring whether the data chain has regained continuity and semantic consistency, forming a closed-loop conflict governance path. Through standardized synchronization processing record archiving and analysis, not only is the transparency of conflict handling improved, but a quantifiable trust foundation is also provided for inter-platform coordination. To ensure the temporal consistency of conflict resolution, it is necessary to first reconstruct the true execution order of the entire business data flow based on the data flow causal dependency graph. This dependency graph records the logical causal paths, temporal order, and cross-platform dependencies between events. By traversing the nodes and edges of the causal graph, a strictly logically ordered sequence of events can be constructed, known as the "true execution order." Specifically, a graph traversal algorithm (such as topological sorting) is used to sort each node in the graph and record its position and weight in the global business logic chain. During the sorting process, invalid causal paths must be eliminated, and circular dependencies resolved to ensure a linear or branch-controllable event time sequence. This true order serves as the core reference standard for subsequent processing, determining whether temporal reversal conflicts and concurrent write behaviors violate logical causality. This step plays a crucial role in achieving automated data flow playback, event tracing, and behavior prediction, and is a fundamental capability module in the entire conflict resolution process.

[0042] After obtaining the true execution order of the data stream, nodes with time-reversal conflicts can be replayed and modified to restore them to their correct logical positions in the data structure. Time-reversal conflicts typically manifest as later events appearing earlier in the data stream, causing logical anomalies and state errors. Resolving such conflicts requires "replaying" the relevant data nodes, i.e., re-executing their data write behavior, but correcting their insertion positions and modification times according to the true order. This process uses an event replay engine to extract the conflicting nodes from the original data stream and then re-insert them into their correct positions according to the causal graph order. During replay, their timestamp fields also need to be corrected to ensure they conform to the time range of the preceding and following causal nodes, while checking for conflicts between the modified content and the previous state. If field overwriting issues exist, a field merging strategy or version retention mechanism can be triggered. Ultimately, all replayed data nodes will be arranged in logical order, forming a new "time-consistent data stream." This data stream has cross-platform time alignment and consistency recovery capabilities, and is one of the key results for ensuring the stability of multi-platform data fusion. In multi-platform business interactions, conflicting modifications are a common problem, especially when multiple users or platforms frequently edit the same object's field, easily leading to version forks. To resolve such conflicts, it's necessary to adjudicate conflicting modifications by combining business semantics and data priorities, and merge them into a single, consistent data result. The field type of the repeatedly modified node is identified; if it's numeric, status, or command-type data, an appropriate adjudication strategy is matched based on the field's semantics. Adjudication strategies include time priority, platform weighting, value validity, and contextual consistency. For example, in resource allocation scenarios, a "highest priority platform strategy" can be used; in user status changes, a "last-write valid strategy" can be used. Next, a merging operation is performed on multiple conflicting versions of the field. If the field is a composable type (such as a tag, list, or attribute set), field merging is performed; if it's an overriding field, the preferred version is retained and the conflict source is marked. The processing result is a unified "fused data stream," where each field has resolved multiple version conflicts and retains the merging source information, ensuring traceability and interpretability. The fused data stream can be directly used as the basis for subsequent synchronous writes, improving data consistency across the entire platform.

[0043] During conflict resolution and data merging, if a significant interruption is found in the data update chain or event chain—that is, the absence of a node causes the chain to fail to continuously express the event evolution process—it is necessary to perform "missing data stream" parsing. This process is based on a causal dependency graph, analyzing the relationships between nodes before and after the interrupted areas of the chain to infer potentially missing intermediate states or operations. Parsing methods include path prediction, semantic inference, and version fitting: path prediction analyzes possible logical jumps between nodes; semantic inference predicts the content of intermediate operations based on field change patterns; and version fitting combines historical version trends to fit the interrupted data. After parsing, structured "missing data stream" nodes are generated, marked as logically simulated data, and accompanied by the inference source and reliability score. This missing data stream, as an intermediate state filling element, will be used to reconstruct the integrity of the data chain, particularly suitable for repairing interrupted chain conflicts, and is also a crucial step in ensuring logical continuity between platforms. After completing the missing data stream parsing, these simulated nodes need to be inserted into the empty positions of the original interrupted chain to form a closed data chain structure. This process is called "simulation replay," and its core is to apply the inferred intermediate data as patch data to the update chain. Simulated replay must maintain consistency with the original data structure and causal path, ensuring reasonable insertion positions, natural field changes, and temporal continuity. Two real nodes before and after the interrupted chain are identified, and their field change trends and time spans are analyzed. Simulated nodes are then inserted between them, assigned appropriate timestamps and field values. Simulated nodes must be marked with a "non-native identifier" for later verification or replacement. The resulting "closed-loop data flow" will possess a complete event evolution structure, avoiding data silos or state jumps caused by interrupted chains. The closed data chain can participate in global business sorting, behavioral modeling, and causal analysis, ensuring high logical consistency and self-healing capabilities across the entire metaverse multi-platform data system, providing stable data support for subsequent intelligent synchronization management.

[0044] In this embodiment, step S5 includes the following steps: Based on the data synchronization processing records, the execution time, resolution strategy type, number of platforms involved, and fusion verification indicators of each resolution operation are extracted to generate multiple evaluation indicators; Based on multiple evaluation indicators, multi-dimensional aggregation calculations are performed to generate the average resolution latency, average conflict rate, and average fusion verification pass rate for different platforms. Based on the average resolution delay, average conflict rate, and average fusion verification pass rate, a platform-by-platform synchronous performance analysis is performed to generate a platform performance benchmark curve. Perform performance degradation detection on the platform's performance baseline curve and extract degradation nodes; Perform data volume distribution statistics on the attenuation nodes to obtain attenuation node distribution information; Perform attenuation analysis on the attenuation nodes to generate attenuation factors; Perform synchronization performance bottleneck analysis on attenuation node distribution information and attenuation factors, and generate a synchronization performance bottleneck report. Based on the synchronization performance bottleneck report, computing and storage resources are reallocated across platforms, and adaptive data synchronization optimization is performed.

[0045] In this embodiment, during data synchronization, each conflict resolution operation generates a detailed synchronization processing record. These records form the basis for subsequent performance analysis. By parsing the synchronization processing records, key metrics for each resolution operation are extracted, including: operation execution time (the duration from conflict detection to resolution completion), the type of resolution strategy used (e.g., time-series replay, repeated merging, link closure, etc.), the number of platforms involved (reflecting the complexity of multi-platform collaboration), and fusion verification metrics (edit distance, fusion verification pass rate, etc.). These metrics are uniformly stored using a predefined structured data model to ensure data integrity and consistency. The extraction process is based on a high-efficiency log analysis engine, employing time series analysis and classification aggregation techniques to ensure accurate and efficient acquisition of key metrics from massive synchronization processing logs. This step aims to form a basic performance evaluation dataset, providing data support for subsequent multi-dimensional metric calculations and platform performance diagnosis. After extracting individual resolution operation metrics, multi-dimensional aggregation analysis will be used to statistically describe the overall performance of each platform. Specific methods include grouping by platform ID, calculating the average resolution latency (the arithmetic mean of the execution times of all resolution operations, reflecting the platform's time efficiency in handling conflicts), calculating the average conflict rate (the ratio of conflicting nodes to the total number of data packets, measuring the frequency of conflicts during platform data synchronization), and calculating the average fusion verification pass rate (the proportion of successful fusion verifications in resolution operations, reflecting the quality and stability of data fusion). Aggregate calculations combine time window segmentation (e.g., hourly, daily) and sliding time window techniques to achieve time-series performance trend analysis. Furthermore, statistical analysis methods (e.g., analysis of variance, distribution fitting) are used to evaluate the volatility and stability of each indicator. The results form a cross-platform, cross-time dimension performance indicator matrix, revealing the overall efficiency and reliability differences in multi-platform data synchronization.

[0046] A comprehensive analysis of the synchronization performance of each platform is conducted using the aforementioned average indicators. Based on statistical methods, three core indicators are used as performance dimensions to construct a multi-dimensional performance space. Performance benchmark curves for each platform are generated through time series modeling and regression analysis. These curves, with time on the horizontal axis and performance indicators on the vertical axis, depict the changes in synchronization efficiency, conflict control capabilities, and data fusion success rates of the platform over different time periods. The performance benchmark curves can be displayed graphically in various ways, such as line charts and radar charts, for convenient and intuitive comparison. During the analysis, auxiliary variables such as platform workload and data traffic are incorporated to identify the driving factors of performance changes. The benchmark curves are not only used for current performance evaluation but also support the prediction of future trends and early warning of potential risks, serving as a core performance reference for multi-platform synchronization management. By analyzing the changing trends of the performance benchmark curves, performance degradation detection is implemented to identify key time points or intervals where platform synchronization performance declines. Detection employs signal processing and anomaly detection techniques, including sliding window averaging, trend line fitting, and abrupt change detection algorithms. A degradation node is defined as a time point where a performance indicator shows a significant decline, which may manifest as a significant increase in resolution latency, an abnormal increase in conflict rate, or a decrease in fusion verification pass rate. The detection process combines threshold setting with an adaptive adjustment mechanism to balance sensitivity and false alarm rate, ensuring accurate capture of real decay events. Extraction of decay nodes provides a starting point for subsequent root cause analysis, helping to focus on performance bottleneck areas and supporting targeted optimization.

[0047] Once the attenuation node is identified, its corresponding data load characteristics need to be analyzed. The data volume distribution at the time of the attenuation node and within a certain time window before and after it is statistically analyzed, including the number of data packets, data size, and business type distribution. Distributed counters and aggregation tools are used to achieve accurate statistics on large-scale data traffic. By comparing the changes in data volume before and after the attenuation node, it is possible to identify whether there are sudden traffic spikes, abnormal data backlogs, or business peaks. The statistical results form the data volume distribution information of the attenuation node, revealing the correlation between data flow characteristics and performance degradation. This information provides a basis for determining whether performance degradation is caused by data load and is an important input for performance bottleneck analysis. Combining the changes in performance indicators and data volume distribution of the attenuation node, attenuation factor analysis is conducted. Through correlation analysis, causal inference, and multivariate regression, key factors affecting performance degradation are identified, which may include computing resource bottlenecks (such as increased CPU and memory utilization), increased storage access latency, network transmission congestion, a surge in conflict types, and inter-platform coordination delays. During the analysis, a multi-dimensional attenuation factor model is formed by combining platform operation logs, resource monitoring data, and synchronization task status. The model clarifies the contribution and mechanism of each factor to performance indicators, providing accurate clues for locating synchronization performance bottlenecks. The scientific extraction of attenuation factors is fundamental to developing effective optimization solutions. By combining the data volume distribution information of attenuation nodes with the attenuation factor model, a comprehensive synchronization performance bottleneck analysis is conducted. The analysis employs fault tree analysis, bottleneck location algorithms, and multi-dimensional data visualization techniques to comprehensively reveal the platform's performance limitations during data synchronization. The bottleneck report includes a description of the bottleneck type, its scope of impact, a summary of causes, and a priority ranking, while also providing information on related resource consumption and conflict surge trends. The report is output in structured text, charts, and indicator lists to support management decisions and targeted improvements by the technical team. The report can also be integrated into the platform monitoring system to form a dynamic performance health management tool for continuous monitoring of bottleneck changes.

[0048] Once the bottleneck report is generated, the analysis results guide the dynamic reallocation of computing and storage resources. The resource reallocation strategy is based on priority adjustment principles, allocating more computing power and storage bandwidth to platforms with significant bottlenecks to alleviate resource pressure. Resource scheduling combines container orchestration, load balancing, and autoscaling mechanisms to achieve elastic resource allocation between platforms. Simultaneously, the transmission protocol, conflict detection threshold, and resolution strategy parameters during data synchronization are adaptively adjusted. For example, for platforms with high conflict rates, the parallelism of conflict resolution is increased, the batch size of data packets is adjusted, and network transmission paths are optimized. Through the linkage of resource allocation and synchronization strategies, overall synchronization efficiency and stability are improved, ultimately forming a closed-loop optimization mechanism to achieve continuous improvement and adaptive adjustment of multi-platform synchronization performance.

[0049] In this embodiment, the specific steps for reallocating computing and storage resources across platforms based on the synchronization performance bottleneck report and performing adaptive data synchronization optimization are as follows: Based on the synchronous performance bottleneck report, computing and storage resources are reallocated across platforms to obtain resource reallocation strategies. The resource reallocation strategy was simulated and verified, and the reallocation effect was extracted. Adaptive data synchronization management is implemented based on the redistribution effect, and synchronization strategy parameters are continuously iterated and optimized.

[0050] In this embodiment, after the performance bottleneck report reveals the resource bottlenecks of each platform, a comprehensive review of the distribution of existing computing and storage resources is conducted, covering key indicators such as CPU utilization, memory usage, storage I / O throughput, and network bandwidth utilization. By comparing the resource consumption differences between the bottleneck platform and other platforms using multi-dimensional indicators, a resource reallocation scheme is designed using resource optimization algorithms (such as linear programming, heuristic scheduling algorithms, or reinforcement learning models). The scheme explicitly prioritizes allocating some computing resources (such as the number of virtual CPU cores) and storage resources (such as cache capacity or read / write bandwidth) to the platform with severe bottlenecks, while reasonably controlling the resource allocation of other platforms to avoid overall performance fluctuations. Specifically, a platform load prediction model is used to estimate the load changes after resource adjustments, ensuring the robustness and rationality of the allocation scheme. This resource reallocation strategy is output in the form of a detailed resource quota list and adjustment timing plan to ensure the operability and monitoring traceability of subsequent execution. After the resource reallocation strategy is formed, it needs to be verified in a simulation environment to ensure the effectiveness and security of the adjustment scheme before actual deployment. The simulation verification is based on the constructed multi-platform synchronization model, simulating data synchronization behavior and performance under different resource configuration conditions. Event-driven simulation, discrete clock simulation, or Monte Carlo methods based on historical data are used to repeatedly test compute and storage resource allocation schemes, evaluating their impact on latency resolution, conflict rate, and fusion validation pass rate. During validation, typical load scenarios are set up, such as high-concurrency data writing, conflict surges, and sudden traffic spikes, to ensure the applicability of the strategy in diverse operating environments. Statistical analysis methods are used to extract changes in key performance indicators from the simulation results, generating a resource reallocation effect report. This report focuses on performance improvements, resource utilization improvements, and potential new bottlenecks, ensuring the strategy's reliability and potential for improvement in practical applications.

[0051] After verifying the effectiveness of the resource reallocation scheme through simulation, the project enters the practical application phase, implementing adaptive data synchronization management based on a feedback closed-loop mechanism. Specifically, the resource reallocation strategy is pushed to each platform for execution, with real-time monitoring of synchronization performance metrics and resource usage. Online learning algorithms and dynamic parameter adjustment techniques are employed to adjust synchronization strategy parameters based on actual operational data, such as conflict detection sensitivity, packet batch size, resolution parallelism, and network priority scheduling. This process supports automated feedback loops, combined with monitoring alerts and performance analysis tools, to achieve continuous evaluation and strategy updates for the synchronization process. Furthermore, a regular review cycle is established, iteratively optimizing resource allocation and synchronization strategies based on newly collected synchronization performance data and changes in business requirements, ensuring the dynamic adaptability and long-term stability of the Metaverse multi-platform synchronization management system. This phase utilizes reinforcement learning and multi-objective optimization methods to balance performance, resource efficiency, and stability, improving the overall synchronization effect.

[0052] In this embodiment, a metaverse data management device is provided for executing the metaverse data management method described above, including: The delay compensation calculation unit is used to perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate dynamic delay compensation functions. The causal analysis unit is used to collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and in-depth causal analysis based on the dynamic latency compensation function, and construct a causal dependency graph of the data stream. The conflict detection unit is used to detect update order conflicts based on the causal dependency graph of the data flow and to build a conflict database. The conflict resolution unit is used to adaptively resolve and synchronize data in the conflict database, and generate data synchronization processing records. The synchronization data management unit is used to perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and to perform reallocation management of computing and storage resources for each platform.

[0053] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the metaverse data management method described in any of the above claims.

[0054] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the metaverse data management method described in any of the preceding claims.

[0055] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0056] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein are implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A metaverse data management method, characterized in that, Includes the following steps: Step S1: Perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate a dynamic delay compensation function; Step S2: Collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and causal depth analysis based on the dynamic latency compensation function, and construct a data stream causal dependency graph; Step S3: Detect update order conflicts based on the data flow causal dependency graph and build a conflict database; Step S4: Adaptively resolve and synchronize the conflict database, and generate data synchronization processing records; Step S5: Perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and perform reallocation management of computing and storage resources on each platform.

2. The metaverse data management method according to claim 1, characterized in that, The specific steps of step S1 are as follows: Periodic clock synchronization detection is performed on multiple metaverse platforms to extract clock information from multiple platforms; Based on a standard time source, timestamp differences are calculated for clock information from multiple platforms, and time delay values ​​for each platform are extracted. Define the time offset calculation period; Based on the time offset calculation period, the delay difference change of time delay values ​​of each platform is analyzed to generate clock drift rate; Timing evolution analysis is performed based on clock drift rate to generate clock drift curves for multiple platforms; Delay distribution is identified based on the clock drift curve, and delay compensation calculations are performed to generate a dynamic delay compensation function.

3. The metaverse data management method according to claim 1, characterized in that, The specific steps of step S2 are as follows: Collect business data streams uploaded in parallel from multiple platforms; Calculate and mark the reporting timestamp for the business data stream; Based on the dynamic delay compensation function, adaptive platform delay compensation is performed on the reported timestamp to obtain the delay correction timestamp; The business data stream is sorted in time sequence according to the delay correction timestamp to generate a global business event sequence; Perform event semantic parsing on the global business event sequence to identify multiple event semantic tags; The multiple event semantic table bridges include user behavior class, asset flow field class and virtual scene state class; Based on multiple event semantic tags, perform in-depth causal analysis to extract causal links and concurrency relationships in data streams; Semantic association topology fitting is performed on delay correction timestamps, causal links of data streams, and concurrency relationships to construct a causal dependency graph of data streams.

4. The metaverse data management method according to claim 1, characterized in that, Step S3 is as follows: Incremental update identification is performed on the business data stream, and incremental update data packets are extracted; Data update traceability is performed on incremental update data packets to obtain the data update chain; Based on the causal dependency graph of the data flow, update order conflict detection is performed on the data update chain, and conflicting nodes in the data update are marked. The conflicting nodes in the data update are classified and labeled to obtain multiple types of conflicting nodes; This includes conflicting nodes with reversed timing, conflicting nodes with repeated modifications, and conflicting nodes with interrupted links; Identify data objects and conflict platforms of multiple types of conflict nodes; Statistical analysis is performed on the data objects and conflict platforms to construct a conflict database.

5. The metaverse data management method according to claim 1, characterized in that, The specific steps of step S4 are as follows: Adaptive resolution processing is applied to the conflict database to generate conflict resolution data and conflict resolution strategies. Based on the conflict resolution data, the original data edit distance of the conflict database is calculated to generate fusion verification indicators; Data synchronization and aggregation are performed on fusion verification indicators, conflict resolution data and conflict resolution strategies to generate synchronization processing records; The adaptive digestion process specifically includes; Calculate the actual execution order of data streams based on the causal dependency graph of the data stream; Based on the actual execution order of the data stream, the time-reversed conflict nodes are replayed and modified to obtain a time-consistent data stream. For nodes that are repeatedly modified and conflict, business semantics and data priority are adjusted, and duplicate merging is performed to generate a fused data stream. Missing data streams are parsed based on the causal dependency graph of the data stream to obtain the missing data streams; The closed link data stream is obtained by simulating and replaying the conflict nodes of the interrupted link based on the missing data stream.

6. The metaverse data management method according to claim 1, characterized in that, The specific steps of step S5 are as follows: Based on the data synchronization processing records, the execution time, resolution strategy type, number of platforms involved, and fusion verification indicators of each resolution operation are extracted to generate multiple evaluation indicators; Based on multiple evaluation indicators, multi-dimensional aggregation calculations are performed to generate the average resolution latency, average conflict rate, and average fusion verification pass rate for different platforms. Based on the average resolution delay, average conflict rate, and average fusion verification pass rate, a platform-by-platform synchronous performance analysis is performed to generate a platform performance benchmark curve. Perform performance degradation detection on the platform's performance baseline curve and extract degradation nodes; Perform data volume distribution statistics on the attenuation nodes to obtain attenuation node distribution information; Perform attenuation analysis on the attenuation nodes to generate attenuation factors; Perform synchronization performance bottleneck analysis on attenuation node distribution information and attenuation factors, and generate a synchronization performance bottleneck report. Based on the synchronization performance bottleneck report, computing and storage resources are reallocated across platforms, and adaptive data synchronization optimization is performed.

7. The metaverse data management method according to claim 6, characterized in that, The specific steps for reallocating computing and storage resources across platforms based on the synchronization performance bottleneck report and performing adaptive data synchronization optimization are as follows: Based on the synchronous performance bottleneck report, computing and storage resources are reallocated across platforms to obtain resource reallocation strategies. The resource reallocation strategy was simulated and verified, and the reallocation effect was extracted. Adaptive data synchronization management is implemented based on the redistribution effect, and synchronization strategy parameters are continuously iterated and optimized.

8. A metaverse data management device, characterized in that, For performing the metaverse data management method as described in claim 1, comprising: The delay compensation calculation unit is used to perform periodic clock synchronization detection and delay compensation calculation on multiple metaverse platforms to generate dynamic delay compensation functions. The causal analysis unit is used to collect business data streams uploaded in parallel from multiple platforms, perform platform latency compensation and in-depth causal analysis based on the dynamic latency compensation function, and construct a causal dependency graph of the data stream. The conflict detection unit is used to detect update order conflicts based on the causal dependency graph of the data flow and to build a conflict database. The conflict resolution unit is used to adaptively resolve and synchronize data in the conflict database, and generate data synchronization processing records. The synchronization data management unit is used to perform platform-by-platform synchronization performance analysis based on data synchronization processing records, and to perform reallocation management of computing and storage resources for each platform.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the metaverse data management method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the metaverse data management method according to any one of claims 1 to 7.

Images