Patent Description:
A cloud data warehouse (also referred to as a "network-based data warehouse" or simply as a "data warehouse") is a network-based system used for data analysis and reporting that comprises a central repository of integrated data from one or more disparate sources. A cloud data warehouse can store current and historical data that can be used for creating analytical reports for an enterprise. To this end, data warehouses typically provide business intelligence tools, tools to extract, transform, and load data into the repository, and tools to manage and retrieve metadata.

In some instances, a user of the network-based data warehouse may wish to make use of functionality that is external to the data warehouse system to analyze or otherwise process data stored by the data warehouse. For example, a user may wish to utilize functionality provided by a third party (e.g., a third-party geocoder) within the context of the network-based data warehouse. As another example, a user may wish to encode or reuse existing business logic (e.g., a complex loss calculation or a machine learning algorithm) within the context of the data warehouse. As yet another example, a user may wish to notify or otherwise trigger external functionality such as a notification system within the context of a data warehouse. As still another example, a user may wish to export data from the cloud warehouse in a way that is driven from within the context of the data warehouse. However, conventional cloud data warehouses do not provide users an ability to call out to a remote software component (e.g., code) that can provide such functionality.

<CIT> describes, an elastic, massively parallel processing (MPP) data warehouse leveraging a cloud computing system, wherein queries are received via one or more API endpoints are decomposed into parallelizable subqueries and executed across a heterogenous set of demand-instantiable computing units. Therein, available computing units vary in capacity, storage, memory, bandwidth, and hardware; the specific mix of computing units instantiated is determined dynamically according to the specifics of the query. Better performance is obtained by modifying the mix of instantiated computing units according to a machine learning algorithm.

Reference will now be made in detail to specific example embodiments for carrying out the inventive subject matter. Examples of these specific embodiments are illustrated in the accompanying drawings, and specific details are set forth in the following description in order to provide a thorough understanding of the subject matter.

As noted above, conventional network-based data warehouses do not provide users with the ability to call out to a remote software component that provides functionality that is external to the data warehouse. Aspects of the present disclosure address the above and other deficiencies of conventional data warehouses by providing a network-based data warehouse system that provides users an ability to invoke external functionality provided by a remote software component. The network-based data warehouse system described herein provides an ability to bind a function (e.g., a Structured Query Language (SQL) function), table function, or procedure to remote software code that is external to the data warehouse and exposed as a web application programming interface (API).

The network-based data warehouse system provides users a mechanism to author functions and stored procedures, that are backed by externally implemented web endpoints (e.g., HyperText Transfer Protocol (HTTP) Representational State Transfer (REST) endpoints) in an externally managed web API management system provided a cloud computing service platform (e.g., Amazon Web Services® (AWS), Microsoft Azure®, or Google Cloud Services®). Users are responsible for provisioning web endpoints and configuring the endpoints based on business logic within the storage platform. In some instances, the web API management system proxy requests to Lambda functions, and in other instances, the web API management system transforms and forwards the requests to third-party software components that are external to the data warehouse system. The network-based data warehouse system enables external functions provided by these external software components to be used in queries like user defined functions, user-defined table functions and stored procedures.

The network-based data warehouse system stores various data objects to enable the invocation of external functionality provided by remote software components. The data objects store information that is used by the network-based data warehouse to obtain temporary security credentials to be used in invoking the external functionality via a web API management system provided by a cloud computing platform. During execution of a query, the network-based data warehouse system authenticates with a target endpoint, via an authentication system of the cloud computing service platform, using the temporary security credentials, and invokes functionality at the endpoint with batches of target data as defined in the query. Target data may, for example, comprise binary data, JavaScript Object Notation (JSON) encoded data or other textual formats such as eXtensible Markup Language (XML). Target data may be passed inline with HTTP requests/responses or written to a commonly accessed storage provided by the cloud computing service platform (e.g., Amazon® Simple Storage Service (S3®)). User data stored by the network-based data warehouse system is encoded in a format suitable to be passed through HTTP requests and responses.

From the perspective of a user, external code can be made a seamless part of the data warehouse functionality similar to any internally-defined function or procedure. That is, the data warehouse can access systems that are, by their nature, external to the data warehouse (e.g., geocoding systems). Further, users are enabled to use any arbitrary external code regardless of the language used to author the code or the system on which the code executes. Moreover, the network-based data warehouse described herein allows users to invoke external functionality while avoiding security concerns that can arise from executing the code within the data warehouse system and do so in a manner that is orthogonal to the functionality of the data warehouse (e.g., an external function can be used in any query). In addition, the technique for invoking external functionality from the data warehouse externalizes security-sensitive authentication information since this information is handled by the cloud computing service platform rather than the network-based data warehouse itself.

In an example, a user of the network-based data warehouse has built a score function using a machine-learning algorithm and has deployed a scoring API to facilitate calls to the score function. The user can bind a function within the network-based data warehouse to the external code and issue an SQL query to the network-based data warehouse that references the function to score a set of input values. When executing the query, the network-based data warehouse accesses the set of input values, makes a call to the score function API, and incorporates the results received from the external score function.

<FIG> illustrates an example computing environment <NUM> in which a network-based data warehouse system <NUM> invokes an external function provided by a remote software component, in accordance with some embodiments of the present disclosure. To avoid obscuring the inventive subject matter with unnecessary detail, various functional components that are not germane to conveying an understanding of the inventive subject matter have been omitted from <FIG> and subsequent <FIG>. However, a skilled artisan will readily recognize that various additional functional components may be included as part of the computing environment <NUM> to facilitate additional functionality that is not specifically described herein.

As shown, the computing environment <NUM> comprises the network-based data warehouse system <NUM>, a cloud computing service platform <NUM> (e.g., AWS®, Microsoft Azure®, or Google Cloud Services®), and a remote computing environment <NUM>. The data warehouse system <NUM> is a network-based system used for reporting and analysis of integrated data from one or more disparate sources (e.g., the cloud computing service platform <NUM>). The cloud computing service platform <NUM> comprises a plurality of computing machines and provides on-demand computer system resources such as data storage and computing power to the network-based data warehouse system <NUM>.

The remote computing environment <NUM> comprises one or more computing machines that execute a remote software component <NUM> to provide additional functionality to users of the network-based data warehouse system <NUM>. In some embodiments, the remote computing environment <NUM> may be included in or provided by the cloud computing service platform <NUM>.

The remote software component <NUM> comprises a set of machine-readable instructions (e.g., code) that, when executed by the remote computing environment <NUM>, cause the remote computing environment <NUM> to provide certain functionality. The remote software component <NUM> may operate on input data and generates result data based on processing, analyzing, or otherwise transforming the input data. As an example, the remote software component <NUM> may comprise a scalar function, a table function, or a stored procedure. External scalar functions can, for example, be used as a mechanism to trigger actions in external systems, which can enhance existing extract, transform, load (ETL) pipelines or enable entirely new data processing scenarios. For example, an external scalar function can be used to send an email or notification or to start a machine learning training job in a component of the cloud computing service platform <NUM>. External stored procedures can, for example, run nested SQL queries in the context of the same session that called the stored procedure.

The network-based data warehouse system <NUM> comprises an access management system <NUM>, a compute service manager <NUM>, an execution platform <NUM>, and a database <NUM>. The access management system <NUM> is the internal access control system for the network-based data warehouse system <NUM> and enables administrative users to manage access to resources and services provided by the network-based data warehouse system <NUM>. Administrative users can create and manage users, roles, and groups, and use permissions to allow or deny access to resources and services.

The compute service manager <NUM> coordinates and manages operations of the network-based data warehouse system <NUM>. The compute service manager <NUM> also performs query optimization and compilation as well as managing clusters of computing services that provide compute resources (also referred to as "virtual warehouses"). The compute service manager <NUM> can support any number of client accounts such as end users providing data storage and retrieval requests, system administrators managing the systems and methods described herein, and other components/devices that interact with compute service manager <NUM>.

