System and Method for Influencing Runtime Personality

Abstract

A system and corresponding method influence a runtime personality of a runtime fabric of an analytics platform. The method determines a new runtime-configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform. The new runtime-configuration is different from a current runtime-configuration of the processing element. The method causes reconfiguration of the processing element to effect the influencing of the runtime personality. The reconfiguration includes changing the current runtime-configuration to the new runtime-configuration determined. The at least one distributed physical plan represents a plurality of jobs for the processing of the user query. The processing element is selected to execute a job of the plurality of jobs. The reconfiguration is performed in time for the processing element to execute the job, enabling per-query runtime configuration for improved compute efficiency.

Description

Docket No. 6214.1006001System and Method for Influencing Runtime PersonalityRELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 695,224, filed on September 16, 2024. This application is related to U.S. Application No. 18 / 542,291, filed December 15, 2023, U.S. Application No. 18 / 541,993, filed December 15, 2023, and U.S. Application No. 18 / 542,488, filed December 15, 2023. The entire teachings of the above applications are incorporated herein by reference.BACKGROUND

[0002] A data lake is a repository designed to store and process large amounts of structured and / or unstructured data. Conventional data lakes provide limited real-time or batch processing of stored data and can analyze the data by executing commands issued by a user in SQL (structured query language) or another query or programming language. The exponential growth of computer data storage raises several challenges for storage, retrieval, and analysis of data. In particular, data lakes and other data storage systems have the capacity to store large and ever-increasing quantities of data.SUMMARY

[0003] According to an example embodiment, a computer-implemented method for influencing a runtime personality of a runtime fabric of an analytics platform comprises determining a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform. The new runtime configuration is different from a current runtime configuration of the processing element. The computer-implemented method further comprises causing a reconfiguration of the processing element to effect the influencing of the runtime personality. The reconfiguration includes changing the current runtime configuration to the new runtime configuration determined. The at least one distributed physical plan represents a plurality of jobs for the processing of the user query. The processing element is selected to execute a job of the plurality of jobs. The reconfiguration is performed in time for the processing element to execute the job.- 1 -4212910. vlDocket No. 6214.1006001

[0004] The at least one distributed physical plan may represent at least one dataflow graph (DFG). The job may be at least a portion of a DFG of the at least one DFG.

[0005] The new configuration determined may be a per-query runtime configuration.

[0006] The new runtime configuration determined may increase compute efficiency of the processing element for executing the job relative to a compute efficiency otherwise effected by executing the job based on the current runtime configuration of the processing element.

[0007] The computer-implemented method may further comprise causing the reconfiguration to be performed, at runtime, in parallel with the processing of the user query.

[0008] The new configuration may include a change to at least one runtime characteristic.

[0009] The new runtime configuration determined may include a total number of instances of a type of an accelerator of the processing element. The total number of instances may be different from a total number of instances of the type of the accelerator in the current runtime configuration. The type of the accelerator may be a field-programmable gate array (FPGA) block of a FPGA, a pre-compiled kernel for a graphics processing unit (GPU), or other type of accelerator for non-limiting examples.

[0010] Causing the reconfiguration may include generating a control signal and sending the control signal generated to the runtime fabric which, in turn, may perform the reconfiguration prior to a time at which the processing element is to execute the job.

[0011] The new runtime configuration determined may be associated with a query profile identifier (ID). The job may be associated with a job ID. Sending the control signal may include sending the control signal to the runtime fabric along with the query profile ID and the job ID.

[0012] Causing the reconfiguration may include determining a total amount of time for changing the current runtime configuration to the new runtime configuration determined and comparing the total amount of time determined for changing the current runtime configuration to the new runtime configuration determined to a total amount of time for the processing of the user query. In an event a result of the comparing indicates that the total amount of time determined is less than the total amount of time for the processing of the user query, the computer-implemented method may further comprise generating a control signal and sending the control signal generated with a query profile ID of a query profile and a job ID of the job to the runtime fabric at a point in time that enables the total amount of time determined to overlap with the total amount of time taken for the processing. In an event a- 2 -4212910. vlDocket No. 6214.1006001 result of the comparing does not indicate that the total amount of time determined is less than the total amount of time for the processing of the user query, the computer-implemented method may further comprise sending the query profile ID to the runtime fabric to accompany the job. The query profile may represent the new runtime configuration determined.

[0013] The computer-implemented method may further comprise producing a per-query operator representation of operators associated with implementation of the job. Determining the new runtime configuration may be further based on the per-query operator representation of operators produced.

[0014] Determining the new runtime configuration may be further based on the current runtime configuration and scheduled usage information of accelerators available to the processing element.

[0015] Determining the new runtime configuration may be further based on accelerator instance information of the processing element, usage information of accelerators instantiated in the current runtime configuration, and accelerators that correspond to operators for executing the job.

[0016] Determining the new runtime configuration may be further based on determining a performance critical operator for executing the at least a portion of the DFG.

[0017] The reconfiguration may further comprise checking a loaded programs database for whether a compiled program for implementing the job is loaded into the processing element. In an event the loaded programs database indicates that the compiled program is not loaded into the processing element, the computer-implemented method may further comprise checking a compiled programs database for whether the compiled program is present. In an event the compiled program is present in the compiled programs database, the computer- implemented method may further comprise loading the compiled program into the processing element. In an event the compiled program is not present in the compiled programs database, the computer-implemented method may further comprise generating the compiled program, automatically at runtime, by compiling a program, loading the compiled program into the processing element, and storing the compiled program in the compiled programs database.

[0018] The computer-implemented method may further comprise generating a key that uniquely identifies the compiled program. The generating may be based on arguments input to the compiled program and respective types of the arguments. Checking the compiled programs database may include employing the key generated. Checking the loaded programs- 3 -4212910. vlDocket No. 6214.1006001 database may include employing the key generated and an identifier of the processing element.

[0019] The computer-implemented method may further comprise executing the job by the processing element to produce a result. The result may contribute to a response to the user data query. The response may be output by the data analytics platform.

[0020] According to another example embodiment, a computer-based system comprises runtime fabric of an analytics platform and an agent. The agent is configured to determine a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform. The new runtime configuration is different from a current runtime configuration of the processing element. The agent is further configured to cause a reconfiguration of the processing element to influence a runtime personality of the runtime fabric. The reconfiguration includes changing the current runtime configuration to the new runtime configuration determined. The at least one distributed physical plan represents a plurality of jobs for the processing of the user query. The processing element is selected to execute a job of the plurality of jobs. The reconfiguration is performed in time for the processing element to execute the job.

[0021] Alternative computer-based system embodiments parallel those described above in connection with the example computer-implemented method embodiment.

[0022] According to another example embodiment, a non-transitory computer-readable medium for influencing a runtime personality of a runtime fabric of an analytics platform has encoded thereon a sequence of instructions which, when loaded and executed by at least one processor, cause the at least one processor to determine a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform. The new runtime configuration is different from a current runtime configuration of the processing element. The sequence of instructions further causes the at least one processor to cause a reconfiguration of the processing element to effect the influencing of the runtime personality. The reconfiguration includes changing the current runtime configuration to the new runtime configuration determined. The at least one distributed physical plan represents a plurality of jobs for the processing of the user query. The processing element is selected to execute a job of the plurality of jobs. The reconfiguration is performed in time for the processing element to execute the job.- 4 -4212910. vlDocket No. 6214.1006001

[0023] Alternative non-transitory computer-readable medium embodiments parallel those described above in connection with the example computer-implemented method embodiment.

[0024] It is noted that example embodiments of a method, system, and computer-readable medium may be configured to implement any embodiments, or combination of embodiments, described herein.

[0025] It should be understood that example embodiments disclosed herein can be implemented in the form of a method, apparatus, system, or computer readable medium with program codes embodied thereon.BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The foregoing will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments.

[0027] FIG. 1 A is a block diagram of an example embodiment of a computer-based system.

[0028] FIG. IB is a block diagram of an example embodiment of a data analytics compute cluster.

[0029] FIG. 2 is a block diagram of an example embodiment of a multi-cloud data analytics system.

[0030] FIG. 3 is a block diagram of an example embodiment of a multi-cloud analytics platform that may be employed as the multi-cloud data analytics system of FIG. 2, and is shown as two networked servers, a service console server and a query server, for non-limiting example..

[0031] FIG. 4 is a block diagram of an example embodiment of a service console server.

[0032] FIG. 5 is a block diagram of an example embodiment of a query server.

[0033] FIG. 6 is a flow diagram of an example embodiment of a data analysis process that may be performed by an example embodiment of a query server disclosed herein.

[0034] FIG. 7 is a block diagram of an example embodiment of a disaggregated data analytics stack with domain-specific computing.

[0035] FIG. 8 is a block diagram of an example embodiment of a third phase of a data analytics pipeline.- 5 -4212910. vlDocket No. 6214.1006001

[0036] FIG. 9 is a flow diagram of an example embodiment of a process for a hardwareagnostic domain-specific virtual machine (VM).

[0037] FIG. 10 is a block diagram of an example embodiment of mapping machine code of a dataflow graph (DFG) to a Programmable Dataflow Unit (PDU).

[0038] FIG. 11 is a block diagram of another example embodiment of mapping machine code of a DFG to a PDU.

[0039] FIG. 12 is a block diagram of an example embodiment of an architecture for a computer-based system disclosed herein.

[0040] FIG. 13 is a block diagram of an example prior art central processing unit (CPU) in operation.

[0041] FIG. 14 is a block diagram of an example embodiment of a PDU in operation.

[0042] FIG. 15 is a block diagram of an example prior art control flow process for a prior art CPU.

[0043] FIG. 16 is a block diagram of an example embodiment of a dataflow process for a PDU.

[0044] FIG. 17 is a block diagram of an example embodiment of a DFG.

[0045] FIG. 18 is a block diagram of an example embodiment of a logical structure of an edge.

[0046] FIG. 19 is a block diagram of an example embodiment of a compute node.

[0047] FIG. 20 is a block diagram of an example embodiment of an execution environment for a compute node.

[0048] FIG. 21 is a flow diagram of an example embodiment of a computer-implemented method.

[0049] FIG. 22 is a flow diagram of another example embodiment of a computer- implemented method.

[0050] FIG. 23 is a block diagram of an example embodiment of an internal structure of a computer optionally within an embodiment disclosed herein.

[0051] FIG. 24 is a block-diagram of an example embodiment of a high-level flow of a data analytics compute plane.

[0052] FIG. 25 is a block diagram of an example embodiment of a host machine that may be configured to host a virtual machine (VM) configured to implement an example embodiment disclosed herein.- 6 -4212910. vlDocket No. 6214.1006001

[0053] FIG. 26A is a schematic diagram of an example embodiment of a dataflow graph (DFG) for non-limiting example.

[0054] FIG. 26B is a table of an example embodiment of costs for different types of operators implemented on different types of processing elements.

[0055] FIG. 26C is a table of a non-limiting example embodiment of costs for moving data between processing elements

[0056] FIGS. 26D-1 and 26D-2 are block diagrams of example embodiments of data movement between processing elements.

[0057] FIG. 27A is block diagram of another example embodiment of a computer-based system.

[0058] FIG. 27B is a block-diagram of an example embodiment of a high-level flow of a data analytics compute plane.

[0059] FIG. 28 is a schematic diagram of an example embodiment of a dataflow graph (DFG) for non-limiting example.

[0060] FIG. 29 is a timeline of an example embodiment of multiple stages of query processing for non-limiting example embodiment.

[0061] FIG. 30 is a flow diagram of an example embodiment of a computer-implemented method for generating a control signal.

[0062] FIG. 31 is a flow diagram of an example embodiment of a computer-implemented method for influencing a runtime personality of a runtime fabric of an analytics platform.

[0063] FIG. 32 is a flow diagram of an example embodiment of a method for automatic code generation.DETAILED DESCRIPTION

[0064] A description of example embodiments follows.

[0065] A runtime “personality” as disclosed herein, may refer to a runtime characteristic(s) or runtime configuration. The term “influencing,” as used herein, refers to causing an effect (change) in a manner that is not necessarily direct or controlling.

[0066] Embodiments disclosed herein provide advanced functionality for data analytics. As used herein, a “dataflow graph” (DFG) may include a graph or tree data structure having one or more dataflow node(s) and edge(s), where each dataflow node may represent a- 7 -4212910. vlDocket No. 6214.1006001 computational operation or task to be performed using data, and each edge may represent a dataflow operation or task, z.e., to move data between dataflow nodes.

[0067] As used herein, a “query front-end,” or simply “front-end,” may include a client entity or computing device at which a user data query (such as a SQL [structured query language] query, for non-limiting example) is created, edited, and / or generated for submission. Likewise, as used herein, a “query back-end,” or simply “back-end,” may include a server entity or computing device that receives a user data query created by a frontend.

[0068] As used herein, an “abstract syntax tree” (AST) may include a graph or tree data structure used to represent the structure of a program, source code, or query, for non-limiting examples. Further, as used herein, a “logical plan” may include a collection of logical operators that describe work used to generate results for a query and / or define which data sources to use and / or operators to apply to generate the results; a logical plan may also be represented by a graph or tree data structure. In the alternative or additionally, a logical plan may represent a query as a relational algebra expression.

[0069] As used herein, a “physical plan” may include a logical plan data structure that is annotated with implementation details. Further, as used herein, an “intermediate representation” (IR) may include a data structure, code, or language for an abstract machine that is used to generate code for one or more target machine(s), optionally after applying one or more optimization(s) and / or transformation(s), for non-limiting examples, to the IR; an IR may also be used to represent a physical plan.

[0070] As used herein, a “strategy tree” (interchangeably referred to as a “tree of actions”) may include a tree data structure having one or more action node(s) (interchangeably referred to as “action(s)”), where each action node may include one or more operation(s) of a query, and where a parent action node’s operation(s) may use data resulting from performing operation(s) of the parent action node’s child action node(s).

[0071] Further, as used herein, a “stage” may include an optional subcomponent of an action node, where a given action node may have one or more optional stage(s), and each of the optional stage(s) may be a data structure that represents a respective portion of the given action node’s operation(s).

[0072] Embodiments provide advanced functionality for data analytics. As used herein, a “dataflow graph” (DFG) may include a graph or tree data structure where each node in the graph represents a computational operation or task to be performed using data, and each edge- 8 -4212910. vlDocket No. 6214.1006001 in the graph represents a dataflow operation or task, i.e., to move data between nodes. Such a DFG may be a machine-readable DFG. Further, as used herein, a “query front-end” or simply “front-end” may include a client entity or computing device at which a user data query is created, edited, and / or generated for submission. Likewise, as used herein, a “query back- end” or simply “back-end” may include a server entity or computing device that receives a user data query created by a front-end. It should also be understood that, as used herein, numerical adjectives, such as the terms “first” and “second,” do not imply ordering (such as, e.g., chronological or other types of ordering) or cardinality, but instead simply distinguish between two different objects or components of the same type, for instance, two different nodes or data blocks.

[0073] Conventional data analytics platforms are constrained in ways that prevent them from meeting the demands of modern data storage, retrieval, and analysis. For example, many existing analytics systems employ general-purpose processors, such as x86 central processing units (CPUs) for non-limiting example, that manage retrieval of data from a database for processing a query. However, such systems often have inadequate bandwidth for retrieving and analyzing large stores of structured and unstructured data, such as those of modern data lakes. Further, the output data resulting from queries of such data stores may be much larger than the input data, placing a bottleneck on system performance. Typical query languages, such as structured query language (SQL) for non-limiting example, can produce inefficient or nonoptimal plans for such systems, leading to delays or missed data. Such plans can also lead to a mismatch between input / output (I / O) and computing load. For example, in a CPU-based analytics system, I / O may be underutilized due to an overload of computation work demanded of the CPU.

