JP7142116B2 - Knowledge-intensive data processing system - Google Patents

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Patent Application Serial No. 14/665,171, filed March 23, 2015, entitled "Knowledge-Intensive Data Processing Systems," the disclosure of which is incorporated by reference in its entirety. is incorporated herein by

Background Complex applications such as managing cloud services, overseeing fulfillment centers, managing grids, advancing science, and treating patients can require applications to manage the building processes of vast amounts of data. As an example, compliance with Service Level Agreements (SLAs) is a key requirement for many cloud operations. SLA compliance involves continuous monitoring of key performance criteria and alerts of impending SLA violations to enable actions to avoid SLA violations or to provide faster problem resolution if violations occur. Requires predictive diagnostic capabilities to detect. Such cloud operations cover millions of data centers, networks, server machines, virtual machines, operating systems, databases, middleware and applications in private, public and hybrid clouds at the administrator and/or customer side. Individual hardware and software elements need to be monitored, diagnosed and managed.

Reactive anomaly detection and manual diagnostic techniques of traditional information technology (IT) operations are very labor intensive, require extensive domain expertise, and are very slow to respond, resulting in instead of isolating and identifying the , it can cause inappropriate responses, including restarting a large number of parts in the system, and fail to scale well to the cloud. Effective cloud system operation includes continuous measurement of important vital signs, time series analysis, multivariate system state models, system response models, predictive anomaly detection, machine learning-based classification, automated diagnosis and prognosis, Requires decision support and various control capabilities.

Brief Summary The embodiments described herein use big data and related technologies to capture and extract high-value data from low-value data to enable large amounts of complex high-volume and high-speed data. provide a variety of techniques for managing and processing The exemplary database system described herein can extract or generate high-value data as well as collect and process the data. High-value data may be utilized in databases that provide features such as multi-temporality, provenance, flashback and registration queries. In some examples, implementing computing models and systems can incorporate knowledge and process management features into a near real-time data processing framework within a computing system that recognizes data-driven situations.

In some embodiments, the techniques described herein store and update a multi-time database, evaluate filter queries based on the multi-time database, and invoke data transformation operations based on the evaluation of the filter queries. can be done. Input data from data streams, big data and other raw input data can be received and stored in multi-time databases. Filter queries, including database constructs such as expression filters, registration queries, triggers, continuous query notifications, etc., may be identified based on the updated multi-time data. Filter queries and/or data transaction processes may be executed based on the current data state and one or more past data states, and differences between multiple executions may be evaluated. Additional data transaction processes and/or loop application instances can be invoked with different filter queries and/or differences between data transaction process results corresponding to different times and data states.

1 is a block diagram illustrating an exemplary instance of an execution model for a data driven transformation loop application, in accordance with one or more embodiments of the present invention; FIG. 1 is a block diagram illustrating high-level elements of a cloud-based computer system executing data-driven applications, in accordance with one or more embodiments of the present invention; FIG. FIG. 4 is a flowchart illustrating a process for invoking data object transformations based on filter queries in a multi-temporal database, in accordance with one or more embodiments of the present invention; FIG. FIG. 4 is a flowchart illustrating an exemplary instance of execution of a loop data transformation application, in accordance with one or more embodiments of the present invention; FIG. FIG. 4 is a graph of valid data items in a multi-time database versus time, in accordance with one or more embodiments of the present invention; 1 is a block diagram illustrating components of an exemplary distributed system in which various embodiments of the invention can be implemented; FIG. 1 is a block diagram illustrating components of a system environment in which services provided by embodiments of the present invention can be provided as cloud services; FIG. 1 is a block diagram of an exemplary computer system upon which embodiments of the invention may be implemented; FIG. 1 is a block diagram illustrating an exemplary model for managing data, knowledge and processes in accordance with one or more embodiments of the invention; FIG. 1 is a block diagram illustrating a physical model, in accordance with one or more embodiments of the present invention; FIG. FIG. 4 is a block diagram illustrating an example CARE definition, in accordance with one or more embodiments of the present invention; FIG. 4 is a block diagram illustrating an example CARE definition, in accordance with one or more embodiments of the present invention; FIG. 4 is a block diagram illustrating an example CARE definition, in accordance with one or more embodiments of the present invention; FIG. 4 is a block diagram illustrating an example CARE definition, in accordance with one or more embodiments of the present invention; FIG. 4 is a block diagram illustrating an example CARE definition, in accordance with one or more embodiments of the present invention; FIG. 4 is a block diagram illustrating annotated FPHD data and CARE data in an exemplary KIDS loop, in accordance with one or more embodiments of the present invention; 1 is a block diagram illustrating information fusion of various types of information between related entity sets, in accordance with one or more embodiments of the present invention; FIG. FIG. 4 is a block diagram illustrating an implementation of a CARE loop in accordance with one or more embodiments of the invention; Implementation of Bayesian Belief Networks According to One or More Embodiments of the Invention is a block diagram showing

DETAILED DESCRIPTION In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments of the invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without these specific details. In some instances, some well-known structures and devices are shown in block diagram form.

The following description provides exemplary embodiments only and does not limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description of the exemplary embodiments. It is to be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.

Specific details are set forth in the following description to provide a thorough understanding of the embodiments of the invention. However, it will be understood by those skilled in the art that embodiments of the invention may be practiced without these specific details. For example, circuits, systems, networks, processes and other components may be shown as block elements in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail so as not to obscure the embodiments. It should also be noted that each embodiment is described as a process depicted as a flowchart, flow diagram, data flow diagram, structural diagram, or block diagram. Although the flowcharts describe the operations as sequential processing, many operations can be performed in parallel or concurrently. Additionally, the order of operations may be rearranged. A process ends when its operations are completed, but may include additional steps not shown in the figure. A process may correspond to a method, function, procedure, subroutine, subprogram, or the like. If the processing corresponds to a function, its termination can correspond to the calling function or the return of the main function.

The term "computer-readable medium" refers to non-transitory media capable of storing, storing or carrying instructions and/or data, such as portable or non-removable storage devices, optical storage devices, and various other media. Including but not limited to media. Code segments or computer-executable instructions can represent procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or hardware circuit by transferring and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be communicated, transferred, or sent via any suitable means such as memory sharing, message transfer, token transfer, network transmission, and the like.

Moreover, embodiments may be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments that perform the necessary tasks may be stored on a computer readable medium. A processor can perform the necessary work.

This specification describes various techniques (e.g., methods, methods, A non-transitory computer-readable storage memory) that stores instructions executable by a system and one or more processors is described. The exemplary database system described herein can extract or generate high-value data as well as collect and process the data. High-value data may be utilized in databases that provide features such as multi-temporality, provenance, flashback and registration queries. In some examples, implementing computing models and systems can incorporate knowledge and process management features into a near real-time data processing framework within a computing system that recognizes data-driven situations.

The techniques described herein can store and update the multi-time database, evaluate filter queries on the multi-time database, and invoke data transformation operations based on the evaluation of the filter queries. Input data from data streams, big data and other raw input data can be received and stored in multi-time databases. Filter queries, including database constructs such as expression filters, registration queries, triggers, continuous query notifications, etc., may be identified based on the updated multi-time data. Filter queries and/or data transaction processes may be executed based on the current data state and one or more past data states, and differences between multiple executions may be evaluated. Additional data transaction processes and/or loop application instances can be invoked with different filter queries and/or differences between data transaction process results corresponding to different times and data states.

Referring to FIG. 1, FIG. 1 is a block diagram showing an execution model of a data-driven transformation loop application. Execution model 100 may be implemented by an execution engine within a database system or other computing system. As described below, such an execution engine comprises dedicated hardware, software and software configured to implement data-driven processes for instantiating, tracking and controlling various elements within the execution model 100. /or may include network elements.

In this example, execution model 100 includes three different categories of objects: data objects, transformation objects and filters. Data objects can represent facts, event streams, relationships, XML (Extensible Markup Language) documents, structured content such as text, semi-structured content and unstructured raw content. Data objects can also represent metadata such as categories, tags, relationships and containers, and/or content captured by the acquisition process such as user interface forms, prescription forms and notification templates. . Transformation objects include algorithms, scripts, processes, queries, RDF (Resource Description Framework) axioms, production rules, decision trees, support vector machines, neural networks, Bayesian networks, hidden Markov models, Hopfield models, human tacit knowledge, and Various transform data can be represented. Transformation objects also include data that can be applied to data objects to add, modify, or delete data objects. A filter corresponds to a path expression and/or a Boolean expression that can be evaluated in the environment of one or more data objects and transformation objects. For example, a filter may include one or more queries registered with the database system that detect changed instances of data objects and/or transformation objects. Such filters can be implemented using database triggers, real-time journal analysis and/or queries registered on multi- or bi-temporal database systems.

As shown in FIG. 1, exemplary execution model 100 may correspond to a data transformation loop application. This data transformation loop application may be a potentially recurring loop process and/or an indeterminate loop process. In this example and other related embodiments, each of the different types of data objects can represent different data with different attributes or properties, and each of the different types of transformation objects can represent one type of data object. There may be implementations of different algorithms or systems that convert to different types of data objects. Although example execution model 100 includes four types of data objects and four types of transform objects, it should be understood that different implementations may have different numbers of data objects and transform objects (e.g., two data objects). object and 2 transform objects, 3 data objects and 3 transform objects,..., 5 data objects and 5 transform objects). It should also be understood that more or fewer filter objects may be implemented in different embodiments, and that some or all filters may not be implemented in a particular embodiment. is.

In the execution model 100, the first type data objects 103, 104 and 120 can represent the raw inputs entered into the computing system. These inputs may include, for example, data streams from the garbage collector within the Java Virtual Machine (JVM), stack traces from periodic thread dumps, memory heap dumps, database AWR reports, and the like. The first type of data objects 103, 104 and 120 may be unstructured conversations, form inputs, quantitative measurements collected from devices, event stream data, XML or text documents, and the like. The second type of data objects 107, 108 and 110 can represent qualitative descriptions of observed or predicted results that are inferred based on the first type of data objects. In some embodiments, the second type of data objects 107, 108 and 110 includes one or more of four different subtypes of data objects: observation objects, prediction objects, norm objects and objective objects. be able to. Observation objects can individualize facts into discrete values. For example, the fact strength of threads (number) for blocking database connections can be individualized into observation objects with qualitative values such as normal, protected, severe or critical. A prediction object can represent a qualitative value predicted from changing conditions. A prediction object can represent a qualitative value interpolated or extrapolated by an observation model, eg, via simulation. A norm object can represent a historical baseline qualitative value. Objective objects can represent target qualitative values for determining observed and predicted objects in order to achieve an overall objective and resolution. Third types of data objects 112 and 114 can represent probable diagnoses or causes based on second types of data objects (eg, observed objects and/or predicted objects). For example, due to a failure of the load balancer, the thread intensity of the thread class in the first server of the two server clusters is classified as a hypertensive state (intensity significantly higher than normal), and the thread intensity of the thread in the second server is classified as Classifying into a hypotensive state (significantly lower intensity than normal) may be a domain-specific example of a third type data object 112 or 114 . The fourth type data objects 116 and 118 may represent a set of scheduled actions that are inferred based on the third type data objects. For example, a set of instructions for capturing a heap dump or configuring a memory management policy may be a domain-specific instance of the fourth type data object 116 or 118 .

Each transformation object can represent abstract knowledge embodied as an automated software program, algorithm, technique, process, or method executing on a hardware and software computer system. Like data objects, transformation objects may be stored in a database system, a file-based storage system, or any data store. Various types of data can be computed within the execution model by retrieving stored transformation objects and applying them to various data objects.

For example, in the execution model 100, the first type transformation objects 105 and 106, for example, by generating a compact representation showing the important data taken from a pool or raw data stream corresponding to the first type data object: Techniques can be implemented for calculating a second type of data object based on a first type of data object. A second type transform object 111 may embody a technique for computing a third type data object based on a second type data object. A third type transform object 115 may embody a technique for computing a fourth type data object based on a third type data object. For example, a third type of transform object 115 may include techniques for developing directives based on the degree to which observed or predicted results deviate from norms. A fourth type transform object 119 may embody a technique for computing a first type data object based on a fourth type data object. For example, a fourth type transform object 119 may be designed to respond to a hypothesis (eg, a third type data object) and capture additional raw inputs (eg, a first type data object). .

The various filter objects 101, 102, 109, 113 and 117 in the execution model 100 can be implemented like data objects, e.g., as data stored in a database or other storage system, or like transformation objects, e.g. It may be implemented as a program, algorithm, technique, etc., or as a combination of data and program. In some cases, filter objects 101, 102, 109, 113, and 117 may implement a minimum data change threshold for determining how much change in data objects is sufficient to invoke a transform object. Additionally or alternatively, filter objects 101, 102, 109, 113 and 117 may be filtered by a condition, polarity or combination of data to determine which properties of the data object are sufficient to invoke the transform object. A minimum trust level can be implemented. As noted above, filters can include database triggers, real-time journal analysis, and/or queries registered on multi- or bi-temporal database systems.

Data objects and transformation objects can implement mechanisms for, for example, removing noise from data objects, detecting and extracting outlier data, and detecting and correcting periodicity trends. For example, the periodicity trend transformer can detect the periodicity trend of data changes in the persistent data object and update the smoothed strength and the smoothed strength growth rate to predict the strength growth trend. In this example, the normalized residual of the predicted intensity can be used as a transformer to detect outliers representing deviations of the measured intensity from the expected intensity. Additionally, multiple independent transformers can perform processing at different time scales in parallel with tracking data estimates. Depending on the timescale, these parallel transformers can serve multiple policies to predict periodic trends, long-term capacity demands, short-term endpoints (out-of-memory errors), and so on.

Like data objects, transform objects can change dynamically during the execution of a data-driven supervisory control loop. In some embodiments, the supervisory control loop can estimate transformation parameters and period factors of the Java virtual machine instances in the system by performing various techniques (e.g., non-linear regression). . In such an example, the supervisory control loop would use the transformation parameter and period factors can be incorporated into the transformation object.