The compute service manager <NUM> is also coupled to database <NUM>, which is associated with the entirety of data stored the computing environment <NUM>. The database <NUM> stores data pertaining to various functions and aspects associated with the network-based data warehouse system <NUM> and its users. For example, the database <NUM> stores various data objects that enable the network-based data warehouse system <NUM> to invoke external functionality provided by the remote software component <NUM>. Further details regarding creation and use of these data objects are discussed below in reference to <FIG>.

In some embodiments, database <NUM> includes a summary of data stored in remote data storage systems as well as data available from a local cache. Additionally, database <NUM> may include information regarding how data is organized in the remote data storage systems and the local caches. Database <NUM> allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from a storage device.

The compute service manager <NUM> is further coupled to the execution platform <NUM>, which provides multiple computing resources that execute various data storage and data retrieval tasks. Execution platform <NUM> is coupled to storage platform <NUM> provided by the cloud computing service platform <NUM>. The storage platform <NUM> comprises multiple data storage devices <NUM>-<NUM> to <NUM>-N. In some embodiments, data storage devices <NUM>-<NUM> to <NUM>-N are cloud-based storage devices located in one or more geographic locations. For example, data storage devices <NUM>-<NUM> to <NUM>-N may be part of a public cloud infrastructure or a private cloud infrastructure. Data storage devices <NUM>-<NUM> to <NUM>-N may be hard disk drives (HDDs), solid state drives (SSDs), storage clusters, Amazon S3TM storage systems or any other data storage technology. Additionally, cloud computing service platform <NUM> may include distributed file systems (such as Hadoop Distributed File Systems (HDFS)), object storage systems, and the like.

The execution platform <NUM> comprises a plurality of compute nodes. A set of processes on a compute node executes a query plan compiled by the compute service manager <NUM>. The set of processes can include: a first process to execute the query plan; a second process to monitor and delete micro-partition files using a least recently used (LRU) policy, and implement an out of memory (OOM) error mitigation process; a third process that extracts health information from process logs and status to send back to the compute service manager <NUM>; a fourth process to establish communication with the compute service manager <NUM> after a system boot; and a fifth process to handle all communication with a compute cluster for a given job provided by the compute service manager <NUM> and to communicate information back to the compute service manager <NUM> and other compute nodes of the execution platform <NUM>.

The cloud computing service platform <NUM> also comprises an access management system <NUM> and a web API management system <NUM>. The access management system <NUM> is an access control system provided by the cloud computing service platform <NUM> that allows users to create and manage users, roles, and groups, and use permissions to allow or deny access to cloud services and resources within the context of the cloud computing service platform <NUM>. A user can, for example, create a role within the context of the cloud computing service platform <NUM> that has permissions to make web calls to the remote software component <NUM> via the web API management system <NUM>. The access management system <NUM> of the network-based data warehouse system <NUM> and the access management system <NUM> of the cloud computing service platform <NUM> can communicate and share information so as to enable access and management of resources and services shared by users of both the network-based data warehouse system <NUM> and the cloud computing service platform <NUM>.

The web API management system <NUM> handles tasks involved in accepting and processing concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. The web API management system <NUM> provides HTTP proxy service for creating, publishing, maintaining, securing, and monitoring APIs (e.g., REST APIs).

In some embodiments, communication links between elements of the computing environment <NUM> are implemented via one or more data communication networks. These data communication networks may utilize any communication protocol and any type of communication medium. In some embodiments, the data communication networks are a combination of two or more data communication networks (or sub-networks) coupled to one another. In alternate embodiments, these communication links are implemented using any type of communication medium and any communication protocol.

As shown in <FIG>, data storage devices <NUM>-<NUM> to <NUM>-N are decoupled from the computing resources associated with the execution platform <NUM>. This architecture supports dynamic changes to the network-based data warehouse <NUM> based on the changing data storage/retrieval needs as well as the changing needs of the users and systems accessing data processing platform <NUM>. The support of dynamic changes allows network-based data warehouse <NUM> to scale quickly in response to changing demands on the systems and components within network-based data warehouse <NUM>. The decoupling of the computing resources from the data storage devices supports the storage of large amounts of data without requiring a corresponding large amount of computing resources. Similarly, this decoupling of resources supports a significant increase in the computing resources utilized at a particular time without requiring a corresponding increase in the available data storage resources.

Compute service manager <NUM>, database <NUM>, execution platform <NUM>, cloud computing service platform <NUM>, and remote computing environment <NUM> are shown in <FIG> as individual components. However, each of compute service manager <NUM>, database <NUM>, execution platform <NUM>, cloud computing service platform <NUM>, and remote computing environment may be implemented as a distributed system (e.g., distributed across multiple systems/platforms at multiple geographic locations). Additionally, each of compute service manager <NUM>, database <NUM>, execution platform <NUM>, and cloud computing service platform <NUM> can be scaled up or down (independently of one another) depending on changes to the requests received and the changing needs of data processing platform <NUM>. Thus, in the described embodiments, the network-based data warehouse <NUM> is dynamic and supports regular changes to meet the current data processing needs.

During typical operation, the network-based data warehouse <NUM> processes multiple jobs determined by the compute service manager <NUM>. These jobs are scheduled and managed by the compute service manager <NUM> to determine when and how to execute the job. For example, the compute service manager <NUM> may divide the job into multiple discrete tasks and may determine what data is needed to execute each of the multiple discrete tasks. The compute service manager <NUM> may assign each of the multiple discrete tasks to one or more nodes of the execution platform <NUM> to process the task. The compute service manager <NUM> may determine what data is needed to process a task and further determine which nodes within the execution platform <NUM> are best suited to process the task. Some nodes may have already cached the data needed to process the task and, therefore, be a good candidate for processing the task. Metadata stored in the database <NUM> assists the compute service manager <NUM> in determining which nodes in the execution platform <NUM> have already cached at least a portion of the data needed to process the task. One or more nodes in the execution platform <NUM> process the task using data cached by the nodes and, if necessary, data retrieved from the cloud computing service platform <NUM>. It is desirable to retrieve as much data as possible from caches within the execution platform <NUM> because the retrieval speed is typically much faster than retrieving data from the cloud computing service platform <NUM>.

As shown in <FIG>, the computing environment <NUM> separates the execution platform <NUM> from the cloud computing service platform <NUM>. In this arrangement, the processing resources and cache resources in the execution platform <NUM> operate independently of the data storage resources <NUM>-<NUM> to <NUM>-n in the cloud computing service platform <NUM>. Thus, the computing resources and cache resources are not restricted to specific data storage resources <NUM>-<NUM> to <NUM>-n. Instead, all computing resources and all cache resources may retrieve data from, and store data to, any of the data storage resources in the cloud computing service platform <NUM>.

<FIG> is a data flow diagram illustrating creation of an integration object <NUM> within the computing environment <NUM>, in accordance with some embodiments of the present disclosure. As shown, an administrative user <NUM> of the cloud computing service platform <NUM> uses the access management system <NUM> of the cloud computing service platform <NUM> to create a role <NUM>. A role in the context of the cloud computing service platform <NUM> is an identity with a set of permissions for making services requests within the cloud computing service platform <NUM>. A role is similar to a user in that it is an identity with permission policies that determine what the identity can do within the cloud computing service platform <NUM>, but rather than being uniquely associated with a single person like a user, a role is an identity that can be assumed by multiple users. A role also does not have long-term security credentials; instead, a user that is assuming a role is provided temporary security credentials that expire after an expiration time.

The administrative user <NUM> of the cloud computing service platform <NUM> creates the role <NUM> with permission to call web endpoints corresponding to the remote software component <NUM>. For example, the administrative user <NUM> can utilize a user interface provided to computing device <NUM> by the cloud computing service platform <NUM> to provide appropriate input to cause the access management system <NUM> to create the role <NUM>.

