Auto recognition of big data computation engine for optimized query runs on cloud platforms

A method may include receiving a request for a big data query including characteristics and user parameters and accessing a set of rules based at least in part on respective properties of one or more big data query engines, the set of rules correlating the one or more characteristics, the one or more user parameters and the respective properties. The method may include determining a candidate list including a subset of the big data query engines, determined based on the set of rules. Using a machine learning model, the method may include generating respective probability scores for each big data query engine. The method may include selecting and executing the big data query using a particular big data query engine. The method may include identifying a trigger indicating a performance issue with the particular big data query engine and switching the execution to a second big data query engine.

BACKGROUND

With the proliferation of big data, more and more users may wish to query big data sets in order to gain valuable insights for their business or other reasons. Data sources to be queried are varied, having different properties, scales etc. Query types may also vary in scope, objective, priority, and other parameters. At the same time, a wide variety of big data query engines may exist, each with their own strengths and weaknesses. Because there are so many variables, choosing an optimal big data query engine may require specialized knowledge, requiring training and experience that can be unavailable to at least some of the users wanting to execute a big data query.

BRIEF SUMMARY

A method may include receiving, by a computing system, a request for a big data query including one or more characteristics and one or more user parameters. The method may include accessing, by the computing system, a set of rules, the set of rules being based at least in part on respective properties of one or more big data query engines, and the set of rules correlating at least one of the one or more characteristics associated with the big data query and the one or more user parameters with the respective properties of the one or more big data query engines. The method may then include determining, by the computing system, a candidate list of big data query engines may include a subset of the one or more big data query engines, the candidate list determined based at least in part on the set of rules. The method may include generating, by the computing system and using a machine learning model, respective probability scores for each big data query engine of candidate list of big data query engines, the respective probability scores representing a likelihood of the big data query being successfully completed by each big data query engine of the subset. The method may include selecting, by the computing system, a particular big data query engine of the one or more big data query engines of the candidate list, based at least in part on the respective probability score of the particular big data query engine. The method may include executing, by the computing system, the big data query using the particular big data query engine. The method may include identifying, by the computing system, a trigger indicating a performance issue with the particular big data query engine. The method may include switching, by the computing system, the execution the big data query to a second big data query engine of the candidate list of big data query engines.

In some embodiments, identifying the trigger indicating a performance issue further may include monitoring, by the computing system, one or more performance metrics of the particular big data query engine during the execution of the big data query. The method may then include determining, by the computing system, that the particular big data query engine is not performing to an expected level based at least in part on the one or more performance metrics and the one or more user parameters. In response to determining that the particular big data query engine is not performing to the expected level, the method may include terminating, by the computing system, the execution of the big data query by the particular big data query engine. The method may then include executing, by the computing system, the big data query using the second data query engine, the second data query engine selected based at least in part on the respective probability score of the second data query engine.

In some embodiments, the method may include determining, by the computing system, one or more performance metrics of the particular big data query engine during the execution of the big data query. The method may include retraining, by the computing system, the machine learning model using the one or more the one or more performance metrics and at least one of the one or more characteristics of the big data query and the one or more user parameters. The machine learning model may be retrained after a specific number of query executions. The one or more user parameters may include at least one of a reliability parameter, a latency parameter, and an accuracy parameter. The one or more characteristics of the big data query may include a number of partitions, a row count, a query-type, and a table size. The machine learning model may be trained using a training data set may include a data set size, a row count, a number of partitions, a column count, a column type map, a number of files, a query-operator count map, a query result reliability weight, a query execution time, and a query execution time weight. In some embodiments, determining the candidate list is based at least in part on a relational tree may include the one or more characteristics associated with the big data query and the one or more user parameters.

A computing system may include one or more processors and a computer readable memory may include instructions that, when executed by the one or more processors, cause the computing system to perform operations. According to the operations, the computing system may receive a request for a big data query may include one or more characteristics and one or more user parameters. The computing system may access a set of rules, the set of rules being based at least in part on respective properties of one or more big data query engines, and the set of rules correlating at least one of the one or more characteristics associated with the big data query and the one or more user parameters with the respective properties of the one or more big data query engines. The computing system may determine a candidate list of big data query engines may include a subset of the one or more big data query engines, the candidate list determined based at least in part on the set of rules. The computing system may generate, using a machine learning model, respective probability scores for each big data query engine of candidate list of big data query engines, the respective probability scores representing a likelihood of the big data query being successfully completed by each big data query engine of the subset. The computing system may select a particular big data query engine of the one or more big data query engines of the candidate list, based at least in part on the respective probability score of the particular big data query engine. The computing system may execute the big data query using the particular big data query engine. The computing system may identify a trigger indicating a performance issue with the particular big data query engine. The computing system may switch the execution the big data query to a second big data query engine of the candidate list of big data query engines.

In some embodiments, the operations may further cause the computing system to monitor one or more performance metrics of the particular big data query engine during the execution of the big data query. The computing system may determine that the particular big data query engine is not performing to an expected level based at least in part on the one or more performance metrics and the one or more user parameters. In response to determining that the particular big data query engine is not performing to the expected level, the computing system may terminate the execution of the big data query by the particular big data query engine. The computing system may execute the big data query using the second data query engine, the second data query engine selected based at least in part on the respective probability score of the second data query engine.

In some embodiments, the computing system may be implemented to select a query engine in a Hadoop environment. The machine learning model may be trained using a training data set may include a data set size, a row count, a number of partitions, a column count, a column type map, a number of files, a query-operator count map, a query result reliability weight, a query execution time, and a query execution time weight. The one or more user parameters may include at least one of a reliability parameter, a latency parameter, and an accuracy parameter. The one or more characteristics of the big data query may include a number of partitions, a row count, a query-type, and a table size.

A non-transitory computer-readable medium may include instructions that, when executed by a processor, cause the processor to perform operations. The operations may include receiving, by a computing system, a request for a big data query may include one or more characteristics and one or more user parameters. The operations may include accessing, by the computing system, a set of rules, the set of rules being based at least in part on respective properties of one or more big data query engines, and the set of rules correlating at least one of the one or more characteristics associated with the big data query and the one or more user parameters with the respective properties of the one or more big data query engines. The operations may then include determining, by the computing system, a candidate list of big data query engines may include a subset of the one or more big data query engines, the candidate list determined based at least in part on the set of rules. The operations may include generating, by the computing system and using a machine learning model, respective probability scores for each big data query engine of candidate list of big data query engines, the respective probability scores representing a likelihood of the big data query being successfully completed by each big data query engine of the subset. The operations may include selecting, by the computing system, a particular big data query engine of the one or more big data query engines of the candidate list, based at least in part on the respective probability score of the particular big data query engine. The operations may include executing, by the computing system, the big data query using the particular big data query engine. The operations may include identifying, by the computing system, a trigger indicating a performance issue with the particular big data query engine. The operations may include switching, by the computing system, the execution the big data query to a second big data query engine of the candidate list of big data query engines.

In some embodiments, identifying the trigger indicating a performance issue further may include monitoring, by the computing system, one or more performance metrics of the particular big data query engine during the execution of the big data query. The operations may then include determining, by the computing system, that the particular big data query engine is not performing to an expected level based at least in part on the one or more performance metrics and the one or more user parameters. In response to determining that the particular big data query engine is not performing to the expected level, the operations may include terminating, by the computing system, the execution of the big data query by the particular big data query engine. The operations may include executing, by the computing system, the big data query using the second data query engine, the second data query engine selected based at least in part on the respective probability score of the second data query engine.

