Patent Description:
Analytics-as-a-service (AaaS) can provide tools (e.g., data analytics software) that can allow for organizing, analyzing and presenting data. AaaS can operate in a distributed computing system (e.g., a cloud) that can include multiple servers (e.g., in data centers distributed over multiple locations). In some implementations, AaaS can provide end-to-end capabilities to its customer (e.g., a company) that can include data acquisition, data analysis and data visualization (e.g., visualization of results of the data analysis).

<CIT> discloses a method for distribution of data science workloads. <CIT> discloses redeploying functions across multiple container platforms. <CIT> discloses edge configuration of software systems. <CIT> discloses a metadata driven analytics framework.

Various aspects of the disclosed subject matter may provide one or more of the following capabilities.

A method includes receiving data characterizing an analytics package, and generating, by an analytics framework associated with a plurality of compute nodes, a container image associated with the analytics package and a unique identifier indicative of the container image. The container image is saved in a central container registry. The method further includes receiving, from a client, data characterizing deployment parameters associated with the deployment of the container image on the plurality of compute nodes and the unique identifier indicative of the container image. The method also includes generating at least one analytics service pod based on the deployment parameters and the unique identifier. The at least one analytics service pod includes the container image. The at least one analytics service pod is configured to execute the analytics package on one or more compute nodes of the plurality of compute nodes based on the deployment parameters. The deployment parameters include computing resource associated with execution of the at least one analytics service pod on the plurality of compute nodes.

One or more of the following features can be included in any feasible combination.

In one implementation, generating the at least one analytics service pod includes selecting the container image from a plurality of container images saved in the central container registry based on the received unique identifier. In another implementation, the method further includes receiving data characterizing a request to execute the analytic package on the one or more compute nodes of the plurality of compute nodes; and executing the analytics package by at least deploying the container image in first analytic pod.

In one implementation, data characterizing the analytics package is received by an incubator service via a first representational state transfer (REST) application programming interface (API) call, data characterizing deployment parameters is received by a deployer service via a second REST API call, and data characterizing the request to execute the analytic package is received by the at least one analytics service pod via a third REST API call. The incubator service, the deployer service and the at least one analytics service pod are included in the analytics framework. In another implementation, the method further includes providing the unique identifier to the client and receiving data characterizing deployment parameters from the client. In yet another implementation, the container image includes code of one or more analytical models in the analytics package. In one implementation, the plurality of compute nodes are a kubernetes cluster.

In some implementations, the method can further include generating multiple replicas of analytics service pods based on a received number of analytics service pod replica. The deployment parameters include the number of analytics service pod replica. In some implementations, computing resource includes one or more of data storage capacity, random access memory, and processing resources.

These and other capabilities of the disclosed subject matter will be more fully understood after a review of the following figures, detailed description, and claims.

Industrial analytics can be used to model physical systems (e.g., oil and gas industrial systems) and assess their current operations and/or predict their future operation. Industrial analytics can include an analytics package (e.g., including one or more analytical model(s)) that can be executed in parallel or in sequence. The analytics package can be executed on a distributed computing system that includes a cluster of compute nodes (e.g., Kubernetes cluster). An analytic framework can allow a client (e.g., a data scientist) to deploy and execute the analytics package. Deployment and execution of analytics packages on existing analytics framework can be inefficient and time-consuming. For example, the client may have to manually deploy the analytics package and/or execute the deployed analytics package. Additionally, the analytics framework can be complex, and the client may need to be trained / experienced in using the analytics framework. This can make it difficult for inexperienced clients from using the distributed computing system. Some implementations of the current subject matter can provide an improved analytics framework that can automate the deployment and/or execution of analytics package(s). Additionally or alternately, the improved analytics framework can reduce the time taken to deploy and/or execute the analytics package.