The cloud computing service platform <NUM> assigns a resource identifier to the role <NUM>. The administrative user <NUM> interacts further with the access management system <NUM> using the UI provided to computing device <NUM> to obtain the resource identifier associated with the role <NUM> and communicates this resource identifier to an administrative user <NUM> of the network-based data warehouse system <NUM>.

At <NUM>, the compute service manager <NUM> creates the integration object <NUM> in the database <NUM> based on input provided by the administrative user <NUM> including the resource identifier associated with the role <NUM> and a scheme for allowing/denying web calls based on target uniform resource locators (URLs). As an example, the administrative user <NUM> can utilize a UI provided to computing device <NUM> by the network-based data warehouse system <NUM> to provide the input and cause the compute service manager <NUM> to create the integration object <NUM>.

The scheme for allowing/denying web calls can comprise a whitelist of permissible URLs to which web calls may be made, a blacklist of impermissible URLs to which web calls are not permitted, or both. In general, the scheme is used by the compute service manager <NUM> to restrict which endpoints can be used with the integration. The integration object <NUM> generated by the compute service manager <NUM> includes: a reference <NUM> to the resource identifier associated with the role <NUM>, a reference <NUM> to a resource identifier associated with a user record <NUM>, and the scheme defining allowed/restricted URLs. In some embodiments, the integration object <NUM> may further comprise a reference to an external identification (ID) string generated by the compute service manager <NUM>. The external ID string generated by the compute service manager <NUM> can be used to establish a trust relationship between the role <NUM> and the user record <NUM>.

The access management system <NUM> can maintain a pool of user records and can select the user record <NUM> to assign to and include in the integration object <NUM>. At <NUM>, the administrative user <NUM> interacts with the compute service manager <NUM> to extract the resource identifier of the user record <NUM> and the external ID string included in the integration object <NUM> and communicates the resource identifier of the user record <NUM> and the external ID string to the administrative user <NUM> in an out-of-band communication.

The administrative user <NUM> interacts with the access management system <NUM> to establish a trust relationship between the role <NUM> and the user record <NUM> to enable a user corresponding to the user record <NUM> to assume the role <NUM> and send web calls to the remote software component <NUM> via the web API management system <NUM>. As a result, the role <NUM> is updated to include a reference <NUM> to the user record <NUM>.

At <NUM>, the compute service manager <NUM> grants usage rights to the integration object <NUM> to one or more users associated with the administrative user <NUM> based on input provided by the administrative user <NUM> via the UI provided to computing device <NUM>.

<FIG> is a data flow diagram illustrating creation of a function object <NUM> within the computing environment <NUM>, in accordance with some embodiments of the present disclosure. As shown, at <NUM>, the web API management system <NUM> is configured to include a target web endpoint <NUM> (also referred to herein simply as "target endpoint <NUM>") corresponding to the remote software component <NUM>. The target endpoint <NUM> can comprise a uniform resource locator (URL) corresponding to the remote software component <NUM>. The web API management system <NUM> is configured by a function author <NUM> using a UI provided to computing device <NUM> by the cloud computing service platform <NUM>. The function author <NUM> is a user with access to an account with the cloud computing service platform <NUM> and an account with the network-based data warehouse system <NUM>. The target endpoint <NUM> is configured to be authenticated by the access management system <NUM> of the cloud computing service platform <NUM> using a resource policy that allows permissions granted to the role <NUM> to be invoked.

The compute service manager <NUM> receives a function definition from the computing device <NUM>. The function definition can be specified by the function author <NUM> using a UI provided to the computing device <NUM> by the network-based data warehouse system <NUM>. The function definition identifies the integration object <NUM> and the target endpoint <NUM>. In some embodiments, the function definition can comprise a maximum batch size for batching rows into requests sent to the web API management system <NUM>.

The compute service manager <NUM> (at <NUM>) checks whether the URL for the target endpoint <NUM> is allowed by the scheme that defines allowed/restricted URLs. If not, the compute service manager <NUM> rejects the function definition. Otherwise, the compute service manager <NUM> creates the function object <NUM> in the database <NUM> (at <NUM>). The function object <NUM> defines a function that can be used in a query (e.g., SQL query) to invoke the external functionality provided by the remote software component <NUM>. The function object <NUM> comprises a reference <NUM> (e.g., a pointer) to the integration object <NUM> and a reference <NUM> to the target endpoint <NUM> (e.g., a URL corresponding to the target endpoint <NUM>). At <NUM>, the compute service manager <NUM> grants usage rights to the function object <NUM> to one or more users of the network-based data warehouse system <NUM> based on input provided by the function author <NUM> via the UI provided to computing device <NUM>.

<FIG> is a data flow diagram illustrating invocation of an external function provided by remote software component <NUM> by the network-based data warehouse system <NUM> within the computing environment <NUM>, in accordance with some embodiments of the present disclosure. The invocation of the external function is initiated by a function caller <NUM> issuing a query to the compute service manager <NUM> using a computing device <NUM> in communication with the compute service manager <NUM>. The function caller <NUM> is a user of the network-based data warehouse system <NUM>. The query comprises an invocation of the function defined by the function object <NUM> and indicates a set of input data for the function.

At <NUM>, the compute service manager <NUM>, in response to receiving the query from the computing device <NUM> of the function caller <NUM>, accesses information from the integration object <NUM> and the function object <NUM> to verify that the function caller <NUM> has appropriate usage rights to invoke the function and to verify that the target endpoint of the function (e.g., endpoint <NUM>) is allowed based on the scheme defining allowable/restricted URLs (e.g., the whitelist and/or blacklist).

If the function caller <NUM> has appropriate usage rights and the target endpoint is allowed, the compute service manager <NUM>, at <NUM>, obtains the resource identifier associated with the user record <NUM>, the resource identifier associated with the role <NUM>, and long-term security credentials associated with the user record <NUM>. The long-term security credentials can be encrypted to mitigate against unauthorized access and can be stored in the database <NUM>, a cache memory component of the compute service manager <NUM>, or both.

At <NUM>, the compute service manager <NUM> works in conjunction with the access management system <NUM> to obtain temporary security credentials for assuming the role <NUM>. The temporary security credentials expire after a time limit is reached (e.g., <NUM> hour). The temporary security credentials are also limited in scope for use specifically in sending requests to the remote software component <NUM>. The temporary security credentials can be obtained by transmitting a request to the access management system <NUM> of the cloud computing service platform <NUM> for the temporary security credentials. The request can comprise or indicate the resource identifier corresponding to the user record <NUM>, the resource identifier corresponding to the role <NUM>, and the long-term security credentials associated with the user record <NUM>. The access management system <NUM> provides the temporary security credentials in response to the request. The temporary security credentials are also encrypted to limit unauthorized access and use.

At <NUM>, the compute service manager <NUM> generates and provides an execution plan to the execution platform <NUM> that specifies data to be processed and actions to be performed. The execution plan also identifies the target endpoint <NUM> and the temporary security credentials to be used to authenticate with the web API management system <NUM>. The temporary security credentials included in the execution plan are also encrypted to ensure secure communication. In generating the execution plan, external functions (e.g., scalar functions, table functions, or stored procedures) may be converted into specification and description language (SDL) nodes along with the target endpoint <NUM> URL and other parameters. The execution platform <NUM> generates a query plan based on the execution plan to extract the data consumed, and as needed, build columns that are sharded in sub-columns.

At <NUM>, the execution platform <NUM> executes the query plan by sending one or more requests (e.g., HTTP requests) to the web API management system <NUM>. The execution platform <NUM> can utilize Transport Layer Security (TLS) protocol in communicating the request to the web API management system <NUM>. Each request can comprise a collection of input rows as well as other metadata for performing a web call to the remote software component <NUM>. Data can be passed as a combination of headers and message body, for example, in JSON, Apache Arrow, or XML format. Rows may be batched into requests to reduce the network overhead of each remote procedure call. Batching can be based on user-specified maximum batch size (e.g., included in the function definition), a maximum payload size allowed by the web API management system <NUM>, or a maximum batch size (e.g., bytes or rows) allowed by the execution platform <NUM>.