In some embodiments, the operations may include determining, by the computing system, one or more performance metrics of the particular big data query engine during the execution of the big data query. The operations may also include retraining, by the computing system, the machine learning model using the one or more the one or more performance metrics and at least one of the one or more characteristics of the big data query and the one or more user parameters. The machine learning model may be retrained after a specific number of query executions. The one or more user parameters may include at least one of a reliability parameter, a latency parameter, and an accuracy parameter. The one or more characteristics of the big data query may include a number of partitions, a row count, a query-type, and a table size.

DETAILED DESCRIPTION

Big data queries may provide a user with valuable insights by accessing and aggregating large data sets from a variety of sources. A query may be directed towards one or more data sources, such as a software-defined file system (SDFS), an object storage, a database, and/or other suitable data storage formats and/or locations. Furthermore, queries may be performed with different goals in mind. Some queries may prioritize a fast response time over accuracy. Other queries may prioritize reliability over latency. Still more queries may prioritize some other attribute. In a big data ecosystem, such as Hadoop, several big data query engines (e.g., Spark, Hive, Trino, Impala, etc.) may be used to query and process the data. The big data query engines may accept a variety of inputs (e.g., a structured query language (SQL) input, then execute the query in a distributed manner. Each of the big data query engines may have various characteristics and capabilities that may enable a particular engine to execute a particular query better than some other query engine. In other words, the priorities associated with a particular query (e.g., latency, response time, etc.) may be better met with a certain big data query engine.

Generally, a user designing the query must decide which query engine to use in order to obtain the results the user needs according to their priorities. While big data service providers may provide big data platforms with several big data query engines installed, the choice of which engine to use is still largely based on the user's knowledge of each query engine, each data source, the interaction between each query engine and each data source, and/or other specialized knowledge. Because of the knowledge required to select the optimal query engine for a particular query, many users may choose an incorrect or less-than-optimal engine for a particular query.

Furthermore, once the user executes the query, the user may not realize that the incorrect query engine was selected until after the results of the query are provided to the user. The user may then re-execute the query, but as before, without the requisite knowledge to choose a query engine better suited to the query, there is no guarantee that the results of the re-executed query will be any better. Therefore, there is a need to develop systems and techniques that are able to filter and select a big data query engine such that even users without specialized knowledge are able to choose an optimal query engine based on the submitted query.

One solution may be to provide a system that may parse a query to determine characteristics associated with the query, then select a query engine based upon the characteristics of the query. For example, a user may generate a query via a user interface or some other appropriate manner. The query may specify one or more data sources to be queried, a query type, and other properties. The user may also provide user parameters representing the user's priorities for the query, such as response time, latency, consistency, amount of data queried, etc. The query may be provided to a query analyzer. The query analyzer may parse the query to identify the characteristics of the query. The query analyzer may also consider the user parameters in parsing the query. The query analyzer may then output data representing the query's characteristics as related to the user parameters.

The data output from the query analyzer may then be provided to an engine selector. The engine selector may include two components: a rules filter (e.g., a static rules filter or a dynamic rules filter) and a machine learning model (MLM). The rules filter may include one or more rules used to associate various characteristics of a query with one or more query engines. For example, if there is a query includes a dataset with a particularly high number of rows and/or partitions, the static rules filter may be used to identify some subset of query engines that perform better with larger numbers of partitions and rows. Another query may be a join query and therefore a second subset of query engines may be identified that perform join queries better than others. The preceding examples may be overly simple for the sake of explanation; an actual query may be much more complex and require filtering based on several rules, characteristics, and user parameters.

After a subset of the query engines is identified using the static rules filter, the subset of query engines may be provided to the MLM. The MLM may be trained to generate a probability score that a particular engine will properly execute a particular query based on the characteristics of the query, the user parameters, and properties of each query engine in the subset of query engines. Thus, the MLM may assign a probability score to each of query engine of the subset of query engines. The engine selector may then utilize the probability scores associated with each of the query engines to select the optimal query engine for the query.

A query monitor may then execute the query using the selected query engine. While the query is being performed, the query monitor may monitor the intermediate results as the intermediate results are received from the query engine. The query monitor may compare the performance of the selected query engine to the user parameters. If the intermediate results are below a threshold such that one or more of the user parameters are not met, the query monitor may terminate the query and re-execute the query using a second query engine. Thus, the query may be properly executed with or without the user's interaction, by an optimal query engine. Because the user may no longer be required to have all of the requisite knowledge to select the optimal query engine, executing a big data query may be performed by more users, leading to greater efficiency. Furthermore, because the query monitor may dynamically switch query engines during the execution of the query, less computing power, energy, and time may be used in case a non-optimal query is selected.

FIG.1illustrates a system100and a process101for automatically selecting a big data query engine and executing a query, according to certain embodiments. The system100may include a computing system102. The computing system102may include a query analyzer104, an engine selector106, and a query monitor108. The computing system102may be a single computing device (e.g., a physical or virtual machine), or may be implemented in a distributed cloud-based architecture. The computing system102may be included in a big data platform, accessed by one or more user of the big data platform. The big data platform may be provided by a cloud services provider and/or big data services provider.

The query analyzer104may be configured to parse big data queries. The query analyzer may utilize a rules-based model, neural network (e.g., an attention network) or other suitable model to determine the characteristics of a particular query. The characteristics may include a size of a data set to be queried, a row count, a number of files, a query type (e.g., aggregate, filter, sort, full scan, join, etc.), a data source, and other such characteristics. The query analyzer may also receive a set of user parameters as part of the particular query as a separate input from a user. The user parameters may include reliability, scalability, a cost associated with the query, a response time, accuracy, and the desired response, a reliability of a returned result, and other such parameters. The user may assign a weight to each of the user parameters. For example, the user may consider the reliability of the response more important than the response time of the request. Therefore, the user may assign a weight of 7 to a reliability parameter, and a weight of 3 to a response time parameter. The weight may be assigned to each parameter according to an input on a user interface, such as a slider or other such interface. The weights may be assigned as a number, a percentage, or any other suitable weighting system.

The query analyzer104may determine relationships between the characteristics of the query and the user parameters. The query analyzer104may then represent the relationships in a relational tree or other such representation. The query analyzer104may thereby output data that represents the characteristics of the query and user parameters that may be used to select a query engine.

The engine selector106may include a static rules filter and/or an MLM configured to assign a probability score to one or more query engines. The static rules filter may be stored in the computing system102or may be external, in a shared storage accessible by other computing systems performing similar operations as the computing system102. The static rules filter may be used by the engine selector to select a candidate list of query engines from the query engines available to perform the query. For example, the engine selector106may access data indicating properties associated with each of the available query engines. The properties may be correlated to at least some of the characteristics of the query. A first query engine may perform better when accessing a particular data source. Another query engine may perform better when executing a certain query type (e.g., a join query). Yet another query engine may perform better when the response time is crucial. One of ordinary skill in the art would recognize many different properties.

The engine selector106may then compare the properties of the available query engines to the data output by the query analyzer104(e.g., the relational tree) to generate a candidate list of query engines. The engine selector106may then assign a probability score to the each of the query engines on the candidate list, representing the likelihood that each query engine could execute the query according to the characteristics of the query and/or the user parameters. To do so, the engine selector106may utilize an MLM. The MLM may include an rules-based model, a neural network (e.g., an attention network), or other such models to predict the likelihood of success of any given query engine.

After the engine selector106selects a query engine, the query monitor108may execute the query using the selected query engine. The query monitor108may monitor the performance of the query engine during the execution of the query. The query monitor108may be configured to terminate the query in the event of a trigger. The trigger may be based on intermediate results of the query not meeting a user parameter, a user-based trigger, or other such trigger. The query monitor108may then re-execute the query using another query engine. In some embodiments, the engine selector106may perform operations to select the other query engine. In other embodiments, the query monitor108may determine the other query engine based on information already received.

At step103, the computing system102may receive a query114. The query114may be a big data query and include one or more characteristics. The characteristics may include a size of a data set to be queried, a row count, a number of files, a query type (e.g., aggregate, filter, sort, full scan, join, etc.), a data source, and other such characteristics. The query114may be generated from a user interface of the computing system102or may be received from another user device. The query114may also include one or more user parameters, representing a user's preferences associated with the query. In some embodiments, the one or more user parameters may be provided separately though another interface. In either case, the query114(including the characteristics and the one or more user parameters) may be provided to the query analyzer104.

At step105, the query analyzer104may parse the query114to determine relationships between the characteristics of the query and the one or more user parameters. The query analyzer104may include an MLM, or may be a rules-based model. The query analyzer104may also access data indicating properties of data source(s)116to be queried. For example, the query114may indicate that the data source(s)116are to be queried via a particular query type. The query analyzer104may then determine properties of the data source(s)116, such as a row count, a partition count, a data format, and other such properties associated with the data source(s)116. The properties of the data source(s)116may be indicated in the query114, or may be stored in a separate data store. In either case, the query analyzer104may use the characteristics of the query114(including the properties of the data source(s)116) and the one or more parameters to determine a complexity of the query114. The query analyzer104may the generate a relational tree or other such data representing the importance of each of the one or more user parameters and/or the characteristics of the query114. The query analyzer104may then provide the relational tree to the engine selector106.

At step107, the engine selector106may generate a candidate list of query engines. To do so, the engine selector106may access a query engine list110. The query engine list110may include a list of all query engines available to the computing system102and/or the user to execute the query114. The list of all available query engines may include properties of each query engine. For example, a first query engine may perform better than other query engines when processing large data sets. A second query engine may perform more reliably when processing queries of a certain type.

The engine selector106may compare the data included in the relational tree provided by the query analyzer104to the properties of each of the available query engines using the static rules filter. The static rules filter may include benchmarks for each of the available query engines based on historical queries. For example, a particular engine may perform better under a certain data load, query type, etc. In another example, a certain query type may only be performed by a particular query engine. In other words, the static rules filter may include information that associates one or more query engines with the characteristics and/or user parameters of the query114. The static rules filter may therefore be used to narrow the number of query engines from the total number of available query engines to a subset of query engines. The subset of query engines may be indicated in a candidate list of query engines.

At step109, the engine selector106may generate probability scores for each query engine on the candidate list. To do so, the candidate list of query engines and/or the relational tree may be provided to an MLM trained to generate a probability score for each query engine. The probability score may represent a likelihood that each query engine would complete the query114according to the user parameters. For example, the candidate list may include two query engines. A first query engine may be determined to have a probability score of 80% of completing the query114successfully, whereas a second query engine may be determined to have a probability score of 92% of completing the query114successfully. The MLM may utilize an attention network or other such model in order to generate the probability scores. Then, at step111, and based at least in part on the respective probability scores, the engine selector106may indicate to the query monitor108that a query engine112is the optimal query engine to perform the query114.

At step113, the query monitor108may cause the query114to be executed by the query engine112. To execute the query114, the query engine112may communicate with the data source(s)116. The query engine112may process results as the data source(s)116is queries, resulting in intermediate results. In other words, instead of compiling all of the results of the query114and generating a response, the query engine112may instead process data as it is received.

At step115, the query monitor108may monitor the performance of the query engine112during the execution of the query114. For example, the query monitor108may determine that the response time of the query engine112is in compliance with the user parameter associated with the query114. The query monitor108may determine that a reliability of the intermediate results, however, are below the corresponding user parameter (e.g., too many error responses, duplicated data, etc.). The query monitor108may then determine that the query engine112is not performing to the user parameters.

In response, the query monitor108may cause the query114to be terminated by the query engine112. Then, the query monitor may re-execute the query114using an alternate query engine. In some embodiments, the query monitor108may re-execute the query114using an alternate query engine previously indicated by the engine selector106. In other embodiments, the query monitor108may provide data indicating the performance of the query engine112to the engine selector106. The engine selector106may then perform some or all of the operations described above to select the alternate engine selector. After the query114is successfully executed, the results of the query114may be processed and returned to the user.

FIG.2illustrates a system200for generating a relational tree240based associated with a big data query214, according to certain embodiments. The system200may be similar to some or all of the system100inFIG.1. The system200may include a query analyzer204. The query analyzer204may be configured to parse a query such as a big data query214to determine relationships between characteristics of the query and one or more user parameters.

The big data query214may include query characteristics224and user parameters234. The query analyzer204may parse the big data query214to find relationships between query characteristics224and the user parameters234. Additionally or alternatively, the query analyzer204may determine properties of a data source associated with the big data query214. For example, the data source may include a row count and/or number of partitions. The query analyzer204may access a data store including the properties of the data store and/or the properties of the data store may be included in or inferred from the big data query214.

The query analyzer204may also parse the user parameters234. The user parameters234may be included in the big data query214or may be provided through a separate interface. Each of the user parameters may include a weight set by a user. For example, as shown inFIG.2, a user parameter associated with latency may have a weight of 5. A user parameter associated with accuracy may have a weight of 7. A user parameter associated with response time may have a weight of 9. Although not illustrated, the user parameters234may include any number of user parameters, such as reliability, format, etc.

Based at least in part on the query characteristics224and the user parameters234, the query analyzer may generate a relational tree240. The relational tree240may include a hierarchical representation of the query characteristics224and the user parameters234. The relational tree240may also show how a user parameter is related to a characteristic of the big data query214. For example, as shown inFIG.2, the response time parameter may be related to the accuracy parameter and the query type. The query type may be related to the data source. The row count may also be related to the data source. It should be understood that although the only some of the query characteristics224and user parameters234are shown in the relational tree240, the relational tree240may include any number of query characteristics224and user parameters234. Furthermore, although the relational tree240is illustrated as a graphical tree, the relational tree may be any type of logical arrangement of data representing some or all of the query characteristics224and/or the user parameters234.

FIG.3illustrates a system300including an engine selector306, according to certain embodiments. The system300may be included in the system100FIG.1and/or combined with the system200inFIG.2. The engine selector306may include an engine list310, a rules filter316(e.g., for filtering rules, including static rules, dynamic rules, etc.), and an MLM320. The engine list310may include a list of all query engines available to perform a big data query. The engine list310may also include properties associated with each of the query engines, such as a cost, response time, and other performance metrics.

The rules filter316may include one or more benchmarks determined by historical big data queries executed by some or all of the query engines included in the engine list310. Thus, the rules filter316may indicate how each of the query engines in the engine list310performs according to certain queries and/or user parameters. For example, the rules filter316may indicate that, based on a certain data load from a particular data source, query engines 1 and 2 tend to perform better than any other query engines included in the engine list310. The rules filter316may also include user rules. For example, a user may have specialized knowledge that a particular query engine is the optimal choice for a certain query type and data source. Therefore, the user may set a rule that any query of the certain query type and data source should be executed by the particular query engine.

The rules filter316may be provided with a relational tree340associated with a big data query. The relational tree340may be similar to the relational tree240inFIG.2, and include query characteristics and user parameters. The rules filter316may compare the relational tree340and/or the properties of the query engines in the engine list310according to the benchmarks and user rules. The rules filter316may generate a candidate list318including query engines selected according to the benchmarks and/or user rules. For example, as shown inFIG.3, the candidate list318includes the query engine 1 and the query engine 2, selected from query engines 1-n. Thus, instead of analyzing every query engine in the engine list310, the MLM320may only analyze the query engines 1 and 2 included in the candidate list318, saving time and computing power.

The candidate list318may be provided to the MLM320. The MLM320may assign a probability score to each of the query engines indicated on the candidate list318. The MLM320may be trained on historical big data queries using various engines. The MLM320may include a neural network (e.g., an attention unit) or other suitable machine learning model. Thus, the MLM320may be trained to recognize certain characteristics of queries and associated those characteristics with performance metrics of the query engines in the engine list310. For example, as shown inFIG.3, the MLM320may determine that the query engine 1 has a probability score of 7 (e.g., out of 10), while the query engine 2 has a probability score of 3. The MLM320may then output the probability scores associated with each of the query engines 1 and 2 as output322.

FIG.4Aillustrates a system400for executing and monitoring a big data query414, according to certain embodiments. The system400may be included in the system100inFIG.1, and/or be combined with the systems200and300inFIGS.2and3, respectively. The system400may include a query monitor408and a query engine412a. The query monitor408and the query engine412amay be implemented on a single computing system (e.g., the computing system102) or may be implemented on different systems. The query monitor408may be similar to the query monitor108inFIG.1. Further, the query monitor408may receive the output from an engine selector such as the engine selector306inFIG.3. Thus, the query monitor408may execute a big data query414via the query engine412abased at least in part on a probability score. The probability score may represent that a likelihood that the query engine412awill execute the big data query414successfully.

The query engine412amay execute the big data query414by accessing one or both of data sources416a-b. As the query engine412aprocesses the data from the data sources416a-b, the query engine412amay generate results444a. The results444amay be intermediate results, as opposed to the full results at the completion of the big data query414. During the execution of the big data query414, the query monitor408may monitor the query engine412afor performance metrics such as latency, response time, etc.

The query monitor408may also monitor the results444aas they are received from the query engine412a. The query monitor408may compare the results444ato user parameters associated with the big data query414, such as the user parameters234inFIG.2. If the results444acorrespond to the user parameters (e.g., an accuracy of the results444ais acceptable as compared to an accuracy parameter), the execution of the big data query414may continue. If the results and/or performance metrics are outside of the user parameters, the query monitor408may terminate the execution of the big data query414. In either case the query monitor408may then generate metadata450associated with the performance metrics and/or the intermediate results. The metadata450may be used to retrain an MLM such as the MLM320inFIG.3and/or used to adjust rules within the rules filter316.

FIG.4Billustrates a system400for dynamically switching big data query engines, according to certain embodiments. After determining that the results444aand/or a performance metric indicated that the query engine412ais not performing the big data query414according to the user parameters, the query monitor408may terminate the big data query414. The query monitor408may then re-execute the big data query414using the query engine412b. The query monitor408may re-execute the big data query414using the query engine412bbased on information previously provided by the engine selector. In some embodiments, the query monitor408may provide some or all of the metadata450to the engine selector and cause the engine selector to choose a different query engine (e.g., the query engine412b).

In re-executing the big data query414, the query engine412bmay also access and process data from the data sources416a-b. The query engine412bmay then provide the query monitor408with results444b. The results444bmay also be intermediate results. The query monitor408may monitor performance metrics of the query engine412band/or the results444b. The query monitor408may then generate the metadata450based at least in part on the performance metrics and/or the results444b.

FIG.5illustrate a system500for retraining a machine learning model520, according to certain embodiments. The system500may be used with some or all of the system100inFIG.1and/or the system300inFIG.3. The system500may include the MLM520and the training data560. The system500may also include a rules filter516. The training data560may include initial training data used to train the MLM520to assign probability scores to query engines, based on a likelihood that a query engine can complete a particular query successfully. For example, the training data560may include characteristics of a query including a data set size, a row count, a number of partitions, a column count, a column type map, a number of files, a query-operator count map, a query result reliability weight, a query execution time, and a query execution time weight. The initial training data may include historical queries executed by a plurality of query engines, such as the available query engines included in the engine list310inFIG.3. The training data560may be updated as a system such the system100selects query engines and executes queries. For example, query characteristics524and user parameters534associated with a query (e.g., the big data query214inFIG.2) may be included in the training data at some point after the query is received and/or executed. Similarly, metadata550associated with the query may be provided to the training data560. Thus, the training data560may be continuously updated as queries are performed.

After a number of queries are executed (e.g., 5, 10, 50, etc.), the training data560may be provided to the MLM520to retrain the MLM520. Thus, the MLM520may become more accurate in the selected query engines as the system executes more queries. Optionally, the rules filter516may be updated using at least some of the training data560. Thus, as applied to the system100, the system100may become more accurate and efficient in selecting and executing big data queries.

FIG.6illustrates a flowchart of a method600for selecting a big data query engine, according to certain embodiments. The method600may be performed by any of the systems described herein, such as the system100inFIG.1. The steps of the method600may be performed in a different order than that shown and/or combined. Some steps may be skipped altogether.

At step602, the method600may include receiving, by a computing system, a request for a big data query. The request for a big data query may include one or more characteristics associated with the big data query and one or more user parameters. For example, the request may be similar to the big data query214inFIG.2. The one or more characteristics may therefore be similar to the query characteristics224and the one or more user parameters may be similar to the user parameters234. The one or more characteristics may include a number of partitions, a row count, a query-type, a table size, and/or other such characteristics. The one or more user parameters may include a reliability parameter, a latency parameter, an accuracy parameter, and/or other such parameters.

At step604, the method600may include accessing, by the computing system, a set of rules. The set of rules may be based at least in part on respective properties of one or more big data query engines (e.g., the query engines in the engine list310inFIG.3). The set of rules may correlate at least one of the one or more characteristics associated with the big data query and the one or more user parameters with the respective properties of the big data query engines. The set of rules may be based on benchmarking of the big data query engines and/or user-generated rules, similar to the static rules filter inFIG.3.

At step606, the method600may include determining, by the computing system, a candidate list of the big data query engines. The candidate list may include a subset of the one or more big data query engines, similar to the candidate list318inFIG.3. The candidate list may be determined based at least in part on the set of rules. In some embodiments, the candidate list may be based at least in part on a relational tree. The relational tree may include the one or more characteristics and the one or more user parameters. The relational tree may be generated by a query analyzer such as the query analyzer204inFIG.2. The query analyzer may parse the query request to generate a hierarchical representation of the characteristics and the one or more parameters and the relationships between each.

At step608, the method600may include generating, by the computing system, a respective probability scores for each of the big data query engines included in the candidate list of big data query engines. The respective probability scores may represent a likelihood of each respective big data query engine successfully executing the query. The respective probability scores may be generated by an MLM. The MLM may include and attention module or other such model. The MLM may be initially trained on historical big data queries and/or other characteristics of queries and/or data sources. The other characteristics may include a data set size, a row count, a number of partitions, a column count, a column type map, a number of files, a query-operator count map, a query result reliability weight, a query execution time, a query execution time weight, and other such characteristics.

At step610, the method600may include selecting, by the computing system, a particular big data query engine based at least in part on the respective probability score of the particular big data query engine. For example, the computing system may select the particular big data query engine because it has the highest probability score as compared to the other big data query engines of the candidate list.

At step612, the method600may include executing, by the computing system, the big data query using the particular big data query engine. During the execution of the big data query, the computing system may monitor one or more performance metrics of the particular big data query engine. The computing system may also monitor intermediate results, received by from the big data query engine.

At step614, the method600may include identifying, by the computing system, a trigger indicating a performance issue with the particular big data query engine. For example, a latency performance metric may be outside of a corresponding user parameter. Additionally or alternatively, the intermediate data may be incorrect and/or contain errors beyond what is allowed by the user parameters. In some embodiments, the trigger may be in response to a user input, indicating a change in a user parameter.

At step616, the method600may include switching, by the computing device, the execution of the big data query to a second big data query engine of the candidate list of big data query engines. The second big data query engine may be determined via information already provided by the computing system, or some or all of the steps of the method600may be repeated to determine the second big data query engine.

In some embodiments, the identifying the trigger may further include monitoring the one or more performance metrics of the particular big data query engine. The computing system may then determine that the particular big data query engine is not performing to an expected level, based at least in part on the one or more performance metrics and/or the one or more user parameters. In response, the computing system may terminate the execution of the big data query by the particular big data query engine. The computing system may then execute the big data query using the second big data query engine. The second big data query engine may be selected in part on the respective probability score associated with the second big data query engine.

In some embodiments, the method600may also include determining, by the computing system one or more performance metrics of the particular big data query engine during the execution of the big data query. The computing system may then retrain the MLM using the performance metrics, the query characteristics, and/or the user parameters. The computing system may retrain the MLM after a certain number of queries are executed.

As noted above, infrastructure as a service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In an IaaS model, a cloud computing provider can host the infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., a hypervisor layer), or the like). In some cases, an IaaS provider may also supply a variety of services to accompany those infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, clustering software, etc.). Thus, as these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.