[0074] The CAP (Consistency, Availability, and Partition Tolerance) theorem states that a distributed data store is capable of providing only two of the following three guarantees: a) Consistency: Every read operation receives data in accordance with the most recent write operation. b) Availability: Every request receives a response. c) Partition tolerance: The system will continue to operate despite experiencing delay or dropping of messages.Similar to the CAP theorem, existing data stores cannot maximize dataset performance, size, and freshness simultaneously; prioritizing two of these qualities leads to the third being compromised. Thus, prior approaches to data analytics have been limited from deriving cost-- 9 -4212910. vlDocket No. 6214.1006001 efficient and timely insights from large datasets. Attempts to solve this problem have led to complex data pipelines having fragmented data silos.

[0075] Example embodiments, described herein, provide data analytics platforms that overcome several of the aforementioned challenges in data analytics. In particular, a query compiler may be configured to generate an optimized DFG from an input query, providing efficient workflow instructions for the platform. PDUs (Programmable Dataflow Units) are hardware engines for executing the input query in accordance with the workflow and may include a number of distinct accelerators that may each be optimized for different operations within the workflow. Such platforms may also match the impedance between computational load and I / O. As a result, data analytics platforms in example embodiments can provide consistent, cost-efficient, and timely insights from large datasets.

[0076] According to an example embodiment, a novel virtual machine (VM) platform, referred to interchangeably herein as “Insight” or a computer-based system, accelerates data analytics workloads, and such acceleration may be enabled by, among other things, a programmable dataflow unit (PDU). Unlike traditional VMs, an example embodiment of a VM disclosed herein may take a description of a computation as dataflow graphs (DFGs) and evaluate the DFGs. The DFGs may include nodes and edges. Nodes may perform operations and edges may carry data between nodes. Edges may move data as a stream of data blocks. All the data blocks may be immutable and shared by multiple nodes using reference counts. There may be three different kinds of nodes: input nodes, output nodes and compute nodes. Input nodes may act as data sources and output nodes may act as data sinks. Input nodes may pull data from local or external sources and push the data into the DFG. Output nodes may pull data from a DFG and push the data to local and / or external sinks. Compute nodes may perform various transformations on data, such as filtering, groupingjoining, etc., for nonlimiting examples, and may use hardware accelerators on a PDU.

[0077] An example embodiment of a VM compute node disclosed herein may be programmable using an instruction set architecture (ISA) that is accelerator-centric. Traditionally, VM instructions are ALU (arithmetic logic unit)-centric, which makes it easy for just-in-time (JIT) compilers to generate code for CPUs where an ALU is the workhorse. According to an example embodiment, an ISA may be designed to be accelerator-centric instead of ALU-centric, which may enable efficient implementation of a hardware accelerator for a given function in the ISA. The ISA may be extensible and can evolve as workload- 10 -4212910. vlDocket No. 6214.1006001 requirements evolve over time. Such an ISA may be employed by a VM of a computer-based system, such as the computer-based system disclosed below with regard to FIG. 1 A.

[0078] FIG. 1 A is a block diagram of an example embodiment of a computer-based system 110, also referred to interchangeably herein as Insight. The computer-based system 110 may include an architecture that that influences runtime personality and / or includes automatic code generation, such as disclosed further below with regard to FIGS. 27A and 27B. Continuing with reference to FIG. 1 A, the system 110 comprises at least one VM (not shown), at least one processor (not shown), and memory (not shown) with computer code instructions (not shown) stored thereon, such as disclosed further below with regard to FIG. 23. Continuing with reference to FIG. 1A, the at least one processor and the memory, with the computer code instructions, may be configured to cause a VM 130 of the at least one VM to select an execution resource 140 from a set of execution resources (not shown) of the VM 130. The execution resource 140 may be for executing a VM instruction (not shown). The VM 130 may transform the VM instruction into machine code 119 for the execution resource selected 140. The VM 130 may execute the machine code 119 via the execution resource selected 140. The executing furthers execution by the VM 130 of a DFG 104 that includes at least one compute node (not shown). A compute node of the at least one compute node has a set of VM instructions (not shown) including the VM instruction. The DFG 104 corresponds to at least a portion of a computation workload (not shown) associated with a user data query 102. An output 108 of the execution of the DFG 104: (i) represents a result (not shown) of processing the at least a portion of the computation workload and (ii) contributes to a response 112 to the user data query 102. In the example embodiment, the user data query 102 is received from a user device 117 of a user 114 for non-limiting example. The user device 117 may be a personal computer (PC), laptop, table, smartphone, or any other user device for non-limiting examples.

[0079] In an example embodiment, the computer-based system 110 may further comprise at least one system resource set (not shown). Each system resource set of the at least one system resource set may be associated with a respective VM of the at least one VM. A system resource set (not shown) of the at least one system resource set may include at least one of: a PDU resource, a GPU resource, a memory resource, a network resource, another type of resource, or a combination thereof, for non-limiting examples.

[0080] In an example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to select the- 11 -4212910. vlDocket No. 6214.1006001 execution resource 140 based on at least one of: (i) a respective efficiency of executing the VM instruction at each execution resource of the set of execution resources and (ii) a respective availability of each execution resource of the set of execution resources.

[0081] According to another example embodiment, the VM instruction may be specified in an ISA. The ISA may be compatible with at least one type of computation workload. The at least one type of computation workload may include a type of the computation workload associated with the user data query 102. The at least one type of computation workload may include a SQL query plan, a data ingestion pipeline, an artificial intelligence (Al) or machine learning (ML) workload, a high-performance computing (HPC) program, another type of computation workload, or a combination thereof, for non-limiting examples.

[0082] Further, in yet another example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to select the execution resource 140 based on the execution resource 140 including an accelerator.

[0083] According to an example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to select the execution resource 140 based on the execution resource 140 including a PDU based accelerator, a GPU based accelerator, a tensor processing core (TPC) based accelerator, a tensor processing unit (TPU) based accelerator, a single instruction multiple data (SIMD) unit based accelerator, a CPU based accelerator, another type of accelerator, or a combination thereof, for non-limiting examples.

[0084] In another example embodiment, the compute node may be a first compute node. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to process, via the first compute node, a first data block associated with the at least a portion of the computation workload. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to, in parallel, perform at least one of: (i) processing, via a second compute node of the at least one compute node, a second data block associated with the at least a portion of the computation workload and (ii) transferring, via an edge of a set of edges (not shown) associated with the DFG 104, the second data block. The second data block may be associated with the at least a portion of the computation workload.

[0085] In an example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to control a flow- 12 -4212910. vlDocket No. 6214.1006001 of data blocks between at least two dataflow nodes (not shown) of the DFG 104. The at least two dataflow nodes may include the at least one compute node. The data blocks may be (i) associated with the at least a portion of the computation workload and (ii) derived from a data source 106 associated with the user data query 102. The data source 106 may be a data lake for non-limiting example.

[0086] According to another example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to perform validation of the DFG 104. Responsive to the validation being unsuccessful, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to terminate execution of the DFG 104. Responsive to the validation being successful, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to proceed with the execution of the DFG 104.

[0087] Further, in another example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to generate a set of edges associated with the DFG 104. Each edge of the set of edges may be configured to transfer data blocks between a corresponding pair of dataflow nodes (not shown) of the DFG 104. The dataflow nodes may include the at least one compute node. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to configure an edge of the set of edges to transfer the data blocks using a first in first out (FIFO) queue. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to configure, based on a user input, a size of the FIFO queue. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to configure an edge of the set of edges to synchronize a first processing speed of a first compute node of the at least one compute node with a second processing speed of a second compute node of the at least one compute node.

[0088] According to an example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to execute the machine code 119 by performing at least one of: an input control function, a flow control function, a register control function, an output control function, a reduce function, a map function, a load function, and a generate function, for non-limiting examples.- 13 -4212910. vlDocket No. 6214.1006001

[0089] In another example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to execute the VM instruction via a software-based execution unit (not shown), a hardware-based execution unit (not shown), or a combination thereof.

[0090] Further, according to yet another example embodiment, the DFG 104 may include at least one input node (not shown). The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to obtain, based on an input node of the at least one input node, at least one data block from a data source, e.g., 106, associated with the user data query 102. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to obtain the at least one data block by implementing a read protocol corresponding to the data source 106.

[0091] In an example embodiment, the DFG 104 may include at least one output node (not shown). The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to store, based on an output node of the at least one output node, at least one data block to a datastore, e.g., the data source 106. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to store the at least one data block by implementing a write protocol corresponding to the datastore, e.g., the data source 106.

[0092] According to another example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to spawn at least one task (not shown) corresponding to at least one of: (i) the at least one compute node, (ii) at least one input node (not shown) of the DFG 104, (iii) at least one output node (not shown) of the DFG 104, and (iv) at least one edge (not shown) associated with the DFG 104. A task of the at least one task spawned may include a thread (not shown) corresponding to the compute node. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to execute the set of VM instructions via the thread. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to monitor execution of a task of the at least one task spawned.

[0093] Further, in yet another example embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to adapt the set of VM instructions based on at least one statistic (not shown) associated- 14 -4212910. vlDocket No. 6214.1006001 with the at least a portion of the computation workload. A statistic of the least one statistic may include a runtime statistical distribution of data values (not shown) in a data source, e.g., 106, associated with the user data query 102. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to adapt the set of VM instructions responsive to identifying a mismatch between the runtime statistical distribution of the data values and an estimated statistical distribution of the data values. The at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to adapt the set of VM instructions by performing at least one of: (i) reordering at least two VM instructions of the set of VM instructions, (ii) removing at least one VM instruction from the set of VM instructions, (iii) adding at least one VM instruction to the set of VM instructions, and (iv) modifying at least one VM instruction of the set of VM instructions for non-limiting examples.

[0094] According to an embodiment, the at least one processor and the memory, with the computer code instructions, may be further configured to cause the VM 130 to generate, based on the DFG 104, a plurality of dataflow subgraphs (not shown). The method may further comprise configuring at least two dataflow subgraphs of the plurality of dataflow subgraphs to, when executed via the VM 130, perform a data movement operation in parallel. The VM 130 may be a first VM. The data movement operation may include at least one of:(i) streaming data from a data source, e.g., 106, associated with the user data query 102 and(ii) transferring data to or from a second VM (not shown). The computer-based system 110 may be employed as part of a data analytics cluster, such as disclosed below with regard to FIG. IB.

[0095] FIG. IB is a block diagram of an example embodiment of a data analytics compute cluster 100. With regard to FIG. 1 A and FIG. IB, the cluster 100 includes the computer-based system 110, e.g., Insight, a distributed compiler 120, the VM 130, and a PDU execution unit 140. The cluster 100 includes a query front-end 150. According to an example embodiment, the cluster 100 may also include other components / modules (not shown), such as a shared state service, performance monitor service, etc., for non-limiting examples. According to an example embodiment, the compiler 120 may provide features such as DFG conversion, execution orchestration, etc., for non-limiting examples. The VM 130 may provide features, such as DFG execution, data path implementation, etc., for nonlimiting examples. The front-end 150 may provide features, such as query planning, optimization, etc., for non-limiting examples. According to an example embodiment, the- 15 -4212910. vlDocket No. 6214.1006001 system 110, compiler 120, VM 130, front-end 150, shared state service, and performance monitor service may be implemented variously as services or stateful applications using a container orchestration system, such as a Kubernetes® (K8s®) system, or any other suitable container system known to those of skill in the art for non-limiting examples.

[0096] FIG. 2 is a block diagram of an example embodiment of a multi-cloud data analytics system 200. The system 200 includes a data lake 206, for non-limiting example, that may be configured to store structured and / or unstructured data. Alternatively, a plurality of data lakes (not shown), or a combination of data lakes, data warehouses and / or other data stores, may be implemented in place of the data lake 206. A multi-cloud analytics platform 260 may be configured to receive a data query, e.g., the query 202 which may be the user data query 102 of FIG. 1 A, disclosed above, to analyze data of the data lake 206 in accordance with the query 202, and may be further configured to provide a corresponding result to a user, such as the response 112 provided to the user 114 of FIG. 1 A. Continuing with reference to FIG. 2, the platform 260 may be implemented via a plurality of cloud networks (not shown) that may each include at least one server (not shown), as described in further detail below. Functional elements of the platform 260 are shown in FIG. 2, including a query processor 250, the computer-based system 210, a PDU block 240, a data management layer 224, a security manager 222, and a management controller 226 for non-limiting examples.

[0097] The query processor 250 may be configured to receive the query 202 from a user. The query 202 may be written in a data analytics language, such as a SQL or Python language, for non-limiting examples, and represents the user’s intent for analysis of the data stored at the data lake 206. The query processor 250 may receive and process the query 202 to generate a corresponding DFG, which defines an analytics operation as a tree of nodes, each node representing a distinct action. The computer-based system 210 may be the computer-based system 110 of FIGS. 1 A and IB, disclosed above, and transforms the DFG into machine-readable instructions for execution by a VM operated at the PDU block 240. The computer-based system 210 may also be referred to herein as Insight. Continuing with reference to FIG. 2, the data management layer 224 interfaces with the data lake 206 to access data requested by the PDU block 240. The security manager 222 provides secure access to the platform 260 and may control authentication, authorization, and confidentiality components, among other examples, of the platform 260. Lastly, the management controller 226 may enable users to view and manage operations of the platform 260, and may manage- 16 -4212910. vlDocket No. 6214.1006001 components of the platform 260, such as monitoring, relocation of components in response to a failure, scaling on up and down, and observing the usage and performance of components.

[0098] The analytics platform 260 can provide several advantages over conventional data analytics solutions. For example, the platform 260 can be scaled easily to service data lakes of any size while meeting demands for reliable data analytics, providing a fully managed analytics service on decentralized data. Further, because the platform 260 can process data regardless of its location and format, it can be adapted to any data store, such as the data lake 206, without changing or relocating the data. The platform 260 may be employed as a multicloud analytics platform, disclosed below with regard to FIG. 3.

[0099] FIG. 3 is a block diagram of an example embodiment of a multi-cloud analytics platform 360 that may be employed as the multi-cloud data analytics platform 260 disclosed above. In the example embodiment of FIG. 3, the multi-cloud analytics platform 360 is shown as two networked servers, a service console server 370, and a query server 380 for non-limiting example. The servers 370, 380 may each include one or more physical servers configured as a cloud service. The service console server 370 may provide a user interface (not shown) to a managing user through a connected device (not shown), enabling the managing user to monitor the performance and configuration of the query server 380. The query server 380 may communicate with a client user (such as an owner of a data lake, e.g., data lake 306, data lake 206 of FIG. 2, or data source 106 of FIG. 1A) to receive a query, e.g., query 302, user data query 202 (FIG. 2), or user data query 102 (FIG. 1 A), to access the data lake 306 to perform an analytics operation in accordance with the query 302, and return a corresponding result to the user, such as disclosed above with regard to FIGS. 1 A and IB. Continuing with reference to FIG. 3, the service console server 370 may transmit management and configuration commands 328 to manage the query server 380, while the query server 380 may provide monitoring communications 332 to the service console server 370. An example embodiment of such a service console server is disclosed below with regard to FIG. 4.

[0100] FIG. 4 is a block diagram of an example embodiment of a service console server 470, with attention to functional blocks that may be operated by the service console server 470. A user interface (UI) 436 can be accessed by a managing user via a computing device (not shown) connected via the Internet or another network, and provides the managing user with access to a plurality of services 438:- 17 -4212910. vlDocket No. 6214.1006001 a) Application Programming Interface (API): Provides the necessary functionality to drive the UI 436. b) Identity and Access Management: Provides authentication services, including verifying the authenticity of the platform user and authorization, and controlling access to various components of the platform to various platform users. c) Workload Management: Manages the control plane workloads, such as creating a cluster and destroying a cluster. d) Cluster Orchestration: Controls operations to create, destroy, start, stop, and relocate the clusters. e) Account Management: Manages the customer account and users within the customer account. f) Cluster Observability: Monitors the cluster for usage and failures so that it can be relocated to other physical machines if the failures rate crosses a threshold.

[0101] The service console server 470 may also include a data store 444 configured to store a range of data associated with a platform, e.g., platform 260 (FIG. 2), such as performance metrics, operational events (e.g., alerts), logs indicating queries and responses, and operational metadata, for non-limiting examples.