Requests are electronically signed and authenticated using the temporary security credentials. At <NUM>, the web API management system <NUM> works in conjunction with the access management system <NUM> to authenticate each received request and verifies that the role <NUM> has appropriate permissions to make web calls to the remote software component <NUM> corresponding to the endpoint <NUM>. If so, the web API management system <NUM> processes the requests by making one or more web calls, at <NUM>, to the remote software component <NUM>, via an API to the remote software component <NUM> provided by the remote computing environment <NUM>, to invoke the external functionality with respect to the set of input data. The remote software component <NUM> communicates result data back to the web API management system <NUM> and the web API management system <NUM> communicates a response back to the execution platform <NUM>, at <NUM>. The result data can comprise JSON, Apache Arrow, or XML encoded data.

The execution platform <NUM> receives the response from the web API management system <NUM> and the execution platform <NUM> parses the response to extract the result data. The result data extracted by the execution platform <NUM> can comprise JSON, Apache Arrow, or XML encoded data. The execution platform <NUM> processes the result data according to the query plan. The processing of the result data can include storing the result data and/or performing one or more actions with respect to the result data.

In some embodiments, as part of executing the query plan, the execution platform <NUM> may pass data to the web API management system <NUM> by writing data to a first temporary data store that is commonly accessible by the network-based data warehouse system <NUM>, the cloud computing service platform <NUM>, and the remote computing environment <NUM>. The data store may be provided by the cloud computing service platform <NUM> (e.g., AWS S3®). In these embodiments, the execution platform <NUM> sends a request to the web API management system <NUM> comprising an electronically signed URL corresponding to the data store and a manifest. The remote software component <NUM> reads data from the first temporary data store, executes the external functionality on the data, writes the result data to a second temporary data store where it can be read by the execution platform <NUM>, and sends a response back to the web API management system <NUM>.

A process executed by the execution platform <NUM> cleans up the temporary data stores when a query is finished or if a query fails. Data is server-side encrypted, using a derived key specific to each query. The key may be sent in HTTP request over TLS and is used by the remote software component <NUM> when reading data from the temporary data stores.

In some embodiments, the web API management system <NUM> applies a hard timeout that imposes a time limit (e.g., <NUM> seconds) for incoming requests. This may be problematic for requests that need longer than the time limit to execute such as external table functions. To support these scenarios, the execution platform <NUM> may, in some embodiments, use an asynchronous model where a single logical request is implemented as a state machine with the following states: <NUM>) begin request; <NUM>) poll status; and <NUM>) read results. In this manner, after beginning a request, the execution platform <NUM> may proceed to poll the web API management system <NUM> for a status of the request and continue to do so until the result data is ready. In some embodiments, the execution platform <NUM> utilizes a webhook-style callback mechanism to address the hard timeout imposed by the web API management system <NUM>.

In some instances, the temporary credentials can expire during a web call to the remote software component <NUM> or while waiting for the response from the web API management system <NUM>. In these instances, the execution platform <NUM> can work in conjunction with the compute service manager <NUM> to refresh the temporary security credentials and upon refreshing the temporary security credentials, communicate additional requests to the web endpoint <NUM>.

<FIG> is an interaction diagram illustrating interactions between the network-based data warehouse system <NUM>, the cloud computing service platform <NUM>, and the remote computing environment <NUM> in performing a method <NUM> for creating of an integration object (e.g., the integration object <NUM>), in accordance with some embodiments of the present disclosure.

At operation <NUM>, the cloud computing service platform <NUM> creates the role <NUM> with permission to call the endpoint <NUM> corresponding to the remote software component <NUM>. The cloud computing service platform <NUM> creates the role <NUM> based on input received from the computing device <NUM> operated by the administrative user <NUM>. For example, the administrative user <NUM> can utilize a user interface provided to computing device <NUM> by the cloud computing service platform <NUM> to provide appropriate input to cause the access management system <NUM> to create the role <NUM>. The cloud computing service platform <NUM> assigns a resource identifier to the role <NUM> once the role <NUM> has been generated, and in an out-of-band communication the administrative user <NUM> communicates the resource identifier to the administrative user <NUM> of the network-based data warehouse system <NUM>.

At operation <NUM>, the compute service manager <NUM> creates the integration object <NUM> in the database <NUM> based on input provided by the administrative user <NUM> (e.g., via a UI provided to computing device <NUM> by the network-based data warehouse system <NUM>). The input provided by the administrative user <NUM> includes the resource identifier associated with the role <NUM> and data defining a scheme for allowing/denying web calls based on target URLs. The integration object <NUM> generated by the compute service manager <NUM> includes: the reference <NUM> to the resource identifier associated with the role <NUM>, the reference <NUM> to a resource identifier associated with the user record <NUM>; and the data defining the scheme. In some embodiments, the integration object <NUM> may further comprise a reference to an external ID string generated by the compute service manager <NUM>.

The administrative user <NUM> extracts the resource identifier of the user record <NUM> and, in some embodiments, the external ID string included in the integration object <NUM> and communicates the resource identifier of the user record <NUM> and the external ID string to the administrative user <NUM> in an out-of-band communication.

At operation <NUM>, the cloud computing service platform <NUM> establishes a trust relationship between the role <NUM> and the user record <NUM> based on input from the administrative user <NUM> including the resource identifier of the user record <NUM> and, in some embodiments, the external ID string. The cloud computing service platform <NUM> establishes the trust relationship to enable a user corresponding to the user record <NUM> to assume the role <NUM> and send web calls to the remote software component <NUM> via the web API management system <NUM>. As part of establishing the trust relationship, the role <NUM> is updated to include a reference <NUM> to the user record <NUM> and the external ID string, in some embodiments.

At operation <NUM>, the compute service manager <NUM> grants usage rights to the integration object <NUM> to one or more users associated with the administrative user <NUM> based on input provided by the administrative user <NUM> via the UI provided to computing device <NUM>.

<FIG> is an interaction diagram illustrating interactions between network-based data warehouse system <NUM>, the cloud computing service platform <NUM>, the remote computing environment <NUM> in creating the function object <NUM>, in accordance with some embodiments of the present disclosure. At operation <NUM>, the web API management system <NUM> is configured by the function author <NUM> to include the target endpoint <NUM> corresponding to the remote software component <NUM>. The function author <NUM> can configure the web API management system <NUM> using a UI provided to computing device <NUM> by the cloud computing service platform <NUM>.

At operation <NUM>, the compute service manager <NUM> receives, from the computing device <NUM>, a function definition identifying the integration object <NUM> and the target endpoint <NUM> (e.g., a URL). The function definition can be specified by the function author <NUM> using a UI provided to the computing device <NUM> by the network-based data warehouse system <NUM>.

At operation <NUM>, the compute service manager <NUM> verifies whether the target endpoint is allowed by the scheme defining allowable/restricted URLs. If it is not allowed, the compute service manager <NUM> rejects the function definition. Otherwise, the compute service manager <NUM>, at operation <NUM>, creates the function object <NUM> in the database <NUM> that defines a function that can be used in a query (e.g., SQL query) to invoke the external functionality provided by the remote software component <NUM>. The function object <NUM> comprises the reference <NUM> (e.g., a pointer) to the integration object <NUM> and the reference <NUM>(e.g., a pointer) to the target endpoint <NUM>. At operation <NUM>, the compute service manager <NUM> grants usage rights to the function object <NUM> to one or more users associated with the function author <NUM> based on input provided by the function author <NUM> via the UI provided to computing device <NUM>.