The VCN706can include a local peering gateway (LPG)710that can be communicatively coupled to a secure shell (SSH) VCN712via an LPG710contained in the SSH VCN712. The SSH VCN712can include an SSH subnet714, and the SSH VCN712can be communicatively coupled to a control plane VCN716via the LPG710contained in the control plane VCN716. Also, the SSH VCN712can be communicatively coupled to a data plane VCN718via an LPG710. The control plane VCN716and the data plane VCN718can be contained in a service tenancy719that can be owned and/or operated by the IaaS provider.

The control plane VCN716can include a control plane demilitarized zone (DMZ) tier720that acts as a perimeter network (e.g., portions of a corporate network between the corporate intranet and external networks). The DMZ-based servers may have restricted responsibilities and help keep breaches contained. Additionally, the DMZ tier720can include one or more load balancer (LB) subnet(s)722, a control plane app tier724that can include app subnet(s)726, a control plane data tier728that can include database (DB) subnet(s)730(e.g., frontend DB subnet(s) and/or backend DB subnet(s)). The LB subnet(s)722contained in the control plane DMZ tier720can be communicatively coupled to the app subnet(s)726contained in the control plane app tier724and an Internet gateway734that can be contained in the control plane VCN716, and the app subnet(s)726can be communicatively coupled to the DB subnet(s)730contained in the control plane data tier728and a service gateway736and a network address translation (NAT) gateway738. The control plane VCN716can include the service gateway736and the NAT gateway738.