One or more execution engines can be used to initiate, track and control data-driven loop applications such as those embodied by execution model 100 . Each time a data object, transformation object or filter object is dynamically updated, the execution engine, for example, instantiates each object in the illustrated execution model 100 and then executes the various processes performed by each object. and monitor and control the execution process. The execution engine detects new and/or updated data for one of the data objects in execution model 100 after instantiating various objects (eg, via object-oriented classes). can be done. After detecting new or updated data, the execution engine analyzes and/or modifies the data by calling the appropriate filter object or automatically executing the filter (e.g., expression filter or iterative query). and can determine whether or not to call a subsequent transform object. If necessary, the execution engine updates the next downstream data object in the loop by invoking the transform object, e.g., updates the data object of the second type based on updates to the data object of the first type. can do. Thus, the loop application can continue until a filter or transform object determines that subsequent data objects should not be updated.

Also, the multi-temporal database repository 121 can contain both low-value data and high-value data. For example, repository 121 may contain data corresponding to (FSD∪ features). Filters 101, 102, 109, 113 and 117 (also called guards) execute filter criteria or processes in the database and analyze data in repository 121 to evaluate differences between filter criteria/processes at different time states. The current and/or past data states can be retrieved by querying the .

Also, additional data updates can be made to any data object at any time during execution of the data-driven loop application. For example, while a transformation object 115 is executing an update of a data object 116, another data object 103 can be dynamically updated by a different process database transaction, the arrival of new data stream data, or the like. In this example, after the execution engine completes execution of transformation object 115, it effectively changes the loop application's instruction pointer to a completely different part of execution model 100 by calling filtering 101 and/or transformation object 105. can do. In another example, the execution engine can effectively pass multiple instruction pointers of a looping application to different parts of execution model 100 by calling filter 101 and/or transformation object 105 without waiting for transformation object 115 to complete execution. can be run asynchronously. Data objects 103, 104, 110, 114 and 118 in execution model 100 can represent a consistent state, although additional data updates can be made to any data object at any time.

In various implementations of execution model 100, different data objects, different transformation objects and/or different filter objects may be stored in a database or other data store, and various database technologies may be used to implement execution model 100 and the description herein. Other techniques disclosed in the document can be implemented. For example, object-oriented classes, such as data object classes and transformation object classes, can be established for some or all categories of objects in execution model 100 . From each implemented parent class, a type-specific subclass, e.g., a first type data object subclass, a second type data object subclass, a third type data object subclass and a fourth type data object subclass, and a One type of transformation object subclass, a second type of transformation object subclass, a third type of transformation object subclass and a fourth type of transformation object subclass can be derived. Each class and subclass implementation can be given labels and attributes appropriate to the applicable object category and type. For example, the execution engine may instantiate a data object of the first type and store attribute values associated with the data object. Similarly, a transform object of the first type can be instantiated and the attribute values associated with that transform object can be stored. Same below. The definition of each of these objects and all instances of these objects may be stored in data stores associated with one or more applications. For example, the execution engine of a data-driven transformation loop application can use various database technologies to store definitions and instances of data objects, transformation objects and filter objects. A bi-directional and/or multi-temporal database can be used to maintain multiple versions of each instance of each object so that the history of each instance can be retrieved. Additionally, in some embodiments, the execution engine can generate and store mappings of objects (instantiations of classes, subclasses, etc.).

In some embodiments, agent objects (or actor objects) may be included in execution model 100 and/or may be created and controlled by the execution engine. Agent objects may correspond to automated agents and may represent individuals, populations or organizations. Agent objects can be instantiated as object-oriented programming objects and can have attributes such as profile and provenance environment. Examples of automated agents include software that encapsulates algorithmic processes, such as workflows, simulations, support vector machines, neural networks, Bayesian networks, and the like. An automated agent can have a profile that indicates the capabilities of the agent. Agent objects can have attributes such as organizational environment, skill profile, knowledge profile, interest profile, preference profile, and the like. A knowledge profile is associated with an agent object and can represent implicit knowledge that systems generally do not encode. When an agent object represents an individual, the agent object can identify the real-time presence and/or real-time activity of the individual represented by that object. The execution engine can assign agent objects to particular transformation objects pending execution based on attributes of the agent objects.

As described further below, the execution model 100 can evolve special algorithms. These specialized algorithms can be used to transform the data or state of the environment by performing transformations such as classification, assessment, resolution and enactment. Transformation objects may represent specialized algorithms that do not need to work together directly. The execution engine of a data-driven process separately develops various algorithms for transformation objects and applies these algorithms to various types of transformation objects (e.g., first to fourth types) that interact via a standardized data model. By encapsulating it as a transformation object of type), it can be integrated into a single system that can evolve as a common application. Various algorithms within the system can complement and enhance each other. Also, some components within execution model 100 may include user interfaces and messaging systems that exchange information with instances of agent objects. Execution model 100 drives information exchange by continuously querying changes in data object instances and initiating execution of dependent transformation objects. Additionally, upgrades of a transform object (eg, updating algorithms, releasing new versions of software, etc.) can trigger retroactive processing of data object instances that have already applied transformations by that transform object. In this case, the transforms by the transform object can be applied immediately after deploying the new/updated transform object.

Referring to FIG. 2, a block diagram illustrating a computer system executing data driven applications is shown. Exemplary system 200 may represent a computer high-level implementation of a cloud-based system. The system can be used to manage the implementation and execution of data-driven applications designed to handle big data analytical problems. Such problems involve very large data volumes, high data rates, complex data types, and require the ability to process complex events in near real time. In this example, system 200 corresponds to a system for launching and managing data-driven applications using the HADOOP software framework. It should be understood that other software frameworks can be used in place of HADOOP in other examples. The various components shown in exemplary system 200, such as bi-temporal database 210, orchestration engine 220, resource manager 230, and computational cluster 240, are specialized combinations of hardware, software, and network elements. It may be implemented on a separate computer system or a shared computer system containing

In this example, the bitemporal database 210 can be implemented in a variety of database servers and technologies including hardware, software and network elements described herein. For a database 210 that uses a bi-temporal (or other multi-temporal) database schema, the various different objects (e.g., data objects, transformation objects, filter queries, etc.) stored within the database 210 are persistent data. It can be timestamped with the transaction time when it becomes or becomes recoverable or becomes visible to other recoverable transactions. These objects can then be invoked using a bi-temporal query consisting of valid time and transaction time. Based on these reification relationships in the bitemporal database 210, for any event manifested in the data, such as updating a data object, transformation object, or filter, it is possible to determine what caused the change. For example, the relationship in bitemporal database 210 is such that instances of a first type of data within a particular time interval are classified as one type of problem, and specific modifications are enacted within the big data system to solve the problem. It can be shown that In this example, the bi-temporal database 210 sends multiple different enacted amendments to the orchestration engine 220 or other system element in the chronological order in which each amendment was determined and enacted to determine why data changes occurred. can be provided to In other embodiments, other multi-temporal databases can be used, for example, multi-temporal databases containing additional timelines or time data of data items corresponding to decision times.

Applications for the big data analytics system can be created and managed by implementing the orchestration engine 220 using a combination of dedicated hardware, software and network elements. The orchestration engine (or execution engine) 220 may be implemented in the same database system with the bitemporal database 210, or may be implemented as a separate control server. In any case, the orchestration engine 220 can be designed to leverage database techniques associated with the bi-temporal database 210, such as complex time-registered flashback queries and expression filters. Orchestration engine 220 can assign data transformation loop applications to resource managers, such as HADOOP resource manager 230 (eg, HADOOP YARN resource manager). In response to the assignment, HADOOP resource manager 230 may select a compute node comprising HADOOP cluster 240 and launch Application Master (AM) 241 for the data transformation loop application within selected HADOOP cluster 240 . can. In some cases, the application master 241 can negotiate with the HADOOP resource manager 230 to obtain a container for performing data transformations for loop applications. For big data analytics, such data transformation behaviors may include, for example, machine learning behaviors, classification behaviors using large amounts of raw data, Bayesian Belief Network (BBN) engines, non-linear regression processes, periodic trend processes. . In some embodiments, the application master 241 of the data transformation loop application may be a long running process. However, containers in HADOOP cluster 240 can be reused when execution of an application's looping process (eg, execution model 100) is stopped or interrupted. Orchestration engine 220 can manage the state of each application master 241 for each data transformation loop application, and each application master 241 can manage the state of its associated data transformation instance 242 . Application master 241 and data transformation instance 242 can synchronize one or more high-value data objects with corresponding data in bitemporal database 210 .

In a particular example, system 200 can support big data analytics applications for cloud-based SaaS systems. For example, each tenanted application SaaS system in the public cloud can be implemented as a collection of pods or virtual machines and database instances using one or more virtualization technologies. The pod-scale model of application SaaS has the analytical advantage of enabling logical clustering of machine data and exploiting data locality to combine and correlate data streams within the same pod. In this environment, the number of data streams for each pod (each sensor providing one data stream) increases as the number of pods continuously increases. Data streams can include, for example, WebLogic server logs, Java Virtual Machine (JVM) garbage collector logs, JVM thread dump logs, HTTP access logs, operating system monitor logs, network device logs, database logs, and the like. Data streams can be stored, for example, in a set of HBase tables and HDFS folders. In some instances, collocate all data streams for each Pod on the same HBase Region Server by partitioning the Regions in the HBase table using the 32-digit MD5 description of the Pod name in the row key prefix. can be done. The data stream in a column cell may be offloaded to an HDFS file once it exceeds a threshold. Extract Transform Load (ETL) operations are performed by MapReduce's mappers, and data local affinity between mappers and HBase region servers allows HDFS files and HBase regions in the same pod to be transferred to the same datanode or HBase region server. can be placed in place. The data organization described in this example can enable data local and a relatively small proportion of rack local computation between application masters 241 for looping applications, data transformation operations, HBase regions and HDFS data nodes. Further, in such an example, orchestration engine 220 and application master 241 may use the dynamic entity model to select a compute node with HADOOP cluster 240 to launch data local application master 241 and containers. can.

The dynamic entity model for the application SaaS in the above example is customer pods, applications deployed on virtual machines, virtual machines deployed on physical compute nodes within a cluster of servers, and physical data nodes deployed on servers. and entities discovered by dynamic classification of high-intensity stack traces in periodic thread dumps according to thread segments, thread classes and/or dependencies between thread classes. . Dependencies can capture inter-thread and inter-process communication between threads. Therefore, a stack trace classification model can be added to the entity model. As noted above, the dynamic entity model may be managed by a temporal database (eg, a bitemporal database or other multitemporal database).

Referring to FIG. 3, a flow chart illustrating the process for invoking data object transformation processing based on filter queries in a multi-time database is shown. As described below, the steps in this process may be performed by one or more components within system 200, such as bi-temporal database 210, orchestration engine 220 and resource manager 230. However, it should be understood that the techniques described herein, including maintaining and updating the multi-time database, evaluating filter queries on the multi-time database, and invoking transform operations based on the filter query evaluations, are not limited to the specific It need not be limited to systems and hardware implementations, but can also be practiced in other hardware and system environments, including other combinations of hardware, software and network elements. Further, although the illustrative process 300 is performed based on updates to database data, similar processes and techniques may be performed in response to updates to transform objects and/or filter objects.

At step 301, database updates may be received, for example, from a data store and/or data manager associated with the data-driven application. For example, a database transaction containing one or more data updates may be initiated on bi-temporal database 210 and received via orchestration engine 220, HADOOP cluster 240, or other data source. The updated data received in step 301 can be of various data types (e.g., unstructured interactions, form inputs, quantitative measurements collected from devices, event stream data, XML, or text documents) can contain structured, unstructured and/or semi-structured data. In various embodiments, the received data can represent, for example, data streams from the Java virtual machine's garbage collector, stack traces from periodic thread dumps, memory heap dumps, database AWR reports, and the like.

At step 302 , one or more multi-time databases may be updated to reflect the data updates received at step 301 . For example, in bitemporal database 210, update data may be written to appropriate database structures that include the transaction time and/or validity time of the update data. A transaction time associated with received data can correspond to one or more time ranges over which the data is believed to be true. Validity time can correspond to the time range over which the received data is actually true for the modeled system. For example, one or both of the transaction time and validity time may be included in the data received at step 301 . Alternatively, the transaction time and/or validity time may be dynamically determined for the received data, eg, by orchestration engine 220 . In some cases, the validity time of received data may be defined by the lifecycle of the object associated with the data or the lifecycle of the database. Additionally, certain objects may include multiple valid times. For example, a feature vector may contain multiple features with different and potentially overlapping validity times. In this case, the validity time of the feature vector may be the intersection of the validity times of all relevant features.

In some embodiments, the systems, software frameworks and/or execution models described herein provide a valid Time and transaction time when data becomes persistent or recoverable or visible to other recoverable transactions can be tracked. By tracking both valid times and transactions, these systems can determine the data values of data object instances at different times and can determine the reasons for past changes made to data object instances. . For example, for a fourth type data object (eg, a directive type data object), the different first through third type data objects underlying the fourth type data object are formally called the fourth type data object. may be associated with data objects of type Thus, at the time orchestration engine 220 or other system element generates the current version of the fourth type data object, the available first through third type data objects associated with the fourth type data object can be determined retrospectively. Over time, new data may come in the form of updates to various first through fourth type data objects in the execution model, potentially as a result of previously generated directives and similar data in the loop application. Available. This new data is retroactive to a different object/data state at a past validity time at a different transaction time when the new data becomes available (e.g. becomes recoverable or visible to other recoverable transactions) can be applied

Therefore, any changes/updates that occur to the data after performing a subsequent transformation process based on past data can be isolated as non-causal, and the data changes at the validity time formally related to the transformation process. can be applied retrospectively, it can be described using the transaction time of data modification. Data updates that are acquired later and that may affect the performance of the data transformation process can be clearly identified as non-causal of the data transformation process if they already existed prior to their acquisition. These subsequently obtained data updates are removed from various data views, reports or analyses, and do not disrupt the underlying data underlying the data transformation process results. At any point in time, the system can determine why a particular data transformation process was initiated, and data transformation processes (e.g., one or more first data object instances) to produce results (e.g., updated data object instances of the second type). The underlying data available for a data object instance of type) can be deduced. These retrospective analyzes can be done by calling various data at an earlier transaction time before modifying the data at a later transaction time. In certain embodiments, bi-time source performance may be used to meet specific regulatory requirements.

At step 303 , one or more filter queries are identified based on the updates made to the multi-time database at step 302 . Filter queries can include any techniques and mechanisms used to track and manage data change states within a multi-time database. For example, filter queries can include database constructs such as expression filters, registration queries, triggers and continuous query notifications within the bi-temporal database 210 . Filter queries may also include extraction rules for forward- and/or backward-chaining data implemented within orchestration engine 220 and/or other system elements. These forward chained data and/or backward chained data can integrate multiple inference engines and/or time series algorithms. Some filter queries, e.g., expression filters and registration queries, may be implemented entirely within one or more database systems, while other filter queries, e.g., internal to the orchestration engine 220 or other system elements. The executing database access software may be partially or wholly implemented external to the database.