[0102] FIG. 5 is a block diagram of an example embodiment of a query server 580, with attention to functional blocks that may be operated by the server 580. As a cloud service, the query server 580 may include a plurality of server clusters 552a-n, of which server 552a is shown in detail. Each of the server clusters 552a-n may be communicatively coupled to a data lake, e.g., the data lake 506, 306 (FIG. 3), 206 (FIG. 2), or 106 (FIG. 1A), to allow independent access to data stored thereon. In response to a query, e.g, the query 502, 302 (FIG. 3), 202 (FIG. 2), or 102 (FIG. 1A), the server clusters 552a-n may coordinate to determine an efficient distribution of tasks to process such query, execute analytics tasks, and generate a corresponding response.

[0103] The server cluster 552a is depicted as a plurality of functional blocks that may be performed by a combination of hardware and software as described in further detail below. Network services 546 may be configured to interface with a user device (not shown) across a network to receive a query, return a response, and communicate with a service console server, e.g, the server 370 (FIG. 3) or 470 (FIG. 4). The query services 550 may include a query optimization block 590, a computer-based system 510, and a PDU executor 540. The- 18 -4212910. vlDocket No. 6214.1006001 computer-based system 510 may be the computer-based system 110 or 210, disclosed above with regard to FIGS. 1 A-B and 2, respectively. As described further below with reference to FIG. 6, the query services 550 of FIG. 5 may operate to generate an intermediate representation (IR) of a query (optionally including one or more optimizations), produce DFG(s) defining execution of the generated IR, and execute the query.

[0104] Continuing with reference to FIG. 5, the management services block 548 may monitor operation of the server cluster 552a, recording performance metrics and events and maintaining a log of the same. The management services block 548 may also govern operation of the query services 550 based on a set of configurations and policies determined by a user. Further, the management services block 548 may communicate with the service console server, e.g., 370 (FIG. 3) or 470 (FIG. 4), to convey performance metrics and events and to update policies as communicated by the server, e.g., 370 or 470. Lastly, a data store 544 may be configured to store the data controlled by the management services block 548, including performance metrics, operational events, logs indicating queries and responses, and operational metadata, for non-limiting examples. The data store 544 may also include a data cache configured to store a selection of data retrieved from the data lake, e.g., 506, 306 (FIG. 3), 206 (FIG. 2), or 106 (FIG. 1 A), for use by the query services 550 for executing a query. An example embodiment of a data analysis process that may be performed by the server 580 is disclosed below with regard to FIG. 6.

[0105] FIG. 6 is a flow diagram of an example embodiment of a data analysis process 600 that may be performed by a query server, e.g., server 380 (FIG. 3) or 580 (FIG. 5). In the example embodiment of FIG. 6, an optional query optimizer 690 may receive a query, e.g, query 602, 502 (FIG. 5), 302 (FIG. 3), 202 (FIG. 2), or 102 (FIG. 1 A), for processing, as well as execution model(s) 656 for reference in optimizing the query. For example, an execution model 656 may specify relevant information on the hardware and software configuration of the PDU executor 158, enabling the query optimizer 156 to adapt an IR to the capabilities and limitations of a PDU executor, e.g, the executor 640, 540 (FIG. 5), 240 (FIG. 2), or 140 (FIG. 1 A). Further, a cost model 656 may specify user-defined limitations regarding resources to dedicate to processing a query over a given timeframe. The optional query optimizer 690 may utilize such a cost model 656 to prioritize a query relative to other queries, define a maximum or minimum number of PDUs to be assigned for the query, and / or lengthen or shorten a timeframe in which to process the query. According to an example embodiment, when invoked, the optional query optimizer 690 may apply optimizations such- 19 -4212910. vlDocket No. 6214.1006001 as customized execution operators and / or and rewrite rules, among other examples. According to an example embodiment, the optional query optimizer 690 may also, or alternatively, apply heuristic-based optimizations and / or any suitable known type of optimization, such as a Volcano optimization, for non-limiting example.

[0106] The computer-based system 610 may receive an IR 618 (optionally optimized by the query optimizer 690) and generate corresponding DFG(s) 604 that define how the query is to be performed by the PDU executor 640. For example, the DFG(s) 604 may define the particular PDUs to be utilized in executing the query, the specific processing functions to be performed by those PDUs, a sequence of functions connecting inputs and outputs of each function, and compilation of the results to be returned to the user. Finally, the PDU executor 640 may access a data lake, e.g., data lake 606, 506 (FIG. 5), 306 (FIG. 3), 206 (FIG. 2), or 106 (FIG. 1 A), perform the query on the accessed data as defined by the DFG(s) 604, and return a corresponding output, e.g., the output 608 or 108 (FIG. 1A). In an embodiment, data lake 606 may be, e.g., Amazon S3®, Microsoft® Azure, PostgreSQL®, or another suitable data lake known to those of skill in the art.

[0107] FIG. 7 is a block diagram of an example embodiment of a disaggregated data analytics stack 700 with domain-specific computing. The stack 700 includes a distributed compiler, e.g., the distributed compiler 720, 620 (FIG. 6), 520 (FIG. 5), 220 (FIG. 2), or 120 (FIG. IB). With reference to FIG. 7, the distributed compiler 720 may receive a user data query, e.g., the query 702, 602 (FIG. 6), 502 (FIG. 5), 302 (FIG. 3), 202 (FIG. 2), or 102 (FIG. 1 A). The user data query 702 may be received from a front-end framework (not shown) such as an Apache Spark™, Python, Presto, or SQL framework, or any other suitable framework known to those of skill in the art for non-limiting examples.

[0108] Continuing with reference to FIG. 7, the distributed compiler 720 may compile the user data query 702 into DFGs, e.g., DFGs 704a-b, 604 (FIG. 6), or 104 (FIG. 1A). The DFGs 704a-b may include dataflow nodes, e.g., dataflow nodes 1074a-d (FIG. 10), 1174a-e (FIG. 11), 1674a-f (FIG. 16), 1774a-j (FIG. 17), or 1974 (FIG. 19) disclosed further below. The dataflow nodes may include VM instruction(s), e.g., VM instruct! on(s) 1076al-3 and / or 1076bl-3 (FIG. 10), 1176al-3 and / or 1176bl-3 (FIG. 11), 1476a-n (FIG. 14), or 2076a-n (FIG. 20), in a domain-specific ISA for data computing, as disclosed further below.

[0109] Continuing with reference to FIG. 7, the stack 700 may also include a computer- based system 710 with resource(s), e.g., SoftPDU 762a (i.e., a software-based PDU executing on a CPU), a PDU 762b (i.e., a hardware-based PDU implemented via a FPGA (field-- 20 -4212910. vlDocket No. 6214.1006001 programmable gate array)), and a GPU 762n. According to an example embodiment, the system 710 may select an execution resource from a set of execution resources, e.g, 762a-n, of a VM, e.g., VM 130 (FIG. 1A). The execution resource may be for executing a VM instruction, e.g, 1076al-3 (FIG. 10), 1076bl-3 (FIG. 10), 1176al-3 (FIG. 11), 1176bl-3 (FIG. 11), 1476a-n (FIG. 14), or 2076a-n (FIG. 20). The system 710 may transform the VM instruction into machine code for the execution resource selected. The system 710 may execute the machine code via the execution resource selected. The executing furthers execution by the VM of a dataflow graph, e.g, 704a or 704b, that includes at least one compute node, e.g., compute node 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19). A compute node of the at least one compute node has a set of VM instructions, e.g., 1076al-3 (FIG. 10), 1076bl-3 (FIG. 10), 1176al-3 (FIG. 11), 1176bl-3 (FIG. 11), 1476a-n (FIG. 14), or 2076a-n (FIG. 20), including the VM instruction. Continuing with reference to FIG. 7, the dataflow graph, e.g., 704a or 704b, corresponds to at least a portion of a computation workload associated with the user data query 702. An output of the execution of the dataflow graph, e.g., 704a or 704b: (i) represents a result of processing the at least a portion of the computation workload and (ii) contributes to a response, e.g., response 112 (FIG. 1 A), to the user data query 702.

[0110] In an example embodiment, the selecting may be based on at least one of: (i) a respective efficiency of executing the VM instruction, e.g., 1076al-3 (FIG. 10), 1076b 1-3 (FIG. 10), 1176al-3 (FIG. 11), 1176bl-3 (FIG. 11), 1476a-n (FIG. 14), or 2076a-n (FIG. 20), at each execution resource of the set of execution resources, e.g., 762a-n, and (ii) a respective availability of each execution resource of the set of execution resources, e.g., 762a-n.

[0111] According to another example embodiment, the VM instruction, e.g., 1076al-3 (FIG. 10), 1076bl-3 (FIG. 10), 1176al-3 (FIG. 11), 1176bl-3 (FIG. 11), 1476a-n (FIG. 14), or 2076a-n (FIG. 20), may be specified in the ISA. The ISA may be compatible with at least one type of computation workload. The at least one type of computation workload may include a type of the computation workload associated with the user data query 702. The at least one type of computation workload may include a SQL query plan, a data ingestion pipeline, an artificial intelligence (Al) or machine learning (ML) workload, a high- performance computing (HPC) program, another type of computation workload, or a combination thereof, for non-limiting examples.

[0112] Further, in another example embodiment, selecting the execution resource may be based on the execution resource including an accelerator.- 21 -4212910. vlDocket No. 6214.1006001

[0113] According to an example embodiment, selecting the execution resource may be based on the execution resource including a PDU based accelerator, a GPU based accelerator, a TPC based accelerator, a TPU based accelerator, a SIMD unit based accelerator, a CPU based accelerator, another type of accelerator, or a combination thereof, for non-limiting examples.

[0114] In another example embodiment, the compute node, e.g., 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19), may be a first compute node. The system 710 may process, via the first compute node, a first data block associated with the at least a portion of the computation workload. The processing may be performed in parallel with at least one of: (i) processing, via a second compute node of the at least one compute node, e.g., 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19), a second data block associated with the at least a portion of the computation workload and (ii) transferring, via an edge of a set of edges, e.g., edge(s) 1696a-f (FIG. 16), 1796a-h (FIG. 17), 1896 (FIG. 18), or 2096al-6 and / or 2096b 1-6 (FIG. 20), the second data block. The second data block may be associated with the at least a portion of the computation workload.

[0115] In another example embodiment, consider a non-limiting example of a DFG including compute nodes N1 - N2 - N3 for processing data blocks Bl, B2, and B3, respectively. Each of the nodes Nl, N2, and N3 may process blocks in parallel with the other nodes. The blocks Bl, B2, and B3 may be processed respectively in chronological or time order. For instance, the node Nl may be a first compute node and the block B2 may be an initial data block associated with at least a portion of a computation workload, while the node N2 may be a second compute node and the block Bl may be a subsequent data block associated with the at least a portion of the computation workload. The initial data block B2 may be processed via the first compute node Nl, in parallel with the subsequent data block Bl being processed via the second compute node N2. Moreover, the first compute node Nl may have already processed the subsequent data block Bl prior to it being processed by the second compute node N2. As should be appreciated from the foregoing example, any two (or three, etc.) data blocks, e.g., Bl and B2, may be processed in parallel (e.g., via nodes N2 and Nl, respectively); however, each individual data block, e.g., Bl and B2, may be processed in time order (e.g., by node Nl followed by node N2, and so on). Continuing with reference to FIG. 7, according to an example embodiment, the stack 700 may further include a data lake, e.g., the data lake 706, 606 (FIG. 6), 306 (FIG. 3), 206 (FIG. 2), or 106 (FIG. 1A). The data- 22 -4212910. vlDocket No. 6214.1006001 lake 706 may be, e.g., a Microsoft Azure, Amazon S3, or Google Cloud Storage™ data lake, or another suitable data lake known to those of skill in the art for non-limiting examples.

[0116] In an example embodiment, the system 710 may control a flow of data blocks between at least two dataflow nodes, e.g., 1074a-d (FIG. 10), 1174a-e (FIG. 11), 1674a-f (FIG. 16), 1774a-j (FIG. 17), or 1974 (FIG. 19), of the dataflow graph, e.g., 704a or 704b. The at least two dataflow nodes may include the at least one compute node, e.g., 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19). The data blocks may be (i) associated with the at least a portion of the computation workload and (ii) derived from a data source, e.g., the data lake 706, associated with the user data query 702.

[0117] According to another example embodiment, the system 710 may perform validation of the dataflow graph, e.g., 704a or 704b. Responsive to the validation being unsuccessful, the system 710 may terminate execution of the dataflow graph, e.g., 704a or 704b. Responsive to the validation being successful, the system 710 may proceed with the execution of the dataflow graph, e.g., 704a or 704b.

[0118] Further, according to another example embodiment, the system 710 may generate a set of edges, e.g., 1696a-f (FIG. 16), 1796a-h (FIG. 17), 1896 (FIG. 18), or 2096al-6 and / or 2096bl-6 (FIG. 20), associated with the dataflow graph, e.g., 704a or 704b. Each edge of the set of edges, e.g., 1696a-f (FIG. 16), 1796a-h (FIG. 17), 1896 (FIG. 18), or 2096a 1-6 and / or 2096b 1-6 (FIG. 20), may be configured to transfer data blocks between a corresponding pair of dataflow nodes, e.g., 1074a-d (FIG. 10), 1174a-e (FIG. 11), 1674a-f (FIG. 16), 1774a-j (FIG. 17), or 1974 (FIG. 19), of the dataflow graph, e.g., 704a or 704b. The dataflow nodes, e.g., 1074a-d (FIG. 10), 1174a-e (FIG. 11), 1674a-f (FIG. 16), 1774a-j (FIG. 17), or 1974 (FIG. 19), may include the at least one compute node, e.g., 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19). The generating may include configuring an edge of the set of edges, e.g., 1696a-f (FIG. 16), 1796a-h (FIG. 17), 1896 (FIG. 18), or 2096al -6 and / or 2096b 1-6 (FIG. 20), to transfer the data blocks using a FIFO queue. The system 710 may configure, based on a user input, a size of the FIFO queue. The generating may include configuring an edge of the set of edges, e.g., 1696a-f (FIG. 16), 1796a-h (FIG. 17), 1896 (FIG. 18), or 2096al-6 and / or 2096b 1-6 (FIG. 20), to synchronize a first processing speed of a first compute node of the at least one compute node, e.g., 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19), with a second processing speed of a second compute node of the at least one compute node, e.g., 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19).4212910. vlDocket No. 6214.1006001

[0119] According to an example embodiment, the executing may include performing at least one of: an input control function, a flow control function, a register control function, an output control function, a reduce function, a map function, a load function, and a generate function, for non-limiting examples.

[0120] In another example embodiment, the executing may include executing the VM instruction, e.g, 1076al-3 (FIG. 10), 1076bl-3 (FIG. 10), 1176al-3 (FIG. 11), 1176bl-3 (FIG. 11), 1476a-n (FIG. 14), or 2076a-n (FIG. 20), via a software-based execution unit, e.g., 762a, a hardware-based execution unit, e.g., 762b or 762n, or a combination thereof.

[0121] Further with reference to FIG. 7, according to another example embodiment, the dataflow graph, e.g., 704a or 704b, may include at least one input node, e.g., input node 1074a (FIG. 10), 1174a-b (FIG. 11), 1674a (FIG. 16), or 1774a-b (FIG. 17). The system 710 may obtain, based on an input node of the at least one input node, e.g., 1074a (FIG. 10), 1174a-b (FIG. 11), 1674a (FIG.16), or 1774a-b (FIG. 17), at least one data block from a data source, e.g., 706, associated with the user data query 702. The obtaining may include implementing a read protocol corresponding to the data source.

[0122] In an example embodiment, the dataflow graph, e.g., 704a or 704b, may include at least one output node, e.g., output node 1074d (FIG. 10), 1174e (FIG. 11), 1674e-f (FIG. 16), or 1774i-j (FIG. 17). The system 710 may store, based on an output node of the at least one output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j of FIGS. 10, 11, 16, and 17, respectively, at least one data block to a datastore, e.g., 706 of FIG. 7. The storing may include implementing a write protocol corresponding to the datastore.