The control plane VCN716can include a data plane mirror app tier740that can include app subnet(s)726. The app subnet(s)726contained in the data plane mirror app tier740can include a virtual network interface controller (VNIC)742that can execute a compute instance744. The compute instance744can communicatively couple the app subnet(s)726of the data plane mirror app tier740to app subnet(s)726that can be contained in a data plane app tier746.

The data plane VCN718can include the data plane app tier746, a data plane DMZ tier748, and a data plane data tier750. The data plane DMZ tier748can include LB subnet(s)722that can be communicatively coupled to the app subnet(s)726of the data plane app tier746and the Internet gateway734of the data plane VCN718. The app subnet(s)726can be communicatively coupled to the service gateway736of the data plane VCN718and the NAT gateway738of the data plane VCN718. The data plane data tier750can also include the DB subnet(s)730that can be communicatively coupled to the app subnet(s)726of the data plane app tier746.

The Internet gateway734of the control plane VCN716and of the data plane VCN718can be communicatively coupled to a metadata management service752that can be communicatively coupled to public Internet754. Public Internet754can be communicatively coupled to the NAT gateway738of the control plane VCN716and of the data plane VCN718. The service gateway736of the control plane VCN716and of the data plane VCN718can be communicatively couple to cloud services756.

In some examples, the service gateway736of the control plane VCN716or of the data plane VCN718can make application programming interface (API) calls to cloud services756without going through public Internet754. The API calls to cloud services756from the service gateway736can be one-way: the service gateway736can make API calls to cloud services756, and cloud services756can send requested data to the service gateway736. But, cloud services756may not initiate API calls to the service gateway736.