In this example, filter queries can be designed and implemented to provide notifications and/or perform specific actions in response to changes in the set of underlying data in the multi-time database. In some cases, a filter query may correspond to a conditional expression relating to one or more columns of a relational database table. For example, a filter query can match incoming data from the data update of step 303 with an expression stored in a database column to identify the target row. In some cases, a filter query may correspond to a simplified SQL query that provides notification or performs functionality whenever the underlying data of the simplified SQL query changes in the database. For example, if the result of an SQL query depends on four separate underlying data elements in the database, the filter query will generate a notification or execute a process whenever any underlying data element changes in the database. be able to. In some cases, a filter query does not reliably determine that the results of an SQL query or other data-driven process have changed, but changes in the data underlying the results cause the SQL query or other data-driven process to change. Potential change can be determined. In other cases, the filter query determines that the results of the SQL query or other data-driven process will definitely change the next time the updated data is used to execute the SQL query or other data-driven process. can do.

After identifying one or more filter queries associated with updated data in the multi-temporal database in step 304, the filter queries can be performed using the multi-temporal data in the current time state. Thus, filter queries can be performed based on the updated data received in step 301 and other multi-time databases of current data state.

At step 305, the same one or more filter queries performed at step 304 may be performed using the past-time state multi-time data. In some cases, past-time states may correspond to past times at which the associated transformation operation (or process) was performed in the past. As noted above, filter queries may be associated with conversion actions or other automated processes. For example, in exemplary execution model 100, filter queries 101 and 102 can act as guards for determining when to invoke transformation objects 105 and 106, respectively. Similarly, filter query 109 can determine when to invoke transform object 111 . Thus, for filter queries associated with instances of data transformation objects, the past time state determined in step 305 is the most recent time that the data transformation object was executed. After determining the past-time state corresponding to the execution of the filter query in step 305, the bi-temporal data (e.g., transaction time and validity time) stored in the database is used to generate an accurate data state of the database for the past time. can do. In some cases, without executing the filter query in step 305 , the past execution result of the filter query determined in the past time may be retrieved and used in step 305 .

At step 306, the results of one or more filter queries performed using the data in the current time state (step 304) and the results of similar filter queries performed using the data in the past time state (step 305). and compare the difference between the results to a predetermined threshold. In certain embodiments, changes in facts, perceptions, hypotheses or directives can be qualified or quantified using predetermined threshold conditions, directions, characteristics or values. Threshold conditions can include changes to transform objects that can change the result of the transform, such as new versions of algorithms, bug fixes, individualization of model parameters. If the difference between the filter query execution results equals or exceeds the threshold ( 306 : Yes), then at step 307 a data transformation process can be invoked. This data transformation process is similar to that described above with reference to the transformation object of FIG. For example, the data transformation process invoked at step 307 may correspond to instances of transformation objects of types 1-4 of exemplary execution model 100 .

Therefore, each filter query shall have one or more threshold conditions, directions, characteristics or values of change in facts, perception results, hypotheses or directives used to determine when to perform the associated transformation process. can be done. The higher the change in threshold condition, directionality, property or value, the more change in the underlying time data and the less associated transform processing is performed. Threshold conditions, orientations, characteristics or values associated with filter queries are advantageous in certain embodiments, for example, in big data analytics and other big data driven applications that receive frequent or continuous data updates. can be Receive and parse large data streams such as WebLogic server logs, Java Virtual Machine (JVM) garbage collector logs, JVM thread dump logs, HTTP access logs, operating system monitor logs, network device logs, and database logs In a looping application implemented as such, it is inefficient to perform the transformation process on every update received into the system. In this case, the filter query and associated threshold conditions, orientations, properties or values can act as guards that restrict data transformation operations performed within the loop application. As a result, data transformation processing can be performed only when the underlying data has changed to the extent that it can cause significant modification of downstream data objects.

