US20170220647A1 - Pluggable architecture for embedding analytics in clustered in-memory databases - Google Patents

Abstract

Disclosed are pluggable, distributed computing-system architectures allowing for embedding analytics to be added or removed from nodes of a system hosting an in-memory database. The disclosed system includes an API that may be used to create customized, application specific analytics modules. The newly created analytics modules may be easily plugged into the in-memory database. Each user query submitted to the in-memory database may specify different analytics be applied with differing parameters. All analytics modules operate on the in-memory image of the data, inside the in-memory database platform. All the analytics modules, may be capable of performing on-the-fly analytics, which may allow a dynamic and comprehensive processing of search results.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This patent application is a continuation of U.S. patent application Ser. No. 14/558,055, filed on Dec. 2, 2014 and titled “Pluggable Architecture For Embedding Analytics In Clustered In-Memory Databases,” which claims a benefit of U.S. Patent Application 61/910,864, filed Dec. 2, 2013 and titled “Pluggable Architecture For Embedding Analytics In Clustered In-Memory Databases,” each of which is hereby fully incorporated by reference herein for all purposes.
• This application is related to U.S. patent application Ser. No. 14/557,794, filed on Dec. 2, 2014 and titled “Method for Disambiguating Features in Unstructured Text”; U.S. patent application Ser. No. 14/558,300, filed on filed Dec. 2, 2014 and titled “Event Detection Through Text Analysis Using Trained Event Template Models”; U.S. patent application Ser. No. 14/557,807, filed on Dec. 2, 2014 and titled “Method for Facet Searching and Search Suggestions”; U.S. patent application Ser. No. 14/558,254, filed on Dec. 2, 2014 and titled “Design and Implementation of Clustered In-Memory Database”; U.S. patent application Ser. No. 14/557,827,filed on Dec. 2, 2014 and titled “Real-Time Distributed In Memory Search Architecture”; U.S. patent application Ser. No. 14/557,951, filed on Dec. 2, 2014 and titled “Fault Tolerant Architecture for Distributed Computing Systems”; U.S. patent application Ser. No. 14/558,009, filed on Dec. 2, 2014 and titled “Installation And Fault Handling In A Distributed System Utilizing Supervisor And Dependency Manager Nodes”; U.S. patent application Ser. No. 14/558,101, filed on Dec. 2, 2014 and titled “Non-Exclusionary Search Within In-Memory Databases”; and U.S. patent application Ser. No. 14/557,900, filed on Dec. 2, 2014 and titled “Data Record Compression With Progressive And/Or Selective Decomposition,” each of which is hereby fully incorporated by reference herein for all purposes.
FIELD OF THE DISCLOSURE
• The present disclosure relates in general to in-memory databases, and more specifically to pluggable in-memory analytic modules.
BACKGROUND
• Traditional databases allow users to find pieces of information that are relevant to an entity, and while millions or billions of records may describe that entity the records are generally not linked together without formal foreign key relationships. Large collections of records exist with informal, unreliable or non-existent foreign key relationships. This makes it extremely challenging to bring together all of the records relevant to a single entity.
• The traditional approach is to pre-link all of the data within such a collection such that finding one record will lead you directly to the collection of records. This traditional approach has two distinct problems.
• First, pre-linking a large collection of records is an intensive process taking considerable time. This imposes a significant lag on the time it can take to integrate new records into the linked collection adversely effecting the timeliness of the data in that collection.
• Second, pre-linking the data by definition is restricted to the model used to perform that pre-linking, drastically reducing the ability of a user of the system to vary the parameters of how strongly or weakly records are linked. Pre-linking is also limited to the data available at the time of the pre-linking step.
• Another approach is to avoid any pre-linking of the data, but rather to link in real time, or “link-on-the-fly,” in response to a user query. This approach allows new records to immediately participate in the collection avoiding any issues of timeliness. It also allows a wide variety of models to be applied to perform the linking using varying algorithms and parameters in the linking process. The traditional disadvantage to this approach has been the ability to run that data intensive query and achieve acceptable interactive response times. This can be overcome be placing the collection in an in-memory database with embedded analytics.
• There is therefore a need in the art for flexible database architecture capable of supporting multiple customized analytics modules, designed to process data in real time without having to change how the data is managed, prepared and stored within the system.
SUMMARY
• Disclosed herein is a distributed-computing system architecture hosting an in-memory database, which may include any suitable combination of modules and clusters, including one or more of a system interface, a search manager, an analytics agent, a search conductor, a partitioner, a collection, a supervisor, a dependency manager, or any suitable combination. Embodiments of the system may have a pluggable architecture of nodes and software modules, which may facilitate installing, embedding, or otherwise including additional components (e.g., nodes, modules, database instances) on-the-fly (i.e., without interrupting or otherwise disrupting status quo operation of the system). Embodiments of the system may accept later-developed or external, third-party custom analytics modules for inclusion to the in-memory database. Database queries may specify which analytics modules and parameters are to be applied on-the-fly to intermediate query results, without having to first retrieve data out of the database. Systems and methods described herein enable custom tailor analytics modules to be developed independently from the in-memory database, and can also be deployed within the system hosting the database to receive the performance benefits of executing analytics using the in-memory database. Exposed and accessible APIs may be used for communicating data with independently created analytics modules, which, because of the APIs, may be seamlessly plugged-into or otherwise integrated with the in-memory database. Validation of data may be available to determine whether the new modules conform to expectations of the API.
• In one embodiment, an in-memory database system comprises one or more storage nodes comprising a non-transitory machine-readable storage media storing one or more records of a database, wherein the storage media of each respective storage node is a main memory of the respective storage node; an analytics agent nodes comprising a processor executing an analytics module using a set of query results as input parameters responsive to receiving a request for analytics indicating the analytics module, wherein the set of query results contains binary data representing one or more records retrieved from the one or more storage nodes storing the one or more records; and an analytics module datastore comprising non-transitory machine-readable storage media storing one or more analytics modules, and a processor configured to transmit a new analytics module to one or more analytics agent nodes.
• Numerous other aspects, features and benefits of the present disclosure may be made apparent from the following detailed description taken together with the drawing figures.
BRIEF DESCRIPTION OF THE DRAWINGS
• The present disclosure can be better understood by referring to the following figures. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the disclosure. In the figures, reference numerals designate corresponding parts throughout the different views.
• FIG. 1 shows an in-memory database architecture, according to an embodiment.
• FIG. 2 is a flowchart of a method for adding new modules to an in-memory database, according to an embodiment.
DEFINITIONS
• As used here, the following terms may have the following definitions:
• “Node” refers to a computer hardware configuration suitable for running one or more modules.
• “Cluster” refers to a set of one or more nodes.
• “Module” refers to a computer software component suitable for carrying out one or more defined tasks. Modules used within the disclosed system may include any software implementation of analytical methods for processing any kind of data.
• “Collection” refers to a discrete set of records.
• “Record” refers to one or more pieces of information that may be handled as a unit.
• “Field” refers to one data element within a record.
• “Partition” refers to an arbitrarily delimited portion of records of a collection.
• “Schema” refers to data describing one or more characteristics one or more records.
• “Search Manager” refers to a module configured to at least receive one or more queries and return one or more search results.
• “Analytics Module” refers to a module configured to at least receive one or more records, process said one or more records using one or more analytics methods, and return the resulting one or more processed records.
• “Analytical Method” refers to any operation that may be applied to an aggregate of search results.
• “Analytics Agent” refers to nodes storing and executing one or more analytics modules.
• “Analytics Parameters” refers to parameters that describe the operation that an analytic module may have to perform in order to get specific results.
• “Search Conductor” refers to a module configured to at least run one or more queries on a partition and return the search results to one or more search managers.
• “Node Manager” refers to a module configured to at least perform one or more commands on a node and communicate with one or more supervisors.
• “Supervisor” refers to a module configured to at least communicate with one or more components of a system and determine one or more statuses.
• “Heartbeat” refers to a signal communicating at least one or more statuses to one or more supervisors.
• “Partitioner” refers to a module configured to at least divide one or more collections into one or more partitions.
• “Dependency Manager” refers to a module configured to at least include one or more dependency trees associated with one or more modules, partitions, or suitable combinations, in a system; to at least receive a request for information relating to any one or more suitable portions of said one or more dependency trees; and to at least return one or more configurations derived from said portions.
• “Database” refers to any system including any combination of clusters and modules suitable for storing one or more collections and suitable to process one or more queries.
• “Query” refers to a request to retrieve information from one or more suitable partitions or databases.
• “Memory” refers to any hardware component suitable for storing information and retrieving said information at a sufficiently high speed.
• “Application Programming Interface,” or “API” allows different user-developed software modules to be compatible with the components (e.g., software modules, nodes) of the distributed computing system.
DETAILED DESCRIPTION
• The present disclosure is here described in detail with reference to embodiments illustrated in the drawings, which form a part here. Other embodiments may be used and/or other changes may be made without departing from the spirit or scope of the present disclosure. The illustrative embodiments described in the detailed description are not meant to be limiting of the subject matter presented here.
• Reference will now be made to the exemplary embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Alterations and further modifications of the inventive features illustrated here, and additional applications of the principles of the inventions as illustrated here, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention.
• An in-memory database is a database storing data in records controlled by a database management system (DBMS) configured to store data records in a device's main memory, as opposed to conventional databases and DBMS modules that store data in “disk” memory. Conventional disk storage requires processors (CPUs) to execute read and write commands to a device's hard disk, thus requiring CPUs to execute instructions to locate (i.e., seek) and retrieve the memory location for the data, before performing some type of operation with the data at that memory location. In-memory database systems access data that is placed into main memory, and then addressed accordingly, thereby mitigating the number of instructions performed by the CPUs and eliminating the seek time associated with CPUs seeking data on hard disk.
• In-memory databases may be implemented in a distributed computing architecture, which may be a computing system comprising one or more nodes configured to aggregate the nodes' respective resources (e.g., memory, disks, processors). As disclosed herein, embodiments of a computing system hosting an in-memory database may distribute and store data records of the database among one or more nodes. In some embodiments, these nodes are formed into “clusters” of nodes. In some embodiments, these clusters of nodes store portions, or “collections,” of database information.
• The present disclosure describes an in-memory database including one or more clusters and one or more modules, where suitable modules may include one or more of a search manager, an analytics agent, a node manager, a search conductor, a supervisor, a dependency manager, and/or a partitioner. The disclosed system architecture allows the implementation of customized pluggable in-memory analytics modules that may be dynamically embedded into one or more analytics agents or search conductors.
• In one or more embodiments nodes, modules, or suitable combinations in the system may be linked to one or more supervisors, where said nodes, modules, or suitable combinations may be configured to send heartbeats to said supervisors. Said supervisors may be linked to one or more dependency managers including one or more dependency trees for one or more modules, partitions, or suitable combinations thereof. Supervisors may additionally be linked to one or more other supervisors, where additional supervisors may be linked to other components in the system.
System ConfigurationSystem Architecture
• FIG. 1 showssystem architecture100 havingsystem interface102,first search manager110,nth search manager112,first analytics agent120,nth analytics agent122,first search conductor130,nth search conductor132,partition data140,partitioner150,first collection160,nth collection162,supervisor170, anddependency manager180.
• In one or more embodiments,system interface102 may feed one or more queries generated outsidesystem architecture100 to one ormore search managers110,112 in a first cluster including at least one node including afirst search manager110 and up to n nodes including annth search manager112. The one ormore search managers110,112 in said first cluster may be linked to one ormore analytics agents120,122 in a second cluster including at least afirst analytics agent120 and up tonth analytics agent122.
• Search managers110,112 in the first cluster may be linked to one ormore search conductors130,132 in a third cluster. The third cluster may include at least afirst search conductor130 and up to annth search conductor132. Each search node (i.e., node executingsearch manager110,112) may include any suitable number ofsearch conductors130,132.
• Search conductors130,132 in the third cluster may be linked to one or more database nodes storingpartition data140.Partition data140 may include one or more partitions (i.e., arbitrarily delimited portions of records partitioned from a discrete set of records) generated by a node executing one or more partitioners150, which may be a module configured to at least divide one or more collections into one or more partitions. Each of the partitions may correspond to at least afirst collection160 and up tonth collection162. Thecollections160,162 may additionally be described by one or more schemata, which may define the data in thecollections160,162. The one or more schemata may include information about the name of the fields in records of the partitions, whether said fields are indexed, what compression method was used, and what scoring algorithm is the default for the fields, amongst others. The schemata may be used bypartitioners150 when partitioning thefirst collection160 and up tonth collection162, and may be additionally be used by thefirst search manager110 and upnth search manager112 when executing one or more queries on the collections.
• One or more nodes may execute asupervisor170 software module that receives a heartbeat signal transmitted from other nodes of thesystem100. Asupervisor170 may be configured to receive data from nodes of thesystem100 that execute one ormore dependency manager180 software modules. Adependency manager180 node may store, update, and reference dependency trees associated with one or more modules, partitions, or suitable combinations thereof, which may indicate configuration dependencies for nodes, modules, and partitions, based on relative relationships. Asupervisor170 may additionally be linked to other nodes in thesystem100 executing one or moreother supervisors170. In some cases, links toadditional supervisors170 may cross between clusters of thesystem architecture100.
• Nodes executing ananalytics agent120,122 may execute one or more suitable analytics modules, which conform to a specified application programming interface (API) that facilitates interoperability and data transfer between the components of the system (e.g., software modules, nodes).Analytics agents120,122 may be configured to process aggregated query results returned fromsearch conductors130,132. For example, asearch manager110 may receive a search query and then generate search conductor queries, which thesearch manager110 issues to one ormore search conductors130,132. After thesearch conductors130,132 execute their respectively assigned search conductor queries, thesearch manager110 will receive a set of aggregated query results from the one ormore search conductors130,132. Thesearch manager110 may forward these search query results to ananalytics agent120 for further processing, if further processing is required by the parameters of the search query.
• In some implementations, after asearch manager110 determines the search query has requested for ananalytics agent120 to process one or more sets of aggregated results received from thesearch conductors130,132, thesearch manager110 may transmit a database schema file and/or one or more analytical parameters to theanalytics agents120,122. In some cases, the search query may request particular analytics algorithms to be performed, which thesearch manager110 may use to identify whichanalytics agent120 should receive aggregated search results. In some cases, one or more of the sets of aggregated results may be transmitted to theanalytics agents120,122 in the form of compressed records, which contain data compressed according to a compression algorithm. In some cases, data of the records may be compressed at the fields of the records; and in some cases, full records may be compressed.
• Nodes executinganalytics agents120,122 having various analytics modules. Non-limiting examples may include: disambiguation modules, linking modules, and link on-the-fly modules, among other suitable modules and algorithms. Suitable modules may include any software implementation of analytical methods for processing any kind of data. In some embodiments, particular analytics modules oranalytics agents120,122 may be accessible only to predetermined instances, clusters, partitions, or/or instantiated objects of an in-memory database.
Analytics Modules
• According to an embodiment, a plurality of analytics modules may be created that conform to an application programming interface (API) defined for pluggable analytics in an in-memory database. The disclosed system architecture may allow the addition of multiple customized analytics modules executed by analytics agents of the system, which may be added to the system architecture, without interrupting operation or services, which may support dynamic processing of constant streams of data.
• Newly created analytics modules may be plugged into the database using simple module set up processes and may enable the application in real time to apply one or more analytical methods to aggregated results lists, without having to change how the data is managed, prepared and stored. Separate APIs may be constructed to support models which score records against queries, typically a search conductor function, or to perform closure or other aggregate analytical function on a record set, typically an analytics agent task.
• FIG. 2 is a flowchart of a method for addinganalytics modules200 to a system hosting an in-memorydatabase having steps202,204,206,208,210,212,214,216 and218, according to an embodiment.
• Instep202, one or more suitable analytics modules may be created that conform to a suitable API for pluggable analytics in an in-memory database. The API may have required methods that the analytics module must implement to provide system interoperability. Analytics modules may be created to satisfy user specific needs.
• One or more analytics modules may be stored in a suitable module store. The module store is a non-transitory machine-readable storage medium that may be managed by a supervisor. Depending upon the embodiment, an entity, developer, user, component, module, external source, and/or other source responsible for building and/or managing analytics modules, may develop the analytics module using one or more suitable programming languages.
• According to some embodiments, an API may serve as a software-to-software interface that may include sets of source code programming instructions and standards for a computer to compile and/or implement, such as parameters or arguments for routines, data structures, object classes, and variables. The APIs may allow the system to accept data inputs from, and output results to, later-developed software modules, while remaining agnostic to ownership, capabilities, or other characteristics of the later-developed modules, as long as the data inputs conform to the data formats (i.e., expected arguments). Some software routines of the system APIs responsible for data input and output may be “exposed” to such newly-developed or later-developed, and often external, software modules. Exposed APIs may validate data acceptability when the exposed APIs receive, fetch, or otherwise “consume” data from the software modules. Authoring software source satisfying the expected arguments of the system APIs may allow developers and other users to develop a variety of software modules, such as analytics modules, to communicate (i.e., transmit, receive) data with the nodes and modules of the system, such as the analytics agents.
• Analytics agents may include one or more nodes within the system hosting the in-memory database, where each analytics agents' node may be able to store and execute one or more analytics modules. APIs may allow different user-developed analytics modules to be compatible with the various nodes and modules of the system and the in-memory database.
• In some embodiments, one or more modules may be external modules developed by third parties using any suitable programing language compatible with the APIs available. In such embodiments, these newly developed modules may be stored in the analytics module store.
• Instep204, the created module may be loaded into the in-memory database by adding the corresponding definition and any dependencies into the dependency manager, which may be accomplished using any suitable automated or manual processes capable of deploying, uploading, or otherwise storing, the appropriate files and instructions onto the dependency manager.
• Instep206, the supervisor determines, based on module settings in the dependency manager, if one or more modules are to be installed on one or more nodes. In some circumstances, module settings stored in the dependency manager will include whether a loaded analytic module is “enabled” or “disabled.” For example, if the settings indicate an analytics module is enabled, then the analytics module may be deployed to each respective node running the analytics agents performing that analytics module. A supervisor then sends installation preparation instructions to one or more node managers on said one or more nodes.
• Instep208, the node manager allocates the node's resources, based on module settings in the dependency manager, for running the one or more desired modules. In one or more embodiments, the allocation of resources may expire after a period of time should the supervisor discontinue the process. The module settings in the dependency manger will indicate how much memory, CPU and/or disk are required by the module.
• Instep210, the supervisor sends a request to a dependency manager for one or more configuration packages associated with the one or more modules to be installed on the node. As an example, automated or manual processes (e.g., system administrator) may have added a new module to the dependency manager, which may also define any dependencies corresponding to configuration packages, such as other software or metadata.
• Instep212, the supervisor may then send the configuration package to the node manager.
• Instep214, the node manager reads any software and data required to run the one or more modules, as defined in the dependency manager.
• Instep216, the node manager installs the required software and data fetched instep214. Analytics Agents may dynamically load and unload modules once they are installed, so there may not be a need to restart any equipment or software and the installed one or more modules may be ready to be used.
• Instep218, the node manager executes the software installed instep216. After the analytics agent starts the analytics module, each analytics agent running the new module may transmit a heartbeat signal to a supervisor. The heartbeat signals may indicate the new module was properly started and is ready to use.
• Example #1 is a system hosting an in-memory database, similar to the one described inFIG. 1. In this example, the in-memory database and system includes a plurality of analytics modules. One analytics module may implement record linking utilizing a weighted model while another uses decision trees. Some modules may be optimized to operate on any available data, while others are tuned to produce desired results from a restricted set of fields or data collections. Some modules were developed and uploaded by different user groups. Each user query can specify different analytics modules be applied and use different parameters for said modules. It is possible for different users to use the in-memory database to extract information at the same time and even process the same data in several different ways at the same time. It is also possible for some users to plug-in new analytics modules at any time, without affecting the performance of the in-memory database or the experience of other users.
• The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
• Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
• The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the invention. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.
• When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
• The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims (18)