<FIG> is an interaction diagram illustrating interactions between components of network-based data warehouse system <NUM>, the cloud computing service platform <NUM>, and the remote computing environment <NUM> in invoking external functionality provided by remote software component <NUM>, in accordance with some embodiments of the present disclosure.

At operation <NUM>, the network-based data warehouse system <NUM> receives a query from the computing device <NUM> operated by function caller <NUM>. The query comprises an invocation of the function defined by the function object <NUM> and indicates a set of input data for the function. In response to receiving the query, the network-based data warehouse system <NUM> verifies, at operation <NUM>, that the function caller <NUM> has appropriate usage rights to invoke the function. At operation <NUM>, the network-based data warehouse system <NUM> verifies that the target endpoint of the function (e.g., endpoint <NUM>) referenced in the query is allowed based on the scheme defining allowable/restricted URLs (e.g., the whitelist and/or blacklist).

If the function caller <NUM> has appropriate usage rights and the target endpoint is allowed, the compute service manager <NUM> obtains temporary security credentials for assuming the role <NUM>, at operation <NUM>. The temporary security credentials can be obtained by transmitting a request to the access management system <NUM> of the cloud computing service platform <NUM> for the temporary security credentials. The request can comprise or indicate the resource identifier corresponding to the user record <NUM>, the resource identifier corresponding to the role <NUM>, and the long-term security credentials associated with the user record <NUM>.

At operation <NUM>, the network-based data warehouse system <NUM> sends one or more requests (e.g., HTTP requests) to the web API management system <NUM> of the cloud computing service platform <NUM> (e.g., using TLS protocol). Each request can comprise a collection of input rows as well as other metadata for performing a web call to the remote software component <NUM>.

The web API management system <NUM> works in conjunction with the access management system <NUM> of the cloud computing service platform <NUM> to authenticate each received request at operation <NUM>. At operation <NUM>, the web API management system <NUM> of the cloud computing service platform <NUM> processes the requests by sending one or more web calls to the remote software component <NUM>, via an API to the remote software component <NUM> provided by the remote computing environment <NUM>, to invoke the external functionality with respect to the set of input data.

At operation <NUM>, the remote computing environment <NUM> executes the remote software component <NUM> with the input data provided as input and in doing so, the remote computing environment <NUM> generates result data (e.g., in JSON, Apache Arrow, or XML format). The remote computing environment <NUM> communicates result data back to the web API management system <NUM>, at operation <NUM>. At operation <NUM>, the web API management system <NUM> communicates a response back to the execution platform <NUM> that comprises the result data (e.g., in JSON, Apache Arrow, or XML format).

The network-based data warehouse system <NUM> parses the response, at operation <NUM>, to extract the result data (e.g., in JSON, Apache Arrow, or XML format). At operation <NUM>, the execution platform <NUM> processes the result data (e.g., by storing the result data and/or performing one or more actions with respect to the result data).

<FIG> is a flow diagram illustrating operations of the network-based data warehouse system <NUM> in performing a method <NUM> for enabling a network-based data warehouse system <NUM> to invoke an external function provided by the remote software component <NUM>, in accordance with some embodiments of the present disclosure. The method <NUM> may be embodied in computer-readable instructions for execution by a hardware component (e.g., a processor) such that the operations of the method <NUM> may be performed by components of network-based data warehouse system <NUM>. Accordingly, the method <NUM> is described below, by way of example with reference thereto. However, it shall be appreciated that the method <NUM> may be deployed on various other hardware configurations and is not intended to be limited to deployment within the network-based data warehouse system <NUM>.

At operation <NUM>, the compute service manager <NUM> generates an integration object (e.g., integration object <NUM>) based on first input received from a first computing device (e.g., computing device <NUM>) corresponding to a first user (e.g., user <NUM>) of the network-based data warehouse system <NUM>. The first user can, for example, provide the input using a UI provided to the computing device by the network-based data warehouse system <NUM>. The input comprises a first resource identifier corresponding to a role (e.g., role <NUM>) in the cloud computing service platform <NUM> and a schemed defining allowable/restricted URLs to which web calls may be sent (e.g., a whitelist and/or blacklist of URLs). The first resource identifier can be communicated to the first user by an administrative user of the cloud computing service platform <NUM> (e.g., the administrative user that created the role).

As part of generating the integration object, the compute service manager <NUM> identifies a second resource identifier corresponding to a user record (e.g., user record <NUM>) maintained by the access management system <NUM> of the network-based data warehouse system <NUM> to assign to the integration. In some embodiments, the compute service manager <NUM> also generates an external ID string that can be used to establish a trust relationship between the role in the cloud computing services platform <NUM> and the user record. Further, the compute service manager <NUM> can also grant usage rights to the integration to one or more users (e.g., users specified by the administrative user of the network-based data warehouse).

The integration object comprises: a reference to the first resource identifier corresponding to the role in the cloud computing service platform <NUM>, a reference to the second resource identifier corresponding to a user record maintained by the network-based data warehouse system <NUM>, data defining a scheme for allowing/denying web calls based on target URLs, and, in some embodiments, a reference to the external ID string. The administrative user of the network-based data warehouse can communicate the second resource identifier and the external ID string to the administrative user of the cloud computing service platform <NUM> and the administrative user of the cloud computing service platform can in turn create the trust relationship between the role and the user record.

At operation <NUM>, the compute service manager <NUM> stores the integration object in the database <NUM> along with a reference to the user record maintained by the access management system <NUM> and a reference to the role maintained by the cloud computing services platform <NUM>. For example, the compute service manager <NUM> can store the integration object with a first pointer corresponding to the user record and a second pointer corresponding to the role.

At operation <NUM>, the compute service manager <NUM> generates a function object (e.g., function object <NUM>) based on second input received from a second computing device (e.g., computing device <NUM>) corresponding to a second user (e.g., function author <NUM>) of the data warehouse system <NUM>. The function object comprises a reference to the integration object and a reference to a target endpoint in the web API management system <NUM> (e.g., target endpoint <NUM>) corresponding to the remote software component <NUM>. The second input can identify the target endpoint and the integration object. For example, the second input can include a URL corresponding to the target endpoint and a resource identifier corresponding to the integration object. Prior to generating the function object, the compute service manager <NUM> verifies that the target endpoint is allowed by comparing the target endpoint to the scheme that defines allowable/restricted URLs.

At operation <NUM>, the compute service manager <NUM> stores the function object with a reference to the integration object and reference to the target endpoint in the web API management system <NUM>. For example, the compute service manager <NUM> can store the function object with a first pointer corresponding to the integration object and a second pointer corresponding to the target endpoint in the web API management system <NUM>.

<FIG> are flow diagrams illustrating operations of the network-based data warehouse system <NUM> in performing a method <NUM> for invoking external functionality provided by remote software component <NUM>, in accordance with some embodiments of the present disclosure. The method <NUM> may be embodied in computer-readable instructions for execution by a hardware component (e.g., a processor) such that the operations of the method <NUM> may be performed by components of network-based data warehouse system <NUM>. Accordingly, the method <NUM> is described below, by way of example with reference thereto. However, it shall be appreciated that the method <NUM> may be deployed on various other hardware configurations and is not intended to be limited to deployment within the network-based data warehouse system <NUM>.

In some embodiments, the method <NUM> is performed subsequent to the method <NUM> where the network-based data warehouse system <NUM> enables invocation of the external functionality by generating and storing the integration object and function object. Consistent with these embodiments, the method <NUM> includes the operations <NUM>, <NUM>, <NUM>, and <NUM> of the method <NUM>.

At operation <NUM>, the compute service manager <NUM> receives a query from a computing device of a third user (e.g., function caller <NUM>) that comprises a reference to a function associated with the remote software component <NUM>. As an example, the remote software component <NUM> may comprise a scalar function, a table function, or a stored procedure. The query further indicates a set of input data for the function.