In some embodiments, various steps of example process 300 may be performed in different database transactions and/or asynchronously. For example, in a data-driven application that receives and analyzes large amounts of streaming data or other frequent data updates, one transaction updates the multi-time database of step 302 and the other transaction performs the data conversion of step 307. It may be advantageous to carry out a treatment. As described below, the data transformation process of step 307 may cause additional iterative loop data updates and/or additional transformation processes to be performed. Therefore, in one or more transactions separate from the transaction that updates the database with externally received data (e.g., steps 301-302) or other event that initiated the application loop instance, the data Performance and stability of some systems can be enhanced by executing an application loop that performs transformations and updates (eg, step 307 and/or subsequent steps 401-416). Thus, in some implementations, steps 301 and 302 of process 300 may be performed in one dedicated database transaction, and steps 303-307 (and subsequent processes 401-416 based on these steps) may be performed in one dedicated database transaction. ) may be executed in one or more separate transactions. Further, in some embodiments, potentially slow or long-running looping applications can be executed asynchronously (eg, in the database engine's asynchronous execution mode).

Referring to FIG. 4, a flow chart illustrating execution of the loop data conversion application is shown. The steps within process 400 may be performed by one or more components within system 200 , such as bi-temporal database 210 , orchestration engine 220 and resource manager 230 . However, it should be understood that the techniques described herein need not be limited to the particular systems and hardware implementations described above, but may include other combinations of hardware, software and network elements. It can also be done within the hardware and system environment of

The exemplary process 400 shown in FIG. 4 is an execution model implemented by orchestration engine 220 or other system elements, similar to execution model 100 of FIG. 1 described above. In this example, the exemplary loop process 400, similar to the execution model 100, performs filters and thresholds before each data transformation operation to avoid unintended indeterminate loops, but potentially It may be a data transformation loop that iterates over and/or an indeterminate data transformation loop. The different data objects used in the exemplary process 400 (eg, first to fourth type data objects) may correspond to different types of data objects with different attributes or characteristics, and may correspond to different transformation objects. (eg, transformation objects of types 1 through 4) may correspond to implementations of different algorithms or systems for transforming data objects of one type into data objects of another type. Further, although the exemplary process 400 includes four types of data objects and four types of transform objects, it should be understood that different implementations may have different numbers of data objects and transform objects (e.g., two data objects and 2 transform objects, 3 data objects and 3 transform objects,..., 5 data objects and 5 transform objects).

Process 400 may begin at step 401 . Step 401 may correspond to step 307 invoking the conversion process described above. However, in other examples, the process 400 need not start at step 401, any of the steps of invoking data transformation (e.g., steps 401, 405, 409 or 413), any of the steps of generating and storing data. (eg, steps 402, 406, 410 or 414) or any step of executing a filter (eg, steps 403, 407, 411 or 415). As described above, a data-driven loop application process may change the state of data in the multi-time database 210, change transform objects (e.g., update algorithms, release new versions of software, etc.), or change filter objects ( for example, updating an expression filter query). Updates to data transformation objects and/or filter queries can trigger recomputation of data previously computed using older versions of transformation objects and/or filters. Thus, an update to one or more of system data, transforms or filters can initiate execution of application loop process 400 . Also, in some cases, thresholds associated with filters and/or transform objects can be dynamically updated. Application loop processing 400 may be invoked by dynamically re-executing one of the threshold determinations (eg, steps 404, 408, 412 and 416) in response to updated thresholds.

Referring to FIG. 5, a graph is shown identifying the validity times of some exemplary data items. The x-axis of graph 500 corresponds to time. Each of the times (t1-t8) marked on graph 500 represents an event that occurred in the system, such as execution of a data transformation process (eg, via a transformation object instance), execution of a data transformation process (eg, via a data object instance), Corresponds to updating database data, or updating conversion processing or filters. The y-axis of graph 500 corresponds to distinct data items in the multi-time database, eg, instances of one or more of the data object types described above. A line segment in the graph 500 indicates the valid time range of each data item. For example, data D1 corresponds to valid data between times t3 and t5, data D2 corresponds to valid data between times t1 and t2, and so on. Because the data in this example is bitemporal data, multiple different data items D1-D8 can represent the same data (eg, the same data object instance) at different times. For example, data item D1 may represent a data object instance from time t3 to time t5, and data item D8 may represent the same data object instance from time t5 to time t8.

The validity time data shown in graph 500 can be used, for example, to perform the retrospective analysis of step 305 described above. Using valid time data in a multi-time database to recall or rerun data transformation operations and/or to retroactively change data, processes or filters used in data driven loop applications , can search any past data state of multi-database. For example, a data-driven loop application compares the state of data in the multi-time database 210 and/or the results of transform operations or filters at the current time (e.g., t8) and similar data or operations at past times (e.g., t6). can do. In this example, the data state at current time (t8) consists of data items D3, D5, D7 and D8, and the data state at past valid time (t6) consists of data items D3, D4, D5, D6 and D8. consists of Corresponding filter queries and data transformation operations, etc., can thus accurately reflect the transformation operations that were performed at the current time and the state of the underlying data that drove the operations at past times.

Referring to FIG. 6, a block diagram illustrating components of an exemplary distributed system in which various embodiments of the present invention can be implemented is shown. In the illustrated embodiment, distributed system 600 is configured to run and operate client applications, such as web browsers or dedicated clients (eg, Oracle Forms), over one or more networks 610. includes one or more client computing devices 602, 604, 606, and 608 configured as Server 612 may be communicatively coupled to remote client computing devices 602 , 604 , 606 and 608 via network 610 .

In various embodiments, server 612 may be configured to run one or more services or one or more software applications provided by one or more components of the system. In some embodiments, these services are provided to client computing devices 602, 604, 60 as web services or cloud services, or based on a Software as a Service (SaaS) model.
6 and/or 608 users. Thus, a user operating a client computing device 602, 604, 606 and/or 608 may use one or more client applications to interact with server 612 to view the services provided by these components. can be used.

In the illustrated configuration, software elements 618 , 620 and 622 of system 600 are implemented on server 612 . In other embodiments, one or more components of system 600 and/or services provided by these components may be implemented by one or more client computing devices 602, 604, 606 and/or 608. good. A user operating a client computing device can utilize the services provided by these components using one or more client applications. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that various system configurations different from distributed system 600 are possible. As such, the illustrated embodiment is an example of a distributed system for implementing an embodiment system and is not intended to be limiting.

Client computing devices 602, 604, 606 and/or 608 may include, for example, software such as Microsoft Windows Mobile(R) and/or iOS, Windows Phone, Android(R), Blackberry (
10 and Palm OS, and Internet, email, short message service (SMS), BlackBerry® or other communication protocol enabled handhelds It may be a handheld device (eg, iPhone®, mobile phone, Ipad®, tablet, personal digital assistant (PDA) or wearable device (Google Glass® head-mounted display). Client computing devices are illustratively personal computers and/or laptops running various versions of the Microsoft Windows® operating system, the Apple Macintosh® operating system and/or the Linux® operating system. The client computing device may be a general-purpose personal computer, including a computer, for example, various GNU/Linux operating systems, such as commercial UNIX (including, but not limited to, Google Chrome OS).
It may also be a workstation computer running various operating systems similar to Microsoft® or UNIX. Alternatively or additionally, client computing devices 602, 604, 606, and 608 may be thin client computers, Internet-enabled gaming systems (e.g., Kinect® gesture input devices) capable of communicating over network 610. (with or without a Microsoft Xbox game console), and/or other electronic devices such as personal messaging devices.

Although exemplary distributed system 600 is shown with four client computing devices, it can support any number of client computing devices. Other devices, such as those with sensors, can exchange information with server 612 .

The network 610 of the distributed system 600 may use any of a variety of commercially available protocols including, but not limited to TCP/IP (Transmission Control Protocol/Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), Apple Talk, and the like. can be used to support data communication, and can be any type of network familiar to those skilled in the art. By way of example only, network 610 may be a local area network (LAN) based on Ethernet, Token Ring, and/or the like. Network 610 may be a wide area network or the Internet. Network 610 may include virtual networks including, but not limited to, virtual private networks (VPNs), intranets, extranets, public switched telephone networks (PSTN), infrared networks, wireless networks (e.g., Institute of Electrical and Electronic Engineers (IEEE) 802.11 protocol suite, Bluetooth®, and/or any other wireless protocol) and/or combinations of these and other networks.

The server 612 can be one or more general purpose computers, dedicated server computers (examples include PC (personal computer) servers, UNIX servers, midrange servers, mainframe computers, rack mount servers), server farms, It may consist of server clusters, or any other suitable configuration and/or combination. In various embodiments, server 612 may be configured to run one or more of the services or software applications described in the foregoing disclosures. For example, server 612 may correspond to a server for performing the processing described above in accordance with embodiments of the present disclosure.

Server 612 can run an operating system, including any of those mentioned above, and any commercially available server operating system. Server 612 also supports a variety of additional server applications and/or applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Java servers, database servers, and/or the like. or run any of the middle-tier applications. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, IBM®, and the like.

In some implementations, server 612 may include one or more applications that analyze and aggregate data feeds and/or event updates received from users of client computing devices 602 , 604 , 606 and 608 . By way of example, data feeds and/or event updates include, but are not limited to, Twitter feeds, Facebook updates or real-time updates received from one or more third sources and continuous data streams. . Real-time updates are useful for sensor data applications, financial tickers, network performance measurement tools (e.g. network monitoring and traffic management applications), page transitions (Clickstream)
May include real-time events related to analytical tools, automotive traffic monitoring devices, and the like. Server 612 may also include one or more applications for displaying data feeds and/or real-time events via one or more displays of client computing devices 602, 604, 606 and 608. .

Distributed system 600 may also include one or more databases 614 and 616 . Databases 614 and 616 may reside in various locations. By way of illustration, one or more of databases 614 and 616 may reside in non-transitory storage media near (and/or within) server 612 . Alternatively, databases 614 and 616 are remote from remote server 612 and communicate with server 612 via network-based or dedicated connections. In one set of embodiments, databases 614 and 616 may reside on a storage area network (SAN). Similarly, any necessary files for performing functions that contribute to server 612 may be stored on server 612 and/or remotely from server 612, as appropriate. In one set of embodiments, databases 614 and 616 may include relational databases such as those provided by Oracle, for example. These relational databases are configured to retrieve, store and update data according to SQL formatting instructions.

Referring to FIG. 7, a block diagram illustrating components of a system environment in which services can be provided as cloud services is shown. In the illustrated embodiment, system environment 700 includes one or more client computing devices 704 , 706 and 708 . A user can use a client computing device to exchange information with a cloud infrastructure system 702 that provides cloud services. A client computing device can be configured to run a client application, such as a web browser, a proprietary client application (eg, Oracle Forms), or other application. A user can utilize the services provided by the cloud infrastructure system 702 by exchanging information with the cloud infrastructure system 702 using client applications.

It should be understood that the illustrated cloud infrastructure system 702 may comprise components other than those illustrated. Moreover, the illustrated embodiment is but one example of a cloud infrastructure system in which embodiments of the present invention may be incorporated. In some other embodiments, the cloud infrastructure system 702 may have more or fewer components than shown, may combine two or more components, or may have different configurations or arrangements of components. may have elements.

Client computing devices 704, 706 and 708 may be similar to client computing devices 602, 604, 606 and 608 described above.

Although illustrated with three client computing devices, exemplary system environment 700 can support any number of client computing devices. Other devices, such as devices with sensors, can exchange information with the cloud infrastructure system 702 .

Network 710 may facilitate communication and exchange of data between clients 704 , 706 and 708 and cloud infrastructure system 702 . Each network can support data communication using any of a variety of commercially available protocols, such as those described above for network 1310, and may be any type of network familiar to those skilled in the art.

Cloud infrastructure system 702 can include one or more computers and/or servers that can include the components described with respect to server 1312 above.

In certain embodiments, the services provided by the cloud infrastructure system include online data storage and backup, web-based email services, hosted office suites that can be provided to users from the cloud infrastructure system on demand. and may include many services such as document collaboration services, database processing, manageable technical support services, and so on. Services provided by cloud infrastructure systems can be dynamically expanded to meet user needs. A specific instance of a service provided by a cloud infrastructure system is referred to herein as a "service instance." Generally, any service that can be provided to users from a cloud service provider's system over a communication network such as the Internet is referred to as a "cloud service." Typically, in public cloud environments, the servers and systems that make up the cloud service provider's system are different from the customer's on-premise servers and systems. For example, a cloud service provider's system can host the application, and users can order and use the application over a communication network, such as the Internet, as desired.

In some instances, services within a computer network cloud infrastructure may include secure computer network storage access, hosted databases, hosted web servers, software applications, or other services provided to users by cloud vendors. services, or other services known in the art. For example, a service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a relational database hosted on a web service and a scripting language middleware engine for private use by developers on the network. As another example, a service may include access to an email software application hosted on a cloud vendor's website.

In certain embodiments, the cloud infrastructure system 702 is a set of application, middleware and database services that can be provided to customers in a self-service, subscription-based, elastically scalable, reliable, highly available and secure manner. can include An example of such a cloud infrastructure system is the Oracle public cloud provided by the assignee of the present application.

In various embodiments, cloud infrastructure system 702 can be configured to automatically provide, manage, and track cloud infrastructure system 702 services subscribed by customers. Cloud infrastructure system 702 can provide cloud services via various deployment models. For example, the service may be provided in a public cloud model with a cloud infrastructure system 702 owned by an organization that sells cloud services (e.g., owned by Oracle) and utilized by the general public or businesses in different industries. can. As another example, services may be provided in a private cloud model, with cloud infrastructure system 702 dedicated to a single organization, and utilized by one or more entities within the organization. Cloud services may also be provided in a collective cloud model. Thus, the cloud infrastructure system 702 and the services provided by the cloud infrastructure system 702 are shared by multiple organizations within an associated collective. Cloud services may also be provided in a hybrid cloud model, which is a combination of two or more different models.

In some embodiments, the services provided by the cloud infrastructure system 702 fall into the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category.
Service) category, Infrastructure as a Service (IaaS) category, or one or more services provided pursuant to other categories of services, including hybrid services. A customer may order one or more services provided by cloud infrastructure system 702 through a subscription. In response, cloud infrastructure system 702 takes action to provide the services included in the customer's subscription form.

In some embodiments, services provided by cloud infrastructure system 702 include, but are not limited to, application services, platform services and infrastructure services. In some examples, application services may be provided by a cloud infrastructure system via a SaaS platform. A SaaS platform may be configured to provide cloud services conforming to the SaaS category. For example, a SaaS platform can function to build and deliver a suite of on-demand applications on an integrated development and deployment platform. A SaaS platform can manage and control the underlying software and infrastructure to provide SaaS services. By using the services provided by the SaaS platform, customers can use applications running on cloud infrastructure systems. Customers can acquire application services without having to purchase separate licenses and support. A variety of different SaaS services can be offered. Examples include, but are not limited to, sales performance management, enterprise consolidation, and services that provide solutions to business flexibility for large organizations.

In some embodiments, platform services may be provided by a cloud infrastructure system via a PaaS platform. A PaaS platform may be configured to provide cloud services that comply with the PaaS category. Examples of platform services are services that give an organization (e.g., Oracle) the ability to integrate existing applications on a shared common architecture and to build new applications that leverage the shared services provided by the platform. including but not limited to. A PaaS platform can manage and control the underlying software and infrastructure to provide PaaS services. Customers can use applications running on cloud infrastructure systems. Customers can acquire application services without having to purchase separate licenses and support. A variety of different SaaS services can be offered. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS) and others.

By using the services provided by the PaaS platform, customers can use the programming languages and tools supported by the cloud infrastructure system and control the deployed services. In some embodiments, platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (eg, Oracle Fusion middleware services), and Java cloud services. In one embodiment, the database cloud service can support a shared service deployment model that can give organizations the ability to accumulate database resources and offer DBaaS (Database as a Service) as a cloud database to customers. can be done. Middleware cloud services can provide customers with a platform for developing and deploying various business applications on cloud infrastructure systems, and Java cloud services are for deploying Java applications on cloud infrastructure systems. You can provide the platform to your customers.

A variety of different infrastructure services may be provided to the cloud infrastructure system by the IaaS platform. These infrastructure services facilitate the management and control of underlying computing resources such as storage, networks and other basic computing resources for customers using services provided by SaaS and PaaS platforms. do.

In particular embodiments, cloud infrastructure system 702 may also include infrastructure resources 730 for providing resources used to provide various services to customers utilizing the cloud infrastructure system. . In one embodiment, infrastructure resources 730 are pre-integrated and optimized combinations of hardware such as server, storage and network resources to run the PaaS platform and services provided by the SaaS platform. may include

In some embodiments, resources within the cloud infrastructure system 702 can be shared among multiple users and dynamically reallocated according to each's needs. Also, resources can be allocated to users in different time zones. For example, the cloud infrastructure system 730 may allow a first group of users in a first time period to utilize cloud infrastructure system resources within a specified time period, and then make similar resources available to another group of users in a different time period. Can be redistributed to maximize resource utilization.

In certain embodiments, multiple internal shared services 732 may be provided and shared by different components or modules of cloud infrastructure system 702 and services provided by cloud infrastructure system 702 . These internal shared services include safety and identification services, integration services, enterprise repository services, enterprise management services, virus scanning and whitelisting services, high availability backup and recovery services, services that enable cloud support, email services, including, but not limited to, notification services, file transfer services, and the like.

In particular embodiments, cloud infrastructure system 702 can provide functionality for comprehensively managing cloud services (eg, SaaS, PaaS, and IaaS services) within the cloud infrastructure system. In one embodiment, cloud management functions may include functions for providing, managing, and tracking customer subscriptions received by cloud infrastructure system 702 or the like.

In one embodiment, as shown, the cloud management function includes one or more modules, such as an order management module 720, an order orchestration module 722, an order fulfillment module 724, an order management and monitoring module 726, and an identity management module. 728. These modules may include or be formed using one or more computers and/or servers. These computers and/or servers may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and/or combination thereof.

At exemplary operation 734, the customer uses a client device, e.g., client device 704, 706 or 708, to request one or more services provided by cloud infrastructure system 702, Information may be exchanged with cloud infrastructure system 702 by ordering one or more services provided by . In certain embodiments, a customer may access a cloud user interface (UI), cloud UI 712, cloud UI 714, and/or cloud UI 716, and order a subscription via these UIs. Order information received by cloud infrastructure system 702 in response to a customer's order includes information identifying the customer and one or more services provided by cloud infrastructure system 702 to which the customer wishes to subscribe. can be done.

After the customer places an order, the order information is received via cloud UI 712, 714 and/or 716.

At operation 736 , the order is saved to order database 718 . Orders database 718 may be one of several databases operated by cloud infrastructure system 718 or operated in conjunction with other system elements.

At operation 738 the order information is transferred to order management module 720 . In some examples, order management module 720 may be configured to perform billing and accounting functions related to orders, such as order confirmation and post-confirmation order entry.

At operation 740 , information about the order is communicated to order orchestration module 722 . The order orchestration module 722 utilizes the order information to prepare the delivery of the services and resources ordered by the customer. In some examples, the order orchestration module 722 can use the services of the order fulfillment module 724 to arrange provision of resources to support the ordered services.

In particular embodiments, the order orchestration module 722 can manage the business processes associated with each order and can apply business logic to determine whether to pay for the order. can. At operation 742, upon receiving an order for a new subscription, order orchestration module 722 sends a request to order fulfillment module 724 to allocate resources and configure the resources needed to fulfill the subscription order. The order fulfillment module 724 can allocate resources for the services ordered by the customer. The order fulfillment module 724 bridges the level of abstraction between the cloud services provided by the cloud infrastructure system 700 and the physical implementation layers used to supply the resources to provide the requested services. Form. In this way, the order orchestration module 722 can be insulated from implementation details such as, for example, whether services and resources are provisioned on-the-spot or pre-provisioned, and allocated/given on request.

At operation 744, after provisioning the services and resources, the order fulfillment module 724 of the cloud infrastructure system 702 can send a notification of the services provided to the customer of the client device 704, 706 and/or 708.

At operation 746, the order management and monitoring module 726 can manage and track the customer's subscription orders. In some examples, the order management and monitoring module 726 collects usage statistics for services within a subscription order, such as storage usage, data transfer, number of users, system up time and system down time. can be configured to collect.

In certain embodiments, cloud infrastructure system 700 may include identity management module 728 . Identity management module 728 may be configured to provide cloud infrastructure system 700 with identity services, such as access management and authorization services. In some embodiments, identity management module 728 can control information about customers who want to use services provided by cloud infrastructure system 702 . Such information includes information authorizing the customer's identity and describing the customer's authorized execution rights to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). can contain. The identity management module 728 can include descriptive information about each customer, how to access and modify the descriptive information, and management over which customers access and modify the descriptive information.

Referring to FIG. 8, a block diagram illustrating an exemplary computer system upon which embodiments of the present invention may be implemented is shown. Computer system 800 can be used to implement any of the computer systems described above. As shown, computer system 800 includes a processing unit 804 in communication with multiple peripheral subsystems via bus subsystem 802 . Peripheral subsystems may include processing acceleration unit 806 , I/O subsystem 808 , storage subsystem 818 , and communication subsystem 824 . Storage subsystem 818 includes tangible computer-readable storage media 822 and system memory 810 .

Bus subsystem 802 provides a mechanism for allowing the various components and subsystems of computer system 800 to communicate with each other as needed. Although the bus subsystem 802 is shown schematically as a single bus, in alternate embodiments, the bus subsystem may utilize multiple buses. Bus subsystem 802 may have any of several types of bus structures, including memory buses or memory controllers, peripheral buses, and local buses using any of a variety of bus architectures. For example, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. Can include buses. These buses can be implemented as mezzanine buses manufactured according to the IEEE P1386.1 standard.

A processing unit 804 , which may be implemented as one or more integrated circuits (eg, a conventional microprocessor or microcontroller), controls the operation of computer system 800 . Processing unit 804 may include one or more processors. These processors may be single-core processors or multi-core processors. In particular embodiments, processing unit 804 may be implemented as one or more independent processing units 832 and/or 834, each comprising a single-core processor or multi-core processor. In other embodiments, processing unit 804 may be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

In various embodiments, processing unit 804 may execute various programs in response to program code, and may execute multiple programs or processes simultaneously. Some or all of the executed program code may reside in processor 804 and/or storage subsystem 818 at any given time. With proper programming, processor 804 can provide the various functions described above. Computer system 800 may further include a processing acceleration unit 806, which may include digital signal processors (DSPs), dedicated processors, and the like.

The I/O subsystem 808 can include user interface input devices and user interface output devices. User interface input devices include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice with voice command recognition systems Input devices, microphones, and other types of input devices may also be included. User interface input devices may also include motion sensing and/or gesture recognition devices, such as, for example, Microsoft Kinect(R) motion sensors. The Microsoft Kinect(R) motion sensor can control and interact with input devices such as the Microsoft Xbox(R) 360 game controller through a natural user interface (NUI) that utilizes gestures and voice commands. be able to. User interface input devices may also include eye gesture recognizers, such as the Google Glass® blink detector. The Google Glass® Blink Detector detects a user's eye activity (e.g., "blinking" when taking pictures and/or selecting menus) and converts eye activity to an input device (e.g., Google Glass). (registered trademark)). Additionally, the user interface input device may include a voice recognition detector that allows the user to interact with a voice recognition system (eg, Siri® navigator) via voice commands.

User interface input devices also include audio/visual devices such as three-dimensional (3D) mice, joysticks or pointing sticks, gamepads, graphics tablets, speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners. , fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye trackers. Further, user interface input devices may include medical image input devices such as, for example, computed tomography devices, magnetic resonance imaging devices, ultrasound emission tomography devices, medical ultrasound devices, and the like. User interface input devices may also include audio input devices such as, for example, MIDI keyboards and electronic musical instruments.

User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. The display subsystem may be, for example, a flat panel device using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device or a touch screen. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 800 to a user or other computer. For example, user interface output devices include various display devices that visually convey text, images, and audio/video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems. Including but not limited to.

Computer system 800 may include storage subsystem 818 . Storage subsystem 818 comprises software elements, which are shown located within system memory 1510 . System memory 810 may store program instructions loadable and executable by processing unit 804 and data generated by execution of these programs.