[0123] According to another example embodiment and with reference to FIGS. 7, 10, 11, 14, and 16-20, the system 710 may spawn at least one task corresponding to at least one of: (i) the at least one compute node, e.g., 1674b-d, 1774c-h, or 1974, (ii) at least one input node, e.g., 1074a, 1174a-b, 1674a, or 1774a-b, of the dataflow graph, e.g., 704a or 704b, (iii) at least one output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j , of the dataflow graph, e.g., 704a or 704b, and (iv) at least one edge, e.g., 1696a-f, 1796a-h, 1896, 2096al-6, or 2096b 1-6, associated with the dataflow graph, e.g., 704a or 704b. A task of the at least one task spawned may include a thread corresponding to the compute node, e.g., 1674b-d, 1774c-h, or 1974. The system 710 may execute the set of VM instructions, e.g., 1076al-3, 1076bl-3, 1176al-3, 1176b 1 -3 , 1476a-n, or 2076a-n, via the thread. The system 710 may monitor execution of a task of the at least one task spawned.- 24 -4212910. vlDocket No. 6214.1006001

[0124] Further, according to another example embodiment, the system 710 may adapt the set of VM instructions, e.g., 1076al-3, 1076bl-3, 1176al-3, 1176bl-3, 1476a-n, or 2076a-n, based on at least one statistic associated with the at least a portion of the computation workload. A statistic of the least one statistic may include a runtime statistical distribution of data values in a data source, e.g., 706, associated with the user data query 702. The adapting may be responsive to identifying a mismatch between the runtime statistical distribution of the data values and an estimated statistical distribution of the data values. The adapting may include at least one of: (i) reordering at least two VM instructions of the set of VM instructions, e.g., 1076al-3, 1076bl-3, 1176al-3, 1176bl-3, 1476a-n, or 2076a-n, (ii) removing at least one VM instruction from the set of VM instructions, e.g., 1076al-3, 1076bl-3, 1176al-3, 1176bl-3, 1476a-n, or 2076a-n, (iii) adding at least one VM instruction to the set of VM instructions, e.g., 1076al-3, 1076bl-3, 1176al-3, 1176bl-3, 1476a-n, or 2076a-n, and (iv) modifying at least one VM instruction of the set of VM instructions, e.g., 1076al-3, 1076bl-3, 1176al-3, 1176bl-3, 1476a-n, or 2076a-n.

[0125] According to an example embodiment, the system 710 may generate, based on the dataflow graph, e.g., 704a or 704b, a plurality of dataflow subgraphs. The method may further comprise configuring at least two dataflow subgraphs of the plurality of dataflow subgraphs to, when executed via the VM, e.g., 130, perform a data movement operation, in parallel. The VM, e.g., 130, may be a first VM. The data movement operation may include at least one of: (i) streaming data from a data source, e.g., 706, associated with the user data query 702 and (ii) transferring data to or from a second VM.

[0126] Continuing with reference to FIG. 7, according to an example embodiment, the disaggregated data analytics stack 700 may provide one or more benefits, such as improved efficiency and agility, among other examples for non-limiting examples. The disaggregated data analytics stack 700 may further supply an end-to-end framework to express general- purpose computations on Big Data (e.g., datasets that are too large and / or complex to be analyzed using conventional approaches).

[0127] FIG. 8 is a block diagram of an example embodiment of a third phase 800 of a data analytics pipeline. According to an example embodiment, the third phase 800 may be implemented by a computer-based system, e.g., system 110 (FIG. 1 A) or 710 (FIG. 7). In an example embodiment, the system may receive a DFG, e.g., DFG 104 (FIG. 1 A), 604 (FIG. 6), or 704a-b (FIG. 7). According to another example embodiment, after the optional validation 842 of the received DFG, the second phase 800 may include laying out 854 the- 25 -4212910. vlDocket No. 6214.1006001DFG in memory, creating FIFO queue(s), and / or connecting edges between nodes of the DFG. In turn, according to another example embodiment, the second phase 800 may include launching a VM interpreter 858 for each compute node of the DFG. Further, in an example embodiment, as part of the second phase 800, input nodes of the DFG may start fetching data and feeding it into the DFG and output nodes of the DFG may start pulling data from the DFG and pushing it to external sinks. According to another example embodiment, compute nodes of the DFG may start interpreting their code and using a PDU to execute data blocks fed into them. In yet another example embodiment, second phase 800 may also include event scheduling 864 and PDU scheduling 866. According to an embodiment, as part of the event scheduling 864, a task (e.g., a process / subprocess or thread) may be spawned for each edge and node in the DFG. In another example embodiment, nodes in the DFG may be assigned various task priorities for non-limiting example. For instance, according to yet another example embodiment, VO tasks may need a higher priority than other tasks, e.g., because network bandwidth may be a scarce resource and keeping the network bandwidth utilized or busy may be a high priority, for non-limiting example. In an example embodiment, the event scheduling module 864 may manage such tasks and / or assign VM execution resources (e.g., CPU resources) to tasks depending on the tasks’ priorities and / or activities, for non-limiting examples.

[0128] FIG. 9 is a flow diagram of an example embodiment of a process 900 for a hardware-agnostic domain-specific VM. The process 900 may be performed by a computer- based system according to example embodiments, e.g., computer-based system 910 or 110 (FIG. 1 A). With reference to FIG. 9, in an example embodiment, the computer-based system 910 may employ a runtime interpreter, e.g., VM interpreter 858 (FIG. 8), to execute computation(s) expressed as DFG(s) 904a-c generated by a distributed compiler, e.g., distributed compiler 120 (FIG. IB), 220 (FIG. 2), 520 (FIG. 5), 620 (FIG. 6), or 720 (FIG. 7). Moreover, the process 900 is a non-limiting example of extensive parallelism and streaming of data. Further, in another example embodiment, the process 900 may leverage existing cloud infrastructure for execution unit(s), e.g., SoftPDU 962a. FPGA PDU 962b, and / or GPU 962n, etc.; additional non-limiting examples of PDU execution units are provided hereinbelow in relation to FIG. 10. According to ab example embodiment, the computer- based system 910 may optionally execute one or more adaptive query optimization(s). In yet another example embodiment, the computer-based system 910 may schedule specific- 26 -4212910. vlDocket No. 6214.1006001 computation(s) of the DFG(s) 904a-c to the appropriate computing element, e.g., the SoftPDU 962a. FPGA PDU 962b, and / or GPU 962n.

[0129] FIG. 10 is a block diagram of an example embodiment of mapping machine code of a DFG 1004 to a PDU 1040. In the example embodiment of FIG. 10, the DFG 1004 includes dataflow nodes 1074a-d. In turn, the dataflow node 1074b (e.g., a filtering node) of the DFG 1004 may include the machine code instructions 1076al-3; likewise, the dataflow node 1074c (e.g., a projection node) of the DFG 1004 may include the machine code instructions 1076b 1-3 for non-limiting examples. According to an example embodiment, the machine code instruction 1076a3 (e.g., an evaluate instruction) of the dataflow node 1074b may be mapped to a vector unit 1078a of the PDU 1040, which may also include a scanner unit 1078b, parser unit 1078c, crypter unit 1078d, mover unit 1078e, hasher unit 1078f, and compressor unit 1078g, for non-limiting examples. Similarly, in another example embodiment, the machine code instruction 1076b3 (e.g., a projection instruction) of the dataflow node 1074c may be mapped to the mover unit 1078e of the PDU 1040.

[0130] FIG. 11 is a block diagram of another example embodiment of mapping machine code of a DFG 1104 to a PDU 1140. In the example embodiment of FIG. 11, the DFG 1104 includes dataflow nodes 1174a-e. In turn, the dataflow node 1174c (e.g., a filtering node) of the DFG 1104 may include the machine code instructions 1176al-3; likewise, the dataflow node 1174d (e.g., a join node) of the DFG 1104 may include the machine code instructions 1176b 1-3 for non-limiting examples. According to an example embodiment, the machine code instruction 1176a3 (e.g., an evaluate instruction) of the dataflow node 1174c may be mapped to a vector unit 1178a of the PDU 1140, which may also include a scanner unit 1178b, parser unit 1178c, crypter unit 1178d, mover unit 1178e, hasher unit 1178f, and compressor unit 1178g, for non-limiting examples. Similarly, in another example embodiment, the machine code instruction 1176b 3 (e.g., a join instruction) of the dataflow node 1174d may be mapped to the hasher unit 1178f of the PDU 1140.

[0131] FIG. 12 is a block diagram of an example embodiment of an architecture 1200 for a computer-based system disclosed herein. With reference to FIG. 12, the architecture 1200 includes a micro-service 1268, computer-based system 1210, and infrastructure system 1272. In an example embodiment, the micro-service 1268 may provide an API endpoint for the computer-based system 1210, such as a Hypertext Transfer Protocol (HTTP) or GraphQL endpoint for non-limiting examples. Other endpoint types known to those of skill in the art are also suitable.- 27 -4212910. vlDocket No. 6214.1006001

[0132] According to an example embodiment, the computer-based system 1210 may include a DFG executor, e.g., the VM 130 (FIG. 1 A), that, for instance, lays out DFG(s), e.g., DFG(s) 104 (FIG. 1A), 604 (FIG. 6), 704a-b (FIG. 7), or 904a-c (FIG. 9). The DFG executor, e.g., 130, may also spawn and monitor tasks (e.g., processes / subprocesses or threads). Further, in an example embodiment, the computer-based system 1210 may interpret compute nodes, including, for instance, via a hardware PDU, e.g., executor 140 (FIG. 1 A), 240 (FIG. 2), 540 (FIG. 5), or 640 (FIG. 6). To continue, according to an example embodiment, the infrastructure system 1272 may provide features and functionality, such as high-performance network protocol stacks (e.g., TLS (transport layer security ) / HTTP), which may include, for instance, zero copy, high performance storage access, and a high-performance task scheduler, which may, for instance, be Quality of Service (QoS) controlled for non-limiting example.

[0133] FIG. 13 is a block diagram of an example prior art CPU 1388 in operation. As shown in FIG. 13, the prior art CPU 1388 includes an ALU 1382 and a control unit 1386. The ALU 1382 of prior art CPU 1388 may execute instructions in an ALU-centric ISA, e.g., prior art ALU instructions 1384a-n. According to existing approaches, VM instructions, e.g, instructions 1384a-n, are ALU centric, which makes it easy for JIT compilers to generate code for CPUs, e.g, prior at CPU 1388, where an ALU, e.g., prior art ALU 1382, is the workhorse.

[0134] FIG. 14 is a block diagram of an example embodiment of a PDU 1440 in operation. As shown in FIG. 14, according to an example embodiment, the PDU 1440 includes a control unit 1421 and accelerator units 1478a (e.g., a scanner unit), 1478b (e.g., a parser unit), 1478c (e.g., a mover unit), and 1478n (e.g., a vector processing unit). In another example embodiment, accelerator units 1478a-n may be hardware-based units. According to an example embodiment, compute nodes may be programmable using an instruction set that is accelerator-centric, e.g., with instructions 1476a-n, 1176al-3 (FIG. 11), 1176bl-3 (FIG. 11), 1076al-3 (FIG. 10), or 1076bl-3 (FIG. 10). Unlike existing approaches, such as using the prior art CPU 1388 and prior art ALU-centric instructions 1384a-n of FIG. 13, an ISA according to an example embodiment may be designed to be accelerator-centric instead, thus, enabling efficient implementation of an accelerator unit, e.g., 1478a-n, for a given function in an instruction, e.g., 1476a-n. An ISA according to an example embodiment may be extensible and evolve as workload requirements change over time.

[0135] FIG. 15 is a block diagram of an example prior art control flow process 1500 for a prior art CPU 1588. As shown in FIG. 15, the prior art process 1500 may include execution- 28 -4212910. vlDocket No. 6214.1006001 threads 1592a and 1592b which, in turn, may include sequences of statement blocks 1594al- 4 and 1594bl-4, respectively, for potential execution by the prior art CPU 1588. According to conventional approaches, the prior art control flow process 1500 may define an explicit order or sequence in which statements, e.g., blocks 1594al-4 and 1594b 1-4, are executed or evaluated. For example, the prior art thread 1592a may follow a predefined sequence of executing block 1594al or 1594a2, followed by executing blocks 1594a3 and 1594a4; likewise, the prior art thread 1592b may follow a predefined sequence of executing block 1594b 1 or 1594b2, followed by executing blocks 1594b3 and 1594b4. With existing techniques, data may follow the flow of the prior art process 1500, but the handling of data is secondary to and follows the expressly defined order of execution flow in the prior art process 1500.

[0136] FIG. 16 is a block diagram of an example embodiment of a dataflow process 1600 for a PDU 1640. According to the example embodiment of FIG. 16, the dataflow process 1600 may employ DFG 1604 having input node 1674a, compute nodes 1674b-d, and output nodes 1674e-f, which dataflow nodes 1674a-f may be connected variously by edges 1696a-f. In another example embodiment, the input node 1674a may push data into the DFG 1604 while the output nodes 1674e-f may pull data from the DFG 1604. Further, according to yet another example embodiment, the compute nodes 1674b-d may perform transformations or computations on data, which may flow along the edges 1696a-f. Unlike existing approaches, such as the prior art control flow process 1500 of FIG. 15, in an example embodiment, the dataflow process 1600 of FIG. 16 may abstract over explicit control flow by prioritizing routing and transformation of data, e.g., via the dataflow nodes 1674a-f and connecting edges 1696a-f. According to another example embodiment, in the dataflow process 1600, control may follow data and computations may be executed implicitly based on data availability.

[0137] Dataflow Graph (DFG)

[0138] FIG. 17 is a block diagram of an example embodiment of a DFG 1704. According to the example embodiment of FIG. 17, the DFG 1704 includes dataflow nodes 1774a-j and edges 1796a-h. In another example embodiment, the nodes 1774a-j may perform operations (i.e., on data) and the edges 1796a-h may carry data across the nodes 1774a-j. Further, in another example embodiment, the edges 1796a-h may move data as stream(s) of data block(s) (not shown). In an example embodiment, all data blocks may be immutable and shared by multiple nodes, e.g., nodes 1774a-j, using reference counts. According to another example embodiment, there may be three different kinds of nodes: input nodes (e.g., 1774a-b), output- 29 -4212910. vlDocket No. 6214.1006001 nodes (e.g., 1774i-j), and compute nodes (e.g., 1774c-h) for non-limiting example. Further, in another example embodiment, input nodes, e.g, 1774a-b, may act as data-sources and output nodes, e.g, 1774i-j , may act as data-sinks. In an example embodiment, input nodes, e.g., 1774a-b, may pull data from local or external sources (not shown) and push the data into a DFG, e.g., 1704. According to another example embodiment, output nodes, e.g., 1774i-j , may pull data from a DFG, e.g., 1704, and push the data to local or external sinks (not shown). Further, in yet another example embodiment, compute nodes, e.g., 1774c-h, may perform various transformations on data such as filtering, groupingjoining, etc., for non-limiting examples, using hardware accelerators on a PDU (not shown). In an example embodiment, a task (e.g., a process / subprocess or thread) may be spawned for each node 1774a-j and edge 1796a-h. According to another example embodiment, each such task may run or execute in parallel.

[0139] Edge