In some examples, the secure host tenancy704can be directly connected to the service tenancy719, which may be otherwise isolated. The secure host subnet708can communicate with the SSH subnet714through an LPG710that may enable two-way communication over an otherwise isolated system. Connecting the secure host subnet708to the SSH subnet714may give the secure host subnet708access to other entities within the service tenancy719.

The control plane VCN716may allow users of the service tenancy719to set up or otherwise provision desired resources. Desired resources provisioned in the control plane VCN716may be deployed or otherwise used in the data plane VCN718. In some examples, the control plane VCN716can be isolated from the data plane VCN718, and the data plane mirror app tier740of the control plane VCN716can communicate with the data plane app tier746of the data plane VCN718via VNICs742that can be contained in the data plane mirror app tier740and the data plane app tier746.

In some examples, users of the system, or customers, can make requests, for example create, read, update, or delete (CRUD) operations, through public Internet754that can communicate the requests to the metadata management service752. The metadata management service752can communicate the request to the control plane VCN716through the Internet gateway734. The request can be received by the LB subnet(s)722contained in the control plane DMZ tier720. The LB subnet(s)722may determine that the request is valid, and in response to this determination, the LB subnet(s)722can transmit the request to app subnet(s)726contained in the control plane app tier724. If the request is validated and requires a call to public Internet754, the call to public Internet754may be transmitted to the NAT gateway738that can make the call to public Internet754. Metadata that may be desired to be stored by the request can be stored in the DB subnet(s)730.

In some examples, the data plane mirror app tier740can facilitate direct communication between the control plane VCN716and the data plane VCN718. For example, changes, updates, or other suitable modifications to configuration may be desired to be applied to the resources contained in the data plane VCN718. Via a VNIC742, the control plane VCN716can directly communicate with, and can thereby execute the changes, updates, or other suitable modifications to configuration to, resources contained in the data plane VCN718.

In some embodiments, the control plane VCN716and the data plane VCN718can be contained in the service tenancy719. In this case, the user, or the customer, of the system may not own or operate either the control plane VCN716or the data plane VCN718. Instead, the IaaS provider may own or operate the control plane VCN716and the data plane VCN718, both of which may be contained in the service tenancy719. This embodiment can enable isolation of networks that may prevent users or customers from interacting with other users', or other customers', resources. Also, this embodiment may allow users or customers of the system to store databases privately without needing to rely on public Internet754, which may not have a desired level of threat prevention, for storage.

In other embodiments, the LB subnet(s)722contained in the control plane VCN716can be configured to receive a signal from the service gateway736. In this embodiment, the control plane VCN716and the data plane VCN718may be configured to be called by a customer of the IaaS provider without calling public Internet754. Customers of the IaaS provider may desire this embodiment since database(s) that the customers use may be controlled by the IaaS provider and may be stored on the service tenancy719, which may be isolated from public Internet754.

