A method for supporting unified management and query of multi-cluster heterogeneous data sources
By using the DataLinks Executor component service and the Spring Cloud + Nacos microservice architecture, unified management and querying of multiple cluster data sources were achieved, solving the problem of inconsistent management of multiple cluster data sources, simplifying the configuration process, and improving system performance and resource utilization.
Patent Information
- Application Number
- CN202511522997.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-23
- Publication Date
- 2026-01-23
- Estimated Expiration
- 2045-10-23
AI Technical Summary
In existing technologies, the management of multiple cluster data sources is not unified, the connection configuration is complex, the load balancing mechanism is imperfect, the management function is incomplete, and the driver compatibility is poor, making it difficult for the system to flexibly adapt to and efficiently manage multiple cluster data sources.
It adopts the DataLinks Executor component service, supports multi-node deployment, configures data sources through custom drivers, combines Druid connection pool and Hutool framework for load balancing, and uses Spring Cloud + Nacos microservice architecture to realize unified management and query of data sources, providing load balancing algorithms and monitoring functions, and supporting dynamic switching of database drivers.
It enables efficient connection and management of multiple cluster data sources, simplifies the configuration process, improves development efficiency and system performance, reduces fault location time, and enhances system adaptability and resource utilization.
Smart Images

Figure CN120973773B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of big data technology, and in particular to a method for supporting unified management and querying of heterogeneous data sources across multiple clusters. Background Technology
[0002] In the current technological environment, existing technologies face the following main problems and challenges:
[0003] (1) Insufficient support for multiple cluster data sources: For multiple cluster data sources, existing technologies often lack a unified management mechanism. The data source management of each cluster is relatively independent, which makes it difficult for the system to flexibly adapt to the environment of different clusters. When it is necessary to manage and operate clusters with different configurations, developers have to modify and adjust the code for the special configuration of each cluster.
[0004] (2) Complex connection configuration: Connecting to different types of data sources requires different configuration information, such as connection address, username, password, driver, etc. Existing technologies usually require developers to manually configure this information, and the configuration process is complex and prone to errors. For some complex data sources, such as distributed data sources, additional configuration and optimization are required, which increases the difficulty of development and maintenance.
[0005] (3) Imperfect load balancing mechanism: Existing load balancing strategies are often relatively simple and cannot be flexibly adjusted according to different data sources and business needs. Common load balancing strategies are mainly based on simple round-robin, random or weight allocation, without taking into account the performance, load, data distribution and other factors of the data source. This may lead to some data source connectors being overloaded while other data source connectors are idle, affecting the overall performance and efficiency of the system.
[0006] (4) Incomplete management functions: Existing data source management systems often only provide basic connection configuration and management functions, lacking comprehensive management of data sources. For example, they cannot monitor and analyze the connection status, performance indicators, and usage of data sources in real time; they cannot record and trace the SQL executed by data sources, which makes it difficult for administrators to fully understand the operation status of data sources and to discover and solve problems in a timely manner.
[0007] (5) Driver compatibility issues: When the existing data source management system faces different versions of databases, the drivers may have significant differences and cannot be dynamically and flexibly switched, resulting in the system being unable to connect to the data source normally. Summary of the Invention
[0008] The purpose of this invention is to overcome the problems of insufficient support for multiple cluster data sources, complex connection configuration, imperfect load balancing mechanism, imperfect management function and driver compatibility in the existing technology, and to provide a method that supports unified management and querying of multiple cluster heterogeneous data sources.
[0009] To address the aforementioned technical problems, the present invention provides the following technical solution:
[0010] A method for supporting unified management and querying of heterogeneous data sources across multiple clusters includes the following steps:
[0011] S1: Start the DataLinks Executor component service, which supports multi-node deployment on a single cluster;
[0012] S2: The user uploads a custom driver for a specific data source, configures the data source using the custom driver, and then clicks "Test Connection".
[0013] S3: After the connection test is successful, enter the unified query menu page, select the data source for which the connection test was successful, and write the SQL statement to be executed;
[0014] S4: After an SQL statement is executed, the Druid connection pool records the executed SQL statement. DataLinksExecutor periodically collects data source information from the Druid connection pool and performs summary statistics.
[0015] S5: The DataLinks Executor's load balancing algorithm selects nodes with lower loads from the aggregated data source information and assigns query tasks to each node.
[0016] As a preferred embodiment of the present invention, step S1 includes: setting the cluster name in the application.yml configuration file of the DataLinks Executor component service through the spring.cloud.nacos.discovery.cluster-name parameter; the Nacos server automatically groups and manages the nodes according to the cluster name to realize service discovery and isolation between clusters.
[0017] As a preferred embodiment of the present invention, step S2 includes:
[0018] S21: After the user creates a custom driver and uploads the corresponding driver file, DataLinks Web sends the test connection command and driver command to the DataLinks Executor of the specified cluster through the Nacos cluster load balancing mechanism.
[0019] S22: After receiving the test connection command, the DataLinks Executor identifies whether the user is using a custom driver;
[0020] S23: If a custom driver is used, the DataLinks Executor downloads the driver file uploaded by the user remotely via HTTP byte stream or HDFS distributed storage, and then loads the driver file based on the URLClassLoader class loader;
[0021] S24: Connect to the data source via JDBC and return the test results to DataLinks Web.
[0022] As a preferred embodiment of the present invention, the step S24 of connecting to the data source via JDBC includes:
[0023] In HA mode, serviceDiscoveryMode=zookeeper is automatically added;
[0024] Kerberos authentication automatically supplements principal parameters and related parameters;
[0025] Automatically configure SSL encryption with ssl=true and certificate-related parameters.
[0026] As a preferred embodiment of the present invention, step S3 includes: DataLinks Web sends the SQL statement executed by the user and the basic connection information of the corresponding data source to the DataLinks Executor on the specified cluster through the Nacos cluster load balancing mechanism;
[0027] After receiving the SQL statement execution instruction, the DataLinks Executor first determines whether the corresponding data source has a connection pool. If the data source connection pool does not exist, the DataLinks Executor creates a connection pool through the Druid data source connection pool framework, obtains a connection through the connection pool, and then executes the user's SQL statement.
[0028] After execution, the SQL statement execution result is returned to the DataLinks Web service, which then renders the execution result and displays it to the user.
[0029] As a preferred embodiment of the present invention, the Nacos cluster load balancing mechanism includes: firstly, performing cluster tagging based on the spring.cloud.nacos.discovery.cluster-name in the application.yml configuration of DataLinksExecutor;
[0030] When the data source executes a query request, it carries the target cluster identifier;
[0031] The load balancer filters out instances that match the specified cluster label from the list of active instances.
[0032] As a preferred embodiment of the present invention, the data source information mentioned in step S4 is a key connection pool indicator, including: total number of queries, total number of updates, and total number of batch processing.
[0033] As a preferred embodiment of the present invention, step S4 further includes: the DataLinks Executor obtains the CPU utilization and memory utilization of the server through the Hutool framework, thereby calculating the server's performance indicators, and records the performance indicators in the Guava cache of the DataLinks Executor. DataLinks Web periodically collects all cached content recorded in all DataLinks Executors and displays it to the operation and maintenance personnel for analysis and statistics.
[0034] As a preferred embodiment of the present invention, the load balancing algorithm formula for the DataLinks Executor in step S5 is as follows:
[0035] Load score = Active connection ratio weight value * (Active number of connection pools of the data source / Maximum number of connection pools of the data source) + Average load weight value of the connection pool * Average load value of the connection pool.
[0036] As a preferred embodiment of the present invention, the active connection ratio weight value is 0.7, and the average load weight value of the connection pool is 0.3.
[0037] Compared with the prior art, the advantages of the present invention are as follows:
[0038] (1) This invention realizes the effective connection and management of multiple cluster data sources. With the help of DataLinks Executor service, it successfully shields the problem of different configuration of different cluster data source environments. This innovative measure significantly reduces the complexity of use for users and greatly simplifies the configuration process, enabling users to manage and operate multiple cluster data sources more conveniently and efficiently, thereby solving the problem of connection and management of multiple cluster data sources.
[0039] (2) By adopting the SpringCloud+Nacos microservice architecture, this invention effectively reduces repetitive development work. The architecture has good compatibility and scalability and can be easily embedded into other microservice products. Other microservice products can query various heterogeneous data sources by calling the DataLinks API without having to repeatedly write JDBC code for data source connection. This not only saves developers' time and energy and avoids repetitive development, but also improves development efficiency and reduces development costs.
[0040] (3) This invention provides a DataLinks Executor monitoring overview function. Based on the Druid data source connection pool framework and Hutool framework, the system can accurately collect key indicator information. Operation and maintenance personnel can easily perceive the connection status of each data source of DataLinks Executor through this monitoring overview and discover potential problems in a timely manner. This helps operation and maintenance personnel to quickly locate faults and take timely response measures, thereby ensuring the stability and reliability of data source connections and reducing system downtime caused by data source failures.
[0041] (4) In response to the situation where there are large differences in data source versions and it is necessary to flexibly switch data source drivers, this invention provides a custom driver function and implements a hot loading mechanism based on URLClassLoader. It can dynamically load and switch different versions of database drivers without restarting the system. This technological innovation effectively solves the problem of incompatibility between different database version drivers and improves the system's adaptability and flexibility to different database environments.
[0042] (5) The present invention implements a unique load balancing algorithm. This algorithm calculates the indicators of multiple dimensions of the data source connection pool, accurately locates low-load nodes, and distributes SQL execution tasks to these nodes. This strategy effectively reduces the idle status of DataLinks Executor resources, optimizes load balancing, improves the overall resource utilization, enables the system to process a large number of SQL query requests more efficiently, and improves the system's performance and response speed. Attached Figure Description
[0043] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. In the drawings:
[0044] Figure 1 This is a flowchart of a method for supporting unified management and querying of heterogeneous data sources across multiple clusters, as described in Embodiment 1 of the present invention.
[0045] Figure 2 This is a software architecture diagram of a method for supporting unified management and querying of heterogeneous data sources across multiple clusters, as described in Embodiment 1 of the present invention.
[0046] Figure 3 This is an internal component architecture diagram of a method for supporting unified management and querying of heterogeneous data sources across multiple clusters, as described in Embodiment 1 of the present invention.
[0047] Figure 4 This is a flowchart of the data source test connection process for a method supporting unified management and query of heterogeneous data sources across multiple clusters, as described in Embodiment 1 of the present invention.
[0048] Figure 5 This is a monitoring graph of DataLinks Executor metrics for a method that supports unified management and querying of heterogeneous data sources across multiple clusters, as described in Embodiment 1 of the present invention. Detailed Implementation
[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
[0050] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance, or suggesting any such actual relationship or order between these entities or operations. Additionally, the terms "connected," "linked," etc., can refer to a direct connection between components or an indirect connection via other components.
[0051] Example 1
[0052] A method to support unified management and querying of heterogeneous data sources across multiple clusters, such as... Figure 1 As shown, it includes the following steps:
[0053] S1: Starting the DataLinks Executor component service: Operations personnel start the DataLinks Executor component service on machines in each cluster. This service supports multi-node deployment on a single cluster, and its software architecture is as follows: Figure 2 As shown, the internal component architecture is as follows Figure 3 As shown, the DataLinks Executor component is mainly responsible for SQL queries and service monitoring of data sources within the cluster;
[0054] Specifically, in the application.yml configuration file of the DataLinks Executor component service, the cluster name is set through the spring.cloud.nacos.discovery.cluster-name parameter. The Nacos server automatically groups and manages nodes according to the cluster name, realizing service discovery and isolation between clusters. This configuration-based cluster identification method ensures deployment standardization and seamlessly integrates with Nacos' native service discovery mechanism.
[0055] S2: Custom Driver Upload and Data Source Test Connection: Users can upload custom drivers for specific data sources and use these custom drivers to configure the data source. Then, by clicking the test connection, DataLinks Web supports users uploading custom drivers. When a user creates a custom driver and uploads the corresponding driver file, DataLinks Web will send the test connection information and driver information to the DataLinksExecutor in the specified cluster through the Nacos cluster load balancing mechanism.
[0056] Upon receiving the test connection command, the DataLinks Executor identifies whether the user is using a custom driver. If a custom driver is used, the DataLinks Executor downloads the user-uploaded driver file remotely via HTTP byte stream or HDFS distributed storage, then loads the driver file using the URLClassLoader class loader. Finally, it connects to the data source via JDBC and returns the test results. The flowchart for this process is as follows: Figure 4 As shown;
[0057] Specifically, connecting to a data source via JDBC includes:
[0058] In HA mode, serviceDiscoveryMode=zookeeper is automatically added;
[0059] Kerberos authentication automatically supplements principal parameters and related parameters;
[0060] Automatically configure SSL encryption with ssl=true and certificate-related parameters.
[0061] The cross-cluster collaboration mechanism of DataLinks Executor is as follows:
[0062] Communication protocol: The OpenFeign framework is used, and the HTTP protocol based on TCP is used for cross-cluster communication to ensure the reliability, order and integrity of data transmission;
[0063] Service discovery: Cross-cluster service discovery and routing are achieved through the Nacos cluster registry.
[0064] When multiple driver versions exist in the data source, after loading the custom driver ClassLoader through URLClassLoader, the content of the original class loader of the current thread context is first obtained by Thread.currentThread().getContextClassLoader() (i.e., the default driver); then the current thread context class loader is set to the user-uploaded driver, and the SQL query Thread.currentThread().setContextClassLoader(jdbcClassLoader) and action.get() are executed; after the execution is completed, the default driver class loader obtained in step one is loaded back into the thread by Thread.currentThread().setContextClassLoader(origintClassLoader).
[0065] Specifically, there are format validations and default value generation mechanisms for different configuration information (such as connection address, username, password, driver, etc.) for different types of data sources. For dependent files, a file upload method is provided to reduce the risk of input errors.
[0066] First, data format validation: The initial number of connections to the data source; minimum number of connections; maximum number of connections; query timeout; number of DataLinksExecutors, etc., are subject to format validation, requiring the user to input the numerical type.
[0067] Secondly, authentication configuration optimization: support for KeyTab file upload (Hive / Spark), support for certificate file upload in SSL configuration, and automatic hiding of irrelevant configuration items based on the authentication method.
[0068] Finally, default value optimization: Kafka SSL default trust library type is set to the commonly used JKS method, automatically generating data source identifiers in the format of "IP@library name", while retaining the ability to customize naming.
[0069] S3: Data Source Query and SQL Execution:
[0070] After the connection test is successful, users can access the unified query menu page, select the data source for which the test connection was successful, and write the SQL statement to be executed. DataLinks Web will then use the Nacos cluster load balancing mechanism to send the SQL statement executed by the user and the basic connection information of the data source to the DataLinks Executor on the specified cluster.
[0071] Upon receiving an SQL execution command, the DataLinks Executor first checks if a connection pool exists for the data source. If the connection pool does not exist, the DataLinks Executor creates a connection pool using the Druid data source connection pool framework, obtains a connection through the pool, and then executes the user's SQL statement. After execution, the SQL execution result is returned to the DataLinks Web service, which ultimately renders and displays the result to the user.
[0072] The Nacos multi-cluster task scheduling fault tolerance mechanism is implemented as follows:
[0073] Fault detection: Abnormal nodes are automatically identified through the Nacos health check mechanism;
[0074] Service isolation: Manually take the faulty node offline in the Nacos console (soft shutdown, process preserved);
[0075] Status synchronization: The DataLinkWeb management interface will synchronize the latest service instance status in real time when the offline status is obtained.
[0076] Traffic shifting: The load balancer automatically excludes offline nodes and selects only healthy instances;
[0077] Recovery mechanism: The node needs to be manually brought back online after the fault is repaired.
[0078] Specifically, the Nacos cluster load balancing mechanism includes: firstly, labeling the cluster based on the cluster-name in the application.yml configuration of DataLinksExecutor;
[0079] When the data source executes a query request, it carries the target cluster identifier;
[0080] The load balancer selects instances from the list of active instances that match a specified cluster label. This mechanism ensures that requests are accurately routed to the specified cluster while maintaining load balancing within the cluster.
[0081] S4: DataLinks Executor execution overview monitoring:
[0082] Operations personnel can view the execution overview of DataLinks Executor through the DataLinks monitoring menu page. When a user executes SQL, the Druid connection pool records the executed SQL. DataLinks Executor periodically collects data source information from the Druid connection pool and performs summary statistics, including key connection pool metrics such as total number of queries, total number of updates, and total number of batch processing.
[0083] Meanwhile, the DataLinks Executor uses the Hutool framework to obtain information such as server CPU and memory usage to calculate server performance metrics. These metrics are recorded in the DataLinks Executor's Guava cache. DataLinks Web periodically collects all cached content recorded in the DataLinks Executor and displays it to operations personnel for analysis and statistics. The design diagram for this part is shown below. Figure 5 As shown;
[0084] For example: Currently, the default parameters of the Druid connection pool do not automatically adjust based on the data source type. They are configured uniformly based on empirical values. The following is the default configuration:
[0085] Initial number of connections: 5; Minimum number of connections: 5; Maximum number of connections: 50; Query timeout: 120; Number of Executors: 1.
[0086] When a user edits a data source on the DataLinksWeb page, the Druid connection pool is recreated. This is because if the user changes core connection parameters such as the database, username, and password, the source connection pool may not be able to execute SQL queries if it is not destroyed. Therefore, when a user edits a data source, a new connection pool is created instead of being reused.
[0087] S5: Load balancing algorithm of DataLinks Executor:
[0088] DataLinks Executor's load balancing algorithm aims to select nodes with lower loads and rationally distribute query tasks among them to improve service stability and node utilization. Each time a data source query connection is established, the load balancing algorithm recalculates the load value of each node and updates the latest load status of each node in real time. The specific algorithm is as follows:
[0089] Load score = Active connection ratio weight value * (Active number of connection pools of the data source / Maximum number of connection pools of the data source) + Average load weight value of the connection pool * Average load value of the connection pool.
[0090] The active connection count ratio weight is 0.7, and the connection pool average load weight is 0.3. These values can be dynamically adjusted by configuring selector.default.active-count-weight and selector.default.pool-load-average-weight in the DataLinksWeb service application.yml configuration file.
[0091] Specifically, the core objective is to achieve dynamic resource allocation by comprehensively evaluating the real-time activity (activeRatio) and historical load trend (poolLoadAverage) of the thread pool. Among these:
[0092] The activeRatio (weight 0.3) reflects the current instantaneous pressure, but may be subject to noise due to sudden requests.
[0093] poolLoadAverage (weight 0.7) smooths out short-term fluctuations through a moving average, reflecting the long-term stability requirements. Based on domain experience, according to the design principles of distributed systems, historical load metrics usually have a greater impact on long-term stability.
[0094] Among them, the node with the lowest load is selected from the available DataLinksExecutor nodes each time;
[0095] The weight calculation formula is: "1-source+0.01";
[0096] The source is the load value of each node. The addition of 0.01 is to prevent the weight value from being 0. Otherwise, when all Executors are at full load, only the first one will be selected.
[0097] The actual calculation index for the average load value of the connection pool is:
[0098] Metrics for the number of active connection pools for a specified data source:
[0099] 1. The number of active connections in the corresponding Druid connection pool;
[0100] 2. Maximum connection pool size for the specified data source: corresponds to the maximum number of active connections in the Druid connection pool;
[0101] 3. Specifies the number of threads that the data source is waiting to acquire a connection: corresponds to the number of Druid waiting threads;
[0102] 4. Total active connections in the connection pool: The total number of active connections in the entire Druid connection pool;
[0103] 5. Maximum total number of connections in the entire Druid connection pool: The maximum number of active connections in all Druid connection pools;
[0104] 6. Total number of threads waiting to acquire a connection: Total number of Druid threads waiting.
[0105] The sampling frequency is updated every time the data source initiates an SQL query.
[0106] The database design includes the following data relationships:
[0107] A user can create multiple data sources; a user can have multiple SQL execution records; a user can create multiple custom data source drivers; a custom driver can be associated with multiple driver files; a data source can be associated with zero or one custom driver; a data source can be associated with multiple query consoles; a data source can be associated with multiple SQL execution records.
[0108] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.
[0109] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.
Claims
1. A method for supporting unified management and querying of heterogeneous data sources across multiple clusters, characterized in that, Includes the following steps: S1: Start the DataLinks Executor component service, which supports multi-node deployment on a single cluster; S2: The user uploads a custom driver for a specific data source, configures the data source using the custom driver, and then clicks "Test Connection". Step S2 includes: S21: After the user creates a custom driver and uploads the corresponding driver file, DataLinks Web sends the test connection command and driver command to the DataLinks Executor of the specified cluster through the Nacos cluster load balancing mechanism. S22: After receiving the test connection command, the DataLinks Executor identifies whether the user is using a custom driver; S23: If a custom driver is used, the DataLinks Executor downloads the driver file uploaded by the user remotely via HTTP byte stream or HDFS distributed storage, and then loads the driver file based on the URLClassLoader class loader; S24: Connect to the data source via JDBC and return the test results to DataLinks Web; Step S24, connecting to the data source via JDBC, includes: In HA mode, serviceDiscoveryMode=zookeeper is automatically added; Kerberos authentication automatically supplements principal parameters and related parameters; Automatically configure SSL encryption with ssl=true and certificate-related parameters; S3: After the connection test is successful, enter the unified query menu page, select the data source for which the connection test was successful, and write the SQL statement to be executed; Step S3 includes: DataLinks Web sends the SQL statement executed by the user and the basic connection information of the corresponding data source to the DataLinks Executor on the specified cluster through the Nacos cluster load balancing mechanism; After receiving the SQL statement execution instruction, the DataLinks Executor first determines whether the corresponding data source has a connection pool. If the data source connection pool does not exist, the DataLinks Executor creates a connection pool through the Druid data source connection pool framework, obtains a connection through the connection pool, and then executes the user's SQL statement. After execution, the SQL statement execution result is returned to the DataLinks Web service, which then renders the execution result and displays it to the user. The Nacos cluster load balancing mechanism includes: firstly, cluster tagging based on the spring.cloud.nacos.discovery.cluster-name configuration in the application.yml file of DataLinksExecutor; When the data source executes a query request, it carries the target cluster identifier; The load balancer filters instances that match the specified cluster label from the list of active instances; S4: After an SQL statement is executed, the Druid connection pool records the executed SQL statement. The DataLinks Executor periodically collects data source information from the Druid connection pool and performs summary statistics. S5: The DataLinks Executor's load balancing algorithm selects nodes with lower loads from the aggregated data source information and assigns query tasks to each node.
2. The method for supporting unified management and querying of heterogeneous data sources across multiple clusters according to claim 1, characterized in that, Step S1 includes: setting the cluster name in the application.yml configuration file of the DataLinks Executor component service through the spring.cloud.nacos.discovery.cluster-name parameter. The Nacos server automatically groups and manages the nodes according to the cluster name to achieve service discovery and isolation between clusters.
3. The method for supporting unified management and querying of heterogeneous data sources across multiple clusters according to claim 1, characterized in that, The data source information mentioned in step S4 is key connection pool metrics, including: total number of queries, total number of updates, and total number of batch processing operations.
4. The method for supporting unified management and querying of heterogeneous data sources across multiple clusters according to claim 1, characterized in that, Step S4 further includes: the DataLinks Executor obtains the server's CPU utilization and memory utilization through the Hutool framework, thereby calculating the server's performance indicators and recording the performance indicators in the DataLinks Executor's Guava cache. DataLinks Web periodically collects all cached content recorded in all DataLinks Executors and displays it to operations and maintenance personnel for analysis and statistics.
5. The method for supporting unified management and querying of heterogeneous data sources across multiple clusters according to claim 1, characterized in that, The load balancing algorithm formula for the DataLinks Executor mentioned in step S5 is as follows: Load score = Active connection ratio weight value * (Active number of connection pools of the data source / Maximum number of connection pools of the data source) + Average load weight value of the connection pool * Average load value of the connection pool.
6. The method for supporting unified management and querying of heterogeneous data sources across multiple clusters according to claim 5, characterized in that, The active connection ratio weight is 0.7, and the connection pool average load weight is 0.3.
Citation Information
Patent Citations
A heterogeneous data source visual query method
CN109815283A
Data processing device, data processing method, storage medium and electronic equipment
CN111949693A