[0140] FIG. 18 is a block diagram of an example embodiment of a logical structure of an edge 1896. As shown in FIG. 18, according to an example embodiment, the edge 1896, which may be included in a DFG, e.g., DFG 104 (FIG. 1 A), 604 (FIG. 6), 704a-b (FIG. 7), 904a-c (FIG. 9), 1004 (FIG. 10), 1104 (FIG. 11), 1604 (FIG. 16), or 1804 (FIG. 17), may be a task (e.g., a process / subprocess or thread) that pulls data block(s) from an input source node, e.g., input node 1074a (FIG. 10), 1174a-b (FIG. 11), 1674a (FIG. 16), or 1774a-b (FIG. 17), and pushes data into output destination node(s), e.g., output node(s) 1074d (FIG. 10), 1174e (FIG. 11), 1674e-f (FIG. 16), or 1774i-j (FIG. 17). With reference to FIGS. 10, 11, and 16-18, in another example embodiment, the edge 1896 may have a single source input node, e.g., 1074a, 1174a-b, 1674a, or 1774a-b, and can have one or more destination output node(s), e.g., 1074d, 1174e, 1674e-f, or 1774i-j . According to yet another example embodiment, the edge 1896 may have FIFO queue(s) 1898a-c in front of its destination(s) (i.e., endpoint(s) of the edge 1896), which may allow for burst-type processing by compute node(s), e.g., compute node(s) 1074b-c (FIG. 10), 1174c-d (FIG. 11), 1674b-d (FIG. 16), or 1774c-h (FIG. 17). In an example embodiment, FIFO queue(s) 1898a-c may be sized, programmably.According to another example embodiment, the FIFO queue(s) 1898a-c may also help in flow control, for instance, if a FIFO, e.g., 1898a, 1898b, or 1898c, in front of a particular destination node, e.g., the compute node 1074b-c, 1174c-d, 1674b-d, or 1774c-h, is full, then the edge task 1896 may stall until that node makes space in its FIFO. Further, in yet another4212910. vlDocket No. 6214.1006001 example embodiment, all data block(s) moving across the edge 1896 may have the same data type.

[0141] Input Node

[0142] In an example embodiment, an input node, e.g., input node 1074a (FIG. 10), 1174a-b (FIG. 11), 1674a (FIG. 16), or 1774a-b (FIG. 17), may pull data from local or external source(s), e.g., data source 106 (FIG. 1A), 206 (FIG. 2), 306 (FIG. 3), 506 (FIG. 5), 606 (FIG. 6), or 706 (FIG. 7), and push the data into a DFG, e.g, DFG 104 (FIG. 1 A), 604 (FIG. 6), 704a-b (FIG. 7), 904a-c (FIG. 9), 1004 (FIG. 10), 1104 (FIG. 11), 1604 (FIG. 16), or 1804 (FIG. 17), for processing. According to another example embodiment, an input node, e.g, 1074a, 1174a-b, 1674a, or 1774a-b, may have an in-degree of zero and an out-degree of n, where 1 < n < 256 for non-limiting example. Further, in another example embodiment, external sources can be, for instance, databases, key-value stores, or distributed filesystems, etc., such as PostgreSQL, MySQL®, Amazon S3, RocksDB, Redis®, Apache HDFS (Hadoop® Distributed File System) for non-limiting examples, or any other suitable known storage system. With reference to FIGS. 10, 11, 16, and 17, in an example embodiment, an input node, e.g., 1074a, 1174a-b, 1674a, or 1774a-b, can also parse incoming data and extract only necessary fields from it. For instance, according to another example embodiment, an input node, e.g., 1074a, 1174a-b, 1674a, or 1774a-b, can parse data in formats such as JSON (JavaScript Object Notation), Apache Parquet®, or any other suitable known format, and extract only the useful columns from it. In yet another example embodiment, a user may provide configuration parameter(s) for an input node, e.g., 1074a, 1174a-b, 1674a, or 1774a- b, including a location configuration parameter and / or a schema configuration parameter, as described hereinbelow for non-limiting examples.

[0143] Location

[0144] With reference to FIGS. 10, 11, 16, and 17, according to an example embodiment, a location configuration parameter may specify for an input node, e.g., 1074a, 1174a-b, 1674a, or 1774a-b, where to fetch data from and / or what protocol to use. Table 1 below lists non-limiting example input data locations and corresponding parameters, if any, for each location, according to an example embodiment. In another example embodiment, if a “full_path” parameter refers to or includes a directory tree that, in turn, contains multiple subdirectories, then an accompanying “partition” parameter may be used to identify parts of the directory tree for processing. By way of non-limiting example, a naming convention for- 31 -4212910. vlDocket No. 6214.1006001 subdirectories may use months of the year, e.g., “Jan”, “Feb”, “Mar”, etc., or any other suitable naming convention.Table 1 : Example supported input data sources

[0145] Schema

[0146] In an example embodiment, a schema configuration parameter may specify for an input node, e.g., 1074a, 1174a-b, 1674a, or 1774a-b, how to parse input data and / or what fields to extract from the data. Table 2 below lists non-limiting example schema configuration parameters according to an example embodiment.- 32 -4212910. vlDocket No. 6214.1006001Table 2: Example schema parameters

[0147] Output Node

[0148] According to an example embodiment, an output node, e.g., output node 1074d (FIG. 10), 1174e (FIG. 11), 1674e-f (FIG. 16), or 1774i-j (FIG. 17), may perform the inverse operation of an input node, i.e., pull data from a DFG, e.g., DFG 104 (FIG. 1A), 604 (FIG. 6), 704a-b (FIG. 7), 904a-c (FIG. 9), 1004 (FIG. 10), 1104 (FIG. 11), 1604 (FIG. 16), or 1804 (FIG. 17), and push the data to local or external sinks, e.g., data source 106 (FIG. 1A), 206 (FIG. 2), 306 (FIG. 3), 506 (FIG. 5), 606 (FIG. 6), or 706 (FIG. 7). With reference to FIGS. 10, 11, 16, and 17, in another example embodiment, an output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j , may have an in-degree of n, where 1 < n < 256 for non-limiting example, and an out-degree of zero. Further, in yet another example embodiment, external sinks can be, for instance, databases, key-value stores, or distributed filesystems, etc., such as PostgreSQL, MySQL, Amazon S3, RocksDB, Redis, Apache HDFS, or any other suitable known storage system. In an example embodiment, an output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j , can also prepare certain types of files in formats such as JSON, Apache Parquet, or any other suitable known format, before pushing to external sinks. According to another example embodiment, a user may provide configuration parameter(s) for an output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j, including, for instance, a location configuration parameter and / or a schema configuration parameter, as described hereinbelow for nonlimiting examples.

[0149] Location- 33 -4212910. vlDocket No. 6214.1006001

[0150] In an example embodiment, a location configuration parameter may specify for an output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j , where to push data and / or what protocol to use. According to another example embodiment, locations supported by input nodes, such as described hereinabove in relation to Table 1 for non-limiting examples, may also be supported by output nodes, e.g., 1074d, 1174e, 1674e-f, or 1774i-j.

[0151] Schema

[0152] According to an example embodiment, a schema configuration parameter may specify for an output node, e.g., 1074d, 1174e, 1674e-f, or 1774i-j , how to convert data from a DFG, e.g., 104, 604, 704a-b, 904a-c, 1004, 1104, 1604, or 1804, before sending it to an external sink, e.g., 106, 206, 306, 506, 606, or 706. In another example embodiment, a schema format for output nodes may be the same as for input nodes, such as described hereinabove in relation to Table 2 for non-limiting examples.

[0153] Compute Node

[0154] FIG. 19 is a block diagram of an example embodiment of a compute node 1974. According to an example embodiment, the compute node 1974, may perform transformations on incoming data block(s) (not shown) and output the transformed data block(s). In another example embodiment, the compute node 1974 can accept input from input nodes (not shown) or other compute nodes (not shown) and send results to other compute nodes (not shown) or output nodes (not shown). As shown in FIG. 19, in another example embodiment, the compute node 1974 may have an in-degree of m, where 1 < m < 256 for non-limiting example, and an out-degree of n, where 1 < n < 256 for non-limiting example. According to yet an example embodiment, the compute node 1974 may be programmable, and users can program the compute node 1974 to compute any general-purpose data transformation(s).

[0155] FIG. 20 is a block diagram of an example embodiment of an execution environment 2000 for a compute node, e.g., compute node 1074b-c (FIG. 10), 1174c-d (FIG. 11), 1674b-d (FIG. 16), 1774c-h (FIG. 17), or 1974 (FIG. 19). In an example embodiment, as shown in FIG. 20, the execution environment 2000 may include an input panel 2001, an output panel 2003, a register file 2005, code memory 2007, accelerator(s) or compute unit(s) 2078a, 2078b, 2078c, 2078d, 2078e (e.g., a hasher unit), and 2078n (e.g., a decompressor unit), and a control unit (not shown). According to another example embodiment, the compute unit(s) 2078a-n may be included by a PDU, e.g., execution resource 140 (FIG. 1 A), 240 (FIG. 2), 540 (FIG. 5), 640 (FIG. 6), 1040 (FIG. 10), 1140 (FIG. 11), or 1440 (FIG. 14). Further, in yet another example embodiment, a runtime interpreter, e.g., VM interpreter 858- 34 -4212910. vlDocket No. 6214.1006001(FIG. 8), may use accelerator(s), e.g., 2078a-n (FIG. 20), to accelerate data processing. Continuing with reference to FIG. 20, according to an example embodiment, data may move in the execution environment 2000 in four directions: (i) from the input panel 2001 to the output panel 2003 (as indicated by arrow 2009a), (ii) from the input panel 2001 to the register file 2005 (as indicated by arrow 2009b), (iii) from the register file 2005 to the register file 2005 (as indicated by arrow 2009c), or (iv) from the register file 2005 to the output panel 2003 (as indicated by arrow 2009d).

[0156] Input Panel

[0157] Continuing with reference to FIG. 20, in another example embodiment, the input panel 2001 may manage the data coming from input edge(s), e.g., 2096a 1-6 for non-limiting examples. According to yet another example embodiment, the input panel 2001 may, among other things, control data block queueing, detect an end of stream (eos), etc., for non-limiting examples.

[0158] Output Panel

[0159] Continuing with reference to FIG. 20, in an example embodiment, the output panel 2003 may manage data going out from the compute node, such as via output edge(s), e.g., 2096b 1-6 for non-limiting examples. According to another example embodiment, the output panel 2003 may, among other things, control data block queueing, send an eos, etc., for non-limiting examples.

[0160] Resister File

[0161] Continuing with reference to FIG. 20, in yet another example embodiment, the register file 2005 may be used to store a context of the compute node, e.g., temporary results during processing of data blocks. According to an example embodiment, the register file 2005 may include 256 registers, e.g., registers 201 la-n, and each register may be 64-bit wide, for non-limiting examples. However, any suitable number of registers may be used, and registers may be of any suitable size. In another example embodiment, each register content may have a type 2013 associated with it. Table 3 below lists non-limiting example predefined registers and their content.Table 3: Example predefined registers- 35 -4212910. vlDocket No. 6214.1006001

[0162] Table 4 below shows a non-limiting example definition of the FLAGS register.Table 4: Example FLAGS register definition

[0163] According to yet another example embodiment, the LESSER, EQUAL, and / or GREATER bits may be set during a compare instruction.

[0164] Code

[0165] Continuing with reference to FIG. 20, in an example embodiment, the code memory 2007 may include VM instructions 2076a-n to be executed as part of performing the compute node’s function. According to another example embodiment, the code memory 2007 may be arbitrarily long, limited only by available memory. Further, in yet another example embodiment, the code memory 2007 may be divided into three non-limiting example sections as given below in Table 5.

[0166] Instruction Set Architecture (ISA)

[0167] Continuing with reference to FIG. 20, in an example embodiment, the compute node programs may be written using an accelerator-centric ISA, which may include control flow, map, reduce, generate instructions, etc., for non-limiting examples. According to another example embodiment, compute-intensive map, reduce and / or generate instructions may be implemented either on a PDU, e.g., execution resource 140 (FIG. 1 A), 240 (FIG. 2), 540 (FIG. 5), 640 (FIG. 6), 1040 (FIG. 10), 1140 (FIG. 11), or 1440 (FIG. 14), or in software using vector processing accelerators such Intel® AVX (Advanced Vector Extensions)-512, GPUs, e.g., 762n (FIG. 7) or 962n (FIG. 9), or any other suitable known accelerator. Further, in yet another example embodiment and with reference to FIG. 20, program branches may be relative to the program counter (PC) 2015 and can be forward branches and / or backward branches.

[0168] Instruction Categories

[0169] Continuing with reference to FIG. 20, in an example embodiment, the VM instructions 2076a-n may be categorized based on the type of control and / or movement of data within the compute node. According to another example embodiment, this may help the- 36 -4212910. vlDocket No. 6214.1006001VM interpreter 858 in improving instruction-level parallelism where possible. Table 6 below lists non-limiting example supported instruction categories.Table 6: Example instruction categories

[0170] FIG. 21 is a flow diagram of an example embodiment of a computer-implemented method 2100. The method begins (2102) and comprises selecting an execution resource from a set of execution resources of a virtual machine (VM), the execution resource for executing a VM instruction (2104). The method further comprises transforming the VM instruction into machine code for the execution resource selected (2106). The method further comprises executing the machine code via the execution resource selected (2108). The executing 2108 furthers execution by the VM of a dataflow graph that includes at least one compute node. A compute node of the at least one compute node has a set of VM instructions including the VM instruction. The dataflow graph corresponds to at least a portion of a computation workload associated with a user data query. An output of the execution of the dataflow graph: (i) represents a result of processing the at least a portion of the computation workload and (ii)- 37 -4212910. vlDocket No. 6214.1006001 contributes to a response to the user data query. The method thereafter ends (2110) in the example embodiment.

[0171] FIG. 22 is a flow diagram of another example embodiment of a computer- implemented method 2200. The method begins (2202) and comprises selecting an execution resource from a set of execution resources of a virtual machine (VM), the selecting performed as part of executing a compute node of at least one compute node of a dataflow graph being executed by the VM, the compute node including at least one VM instruction, the selecting performed on an instruction-by-instruction basis (2204). The method further comprises performing, at the compute node on the instruction-by-instruction basis, just-in- time compilation of a VM instruction of the at least one VM instruction, the performing transforming the VM instruction to machine code executable by the execution resource selected (2206). The method further comprises executing the machine code by the execution resource selected, the dataflow graph corresponding to at least a portion of a computation workload associated with a user data query, the executing advancing the compute node toward producing a result, the result contributing to production of a response to the user data query (2208). The method thereafter ends (2210) in the example embodiment.

[0172] FIG. 23 is a block diagram of an example embodiment of an internal structure of a computer 2300 in which various embodiments of the present disclosure may be implemented. The computer 2300 contains a system bus 2352, where a bus is a set of hardware lines used for data transfer among the components of a computer or digital processing system. The system bus 2352 is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input / output ports, network ports, etc.) that enables the transfer of information between the elements. Coupled to the system bus 2352 is an I / O device interface 2354 for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer 2300. A network interface 2356 allows the computer 2300 to connect to various other devices attached to a network (e.g., global computer network, wide area network, local area network, etc.). Memory 2358 provides volatile or non-volatile storage for computer software instructions 2360 and data 2362 that may be used to implement embodiments (e.g., the method 2200, method 2100, execution environment 2000, compute node 1974, edge 1896, dataflow process 1600, PDU 1440, architecture 1200, process 900, third phase 800, data analytics stack 700, process 600, server 580, server 470, platform 360, system 200, cluster 100, and computer- based system 110, etc.) of the present disclosure, where the volatile and non-volatile- 38 -4212910. vlDocket No. 6214.1006001 memories are examples of non-transitory media. Disk storage 2364 provides non-volatile storage for computer software instructions 2360 and data 2362 that may be used to implement embodiments (e.g., methods 2100, 2200, 3000, 3110, and 3200, execution environment 2000, compute node 1974, edge 1896, dataflow process 1600, PDU 1440, architecture 1200, process 900, third phase 800, data analytics stack 700, process 600, server 580, server 470, platform 360, system 200, cluster 100, and computer-based system (110, 2710), etc.) of the present disclosure. A central processor unit 2366 is also coupled to the system bus 2352 and provides for the execution of computer instructions.

[0173] An example embodiment disclosed herein enables selection of a processing (compute) element, such as a central processing unit (CPU), field-programmable gate array (FPGA), graphics programming unit (GPU), or other processing element (execution resource) for non-limiting examples, to execute an operation, such as a hash operationjoin operation, scan operation, filter operation, parquet decoder operation, or other operation for non-limiting examples. Such an operation, performed by a processing element, may be referred to interchangeably herein as an operator. Selection of the processing element may be based on at least one criteria that may be based on compute efficiency, cost of data movement, or other criteria for non-limiting examples. A decision for which processing element to select may be performed dynamically, during runtime, that is, during an execution mode (runtime stage) of a computer-based system used as a data analytics platform, such as disclosed further below.