FIG.8is a block diagram800illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators802(e.g., service operators702ofFIG.7) can be communicatively coupled to a secure host tenancy804(e.g., the secure host tenancy704ofFIG.7) that can include a virtual cloud network (VCN)806(e.g., the VCN706ofFIG.7) and a secure host subnet808(e.g., the secure host subnet708ofFIG.7). The VCN806can include a local peering gateway (LPG)810(e.g., the LPG710ofFIG.7) that can be communicatively coupled to a secure shell (SSH) VCN812(e.g., the SSH VCN712ofFIG.7) via an LPG710contained in the SSH VCN812. The SSH VCN812can include an SSH subnet814(e.g., the SSH subnet714ofFIG.7), and the SSH VCN812can be communicatively coupled to a control plane VCN816(e.g., the control plane VCN716ofFIG.7) via an LPG810contained in the control plane VCN816. The control plane VCN816can be contained in a service tenancy819(e.g., the service tenancy719ofFIG.7), and the data plane VCN818(e.g., the data plane VCN718ofFIG.7) can be contained in a customer tenancy821that may be owned or operated by users, or customers, of the system.

The control plane VCN816can include a control plane DMZ tier820(e.g., the control plane DMZ tier720ofFIG.7) that can include LB subnet(s)822(e.g., LB subnet(s)722ofFIG.7), a control plane app tier824(e.g., the control plane app tier724ofFIG.7) that can include app subnet(s)826(e.g., app subnet(s)726ofFIG.7), a control plane data tier828(e.g., the control plane data tier728ofFIG.7) that can include database (DB) subnet(s)830(e.g., similar to DB subnet(s)730ofFIG.7). The LB subnet(s)822contained in the control plane DMZ tier820can be communicatively coupled to the app subnet(s)826contained in the control plane app tier824and an Internet gateway834(e.g., the Internet gateway734ofFIG.7) that can be contained in the control plane VCN816, and the app subnet(s)826can be communicatively coupled to the DB subnet(s)830contained in the control plane data tier828and a service gateway836(e.g., the service gateway736ofFIG.7) and a network address translation (NAT) gateway838(e.g., the NAT gateway738ofFIG.7). The control plane VCN816can include the service gateway836and the NAT gateway838.

The control plane VCN816can include a data plane mirror app tier840(e.g., the data plane mirror app tier740ofFIG.7) that can include app subnet(s)826. The app subnet(s)826contained in the data plane mirror app tier840can include a virtual network interface controller (VNIC)842(e.g., the VNIC of742) that can execute a compute instance844(e.g., similar to the compute instance744ofFIG.7). The compute instance844can facilitate communication between the app subnet(s)826of the data plane mirror app tier840and the app subnet(s)826that can be contained in a data plane app tier846(e.g., the data plane app tier746ofFIG.7) via the VNIC842contained in the data plane mirror app tier840and the VNIC842contained in the data plane app tier846.

The Internet gateway834contained in the control plane VCN816can be communicatively coupled to a metadata management service852(e.g., the metadata management service752ofFIG.7) that can be communicatively coupled to public Internet854(e.g., public Internet754ofFIG.7). Public Internet854can be communicatively coupled to the NAT gateway838contained in the control plane VCN816. The service gateway836contained in the control plane VCN816can be communicatively couple to cloud services856(e.g., cloud services756ofFIG.7).

In some examples, the data plane VCN818can be contained in the customer tenancy821. In this case, the IaaS provider may provide the control plane VCN816for each customer, and the IaaS provider may, for each customer, set up a unique compute instance844that is contained in the service tenancy819. Each compute instance844may allow communication between the control plane VCN816, contained in the service tenancy819, and the data plane VCN818that is contained in the customer tenancy821. The compute instance844may allow resources, that are provisioned in the control plane VCN816that is contained in the service tenancy819, to be deployed or otherwise used in the data plane VCN818that is contained in the customer tenancy821.

In other examples, the customer of the IaaS provider may have databases that live in the customer tenancy821. In this example, the control plane VCN816can include the data plane mirror app tier840that can include app subnet(s)826. The data plane mirror app tier840can reside in the data plane VCN818, but the data plane mirror app tier840may not live in the data plane VCN818. That is, the data plane mirror app tier840may have access to the customer tenancy821, but the data plane mirror app tier840may not exist in the data plane VCN818or be owned or operated by the customer of the IaaS provider. The data plane mirror app tier840may be configured to make calls to the data plane VCN818but may not be configured to make calls to any entity contained in the control plane VCN816. The customer may desire to deploy or otherwise use resources in the data plane VCN818that are provisioned in the control plane VCN816, and the data plane mirror app tier840can facilitate the desired deployment, or other usage of resources, of the customer.

In some embodiments, the customer of the IaaS provider can apply filters to the data plane VCN818. In this embodiment, the customer can determine what the data plane VCN818can access, and the customer may restrict access to public Internet854from the data plane VCN818. The IaaS provider may not be able to apply filters or otherwise control access of the data plane VCN818to any outside networks or databases. Applying filters and controls by the customer onto the data plane VCN818, contained in the customer tenancy821, can help isolate the data plane VCN818from other customers and from public Internet854.

In some embodiments, cloud services856can be called by the service gateway836to access services that may not exist on public Internet854, on the control plane VCN816, or on the data plane VCN818. The connection between cloud services856and the control plane VCN816or the data plane VCN818may not be live or continuous. Cloud services856may exist on a different network owned or operated by the IaaS provider. Cloud services856may be configured to receive calls from the service gateway836and may be configured to not receive calls from public Internet854. Some cloud services856may be isolated from other cloud services856, and the control plane VCN816may be isolated from cloud services856that may not be in the same region as the control plane VCN816. For example, the control plane VCN816may be located in “Region 1,” and cloud service “Deployment 7,” may be located in Region 1 and in “Region 2.” If a call to Deployment 7 is made by the service gateway836contained in the control plane VCN816located in Region 1, the call may be transmitted to Deployment 7 in Region 1. In this example, the control plane VCN816, or Deployment 7 in Region 1, may not be communicatively coupled to, or otherwise in communication with, Deployment 7 in Region 2.

FIG.9is a block diagram900illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators902(e.g., service operators702ofFIG.7) can be communicatively coupled to a secure host tenancy904(e.g., the secure host tenancy704ofFIG.7) that can include a virtual cloud network (VCN)906(e.g., the VCN706ofFIG.7) and a secure host subnet908(e.g., the secure host subnet708ofFIG.7). The VCN906can include an LPG910(e.g., the LPG710ofFIG.7) that can be communicatively coupled to an SSH VCN912(e.g., the SSH VCN712ofFIG.7) via an LPG910contained in the SSH VCN912. The SSH VCN912can include an SSH subnet914(e.g., the SSH subnet714ofFIG.7), and the SSH VCN912can be communicatively coupled to a control plane VCN916(e.g., the control plane VCN716ofFIG.7) via an LPG910contained in the control plane VCN916and to a data plane VCN918(e.g., the data plane718ofFIG.7) via an LPG910contained in the data plane VCN918. The control plane VCN916and the data plane VCN918can be contained in a service tenancy919(e.g., the service tenancy719ofFIG.7).