At operation <NUM>, the compute service manager <NUM> accesses a function object (e.g., the function object <NUM>) corresponding to the function based on the reference to the function included in the query. The function object is stored with an association (e.g., a pointer) to an integration object associated with the remote software component <NUM>, and the compute service manager <NUM> uses this information in the function object to identify the integration object.

At operation <NUM>, the compute service manager <NUM> accesses the integration object (e.g., integration object <NUM>) from the database <NUM> based on the association with the function object. The integration object includes a reference to a user record maintained by the access management system <NUM> and a reference to a role (e.g., role <NUM>) maintained by the access management system <NUM> of the cloud computing services platform <NUM>.

At operation <NUM>, the compute service manager <NUM> obtains temporary security credentials to be used in authenticating with the web API management system <NUM> to assume the role in the cloud computing service platform <NUM>. The temporary security credentials expire after a time limit is reached (e.g., <NUM> hour) and are limited in scope for use specifically in invoking external functionality provided by the remote software component <NUM>.

At operation <NUM>, the execution platform <NUM> sends one or more requests (e.g., one or more HTTP requests) to the web API management system <NUM> of the cloud computing service platform <NUM> to invoke the external functionality provided by the remote software component <NUM>. The one or more requests comprises input data and a reference to the target endpoint corresponding to the remote software component <NUM> and are electronically signed using the temporary security credentials. The one or more requests are authenticated by the access management system <NUM> and cause the web API management system <NUM> to invoke the external functionality provided by the remote software component <NUM>. For example, the requests may cause the web API management system <NUM> to send one or more web calls to the remote software component <NUM> (e.g., via an API provided by the remote computing environment <NUM>). The remote software component <NUM>, in turn, executes a scalar function, tabular function, or procedure and generates result data based thereon. The remote software component <NUM> communicates the result data back to the web API management system <NUM> (e.g., in one or more HTTP responses). The web API management system <NUM> communicates a response to the request to the execution platform <NUM>. The result data can comprise JSON, Apache Arrow, or XML encoded data.

At operation <NUM>, the execution platform <NUM> receives the response to the request from the compute service manager <NUM> and the execution platform <NUM> parses the response to extract the result data, at operation <NUM>. The result data extracted by the execution platform <NUM> can comprise JSON, Apache Arrow, or XML encoded data.

At operation <NUM>, the execution platform <NUM> processes the result data. The processing of the result data can include storing the result data and/or performing one or more actions with respect to the result data.

As shown in <FIG>, the method <NUM> may, in some embodiments, further include operations <NUM>, <NUM>, <NUM>, and <NUM>. Consistent with these embodiments, the operations <NUM> and <NUM> are performed subsequent to operations <NUM> wherein the compute service manager <NUM> accesses the integration object. At operation <NUM>, the compute service manager <NUM> verifies that the third user (e.g., the function caller <NUM>) has usage rights to utilize the integration based on usage rights indicated by the integration object. At operation <NUM>, the compute service manager <NUM> verifies that the target endpoint included in the query is allowed based on a comparison of the target endpoint with the scheme that defines allowable/restricted URLs indicated by the integration object.

Consistent with these embodiments, the operations <NUM> and <NUM> may be performed as part of operation <NUM> (e.g., as sub-operation or a subroutine), where the compute service manager <NUM> obtains temporary security credentials to assume the cloud computing service platform <NUM> role.

At operation <NUM>, the compute service manager <NUM> accesses long-term security credentials associated with the user record in the data cloud warehouse system <NUM>. The long-term security credentials can be stored in an encrypted format in the database and/or a cache memory component of the compute service manager <NUM>.

At operation <NUM>, the compute service manager <NUM> transmits a request to the access management system <NUM> of the cloud computing service platform <NUM> for the temporary security credentials. The request can comprise or indicate the first resource identifier corresponding to the user record in the data warehouse system <NUM>, the second resource identifier corresponding to the cloud computing services platform role, and the long-term security credentials associated with the user record. The access management system <NUM> of the cloud computing service platform <NUM> provides the temporary security credentials in response to the request.

As shown in <FIG>, the method <NUM> may, in some embodiments, include operations <NUM> and <NUM>. Consistent with these embodiments, the operations <NUM> and <NUM> may be performed prior to operation <NUM> where the execution platform <NUM> receives the response from the web API management system <NUM>. At operation <NUM>, the execution platform <NUM> detects an expiration of the temporary security credentials. For example, the execution platform <NUM> can detect the expiration of the temporary security credentials based on determining the expiration time limit has been reached or based on a timeout message received from the cloud computing service platform <NUM>. In some embodiments, the execution platform <NUM> may poll the web API management system <NUM> for a status of the request and detect the expiration of the temporary credentials based on a response thereto.

At operation <NUM>, the compute service manager <NUM> refreshes the temporary security credentials to enable the execution platform <NUM> to continue assuming the role. For example, the compute service manager <NUM> can refresh the temporary security credentials by sending an additional request to the access management system <NUM> of the cloud computing service platform <NUM>. Upon refreshing the security credentials, the compute service manager <NUM> may prompt the execution platform <NUM> to send one or more additional requests to the web API management system <NUM> to invoke the external functionality provided by the remote software component <NUM>. In some instances, the compute service manager <NUM> may refresh the temporary security credentials to ensure that the web API management system <NUM> is able to communicate the response back to the execution platform <NUM>.

<FIG> is a block diagram illustrating components of the compute service manager <NUM>, in accordance with some embodiments of the present disclosure. As shown in <FIG>, <FIG> request processing service <NUM> manages received data storage requests and data retrieval requests (e.g., jobs to be performed on database data). For example, the request processing service <NUM> may determine the data necessary to process a received query (e.g., a data storage request or data retrieval request). The data may be stored in a cache within the execution platform <NUM> or in a data storage device in cloud computing service platform <NUM>. A management console service <NUM> supports access to various systems and processes by administrators and other system managers. Additionally, the management console service <NUM> may receive a request to execute a job and monitor the workload on the system.

The compute service manager <NUM> also includes a job compiler <NUM>, a job optimizer <NUM> and a job executor <NUM>. The job compiler <NUM> parses a job into multiple discrete tasks and generates the execution code for each of the multiple discrete tasks. The job optimizer <NUM> determines the best method to execute the multiple discrete tasks based on the data that needs to be processed. The job optimizer <NUM> also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the job. The job executor <NUM> executes the execution code for jobs received from a queue or determined by the compute service manager <NUM>.

A job scheduler and coordinator <NUM> sends received jobs to the appropriate services or systems for compilation, optimization, and dispatch to the execution platform <NUM>. For example, jobs may be prioritized and processed in that prioritized order. In an embodiment, the job scheduler and coordinator <NUM> determines a priority for internal jobs that are scheduled by the compute service manager <NUM> with other "outside" jobs such as user queries that may be scheduled by other systems in the database but may utilize the same processing resources in the execution platform <NUM>. In some embodiments, the job scheduler and coordinator <NUM> identifies or assigns particular nodes in the execution platform <NUM> to process particular tasks. A virtual warehouse manager <NUM> manages the operation of multiple virtual warehouses implemented in the execution platform <NUM>. As discussed below, each virtual warehouse includes multiple execution nodes that each include a cache and a processor.

Additionally, the compute service manager <NUM> includes a configuration and metadata manager <NUM>, which manages the information related to the data stored in the remote data storage devices and in the local caches (i.e., the caches in execution platform <NUM>). The configuration and metadata manager <NUM> uses the metadata to determine which data micro-partitions need to be accessed to retrieve data for processing a particular task or job. A monitor and workload analyzer <NUM> oversee processes performed by the compute service manager <NUM> and manages the distribution of tasks (e.g., workload) across the virtual warehouses and execution nodes in the execution platform <NUM>. The monitor and workload analyzer <NUM> also redistribute tasks, as needed, based on changing workloads throughout the data warehouse <NUM> and may further redistribute tasks based on a user (e.g., "external") query workload that may also be processed by the execution platform <NUM>. The configuration and metadata manager <NUM> and the monitor and workload analyzer <NUM> are coupled to a data storage device <NUM>. Data storage device <NUM> in <FIG> represent any data storage device within the data warehouse <NUM>. For example, data storage device <NUM> may represent caches in execution platform <NUM>, storage devices in cloud computing service platform <NUM>, or any other storage device.