[0174] As disclosed above, a VM platform, referred to interchangeably herein as “Insight” or a computer-based system, accelerates data analytics workloads, and such acceleration may be enabled by, among other things, processing elements, such as disclosed above and as disclosed below with regard to FIG. 24. Compute nodes may perform various transformations on data, such as filtering, groupingjoining, etc., for non-limiting examples, and may use hardware accelerators on a PDU.

[0175] FIG. 24 is a block-diagram of an example embodiment of a high-level flow 2400 of a data analytics compute plane of a data analytics platform, such as disclosed above. In such a compute plane, a user query 2402, also referred to interchangeably herein as an intent, may be expressed in SQL (structured query language), Python, or other programming language for non-limiting examples. A logical plan 2404 may be created from the user query 2402 and the logical plan 2404 may be converted / translated / compiled into at least one distributed physical plan 2406. The at least one distributed physical plan 2406 may, in turn, be transformed into at least one DFG 2408, generated for execution by at least one worker- 39 -4212910. vlDocket No. 6214.1006001 node, such as the at least one processing element 2412 of the at least one VN 2410, as disclosed above. A processing element of the at least one processing element 2412 may be referred to interchangeably herein as a compute element (component), worker node, or execution resource. An example embodiment may select a processing element of the at least one processing element 2412 based one at least one criteria. The selecting may be based on a respective efficiency of executing a VM instruction at each execution resource of the set of execution resources, as disclosed above. Such respective efficiency may be a compute efficiency, as disclosed further below.

[0176] For non-limiting example, a respective set of at least one processing element for a VM may be different for different VMs of the at least one VM 2410. The respective set may include a CPU 2414, FPGA 2416, GPU 2418, other processing element, or any combination thereof for non-limiting examples. A VM of the at least one VM 2410 may, at runtime, map machine code of a DFG to a target processing element, such as a CPU, FPGA, GPU, or other processing element of the VM. Such machine code may correspond to an operator that represents an operation, such as a hash operationjoin operation, parquet decoder operation, filter operation, or other operation for non-limiting examples. An example embodiment disclosed herein enables, on an operator-by-operator-basis, selection of a processing element of a respective set of at least one processing element of a VM of the at least one VM 2410 to perform the operation represented by the operator. The operator may be an operator of a node of a DFG transmitted to the VM for execution.

[0177] Such decision making, that is selection of a processing element on an operator-by- operator basis, may be performed during a runtime (execution) mode and may be influenced at various stages of the control plane, such as a generation stage 2420 of the at least one distributed physical plan 2406, or an execution stage 2422 of a VM of the least one VM 2410. The VM may run on a host machine, that is a physical machine, such as a server for non-limiting example. An example embodiment may perform the decision making based on at least one criteria associated with implementation of the operator.

[0178] According to an example embodiment, the at least one criteria may include compute efficiency associated with implementation of the operator at a processing element. Compute efficiency may be represented as a computational cost for implementing the operator at a processing element, such as a total amount of time or a total number of compute cycles used by a processing element for implementing the operator for non-limiting examples. The processing element selected for implementing the operator may be a- 40 -4212910. vlDocket No. 6214.1006001 processing element of the at least one processing element 2412 that is considered to be best suited, relative to other processing elements of the at least one processing element 2412, for implementing the operator based on the at least one criteria.

[0179] For example, the processing element selected may be processing element of a set of respective processing elements of a virtual machine wherein the processing element selected is associated with a highest compute efficiency for implementing the operator relative to other processing elements of the respective set. The highest compute efficiency may be determined based on a comparison of respective computational cost associated with each processing element for implementing the operator. The processing element selected may be associated with a lowest computational cost for such implementation. The operator may, in turn, be implemented by the processing element selected. Such implementation may be performed to produce a result toward generating a response to the user query, as disclosed above. According to another example embodiment, the at least one criteria may include a cost of data movement, such as disclosed below with regard to FIG. 25.

[0180] FIG. 25 is a block diagram of an example embodiment of a host machine that may be configured to host a VM, such as a VM of the at least one VM 2410 disclosed above with regard to FIG. 24. With reference to FIG. 25, the host machine 2530 is coupled to a network 2532 and includes a host CPU 2534 that is coupled to a plurality of processing of processing elements (processing elemento, . . ., processing elementN). The host CPU 2534 is coupled to a processing element of the plurality of processing of processing elements via a respective bus (2536a, 2536b), such as a Peripheral Component Interconnect Express (PCIe®) bus for nonlimiting example.

[0181] The host CPU 2534 is further coupled to host-CPU local memory 2538, such as dynamic random-access memory (DRAM) for non-limiting example and host-CPU local persistent data storage 2540. The host-CPU local persistent data storage 2540 may be a solid- state drive (SSD) for non-limiting example. A decision for selecting a processing element of the plurality of processing elements 2512 to implement an operator may be based on at least one criteria, such as compute efficiency as disclosed below with regard to FIGS. 26A and 26B.

[0182] FIG. 26A is a schematic diagram 2600 of an example embodiment of a DFG for non-limiting example. The DFG includes operators A-G for non-limiting example. Each operator may represent a stage of processing for the DFG and may be associated with a respective cost of implementation for each type of processing element. Selection of a- 41 -4212910. vlDocket No. 6214.1006001 processing element may be based on a cost-based analysis that is based on such respective costs, such as disclosed below with regard to FIG. 26B.

[0183] FIG. 26B is a table 2650 of an example embodiment of costs for different types of operators implemented on different types of processing elements. It should be understood that the costs, types of operators, and types of processing elements in the table 2650 are for nonlimiting examples. With reference to FIG. 26A and FIG. 26B, the table 2650 includes respective costs 2652 for implementing the operators of type A-G on processing elements of type CPU, FPGA, and GPU for non-limiting examples. In the table 2650, the processing element type associated with the lowest cost for implementing the operator is chosen, as shown via the circled cost. Thus, a processing element of that type may be selected for implementing the operator.

[0184] For example, the costs for implementing operator A on processing element types corresponding to CPU, FPGA, and GPU are 1, 2, and 5, respectively, in the non-limiting example. The costs for implementing operator B on the processing element types corresponding to CPU, FPGA, and GPU are 3, 4, and 1, respectively, in the non-limiting example. The processing element selected may be the processing element of the processing element type with the lowest cost for implementation of the operator. As such, a CPU may be chosen for implementing operator A, whereas a GPU may be chosen for implementing operator B in the non-limiting example. As such, data may be moved to the CPU for implementing operator A and moved to the GPU for implementing operator B. An example embodiment may also consider cost for such data movement.

[0185] For example, it may be undesirable to move data between multiple elements of the host machine, such as from the CPU to the FPGA, then back to the CPU, then from the CPU to the GPU, then from the GPU to the CPU, and then from the GPU to the CPU. An example embodiment may consider cost of data movement for selection of a processing element for implementing an operator.

[0186] An example embodiment may consider whether it may be advantageous for consecutive operators, such as operators C and E in the DFG 2600 of FIG. 26 A, to be implemented on a same processing element, even though respective costs for implementing C and E on that element may not be the lowest cost relative to other processing elements. An example embodiment of costs for moving data between processing elements is disclosed below with regard to FIG. 26C.- 42 -4212910. vlDocket No. 6214.1006001

[0187] FIG. 26C is a table 2660 of a non-limiting example embodiment of costs for moving data between processing elements, such as a CPU, FPGA, and GPU for non-limiting examples. In the example embodiment of FIG. 26C, cost of data movement between processing elements of the same type is zero. For example, a cost of data movement from FPGA to FPGA is zero, whereas a cost of data movement from FPGA to GPU is three in the non-limiting example. An example embodiment may select a processing element for implementing an operator in order to avoid data movement, such as disclosed below with regard to FIGS. 26D-1 and 26D-2.

[0188] FIGS. 26D-1 and 26D-2 are block diagrams (2666-1, 2666-2) of example embodiments of data movement between processing elements (CPU, FPGA, GPU) for various stages of processing of the DFG 2600 of FIG. 26A, for non-limiting examples. With reference to FIG. 26A and FIG. 26D, implementation of operators A, B, C, E, F, and G may be implemented on the CPU, FPGA, and GPU processing elements based on compute efficiency. As shown in the block diagram 2666-1, however, such selection, based solely on compute efficiency, can lead to multiple instances of data movement between elements with associated cost for data movement related thereto, as disclosed with regard to FIG. 26C, above. With reference to FIG. 26D-1, such data movement shown in the block diagram 2666- 1 may be reduced, as shown in the block diagram 2666-2 of FIG. 26D-2.

[0189] With reference to FIG. 26D-2, even though implement of operators B and C at the FPGA may be inefficient from a compute efficiency perspective relative, the FPGA may be selected to implement such operators to reduce cost of data movement to as implementing both B and C at the same processing element, that is, the FPGA, has a zero cost of data movement. As such, an example embodiment may consider compute efficiency, data movement, or a combination thereof for selection, at runtime, of a processing element for executing an operator.Architecture for Influencing Runtime Personality

[0190] An example embodiment disclosed herein may determine runtime characteristics best suited for a given query plan for processing a query, thereby influencing a runtime “personality” of a runtime fabric that performs such processing The given query plan may be referred to as a physical plan, such as disclosed above and in U.S. Application No.18 / 542,291, U.S. Application No. 18 / 541,993, and U.S. Application No. 18 / 542,488- 43 -4212910. vlDocket No. 6214.1006001(hereinafter, “the '291, '993, and '488 applications”), each of which was filed on December 15, 2023, the entire teachings of which are incorporated herein by reference.

[0191] An example embodiment disclosed herein may employ a control signal to provide such influence. The control signal may enable a runtime execution engine, also referred to interchangeably herein as a processing element or execution resource, to be re-configured at runtime, in parallel with processing of the query. Such reconfiguration may enable a perquery runtime configuration of the processing element for improved compute efficiency. The control signal may be sent by an agent to the runtime fabric to cause a runtime configuration of the processing element (execution engine) to be updated concurrent with generation (creation) of the physical plan. The runtime configuration may be updated at runtime, that is, in an execution mode of a computer-based system, such as a data analytics platform that includes the runtime fabric.

[0192] The runtime configuration may be updated to increase a total number of instances of a given type of accelerator. The accelerator may be a field programmable gate array (FPGA) block of a FPGA, a pre-compiled kernel for a graphics processing unit (GPU), or other type of accelerator for another type of processing element for non-limiting examples. Updating the runtime configuration of a processing element may be triggered, via the control signal, prior to a time at which the processing element is to perform processing for the query. The updated runtime configuration may be optimized based on the query to increase compute efficiency of a procession of the query at the processing element, thereby increasing efficiency of processing of the query overall.

[0193] Embodiments disclosed herein may provide advanced functionality for data analytics. As used herein, a “dataflow graph” (DFG) may include a graph or tree data structure where each node in the graph represents a computational operation or task to be performed using data, and each edge in the graph represents a dataflow operation or task, z.e., to move data between nodes, such as disclosed above and in the '291, '993, and '488 applications,

[0194] Conventional data analytics platforms are constrained in ways that prevent them from meeting the demands of modern data storage, retrieval, and analysis. For example, many existing analytics systems employ general-purpose processors, such as x86 central processing units (CPUs) for non-limiting example, that manage retrieval of data from a database for processing a query. However, such systems often have inadequate bandwidth for retrieving and analyzing large stores of structured and unstructured data, such as those of- 44 -4212910. vlDocket No. 6214.1006001 modern data lakes. Further, the output data resulting from queries of such data stores may be much larger than the input data, placing a bottleneck on system performance. Typical query languages, such as structured query language (SQL) for non-limiting example, can produce inefficient or nonoptimal plans for such systems, leading to delays or missed data. Such plans can also lead to a mismatch between input / output (I / O) and computing load. For example, in a CPU-based analytics system, I / O may be underutilized due to an overload of computation work demanded of the CPU.

[0195] As disclosed above and in the '993 application, a virtual machine (VM) platform, referred to interchangeably herein as “Insight” or a computer-based system, accelerates data analytics workloads, and such acceleration may be enabled by, among other things, processing elements, such as disclosed below with regard to FIG. 27B. Compute nodes may perform various transformations on data, such as filtering, groupingjoining, etc., for nonlimiting examples, and may use hardware accelerators on a programmable data unit (PDU), such as disclosed in the '488 application, and with regard to FIGS. 27A and 27B, disclosed below.

[0196] FIG. 27A is a block diagram of an example embodiment of a computer-based system 2710. The computer-based system comprises runtime fabric 2722 of an analytics platform 2790 and an agent 2720. The agent 2720 is configured to determine a new runtime configuration (not shown) for a processing element 2740’ of the runtime fabric 2722 based on at least one distributed physical plan 2706 received by the runtime fabric 2722 for processing a user query 2702 received by the analytics platform 2790. The new runtime configuration is different from a current runtime configuration (not shown) of the processing element 2740’. The agent 2720 is further configured to cause a reconfiguration of the processing element 2740’ to influence a runtime personality of the runtime fabric 2722. The reconfiguration includes changing the current runtime configuration to the new runtime configuration determined. The at least one distributed physical plan 2706 represents a plurality of jobs (not shown) for the processing of the user query 2702. The processing element 2740’ is selected to execute a job of the plurality of jobs. The reconfiguration is performed in time for the processing element to execute the job.

[0197] FIG. 27B is a block-diagram of an example embodiment of a high-level flow 2700 of a data analytics compute plane of a data analytics platform, such as disclosed above and in the '291, '993, and '488 applications, the entire teachings of which are incorporated herein by reference. In such a compute plane, a user query 2702, also referred to interchangeably herein- 45 -4212910. vlDocket No. 6214.1006001 as an intent, may be expressed in SQL (structured query language), Python, or other programming language for non-limiting examples. A logical plan 2704 may be created from the user query 2702 and the logical plan 2704 may be converted / translated / compiled into at least one distributed physical plan 2706. The at least one distributed physical plan 2706 may, in turn, be transformed into at least one data flow graph (DFG) 2708 generated for execution by at least one worker node, such as the at least one processing element 2740 of the at least one virtual machine (VM) 2730, as disclosed above and in the '291, '993, and '488 applications.

[0198] A personality (runtime characteristics, runtime configuration) of the at least one processing element 2740, also referred to interchangeably herein as a runtime execution engine, may be known (fixed) and used to influence the at least one distributed physical plan 2706, also referred to interchangeably herein as a query execution plan, or query plan. In contrast, according to an example embodiment disclosed herein, an agent 2720 may determine a runtime configuration (not shown) of at least a portion of a runtime fabric 2722 based on the query plan, that is, the at least one distributed physical plan 2706. As such, given a query plan, the agent 2720 may be configured to determine how to configure the at least a portion of the runtime fabric 2722 to be optimized for processing of the user query 2702. As such, an example embodiment may influence a personality, namely a runtime configuration, of a runtime execution engine (processing element) as per an input query plan’s requirement(s).

[0199] For non-limiting example, a respective set of at least one processing element for a VM may be different for different VMs of the at least one VM 2730. The respective set may include a central processing unit (CPU) 2714, field-programmable gate array (FPGA) 2716, graphics processing unit (GPU) 2718, other processing element, or any combination thereof for non-limiting examples. A VM of the at least one VM 2730 may, at runtime, map machine code of a DFG to a target processing element, such as a CPU, FPGA, GPU, or other processing element of the VM, as disclosed above and in the '993. Such machine code may correspond to an operator that represents an operation, such as a hash operationjoin operation, parquet decoder operation, filter operation, or other operation for non-limiting examples.

[0200] According to an example embodiment, as the user query 2702 is being processed and the at least one distributed physical plan 2706 is being created, a control signal 2724, also referred to interchangeably herein as a sideband signal, may be generated to cause a- 46 -4212910. vlDocket No. 6214.1006001 processing element of the at least one processing element 2740 to be reconfigured, at runtime, prior to receipt of a job, such as a portion of a DFG of the at least one DFG 2708, to be implemented as part of the query processing. The control signal 2724 may be generated to cause reconfiguration of a processing element of the at least one processing element 2740 concurrent with the user query 2702 going through the processing pipeline of the high-level flow 2700. Such reconfiguration of the processing element may be performed concurrent with query processing of the user query 2702, at runtime, at the processing element. As such, the control signal 2724 may be generated while the processing element is processing the user query 2702, that is, a job(s) for processing the user query 2702.

[0201] According to an example embodiment, at the distributed physical plan generation stage, a job, of continuously flowing jobs, may represent respective execution for processing at least a portion of a DFG of the at least one DFG 2708, and may be assigned a unique job identifier (ID) (not shown). The control signal 2724 may be provided to a processing element of the at least one processing element 2740 selected for executing the job. The control signal 2724 may enable at least one runtime characteristic (not shown) of the processing element to be configured in time for execution of the job. As such, a runtime implementation for executing the job may be controlled in a manner that enables the runtime implementation to be configured to match a new runtime configuration for executing the job, wherein the new runtime configuration increases compute efficiency of the processing element for executing the job relative to a compute efficiency otherwise effectuated (effected) by a current runtime configuration of the processing element.

[0202] For non-limiting example, as the at least one distributed physical plan 2706 is being generated for the user query 2702, the agent may be determined that the user query 2702 is join “heavy,” that is, multiple join operators may be employed. It may be that the user query 2702 is a first user query, referred to as QI, that is followed by a second user query, referred to as Q2. While QI may be determined to be join operator heavy, that is, a total number of join operators used in a respective physical plan for QI exceeds an operator threshold, the second user query, namely Q2, may be considered be scan operator heavy. Q2 may be considered scan operator heavy if a total number of scan operators used in a respective physical plan for Q2 exceeds the operator threshold.

[0203] According to an example embodiment, a per-query operator representation may be employed to determine such operator “heaviness.” The per-query operator representation may represent the operator(s) associated with implementation of the user query 2702. Such a- 47 -4212910. vlDocket No. 6214.1006001 representation may, for non-limiting example, be a respective bitmap for the user query 2702, wherein each bit of the bitmap may correspond to an operator, such as join, scan, hasher, mover, vector processor, parser, or other operator for non-limiting examples. For nonlimiting example, a value of ‘ 1’ in a bit corresponding to an operator may indicate that such operator is used for implementation of the respective query. The operator may have a 1 : 1 correspondence with an accelerator for implementing same. Based on the per-query operator representation, a respective presence or absence of an accelerator and a total number of instances for the accelerator may be determined. According to an example embodiment, the per-query operator representation may be a two-dimensional representation. A type of accelerator may correspond to a type of operator. The per-query operator representation may represent presence or absence of an accelerator and a total number of instances of the accelerator to be employed for the respective query.

[0204] For non-limiting examples, to implement QI, three hashers and one vector processor may be needed, and for Q2, the per-query operator representation may indicate that three movers and one filter are needed. According to an example embodiment, the control signal 2724 may represent the presence or absence of an accelerator and a total number of instances of the accelerator to be employed for the respective query. At least a portion of the runtime fabric 2722 may be configured based on the control signal 2724 such that a runtime configuration of a processing element of the at least one processing element 2740 is configured with the appropriate accelerator(s) and number of instance(s) thereof, such that the processing element is configured to employ same at a point of execution that relies on same. As such, runtime may be influenced as per the query 2702 such that when the query 2702 lands (is received) at the processing element via normal progression, the processing element has been changed / configured accordingly.

[0205] According to an example embodiment, the agent 2720 may have access to cost information for each operator and execution unit (processing element), such as the per- operator / per-processing-element costs disclosed above and in U.S. Application No. 63 / 695,215, entitled “Adaptive Runtime Decision Making Process for Processing Element Selection” (Attorney Docket No.: 6214.1005-000), filed on September 16, 2024, the entire teachings of which are incorporated herein by reference. The agent 2720 may also have access to per-accelerator performance information.

[0206] According to an example embodiment, the agent 2720 may have access to per- operator per-accelerator performance information (not shown) for accelerators available to- 48 -4212910. vlDocket No. 6214.1006001 the at least one processing element 2740. An accelerator may be a block of a FPGA or precompiled kernel of a GPU for non-limiting examples. Based on the at least one distributed physical plan 2706, the agent 2720 may determine that a stage of processing of the user query 2702 is assigned to be implemented at a processing element of the at least one processing element 2740. The agent 2720 may be configured to influence a runtime configuration of such processing element in a manner that optimizes the processing element’s performance for implementing the stage of processing assigned. Such influence may be provided by way of the control signal 2724 such that the processing element is reconfigured a priori relative to its receipt of instructions for implementing the stage of processing for the user query 2702.

[0207] For example, a stage for processing the user query 2702 may be represented by a table with a billion rows representing join operators followed by a filter operator for nonlimiting example. The per-operator per-accelerator performance information may indicate that a join accelerator, specialized for performing a join, can process 100 million joins / sec for non-limiting example. The agent 2720 may have access to a current runtime configuration for the processing element and scheduled usage information for accelerators available to the processing element assigned to implement the stage of processing.

[0208] For non-limiting example, the processing element of the ate least one processing element 2740 may be a FPGA with a current runtime configuration that includes a single join accelerator block and a single filter accelerator block. As such, for non-limiting example, the agent 2720 may compute a processing time for the stage of processing at the FPGA to be 1,000,000,000 joins x 100 million joins / sec = 10 sec for the joins, followed by 10 sec for the filtering, for a total latency of 20 sec. The agent 2720 may, however, be aware that the current runtime configuration of the FPGA includes accelerator blocks that are not in use, such as a vector processing block, mover block, or other accelerator block that may not be employed for the query processing for non-limiting examples. Based on such accelerator usage information, the agent 2720 may configure the control signal 2724 in a manner that causes (influences) the FPGA to be configured with a new runtime configuration, different from the current runtime configuration.

[0209] For example, the new runtime configuration may replace unused accelerator blocks to increase a total number of instances of an accelerator block that is employed for the stage of processing of the user query 2702, such the join block in the non-limiting example. The agent 2724 may determine that by increasing a total number of instances for the join- 49 -4212910. vlDocket No. 6214.1006001 block to four, the same stage or processing can be performed in 12.5 seconds for non-limiting example.

[0210] According to an example embodiment, each processing element may be associated with accelerator instance information (not shown) that includes a maximum total number of instances of accelerators and type(s) of accelerators that can be instantiated on the processing element. The agent 2720 may determine the new runtime configuration based on the accelerator instance information, usage information of accelerator s) instantiated in the current runtime configuration, and accelerator(s) corresponding to operator(s) of the stage of processing of the user query 2702 to be implemented (executed) at the processing element. The new runtime configuration may be determined by the agent 2720 to enable the processing element to complete the stage of processing, that is, a task or job, efficiently.