Depending on the configuration and type of computer system 800, system memory 810 may be volatile memory (eg, random access memory (RAM)) and/or non-volatile memory (eg, read-only memory). It may be a dedicated memory (read-only memory: ROM), flash memory). RAM generally contains data and/or program modules that are immediately accessible to processing unit 804 and/or are currently being operated on and executed by processing unit 804 . In some implementations, system memory 810 is static random access memory (SRAM).
or may include multiple different types of memory such as dynamic random access memory (DRAM). In some implementations, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 800, such as during start-up, is typically stored in ROM. can be By way of example and not limitation, system memory 810 stores application programs 812, program data 814, and operating system 816, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), and the like. also show By way of example, operating system 816 may include Microsoft Windows®, Apple Macintosh®, and/or Linux®
Various versions of operating systems, various commercially available UNIX or UNIX-like operating systems, including but not limited to various GNU/Linux operating systems, Google Chrome OS, etc. ) and/or iOS, Windows Phone, Android
® OS, BlackBerry ® 10 OS and Palm ® OS operating systems.

Storage subsystem 818 may also provide tangible computer-readable storage media for storing the underlying programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provide the functions described above when executed by the processor may be stored in storage subsystem 818 . These software modules or instructions may be executed by processing unit 804 . Storage subsystem 818 may also provide a repository for storing data used in accordance with the present invention.

Storage subsystem 810 may also include a computer readable storage media reader 820 that is further connectable to computer readable storage media 822 . Computer-readable storage media 822, along with or optionally in combination with system memory 810, is in addition to storage media for temporarily and/or permanently containing, storing, transmitting, and retrieving computer-readable information. , remote storage, local storage, permanent storage and/or removable storage.

Also, a computer-readable storage medium 822 including code or portions of code may include any suitable medium known or used in the art, which may be used for storing and/or transmitting information. Storage media and communication media including, but not limited to, volatile and nonvolatile, removable and non-removable media implemented in any method or technology. This may be RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other It may include non-transitory tangible computer-readable storage media such as optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or other tangible computer-readable media. It can also include intangible computer-readable media, such as data signals, data transmissions, or other media accessible by computer system 800 that can be used to transmit desired information.

By way of example, computer readable storage medium 822 includes hard disk drives that read from or write to non-removable, nonvolatile magnetic media, magnetic disk drives that read from, or write to, removable nonvolatile magnetic disks, and It may include an optical disk drive that reads from or writes to removable non-volatile optical disks such as CD ROMs, DVDs and Blu-ray disks or other optical media. Computer readable storage media 822 include Zip drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD discs, digital video tapes, and the like. obtain, but are not limited to. The computer-readable storage medium 822 also includes flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as solid-state ROM, solid-state RAM, dynamic RA, etc.
M, SSDs based on volatile memory such as static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for computer system 800 .

Communications subsystem 824 provides an interface with other computer systems and networks. Communications subsystem 824 serves as an interface for receiving data from other systems and for transmitting data from computer system 800 to other systems. For example, communications subsystem 824 may allow computer system 800 to connect to one or more devices over the Internet. In some embodiments, the communication subsystem 824 connects to wireless voice and/or data networks (eg, using cellular technology, advanced data network technology such as 3G, 4G or enhanced data rates for global evolution (EDGE)). Radio frequency (RF) transceiver components for access, WiFi (IEEE 1602.
11 family standards or other mobile communication technologies or any combination thereof), a global positioning system (GPS) receiver component, and/or other components. In some embodiments, communications subsystem 824 may provide a wired network connection (eg, Ethernet) in addition to or instead of a wireless interface.

Also, in some embodiments, communication subsystem 824 communicates structured and/or unstructured data feeds 826, event streams, and other data on behalf of one or more users who may use computer system 800. Incoming communications may be received in the form of 828, event updates 830, and the like.

As an example, the communication subsystem 824 provides real-time social data feeds 826 such as web feeds such as Twitter feeds, Facebook updates, Rich Site Summary (RSS) feeds. It may be configured to receive real-time updates from users of networks and/or other communication services and/or from one or more third party sources.

The communication subsystem 824 may also be configured to receive data in the form of a continuous data stream, which may be continuous or essentially devoid of sharp edges. may include an event stream 828 and/or an event update 830 of real-time events that may be unbounded in . Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (eg, network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

Communication subsystem 824 also communicates structured and/or unstructured data feeds 826, event streams 828, event updates 830, etc. to one or more streaming data source computers coupled to computer system 800. It can be configured to output to one or more databases with which it can communicate.

Computer system 800 may include handheld portable devices (eg, iPhone® mobile phones, Ipad® computing tablets, PDAs), wearable devices (eg, Google Glass® head-mounted displays), PCs, workstations, It may be one of a variety of types including mainframes, kiosks, server racks or other data processing systems.

Due to the continual evolution of computers and networks, the depicted description of computer system 800 is intended only as a specific example. Many other configurations are possible, having more or fewer components than the system shown in the figures. Customized hardware may also be used and/or particular elements may be implemented, for example, in hardware, firmware, software (including applets), or a combination. Additionally, connections to other computing devices, such as network input/output devices, may be utilized. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other means and/or methods for implementing various embodiments.

In the above description, the methods have been described in a particular order for purposes of illustration. In alternate embodiments, the methods may be performed in a different order than the order described. Also, the methods described above may be performed by hardware components or embodied in a series of machine-executable instructions. Machine-executable instructions can be used to direct a general-purpose or special-purpose processor or logic circuit programmed with the instructions to perform the methods. These machine-executable instructions may be stored on one or more machine-readable media or memory devices, such as CD-ROM or other type of optical disk, floppy disk, ROM, RAM, EPROM, EEPROM, magnetic or optical. It includes a card, flash memory, or other type of machine-readable medium or memory device suitable for storing electronic instructions. Alternatively, these methods may be performed by a combination of hardware and software.

Although illustrative and presently preferred embodiments of the invention have been described in detail herein, it is to be understood that the concepts of the invention may be embodied and used in many different forms, including the following: The claims are intended to cover these variations except as limited by the prior art.

Exemplary Embodiments Referring to FIG. 9, FIG. 9 illustrates a Knowledge-Intensive Database System for managing data, knowledge and processes in a manner that is synergistic, consistent and organized. :KIDS) shows an example of a model. As described below, the model captures quantitative facts, derives compact qualitative information by classifying the facts, establishes one or more hypotheses by evaluating the derived information, and formulate directives (or determine prohibitive directives) by using the hypotheses of New facts can be created by implementing the resulting directives. Same below.

Looking at the KIDS model of FIG. 9 from a knowledge perspective, the CARE loop (Classification, Assessment, Resolution and Enactment) consists of four different categories of knowledge. These four different categories of knowledge act on specific categories of data to produce specific categories of data. The CARE loop represents the normalization workflow. Looking at a similar model from a data perspective, the FPHD loop (Fact, Perception, Hypothesis and Directive) has 4
Represents one type of data. Data, without distinction, describes what is stored in modern database systems. Formal knowledge is stored in articles, books, application code, workflows, case management systems or decision support systems without distinguishing between the times and interactions that use the knowledge the most. To compensate for this shortcoming, the CARE/FPHD loop creates an interaction structure between data, knowledge and processes that is sorely needed by applications.

In this embodiment, the KIDS may include the KIDS model itself, the KIDS tools and the KIDS infrastructure. This KIDS infrastructure is designed to manage four categories of data, four categories of knowledge, and the launch of knowledge and data based on a normalization processing structure. The KIDS model can interconnect data, knowledge and processes as seen in the real world. The KIDS model differs from current models in that knowledge and processes exist in separate worlds, separate from each other and from data. By using KIDS tools, users can develop applications based on the KIDS model. These tools leverage existing tools available in various components and add support (constraints) to comply with the KIDS model. The KIDS infrastructure leverages existing technologies, particularly modern databases and application servers, for managing application execution, data and knowledge in the form of rules, storage queries, models, data transformation procedures and workflows that control the use of knowledge. use.

KIDS can combine two evolving big data and CEP technologies when managing data. While the classification of the CARE loop can be implemented using big data techniques (in ad-hoc/batch environments) or CEP techniques (in real-time environments), KIDS classifies these data and knowledge representations and It advances both big data technology and CEP technology by incorporating into modern application structures. That is, big data and CEP are among the key technologies of KIDS, including FSD (flexible schema data), multi-time databases, provenance, ILM (Information Life Cycle Management), registration queries and OLAP data cubes, etc. are two important basic elements in

In various embodiments, KIDS is:
A model for structuring applications to better manage data, knowledge and processes;
normalization of data, knowledge and interactions by introducing four pairs of complementary categories, each pair serving a specific purpose in the interaction structure;
・Comprehensive environment for big data and CEP,
a declarative specification of all components,
state tracking, time transition, and provenance features;
• Provides a model for continuously evolving applications through infrastructure improvements, evolution of user standards and knowledge discovery from data.

Use Case - Cloud Operations Compliance with Service Level Agreements (SLAs) can be a key requirement for cloud operations. SLA compliance involves continuous monitoring of key performance criteria and alerts of impending SLA violations to enable actions to avoid SLA violations or to provide faster problem resolution if violations occur. Requires predictive diagnostic capabilities to detect. A typical cloud operation includes hundreds of data centers, networks, server machines, virtual machines, operating systems, databases, middleware, and applications located in private, public, and hybrid clouds on the operator and/or customer side. Tens of thousands of hardware and software elements need to be monitored, diagnosed and managed. Traditional IT operational reactive anomaly detection and manual diagnostic techniques are very labor intensive, require extensive domain expertise, and respond very slowly to isolate and Rather than specific, it can cause inappropriate responses, including restarting a large number of parts in the system, and fail to scale properly to the cloud. Cloud operations use diagrams to obtain periodic cycles, load trends, load spikes, system response characteristics and transient glitch dynamics, early warnings of degradation and aging, and performance evolution of millions of components in the environment. This is an area where rapid iteration of KIDS loops, such as the CARE/FPHD loop shown in 9, can grow. Through computerized KIDS loops, such systems can provide continuous measurement of vital signs, time series analysis, multivariate system state models, system response models, predictive anomaly detection, machine learning-based classification, automated diagnosis and prognosis. , decision support, and control capabilities.

The basic premise of cloud computing is to provide virtually unlimited resources through scale effects through consolidation and pooling of physical resources, and dynamic resource management. In addition to dynamic resource management, the control system manages a dynamic entity model to keep pace with changes in the system due to frequent releases of new software, patches to fix bugs, hardware upgrades, and capacity expansion. It should provide accurate recognition.

In this section, we describe the complexity of the entity model, along with the large amount of machine data containing important vital signs of system health. Big data analysis and real-time CEP technology have received great attention to solve problems in this field. Each technology by itself is insufficient to solve the problems in this field, but in most cases the two technologies are separated. A framework, such as KIDS, is needed to integrate the two technologies and add other required technologies for large-scale state management. Examples of essential technologies include, for example, bitemporal databases, expression filters, registration queries, and forward chaining to integrate many inference engines such as RETE, BBN, MSET, SVM, neural networks, OWL and various time-series algorithms. Orchestration engines and back chain orchestration engines are included.

Referring to FIG. 10, a physical model is shown. This entity model is the model used for Oracle Fusion application SaaS that includes customer pods. This Fusion application is deployed in a virtual machine. The virtual machines are placed on the physical compute nodes of the Exalogic rack and the databases are placed on the physical database nodes of the Exadata rack. This entity model is extended with entities discovered by dynamic classification of high-intensity stack traces in periodic thread dumps by thread segments, thread classes and dependencies between thread classes. Dependencies capture communication between threads and communication between processes. Adding a stack trace classification model to an entity model is very similar in systems biology to adding human genome informatics to a human anatomy model.

Thread intensity provides a statistical measure of the "hotness" of system function performance hotspots. The hotness of a code block can be quantified by multiplying the number of calls to the code block times the execution time of the code block. A similar measure can be used with various performance analysis tools such as Oracle Sun Studio 12 Performance Analyzer, Intel® VTune Amplifier, AMD® CodeAnalyst, Oracle Database Active Session History (ASH), Oracle JRockit Flight Recorder, and Applies to the UNIX gprof command.

A thread class is an ordered set of segment classes. For example, the CRM Domain Sales Server ADF Application Thread is represented by a set of segment classes (CRM Domain, Sales Server, ADF Application, and ADF Web Service Call). An exemplary thread dependency is [(ADF Web Service Call)→(ADF Web Service, ADF-BC)]. [(ADF Web Service Call) → (ADF Web Service, ADF-BC)] is subclass [(CRM Domain, Sales Server, ADF Application, and ADF Web Service Call) → (CRM Domain, Order Retrieval Server, ADF Web Service , ADF-BC, database operation)]. Classes (ADF Web Service, ADF-BC) may be drilled down into high intensity classes (CRM Domain, Order Fetch Server, ADF Web Service, ADF-BC, Database Operations), through thread dependencies, database Drill into Threads (Database, Fusion App Schema) and then view the call graph, call tree or call stack model (including SQL execution plans and execution traces) in the database (Database, Fusion App Schema) with a high-intensity subclass of Thread (Database, Fusion App Schema) may be drilled down to.

Exception traces can be correlated between middleware and database layers with execution environment IDs (ECIDs) propagated along the call chain to aid in root cause analysis of problems in individual execution environments. . Vital signs can be used to diagnose system problems based on measurements of intensity statistics for different classes of threads and thread segments from a series of thread dump samples taken at regular time intervals. Dependency information between classes of threads can be used to assist in root cause analysis by correlating incidence between middleware and database hierarchies. Thread strength statistics improve the ability to drill down the taxonomy hierarchy to observe the strength of particular subclasses of the thread hierarchy. Thread intensity statistics improve the observability of traffic intensity of communication channels between threads or queues in resource pools and sensitivity to small performance glitches, which are key indicators of SLA problems.

Data cubes can be roll-up, drill-down, slice and dice, pivot, drill-across, and drill-through are defined with dimensions and concept lattices that reflect "parts" of the relationships in the entity model to support OLAP operations such as A predictive diagnostic solution requires a state-space model of the system that includes measurements of various system statistics that constitute the vital signs of system function. The Multivariate State Estimation Technique (MSET) is particularly effective in fusing time series data from a set of related entities. MSET combined with the Sequential Probability Ratio Test (SPRT) is a robust classification model that applies machine learning to predictive anomaly detection. Statistical measures are extracted from big data system logs and organized into data cubes. Statistical measures include trend and periodicity information derived by time series filters. Brown exponential filter, Holt double exponential filter, Winters triple exponential filter, Wright expansion for irregular time intervals, Hanzak adjustment factor for short time intervals, and/or outlier detection and Cauchy distribution problems, especially JVM full GC A particular time series filter can be implemented based on truncation with adaptive scaling of outlier truncation to overcome the Cauchy distribution problem in time series analysis of statistics. Trends such as level surges, level transitions, variance changes, outliers and endpoint predictions can be extracted from time series data and this quantitative trend can be transformed into qualitative values such as low, normal or high.

