CN112948349A

CN112948349A - Data processing method and device of system cooperation platform

Info

Publication number: CN112948349A
Application number: CN202011050190.XA
Authority: CN
Inventors: 胡艺超; 王红阳; 曾庆雷
Original assignee: Shenzhen Mingyuan Cloud Technology Co Ltd
Current assignee: Shenzhen Mingyuan Cloud Technology Co Ltd
Priority date: 2020-09-29
Filing date: 2020-09-29
Publication date: 2021-06-11

Abstract

The application is applicable to the technical field of internet and provides a data processing method and device of a system collaboration platform, wherein the method comprises the following steps: determining a first business attribute corresponding to a target business to be processed by a system cooperation platform; determining at least one corresponding target subsystem from a plurality of subsystems of the system cooperation platform according to the first service attribute; and determining a service data table according to the historical data corresponding to each target subsystem, wherein the service data table is used for responding to the access request aiming at the target service. Therefore, the data cleaning service is introduced, the data dispersed in different subsystems are integrated based on the service attributes, the query is easier, and the response speed of the service is improved.

Description

Data processing method and device of system cooperation platform

Technical Field

The application belongs to the technical field of internet, and particularly relates to a data processing method and device of a system collaboration platform.

Background

In the system cooperation platform, data between different systems are stored in corresponding databases in an independent mode. The storage mode is beneficial to ensuring the consistency of the states of different service system data and simultaneously can also be used for storing larger data volume.

However, the relatively independent and inter-system distributed storage of data is disadvantageous for joint query and statistics of related data by multiple systems, for example, some subsystems in the collaborative development platform store basic information of a project, and some subsystems store requirement information, and these data are stored in different types of databases. At this time, if the basic information of the item meeting some requirements is desired to be queried, the operation is complicated and the time consumption is large.

In view of the above problems, no better solution has been proposed in the industry at present.

Disclosure of Invention

In view of this, embodiments of the present application provide a data processing method and apparatus for a system collaboration platform, so as to at least solve the problem in the prior art that a system collaboration platform is complex and time-consuming when performing data query across databases.

A first aspect of an embodiment of the present application provides a data processing method for a system collaboration platform, including: determining a first business attribute corresponding to a target business to be served by a system cooperation platform; determining at least one corresponding target subsystem from a plurality of subsystems of the system cooperation platform according to the first service attribute; and determining a service data table according to the historical data corresponding to each target subsystem, wherein the service data table is used for responding to the access request aiming at the target service.

A second aspect of the embodiments of the present application provides a data processing apparatus of a system collaboration platform, including: the system comprises a business attribute determining unit, a business attribute determining unit and a business attribute determining unit, wherein the business attribute determining unit is configured to determine a first business attribute corresponding to a target business to be served by a system cooperation platform; a target subsystem determining unit configured to determine, from a plurality of subsystems of the system cooperation platform, a corresponding at least one target subsystem according to the first service attribute; and the service data table determining unit is configured to determine a service data table according to the historical data corresponding to each target subsystem, wherein the service data table is used for responding to an access request aiming at the target service.

A third aspect of embodiments of the present application provides a mobile terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method when executing the computer program.

A fourth aspect of embodiments of the present application provides a computer-readable storage medium, in which a computer program is stored, which, when executed by a processor, implements the steps of the method as described above.

A fifth aspect of embodiments of the present application provides a computer program product, which, when run on a mobile terminal, causes the mobile terminal to implement the steps of the method as described above.

Compared with the prior art, the embodiment of the application has the advantages that:

according to the embodiment of the application, the historical data in the subsystems with the service relevance are combined together according to the service attributes of the services served by the system cooperation platform, and the new service data table is determined, so that the service data table can be directly called when the access request of the corresponding service is executed, the access or the call across a database is not needed, and the service response efficiency can be improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

FIG. 1 is a flow chart illustrating an example of a data processing method of a system collaboration platform according to an embodiment of the present application;

FIG. 2 illustrates a flow chart of an example of determining a business data table according to an embodiment of the present application;

FIG. 3 shows a flowchart of an example of a data processing method of the system collaboration platform according to an embodiment of the application;

FIG. 4 is an architectural diagram illustrating an example of a system suitable for applying the data processing method of the system collaboration platform according to the embodiment of the present application;