<FIG> is a flow chart of an exemplary method for deploying an analytics package on a distributed computing system (e.g., a cloud, a kubernetes cluster, etc.). The analytics package can include, for example, source code of the analytics (e.g., code of analytical models) with its dependencies listed in a text file (e.g., a requirements. The distributed computing system can include a plurality of compute nodes with computing resources (e.g., processors, random access memory, data storage capacity, etc.) for executing the analytics package. At step <NUM>, data characterizing analytics package is received by an analytics framework of the distributed computing system. In some implementations, the analytic framework can include an abstraction / flow that can allow for execution of the analytics package by generating, deploying and executing a container image of the analytics package. In some implementations, the analytics package can be provided by a client (e.g., a data scientist, a customer, etc.) of the distributed computing system. The analytics package can include computer executable code (e.g., code defining user's analytical model). <FIG> illustrates an exemplary analytics framework <NUM> of a distributed computing system. The analytics framework <NUM> can receive the data characterizing the analytics package from a client <NUM> (e.g., via a GUI). This can be done, via a first application programming interface (API) call <NUM> (e.g., a first representational state transfer [REST] call). In some implementations, the client can upload the analytics package (e.g., an analytical model of an industrial system) and the uploaded analytics package can be received by an incubator service <NUM> of the analytics framework <NUM>.

At step <NUM>, the incubator service <NUM> in the analytics framework <NUM> can generate a container image <NUM> associated with the analytics package. In some implementations, the incubator service <NUM> can include software that can create the container image of the analytics package and push the container image <NUM> to a container registry <NUM>. In some implementations, the container image <NUM> can be a standalone package of software that includes the requisite executable code to execute an application (e.g., an analytics package). The container image <NUM> can include various information associated with the analytics package. The container image can include a computer executable code of the analytical model in the analytics package. Additionally or alternately, the container image can include the runtime environment, libraries (e.g., associated with the computer language in which the code of the analytical model is written), configurations, etc., associated with the execution of the analytics package on the distributed computing system (e.g., cloud). <FIG> illustrates an exemplary container image <NUM>. The container image <NUM> can include a multithreaded Python Gunicorn Server <NUM>, code of the analytic model <NUM> and requirement data <NUM>. The Python Gunicorn Server <NUM> can be a multithreaded server which can allow for execution of the analytics package on the distributed computing system. The multithreaded nature of the Python Gunicorn Server <NUM> can facilitate for handling of multiple concurrent requests. The requirement data <NUM> is a text file which specifies the various dependent packages which have been used in the analytic model <NUM>.

The container image <NUM> can be stored in the container registry <NUM>. The container registry <NUM> can be used to store multiple container images associated with various analytics packages (e.g., from multiple clients). The incubator service <NUM> can also generate a unique identifier associated with the container image <NUM>. The unique identifier can be used to deploy the container image <NUM>. For example, the unique identifier can be used to retrieve the container image <NUM> form the container registry <NUM>. The unique identifier is provided to the client <NUM> (e.g., via the GUI). The client <NUM> can request the deployment of the container image <NUM> by providing the unique identifier to the analytics framework <NUM> (e.g., via the GUI).

Returning to <FIG>, at step <NUM>, a deployer service <NUM> in the analytics framework <NUM> can receive data characterizing deployment parameters associated with the deployment of the container image <NUM> on the plurality of compute nodes of the distributed computing system. The deployer service <NUM> includes software that can pull / extract a container image from the container registry <NUM>. The data characterizing the deployment parameters can be received from the client <NUM>. This can be done, via a second API call <NUM> (e.g., a second REST API call). The deployment parameters can include the computing resources of the distributed computing system needed to execute the analytics package in the container image <NUM> (e.g., execute the analytical model code). For example, the deployment parameters can include one or more of the compute nodes (e.g., processors / processing resources), data storage capacity, RAM, etc. that are needed to execute the analytics package. Based on deployment parameters, the analytics framework <NUM> can allocate the computing resources of the distributed computing system. Additionally, the deployer service <NUM> can receive the unique identifier indicative of the container image <NUM> from the client <NUM>.

At step <NUM>, the deployer service <NUM> can deploy / generate an analytics service pod <NUM> associated with the container image <NUM>. The deployer service <NUM> can retrieve the container image <NUM> from the container registry <NUM> based on the unique identifier received at step <NUM>. After the container image <NUM> has been retrieved, the deployer service <NUM> can generate the analytic service pod <NUM> based on the retrieved container image <NUM> and the deployment parameters received at step <NUM>. For example, the analytics service pod <NUM> can include the container image <NUM> and the deployment parameters. The analytics service pod <NUM> can be configured to execute the analytics package in the container image <NUM> on the distributed computing system based on the deployment parameters. For example, the computing resources of the distributed computing system (e.g., number of compute nodes) can be allocated based on the deployment parameters in the analytics service pod. The analytics service pod <NUM> can execute the analytics package upon receiving an input from the client. In some implementations, the analytics service pod <NUM> can include an instance of a running process on the distributed computing system that has been created based on parameters provided by the user (e.g., via second API call).

The analytics service pod <NUM> can receive data characterizing a request to execute the analytics package associated with the container image <NUM> on the distributed computing system (e.g., on one or more compute nodes of distributed computing system). The request can include input parameter(s) for the analytics package included in the container image <NUM> of the analytics service pod <NUM>. The data characterizing the request to execute the analytic package can be received from the client <NUM>. This can be done, via a third API call <NUM> (e.g., a third REST API call). Upon receiving the request, the deployed analytics service pod <NUM> can execute the analytics package (e.g., based on input parameter(s) as inputs of the analytics package).

The database <NUM> can include meta-information associated with the analytic package / container image. The meta-information can include, for example, the unique model identifier, the runtime of the analytics package, distributed system machine parameters associated with the execution of the analytics package, status of the analytics model, etc. Catalog Service <NUM> can be a layer above the database <NUM> which can facilitate the database operations (e.g., create, update, fetch, delete, etc.) via exposed REST endpoint. In some implementations, a security service <NUM> can regulate the access of the client <NUM> to the analytics framework. For example, the security service <NUM> can request the client <NUM> for a passcode prior to allowing access to the client <NUM> to the analytics framework (e.g., prior to making first, second or third API calls).

In some implementations, the deployer service <NUM> can generate multiple analytics service pods. For example, the deployment parameters can include a number of replicas of analytics service pods to be generated for the container image <NUM> (e.g., associated with the analytics package received at step <NUM>). <FIG> illustrates an exemplary schematic illustration of multiple analytics service pod deployed on the distributed computing system. The analytics framework can include an ISTIO <NUM> that can receive the third API call <NUM> from the client <NUM>. The analytics framework can further include load balancers <NUM>, <NUM> and <NUM>. Each of the load balancers can be associated with analytics service pods of a unique container image (or a unique analytics package / analytical model). For example, load balancer <NUM> can execute analytics service pods 416a and 416b (e.g., associated with a first analytics package); load balancer <NUM> can execute analytics service pods 418a and 418b (e.g., associated with a second analytics package); and load balancer <NUM> can execute analytics service pods 420a and 420b (e.g., associated with a third analytics package). Analytics service pods 418a and 418b can be replica analytics service pods generated for a given container image. The number or replicas can be based on the deployment parameters associated with the give container image (e.g., received in the second API call). For example, the deployment parameters can include a number of analytic service pods replica to be created for the given container image. In some implementations, the number of analytic service pods replica can be indicative of the maximum number simultaneous execution of the analytics package associated with the given container image (e.g., simultaneous execution of an analytical model with different input parameters).

Upon receiving the third API call <NUM>, the ISTIO can identify the analytics package / container image requested to be executed in the API call <NUM>, and can instruct the relevant load balancer to carry out the execution of an analytics service pod associated with the analytics package / container image. Upon receiving the instruction from the ISTIO the load balancer can identify the analytics service pod replicas that are currently available (e.g., are not executing the analytics package therein) and execute the identified analytics service pod. Other embodiments are within the scope of the disclosed subject matter. For example, the prioritization method described in this application can be used in facilities that have complex machines with multiple operational parameters that need to be altered to change the performance of the machines. Usage of the word "optimize" / "optimizing" in this application can imply "improve" / "improving.

Certain exemplary embodiments will now be described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the systems, devices, and methods disclosed herein. One or more examples of these embodiments are illustrated in the accompanying drawings. Those skilled in the art will understand that the systems, devices, and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the present invention is defined solely by the claims. The features illustrated or described in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention.

The subject matter described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them.

Generally, a processor will receive instructions and data from a Read-Only Memory or a Random Access Memory or both.

The subject matter described herein can be implemented in a computing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a web interface through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components.

Claim 1:
A method (<NUM>) comprising:
receiving (<NUM>) data characterizing an analytics package; generating (<NUM>), by an analytics framework (<NUM>) associated with a plurality of compute nodes, a container image (<NUM>) associated with the analytics package and a unique identifier indicative of the container image (<NUM>) and providing the unique identifier to a client (<NUM>), wherein the container image (<NUM>) is saved in a central container registry (<NUM>), the analytics framework allowing for execution of the analytics package by generating, deploying and executing a container image (<NUM>) of the analytics package using the unique identifier indicative of the container image (<NUM>);
retrieving the container image (<NUM>) from the central container registry (<NUM>) using the unique identifier, the central container registry (<NUM>) storing multiple container images (<NUM>) associated with various analytics packages;
receiving (<NUM>), from the client (<NUM>) by a deployer service (<NUM>) of the analytics framework (<NUM>), data characterizing deployment parameters associated with the deployment of the container image (<NUM>) on the plurality of compute nodes and the unique identifier indicative of the container image (<NUM>) wherein the deployer service (<NUM>) includes software configured to automatically retrieve the container image (<NUM>) from the central container registry (<NUM>) using the unique identifier; and
generating (<NUM>) at least one analytics service pod (<NUM>) based on the deployment parameters and the unique identifier, wherein the at least one analytics service pod (<NUM>) includes the container image (<NUM>) and is configured to execute the analytics package on one or more compute nodes of the plurality of compute nodes based on the deployment parameters,
wherein the deployment parameters include computing resource associated with execution of the at least one analytics service pod on the plurality of compute nodes.