The control plane VCN916can include a control plane DMZ tier920(e.g., the control plane DMZ tier720ofFIG.7) that can include load balancer (LB) subnet(s)922(e.g., LB subnet(s)722ofFIG.7), a control plane app tier924(e.g., the control plane app tier724ofFIG.7) that can include app subnet(s)926(e.g., similar to app subnet(s)726ofFIG.7), a control plane data tier928(e.g., the control plane data tier728ofFIG.7) that can include DB subnet(s)930. The LB subnet(s)922contained in the control plane DMZ tier920can be communicatively coupled to the app subnet(s)926contained in the control plane app tier924and to an Internet gateway934(e.g., the Internet gateway734ofFIG.7) that can be contained in the control plane VCN916, and the app subnet(s)926can be communicatively coupled to the DB subnet(s)930contained in the control plane data tier928and to a service gateway936(e.g., the service gateway ofFIG.7) and a network address translation (NAT) gateway938(e.g., the NAT gateway738ofFIG.7). The control plane VCN916can include the service gateway936and the NAT gateway938.

The data plane VCN918can include a data plane app tier946(e.g., the data plane app tier746ofFIG.7), a data plane DMZ tier948(e.g., the data plane DMZ tier748ofFIG.7), and a data plane data tier950(e.g., the data plane data tier750ofFIG.7). The data plane DMZ tier948can include LB subnet(s)922that can be communicatively coupled to trusted app subnet(s)960and untrusted app subnet(s)962of the data plane app tier946and the Internet gateway934contained in the data plane VCN918. The trusted app subnet(s)960can be communicatively coupled to the service gateway936contained in the data plane VCN918, the NAT gateway938contained in the data plane VCN918, and DB subnet(s)930contained in the data plane data tier950. The untrusted app subnet(s)962can be communicatively coupled to the service gateway936contained in the data plane VCN918and DB subnet(s)930contained in the data plane data tier950. The data plane data tier950can include DB subnet(s)930that can be communicatively coupled to the service gateway936contained in the data plane VCN918.

The untrusted app subnet(s)962can include one or more primary VNICs964(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs)966(1)-(N). Each tenant VM966(1)-(N) can be communicatively coupled to a respective app subnet967(1)-(N) that can be contained in respective container egress VCNs968(1)-(N) that can be contained in respective customer tenancies970(1)-(N). Respective secondary VNICs972(1)-(N) can facilitate communication between the untrusted app subnet(s)962contained in the data plane VCN918and the app subnet contained in the container egress VCNs968(1)-(N). Each container egress VCNs968(1)-(N) can include a NAT gateway938that can be communicatively coupled to public Internet954(e.g., public Internet754ofFIG.7).

The Internet gateway934contained in the control plane VCN916and contained in the data plane VCN918can be communicatively coupled to a metadata management service952(e.g., the metadata management system752ofFIG.7) that can be communicatively coupled to public Internet954. Public Internet954can be communicatively coupled to the NAT gateway938contained in the control plane VCN916and contained in the data plane VCN918. The service gateway936contained in the control plane VCN916and contained in the data plane VCN918can be communicatively couple to cloud services956.