FIG. 5 is a block diagram illustrating an example of a data processing apparatus of a system collaboration platform according to an embodiment of the present application;

fig. 6 is a schematic diagram of an example of a mobile terminal according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

In order to explain the technical solution described in the present application, the following description will be given by way of specific examples.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also to be understood that the terminology used in the description of the present application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the present application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be further understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

In particular implementations, the mobile terminals described in embodiments of the present application include, but are not limited to, other portable devices such as mobile phones, laptop computers, or tablet computers having touch sensitive surfaces (e.g., touch screen displays and/or touch pads). It should also be understood that in some embodiments, the devices described above are not portable communication devices, but rather are desktop computers having touch-sensitive surfaces (e.g., touch screen displays and/or touch pads).

In the discussion that follows, a mobile terminal that includes a display and a touch-sensitive surface is described. However, it should be understood that the mobile terminal may include one or more other physical user interface devices such as a physical keyboard, mouse, and/or joystick.

Various applications that may be executed on the mobile terminal may use at least one common physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface and corresponding information displayed on the terminal can be adjusted and/or changed between applications and/or within respective applications. In this way, a common physical architecture (e.g., touch-sensitive surface) of the terminal can support various applications with user interfaces that are intuitive and transparent to the user.

In addition, in the description of the present application, the terms "first," "second," "third," and the like are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.

Fig. 1 is a flowchart illustrating an example of a data processing method of a system collaboration platform according to an embodiment of the present application. Regarding the execution subject of the method of the embodiment of the present application, it may be a platform processor or a controller in the system cooperation platform.

As shown in fig. 1, in step 110, a first business attribute corresponding to a target business to be serviced by the system-based collaboration platform is determined. It should be understood that in the system cooperation platform, different subsystems may need to cooperate with each other to provide services for one or more corresponding services. Further, the first service attribute may be attribute information such as name, category, data source, etc. related to the service.

In step 120, at least one target subsystem is determined from the plurality of subsystems of the system collaboration platform according to the first service attribute. Illustratively, each subsystem in the system collaboration platform has a corresponding service attribute (for example, basic information of an item exists in a first subsystem, demand information of the item exists in a second subsystem, and the like), and through comparison operation of the service attributes, a corresponding target subsystem can be determined.

In step 130, a service data table is determined according to the historical data corresponding to each target subsystem. Illustratively, the basic information in the first subsystem and the requirement information in the second subsystem are sorted into a service data table. Here, the service data table is used for responding to an access request for a target service, and for example, when basic information of an item meeting some requirements is queried, the service data table can be directly queried without respectively calling different subsystems, thereby improving response efficiency of service processing.

According to the embodiment of the application, data cleaning service is introduced into the collaborative research and development platform, data dispersed in different subsystems are integrated based on closely related data in the service processing or query process, read-only data which are easier to query are formed, and the response speed of services can be improved.

Fig. 2 shows a flowchart of an example of determining a business data table according to an embodiment of the application.

In step 210, a second service attribute corresponding to the target service is determined.

In step 220, a corresponding target data collection mode is determined from the plurality of data collection modes according to the second service attribute. Illustratively, each data collection mode is respectively matched with the corresponding second service attribute, and the matching relation can be predetermined, for example, some services may require real-time data feedback, while other services may not require real-time data feedback, so that system resources can be saved.

In step 230, historical data is collected according to the target data collection mode.

In step 240, a business data table is determined based on the collected historical data.

According to the embodiment of the application, the corresponding data acquisition mode is determined according to the business attributes, and the historical data is acquired in the corresponding mode, so that the requirements of different business service scenes can be met.

In some examples of embodiments of the present application, the target data acquisition mode may include a timed data acquisition mode. Specifically, when the historical data is collected, the historical data may be collected from the historical databases corresponding to the target subsystems at regular time according to a preset time period. Here, the time period may be set according to different services.

In the embodiment of the application, a service for processing tasks at regular time can be introduced, and other services can be notified to process a certain business logic at a specified time or period. Moreover, the time for processing the business can be appointed by a developer, the service of the timed processing task is activated at the appointed time, the required data is read from different business databases, screening and integration are carried out according to the business requirements, and the final result is stored in a corresponding business data table, so that the query is facilitated.