Higher order classification information can be extracted by transforming fact data, including JVM full GC statistics and periodic thread dumps. Thread segments and threads are classified in increasing order according to traffic intensity. Stack traces are categorized into high intensity thread segments and threads and higher level information including dependencies between thread classes and thread class drill-downs into segment classes. Time-series data of periodic thread dumps provide trend information about the strength of each thread class and segment class, such as periodic cycles, linear trends, variance changes, level surges, level transitions, outliers, saturation or endpoint predictions. include. By scaling the number of events to the number of substantial trend changes over observation time, trend information reduces large amounts of time-series data to a more concise series of events. System states can be identified by feature vectors representing trend information. System state transitions can be defined by events that represent substantial trend changes.

Thus, the KIDS model is capable of fusing various specific types of information such as observations, objectives, predictions, simulation results and periodic predictions inferred by different taxonomic knowledge and fusion of information between related entities. . The KIDS model also addresses the complexity required to detect anomalies, diagnose root causes, and dynamically manage resources during large-scale cloud operations by supporting an effective KIDS loop. and heterogeneity, it is capable of information fusion and situational awareness.

Use Case - Software and Hardware Product Support This use case can be characterized by collaborative and iterative problem-solving behavior by support and customer-facing technicians to minimize system unavailability. . To achieve these goals, the time required to search and apply existing (implicit or explicit) knowledge to solve a known problem, or to find improvements to a new problem. It is important to minimize the time spent By increasing or maximizing the degree of automation in handling known problems, support and customer-facing technicians are freed up to focus on emerging problems that require a great deal of human experience and knowledge. . Applications developed in this field are therefore subject to constant change due to constant automation demands. Automation requirements address three challenges: 1) achieving economical automation, 2) designing applications to enable rapid deployment of automation, and 3) how to obtain an accurate representation and provenance of the problem solved. The biggest non-technical problem arises. Ensuring capture of data and knowledge about product issues throughout the product lifecycle (in bug databases, support tickets) with accurate representation and provenance is essential to enable economical automation . These data and knowledge include terminology consistent with precise definitions, precise and valid causal relationships, system configurations and contributions of engineers. Such representations and provenance allow accurate statistics regarding the likelihood of problem recurrence and complexity in automatically or semi-automatically recognizing and solving problems. A process for diagnosing problems can then be standardized based on the source data collected. The purpose of such standardization is to establish standardization for standardized collection of data, standardized analysis and interpretation of data, standardized diagnosis, standardized remediation, and standardization throughout the problem-solving process.

To achieve a robust application architecture that enables rapid deployment of automation, the automation problem space can be divided into coherent modular elements. In order to achieve such partitioning, the automation complexity of the space may not be uniform. Automating data collection is less complicated than automating data analysis. Also, automation of data analysis is less complex than automation of diagnostics. Also, repair automation is more complex and different. Such automated varying levels of complexity can provide natural boundaries for partitioning the problem space.

Use Case—Patient Care Patient care can be a demanding task dictated by an ever-increasing amount and complexity of captured data, observations, knowledge and procedures. As medical sensors become mainstream, the amount of data and knowledge is expected to grow even faster. By using sensors, a doctor can diagnose a patient at all times, whether the patient is in the doctor's office or not. The collection of EMRs (Electronic Medical Records), the combination of data describing measurements, images (and readings), observations, diagnoses and treatments, is of great importance, but these records alone are not enough. Inadequate. EMR does not organize the data into meaningful categories, but rather who looked at what data when, what diagnosis was made for what reason, what computerized knowledge and version was used to draw what conclusions. is not listed. Also, medical costs are enormous and misdiagnosis lawsuits continue unabated, either caused by physician negligence or by patient or attorney greed.

Physicians use many methods to care for their patients. Some frequently used terms include case-based medicine, care standards, differential diagnosis and individualized/precision medicine. A myriad of applications can be used to support physicians, but these applications can only do some of the work, and furthermore, because these applications are proprietary and obscure, they are substantially larger and more individualized. It is not possible to do the optimization and fast evolution. A non-exhaustive list is to assist physicians at all stages of treatment, enable physicians to communicate with the system in the physician's language, convert measurements into compact form, provide precise provenance, warn of abnormalities, and A perpetually evolving system that allows for expansion and personalization is needed.

Patient care begins with the collection of evidence obtained in the form of facts and observations. Facts include measurements such as vital signs, blood chemistries and images. Measurement facts are quantitative. Using classification, facts are transformed into cognitive outcomes such as the degree to which measurements deviate from the norm and the interpretation of images. Facts are complemented by observations treated as cognitive outcomes. Evaluating the cognitive results can lead to one or more diagnoses (hypotheses) that determine the underlying cause and associated reliability of the observed disease. In the next step, based on the standard of care, a treatment plan leading to directives, eg, specific treatments and/or more tests, can be performed. Implementing Directives produces more facts. This cycle continues until either the goal has already been met or there is nothing more to be done, or there is a hypothesis that nothing more can be done. This is an example of differential diagnosis. Most of these steps are computer-supported or increasingly computer-supported so that the patient can be permanently monitored based on a constant fact stream. New computerized knowledge must be used as soon as it is validated and released. Support needs to be individualized. Knowledge needs to be applied based on individual or team preferences. Social networking and tacit knowledge profiling can help identify the person or team most qualified for the task.

This use case highlights the need to transform facts into cognitive outcomes. Patients have approximately 10 vital signs. These vital signs have varying magnitudes and ranges, depending on the patient's circumstances. Therefore, it is very difficult to specify notification conditions. Physicians use the same classifier for many types of facts and specify notification conditions by classifying the facts. Possible modifiers of all vital signs are normal, monitored, serious and critical. The real goal is to use fewer modifiers to express things intuitively. Qualifiers can be used to normalize and simplify the query Tell me all patients with at least 1 critical vital sign or 2 serious vital signs. Physicians add annotations such as worsening/improving to progression values over time. The rate of change can be used to discuss slow deterioration or fast deterioration. Obviously, one can discuss stability values such as whether the patient's vital signs are stable or not. Cognitive Results is preferred by physicians because it uses intuitive and compact language. Ambiguity in cognitive results must be compensated for by strict provenance.

In addition to the benefits of classifying single values, there is a greater need to classify sets of values or images. As an example, the risk of cardiac arrest can be determined from a blood test hours earlier. Unfortunately, this judgment requires understanding complex interrelationships between at least ten numerical values. This is impossible for even the brightest professional, but a computer can do it well. Therefore, there is a need to evaluate a large number of models in real time. This allows physicians to recognize potential risks they may not have experienced or known about. Similarly, physicians need precise provenance in order to view classifications.

Cognitive outcomes should describe important features of the patient's current situation in time. This is because doctors want to know what is happening now, how this situation has evolved, and how it will evolve in the future. Also, past situations must be readily available. By using predictions in conjunction with classification, physicians can articulate a very generic request to notify if a patient's condition does not evolve as expected. This request has a specific meaning in a specific situation.

KIDS Model - Concepts KIDS provides a model for structuring applications that focus on data, knowledge and process management (see, eg, Figure 9). Data management is now a relatively mature technology that is evolving rapidly. KIDS adds to this evolution by defining and managing four different data categories:
• Facts Facts are data that can be measured in the world. The human cognitive system has difficulty directly perceiving the number, velocity and quantitative nature of facts. Technologies such as CEP and big data acquire and process these data.
Cognitive Outcomes Cognitive outcomes are compact, temporal and qualitative representations of facts (and observations). Cognitive results are optimized for use by the human cognitive system. Cognitive results represent the most important features of the evolutionary state that can be discerned from facts. Cognitive results depend on the viewpoint of the user who uses the information.
Hypotheses Hypotheses describe possible root causes that explain facts and cognitive outcomes.
• Directives Directives describe actions to be taken in response to certain facts, perceived outcomes and hypotheses. Directives often specify action plans in the form of workflows or processes. Clearly, directives will have the greatest impact on the evolution of facts.

Any of these categories of data can be represented by a wide range of data types/structures, extensibility, declarative access between data types/structures, transitions over time, flexibility of evolving data structures (supporting structured data, and supporting data first and then structure or not), OLTP and parsing, etc. It may also require advanced features such as (fine-grained) security, provenance and ILM. Key operational features may include disaster recovery, high availability, reliability, scalability, performance, and rapid development tools. In some cases, managing data requires extensive functional and operational support available in mature and widely used databases. Collection and management of facts does not require classical trading models and can tolerate limited loss of data. A mature database can provide support for optimizing fact management and significantly reducing resource consumption.

In certain embodiments, knowledge can be divided into four categories to complement the four data categories: Classification, Assessment, Resolution and Enactment. The four categories are based on the mode of reasoning required to process each data category. Appropriate computational models can automate a substantial subset of each category of knowledge.
• Classification knowledge (transforming data into cognitive outcomes) is primarily expressed in deductive reasoning mode. Some classification knowledge that produces predictions or norms may involve inductive reasoning. Computational models for classification include support vector machines, naive Bayes networks, neural networks, clustering, association rules, decision trees, multivariate state estimation techniques, cognitive arithmetic, and others.
・Evaluation knowledge (converting recognition results into hypotheses) is typically realized by idea inference that derives hypotheses from recognition results. Computational models for evaluation include Bayesian belief networks, least-squares optimization of solutions to inverse problems, or regression.
• Solution knowledge (which converts hypotheses to directives) makes decisions under outcome uncertainty, considering the relative merits and associated payoffs/costs of different outcomes. Computational models for solving have been extended with decision and payoff/cost nodes and include Bayesian belief networks known as influence diagrams, Dempster-Shafer theory, decision trees and prognostics of remaining useful life.
Implementation knowledge (transforming directives into actions (and new facts)) can be scripted, planned,
It contains schedules, BPEL workflows, and control structures coded into BPMN business processes.

Knowledge may be applied in the proper order specified by the CARE loop. In some cases, it is not necessary to perform all steps of the CARE loop. Storing knowledge (including versions) in a database can provide complete provenance and enable sophisticated querying. Knowledge is ad-hoc and real-time applicable. One use case is to discover what is missing and what is overestimated by revisiting data (especially facts and cognitive outcomes) with new knowledge.

Using big data/CEP in the KIDS environment can create a more comprehensive and systematic approach.
• Queries/models are treated as knowledge rather than individual elements. Knowledge can be queried and evolved.
• Data and knowledge (queries, rules and models) are related to each other in four categories with specific properties.
• Transforming facts into cognitive outcomes is contextually complemented by actions.
• Provenance support clearly states which version of knowledge was applied to derive which version of the data.

Furthermore, formal knowledge in each category may be supplemented by human tacit knowledge. Applications may require social networking services that can profile the tacit knowledge and social preferences of actors within the system. Therefore, by adjusting the tacit knowledge profile based on recent behavior, the person or team most qualified for the task can be identified. This can ensure that the profile is as up-to-date as possible.

In some embodiments, the application can include continuous improvement. Continuous improvement of an application can be achieved by continuously improving knowledge. Techniques that enable continuous improvement are: 1) techniques that leverage the insights of users and subject matter experts to improve rules, queries, models and code; including techniques for re-evaluating and re-executing

Subject matter experts can exchange knowledge. This exchange will be as formal as possible. The paper provides Venn diagrams to help intuitively understand the model or formalism used.
Diagram). New knowledge usually needs to be carefully reviewed before it can be used. KIDS can use evolving and existing knowledge simultaneously and can show the results of both. KIDS can also review existing data with new knowledge, and can point to new as well as previously overestimated risks and opportunities.

Formal Model of KIDS KIDS is a human actor, a computer program or hardware element (agent) acting on behalf of the human actor, and/or an engine that drives interactions between the entities being observed, diagnosed and treated. can contain. The formal model of KIDS can actively manage information change within the system by informing the implementation of process management applications that drive interactions between actors, agents and entities within the system.

A formal model of KIDS may be represented in a multi-temporal database system. The data in the model are considered to have a transaction time (Txn time), but the transaction time may not be explicitly represented in the model. One exception to this rule is behavioral environments that explicitly represent transaction times to support flashback queries and provenance.

Valid Time may be explicitly indicated in FSD data and feature data, two of the basic data structures in the formal definition.

FSD ⊆ entity x value x valid time x FSD type feature ⊆ entity x value x valid time x feature type vector = { feature ⁿ | n = 1, 2, . . . , N}
Big vector={FSD ⁿ |n=1, 2, . . . , N}∪ vector A FSD (Flexible Schema Data) can be any extensible data in a database, including text, audio, video, spatial, graph, XML, RDF and JSON. Thus, an FSD can represent a file. Depending on the type of FSD involved, the files can include electrocardiograms, x-rays, CT scans, MRI scans, etc. in the patient care domain, thread dumps, Can include heap dumps, database AWR snapshots, database traces, and the like. Features can represent categorical values such as low, normal and high within the observed range of symptoms or diseases. Depending on the type of feature involved, a condition or disease can represent respiratory infections, acute bronchitis, asthma, etc. in the patient care domain; It can represent hypotension, impedance mismatch, convoy effects, and the like.

Valid time and Txn time are time intervals. The time interval [t1, t2) represents the set {t|t>=t1, t<t2, and t1<t2, t, t1, t2 ∈ date time}. The instant t1 can be represented by [t1,NA). Two valid times [t1, t2) and [t2, t3) can be merged into one valid time [t1, t3).
・Valid time = [date time, date time∪{∞. NA})
- Txn time = [date time, date time∪{∞. NA})
The KIDS system may be a 7-tuple (Actor, Agent, Entity, CARE, Metadata, Environment, Profile). An actor is a set of human actors, and an agent is a set of computer programs or hardware elements that act on behalf of human actors. An entity is a collection of entities that are observed, diagnosed and treated.
・CARE = (data, knowledge)
・Data = (fact, recognition result, hypothesis, instruction)
・Knowledge = (classification, evaluation, solution, implementation)
• Data is represented in two basic data structures FSD and features.
・Fact ⊆ Guard x Behavior x Entity x Big Vector x Valid Time ・Recognition Result ⊆ Guard x Behavior x Entity x Vector x Valid Time x FoM
・Hypothesis ⊆ Guard x Behavior x Entity x Vector x Valid Time x FoM
・Command ⊆ Guard x Action x Entity x Vector x Valid Time x FoM
Situation=Fact∪Perceived Result∪Hypothesis∪Directive A situation may be a summary of facts, cognitive results, hypotheses and directives. A Context Instance is associated with a particular Behavior Instance within a CARE Loop Instance and represents the input or output of the KFun function associated with the Behavior Instance. A situation instance may be associated with an entity and contains a vector of features or FSDs that may be part of the state of the associated entity. That is, a context entity can be associated with each FSD or feature entity within the context by a valid JPQL path expression. A FoM is a quantitative or qualitative figure of merit representing confidence levels, confidence intervals, probabilities, scores, root mean square errors, payoffs/costs, and the like.