<FIG> is a block diagram illustrating components of the execution platform <NUM>, in accordance with some embodiments of the present disclosure. As shown in <FIG>, execution platform <NUM> includes multiple virtual warehouses, including virtual warehouse <NUM>, virtual warehouse <NUM>, and virtual warehouse n. Each virtual warehouse includes multiple execution nodes that each include a data cache and a processor. The virtual warehouses can execute multiple tasks in parallel by using the multiple execution nodes. As discussed herein, execution platform <NUM> can add new virtual warehouses and drop existing virtual warehouses in real-time based on the current processing needs of the systems and users. This flexibility allows the execution platform <NUM> to quickly deploy large amounts of computing resources when needed without being forced to continue paying for those computing resources when they are no longer needed. All virtual warehouses can access data from any data storage device (e.g., any storage device in cloud computing service platform <NUM>).

Although each virtual warehouse shown in <FIG> includes three execution nodes, a particular virtual warehouse may include any number of execution nodes. Further, the number of execution nodes in a virtual warehouse is dynamic, such that new execution nodes are created when additional demand is present, and existing execution nodes are deleted when they are no longer necessary.

Each virtual warehouse is capable of accessing any of the data storage devices <NUM>-<NUM> to <NUM>-n shown in <FIG>. Thus, the virtual warehouses are not necessarily assigned to a specific data storage device <NUM>-<NUM> to <NUM>-n and, instead, can access data from any of the data storage devices <NUM>-<NUM> to <NUM>-n within the cloud computing service platform <NUM>. Similarly, each of the execution nodes shown in <FIG> can access data from any of the data storage devices <NUM>-<NUM> to <NUM>-n. In some embodiments, a particular virtual warehouse or a particular execution node may be temporarily assigned to a specific data storage device, but the virtual warehouse or execution node may later access data from any other data storage device.

In the example of <FIG>, virtual warehouse <NUM> includes three execution nodes <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-n. Execution node <NUM>-<NUM> includes a cache <NUM>-<NUM> and a processor <NUM>-<NUM>. Execution node <NUM>-<NUM> includes a cache <NUM>-<NUM> and a processor <NUM>-<NUM>. Execution node <NUM>-n includes a cache <NUM>-n and a processor <NUM>-n. Each execution node <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-n is associated with processing one or more data storage and/or data retrieval tasks. For example, a virtual warehouse may handle data storage and data retrieval tasks associated with an internal service, such as a clustering service, a materialized view refresh service, a file compaction service, a storage procedure service, or a file upgrade service. In other implementations, a particular virtual warehouse may handle data storage and data retrieval tasks associated with a particular data storage system or a particular category of data.

Similar to virtual warehouse <NUM> discussed above, virtual warehouse <NUM> includes three execution nodes <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-n. Execution node <NUM>-a includes a cache <NUM>-<NUM> and a processor <NUM>-<NUM>. Execution node <NUM>-n includes a cache <NUM>-n and a processor <NUM>-n. Execution node <NUM>-n includes a cache <NUM>-n and a processor <NUM>-n. Additionally, virtual warehouse <NUM> includes three execution nodes <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-n. Execution node <NUM>-<NUM> includes a cache <NUM>-<NUM> and a processor <NUM>-<NUM>. Execution node <NUM>-<NUM> includes a cache <NUM>-<NUM> and a processor <NUM>-<NUM>. Execution node <NUM>-n includes a cache <NUM>-n and a processor <NUM>-n.

In some embodiments, the execution nodes shown in <FIG> are stateless with respect to the data the execution nodes are caching. For example, these execution nodes do not store or otherwise maintain state information about the execution node, or the data being cached by a particular execution node. Thus, in the event of an execution node failure, the failed node can be transparently replaced by another node. Since there is no state information associated with the failed execution node, the new (replacement) execution node can easily replace the failed node without concern for recreating a particular state.

Although the execution nodes shown in <FIG> each include one data cache and one processor, alternate embodiments may include execution nodes containing any number of processors and any number of caches. Additionally, the caches may vary in size among the different execution nodes. The caches shown in <FIG> store, in the local execution node, data that was retrieved from one or more data storage devices in cloud computing service platform <NUM>. Thus, the caches reduce or eliminate the bottleneck problems occurring in platforms that consistently retrieve data from remote storage systems. Instead of repeatedly accessing data from the remote storage devices, the systems and methods described herein access data from the caches in the execution nodes which is significantly faster and avoids the bottleneck problem discussed above. In some embodiments, the caches are implemented using high-speed memory devices that provide fast access to the cached data. Each cache can store data from any of the storage devices in the cloud computing service platform <NUM>.

Further, the cache resources and computing resources may vary between different execution nodes. For example, one execution node may contain significant computing resources and minimal cache resources, making the execution node useful for tasks that require significant computing resources. Another execution node may contain significant cache resources and minimal computing resources, making this execution node useful for tasks that require caching of large amounts of data. Yet another execution node may contain cache resources providing faster input-output operations, useful for tasks that require fast scanning of large amounts of data. In some embodiments, the cache resources and computing resources associated with a particular execution node are determined when the execution node is created, based on the expected tasks to be performed by the execution node.

Additionally, the cache resources and computing resources associated with a particular execution node may change over time based on changing tasks performed by the execution node. For example, an execution node may be assigned more processing resources if the tasks performed by the execution node become more processor-intensive. Similarly, an execution node may be assigned more cache resources if the tasks performed by the execution node require a larger cache capacity.

Although virtual warehouses <NUM>, <NUM>, and n are associated with the same execution platform <NUM>, the virtual warehouses may be implemented using multiple computing systems at multiple geographic locations. For example, virtual warehouse <NUM> can be implemented by a computing system at a first geographic location, while virtual warehouses <NUM> and n are implemented by another computing system at a second geographic location. In some embodiments, these different computing systems are cloud-based computing systems maintained by one or more different entities.

Additionally, each virtual warehouse is shown in <FIG> as having multiple execution nodes. The multiple execution nodes associated with each virtual warehouse may be implemented using multiple computing systems at multiple geographic locations. For example, an instance of virtual warehouse <NUM> implements execution nodes <NUM>-<NUM> and <NUM>-<NUM> on one computing platform at a geographic location and implements execution node <NUM>-n at a different computing platform at another geographic location. Selecting particular computing systems to implement an execution node may depend on various factors, such as the level of resources needed for a particular execution node (e.g., processing resource requirements and cache requirements), the resources available at particular computing systems, communication capabilities of networks within a geographic location or between geographic locations, and which computing systems are already implementing other execution nodes in the virtual warehouse.

Execution platform <NUM> is also fault tolerant. For example, if one virtual warehouse fails, that virtual warehouse is quickly replaced with a different virtual warehouse at a different geographic location.

A particular execution platform <NUM> may include any number of virtual warehouses. Additionally, the number of virtual warehouses in a particular execution platform is dynamic, such that new virtual warehouses are created when additional processing and/or caching resources are needed. Similarly, existing virtual warehouses may be deleted when the resources associated with the virtual warehouse are no longer necessary.

In some embodiments, the virtual warehouses may operate on the same data in cloud computing service platform <NUM>, but each virtual warehouse has its own execution nodes with independent processing and caching resources. This configuration allows requests on different virtual warehouses to be processed independently and with no interference between the requests. This independent processing, combined with the ability to dynamically add and remove virtual warehouses, supports the addition of new processing capacity for new users without impacting the performance observed by the existing users.