Therefore, by presetting the time period, the service data table can be regularly arranged by using the historical data in the historical databases corresponding to different subsystems, and the requirement of high-efficiency data query service can be met.

It should be noted that, through different timing processing tasks, according to the requirement of the query service, the required data can be read from different databases and integrated to be stored in a new data table. In this process, unwanted data may be screened out, and eligible data may be recombined and redundant into a new, more appropriate database system or data table. Therefore, the query data volume is reduced, and the logic of the query is more consistent. In addition, the scenes suitable for applying the timing data acquisition mode are generally scenes in which the data volume of the query object is large, the data is relatively dispersed, the query conditions are changed more, the query frequency is not very high, and the real-time requirement is not very high.

In some examples of embodiments of the present application, the target data acquisition mode comprises a real-time data acquisition mode. Specifically, when the history data is collected, corresponding first history data may be collected from an MQ (Message Queue) corresponding to each target subsystem, and corresponding second history data may be collected from a history database corresponding to each target subsystem.

It should be understood that a message queue is a first-in-first-out data structure, one end (e.g., a client) continuously writing data to the message queue and the other end (e.g., a server) continuously fetching data from the message queue, which is a data structure for implementing asynchronous communication between the client and the server. Furthermore, no limitation may be placed on the specific type of message queue, such as a RabbitMQ queue, a Kafka queue, etc.

In the embodiment of the application, the message queue can be accessed for the business service to subscribe the business message, the logic of message filtering processing is added, the messages which do not need to be processed are filtered, calculation is carried out according to the existing business data, and the calculation result data is stored in the statistical business data table, so that subsequent query is facilitated. Therefore, when a message of service state change is received, the data in the message queue can be integrated by combining with the data in the historical database through the predefined processing flow, and the data is stored in a new data table, so that the query is facilitated. It should be noted that the real-time data acquisition mode is applicable to a service scenario in which a single piece of queried data is relatively independent, but has a plurality of states, and is derived from different systems, and the real-time performance of the data is relatively high.

Therefore, the service data table is determined according to the first historical data and the second historical data, so that the historical data generated in the message queue in real time can exist in the service data, and the requirement of real-time data query of some services can be met.

In some embodiments, after the target subsystems are determined based on the first service attributes, the message queues corresponding to the respective target subsystems may be subscribed, and corresponding first history data may be collected from the subscribed respective message queues. Therefore, historical data generated in real time can be collected from the corresponding message queue in a data subscription mode.

Fig. 3 is a flowchart illustrating an example of a data processing method of the system collaboration platform according to an embodiment of the present application.

As shown in fig. 3, in step 310, a first business attribute corresponding to a target business to be processed by the system collaboration platform service is determined.

In step 320, at least one target subsystem is determined from the plurality of subsystems of the system collaboration platform according to the first service attribute.

In step 330, a second service attribute corresponding to the target service is determined.

In step 340, a corresponding target data collection mode is determined from the plurality of data collection modes according to the second service attribute.

In step 350, in the target data collection mode, for each target subsystem, the data in the message queue corresponding to the target subsystem is continuously stored by using a plurality of queue structures corresponding to the preset first time period, so as to obtain corresponding first historical data.

Illustratively, each queue structure may be used to store messages generated by the corresponding target subsystem within one hour. For example, a first queue structure is used to store messages generated by the target subsystem at 1 o ' clock, a second queue structure may be used to store messages generated by the target subsystem at 2 o ' clock, and when the current time is 2 o ' clock, the historical data in the first queue structure may be dumped to a database, and the data may be used to determine a business data table, and then the data in the first queue structure may be emptied, as will be described in more detail below. Therefore, historical data in the message queue can be collected according to the time period, and the requirement of the personalized application scene is met.

In step 360, in the target data collection mode, the historical data corresponding to the preset second time period is collected from the historical database corresponding to each target subsystem, so as to obtain corresponding second historical data. Here, the second time period is greater than the first time period.

In step 370, a traffic data table is determined based on the first historical data and the second historical data.

In the embodiment of the application, the real-time data acquisition mode and the timing data acquisition mode can be integrated, the requirements of real-time performance and accuracy of service processing are met, and more personalized service scenes can be supported. Illustratively, the first time period may be one hour and the second time period may be one day, so that the service data table may be updated with the historical data in the database every day in addition to the update of the service data table with the historical data in the real-time message queue every hour. Therefore, wider service scenes can be supported, for example, services with a revocation function or a supplementation function are supported, that is, after data information of a certain item is revoked or supplemented within 1 hour, the server can also maintain a service data table by using historical data in the database, and the accuracy of the service data table is guaranteed.