[0211] Based on a distributed physical plan of the at least one distributed physical plan2706, the agent 2724 may determine a performance critical operator of a DFG of a DFG of the at least one DFG 2708 to be processed (executed) by a processing element of the at least one processing element 2740. The agent 2720 may determine the new runtime configuration based on the performance critical operator in a performance critical path, such as disclosed below with regard to FIG. 28.

[0212] FIG. 28 is a schematic diagram of an example embodiment of a dataflow graph (DFG) 2800 for non-limiting example. With reference to FIG. 27B and FIG. 28, the agent 2720 has identified that operator C is a performance critical operator in a performance critical path 2811 of the DFG 2800 that includes operators A-H, namely A-H stages of processing. The agent 2720 may add multiple instances 2813 of operator C to the new runtime configuration of a processing element of the at least one processing element 2740 to cause execution of the DFG 2800 to be more efficient. The control signal 2724 may be used to cause the new runtime configuration to be used by the runtime fabric 2722, such as disclosed below with regard to FIG. 29.

[0213] FIG. 29 is a timeline 2900 of an example embodiment of multiple stages (Si-SN) of query processing for non-limiting example. With reference to FIG. 27B and FIG. 29, the timeline 2900 may be for the user query 2702. In the timeline 2900, processing of the user query 2702 may be completed at S5 for non-limiting example, which may be the point at which the user query 2702 is considered to have been executed. At some point in the timeline 2900, the agent 2720 may determine that runtime configuration of downstream execution of the user query 2702 should be influenced.- 50 -4212910. vlDocket No. 6214.1006001

[0214] For example, at a point 2901 in the timeline 2900, the agent 2720 may determine that a current runtime configuration (not shown) of a processing element of the at least one processing element 2740 should be updated to a new runtime configuration (not shown) to cause query processing of the user query 2702 to be more efficient. Such influence may be implemented by the agent 2720 by sending the control signal (2724, 2924) to the runtime fabric 2722 which may, in turn, reconfigure the processing element based on the new runtime configuration.

[0215] At the point 2901, the agent 2720 may send the control signal (2724, 2924) along with a job ID and a query profile ID to the runtime fabric 2722 to initiate a reconfiguration of the processing element from its current runtime configuration to the new runtime configuration determined by the agent 2724. The new runtime configuration may indicate a change in at least one instance of an accelerator at the processing element, as disclosed above. For non-limiting examples, the at least one instance may include an instance of a FPGA accelerator block for a FPGA or a pre-compiled kernel of an accelerator for a GPU.

[0216] The agent 2720 may determine the point 2901 based on a total amount of time needed to change a runtime configuration of the processing element from the current runtime configuration to the new runtime configuration and a total amount of time for processing the user query 2902. For example, the agent 2924 may be configured to send the control signal (2724, 2924) at a point in time that enables a time for reconfiguration to overlap with time taken for the query processing. It should be understood that reconfiguration of a processing element may be based on a type of processing element. For example, a FPGA may take 10 seconds for reconfiguration while a GPU may take 5 seconds for non-limiting examples.

[0217] The agent 2720 may determine whether or not to send the control signal (2724, 2924) based on an amount of time determined for reconfiguration compared to an amount of time for query processing. For example, if an amount of time for reconfiguration of a processing element of the at least one processing element 2740 is determined to exceed the amount of time for query processing, the agent 2720 may determine not to send the control signal (2724, 2924) and the reconfiguration may be trigged by a query profile (not shown) that accompanies the instructions for processing. The query profile may represent the new runtime configuration. As such, re-configuration of a runtime configuration of a processing element may be triggered a prior or just-in-time, relative to receipt of instructions for performing a stage(s) of processing of the user query 2702 for which the new runtime configured has been optimized. The query profile may indicate a type(s) of an accelerator(s)- 51 -4212910. vlDocket No. 6214.1006001 and an instance(s) thereof to be configured, at runtime, and may be communicate via the control signal (2724, 2924) or with query stage processing instructions, as disclosed below with reference to FIG. 30.

[0218] FIG. 30 is a flow diagram 3000 of an example embodiment of a method for generating a control signal. With reference to FIG. 27B and FIG. 30, the method may be implemented by the agent 2720. The method may begin (3002) and determine a runtime configuration (3004), such as the new runtime configuration that is different from a current runtime configuration as disclosed above. The method may determine a total amount of time to configure the runtime configuration determined (3006). The method may check for whether the total amount of time determined is less than query processing time (3008). If yes, the method may send a control signal with a query profile (3010), wherein the query profile indicates a type(s) of an accelerator s) and an instance(s) thereof to be configured at a processing element. The method thereafter ends (3012) in the example embodiment. If, however, the total amount of time determined for the reconfiguration is not less than the query processing time, the query profile may accompany instructions for query processing, and the method thereafter ends (3012) in the example embodiment.

[0219] FIG. 31 is a flow diagram of an example embodiment of a computer-implemented method 3100 for influencing a runtime personality of a runtime fabric of an analytics platform. The computer-implemented method begins (3102) and comprises determining a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform (3104). The new runtime configuration is different from a current runtime configuration of the processing element. The computer-implemented method further comprises causing a reconfiguration of the processing element to effect the influencing of the runtime personality (3106). The reconfiguration includes changing the current runtime configuration to the new runtime configuration determined. The at least one distributed physical plan represents a plurality of jobs for the processing of the user query. The processing element is selected to execute a job of the plurality of jobs. The reconfiguration is performed in time for the processing element to execute the job. The computer-implemented method thereafter ends (3108) in the example embodiment.

[0220] The at least one distributed physical plan may represent at least one dataflow graph (DFG). The job may be at least a portion of a DFG of the at least one DFG.

[0221] The new configuration determined may be a per-query runtime configuration.- 52 -4212910. vlDocket No. 6214.1006001

[0222] The new runtime configuration determined may increase compute efficiency of the processing element for executing the job relative to a compute efficiency otherwise effected by executing the job based on the current runtime configuration of the processing element.

[0223] The computer-implemented method may further comprise causing the reconfiguration to be performed, at runtime, in parallel with the processing of the user query.

[0224] The new configuration may include a change to at least one runtime characteristic.

[0225] The new runtime configuration determined may include a total number of instances of a type of an accelerator of the processing element. The total number of instances may be different from a total number of instances of the type of the accelerator in the current runtime configuration. The type of the accelerator may be a field-programmable gate array (FPGA) block of a FPGA, a pre-compiled kernel for a graphics processing unit (GPU), or other type of accelerator for non-limiting examples.

[0226] Causing the reconfiguration may include generating a control signal and sending the control signal generated to the runtime fabric which, in turn, may perform the reconfiguration prior to a time at which the processing element is to execute the job .

[0227] The new runtime configuration determined may be associated with a query profile identifier (ID). The job may be associated with a job ID. Sending the control signal may include sending the control signal to the runtime fabric along with the query profile ID and the job ID.

[0228] Causing the reconfiguration may include determining a total amount of time for changing the current runtime configuration to the new runtime configuration determined and comparing the total amount of time determined to a total amount of time for the processing of the user query. In an event a result of the comparing indicates that the total amount of time determined is less than the total amount of time for the processing of the user query, the computer-implemented method may further comprise generating a control signal and sending the control signal generated with a query profile ID of a query profile and a job ID of the job to the runtime fabric at a point in time that enables the total amount of time determined to overlap with the total amount of time taken for the processing. In an event a result of the comparing does not indicate that the total amount of time determined is less than the total amount of time for the processing of the user query, the computer-implemented method may further comprise sending the query profile ID to the runtime fabric to accompany the job. The query profile may represent the new runtime configuration determined.- 53 -4212910. vlDocket No. 6214.1006001

[0229] The computer-implemented method may further comprise producing a per-query operator representation of operators associated with implementation of the job. Determining the new runtime configuration may be further based on the per-query operator representation of operators produced.

[0230] Determining the new runtime configuration may be further based on the current runtime configuration and scheduled usage information of accelerators available to the processing element.

[0231] Determining the new runtime configuration may be further based on accelerator instance information of the processing element, usage information of accelerators instantiated in the current runtime configuration, and accelerators that correspond to operators for executing the job. Determining the new runtime configuration may be further based on determining a performance critical operator for executing the at least a portion of the DFG.

[0232] The computer-implemented method may further comprise executing the job by the processing element to produce a result. The result may contribute to a response to the user data query. The response may be output by the data analytics platform.

[0233] The reconfiguration may further comprise checking a loaded programs database for whether a compiled program for implementing the job is loaded into the processing element. In an event the loaded programs database indicates that the compiled program is not loaded into the processing element, the computer-implemented method may further comprise checking a compiled programs database for whether the compiled program is present. In an event the compiled program is present in the compiled programs database, the computer- implemented method may further comprise loading the compiled program into the processing element. In an event the compiled program is not present in the compiled programs database, the computer-implemented method may further comprise generating the compiled program, automatically at runtime, by compiling a program, loading the compiled program into the processing element, and storing the compiled program in the compiled programs database.

[0234] The computer-implemented method may further comprise generating a key that uniquely identifies the compiled program. The generating may be based on arguments input to the compiled program and respective types of the arguments. Checking the compiled programs database may include employing the key generated. Checking the loaded programs database may include employing the key generated and an identifier of the processing element for such automatic code generation, which may be specific to a type of processing element, such as a GPU for non-limiting example.- 54 -4212910. vlDocket No. 6214.1006001