<FIG> illustrates a diagrammatic representation of a machine <NUM> in the form of a computer system within which a set of instructions may be executed for causing the machine <NUM> to perform any one or more of the methodologies discussed herein, according to an example embodiment. Specifically, <FIG> shows a diagrammatic representation of the machine <NUM> in the example form of a computer system, within which instructions <NUM> (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine <NUM> to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions <NUM> may cause the machine <NUM> to execute any one or more operations of any one or more of the methods <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. As another example, the instructions <NUM> may cause the machine <NUM> to implemented portions of the data flows illustrated in any one or more of <FIG>. In this way, the instructions <NUM> transform a general, non-programmed machine into a particular machine <NUM> (e.g., the remote computing environment <NUM>, the access management system <NUM>, the compute service manager <NUM>, the execution platform <NUM>, the access management system <NUM>, the web API management system <NUM>, and the computing devices <NUM>, <NUM>, <NUM>, and <NUM>) that is specially configured to carry out any one of the described and illustrated functions in the manner described herein.

In alternative embodiments, the machine <NUM> operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine <NUM> may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a smart phone, a mobile device, a network router, a network switch, a network bridge, or any machine capable of executing the instructions <NUM>, sequentially or otherwise, that specify actions to be taken by the machine <NUM>. Further, while only a single machine <NUM> is illustrated, the term "machine" shall also be taken to include a collection of machines <NUM> that individually or jointly execute the instructions <NUM> to perform any one or more of the methodologies discussed herein.

The machine <NUM> includes processors <NUM>, memory <NUM>, and input/output (I/O) components <NUM> configured to communicate with each other such as via a bus <NUM>. In an example embodiment, the processors <NUM> (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor <NUM> and a processor <NUM> that may execute the instructions <NUM>. The term "processor" is intended to include multi-core processors <NUM> that may comprise two or more independent processors (sometimes referred to as "cores") that may execute instructions <NUM> contemporaneously. Although <FIG> shows multiple processors <NUM>, the machine <NUM> may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

The memory <NUM> may include a main memory <NUM>, a static memory <NUM>, and a storage unit <NUM>, all accessible to the processors <NUM> such as via the bus <NUM>. The main memory <NUM>, the static memory <NUM>, and the storage unit <NUM> store the instructions <NUM> embodying any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or partially, within the main memory <NUM>, within the static memory <NUM>, within the storage unit <NUM>, within at least one of the processors <NUM> (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine <NUM>.

The I/O components <NUM> include components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components <NUM> that are included in a particular machine <NUM> will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components <NUM> may include many other components that are not shown in <FIG>. The I/O components <NUM> are grouped according to functionality merely for simplifying the following discussion and the grouping is in no way limiting. In various example embodiments, the I/O components <NUM> may include output components <NUM> and input components <NUM>. The output components <NUM> may include visual components (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), other signal generators, and so forth. The input components <NUM> may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

Communication may be implemented using a wide variety of technologies. The I/O components <NUM> may include communication components <NUM> operable to couple the machine <NUM> to a network <NUM> or devices <NUM> via a coupling <NUM> and a coupling <NUM>, respectively. For example, the communication components <NUM> may include a network interface component or another suitable device to interface with the network <NUM>. In further examples, the communication components <NUM> may include wired communication components, wireless communication components, cellular communication components, and other communication components to provide communication via other modalities. The devices <NUM> may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a universal serial bus (USB)). For example, as noted above, the machine <NUM> may correspond to any one of the remote computing environment <NUM>, the access management system <NUM>, the compute service manager <NUM>, the execution platform <NUM>, the access management system <NUM>, the web API management system <NUM>, and the computing devices <NUM>, <NUM>, <NUM>, and <NUM>, and the devices <NUM> may include any other of these systems and devices.

The various memories (e.g., <NUM>, <NUM>, <NUM>, and/or memory of the processor(s) <NUM> and/or the storage unit <NUM>) may store one or more sets of instructions <NUM> and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions <NUM>, when executed by the processor(s) <NUM>, cause various operations to implement the disclosed embodiments.

As used herein, the terms "machine-storage medium," "device-storage medium," and "computer-storage medium" mean the same thing and may be used interchangeably in this disclosure. The terms refer to a single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store executable instructions and/or data. The terms shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media, including memory internal or external to processors. Specific examples of machine-storage media, computer-storage media, and/or device-storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), field-programmable gate arrays (FPGAs), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine-storage media," "computer-storage media," and "device-storage media" specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term "signal medium" discussed below.

In various example embodiments, one or more portions of the network <NUM> may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local-area network (LAN), a wireless LAN (WLAN), a wide-area network (WAN), a wireless WAN (WWAN), a metropolitan-area network (MAN), the Internet, a portion of the Internet, a portion of the public switched telephone network (PSTN), a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, the network <NUM> or a portion of the network <NUM> may include a wireless or cellular network, and the coupling <NUM> may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or another type of cellular or wireless coupling. In this example, the coupling <NUM> may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (1xRTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including <NUM>, fourth generation wireless (<NUM>) networks, Universal Mobile Telecommunications System (UMTS), High-Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, others defined by various standard-setting organizations, other long-range protocols, or other data transfer technology.

The instructions <NUM> may be transmitted or received over the network <NUM> using a transmission medium via a network interface device (e.g., a network interface component included in the communication components <NUM>) and utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions <NUM> may be transmitted or received using a transmission medium via the coupling <NUM> (e.g., a peer-to-peer coupling) to the devices <NUM>. The terms "transmission medium" and "signal medium" mean the same thing and may be used interchangeably in this disclosure. The terms "transmission medium" and "signal medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions <NUM> for execution by the machine <NUM>, and include digital or analog communications signals or other intangible media to facilitate communication of such software. Hence, the terms "transmission medium" and "signal medium" shall be taken to include any form of modulated data signal, carrier wave, and so forth.

The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" mean the same thing and may be used interchangeably in this disclosure. The terms are defined to include both machine-storage media and transmission media.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of the methods <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be performed by one or more processors. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but also deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other embodiments the processors may be distributed across a number of locations.

Although the embodiments of the present disclosure have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the inventive subject matter. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show, by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims.

Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent, to those of skill in the art, upon reviewing the above description.

Claim 1:
A system including a network-based data warehouse system (<NUM>) and a cloud-computing service platform (<NUM>), wherein the network-based data warehouse system (<NUM>) is in communication with the cloud computing service platform (<NUM>) comprising a web application programming interface, API, management system (<NUM>),
the network-based data warehouse system (<NUM>) comprising:
a compute service manager (<NUM>) comprising at least one hardware processor, the compute service manager (<NUM>) configured to perform operations comprising:
receiving, from a computing device, a query referencing a function associated with a remote software component (<NUM>); and
obtaining, from the cloud computing service platform (<NUM>) comprising at least one network-accessible storage device, temporary security credentials corresponding to a role with associated privileges to send calls to an endpoint corresponding to the remote software component (<NUM>), the cloud computing service platform (<NUM>) being independent from the compute service manager (<NUM>);
an execution platform (<NUM>) coupled to the compute service manager (<NUM>), the execution platform (<NUM>) comprising a plurality of compute nodes, at least one of the compute nodes configured to perform operations comprising:
sending, to a web application programming interface, API, management system (<NUM>) of the cloud computing service platform (<NUM>), a request that, when received by the web API management system (<NUM>), causes the web API management system (<NUM>) to invoke external functionality provided by the remote software component (<NUM>) at the web endpoint with respect to input data included in the request, the request being electronically signed using the temporary security credentials;
receiving, from the web API management system (<NUM>), a response to the request, the response comprising result data comprising a result of invoking the external functionality; and
processing the result data according to the query.