Fig. 4 is a schematic architecture diagram illustrating an example of a system to which the data processing method of the system collaboration platform according to the embodiment of the present application is applied.

The system architecture shown in fig. 4 is provided with a message sorting module 410 and a data statistics module 420. Specifically, the message sorting module 410 may provide message sorting services based on an ABA mode, and the services may subscribe to messages of the RabbitMQ system according to a certain routingKey according to business needs, and perform switching according to a certain period. Thus, messages received from the message queues MQ 1-MQN may be queue filtered and sorted according to a predefined time node. For example, under the condition of hour switching, when the time reaches 12 o 'clock, the system switches the received qualified message from the last put queue a to the put queue B, that is, puts the message generated at 12 o' clock and later into another queue.

In addition, the data statistics module 420 can listen to the traffic queues and notification queues of the message sorting module 410. The service queue is a queue structure (i.e. a queue structure divided into a and B) for receiving and forwarding the messages by the sorting service in a loss-free manner, and the notification queue is a queue for notifying the service subscribing to the message when the data processing service performs a queue switch.

Preferably, upon receiving the notification from the switch queue generated by the message sorting module 410, the data statistics module 420 receives all of the messages from the original a queue and acknowledges all of the messages without processing (since the messages are relatively out of date) to clear the queue.

Further, the data statistics module 420 may batch process the business data in a plurality of systems and store the result in the statistics table.

In addition, after the timed task is completed, the switched queue B may be accessed by the message sorting module 410 and a new round of real-time data statistics may begin to be processed, for example, repeatedly at 1 o' clock, except that the queue structure needs to be switched back from B to a.

In the embodiment of the application, a timing and real-time calculation mode is adopted, so that the problems that the processing time is long during timing screening, and the data between two timing tasks are inconsistent for a long time due to the calculation delay are solved. Therefore, on the basis of the timing full-scale statistical data, the message queue of the access subsystem refreshes data in real time when the data state changes. It should be noted that the scenario for which this processing method is applicable is a service scenario in which the data size is relatively large and the requirement on real-time performance is relatively high, and at the same time, some functions have a cancel or supplement function, for example, the processing logic of the next day may affect the statistical result of the previous day.

Fig. 5 is a block diagram illustrating an example of a data processing apparatus of a system collaboration platform according to an embodiment of the present application.

As shown in fig. 5, the data processing apparatus 500 of the system cooperation platform includes a service attribute determining unit 510, a target subsystem determining unit 520, and a service data table determining unit 530.

The business attribute determining unit 510 is configured to determine a first business attribute corresponding to a target business to be serviced by the system-based collaboration platform.

The target subsystem determining unit 520 is configured to determine, from the plurality of subsystems of the system collaboration platform, a corresponding at least one target subsystem according to the first service attribute.

The service data table determining unit 530 is configured to determine a service data table according to the historical data corresponding to each of the target subsystems, where the service data table is used for responding to the access request for the target service.

It should be noted that, for the information interaction, execution process, and other contents between the above-mentioned devices/units, the specific functions and technical effects thereof are based on the same concept as those of the embodiment of the method of the present application, and specific reference may be made to the part of the embodiment of the method, which is not described herein again.

Fig. 6 is a schematic diagram of an example of a mobile terminal according to an embodiment of the present application. As shown in fig. 6, the mobile terminal 600 of this embodiment includes: a processor 610, a memory 620, and a computer program 630 stored in the memory 620 and executable on the processor 610. The processor 610, when executing the computer program 630, implements the steps in the data processing method embodiments of the system collaboration platform described above, such as the steps 110 to 130 shown in fig. 1. Alternatively, the processor 610, when executing the computer program 630, implements the functions of each module/unit in the above-described device embodiments, such as the functions of the units 510 to 530 shown in fig. 5.

Illustratively, the computer program 630 may be partitioned into one or more modules/units that are stored in the memory 620 and executed by the processor 610 to accomplish the present application. The one or more modules/units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution of the computer program 630 in the mobile terminal 600. For example, the computer program 630 may be divided into a service attribute determination module, a target subsystem determination module, and a service data table determination module, and the specific functions of each module are as follows:

the business attribute determining module is configured to determine a first business attribute corresponding to a target business to be serviced by the system cooperation platform.

The target subsystem determination module is configured to determine, from a plurality of subsystems of the system collaboration platform, a corresponding at least one target subsystem according to the first business attribute.

The service data table determining module is configured to determine a service data table according to the historical data corresponding to each target subsystem, wherein the service data table is used for responding to an access request aiming at the target service.

The mobile terminal 600 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The mobile terminal may include, but is not limited to, a processor 610, a memory 620. Those skilled in the art will appreciate that fig. 6 is only an example of a mobile terminal 600 and is not intended to be limiting of the mobile terminal 600, and that it may include more or less components than those shown, or some components may be combined, or different components, e.g., the mobile terminal may also include input-output devices, network access devices, buses, etc.

The Processor 610 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The storage 620 may be an internal storage unit of the mobile terminal 600, such as a hard disk or a memory of the mobile terminal 600. The memory 620 may also be an external storage device of the mobile terminal 600, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), etc. provided on the mobile terminal 600. Further, the memory 620 may also include both an internal storage unit and an external storage device of the mobile terminal 600. The memory 620 is used for storing the computer program and other programs and data required by the mobile terminal. The memory 620 may also be used to temporarily store data that has been output or is to be output.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/mobile terminal and method may be implemented in other ways. For example, the above-described apparatus/mobile terminal embodiments are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The above units can be implemented in the form of hardware, and also can be implemented in the form of software.

The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A data processing method of a system cooperation platform is characterized by comprising the following steps:

determining a first business attribute corresponding to a target business to be served by a system cooperation platform;

determining at least one corresponding target subsystem from a plurality of subsystems of the system cooperation platform according to the first service attribute;

and determining a service data table according to the historical data corresponding to each target subsystem, wherein the service data table is used for responding to the access request aiming at the target service.

2. The method of claim 1, wherein determining a service data table according to historical data corresponding to each of the target subsystems comprises:

determining a second service attribute corresponding to the target service;

determining a corresponding target data acquisition mode from a plurality of data acquisition modes according to the second service attribute;

acquiring historical data according to the target data acquisition mode; and

and determining a business data table based on the collected historical data.

3. The method of claim 2, wherein the target data acquisition mode comprises a timed data acquisition mode,

wherein, according to the target data collection mode, collecting historical data comprises:

and according to a preset time period, acquiring historical data from the historical database corresponding to each target subsystem in a timing manner.

4. The method of claim 2, wherein the target data acquisition mode comprises a real-time data acquisition mode,

collecting corresponding first historical data from the message queues corresponding to the target subsystems;

and collecting corresponding second historical data from the historical databases corresponding to the target subsystems.

5. The method of claim 4, wherein collecting respective first historical data from the message queue corresponding to each of the target subsystems comprises:

subscribing the message queue corresponding to each target subsystem;

and collecting corresponding first historical data from each subscribed message queue.

6. The method of claim 4, wherein collecting respective first historical data from the message queue corresponding to each of the target subsystems comprises:

and for each target subsystem, continuously storing data in the message queue corresponding to the target subsystem by using a plurality of queue structures corresponding to a preset first time period to obtain corresponding first historical data.

7. The method of claim 6, wherein collecting the corresponding second historical data from the historical database corresponding to each of the target subsystems comprises:

and acquiring historical data corresponding to a preset second time period from the historical database corresponding to each target subsystem to obtain corresponding second historical data, wherein the second time period is greater than the first time period.

8. A data processing apparatus of a system collaboration platform, comprising:

the system comprises a business attribute determining unit, a business attribute determining unit and a business attribute determining unit, wherein the business attribute determining unit is configured to determine a first business attribute corresponding to a target business to be served by a system cooperation platform;

a target subsystem determining unit configured to determine, from a plurality of subsystems of the system cooperation platform, a corresponding at least one target subsystem according to the first service attribute;

and the service data table determining unit is configured to determine a service data table according to the historical data corresponding to each target subsystem, wherein the service data table is used for responding to an access request aiming at the target service.

9. A mobile terminal comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method according to any of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.