[0235] Further technical details with regard to automatic code generation are disclosed below.Automatic Code Generation

[0236] Typically, when a SQL query is issued by a data analyst, a sub-set of columns in a table are referenced in the SQL query. For example, a table may contain 100+ columns, but a query, such as “select productname, sum(sales), max(quantity) from ITEMS group by productname,” uses only 3 columns from it, for non-limiting example. The types of columns used in the analyst queries also vary depending on the query. In the non-limiting example above, “productname” is a string, “sales” is a floating-point number, and quantity is an integer. During runtime, if a pre-written program / function is used to implement SQL clauses like FILTER, PROJECT, JOIN, GROUP BY, ORDER BY etc., then such program / function needs to handle the number of arguments used in the clause, as well as the different data types used in those causes. As such, the program / function would employ a plurality of jump instructions in the code, which causes cache thrashing and results in poor performance.

[0237] Instead of using pre-written programs / functions, an example embodiment of a backend, such as the backend 2723 of FIG. 27B, disclosed above, may be configured to generate optimal code for each query, using the number of arguments to the clause and the respective data types of those arguments, resulting in high performance at the cost of an amortized compilation time

[0238] To re-use the generated programs / functions where possible, the backend 2723 may maintain a compiled programs database (not shown) of compiled programs (not shown) for executing on a GPU and a loaded programs database (not shown), per-GPU, that indicates which of the compiled programs are loaded on a respective GPU. Before compiling, the backend 2723 may be configured to check if a requested program / function was compiled and loaded by checking the loaded programs database. If the requested program / function is not found in the loaded programs database, the compiled programs database may be checked and re-compilation of the program / function can be avoided if such program / function is found to be present in the database

[0239] For a FILTER clause, programs may be generated using a same expression code generation used for a X64 backend; however, a GPU kernel may be produced instead. For PROJECT, JOIN, GROUP BY, ORDER BY clauses, pre-written C++ template-based- 55 -4212910. vlDocket No. 6214.1006001 functions may be employed, which may take a number of arguments and their types as templates.

[0240] FIG. 32 is a flow diagram of an example embodiment of a method 3200 for automatic code generation. The method may begin (3202) and comprise checking a loaded programs database for whether a compiled program for implementing the job is loaded into the processing element (3204). In an event a check (3206) of the loaded programs database indicates that the compiled program is loaded into the processing element, the method thereafter ends (3214) in the example embodiment.

[0241] In an event the check (3206) of the loaded programs database indicates that the compiled program is not loaded into the processing element, the computer-implemented method may further comprise checking a compiled programs database (3208) for whether the compiled program is present (stored). In an event the check (3210) indicates that the compiled program is present in the compiled programs database, the computer-implemented method may further comprise loading the compiled program into the processing element (3212), and the method thereafter ends (3214) in the example embodiment.

[0242] In an event the check (3210) indicates that the compiled program is not present in the compiled programs database, the computer-implemented method may further comprise generating the compiled program, automatically at runtime, by compiling a program (3216), loading the compiled program into the processing element (3218), and storing the compiled program in the compiled programs database (3220). The method thereafter ends (3214) in the example embodiment.

[0243] As used herein, the terms “agent,” “engine,” “fabric,” “unit,” or “module,” may refer to any hardware, software, firmware, electronic control component, processing logic, and / or processor device, individually or in any combination, including without limitation: an application specific integrated circuit (ASIC), a FPGA, an electronic circuit, a processor and memory that executes one or more software or firmware programs, and / or other suitable components that provide the described functionality.

[0244] Example embodiments disclosed herein may be configured using a computer program product; for example, controls may be programmed in software for implementing example embodiments. Further example embodiments may include a non-transitory computer-readable medium that contains instructions that may be executed by a processor, and, when loaded and executed, cause the processor to complete methods (e.g., the method 2200, method 2100, etc.) described herein. It should be understood that elements of the block- 56 -4212910. vlDocket No. 6214.1006001 and flow diagrams may be implemented in software or hardware, such as via one or more arrangements of circuitry of FIG. 23, disclosed above, or equivalents thereof, firmware, a combination thereof, or other similar implementation determined in the future. In addition, the elements of the block and flow diagrams described herein may be combined or divided in any manner in software, hardware, or firmware. If implemented in software, the software may be written in any language that can support the example embodiments disclosed herein. The software may be stored in any form of computer readable medium, such as randomaccess memory (RAM), read-only memory (ROM), compact disk read-only memory (CD- ROM), and so forth. In operation, a general purpose or application-specific processor or processing core loads and executes software in a manner well understood in the art. It should be understood further that the block and flow diagrams may include more or fewer elements, be arranged or oriented differently, or be represented differently. It should be understood that implementation may dictate the block, flow, and / or network diagrams and the number of block and flow diagrams illustrating the execution of embodiments disclosed herein.

[0245] The teachings of all patents, published applications and references cited herein are incorporated by reference in their entirety.

[0246] While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments encompassed by the appended claims.- 57 -4212910. vl

Claims

Docket No. 6214.1006001CLAIMSWhat is claimed is:

1. A computer-implemented method for influencing a runtime personality of a runtime fabric of an analytics platform, the computer-implemented method comprising: determining a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform, the new runtime configuration different from a current runtime configuration of the processing element; and causing a reconfiguration of the processing element to effect the influencing of the runtime personality, the reconfiguration including changing the current runtime configuration to the new runtime configuration determined, the at least one distributed physical plan representing a plurality of jobs for the processing of the user query, the processing element selected to execute a job of the plurality of jobs, the reconfiguration performed in time for the processing element to execute the job.

2. The computer-implemented method of Claim 1, wherein the at least one distributed physical plan represents at least one dataflow graph (DFG) and wherein the job is at least a portion of a DFG of the at least one DFG.

3. The computer-implemented method of Claim 1, wherein the new configuration determined is a per-query runtime configuration.

4. The computer-implemented method of Claim 1, wherein the new runtime configuration determined increases compute efficiency of the processing element for executing the job relative to a compute efficiency otherwise effected by executing the job based on the current runtime configuration of the processing element.

5. The computer-implemented method of Claim 1, further comprising causing the reconfiguration to be performed, at runtime, in parallel with the processing of the user query.

6. The computer-implemented method of Claim 1, wherein the new configuration includes a change to at least one runtime characteristic.- 58 -4212910. vlDocket No. 6214.10060017. The computer-implemented method of Claim 1, wherein the new runtime configuration determined includes a total number of instances of a type of an accelerator of the processing element, wherein the total number of instances is different from a total number of instances of the type of the accelerator in the current runtime configuration, wherein the type of the accelerator is a field-programmable gate array (FPGA) block of a FPGA, a pre-compiled kernel for a graphics processing unit (GPU), or other type of accelerator.

8. The computer-implemented method of Claim 1, wherein causing the reconfiguration includes generating a control signal and sending the control signal generated to the runtime fabric which, in turn, performs the reconfiguration prior to a time at which the processing element is to execute the job.

9. The computer-implemented method of Claim 8, wherein the new runtime configuration determined is associated with a query profile identifier (ID), where the job is associated with a job ID, and wherein sending the control signal includes sending the control signal to the runtime fabric along with the query profile ID and the job ID.

10. The computer-implemented method of Claim 1, wherein causing the reconfiguration includes: determining a total amount of time for changing the current runtime configuration to the new runtime configuration determined; and comparing the total amount of time determined for changing the current runtime configuration to the new runtime configuration determined to a total amount of time for the processing of the user query, wherein: in an event a result of the comparing indicates that the total amount of time determined is less than the total amount of time for the processing of the user query, the computer-implemented method further comprises generating a control signal and sending the control signal generated with a query profile ID of a query profile and a job ID of the job to the runtime fabric at a point in time that enables the total amount of time determined to overlap with the total amount of time taken for the processing; and- 59 -4212910. vlDocket No. 6214.1006001 in an event a result of the comparing does not indicate that the total amount of time determined is less than the total amount of time for the processing of the user query, the computer-implemented method further comprises sending the query profile ID to the runtime fabric to accompany the job, wherein the query profile represents the new runtime configuration determined.

11. The computer-implemented method of Claim 1, further comprising producing a perquery operator representation of operators associated with implementation of the job and wherein determining the new runtime configuration is further based on the perquery operator representation of operators produced.

12. The computer-implemented method of Claim 1, wherein determining the new runtime configuration is further based on the current runtime configuration and scheduled usage information of accelerators available to the processing element.

13. The computer-implemented method of Claim 1, wherein determining the new runtime configuration is further based on accelerator instance information of the processing element, usage information of accelerators instantiated in the current runtime configuration, and accelerators that correspond to operators for executing the job.

14. The computer-implemented method of Claim 1, wherein the at least one distributed physical plan represents at least one at least one DFG, wherein the job is at least a portion of a DFG of the at least one DFG, and wherein determining the new runtime configuration is further based on determining a performance critical operator for executing the at least a portion of the DFG.

15. The computer-implemented method of Claim 1, wherein the reconfiguration further comprises checking a loaded programs database for whether a compiled program for implementing the job is loaded into the processing element and wherein, in an event the loaded programs database indicates that the compiled program is not loaded into the processing element, the computer-implemented method further comprises: checking a compiled programs database for whether the compiled program is present and wherein:- 60 -4212910. vlDocket No. 6214.1006001 in an event the compiled program is present in the compiled programs database, the computer-implemented method further comprises loading the compiled program into the processing element; and in an event the compiled program is not present in the compiled programs database, the computer-implemented method further comprises: generating the compiled program, automatically at runtime, by compiling a program; loading the compiled program into the processing element; and storing the compiled program in the compiled programs database.

16. The computer-implemented method of Claim 15, further comprising generating a key that uniquely identifies the compiled program, wherein the generating is based on arguments input to the compiled program and respective types of the arguments, wherein checking the compiled programs database includes employing the key generated, and wherein checking the loaded programs database includes employing the key generated and an identifier of the processing element.

17. The computer-implemented method of Claim 1, further comprising executing the job by the processing element to produce a result, wherein the result contributes to a response to the user data query, and wherein the response is output by the data analytics platform.

18. A computer-based system comprising: runtime fabric of an analytics platform; and an agent configured to determine a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform, the new runtime configuration different from a current runtime configuration of the processing element, the agent further configured to cause a reconfiguration of the processing element to influence a runtime personality of the runtime fabric, the reconfiguration including changing the current runtime configuration to the new runtime configuration determined, the at least one distributed physical plan representing a- 61 -4212910. vlDocket No. 6214.1006001 plurality of jobs for the processing of the user query, the processing element selected to execute a job of the plurality of jobs, the reconfiguration performed in time for the processing element to execute the job.

19. The computer-based system of Claim 18, wherein the at least one distributed physical plan includes at least one dataflow graph (DFG) and wherein the job is at least a portion of a DFG of the at least one DFG.

20. The computer-based system of Claim 18, wherein the new configuration determined is a per-query runtime configuration.

21. The computer-based system of Claim 18, wherein the new runtime configuration determined increases compute efficiency of the processing element for executing the job relative to a compute efficiency otherwise effected by executing the job based on the current runtime configuration of the processing element.

22. The computer-based system of Claim 18, where the agent is further configured to cause the reconfiguration to be performed, at runtime, in parallel with the processing of the user query.

23. The computer-based system of Claim 18, wherein the new configuration includes a change to at least one runtime characteristic.

24. The computer-based system of Claim 18, wherein the new runtime configuration determined includes a total number of instances of a type of an accelerator of the processing element, wherein the total number of instances is different from a total number of instances of the type of the accelerator in the current runtime configuration, wherein the type of the accelerator is a field-programmable gate array (FPGA) block of a FPGA, a pre-compiled kernel for a graphics processing unit (GPU), or other type of accelerator.

25. The computer-based system of Claim 18, wherein, to cause the reconfiguration, the agent is further configured to generate a control signal and send the control signal generated to the runtime fabric which, in turn, is configured to perform the reconfiguration prior to a time at which the processing element is to execute the job .- 62 -4212910. vlDocket No. 6214.100600126. The computer-based system of Claim 25, wherein the new runtime configuration determined is associated with a query profile identifier (ID), where the job is associated with a job ID, and wherein sending the control signal includes sending the control signal to the runtime fabric along with the query profile ID and the job ID.

27. The computer-based system of Claim 18, wherein, to cause the reconfiguration, the agent is further configured to: determine a total amount of time for changing the current runtime configuration to the new runtime configuration determined; and compare the total amount of time determined for changing the current runtime configuration to the new runtime configuration determined to a total amount of time for the processing of the user query to produce a comparison result, wherein: in an event the comparison result indicates that the total amount of time determined is less than the total amount of time for the processing of the user query, the agent is further configured to generate a control signal and send the control signal generated with a query profile ID of a query profile and a job ID of the job to the runtime fabric at a point in time that enables the total amount of time determined to overlap with the total amount of time taken for the processing; and in an event the comparison result does not indicate that the total amount of time determined is less than the total amount of time for the processing of the user query, the agent is further configured to send the query profile ID to the runtime fabric to accompany the job, wherein the query profile represents the new runtime configuration determined.

28. The computer-based system of Claim 18, wherein the agent is further configured to generate a per-query operator representation of operators associated with implementation of the job, and wherein the agent is further configured to determine the new runtime configuration based on the per-query operator representation of operators produced.

29. The computer-based system of Claim 18, wherein the agent is further configured to determine the new runtime configuration based on the current runtime configuration and scheduled usage information of accelerators available to the processing element.- 63 -4212910. vlDocket No. 6214.100600130. The computer-based system of Claim 18, wherein the agent is further configured to determine the new runtime configuration based on accelerator instance information of the processing element, usage information of accelerators instantiated in the current runtime configuration, and accelerators that correspond to operators for executing the job.

31. The computer-based system of Claim 18, wherein the at least one distributed physical plan is at least one at least one DFG, wherein the job is at least a portion of a DFG of the at least one DFG, and wherein the agent is further configured to determine the new runtime configuration based on determining a performance critical operator for executing the at least a portion of the DFG.

32. The computer-based system of Claim 18, wherein the reconfiguration further includes checking a loaded programs database for whether a compiled program for implementing the job is loaded into the processing element and wherein, in an event the loaded programs database indicates that the compiled program is not loaded into the processing element, the reconfiguration further includes: checking a compiled programs database for whether the compiled program is present and wherein: in an event the compiled program is present in the compiled programs database, the reconfiguration further includes loading the compiled program into the processing element; and in an event the compiled program is not present in the compiled programs database, the reconfiguration further comprises: generating the compiled program, automatically at runtime, by compiling a program; loading the compiled program into the processing element; and storing the compiled program in the compiled programs database.

33. The computer-based system of Claim 32, wherein the runtime fabric is further configured to generate a key that uniquely identifies the compiled program, wherein generation of the key is based on arguments input to the compiled program and respective types of the arguments, wherein checking the compiled programs database- 64 -4212910. vlDocket No. 6214.1006001 includes employing the key generated, and wherein checking the loaded programs database includes employing the key generated and an identifier of the processing element.

34. The computer-based system of Claim 18, wherein executing the job by the processing element produces a result, wherein the result contributes to a response to the user data query, and wherein data analytics platform is configured to output the response.

35. A non-transitory computer-readable medium for influencing a runtime personality of a runtime fabric of an analytics platform, the non-transitory computer-readable medium having encoded thereon a sequence of instructions which, when loaded and executed by at least one processor, cause the at least one processor to: determine a new runtime configuration for a processing element of the runtime fabric based on at least one distributed physical plan received by the runtime fabric for processing a user query received by the analytics platform, the new runtime configuration different from a current runtime configuration of the processing element; and cause a reconfiguration of the processing element to effect the influencing of the runtime personality, the reconfiguration including changing the current runtime configuration to the new runtime configuration determined, the at least one distributed physical plan representing a plurality of jobs for the processing of the user query, the processing element selected to execute a job of the plurality of jobs, the reconfiguration performed in time for the processing element to execute the job.- 65 -4212910. vl

Images