In some examples, the customer of the IaaS provider may grant temporary network access to the IaaS provider and request a function to be attached to the data plane app tier946. Code to run the function may be executed in the VMs966(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN918. Each VM966(1)-(N) may be connected to one customer tenancy970. Respective containers971(1)-(N) contained in the VMs966(1)-(N) may be configured to run the code. In this case, there can be a dual isolation (e.g., the containers971(1)-(N) running code, where the containers971(1)-(N) may be contained in at least the VM966(1)-(N) that are contained in the untrusted app subnet(s)962), which may help prevent incorrect or otherwise undesirable code from damaging the network of the IaaS provider or from damaging a network of a different customer. The containers971(1)-(N) may be communicatively coupled to the customer tenancy970and may be configured to transmit or receive data from the customer tenancy970. The containers971(1)-(N) may not be configured to transmit or receive data from any other entity in the data plane VCN918. Upon completion of running the code, the IaaS provider may kill or otherwise dispose of the containers971(1)-(N).

In some embodiments, the trusted app subnet(s)960may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted app subnet(s)960may be communicatively coupled to the DB subnet(s)930and be configured to execute CRUD operations in the DB subnet(s)930. The untrusted app subnet(s)962may be communicatively coupled to the DB subnet(s)930, but in this embodiment, the untrusted app subnet(s) may be configured to execute read operations in the DB subnet(s)930. The containers971(1)-(N) that can be contained in the VM966(1)-(N) of each customer and that may run code from the customer may not be communicatively coupled with the DB subnet(s)930.

In other embodiments, the control plane VCN916and the data plane VCN918may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN916and the data plane VCN918. However, communication can occur indirectly through at least one method. An LPG910may be established by the IaaS provider that can facilitate communication between the control plane VCN916and the data plane VCN918. In another example, the control plane VCN916or the data plane VCN918can make a call to cloud services956via the service gateway936. For example, a call to cloud services956from the control plane VCN916can include a request for a service that can communicate with the data plane VCN918.

FIG.10is a block diagram1000illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators1002(e.g., service operators702ofFIG.7) can be communicatively coupled to a secure host tenancy1004(e.g., the secure host tenancy704ofFIG.7) that can include a virtual cloud network (VCN)1006(e.g., the VCN706ofFIG.7) and a secure host subnet1008(e.g., the secure host subnet708ofFIG.7). The VCN1006can include an LPG1010(e.g., the LPG710ofFIG.7) that can be communicatively coupled to an SSH VCN1012(e.g., the SSH VCN712ofFIG.7) via an LPG1010contained in the SSH VCN1012. The SSH VCN1012can include an SSH subnet1014(e.g., the SSH subnet714ofFIG.7), and the SSH VCN1012can be communicatively coupled to a control plane VCN1016(e.g., the control plane VCN716ofFIG.7) via an LPG1010contained in the control plane VCN1016and to a data plane VCN1018(e.g., the data plane718ofFIG.7) via an LPG1010contained in the data plane VCN1018. The control plane VCN1016and the data plane VCN1018can be contained in a service tenancy1019(e.g., the service tenancy719ofFIG.7).

The control plane VCN1016can include a control plane DMZ tier1020(e.g., the control plane DMZ tier720ofFIG.7) that can include LB subnet(s)1022(e.g., LB subnet(s)722ofFIG.7), a control plane app tier1024(e.g., the control plane app tier724ofFIG.7) that can include app subnet(s)1026(e.g., app subnet(s)726ofFIG.7), a control plane data tier1028(e.g., the control plane data tier728ofFIG.7) that can include DB subnet(s)1030(e.g., DB subnet(s)930ofFIG.9). The LB subnet(s)1022contained in the control plane DMZ tier1020can be communicatively coupled to the app subnet(s)1026contained in the control plane app tier1024and to an Internet gateway1034(e.g., the Internet gateway734ofFIG.7) that can be contained in the control plane VCN1016, and the app subnet(s)1026can be communicatively coupled to the DB subnet(s)1030contained in the control plane data tier1028and to a service gateway1036(e.g., the service gateway ofFIG.7) and a network address translation (NAT) gateway1038(e.g., the NAT gateway738ofFIG.7). The control plane VCN1016can include the service gateway1036and the NAT gateway1038.

The data plane VCN1018can include a data plane app tier1046(e.g., the data plane app tier746ofFIG.7), a data plane DMZ tier1048(e.g., the data plane DMZ tier748ofFIG.7), and a data plane data tier1050(e.g., the data plane data tier750ofFIG.7). The data plane DMZ tier1048can include LB subnet(s)1022that can be communicatively coupled to trusted app subnet(s)1060(e.g., trusted app subnet(s)960ofFIG.9) and untrusted app subnet(s)1062(e.g., untrusted app subnet(s)962ofFIG.9) of the data plane app tier1046and the Internet gateway1034contained in the data plane VCN1018. The trusted app subnet(s)1060can be communicatively coupled to the service gateway1036contained in the data plane VCN1018, the NAT gateway1038contained in the data plane VCN1018, and DB subnet(s)1030contained in the data plane data tier1050. The untrusted app subnet(s)1062can be communicatively coupled to the service gateway1036contained in the data plane VCN1018and DB subnet(s)1030contained in the data plane data tier1050. The data plane data tier1050can include DB subnet(s)1030that can be communicatively coupled to the service gateway1036contained in the data plane VCN1018.

The untrusted app subnet(s)1062can include primary VNICs1064(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs)1066(1)-(N) residing within the untrusted app subnet(s)1062. Each tenant VM1066(1)-(N) can run code in a respective container1067(1)-(N), and be communicatively coupled to an app subnet1026that can be contained in a data plane app tier1046that can be contained in a container egress VCN1068. Respective secondary VNICs1072(1)-(N) can facilitate communication between the untrusted app subnet(s)1062contained in the data plane VCN1018and the app subnet contained in the container egress VCN1068. The container egress VCN can include a NAT gateway1038that can be communicatively coupled to public Internet1054(e.g., public Internet754ofFIG.7).

The Internet gateway1034contained in the control plane VCN1016and contained in the data plane VCN1018can be communicatively coupled to a metadata management service1052(e.g., the metadata management system752ofFIG.7) that can be communicatively coupled to public Internet1054. Public Internet1054can be communicatively coupled to the NAT gateway1038contained in the control plane VCN1016and contained in the data plane VCN1018. The service gateway1036contained in the control plane VCN1016and contained in the data plane VCN1018can be communicatively couple to cloud services1056.

In some examples, the pattern illustrated by the architecture of block diagram1000ofFIG.10may be considered an exception to the pattern illustrated by the architecture of block diagram900ofFIG.9and may be desirable for a customer of the IaaS provider if the IaaS provider cannot directly communicate with the customer (e.g., a disconnected region). The respective containers1067(1)-(N) that are contained in the VMs1066(1)-(N) for each customer can be accessed in real-time by the customer. The containers1067(1)-(N) may be configured to make calls to respective secondary VNICs1072(1)-(N) contained in app subnet(s)1026of the data plane app tier1046that can be contained in the container egress VCN1068. The secondary VNICs1072(1)-(N) can transmit the calls to the NAT gateway1038that may transmit the calls to public Internet1054. In this example, the containers1067(1)-(N) that can be accessed in real-time by the customer can be isolated from the control plane VCN1016and can be isolated from other entities contained in the data plane VCN1018. The containers1067(1)-(N) may also be isolated from resources from other customers.

In other examples, the customer can use the containers1067(1)-(N) to call cloud services1056. In this example, the customer may run code in the containers1067(1)-(N) that requests a service from cloud services1056. The containers1067(1)-(N) can transmit this request to the secondary VNICs1072(1)-(N) that can transmit the request to the NAT gateway that can transmit the request to public Internet1054. Public Internet1054can transmit the request to LB subnet(s)1022contained in the control plane VCN1016via the Internet gateway1034. In response to determining the request is valid, the LB subnet(s) can transmit the request to app subnet(s)1026that can transmit the request to cloud services1056via the service gateway1036.

FIG.11illustrates an example computer system1100, in which various embodiments may be implemented. The system1100may be used to implement any of the computer systems described above. As shown in the figure, computer system1100includes a processing unit1104that communicates with a number of peripheral subsystems via a bus subsystem1102. These peripheral subsystems may include a processing acceleration unit1106, an I/O subsystem1108, a storage subsystem1118and a communications subsystem1124. Storage subsystem1118includes tangible computer-readable storage media1122and a system memory1110.

Bus subsystem1102provides a mechanism for letting the various components and subsystems of computer system1100communicate with each other as intended. Although bus subsystem1102is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem1102may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, which can be implemented as a Mezzanine bus manufactured to the IEEE P1386.1 standard.

Processing unit1104, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of computer system1100. One or more processors may be included in processing unit1104. These processors may include single core or multicore processors. In certain embodiments, processing unit1104may be implemented as one or more independent processing units1132and/or1134with single or multicore processors included in each processing unit. In other embodiments, processing unit1104may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

In various embodiments, processing unit1104can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processor(s)1104and/or in storage subsystem1118. Through suitable programming, processor(s)1104can provide various functionalities described above. Computer system1100may additionally include a processing acceleration unit1106, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.

Computer system1100may comprise a storage subsystem1118that provides a tangible non-transitory computer-readable storage medium for storing software and data constructs that provide the functionality of the embodiments described in this disclosure. The software can include programs, code modules, instructions, scripts, etc., that when executed by one or more cores or processors of processing unit1104provide the functionality described above. Storage subsystem1118may also provide a repository for storing data used in accordance with the present disclosure.

As depicted in the example inFIG.11, storage subsystem1118can include various components including a system memory1110, computer-readable storage media1122, and a computer readable storage media reader1120. System memory1110may store program instructions that are loadable and executable by processing unit1104. System memory1110may also store data that is used during the execution of the instructions and/or data that is generated during the execution of the program instructions. Various different kinds of programs may be loaded into system memory1110including but not limited to client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), virtual machines, containers, etc.

System memory1110may also store an operating system1116. Examples of operating system1116may include various versions of Microsoft Windows®, Apple Macintosh®, and/or Linux operating systems, a variety of commercially-available UNIX® or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems, the Google Chrome® OS, and the like) and/or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems. In certain implementations where computer system1100executes one or more virtual machines, the virtual machines along with their guest operating systems (GOSs) may be loaded into system memory1110and executed by one or more processors or cores of processing unit1104.

System memory1110can come in different configurations depending upon the type of computer system1100. For example, system memory1110may be volatile memory (such as random access memory (RAM)) and/or non-volatile memory (such as read-only memory (ROM), flash memory, etc.) Different types of RAM configurations may be provided including a static random access memory (SRAM), a dynamic random access memory (DRAM), and others. In some implementations, system memory1110may include a basic input/output system (BIOS) containing basic routines that help to transfer information between elements within computer system1100, such as during start-up.

Computer-readable storage media1122may represent remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing, storing, computer-readable information for use by computer system1100including instructions executable by processing unit1104of computer system1100.

Computer-readable storage media1122can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information. This can include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media.

Machine-readable instructions executable by one or more processors or cores of processing unit1104may be stored on a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium can include physically tangible memory or storage devices that include volatile memory storage devices and/or non-volatile storage devices. Examples of non-transitory computer-readable storage medium include magnetic storage media (e.g., disk or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM, or flash memory, hard drives, floppy drives, detachable memory drives (e.g., USB drives), or other type of storage device.

Communications subsystem1124provides an interface to other computer systems and networks. Communications subsystem1124serves as an interface for receiving data from and transmitting data to other systems from computer system1100. For example, communications subsystem1124may enable computer system1100to connect to one or more devices via the Internet. In some embodiments communications subsystem1124can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem1124can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

In some embodiments, communications subsystem1124may also receive input communication in the form of structured and/or unstructured data feeds1126, event streams1128, event updates1130, and the like on behalf of one or more users who may use computer system1100.

Additionally, communications subsystem1124may also be configured to receive data in the form of continuous data streams, which may include event streams1128of real-time events and/or event updates1130, that may be continuous or unbounded in nature with no explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measuring tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

Communications subsystem1124may also be configured to output the structured and/or unstructured data feeds1126, event streams1128, event updates1130, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system1100.