・Ｋｆｕｎは、分類、評価、解決、実施および症状解決の概括である。
・メタデータ＝（ＣＡＲＥループタイプ、行動タイプ、ＦＳＤタイプ、特徴タイプ、Ｋｆｕｎ定義）。
・ＣＡＲＥループタイプ⊆名前
・行動タイプ⊆名前
・ＦＳＤタイプ⊆名前×実体タイプ×暗号化×言語
・特徴タイプ⊆名前×実体タイプ×許容値
・Ｋｆｕｎ定義＝（事前条件、事後条件）
・事前条件⊆フィルタ定義^ｎ×Ｋｆｕｎ
・事後条件⊆Ｋｆｕｎ×フィルタ定義^ｎ
・フィルタ定義⊆（ＦＳＤタイプ∪特徴タイプ）×フィルタ×受任者
事前条件メタデータおよび事後条件メタデータは、Ｋｆｕｎ関数間の影響関係を捕捉することによって、（関連する実体セットの）ＦＳＤおよび特徴セットが同時に有効になり、Ｋｆｕｎ関数を呼び出すために必要な状況を満たす時間を検出する。フィルタは、ＪＰＱＬ経路式（path expression）で定義された述語である。必須物は、Ｋｆｕｎ関数を呼
び出すために、入力または出力状況の一部でなければならない対応するＦＳＤタイプまたは特徴タイプを指定するブール演算式（Boolean expression）である。

• Kfun is an overview of classification, assessment, resolution, implementation and symptom resolution.
• Metadata = (CARE loop type, action type, FSD type, feature type, Kfun definition).
・CARE loop type ⊆ name ・Action type ⊆ name ・FSD type ⊆ name x entity type x encryption x language ・Feature type ⊆ name x entity type x allowable value ・Kfun definition = (precondition, postcondition)
・Precondition ⊆ filter definition ⁿ × Kfun
・Post-condition ⊆ Kfun × filter definition ⁿ
Filter definition ⊆ (FSD type ∪ feature type) x filter x mandate The pre-condition and post-condition metadata can be defined by capturing the influence relationship between the Kfun functions, the FSD and the feature set (of the associated entity set). are valid at the same time and satisfy the conditions necessary to call the Kfun function. A filter is a predicate defined in a JPQL path expression. Required is a Boolean expression specifying the corresponding FSD type or feature type that must be part of the input or output context in order to invoke the Kfun function.

The environment is a 5-tuple (CARE loop, classify, evaluate, resolve, enforce).
・CARE loop = CARE loop type x entity x actor x counter x (classification x evaluation x solution x implementation) ⁿ
A CARE loop instance is a closure of a series of actions, with each action instance representing an environment for evaluating the filters defined by the CARE definition. The counter is a loop counter in 0-n that is part of the state of the CARE loop instance.
・Classification ⊆ Behavior type x Fact x (Classification) ⁿ x Cognitive result x Actor x Txn time x Valid time ・Evaluation ⊆ Behavior type x Cognitive result x (Evaluation) ⁿ x Hypothesis x Actor x Txn time x Valid time/Solution ⊆ Action type x Hypothesis x (Solution) x Command x Actor x T x n time x Valid time/Implementation ⊆ Action type x Command x (Implementation) ⁿ x Fact x Actor x T x n time x Valid time Classification, evaluation, resolution, or An implementation instance can represent an execution environment for each of the classification, evaluation, resolution, or enforcement functions.
Action = Classification ∪ Evaluation ∪ Solution ∪ Action Action = Action Type x Situation x (KFun) ⁿ x Situation x Actor x Txn Time x Effective Time An action may be a summary of classification, evaluation, resolution and implementation. . Many behavior instances (each with a pair of input/output situation instances) can be associated with the same KFun function. A guard is a query composed of a set of filters specified in JPQL path expressions and required Boolean expressions that are evaluated in the context of a CARE loop instance or behavior instance.
• A profile is a triple of (actor profile, knowledge profile, behavioral agent, personalization).
・Actor Profile ⊆ Actor → Entity x Features x Effective Time x FoM
・Knowledge profile ⊆ Kfun → entity x feature x effective time x FoM
・Action agent ⊆ {f|f: action → actor} × effective time ・Individualization: Kfun × actor → Kfun
• Individualization can be interpreted in terms of Curry operators.
・Personalization (Kfun, Actor) ≡ Curry (Kfun) (Actor Profile (Actor))
KIDS Execution Model This section describes one or more embodiments of the KIDS execution model. A CARE loop instance may be a closure of a set of actions (classification, evaluation, resolution and enforcement). A CARE loop instance can provide a historical and intentional environment consisting of past actions, current or ongoing actions, and possible future actions. KIDS can maintain a loop counter for each CARE loop instance. A behavior instance may be considered a current behavior instance if it executes under the current loop counter. The current action instance is assumed to be executed when the input context of the action instance is substantially changed. A loop counter is incremented when all current solving action instances under the current loop counter have been executed.

A CARE loop instance can have an instance type and an instance owner. Instance types group similar CARE loop instances. Instance types can be used to customize or constrain the behavior instances that run within a CARE loop instance. When a CARE loop type is specified for the first time, an actor (either the actor who instantiated the first instance of that type or another actor specified by this actor) is associated with that type as the owner. Each action instance of a CARE loop instance has an agent eligible to perform the action instance. If a behavior instance has no delegate, the owner of the CARE loop instance becomes the behavior instance's delegate. Also, if there is no explicitly named owner for the CARE loop instance, the type owner defaults to the instance owner. Instance owners or delegates of behavior instances can be computed from the behavior delegates by a specified function. Such a function is defined by a path expression evaluated on the environment of a CARE Loop instance or an action instance within a CARE Loop instance.

The owner of a CARE loop instance type can constrain the behavior of all instances of a certain kind. The owner of a CARE loop instance can also further customize the instance's behavior within the constraints specified by the type owner. CA
The owner of the RE Loop instance can define new behavior instances for the CARE Loop instance during execution by creating an initial behavior instance and any subsequent behavior instances. A CARE Loop instance or type owner may also create CARE definition metadata by creating a new FSD type or feature type before creating a FSD or feature for a situation instance of an action instance. Behavior instances can be implemented by knowledge functions (machines such as SVM, MSET, BBN, etc.) defined and encoded by CARE-defined metadata. Some examples of CARE definitions are shown in FIGS. 11A-11E.

Using an index (e.g., CARE loop[i].classification, CARE loop[i].evaluation, CARE loop[i].solution and CARE loop[i].implementation index i (i=0...n)) , a behavior instance can be uniquely identified from a CARE loop instance. The state of a CARE Loop instance is the collection of FSDs and Features in the Circumstance Instances associated with the Behavior Instances in the CARE Loop Instance, i.e. the collection of FSDs and Features available by path expressions, e.g., the CARE Loop[2]. Classification. Cognitive results. Feature [average memory usage]. Contains the entity. Many behavior instances can be associated with a Kfun function and the Kfun function's CARE definition metadata. KIDS can select the current action instance to be executed under the current loop counter. Execution of the current action instance is controlled using the guards assigned to each action instance. A guard contains a set of filter predicates specified by a path expression and a required boolean expression. A path expression, eg, CARE loop[1]. Solution. instructions. Feature [Allocate more memory]. value or cognitive outcome. Feature [rapid increase in memory usage]. Values are evaluated in the environment of a CARE Loop instance or an Behavior instance within a CARE Loop instance. Once the behavior instance is up-to-date, KIDS builds the SQL query statement with the corresponding guards. The result of such a query is a situational (fact, cognitive result, hypothesis or directive) instance. You can register a query whenever you detect a change in an object. When updating or inserting FSDs or features, KIDS executes a flashback query for each registered query statement with the last transaction time recorded by the Txn time of the corresponding behavior instance. KIDS also executes queries at the current transaction time. If the context instance changes substantially between two transactions, KIDS can use the updated context to launch the behavior instance. This is a call to the Kfun function associated with the behavior instance. After executing the Kfun function call and the I/O situation instance, KIDS saves the new transaction time (Txn time) to the action instance. KIDS defers calling the Kfun function until all required FSDs and features are part of the input context. Therefore, KIDS coordinates the execution of the CARE Loop action instance and increments the CARE Loop's counter.

A context definition can include a list of filter definitions that specify the FSD types and feature types of the FSDs or features in the context. Also, each filter definition is YAK-Dom0.12-OVM. 222 = Features. entity. Oracle VM and Features. It also specifies a filter predicate such as name=ESS process explosion. Selects registered query statements that can be affected by new or updated FSDs or features within the current transaction by registering the expression in the Oracle database expression filter table using the filter predicate specified by the filter definition can do. KIDS detects changes in context instances by executing flashback queries only on the affected query statements. By using path expressions in filters, FSDs and features of related entity sets can be aggregated into context instances. Path expressions must be valid for the specified entity model.

KIDS can select and execute one action according to the priority of classification<evaluation<solution<implementation if the current loop counter detects a change to more than one current action input context instance. The current action can be executed repeatedly as the input context instance of the current action changes until the execution of one or more current resolved action instances reaches a loop counter, activating a series of new action instances. A new version of the Kfun function can also be used to reset the loop counter to a lower number in order to re-evaluate the situation instance and re-execute the action instance.

Thus, the KIDS engine can be implemented with mature database technology for large-scale state management, rich data models and data types, expression filters, flashback queries and registration queries.

KIDS - Cloud Operations Experience The KIDS engine can orchestrate the interactions of the various inference engines such as BBN, RETE, MSET, SVN, etc. mentioned above. The KIDS database can implement the KIDS loop of provenance data by annotating the FPHD and CARE data within the fact data, as shown in FIG. The KIDS model can integrate big data systems for log analysis systems and real-time enterprise management systems during IT operations. The two systems represent big data and CEP disconnected and surrounded by islands of automation. The KIDS model can enable faster OODA loops in real-time by fusing information from dynamic entity models, log analysis and real-time monitoring.

The KIDS model enables information fusion of various special kinds of cognitive outcomes, such as observations, objectives, predictions and simulation results, inferred by different taxonomic knowledge, and enables information fusion between related entities. . In the exemplary scenario of information fusion shown in Figure 13, the set of related entities converging information includes an Oracle VM, a JAVA VM, a Dom0 host, other Oracle VMs and Java VMs located on the Dom0 host. . A dynamic entity model is managed by a temporal database.

In the exemplary scenario illustrated in FIGS. 11A-11C, the "memory usage spike" and "enterprise scheduler service process spike" features may be part of the classification of unusual trends in OS memory and OS process measurements. . The "out of memory prediction" features in Figures 11A and 11C are part of the cognitive results produced by the time series filter. Additional features such as "can compress heaps of JVMs in other Oracle VMs" and "can reclaim memory from other Oracle VMs" are the average load of all Java VMs located in all Oracle VMs in Dom0. and some of the cognitive outcomes predicted by rollup operations on data cubes containing periodic trend data. The KIDS entity model includes "list of Oracle VMs running in Dom0", "list of Java VMs running in each Oracle VM", and "can compress heaps of JVMs in other Oracle VMs" and " Situational awareness can be based on perception results about "memory can be reused from other Oracle VMs." All of these cognitive outcomes must agree on a common valid time interval within the context instance.

The KIDS model can capture the interaction structure of knowledge functions implemented in various inference engines. The CARE loop shown in FIG. 14 is effectively a series of networks, where the interactions are (action instances and guard instances represent transitions, situation instances represent locations, and FSDs and features represent tokens). Similar to Petri-Net. Behavioral instances of the evaluation function are implemented by the Bayesian Belief Network shown in FIG. By using interaction models, KIDS can coordinate the execution of models involving various inference engines.

The evaluation knowledge "Diagnosis of Oracle VM memory" indicated by the BBN in FIG. It is possible to derive the hypothesis that there is A similar network includes the solution knowledge 'Resolve Oracle VM memory' which combines the hypotheses of reaching Dom0's directive with 'Allocate memory from Dom0 to OVM2'. Evaluative knowledge can arrive at a hypothesis that "memory needs to be reclaimed from OVM" after processing an ESS job. The solution knowledge presented by the influence diagram leads to Dom0's directive to "reclaim memory from Oracle VM". The directive "allocate memory from Dom0 to an Oracle VM" is performed by an enforcement function that triggers full garbage collection (GC) and heap compaction of Java VMs running in other Oracle VMs located in the same Dom0. be done. After the Java VM's heap compaction, the enforcement function can instruct Dom0 to expand the memory balloon (part of the startup mechanism) of other Oracle VMs to reclaim the memory in the balloon. can. This allows Dom0 to allocate elastic memory to Oracle VM to support processes spawned by ESS. Since the ESS process is a scheduled behavior that exhibits periodicity, the reactive and predictive response of KIDS by the enforcement function becomes part of the periodic behavior.

KIDS Experience - Software and Hardware Products The following describes a summary of the KIDS design knowledge extraction and automation experience. This summary shows how to map the troubleshooting behavior of modular product support to the CARE loop, balancing the individual productivity of the personnel involved with an accurate combination of knowledge and provenance. Accurate coupling of knowledge and sources will lead to standardization of economic terminology and processes, ultimately leading to knowledge automation and rapid application evolution. This method can greatly contribute to fostering cooperative and productive communities of practice.

In the following scenarios, either an automatic incident or a manual action by the customer instantiates a new CARE loop instance starting with loop index i=0. The process consists of four stages: problem identification, problem verification, cause identification and solution provision.

・Problem identification stage (II-i)
Directives (II-i) are action plans that elicit data or collect telemetry data about problems from customer representatives and generate facts (II-i) in response to problems or collection of metric values.