What is claimed is:

1. A system comprising:

a first node including a main memory configured to store a record of an in-memory database;

a second node including a processor configured to receive a request for an action involving a software component, to input a query result into the software component, and to execute the software component based on the query result, wherein the query result is based on the record; and

a third node configured to supervise the second node and to receive a heartbeat signal from the second node, wherein the heartbeat signal is informative of the second node receiving the software component.

2. The system ofclaim 1, further comprising:

a fourth node configured to transmit the query result to the second node based on a determination if a search query contains the request for the action.

3. The system ofclaim 2, wherein the fourth node is configured to identify the second nodes prior to transmitting the search query to a fifth node.

4. The system ofclaim 3, wherein the fourth node is configured to determine an action parameter to be applied prior to transmitting the search query to the fifth node.

5. The system ofclaim 2, wherein the fourth node is configured to determine if the search query contains the request for the action and to identify the second node executing the software component.

6. The system ofclaim 5, further comprising:

a fifth node configured to execute a search conductor query and to send a subset of the query result containing a record of a sixth node satisfying the search conductor query based on a receipt of the search conductor query from the fourth node, wherein the fourth node is configured to generate the search conductor query based on the search query, wherein the fourth node is configured to send the search conductor query to the fifth node.

7. The system ofclaim 6, wherein the fourth node is configured to aggregate the subset of the query result received from the fifth node and thereby generate the query result.