By classifying facts (II-i), we obtain cognitive outcomes (II), known as observations.

By assessing the cognitive outcomes (II-i), we obtain hypotheses (II-i) known as potential problems.

Solving hypotheses (II-i) yields directives (IV-i+1), known as action plans for initial data collection.

・Problem verification loop (IV-i)
Executing Directives (IV-i) produces Facts (IV-i) which are a series of log and trace files.

By analyzing (classifying) the facts (IV-i), we obtain cognitive results (IV-i), which are a series of observations.

Evaluating the cognitive outcomes (IV-i) yields hypotheses (IV-i) that are either tested or untested problems.

If the problem is verified, proceed to cause determination and determine the cause (failure condition) by creating a command (CD-i+1). Otherwise, return to problem identification by creating directive (II-i+1).

・Cause determination loop (CD-i)
Executing Directives (CD-i) produces Facts (CD-i) in the form of additional log files, trace files and configuration data.

An additional observation, the cognitive outcome (CD-1), is obtained by analyzing the facts (CD-i).

By evaluating the cognitive outcomes (CD-i), hypotheses (CD-i) known as fault conditions are generated.

If a hypothesis (CD-i) is found with high confidence, a directive (SP-i+1) (solution action plan) is created. If not, further investigate the potential cause by generating a directive (CD-i+1) to collect more data.

・Solution planning loop (SP-i)
A directive (SP-i) is a series of actions that correct the problem caused by the hypothesized cause and collect additional data to validate the solution. These actions, when performed, produce facts (SP-i).

By analyzing the facts (SP-i), we obtain the cognitive results (SP-i), which are the observed results of the solution.

By evaluating the cognitive outcomes (SP-i), generate hypotheses (SP-i) that test whether the solution can solve the problem.

If the hypothesis (SP-i) verifies the solution, provide an instruction (NO-OP-END) to terminate the CARE loop. If not, go back to cause determination by making a directive (CD-i+1) or try a new solution by making a directive (SP-i+1).

Any of the actions within the particular CARE loop described above may be performed manually, partially or fully automatically, depending on the maturity of the process and the explicit knowledge of the support team owning the loop as well as the complexity of the domain. good. Utilize the KIDS analysis service to qualify manual actions that are ready for partial or full automation. Such activities must reach sufficient maturity and have an economically viable ROI for automation. Data collection automation is achieved through a diagnostic framework built into the product, enabling first-failure data capture of critical issues and on-demand instrumentation for deeper insight. To achieve rapid deployment, automation elements are specified in a declarative manner and detection is fully automated, ensuring rapid turnaround of automation. The KIDS plugin framework can be utilized to include an XML-based diagnostic data analysis framework that supports domain-specific services and knowledge, eg, a domain-specific ontology repository, an auto-discovery framework for analysis modules. Automation of data analysis is achieved by transforming collected data into an XML canonical representation and specifying data analysis rules within XPATH rules. For complex patterns that cannot be easily specified in XPATH, libraries of reusable data analysis patterns can be developed in Java. To automate diagnosis, manual modeling is the only viable method for automation. The KIDS plugin framework can also be utilized to include modeling, auto-detection and automation frameworks based on Bayesian belief networks. In fact, the KIDS CARE loop can also be used to build and test these models. A Bayesian Belief Network (BBN) can be used to model diagnosis. BBN provided an ideal paradigm due to the scattered nature of the problem space that hinders machine learning. Building a BBN helps explain diagnostic results and handle incomplete and abnormal input data.

KIDS in the form of guided tagging, hashtag extensions and inline action planning specifications can also be used for personal productivity services to support personal productivity of manual actions. Specifically, guided tagging can be utilized to allow standardization of terminology. Hashtag extensions can be used to define personal terms. With KIDS, in-line action plan specifications can be considered for capturing and sharing action plans, and automation of self-service personal data analysis can be considered for capturing and sharing data analysis rule sets. can do. These various examples can provide personal empowerment on the one hand, and enable community sharing and collaboration on the other. For example, tagging allows personal knowledge to be organized and searched. Guided tagging enables community focus on a standardized set of tags. In addition, the Hashtag Extended User Experience Service aims to help the community to share these definitions by helping individuals specify text phrasebooks or term definitions once and then reuse them multiple times. and Finally, inline action plans allow the creation of reusable action plans at the individual level, allowing action plan actors to leverage the action plan as a checklist. Action plans can be shared and exchanged at the community level. All such user experience services support personal delegation and help the action community focus on best practices and common language.

The KIDS Experience - Patient Care The purpose of the Patient Care KIDS project is classification and provenance. To support provenance, all patient records are managed in a transaction-time database. Manage classification using registered queries and models. To reduce false alarms, physicians can adjust the classification down to the level of individual patients. Vital signs were classified as normal, monitored, severe and critical. Registration queries can be expressed to use these classifications. As a result, the doctor can define a rule in his own language, for example, to notify me if at least one vital sign of patient X becomes critical for more than 2 minutes. Such rules are independent of classification details, so a small number is sufficient and stable.

In addition, non-hypothetical driven models can be used to predict the likelihood that the heart will stop after a few hours. A surprising result is that vital signs, especially those for which the most recent data are available, are not important for 'long term' prediction. KIDS technology can present an abstraction of such events or bad end-users. You can use the term incident object. Ideas can evolve into situational (state) models. Some embodiments are simply concerned with managing facts, classifications and cognitive outcomes. Other elements of the CARE loop can be added after the project is complete.

KIDS Database Specifications In some embodiments, the database used to implement the KIDS model must meet certain requirements or specifications. In some cases, the KIDS database may provide a declarative query language to allow users to query CARE loop instances. SQL can be used to provide a declarative language model. However, SQL can only query atomic data. To query KIDS, we need to extend SQL to query a set of CARE loop instances. SQL can query links between data using primary/foreign keys, but is limited to querying CARE loop instances and action instances that involve recursive graph traversal. The closest support for declarative constructs of graph traversal in SQL is recursive queries. However, the recursive query provides the final results in tabular form rather than the results obtained from the original recursive structure. Thus, the KIDS query language allows users to query and traverse the CARE loop paths to see how behavior instances depend on situation instances and how Kfun knowledge functions are applied. .

The KIDS database can also provide a declarative manipulation language for manipulating KIDS elements. A CARE loop can keep track of what happened. However, if a user changes knowledge in some kind of way, eg a "what if query", DML can be used to assert what happened or what will happen. Thus, a user can gain new insights from historical data by evaluating it with new knowledge. This is similar to time traversal into the past. Additionally, the user can assert future data by forking multiple CARE loops with different versions of knowledge. This is similar to time traversal into the past.

Specification of KIDS Tools The KIDS toolset can assist users in building KIDS applications as well as various controls over the underlying infrastructure: evolution of knowledge based on user feedback and re-characterization of knowledge with new data. You can also specify a date.

KIDS Application Server The KIDS application server can support the execution of KIDS applications using KIDS data, knowledge and process models stored in databases. The KIDS application server can communicate information representing unambiguous provenance and delegate state management and event handling to the database.

KIDS Optimization The KIDS database may be designed to support the ACID properties of transactions. Fact collection requires full or reduced durability, so we need a database service that supports data models and types as well as security, compression, compression, time travel and provenance, etc. all. Durability must be controlled by user requirements, eg, all >x% of the data or accuracy high enough to answer questions of provenance. The service must also support high performance classification. By relaxing the ACID requirements, resource consumption can be significantly reduced. For this purpose, a special database can be considered, but it should have the functionality to meet all requirements. Some approaches therefore involve optimizing existing databases and leveraging hardware acceleration in response to evolving patterns.

KIDS Support for Distributed Processing In some embodiments, KIDS can operate in a distributed environment to leverage the underlying infrastructure.

Integrating Social Networking and Personalization In some embodiments, social networking is an integral part of KIDS. Personalization can be concerned with specific areas and individualize knowledge based on group or individual preferences. For example, the patient care use case illustrates the importance of personalization.

KIDS Migration With regard to migration support, existing applications can continue to work in order to maintain existing functionality, but based on the KIDS model, "shadow" applications can also be created. In some cases, "shadow" applications monitor data in existing systems by crawling. However, along with some existing technology, new functionality can also be implemented in KIDS.

Claims (13)

A method for a computer to perform data transformation processing in a multi-time database, comprising:
a computer system invoking a first data transformation process on one or more data objects in the multi-temporal database;
In response to invoking the first data conversion process,
(a) the computer system determines a first time associated with the first data conversion process;
(b) the computer system performs a first execution of a first filter query configured to calculate results based on a first set of multi-temporal data items stored in the multi-temporal database;
(c) the computer system configured to: (i) data corresponding to the first set of multi-temporal data items; (ii) a first result of the execution of the first filter query ; (iii) the first data; storing the first time associated with the conversion process;
the computer system receiving multiple data updates of data stored in a multi-time database;
the computer system determining an expiration time for each of the received plurality of data updates;
updating one or more multi-temporal data items in the multi-temporal database based on the received data updates, wherein updating the multi-temporal data items comprises: storing the determined validity time and a separate transaction time for each of the updates;
responsive to receiving the plurality of data updates, determining whether the plurality of data updates changed any of the first set of multi-temporal data items in the multi-temporal database;
in response to determining that the plurality of data updates changed one or more multi-temporal data items in the first set of multi-temporal data items in the multi-temporal database;
(a) said computer system performs a second execution of said first filter query to compute a second result, said second execution of said first filter query corresponding to a current time and said multiple time period; using multi-temporal data including the modified one or more multi-temporal data items of the first set of multi-temporal data items in a database;
(b) a second result of said second execution of said first filter query using multi-temporal data corresponding to said current time; and said multi-temporal data corresponding to said first time associated with said first data transformation process ; determining a difference between the first result of the first execution of the first filter query using time data;
(c) comparing the difference to a predetermined threshold, the predetermined threshold determined based at least in part on changes in values of one or more objects within the multi-temporal data, the predetermined threshold comprising: used to determine a second invocation of the first data transformation process;
(d) performing the second invocation of the first data transformation process on the one or more data objects in the multi-temporal database in response to determining that the difference is greater than the predetermined threshold; ,
After invoking the first data transformation process, receiving a request to determine a set of data updates that trigger the first data transformation process;
retrieving a plurality of multi-temporal data items, including the first set of multi-temporal data items, from the computer system in response to the request;
determining a multi-temporal data item among the plurality of multi-temporal data items that triggered the first data transformation process, wherein the determination includes the valid time and the validity time of the retrieved plurality of spatiotemporal data items. sending a response to the received request including data identifying the multi-time data item determined to have caused the first data transformation process based on the separate transaction time;
Determining the multi-temporal data item among the plurality of multi-temporal data items that caused the second invocation of the first data transformation process comprises:
A first updated data item in the plurality of multi-time data items has a valid time before the second call of the first data transformation process and a transaction after the second call of the first data transformation process. determining to have time;
Based on the determination that the transaction time of the first updated data item is after the second invocation of the first data transformation process, the first updated data item is processed by the second invocation of the first data transformation process. and determining not included in the set of data updates that caused the call . 2. The method of claim 1, wherein the first data transformation process is performed by a data transformation loop application running within a compute node of a HADOOP data processing cluster. The first data transformation process includes machine learning process, raw data processing classification, support vector machine, naive Bayes classifier, neural network, clustering, association rule, decision tree, univariate periodic linear trend, multivariate state estimation technology, Cognitive Computing, Bayesian Belief Networks, Least Squares Optimization or Regression of Solutions to Inverse Problems, Influence Diagrams, Dempster-Shafer Theory, Decision Trees, Remaining Valid Life Prognosis, Scripts, Planning, Scheduling, BPEL Workflows, and BPMN Business 3. The method of claim 2, comprising one or more of the processes. storing a second data object corresponding to the result of the second invocation of the first data transformation process;
determining a difference between the second data object and another data object of the same type as the second data object, wherein the another data object is a first invocation of the first data transformation process; generated by
Further comprising invoking a second data transformation process for the second data object based on determining that the difference between the second data object and the another data object is greater than a second predetermined threshold. , the method according to any one of claims 1 to 3. said first data transformation process and said second data transformation process being part of a continuous data transformation loop application;
The method includes
receiving one or more additional updates to the multi-temporal data stored on the computer system;
updating the one or more multi-temporal data items based on the received additional updates;
performing a third execution of the first filter query using the additional updates of the multi-temporal data;
performing a fourth execution of the first filter query using multi-temporal data corresponding to past execution times of the second data transformation process;
determining a difference between results of the third execution of the first filter query and results of the fourth execution of the first filter query ;
comparing the difference to a predetermined threshold;
5. The method of claim 4, further comprising reinvoking the data conversion process if determining that the difference is greater than the predetermined threshold. performing the first execution and the second execution of the first filter query ; and comparing the difference between the first execution and the second execution of the first filter query to the predetermined threshold. is executed outside and asynchronously with the first transaction that updates the one or more multi-time data items;
6. The method of claim 5, wherein said first and said second invocations of said first data transformation process are performed outside said first transaction and asynchronously with said first transaction. The method of any one of claims 1-6, wherein determining the validity time of the received data update comprises receiving the validity time of each of the plurality of received data updates. Determining the validity time of the received data update includes dynamically determining the validity time of each of the plurality of received data updates using an orchestration engine of the computer system. Item 8. The method according to any one of items 1 to 7. Determining the multi-temporal data item among the plurality of multi-temporal data items that caused the second invocation of the first data transformation process comprises:
determining that a first updated data item in the plurality of multi-time data items has a validity time later than the second invocation of the first data transformation process;
Based on the determination that the validity time of the first updated data item is after the second invocation of the first data transformation process, the first updated data item is processed by the second call of the first data transformation process. and determining not included in the set of data updates that caused the call. The first filter query determines that updates to the received data reliably change the results of the first filter query , thereby reducing at least some of the updated multi-time data items to multi-time data items. A method according to any preceding claim, further comprising determining that it is configured to calculate a result based on said first set of multi-temporal data items including temporal data items. A first filter query determines at least some of the updated multi-time data items by determining that updates to the received data potentially, but not reliably, change the results of the first filter query . 11. The method of any one of claims 1 to 10 , further comprising determining to be configured to calculate a result based on the first set of multi-temporal data items including a multi-temporal data item of the method of. A program for causing a computer to execute the method according to any one of claims 1 to 11 . a memory for storing the program according to claim 12 ;
and a processor that executes the program.

Images