8. The system ofclaim 6, wherein the fourth node is configured to send a record in the query result to the second node, wherein the record in the query result is compressed.

9. The system ofclaim 1, wherein the software component includes at least one of a disambiguation module, a linking module, a scoring module, or a link-in-real-time module.

10. The system ofclaim 1, further comprising:

a fourth node configured to send the software component to a data store based on receiving the software component from a remote data source, wherein the second node is configured to retrieve the software component from the data store before the query result is input.

11. The system ofclaim 1, further comprising:

a fourth configured to validate the search query based on a programming interface.

12. The system ofclaim 1, further comprising:

a fourth node configured to store the software component in an agent and to generate the software component based on a programming interface.

13. The system ofclaim 2, wherein the fourth node is configured to receive the search query from a remote data source.

14. The system ofclaim 1, wherein the component includes a module.

15. The system ofclaim 1, wherein the third node is configured to request that the software component be sent from a data store to the second node according to a dependency tree stored in a fourth node and before the query result is input, wherein the third node is configured to supervise the fourth node.

16. The system ofclaim 1, wherein the action includes an analytic.

17. The system ofclaim 1, wherein the second node is configured to host an agent configured to run the software component.

18. The system ofclaim 1, wherein the software component is configured for selectively plugging into the second node and selectively unplugging from the second node.

Images