CN115023921A - System and method for global data sharing - Google Patents

Abstract

Shared data in data exchange across multiple cloud computing platforms and/or cloud computing platform regions is described. An example computer-implemented method may include receiving data sharing information from a data provider for sharing a data set in a data exchange from a first cloud computing entity to a set of second cloud computing entities. In response to receiving the data sharing information, the method may further include creating an account with each of the set of second cloud computing entities. The method may also further include sharing the data set from the first cloud computing entity with the set of second cloud computing entities using at least the corresponding account of the second cloud computing entity.

Description

System and method for global data sharing

Cross Reference to Related Applications

The present application claims the benefit of U.S. patent application No. 16/814,875 filed 3, 10, 2020, and the benefit of U.S. provisional application serial No. 62/966,977 filed 1, 28, 2020, the disclosures of which are incorporated herein by reference in their entireties, in accordance with 35u.s.c. 119 (e).

Technical Field

The present disclosure relates to resource management systems and methods for managing data storage and computing resources.

Background

Databases are widely used for data storage and access in computing applications. A database may include one or more tables that include or reference data that may be read, modified, or deleted using a query. Databases may be used to store and/or access personal information or other sensitive information. Secure storage and access to database data may be provided by encrypting and/or storing the data in encrypted form to prevent unauthorized access. In some cases, data sharing may be needed for other parties to perform queries against a set of data.

Brief Description of Drawings

The described embodiments and their advantages are best understood by referring to the following description in conjunction with the accompanying drawings. These drawings in no way limit any changes in form and detail that may be made to the described embodiments by one skilled in the art without departing from the spirit and scope of the described embodiments.

FIG. 1A is a block diagram depicting an example computing environment in which methods disclosed herein may be implemented.

FIG. 1B is a block diagram illustrating an example virtual warehouse (winehouse).

FIG. 2 is a schematic block diagram of data that may be used to implement public or private data exchanges according to an embodiment of the present invention.

FIG. 3 is a schematic block diagram of components used to implement data exchange in accordance with an embodiment of the present invention.

Fig. 4A is a process flow diagram of a method for controlled sharing of data between entities in a data exchange, according to an embodiment of the invention.

Fig. 4B is a diagram illustrating data for implementing private sharing of data according to an embodiment of the present invention.

FIG. 4C is a diagram illustrating a secure view for implementing private sharing of data, according to an embodiment of the invention.

Fig. 5 is a process flow diagram of a method for commonly sharing data between entities in a data exchange, according to an embodiment of the invention.

Fig. 6 is a process flow diagram of a method for performing bidirectional sharing in a data exchange, according to an embodiment of the invention.

FIG. 7 is a process flow diagram of a method for providing rich data in a data exchange, according to an embodiment of the invention.

Fig. 8 is a block diagram illustrating a network environment in which data providers may share data via a cloud computing service.

Fig. 9 is an example private data exchange according to an embodiment of the present invention.

Fig. 10 is a diagram illustrating an example secure view of shared data from a private data exchange.

Fig. 11 is a diagram illustrating example tunneling of a data list between two private data exchanges.

FIG. 12 is a diagram illustrating an example data query and delivery service according to some embodiments of the invention.

Fig. 13A is a block diagram of an example system of multiple cloud computing services sharing data with a data exchange.

Fig. 13B is a block diagram of an example system of a cloud computing service sharing data with data exchange across multiple regions of the cloud computing service.

Fig. 14 is a process flow diagram of a method for sharing data across multiple cloud computing services and/or across multiple regions with a cloud computing service.

Fig. 15 is a process flow diagram of a method for creating a list in a data exchange, wherein the list is available in different cloud computing services and/or in multiple areas having cloud computing services.

Fig. 16 is a process flow diagram of a method for creating a list for personalized sharing in a data exchange, wherein the list is available in different cloud computing services and/or in multiple areas having cloud computing services.

FIG. 17 is a process flow diagram of a method for sharing data with a Virtual Private Cloud (VPC).

Fig. 18 is a block diagram of an example computing device that may perform one or more operations described herein, in accordance with some embodiments.

Detailed Description

Data providers often have data assets that are difficult to share. A data asset may be data of interest to another entity. For example, a large online retail company may have a data set that includes the purchasing habits of millions of customers over the last decade. This data set may be large. If the online retailer wishes to share all or part of this data with another entity, the online retailer may need to use an old and slow method to transfer the data, such as File Transfer Protocol (FTP), or even copy the data onto physical media and then mail the physical media to another entity. This has several disadvantages. First, it is slow. Copying terabytes (bytes) or terabytes (bytes) of data may take days. Second, once the data is delivered, the sharer has no control over what the data happens. The recipient can change the data, make copies, or share with others. Again, the only entity interested in accessing such large data sets in such a manner is a large company that can afford the complex logistics of transferring and processing data, as well as the high price of such cumbersome data transfers. Thus, smaller entities (e.g., "couple shops") or even smaller, more flexible, cloud-centric pioneers often are too expensive to access the data, even though the data may be valuable to their businesses. This may be because the raw data assets are often too coarse and full of potentially sensitive data to be sold directly to other companies. The data owner must first perform data scrubbing, de-tagging, aggregation, connection, and other forms of data enrichment before it can be shared with another party. This is both time consuming and expensive. Finally, for the reasons described above, conventional data sharing methods do not allow scalable sharing, and thus it is difficult to share data assets with many entities. The traditional sharing approach also introduces latency and delay to all parties accessing the most recently updated data.

Private data exchange may allow data providers to more easily and securely share their data assets with other entities. The private data exchange may use the data provider's trademark and the data provider may control who can access it. Private data exchanges can only be used internally or can also be open to customers, partners, suppliers or others. The data provider can control which data assets are listed and who can access which data sets. This allows a seamless way to discover and share data within the organization of the data provider and its business partners.

Private data exchange may be facilitated through cloud computing services such as snowflag, and allows data providers to offer data assets directly from their own online domains (e.g., websites) in private online marketplaces with their own brands. Private data exchange may provide a centralized, managed hub for entities to list internal or external shared data assets, to motivate data collaboration, and to maintain data governance and audit access. Through private data exchange, data providers are able to share data without copying data between companies. The data provider can invite other entities to view their data listings, control which data listings appear in their private online marketplaces, control who can access the data listings, and how others can interact with data assets connected to the listings. It can be considered a "walled garden" market where visitors entering the garden must be approved and access to certain listings may be restricted.

For example, company a may be a consumer data company that has collected and analyzed the consumption habits of millions of individuals in several different categories. Their data set may include the following categories of data: online shopping, video streaming, power consumption, car usage, internet usage, clothing purchases, mobile application purchases, club membership, and online subscription services. Company a may wish to provide these data sets (or a subset or derivative of these data sets) to other entities. For example, a new brand of clothing may wish to access a data set relating to consumer clothing purchases and online shopping habits. Company a may support a page on its website that is or functions substantially similar to a private data exchange where a data consumer (e.g., a new clothing brand) may browse, explore, discover, access, and possibly purchase a data set directly from company a. Further, company a may control: who can enter the private data exchange, entities that can view a particular list, actions that an entity can take with respect to a list (e.g., view only), and any other suitable actions. In addition, the data provider may combine its own data with other data sets from, for example, a public data exchange, and create a new list using the combined data.

Private data exchange may be a suitable place to discover, combine, clean up, and enrich the data to make it more profitable. A large company may aggregate data for its various branches and departments in a private data exchange, which may be valuable to another company. In addition, participants in the private ecosystem data exchange can work together to join their data sets together to create a useful data product that neither of them can produce alone. Once these connected datasets are created, they can be listed on public or private data exchanges.

The systems and methods described herein provide a flexible and extensible data warehouse using a new data processing platform. In some embodiments, the described systems and methods utilize cloud infrastructure that supports cloud-based storage resources, computing resources, and the like. Example cloud-based storage resources provide a large amount of storage capacity available on demand at low cost. Furthermore, these cloud-based storage resources may be fault tolerant and highly scalable, which may be expensive to implement in private data storage systems. Example cloud-based computing resources are available on demand and may be priced based on the actual usage level of the resource. Typically, the cloud infrastructure is dynamically deployed, reconfigured, and disabled (decommissioning) in a fast manner.

In the described systems and methods, a data storage system utilizes a relational database based on SQL (structured query language). However, these systems and methods are applicable to any type of database and any type of data storage and retrieval platform that stores and retrieves data within the data storage and retrieval platform using any data storage architecture and using any language. The systems and methods described herein also provide a multi-tenant (multi-tenant) system that supports isolation of computing resources and data between different customers/clients (clients) and between different users within the same customer/client.

FIG. 1A is a block diagram of an example computing environment 100 in which the systems and methods disclosed herein may be implemented. In particular, cloud computing platform 110 may be implemented, such as an AMAZON Web SERVICE ^TM (AWS)、MICROSOFT AZURE ^TM 、GOOGLE CLOUD ^TM And so on. As known in the art, the cloud computing platform 110 provides computing that can be acquired (purchased) or leased and configured to execute applications and store dataResources and storage resources.

The cloud computing platform 110 may host cloud computing services 112, the cloud computing services 112 facilitating storage (e.g., data management and access) and analytics functions (e.g., SQL queries, analytics) and other computing capabilities (e.g., secure data sharing between users of the cloud computing platform 110) of data on the cloud computing platform 110. The cloud computing platform 110 may include a three-tier architecture: data storage 140, query processing 130, and cloud services 120.

The data store 140 may facilitate storing data on the cloud computing platform 110 in one or more cloud databases 141. The data store 140 may store data and query results on the cloud computing platform 110 using a storage service, such as AMAZON S3. In particular embodiments, to load data into cloud computing platform 110, a data table may be horizontally partitioned into large, immutable files, which may resemble blocks or pages in a traditional database system. Within each file, the values of each attribute or column are grouped together and compressed using a scheme sometimes referred to as hybrid column (hybrid column). Each table has a header that contains, among other metadata, an offset for each column in the file.

In addition to storing table data, data store 140 facilitates storing temporary data generated by query operations (e.g., joins) as well as data contained in large query results. This may allow the system to compute large queries without memory starvation or disk starvation errors. Storing query results in this manner can simplify query processing because it does not require server-side cursors in traditional database systems.

Query processing 130 may handle query execution within a flexible cluster of virtual machines (referred to herein as a virtual warehouse or data warehouse). Thus, query processing 130 may include one or more virtual warehouses 131, virtual warehouses 131 also may be referred to herein as data warehouses. Virtual warehouse 131 may be one or more virtual machines running on cloud computing platform 110. Virtual warehouse 131 may be a computing resource that may be created, destroyed, or resized at any time as desired. This functionality may create a "flexible" virtual warehouse that may expand, contract, or close according to the needs of the user. Extending a virtual warehouse involves generating one or more compute nodes 132 to virtual warehouse 131. Shrinking the virtual warehouse involves removing one or more compute nodes 132 from virtual warehouse 131. More compute nodes 132 may result in faster computation times. For example, a data load that takes 15 hours to perform on a system with four nodes may only take 2 hours on a system with 32 nodes.

The cloud service 120 may be a collection of services that coordinate activities on the cloud computing service 110. These services bundle all of the different components of the cloud computing service 110 together in order to handle user requests distributed from login to query. The cloud service 120 may operate computing instances provided by the cloud computing service 110 from the cloud computing platform 110. Cloud services 120 may include services that manage virtual warehouses, queries, transactions, data exchanges, and collections of metadata associated with these services, such as database schemas, access control information, encryption keys, and usage statistics. The cloud services 120 may include, but are not limited to, an authentication engine 121, an infrastructure manager 122, an optimizer 123, an exchange manager 124, a security 125 engine, and a metadata store 126.

Fig. 1B is a block diagram illustrating an example virtual warehouse 131. The exchange manager 124 may facilitate data sharing between data providers and data consumers using, for example, private data exchanges. For example, cloud computing service 112 may manage storage and access to database 108. Database 108 may include various instances of user data 150 for different users (e.g., different businesses or individuals). The user data may include a user database 152 of data stored and accessed by the user. The user database 152 may be access controlled such that only the owner of the data is allowed to change and access the database 112 after authentication with the cloud computing service 112. For example, the data may be encrypted such that it can only be decrypted using decryption information owned by the owner of the data. Using the switching manager 124, certain data from the user database 152 subject to these access controls may be shared with other users in a controlled manner according to the methods disclosed herein. In particular, a user may specify a share 154, which share 154 may be shared in an uncontrolled manner in a public or private data exchange, as described above, or shared in a controlled manner with a particular other user. "shared" encapsulates all the information needed to share data in the database. The sharing may include at least three pieces of information: (1) rights to grant access to the database and the schema containing the objects to be shared, (2) rights to grant access to specific objects (e.g., tables, secure views, and secure UDFs), and (3) consumer accounts shared with the database and its objects. When sharing data, the data is not copied or transferred between users. The sharing is accomplished through the cloud service 120 of the cloud computing service 110.

Sharing data may be performed when a data provider creates a share of a database in the data provider's account and grants access to specific objects, such as tables, security views, and secure User Defined Functions (UDFs). The read-only database may then be created using the information provided in the share. Access to the database may be controlled by a data provider.

The shared data may then be used to process the SQL query, which may include joins, aggregations, or other analyses. In some cases, the data provider may define the sharing such that a "secure connection" is allowed to be performed with respect to the shared data. A secure connection may be performed such that analysis may be performed with respect to the shared data, but the actual shared data is not accessible to data consumers (e.g., shared recipients). The secure connection may be performed as described in U.S. application serial No. 16/368,339 filed on 3/18/2019.

User devices 101 and 104, such as laptop computers, desktop computers, mobile phones, tablet computers, cloud-hosted serverless processes, or other computing processes or devices, may be used to access virtual warehouses 131 or cloud services 120 over a network 105, such as the internet or a private network.

In the following description, actions are attributed to users, particularly consumers and providers. It should be understood that such actions are performed with respect to the device 101 and 104 operated by such a user. For example, the notification to the user may be understood to be a notification sent to the device 101-104, the input or instruction from the user may be understood to be received through the device 101-104 of the user, and the user interaction with the interface should be understood to be interaction with the interface on the device 101-104 of the user. Additionally, database operations (connections, aggregations, analyses, etc.) attributed to a user (consumer or provider) should be understood to include the cloud computing service 110 performing such actions in response to instructions from the user.

FIG. 2 is a schematic block diagram of data that may be used to implement public or private data exchanges according to an embodiment of the present invention. The exchange manager 124 may operate with respect to some or all of the illustrated exchange data 200, and the exchange data 200 may be stored on a platform (e.g., the cloud computing platform 110) executing the exchange manager 124 or at some other location. The exchange data 200 may include a plurality of lists 202 that describe data shared by a first user ("provider"). The list 202 may be a list in a private data exchange or in a public data exchange. Access control, management, and administration of lists may be similar for both public and private data exchanges. The list 202 may include metadata 204 describing the shared data. The list 202 may include metadata 204 describing the shared data. The metadata 204 may include some or all of the following information: an identifier of the sharer sharing the data, a URL associated with the sharer, a name of the share, a name of the table, a category to which the shared data belongs, an update frequency of the shared data, a directory of the tables, a number of columns and rows in each table, and a name and description of the columns. Metadata 204 may also include examples of data that assists a user in using the data. Such examples may include a sample table or view (which includes a sample of the rows and columns of the example table), an example query that may be run against the table or possible results thereof, an example view of the example table, an example visualization based on table data (e.g., chart, dashboard). Other information included in the metadata 204 may be metadata for use by the business intelligence tool, textual descriptions of data contained in the table, keywords associated with the table to facilitate searching, bloom filters or other full-text indexes for data in certain columns, links (e.g., URLs) to documents related to shared data, and refresh intervals indicating the frequency of updates to the shared data (or indications that the shared data is continually updated) and the date of the last update of the data.

The list 202 may include access controls 206, and the access controls 206 may be configured in any suitable access configuration. For example, access control 206 may indicate that shared data is available unrestricted to any member of the private exchange ("any share" as used elsewhere herein). Access control 206 may specify categories of users (members of a particular group or organization) that are allowed to access data and/or view lists. The access control 206 may specify "peer-to-peer" sharing (see discussion of fig. 4), where the user may request access, but only allowed access upon approval by the provider. The access control 206 may specify a set of user identifiers for the user that are excluded from being able to access the data referenced by the list 202.

Note that some lists 202 may be discovered by the user without further authentication or access permission, with actual access only allowed after subsequent authentication steps (see discussion of fig. 4 and 6). Access control 206 may specify that list 202 is only discoverable by a particular user or class of users.

It should also be noted that the default function of the list 202 is that the shared referenced data is not exportable or reproducible by the consumer. Alternatively, access control 206 may specify that the operation is not allowed. For example, access control 206 may specify that security operations (such as secure connections and security functions, as discussed below) may be performed with respect to the shared data such that the shared data is not allowed to be viewed and exported.

In some embodiments, once a user is authenticated with respect to list 202, a reference to the user (e.g., a user identifier of the user's account in virtual warehouse 131) is added to access control 206 so that the user will then access the data referenced by list 202 without further authentication.

The list 202 may define one or more filters 208. For example, the filter 208 may define a particular user identifier 214 of a user that may view a reference to the list 202 when browsing the catalog 220. The filter 208 may define a category of users (users of a particular industry, users associated with a particular company or organization, users within a particular geographic region or country) that may view references to the list 202 when browsing the catalog 220. In this manner, the same components may be used by the switching manager 124 to implement private switching. In some embodiments, excluded users in excluded access list 202 (i.e., adding list 202 to the excluded user's consumption share 156) may still be allowed to view a representation of the list while browsing directory 220, and may further be allowed to request access to list 202, as described below. Requests to access the list by such excluded users and other users may be listed in an interface presented to the provider of the list 202. The provider of the list 202 may then review the requirements for access to the list and select the expansion filter 208 to grant access to the excluded users or categories of excluded users (e.g., users of the excluded geographic region or country).

The filter 208 may further define which data the user may view. In particular, the filter 208 may indicate that a user selecting the list 202 to add to the user's consumption share 156 is allowed to access data referenced by the list but only a filtered version that includes only data associated with the user's identifier 214, associated with the user's organization, or some other classification specific to the user. In some embodiments, the private exchange is by invitation: upon delivery acceptance of the invitation received from the provider, the user invited by the provider to view the list 202 of private exchanges is allowed to conduct the private exchange through the exchange manager 124.

In some embodiments, the list 202 may be addressed to a single user. Thus, a reference to the list 202 may be added to a set of "pending shares" viewable by the user. The list 202 may then be added to the user's set of shares after the user passes the approval to the exchange manager 124.

The list 202 may further include usage data 210. For example, the cloud computing service 112 may implement a points system in which points are purchased by a user and consumed each time the user runs a query, stores data, or other service implemented using the cloud computing service 112. Thus, usage data 210 may record points consumed by accessing shared data. The usage data 210 may include other data, such as the number of queries, the number of aggregations of each of multiple types performed against shared data, or other usage statistics. In some embodiments, the usage data for the list 202 or lists 202 of users is provided to the users in the form of a shared database (i.e., the switching manager 124 adds a reference to the database including the usage data to the user's consumption share).

The list 202 may also include a heat map 211, which heat map 211 may represent the geographic location of the user's clicks on that particular list. The cloud computing service 110 may use the heatmap to make replication decisions or other decisions about the list. For example, the private data exchange may display a list containing weather data for the state of georgia in the united states. The heatmap 211 may indicate that many users of california are selecting the list to learn about the weather in georgia. In view of this information, the cloud computing service 110 may replicate the list and make the list available in a database (the servers of which are physically located in the western united states) so that consumers in the state of california may access the data. In some embodiments, the entity may store its data on a server located in the western united states. A particular listing may be highly popular with consumers. The cloud computing service 110 may replicate this data and store it in servers located in the eastern united states so that consumers in the midwest and east coast may also access the data.

The list 202 may also include one or more tags 213. Tags 213 may facilitate easier sharing of data contained in one or more lists. For example, a large company may have a list of Human Resources (HR) that contains HR data for internal employees on a private data exchange. The HR data may contain ten types of HR data (e.g., employee number, selected health insurance, current retirement plan, job title, etc.). The HR list is accessible to 100 people in the company (e.g., each of the HR departments). A management layer of the HR department may wish to add an eleventh type of HR data (e.g., employee stock option plans). Rather than manually adding it to the HR list and granting each of the 100 people access to the new data, the management layer may simply apply the HR tag to the new data set, and the HR tag may be used to classify the data as HR data, list it with the HR list, and grant 100 people access to view the new data set.

The list 202 may also include version metadata 215. The version metadata 215 may provide a way to track how the data set changes. This may help ensure that the data being viewed by an entity does not change prematurely. For example, if a company owns an original data set and then publishes an updated version of the data set, the update may interfere with the processing of the data set by another user because the update may have a different format, new columns, and other changes that may not be compatible with the current processing mechanisms of the recipient user. To remedy this, the cloud computing service 112 may track version updates using the version metadata 215. The cloud computing service 112 may ensure that each data consumer accesses the same version of the data until they accept an updated version that does not interfere with the current processing of the data set.

The exchange data 200 may further include a user record 212. User records 212 may include data identifying the user associated with user records 212, e.g., an identifier of the user (e.g., a repository identifier) having user data 150 in service database 128 and managed by virtual repository 131.

The user record 212 may list shares associated with the user, such as the reference list 202 created by the user. The user record 212 may list shares consumed by the user, such as a reference list 202 created by another user and already associated with the user's account according to the methods described herein. For example, the list 202 may have an identifier that will be used to reference it in the sharing or consumption sharing of the user record 212.

Exchange data 200 may further include a directory 220. The catalog 220 may include a listing of all available listings 202 and may include an index of data from the metadata 204 to facilitate browsing and searching according to the methods described herein. In some embodiments, the list 202 is stored in a directory in the form of a JavaScript object notation (JSON) object.

Note that where multiple instances of virtual warehouse 131 exist on different cloud computing platforms, directory 220 of one instance of virtual warehouse 131 may store lists or references to lists from other instances on one or more other cloud computing platforms 110. Thus, each list 202 may be globally unique (e.g., assigned a globally unique identifier across all instances of virtual warehouse 131). For example, an instance of virtual warehouse 131 may synchronize its copies of catalog 220 such that each copy indicates a list 202 available from all instances of virtual warehouse 131. In some instances, the provider of the list 202 may specify that it is only available on a specified one or more computing platforms 110.

In some embodiments, catalog 220 is available on the Internet so that it can be searched by a search engine such as BING or GOOGLE. The directory may be subject to Search Engine Optimization (SEO) algorithms to improve its visibility. A potential consumer may thus browse the catalog 220 from any web browser. The switching manager 124 may expose a Uniform Resource Locator (URL) linked to each list 202. The web page under each URL may be searchable and may be shared outside of any interface implemented by the exchange manager 124. For example, a provider of a listing 202 may publish a URL of its listing 202 to facilitate use of its listing 202 and its brand.

FIG. 3 illustrates various components 300 and 310 that may be included in the switching manager 124. The creation module 300 may provide an interface for creating the list 202. For example, the web interface enables a user on one or more of devices 101-104 to select data, such as a particular table in the user data 150 of the user, for sharing and entering values defining some or all of the metadata 204, access controls 206, and filters 208. In some embodiments, the creation may be performed by a user through SQL commands in an SQL interpreter executing on the cloud computing platform 110 and accessed through a web interface on the user device 101 and 104.

The confirmation module 302 can confirm the information provided by the provider when attempting to create the list 202. Note that in some embodiments, the actions attributed to the confirmation module 302 may be performed by a human review provider provided information. In other embodiments, these actions are performed automatically. The confirmation module 302 may perform or facilitate a human operator to perform various functions. These functions may include: verify that the metadata 204 is consistent with the shared data it references; the shared data referenced by the verification metadata 204 is not pirated data, Personal Identification Information (PII), Personal Health Information (PHI), or other data for which sharing or sharing of illegitimate is undesirable. The validation module 302 may also facilitate verifying whether the data has been updated within a threshold period of time (e.g., within the last twenty-four hours). Validation module 302 can also facilitate verifying that data is not static or cannot be obtained from other static public sources. Validation module 302 can also facilitate verifying that the data is not just a sample (e.g., the data is complete enough to be useful). For example, geographically limited data may be undesirable, while aggregation of otherwise unrestricted data may still be useful.

The switching manager 124 may include a search module 304. The search module 304 may implement a web interface accessible by the user on one or more of the user devices 101-104 to invoke a search for the search string with respect to the metadata in the catalog 220, receive a response to the search, and select a reference to the list 202 in the search results to add to the consumption shares 156 of the user record 212 of the user performing the search. In some embodiments, the search may be performed by the user through SQL commands in an SQL interpreter executing on the cloud computing platform 102 and accessed through a web interface on the user device 101 and 104. For example, search sharing may be performed by SQL queries against the directory 220 within the SQL engine 310 discussed below.

The search module 304 may further implement a recommendation algorithm. For example, the recommendation algorithm may recommend other lists 202 for the user based on the other lists in the user's consumption share 156 or previously in the user's consumption share. Recommendations may be based on logical similarity: one source of weather data results in a recommendation of a second source of weather data. Recommendations can be made based on different points: one list is for data in one domain (geographical area, technical field, etc.), resulting in a list in different domains (different geographical areas, related technical fields, etc.) to facilitate complete coverage of user analysis.

The switching manager 124 may include an access management module 306. As described above, the user may add the list 202. This may require authentication with respect to the provider of the list 202. Once the list 202 is added to the consumption share 156 of the user's user record 212, the user may (a) need to authenticate each time the data referenced by the list 202 is accessed, or (b) automatically authenticate and be allowed access to the data once the list 202 is added. The access management module 306 may manage automatic authentication of subsequent access to data in the user's consumption share 156 in order to provide seamless access to shared data as if it were part of the user data 150 for that user. To this end, the access management module 306 may access the access controls 206, certificates, tokens, or other authentication material of the list 202 to authenticate the user when performing access to the shared data.

The switching manager 124 may include a connection module 308. The connection module 308 manages the integration of shared data referenced by the user's consumption shares 156 (i.e., shared data from different providers) with each other and with the user database 152 of data owned by the user. In particular, the connection module 308 may manage the execution of queries and other computing functions with respect to these various data sources such that their access is transparent to the user. The connection module 308 may further manage access to the data to enforce restrictions on the shared data, such as making it possible to perform analysis and display the results of the analysis without exposing the underlying data to the data consumer (where the restrictions are indicated by the access controls 206 of the list 202).

The exchange manager 124 may further include a Standard Query Language (SQL) engine 310, the SQL engine 310 programmed to receive queries from users and execute the queries on data referenced by the queries, which may include the user's consumption shares 156 and the user data 112 owned by the users. SQL engine 310 may perform any query processing function known in the art. SQL engine 310 may additionally or alternatively include any other database management tool or data analysis tool known in the art. The SQL engine 310 may define a web interface executing on the cloud computing platform 102 through which SQL queries are entered and responses to the SQL queries are presented.

Referring to fig. 4A, the illustrated method 400 may be performed by the switching manager 124 to enable peer-to-peer sharing between a first user ("provider 402") and a second user ("consumer 404").

The method 400 may include the provider inputting 406 metadata. This may include a user on provider's device 101-104 entering metadata into fields of a form in a web page provided by exchange manager 124. In some embodiments, the metadata may be entered 406 by the SQL engine 310 using SQL commands. The metadata items may include some or all of those discussed above with respect to the metadata 204 of the list 202. Step 406 may include receiving other data for the list 202, such as access controls 206 and parameters defining the filters 208.

Provider 402 may then invoke the submission of forms and input data on device 101-104.

The exchange manager 124 may then verify 408 the metadata and validate 410 the data referenced by the metadata. This may include performing some or all of the actions attributed to the confirmation module 302.

If the metadata and shared data are not successfully verified 408 and confirmed 410, the exchange manager 124 may notify the provider 402, such as by way of a notification through a network interface through which the metadata is submitted at step 406.

If the metadata and shared data are not successfully validated 408 and validated 410, the exchange manager 124 may notify the provider 402, such as through a web interface through which the metadata was submitted at step 406.

The switching manager 124 may further create 412 a list 202 including the data submitted in step 406, and may further create an entry in the directory 220. For example, keywords, descriptive text, and other information items in the metadata may be indexed to facilitate searching.

Note that step 406-412 may be performed by way of an interface provided to provider 402. Such an interface may include any suitable features, including elements for inputting data (e.g., elements 204 and 210), and elements for generating a data list. Additionally, the interface may include an element for publishing the data list, or an element that does not publish (unpublish) the data list so that the list is not viewable to at least some other users. The interface may also include elements for updating a version of the data list or rolling back to a previous version of the list or metadata associated with the list. The interface may also include a list of add data or a list of pending requests to add members to the data exchange. The interface may also include an indication of the quantity and other non-identifying information associated with the data consumer accessing a given list, as well as a representation of the usage pattern of the data referenced by the list by the data consumer of the list.

Another user acting as consumer 404 may then browse 414 the catalog. This may include accessing a web page that provides a directory search interface. The web page may be external to virtual warehouse 131, i.e., accessible by users who are not logged into virtual warehouse 131. In other embodiments, only users logged into virtual warehouse 131 may be able to access the search interface. As described above, the browsing of the catalog 220 may be performed using a query to the SQL engine 310 that references the catalog 220. For example, the user device 101-104 may have a web-based interface to the SQL engine 310 through which queries for the catalog 220 are entered by the consumer 404 and sent to the SQL engine 310.

In response to the consumer's browsing activity, exchange manager 124 may display a catalog and perform 416 a search with respect to the catalog to identify listings 202 having metadata corresponding to a query or search string submitted by consumer 404. The manner in which this search is performed may be according to any search algorithm known in the art. In the case of an SQL query, the query may be processed according to any method known in the art for processing SQL queries.

The exchange manager 124 may return the results of the search string or SQL query to the device 101 of the consumer 404 and 104, such as in the form of a list of references to the list 202 identified from the search algorithm or processing the SQL query. The list may include metadata items or links that consumer 404 may select to invoke the metadata display. In particular, any item of metadata 204 for the list 202 may be displayed in the list or linked by an entry in the list corresponding to the search record 202.

Note that the exchanges referenced in fig. 4A may be private exchanges or public exchanges. In particular, those lists 202 that are displayed and searched 416 during browsing 414 and that consumer 404 may view may be limited to those lists having filters 208 that indicate that the list 202 may be viewed by consumer 404, the organization of the consumer, or some other category to which consumer 404 belongs. Where the exchange is public, then in some embodiments, consumer 404 need not satisfy any filtering criteria.

Method 400 may include consumer 404 requesting 418 access to data corresponding to list 202. For example, by selecting an entry in the list on device 101 and 104 of consumer 404, this invokes transmission of a request to switching manager 124 to add the list 202 corresponding to the entry to the consumption share 156 in user record 212 of consumer 404.

In the example shown, the list 202 of selected entries has an access control 206. Accordingly, exchange manager 124 may forward 420 the request to provider 402 along with the identifier of consumer 404. Consumer 404 and provider 402 may then interact to perform either or both of: (a) authenticating (logging in) 424 consumer 404 with respect to provider 402; and (b) processing 424 a payment for accessing the data referenced by the list 202. The interaction may be according to any login or authentication or method known in the art. Likewise, any method for processing payments between parties may be implemented. In some embodiments, data warehouse module may provide a discount to provider 402 due to points consumed by consumer 404 when accessing the provider's shared data. Points, which may be units of use purchased by a user, are then consumed in response to services of virtual warehouse 131 used by consumer 404 (e.g., queries and other analysis performed on data hosted by virtual warehouse 131). The interaction may be directly between consumer 404 and provider 402's device 126, or may be performed through exchange manager 124. In some embodiments, exchange manager 124 uses access control information 206 to authenticate consumer 404 such that no interaction with provider 402 is required. Likewise, the list 202 may define payment terms such that the exchange manager 124 processes the payment without interaction with the provider 402. Once provider 402 determines that consumer 404 is authenticated and authorized to access the data referenced by list 202, provider 402 may notify 426 exchange manager 124 that consumer 404 may access the data referenced by list 202. In response, exchange manager 124 adds 428 a reference to list 202 to consumption share 156 in user record 212 of consumer 404.

Note that in some cases, list 202 does not list specific data, but instead references a specific cloud service 120, such as a brand name or company name of the service. Thus, the request to access the list 202 is a request to access the user data 150 of the requesting consumer. Thus, steps 422, 424, 426 include authenticating consumer 404 with respect to authentication engine 121 so that cloud service 120 can verify the identity of consumer 404 and inform exchange manager 124 which data is to be shared with consumer 404 and indicate that consumer 404 is authorized to access the data.

In some embodiments, this may be accomplished using a "single sign on" approach, in which the consumer 404 authenticates (logs in) once with respect to the cloud service 120, and then enables the consumer 404 to access the consumer 404 data in the service database 158. For example, exchange manager 124 may present an interface to cloud service 120 on device 101 and 104 of consumer 404. The consumer 404 enters authentication information (username and password, credentials, tokens, etc.) into the interface and the information is forwarded to the authentication engine 121 of the cloud service 120. The authentication information processes the authentication information and, if the information corresponds to a user account, notifies the exchange manager 124 that the consumer 404 is authenticated with respect to the user account. The exchange manager 124 may then identify the user data 150 for the user account and create a database referencing the data. A reference to the database will then be added to the consumption share 156 of consumer 404.

In some embodiments, user authentication with virtual warehouse 131 is sufficient to authenticate the user with cloud service 120, such that steps 422, 424 are omitted in view of previous authentication of consumer 404. For example, consumer 404 may indicate virtual warehouse 131 to cloud service 120 to be authorized to verify the identity of consumer 404.

In some embodiments, exchange manager 124 uses access control information 206 to authenticate consumer 404 such that no interaction with provider 402 is required. Likewise, the list 202 may define payment terms such that the exchange manager 124 processes the payment without interaction with the provider 402. Thus, in such embodiments, step 422 is performed by switching manager 124 and step 426 is omitted. Once consumer 404 is authenticated and/or provided with the required payment, exchange manager 124 performs step 428.

In some embodiments, adding list 202 to the consumption share of consumer 404 may further include: acceptance of the terms presented to the consumer 404 is received from the consumer 404. In some embodiments, in the event that the terms of the agreement are changed by provider 402 after consumer 404 has added list 202 according to method 400 described herein or other methods, exchange manager 124 may require consumer 404 to agree to the changed terms before allowing it to continue to access the data referenced by list 202.

Adding 428 the data referenced by the list 202 may include creating a database of referenced data. A reference to the database may then be added to the consumption share 156 and the database may then be used to process queries that reference the data referenced by the shared record. Adding 428 data may include adding data filtered according to the filter 208. For example, data referenced by list 202 and associated with consumer 404, an organization of consumer 404, or some other classification of consumer 404 (e.g., a filtered view of the data).

In some embodiments, adding list 202 to user record 212 may include changing access control 206 of list 202 to reference identity data 214 of consumer 404 so that an attempt to access the data referenced by list 202 will be allowed and performed by switching manager 124.

The consumer 404 may then input 432 the query to the SQL engine 310 via the consumer's device 101-104. The query may reference the data referenced in the list 202 added at step 428 as well as other data referenced in the user database 152 and consumption share 156. SQL engine 310 then processes 430 the query using the database created at step 428 and returns the results to consumer 404, or creates a view, instantiates a view or other data that the user can access or analyze. As described above, the data shared by consumption of the query operation may have been previously filtered to include only data relevant to consumer 404. Thus, different consumers 404 who add the same list 202 to their consumption shares 156 will see different versions of the database referenced by the list 202.

Referring to FIG. 4B, in some embodiments, private sharing of data and filtering of data according to the identity of consumer 404 may be implemented using the data structures shown. For example, the service database 158 of the provider 402 may include a customer map 434, the customer map 434 including an entry for a customer identifier 436 of a user of a service provided by the provider 402 (e.g., a service implemented by the cloud service 120 of the server), and an entry for the customer identifier 436 as an identifier for authenticating with the authentication interface 120. Customer mapping 434 may map each customer identifier 436 to a repository identifier 438, i.e., a user identifier that a user uses to authenticate to virtual repository 131, such that the same user corresponds to both identifiers 436, 438. The mapping between identifiers 436 and 438 may be performed by authentication as described above (e.g., the single point sign-on method described above).

The customer map 434 may further include a reference 440 to an entitlement table 442, which entitlement table 442 may be one of a plurality of entitlement tables 442. Each entitlement table 442 defines which of the one or more tables 444 of the provider 402 can be accessed with the customer ID436 mapped thereto. The rights table 442 may further define a column of the table 444 that may be accessed using the customer ID 436. The rights table 442 may further define a row or type of row based on one or more filter criteria of the table 444 that may be accessed using the customer ID 436. The rights table 442 may further define a schema for the table 444 that may be accessed using the customer ID 436.

Thus, list 202 of tables 444 may specify that access to data tables 444 is to be performed as defined by customer mapping 434. For example, referring to fig. 4C, when consumer 404 requests to add a list 202 for a database for which access is defined according to the customer mapping, switching manager 124 may create a secure view 446 according to customer identifier 436 and rights table 442 mapped to repository identifier 438 of consumer 404. The secure view may be generated by performing an internal connection of a data table 444 of the database specified in the rights table 442 (or a portion of the data table as specified in the rights table 442) filtered according to the customer identifier 436, such that the connection result includes only the data of the particular customer identifier 436 and only those portions of the database specified in the rights table 442 (the table 444 and/or portions of the table 444). The manner in which the security view is generated may be as described in U.S. application Ser. No. 16/055,824 entitled "SECURE DATA SHARING IN A MULTI-TENAT DATABASE" filed on 6.8.2018 and U.S. application Ser. No. 16/241,463 entitled "SECURE DATA SHARING IN A MULTI-TENAT DATABASE" filed on 7.1.2019.

Fig. 5 illustrates an alternative method 500 for sharing data, which alternative method 500 may be performed when a consumer requests 418 to add a list 202 available to all users of a public or private exchange. In this case, exchange manager 124 adds 428 a reference to list 202 to consumer 404's consumption share 156 and omits the authentication or payment step. Step 428 may be performed as described above except that no change to access control 206 is performed. Also, as described above, steps 430 and 432 may be performed with respect to shared data. The exchange of fig. 5 may be a public exchange or a private exchange as described above with respect to fig. 4. Fig. 5 illustrates that if the list 202 is viewable (i.e., the filter criteria allow the consumer 404 to view as described above), the consumer 404 may add the list 202 to the consumer 404's consumption share 156 without further authentication or payment.

Note that when the list 202 is added to the user's consumption share 156 according to any of the methods disclosed herein, the exchange manager 124 may notify the consumer of the list 202 when the data referenced by the list 202 is updated.

Referring to fig. 6, in some embodiments, method 600 may include consumer 404 browsing a catalog from exchange manager 124 and selecting list 202 as described for other methods described herein (e.g., see fig. 4A and 5), bi-directional sharing of data referenced by the list ("shared data"), as well as additional data in user database 112 ("user data"). Note that in some embodiments, the list 202 of providers 402 does not reference any particular data (e.g., a particular table or database), but rather provides fulfillment services with respect to the data provided by the consumers 404. Thus, in such cases, as described below, "sharing data" may be understood as being replaced with "provided services".

In response to the request, exchange manager 124 implements 604 point-to-point sharing of shared data with respect to consumer 404 and provider 402. This may be performed as described above with respect to fig. 4A, including, for example, authentication of consumer 404, and possibly filtering the shared data to include only data associated with consumer 404, as described above. The switching manager 124 may further enable peer-to-peer sharing of user data with respect to the provider 402 as described with respect to fig. 4A, except that: (a) consumer 404 acts as a provider and provider 402 acts as a consumer of user data, and the user's data is added to consumption share 156 of provider 402, and (b) consumer 404 need not create list 202 for the user data, and the user data need not be listed in catalog 220.

After step 606, either consumer 404 or provider 402 may access shared data and user data. Queries may then be run against both, they are connected, aggregation is performed on the connected data, or any other action or enrichment known in the art is performed with respect to multiple databases.

In some embodiments, the bidirectional sharing may include or be requested by consumer 404 including provider 402 also connecting 608 the shared data and user data to obtain connection data, and returning 610 the reference to the connection data to switching manager 124 with a request (by switching manager 124) to add 612 the reference to the connection data to consumption share 156 of consumer 404.

Thus, consumer 404 will now have access to the connected data. Step 608 may further include performing other actions (aggregation, analysis) on the user data and the shared data before or after the connection. Virtual warehouse 131 may perform step 608 in response to a request from consumer 404 to do so.

Note that the connection result may be (a) a new database as a result of the connection, or (b) a connection database view that defines a connection of shared data and user data.

The results from step 608 (join, aggregate, analyze, etc.) may alternatively be added to the original sharing performed at steps 606, 608, e.g., a view (materialized or not) defining the operation performed at step 608.

Step 608 and 612 may also be performed by virtual warehouse 131 in response to a request from consumer 404 or provider 402 to do so independently of the request made at step 602.

Note that in many cases, there are many consumers 404 attempting to perform bi-directional sharing with respect to provider 402, and these consumers 404 may seek bi-directional sharing with respect to their user data, which may take many different formats (schemas) that may be different from the schemas used by provider 402 for sharing data. Thus, step 608 may include a transformation step. The transforming step maps a source pattern of user data to a target pattern of shared data. The transformation may be a static transformation provided by a human operator. The transformation may be according to an algorithm that maps column labels of the source schema to corresponding column labels of the target schema. The algorithm may include a machine learning or artificial intelligence model trained to perform the transformation. For example, a plurality of training data entries may be specified by a human annotator, each entry including as input a source pattern and as output a mapping between the source pattern and a target pattern. These entries can then be used to train a machine learning or artificial intelligence algorithm to output a mapping to a target pattern for a given input source pattern.

The shared data added to consumption by consumers 404 and providers 402 may then be operated on by consumers 404 and providers 402, respectively, such as by performing queries against the data, aggregating the data, analyzing the data, or performing any other action described herein as being performed with respect to the sharing added to the user's consumption share 156.

In particular embodiments, as described above, a data provider may improve its relationship with business partners by enabling secure exchange of data in a bi-directional manner. The conventional two-way data sharing method is difficult to implement and can only share a very limited data set via API, FTP or file transfer between companies. This typically involves significant cost, expense, data delay, and even some security risks.

The data provider may instead host a private data exchange and invite its customers and partners to participate in the exchange. Customers and partners may access the data, for example, in a secure view, and they may also push the data in the other direction. This may be sharing the data back to the host or listing the data so that other participants of the ecosystem can also share the data securely. Data from public data exchanges, other private exchanges, or from other external sources may also be included.

Each large company depends on other companies and their customers. Two-way sharing of data not only from the company to these parties, but also between these external parties, can allow for the development of a rich collaborative data ecosystem where corporate groups can work around data together. They can securely discover, consolidate and enrich data assets to help serve common customers or to establish new partnerships between each other. Some of these relationships may even lead to opportunities to sell data, secure views across data, or functionality to other participants of the walled garden ecosystem.

Referring to FIG. 7, a method of sharing and consuming data as described herein enables enriching data and returning the enriched data to the exchange. For example, provider a may request 702 and exchange shared data (share 1) in the same manner as other methods described herein. The switching manager 124 validates, and adds 704 share 1 to the directory 220.

Second provider B may then browse catalog 220 and add 706 share 1 to its consuming share 156. Provider B may perform 708 operations on the shared data, such as concatenating it with other data, performing aggregation, and/or performing other analysis on share 1, resulting in modified data (share 2). Provider B may then request 710 to share 2 with the exchange described herein. Note that the connection of step 708 may include connecting any number of databases, such as any number of shares based on any number of lists of any number of other users. Thus, the iteration of steps 702-710 for many users can be viewed as a hierarchical structure in which a larger list 202 of a plurality of users is narrowed to a smaller number of lists 202 based on data from a larger number of lists 202.

The switching manager 124 validates, and adds 712 share 2 to the directory 220. As provider a, provider B, or a different provider adds share 2, based on which modified data is generated and the results are added back to the catalog in the same manner, the process may be repeated 714 with respect to share 2. In this way, users can be made to obtain rich data and analyze the ecosystem. The sharing according to method 700 may be any sharing, point-to-point sharing, private exchange sharing, or bidirectional exchange sharing according to the methods disclosed herein.

Note that there is a possibility that the provider may perform steps 708 and 710 with respect to the list 202 based on the list 202. For example, provider B uses list L1 for provider A to create list L2, provider C uses this list L2 to create list L3, and provider A uses this list L3 to define list L1. Such a flow may include any number of steps. This may be undesirable in some cases (so that list L1 is not allowed to be modified to refer to L3 in view of deriving L3 from L1). In other cases, such a cycle is allowed if there is a time delay in refreshing the data referenced by each list. For example, L1 may reference L3, provided that L3 is not refreshed until some time after L1 is refreshed, and thus the cyclic reference does not result in continuous updates of L1 and L3 indefinitely. The present disclosure also contemplates non-circular streams such that list L1 is not affected by the use of list L1 by other providers.

The list created at step 712 (share 2) may (a) include a copy of the data from share 1 that remains after step 708 and is as modified according to step 708, or (b) include a view that references share 1 (e.g., a database that was created based on list 202 of share 1 according to the methods disclosed herein) and defines the operations performed at step 708 without including actual data from share 1 or derived from share 1. Thus, the hierarchy as described above may be a hierarchy of views that reference one or both of the list 202 of views created according to the method 700 or the list 202 of data from one or more providers according to any of the methods disclosed herein.

In the methods disclosed herein, methods for creating shares (list 202) and for adding shares are disclosed. In a similar manner, consumer 404 may instruct exchange manager 124 to delete the added share. Provider 402 may instruct the switching manager 124 to stop sharing certain lists 202. In some embodiments, this may be accompanied by an action to avoid interfering with consumers 404 of those lists 202. Such as by notifying these consumers 404 and only stopping sharing list 202 after a specified period of time after notification or after all consumers 404 delete references to list 202 from their consumption shares 156.

Use case

In a first use case, a company implements private exchanges according to the method described above. In particular, the list 202 of companies is viewable only by consumers 404 (employees, managers, investors, etc.) associated with the companies. Likewise, only people associated with the company are allowed to add the list 202. When the list 202 is added to the consumption share 156, it may be filtered based on the identity of the consumer that added the list, i.e., data related to the consumer's role in the company.

In a second use case, provider 402 creates a reader account or reader/writer account for consumer 404 that has not yet become a user of virtual warehouse 131. The account may be associated with account data for the consumer (see the consumer mapping of FIG. 4B discussed above). Consumer 404 may then log into the account and then access the list of providers to access consumer data 404 managed by provider 402 (see, e.g., the discussion of fig. 4A).

In a fifth use case, consumer 404 adds private shares (e.g., accessible according to the methods described above due to the identity of consumer 404), as well as public shares. Consumers 404 may then connect these shares and use them to process queries.

In a sixth use case, the list 202 may be shared based on subscriptions (e.g., monthly), or the list 202 may be accessed based on a price or credit boost multiplier for each query. Accordingly, exchange manager 124 may manage the processing of payments and accesses such that consumer 404 is allowed access to data (subscriptions, per query, etc.) subject to the pricing model.

In a seventh use case, exchange manager 124 implements a secure function and a secure machine learning model (both training and scoring) that can be used to process private data, such that consumer 404 is allowed to use the results of the function or machine learning model, but does not have access to the raw data processed by the function or machine learning model itself. Also, consumers of the shared data are not allowed to export the shared data. Nevertheless, consumers are allowed to perform analysis functions on the shared data. For example, the following security functions may be implemented to enable customer shopping data to be viewed in a secure manner:

create or replace secure function

UDF_DEMO.PUBLIC.get_market_basket(input_item_sk number(38))

returns table(input_item NUMBER(38,0),basket_item_sk NUMBER(38,0),

num_baskets NUMBER(38,0))

as

'select input_item_sk,ss_item_sk basket_Item,count(distinct

ss_ticket_number)baskets

from udf_demo.public.sales

where ss_ticket_number in(select ss_ticket_number from udf_demo.public.sales where ss_item_sk＝input_item_sk)

group by ss_item_sk

order by 3desc,2'；

in an eighth use case, the switching manager 124 may provide usage statistics (e.g., queries, points used, tables scanned, tables hit, etc.) for the list 202 by one or more consumers 404 to the provider 402 of the list.

In a ninth use case, the systems and methods disclosed herein are used for industry-specific applications. For example: 1. network security (Cybersecurity)

a. Allowing sharing of risk vectors, bad actors, IP whitelists/blacklists, ongoing real-time attacks, known good/bad email programs, etc

2. Medical health care

a. Secure sharing of patient information, including cost information and outcome information, among other types of information

b. Multi-hospital databases are protected so that patients can share their information to multiple providers. (for example, if patient A lives in California and vacates to Florida, is injured and receives treatment in the emergency room, a Florida hospital may be able to access patient A's records from different hospitals and providers).

Other industries may also benefit from private or public sharing of data according to the systems and methods disclosed herein. Such as financial services, telecommunications, media and advertising, government agencies, military and intelligence agencies.

In a tenth use case, the first user provides marketing services to the second user, and thus, the second user shares the customer list with the first user. The first user shares data about the marketing campaign, such as campaign metadata, current user events (session start/end of a particular user, purchases of a particular user, etc.), to the second user. This can be achieved using the two-way sharing of fig. 6. This data (customer list from first user + customer events) may be concatenated to better understand the events for a particular user or group of users. As described above, such data exchange may be performed without creating a copy or transferring data-each user accessing the same copy of the shared data. Because there is no data transfer, the data can be accessed in near real time as the customer event occurs.

Fig. 8 is a block diagram illustrating a network environment in which data providers may share data via a cloud computing service. The data provider 810 may upload one or more data sets 820 into the cloud storage device using the cloud computing service 112. These data sets may then be viewed by one or more data consumers 101-104. The data provider 810 can use the cloud computing service 112 to control, monitor, and increase the security of its data using the methods and systems discussed herein. In particular embodiments, the data provider 810 may implement private data exchange on its own online domain using the functions, methods, and systems provided by the cloud computing service 112. Data provider 810 may be any data provider such as, for example, a retail establishment, a government agency, a poll agency, a non-profit organization, and the like. Data consumers 101-104 may be internal to data provider 810 or external to data provider 810. The data consumers inside the data provider can be employees of the data provider 810. The data provider may be a bicycle sharing company that provides bicycles at a daily, monthly, yearly, or travel-based fee. The bike sharing company may collect data about its users such as basic demographic information as well as ride information, including ride date, ride time, and ride duration. This information may be available to employees of the bicycle sharing company via the cloud computing service 112.

The interaction between the data provider 810, the private data exchange 812 (as implemented by the cloud computing service 112), and the data consumer may be as follows. The data provider can create one or more lists 811 using the data set 820. The list may be for any suitable data. For example, a consumer data company may create a list called "video streaming" that contains data related to the video streaming habits of a large number of users. The data provider may set a listing policy 821 on who can view the listing 811, who can access the data in the listing 811, or any other suitable policy. Such list policies are discussed above with reference to fig. 2. The data provider 810 may then submit to the private exchange 812 at step 813. The private data exchange 812 may be embedded within the network domain of the data provider 810. For example, if the network domain of the consumer data company is www.entityA.com, then a private data exchange may be found at www.entityA.com/privatedataexchange. If the list complies with one or more rules determined by the cloud computing service 112, the private data exchange 812 may receive the list and approve it at step 814. The private data exchange 812 may then set access control at 815 based at least in part on the list policy set in step 821. Private data exchange 812 may then invite the member at step 816. The member may be a data consumer 801. Data consumer 801 may accept the invitation at step 817 and may then begin consuming data at 818. The type of data consumption may depend on the access control established at 815. For example, a data consumer may only read data or share data. As another example, a data consumer can perform any combination of the above-described read or share operations on data according to access controls. Typically, data sharing does not involve changing the shared data.

In some embodiments, data consumer 801 may independently access private data exchange 812 by navigating directly to private data exchange 812 in a browser, or by clicking on an advertisement for private data exchange 812, or by any other suitable mechanism. Private data exchanges may also be presented via custom or other code by accessing lists and other information via an API. If data consumer 801 wishes to access data within the list and the list is not yet generally available or data consumer 801 does not yet have access rights, data consumer 801 may need to request access at step 820. The data provider may approve or deny the request at 822. If approved, the private data exchange may grant access to the list at 823. The user may then begin consuming the data as described above.

In particular embodiments, one or more data exchange administrator accounts may be specified by cloud computing service 112. A data exchange administrator may manage private data exchange members by designating members as data providers 810 or data consumers 801. The data exchange administrator can control the visibility of the lists by selecting which members can see a given list. The data exchange administrator may also have other functions, such as approving the list before publishing the list onto the private data exchange, tracking usage of each list in the list, or any other suitable administrative function. In some embodiments, the data provider and the data exchange administrator are part of the same entity; in some embodiments, they are separate entities. The provider may create a list, may test sample queries for data under the list, may set access to the list, grant access to requests for the list, and track usage of each list in the list and data under the list. Data consumer 801 may access private data exchanges and browse visible lists that may be displayed as tiles (tiles). To consume the data below the list, the consumer may immediately access the data, or may request access to the data.

Fig. 9 is an example private data exchange 900 according to an embodiment of the invention. The private data exchange 900 may be what a data consumer sees when navigating to the private data exchange on the network. For example, a data consumer may enter www.entityA.com/privatedataexchange into their browser. As discussed herein, the "entity a data exchange" may be a private data exchange facilitated by the cloud computing service 112 and embedded into entity a's own network domain or application, or may be accessed via an API. The private data exchange 900 may include several lists, such as lists a-L, for different data sets. The lists a-L may also be referred to herein as data directories that may allow visitors of the private data exchange to view all available lists in the private data exchange. These lists may be placed by an administrator inside entity a. Providing data catalogs in this manner may be used to combine the advantages of crowd-sourced content (crowdsourced content), data quality, and appropriate levels of centralized control and coordination, which may overcome challenges that slow adoption of other enterprise data classification approaches, such as indexing and crawling systems. It allows users throughout the enterprise to provide data, use data in other groups, and concatenate data together to create a rich data product for internal use and potentially for external profit.

By way of example and not limitation, entity A may be a consumer data company that has collected and analyzed the consumption habits of millions of people in a plurality of different categories. Their data set may include the following categories of data: online shopping, video streaming, power consumption, car usage, internet usage, clothing purchases, mobile application purchases, club membership, and online subscription services. Each of these data sets may correspond to a different list. For example, list a may be used for online shopping data, list B may be used for video streaming data, list C may be used for power consumption data, and so on. Note that the data may be anonymous, so that the identity of the individual is not revealed. The list located below line 915 may correspond to a list of third parties that entity a may allow on its private data exchange. Such lists may be generated by other data providers and may be subject to approval by entity a before being added to the private data exchange 900. The data consumer can click on and view any list subject to the various access controls and policies discussed above with reference to fig. 2, 4, and 8.

In particular embodiments, the data provider may invite the member to access its private data exchange, as discussed with reference to fig. 8. One class of members may be physical and digital supply chain providers of the data provider. For example, data providers may share data with suppliers in terms of their inventory levels or consumption of items provided by the suppliers so they may better meet the needs of the data providers. In addition, the digital data provider can provide data directly into its private data exchange so that it is immediately available for and connected to internal enterprise data, saving both parties the cost of transmitting, storing, and loading the data.

Some companies, such as hedge funds and marketing institutions, import data from many external sources. Some hedge funds evaluate hundreds of potential data sets each year. The private data exchange can be used not only to connect purchased data, but also to evaluate new data assets. For example, hedged funds may have potential data providers list their data on their private exchanges, and the funds may explore and "buy" the data in their private data stores that are unique customers. As discussed with reference to fig. 11, such internal data stores may also "tunnel" data assets from a public data exchange (e.g., a snowflag public data exchange).

As another example, an existing provider of marketing data for a company may list some additional data sets that its customers may use via their private exchange on a trial basis, and if the customers find them useful, the provider may immediately provide full access through the same exchange. These arrangements may result in greater data depth, bi-directional and fresher data, and greater trust and transparency in the relationship between the suppliers of data and physical goods and their customers.

FIG. 10 is a diagram illustrating an example security view of shared data from a private data exchange. When data consumer 1020 wishes to access data in a list (e.g., list H), cloud computing service 112 may facilitate access via a secure view 1010 of shared data. The secure view of shared data 1010 may include metadata 1015, the metadata 1015 including the metadata and access controls discussed herein with reference to fig. 2. This may enable data providers to share data without exposing underlying tables or internal details. This makes the data more private and secure. With the secure view of shared data 1010, the view definition and details are only visible to authorized users.

In private data exchange, data can be shared within the same entity as well as between different entities. In addition, data sharing may be unidirectional, bidirectional, or multidirectional. In one embodiment, this may result in up to five main use cases for sharing data: bi-directional inter-entity, bi-directional intra-entity, uni-directional inter-entity, uni-directional intra-entity, and multi-directional multi-entity. An example of bi-directional inter-entity data sharing may be data sharing from a portfolio company to a parent company and between portfolio companies. An example of bi-directional intra-entity data sharing may be data sharing from a large corporate headquarters to different business divisions within the corporation, and also data sharing from business divisions to headquarters. An example of one-way inter-entity data sharing may be a large data provider (e.g., a national weather service) that shares data with many different entities but does not receive data from those entities. An example within a unidirectional entity may be a large company that provides data to its corresponding business segments, but does not receive data from those business segments. In particular embodiments, data may be shared as "point-to-point sharing" or "any sharing" of particular data. Peer-to-peer sharing of specific data may include private data exchange sharing between a parent company and a specific portfolio company. Any sharing may include private data exchange sharing from a parent company to numerous data consumers on or within a public exchange.

In particular embodiments, cloud computing service 112 may generate a private data exchange for an entity that is the owner of data to be shared on the private data exchange. The cloud computing service 112 may specify one or more administrators of private data exchanges. These administrators may control the access rights of private data exchanges with respect to other users. For example, an administrator can add another user account to a private data exchange and designate that account as a data provider, a data consumer, an exchange administrator, or a combination of these.

In particular embodiments, the exchange administrator may control the viewing and access rights of the private data exchange. The viewing permissions may include a list of entities that can view the list in the private data exchange. The access rights may include a list of entities that may access the data after selecting a particular list. For example, a company may publish a private data exchange 900 and may include several lists, list a through list L. Each of these lists may include their own individual viewing and access rights. For example, list a may include a first list of entities that have access to view the list on the private data exchange 900 and a second list of entities that have access to the list. Viewing the list may simply see that the list exists on the private data exchange. Accessing the list may select the list and access the underlying data for the list. Accessing may include viewing underlying data, manipulating the data, or both. Controlling viewing rights may be useful for data providers that do not want some users to even know that a certain list exists in a private data exchange. Thus, when a user who does not have viewing rights to a particular list accesses a private data exchange, that user will not even see the list on the exchange. In particular embodiments, the viewing and access rights discussed above may be provided through an Application Program Interface (API). The exchange directory may be a query and may be updated via an API. This may allow the data provider to display the list to anyone visiting on its own application or website. When a user wants to access or request access to data, the user may then create an account and obtain access using the cloud computing service 112. In some embodiments, the URL may be invoked when a user requests access to data in the list. This may allow integration with external request approval workflows. For example, if a user issues an access request, an external request approval workflow of the data provider may be accessed and activated. The external request approval workflow may then operate normally to perform the external request approval process. In some embodiments, the list may not be listed, meaning that the list exists but is not visible on the data exchange. To access the unlisted list, the consumer may enter a global URL in the browser. This may require a unique URL for each list.

In particular embodiments, when creating a new private data exchange for a data provider, cloud computing service 112 may specify an exchange administrator (e.g., a data transaction administrator as discussed above), and may also generate the following metadata regarding the private data exchange: the name of the private data exchange (which must be unique), the display name, the logo, a short description of the private data exchange, and an indication of whether Approval by the exchange administrator is required for publication (e.g., Admin _ Approval _ for _ Publishing). This may be a true/false statement. The exchange administrator may set this to true if they need to approve the list submitted to the private data exchange before they are published. If the exchange administrator does not need to provide such approval, it may be set to false. In this case, the provider may publish the data directly. If the exchange administrator sets Admin _ Approxal _ for _ Publishing to true, the exchange administrator can see the list of lists and select the list to preview and approve/reject. The owner of the private data exchange may be an account that is charged for the private data exchange. The metadata information may be stored as part of the exchange object. Also stored in association with the private data exchange are users and accounts that provide data to the exchange, consumers of the exchange, and exchange administrators.

In particular embodiments, the exchange administrator may add members to the private data exchange by inviting members (e.g., data providers and data consumers) in any suitable manner. For example, by inviting a user account on the cloud computing service 112, or by sending an email to the user's email account address. When the exchange administrator adds a member to the private data exchange, the exchange administrator may also specify one or more member types: exchange administrator, provider, or consumer. The exchange administrator is able to add and delete members from the private data exchange, as well as edit metadata associated with the private data exchange. For each user, the exchange administrator may specify whether the user is an exchange administrator, a data provider, and a data consumer or multiple of these roles. The following table summarizes the permissions associated with each type of account.

Table 1: permissions associated with each type of private data exchange account

In some embodiments, if the exchange administrator deletes a member or simply changes the type of member from provider to consumer, the existing list published by that member may be changed from exchange to unpublished. In addition, the existing shares that the member added to the exchange are no longer considered part of the private data exchange. The list published by the member may be archived and no longer visible to anyone (including the member) in the UI. The cloud computing service 112 may cancel the archiving if the same member (the same account on the cloud computing service 112) that has been deleted becomes the provider again.

In some embodiments, the exchange administrator can specify a category list and edit an existing list. A category may have an icon associated with it and the exchange administrator can specify the icon along with the category name.

When a member becomes a data provider, a provider profile may be generated that includes a logo, a description of the provider, and a URL of the provider's website. Upon submitting the list, the provider may perform the following operations: selecting which private data exchange to publish the data (e.g., there may be many private exchanges, and the provider may need to select a subset of these exchanges, which may be one or more), and set metadata about the new list. The metadata may include a list title, a list type (e.g., standard or personalized), a list description, one or more use examples (e.g., title and sample queries), a list category (which may be entered as free-form text), an update frequency of the list, supporting emails/URLs, and document links. The provider may also set access rights to the list. The provider may allow the exchange administrator to control the visibility of the list, or the provider may retain that control itself. The provider may also associate the sharing with the list. For standard sharing, a list may be associated with zero or more shares. The provider may associate the sharing with the list through UI or SQL. For personalized sharing, when a provider provides a share in response to a request, the provider may associate the share with a list. When a provider wishes to publish a list, the list may first require the approval of an exchange administrator, depending on the publication rules of the private data exchange.

Fig. 11 is a diagram illustrating example tunneling of a data list between a public data exchange and a private data exchange. Alternatively, data may be tunneled between two public data exchanges or between two private data exchanges, or from one public exchange to multiple private exchanges, or in any other suitable combination. In some embodiments, an entity may wish to provide a publicly listed data list on its private data exchange. For example, entity B may wish to include a list F of public data exchanges 1100 on its own private data exchange 1000. The data below list F may be tunneled from public data exchange 1100 to private data exchange 1000. In particular embodiments, data may be tunneled between two private data exchanges. At times, the first data provider may wish to allow the second data provider to list data belonging to the first data provider on the second data provider's private data exchange. Tunneling of data lists may allow two data providers to provide the same list. For example, entity a and entity B may have a business agreement to share list F on each of their private data exchanges. The list F may be the property of entity a, but entity B may also have a license to provide it on its private data exchange. In this case, both lists, entitled "list F," will point to the same data set stored in the cloud computing platform 110. The tunnel 1015 is a representation that illustrates that the list F can be shared securely and easily between two or more data exchanges 1100 and 1000. No data is copied or transferred during tunneling. Instead, each list contains a pointer to the data referenced by list F discussed herein.

In particular embodiments, tunneling links may be completed between private data exchanges and public data exchanges, and vice versa. For example, data exchange 1100 may be a public data exchange. Entity B may use the list listed on public data exchange 1100 on its own private data exchange 1000 via tunnel 1015. In some embodiments, the data list may be tunneled from one data exchange to another, and the base data may then be connected with another data set, and a new list may then be generated from the combined data set. By way of example and not limitation, the first data set may be listed on a private data exchange that includes NBA player shot statistics for the last five years. The second data set may be listed on a different data exchange that includes weather data over the same time span. The two data sets may be concatenated and listed as a new list in a private or public data exchange. The data consumer may then access this data set according to the viewing and access controls discussed herein to see how weather may affect the player's shot hit rate. Additionally, if the data is listed on a public data exchange (e.g., a data exchange hosted by the cloud computing service 112), the data may be tunneled to a private data exchange.

In some embodiments, tunneling of data sets may be used to create public or private "industry wide" data exchanges. Many different entities may tunnel data sets to a "large ecosystem data exchange". If the private ecosystem's data exchange really rises up, it may become so bulky and influential that it may become a standard place for data exchange, collaboration, and monetization throughout the industry. Each industry may have one or two spaces for "large ecosystem data exchange". Once any exchange has gained a great deal of attraction, it may become the industry's "go". If more than one viable exchange occurs in an industry, their respective owners may decide to collaborate and "cross-tunnel" trade some (but possibly not all) assets between their exchanges to reach a critical volume.

While industry alliances can host such exchanges through tunneling, it is likely that one or two large participants in each industry will quickly and widely direct ecosystem-private data exchange to become the actual data exchange for their industry. This provides a tremendous incentive for companies that wish to be the primary participant in their industry data to establish internal data exchanges as soon as possible and then quickly open up to their suppliers, customers and partners.

FIG. 12 is a diagram illustrating an example data query and delivery service 1200 according to some embodiments of the invention. The data query and delivery service 1200 illustrates four ways in which data providers can share data. The first way is through data exchange 900. The data exchange 900 may be a public data exchange or a private data exchange. The data provider 1210 may list 1211 data on the data exchange according to the methods and systems described herein with reference to fig. 2, 4, and 8. Data consumer 1220 may access the data in the list by accepting an invitation from a data provider as discussed herein or by accessing the list via request 1212 as discussed herein with reference to fig. 8. A second way to share data may be to share data directly 1213. This may be point-to-point sharing as discussed with reference to fig. 4, or may be any other suitable type of sharing implemented using the secure data sharing methods discussed herein. Note that both data providers 1210 and data consumers 1220 are users of cloud computing service 112. If the data provider 1210 wishes to share data with the non-user 1230, this may be as a third way of sharing data with the reader account 1215a or with the reader account/writer account 1215 b. Here, the non-user may need to have a reader account, but may not necessarily be the actual user of the cloud computing service 112. The reader account may allow the non-user 1230 to view the data, but do no other processing on the data. Finally, a fourth way to share data is via a file drag-and-drop to cloud storage 1214. Here, the data provider 1210 may replicate the data set 1216 and may allow another non-user 1230 to have the data set 1216. This way of sharing data may not allow the data provider 1210 to retain control over the data set. Thus, using the fourth approach, the non-users 1230 are able to view, manipulate, and re-share data.

Global data sharing

As described above, private data exchange is used within one data area of a cloud computing service or within a single cloud computing service. A customer may wish to be able to have one or more lists across multiple areas of a cloud computing platform and/or across multiple cloud computing platforms. In order for a data provider to share a data set across multiple cloud computing platform regions and/or multiple cloud computing platforms, the data provider needs to set up accounts in different regions, log into each account to set up replication, and refresh using tasks. The data provider needs to be shared with the consumers in the target area and needs to replicate the entire database. The entire process adds a significant amount of overhead to the data provider. Furthermore, when a Virtual Private Cloud (VPC) customer wants to consume shared data through data exchange, the customer currently has no way to do so within his VPC account. Alternative methods, such as requiring the customer to open a multi-tenant account and save shared data there, place a burden on the consumer. In one embodiment, the multi-tenant account is an account in a system that supports isolation of computing resources and data between different customers/clients and between different users within the same customer/client. Therefore, it is difficult. It is useful for data providers (and customers who consume such data) to implement cross-region and cross-cloud data sharing.

In one embodiment, for global data sharing, there are two types of data: standard and personalized. The standard data represents the same data for each consumer. For example, there is no dynamic filtering of rows based on a customer account. In contrast, personalization data represents data that is unique to each consumer (or group of consumers). In one embodiment, the personalization data may have a secure view to dynamically filter rows of data based on the consumer's account so each consumer sees their own slice of data. In yet another embodiment, for data providers, this means that they can create views for some or all of their consumers, rather than creating views for each consumer.

In one embodiment, the list of shared data may include metadata, or a set of Database (DB) objects, associated with zero or more shares. Further, the list may be free data or paid data. In addition, the data provider may grant the consumer access to the shared data based on whether the shared data is standard (where each customer may access the same shared data), or whether the shared data is personalized (where the data is shared on an individual or group basis). For personalized data, in one embodiment, the data provider adds each customer of the data to the entitlement table. Alternatively, non-personalized data may still require some type of approval process for the customer to access the data. For example, in one embodiment, in a private exchange, obtaining access to the share may require approval of the workflow even if the data itself is not personalized. Thus, in one embodiment, for standard data sharing, the data provider need not be in the request implementation loop. Any consumer account that discovers the list may access the data and use the data to create a database therefrom. Alternatively, for data that is shared by request, the data provider will need to explicitly add the consumer to the share.

In another embodiment, standard sharing may exist in the context of data exchange (whether public or private) as data exchange represents the membership base available to it and how the list is discovered. In one embodiment, the data shared by the data providers is also referred to as data sharing. In one embodiment, the consumer should not be really concerned about the underlying sharing type (e.g., standard or per Request). Further, the consumer can always interact with the standard list. In this embodiment, the data providers must know the shares to create them. However, the data exchange will handle the creation of these shares.

In one embodiment, the sharing of data outside of the exchange is by definition a share on request. Further, the data exchange may include a non-listed or undiscoverable list of criteria that have no entries in the data exchange. The effective membership basis for this is any snowfall customer. However, the consumer cannot discover the list because the data provider would send the list URL. In this embodiment, anyone viewing the URL and logging into the data exchange can view the data and create a DB from the share, for example.

In one embodiment, both the standard list and the on-demand list may be free or paid for. If the data sharing is free, the consumer may create a DB from the shared data once the consumer accepts the provider terms. If the data sharing is a payment, the consumer may accept the terms and arrange for the payment. The consumer may then create a DB from the share. In one embodiment, for a criteria list, data may or may not be available in the region: if the data in the region is not already available, the consumer still clicks on the fetch and may create a database from the share. In this regard, the data exchange may let them know that the data will be available for a certain amount of time (e.g., there may be a visual countdown if in seconds, or a progress bar indication in the UI). In one embodiment, the personalized data sharing may be of the type shared or listed on request.

Fig. 13A is a block diagram of an example system 1300 of multiple cloud computing platforms sharing data with data exchange. In FIG. 13A, the system 1300 includes two different cloud computing platforms 1302A-B, where each cloud computing platform 1302A-B may be one of the cloud computing platforms described above in FIG. 1. Each cloud computing platform 1302A-B is coupled to a data exchange 1306. In one embodiment, the data exchange 1306 is similar to the data exchange described above, except that the data exchange 1306 may support data sharing across multiple cloud computing platforms (such as cloud computing platforms 1302A-B).

In one embodiment, cloud computing platform 1302A includes data provider sharing 1304. In this embodiment, the data providers share some or all of their data 1304 via a data exchange 1306, the data exchange 1306 being visible to data consumers in both cloud computing platforms 1302A-B. For example, in one embodiment, a data consumer 1308 in a different cloud computing platform (e.g., cloud computing platform 1302B) may view a list of data provider shares 1304 via data exchange. If the data consumer 1308 requests the list, in response, the data exchange 1306 may create a provider account in the cloud computing platform 1302B for the data provider share 1304 and copy the data share to the cloud computing platform 1302B. With data sharing 1310 replicated in cloud computing platform 1302B, data consumers 1308 may access data. In one embodiment, the data exchange 1306 may replicate the entire data provider share 1304, or may replicate some of the data provider shares 1304. In one embodiment, the data provider indicates which portions of the data provider to share 1304 to copy. In another embodiment, the data exchange 1304 infers which portions the data provider shares 1304 are to replicate. In this embodiment, the data exchange may infer the objects that the data provider shares that need to be replicated, the frequency with which these objects need to be replicated, and/or the area of the customer account and the corresponding provider secondary account.

Fig. 13B is a block diagram of an example system 1320 of a cloud computing platform that shares data with data exchanges across multiple regions of the cloud computing platform. In fig. 13B, system 1320 includes a cloud computing platform having two different regions 1322A-B, where each cloud computing platform region 1322A-B may be a different geographic region of the cloud computing platform (e.g., the western united states, the eastern united states, europe, asia, and/or another type of geographic region). In one embodiment, each cloud computing platform region 1322A-B is coupled to a data exchange 1306. In one embodiment, data exchange 1306 is similar to the data exchange described except that data exchange 1306 may support data sharing across multiple cloud computing platforms (such as cloud computing platform regions 1322A-B).

In one embodiment, cloud computing platform region 1322A includes data provider share 1304. In this embodiment, the data providers share some or all of their data 1304 via a data exchange 1306, which data exchange 1306 is visible to data consumers in both cloud computing platforms 1302A-B. For example, in one embodiment, data consumers 1308 in a different cloud computing platform area (e.g., cloud computing platform area 1302B) may view a list of data provider shares 1304 via data exchange. If the data consumer 1308 requests the list, in response, the data exchange 1306 may create a provider account in the cloud computing platform 1322B for the data provider share 1304 and copy the data share to the cloud computing platform area 1322B. With data sharing 1310 replicated in cloud computing platform region 1322B, data consumers 1308 may access data. In one embodiment, the data exchange 1306 may replicate the entire data provider share 1304, or may replicate some of the data provider shares 1304. In one embodiment, the data provider indicates which portions of the data provider share 1304 to copy. In another embodiment, the data exchange 1304 infers which portions the data provider shares 1304 are to replicate. In this embodiment, the data exchange may infer the objects that the data provider shares that need to be replicated, the frequency with which these objects need to be replicated, and/or the area of the customer account and the corresponding provider secondary account.

In one embodiment, there are different types of use cases for data sharing across deployments, such as across regions, across clouds, and/or and into/out of VPCs. For example, in one embodiment, a data provider may provide non-personalized on-demand data sharing in or outside of a data exchange, where consumers may be in different deployments. In one embodiment, this is some other type of basic building block that may be built on. Another use case type is a data provider for a standard list of many different consumers (e.g., weather data on public or private exchanges). A third use case type may be a data provider that personalizes the sharing/listing. This use case type may be on public data exchange, in private data exchange, or outside exchange (data sharing only). Finally, one use case type may be that a consumer on the VPC wants to access data sharing in the cloud computing platform. In one embodiment, an additional nuance is that private data exchange adds the addition of providers by the data exchange administrator. Ideally, a data exchange administrator would like to not have to train a provider to manage the complexity of setting up replication to share data from the provider to other private exchange members that may be located on different areas/clouds.

In one embodiment, the subscription data provider wants to share selected tables and/or views whose data is stored on the us-west region of the cloud computing platform with the marketing data company (whose primary account is on the same cloud computing platform, but in a different region, e.g., us-east). In this embodiment, the subscription data provider is a customer of the marketing data provider. The main goal of the marketing data provider is to process this information and incorporate it into the marketing data provider's product. In one embodiment, the cost should affect the data exchange accounts of the marketing data providers, but not the accounts of the subscription data providers. In this embodiment, a secondary goal of the marketing data provider is to share certain views from the marketing data provider to the subscription data provider. In this case, the reservation data provider is a customer of the marketing data provider, and thus the marketing data provider does not want to let the reservation data provider do this. Furthermore, the marketing data provider has a view that references objects in another database, so both databases must be replicated. In one embodiment, the subscription data provider determines which tables and/or views to list in the data exchange. In response to the marketing data provider requesting data sharing via the data exchange, the data exchange creates an account in the U.S. -east region of the cloud computing provider and replicates the relevant data shares of the subscription data provider (e.g., the primary data share and the secondary data indicated by the subscription data provider). FIG. 14 below further describes sharing data across cloud computing platforms and/or regions.

In yet another embodiment, in a private exchange, a non-profit research institution wants a list that members must request access to. In this embodiment, these requests trigger a workflow with a cloud computing platform, each consumer being added once approval is complete. This is a common scenario in private exchanges where data is not personalized, but the consumer needs to go through an approval workflow. Fig. 14 below further describes sharing data across cloud computing platforms and/or regions using an approval workflow.

In another embodiment, the data provider desires to replicate a customized data share set for the consumer across different cloud computing platforms and/or regions. In this embodiment, the data provider only wishes to replicate certain tables of its database. The data of the transport analysis company is in a cloud computing service, where each table contains data of a particular data set. The company shares a particular data set with the customer based on the data set to which the customer subscribes. Transport analysis companies wish to model their data in cloud computing services independently of how shares are created. Then, when the transport analysis company creates shares for a particular customer, they only want to copy those tables. Fig. 14 below further describes sharing data across cloud computing platforms and/or regions using an approval workflow.

In one embodiment, the list of criteria on the public exchange may represent an increased opportunity for data exchange and/or cloud computing services. Payment criteria sharing presents a new source of revenue through monetization. In one embodiment, the consumer is able to obtain the experience of a free or paid listing as immediately as possible. Since the provider does not explicitly add consumers to the share, they are not in the user stream. In addition, data providers also indicate that it is also desirable to generate replication costs based on demand. For example, in one embodiment, a weather data provider has made available a free subset of its data as a free standard list, and wishes to have a paid standard list where customers can immediately pay for and obtain predefined packages. Third, for more customized packages, they want the consumer to contact them and they will establish direct sharing with the consumer. In this case, the most likely scenario is that the free list is available in (almost) all regions. For paid listings, the data provider may want to be available on any deployment as long as there is at least one paying user in the deployment, or if the cloud computing service covers replication costs. Note that while free sharing and paid sharing may be set as filters on the rows (secure views within one share) or as completely separate shares, one case is that these are two separate shares. For example, a retail analysis provider creates different shares for different sets of objects that are free and paid for. In pay sharing, the data provider will have the ability for consumers to select which rows they want to create a dynamically created package. For example, the consumer would select via the data exchange user interface only the location data they want for "Type ═ McDonald's" and "State ═ CA", and therefore only pay for the rows they obtained.

In one embodiment, the data replication described above may be used to handle various scenarios. For example, in one embodiment, brand data providers are building their data-driven marketing solutions on cloud computing services. They will provide standard and personalized sharing over the open exchange. They have hundreds of TBs of data and can share with hundreds of clients, most of which are novices to cloud computing services. Based on the dataset that the client purchases on their platform, they automatically insert the client ID into the entitlement table in the cloud computing service and add their consumer account to the share. They want the auto-share pipeline to be able to work across regions and clouds with little or no human effort. Furthermore, the brand data provider may also wish to share data into the VPC.

The customer relationship company builds a mobile marketing campaign and shares the results with the customers via data exchange. In one example, where activity data arrives at their 50TB event table at least every 15 minutes, consumer-specific data will be shared with the consumer. In addition, the company wants a 15 minute delay (or less) to their customers.

Device manufacturers want to share machine health data with 200 dealers so that they can take corrective action. The amount of data is not large, but data is coming out of the oven all day long, and they want to give their dealer a delay and/or freshness guarantee. "I expect remote data sharing to be a continuous stream of data, not a batch model. "the company will set up the security view based on the entitlement table mapping dealers to devices so that each dealer only sees the row associated with them.

In another example and embodiment, a VPC customer wants to consume shares from data providers in a multi-tenant deployment. In one embodiment, the VPC is an on-demand configurable pool of shared computing resources allocated within a public cloud environment, providing a level of isolation between different organizations using the resources. For example, a finance company wants to consume marketing data from such a company as a marketing company. However, when data from these data sources is consumed directly, considerable effort is required to ingest the data, manage and maintain the ingest process, and alter the management of the underlying schema. Solving a problem commonly referred to as the first mile problem of data ingestion may provide a tremendous benefit. The finance company may have a third party process the data before ingesting the data from the exchange. In addition, financial companies have multiple business departments (BUs) with different requirements and visibility requirements for sharing data. Therefore, when a financial company shares data provided by a third party company with its internal customers (BU), it needs the ability to apply fine-grained security control. Furthermore, any solution to be considered must be easy to use (no additional coding and/or engineering time), robust (no fragile ongoing or maintenance procedures). Processing this type of workflow is further described in FIG. 16 below.

Fig. 14 is a process flow diagram of a method 1400 for sharing data across multiple cloud computing services and/or across multiple regions with a cloud computing service. In general, method 1400 may be performed by processing logic that may comprise hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuits, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. For example, processing logic may be implemented as switching manager 124. Method 1400 may begin at step 1402 with processing logic receiving an indication of data sharing across different cloud computing platforms or cloud computing platforms having multiple regions. In one embodiment, the data provider may create a standard list available to all customers, share data available by request, and/or other types of data sharing as described above. FIG. 15 below further describes creating a list. At block 1404, processing logic receives a request for a list of data shares. In one embodiment, the request is associated with a customer account that is an account of the cloud computing platform or a portion of the cloud computing platform area. For example, in one embodiment, the request may be associated with a customer account of a different cloud computing platform and/or cloud computing platform area that is different from the cloud computing platform and/or cloud computing platform area associated with the listing. Processing logic determines whether to allow the provider customer account in the cloud computing platform and/or cloud computing platform area associated with the listing request. For example, in one embodiment, the provider may have information (e.g., security data) that is not allowed to exceed a certain area. If not, execution proceeds to block 1406 where an error is returned. If the provider customer account is allowed, then processing logic creates a customer account list request at block 1410. In one embodiment, if the request is for a customer who is in a different cloud computing platform and/or cloud computing platform area, processing logic creates a provider account in the cloud computing platform and/or cloud computing platform area so the data provider can share data with the requesting customer.

At block 1412, processing logic shares data. In one embodiment, processing logic shares data by copying the data to a cloud computing platform and/or cloud computing platform area associated with the consumer that issued the original list request. In one embodiment, processing logic may replicate an entire data share or portions of a data share. In this embodiment, processing logic may infer which portions of the data are to be shared based on characteristics (geography, time, etc.) of the requesting consumer. In yet another embodiment, processing logic may customize data based on the consumer (e.g., paid data represents one view as opposed to unpaid data, shared data is based on the consumer's locale, the consumer's affiliation, and/or other types of characteristics). At block 1414, processing logic sets the task for frequency replication. In one embodiment, by setting these tasks, data shared with different cloud computing platforms and/or cloud computing platform regions may be refreshed periodically so that a data provider or consumer does not need to manually refresh the data.

In fig. 14, a consumer requests shared data across different cloud computing platforms and/or cloud computing platform regions. In one embodiment, a data provider may create a list that allows data to be replicated across different cloud computing platforms and/or cloud computing platform regions. Fig. 15 is a process flow diagram of a method 1500 for creating a list in a data exchange, where the list is available in different cloud computing services and/or in multiple areas with cloud computing services. For example, processing logic may be implemented as switching manager 124. Method 1500 may begin at step 1502 where processing logic receives a request from a data provider to create a data list. In one embodiment, the data list may include a list type (e.g., a standard or per-request, whether free or paid, a list of what data to share (e.g., which tables, rows, etc. of a database to share), any sharing restrictions, data provider information, and/or other information for the list.) at block 1504, processing logic creates a list in the data exchange. Processing logic sets up the task for frequency replication. In one embodiment, by setting up these tasks, data shared with different cloud computing platforms and/or cloud computing platform regions may be refreshed periodically so that a data provider or consumer does not need to manually refresh the data.

In one embodiment, another type of sharing model is a model in which a data provider provides shared data to one or more third party entities prior to sharing the data with consumers. This can be used to personalize the shared data to the consumer. Fig. 16 is a process flow diagram of a method 1600 for creating a list for personalized sharing in a data exchange, wherein the list is available in a different cloud computing service and/or in multiple areas with cloud computing services. For example, processing logic may be implemented as switching manager 124. Method 1600 may begin at step 1602, where at block 1602 processing logic receives a request to create a list from a data provider. In one embodiment, the data provider may create a standard list available to all customers, share data available by request, and/or other types of data sharing as described above. In yet another embodiment, the list may include a collection of cloud computing platforms and/or cloud computing platform regions where the list may be visible. The list may be visible in all possible cloud computing areas and/or cloud computing platform clouds, or may be a subset of all possible cloud computing areas and/or cloud computing platform clouds. In addition, the list may include other information (e.g., allowed consumers of the data). At block 1604, processing logic creates a list in the data exchange. In one embodiment, processing logic creates the list by creating an entitlement map that maps the consumer identifier to the data provider. Further, the list may include a secure view of the data that is added to the shared data.

At block 1606, processing logic determines which third party account is to receive the data. In one embodiment, the shared data may be copied to another party for processing prior to sharing the data with the consumer. At block 1608, processing logic determines which objects are to be copied to the potential third party. At block 1610, processing logic copies the data to a third party account. At block 1612, processing logic determines a secure view of the shared data for the potential consumer. In one embodiment, the secure view is used to create a secure way to access shared data for potential consumers. In this embodiment, there may be different security views for different potential consumers, groups of consumers, or the same security view for all potential consumers.

At block 1614, processing logic may copy the shared data and the entitlement table in advance based on the data to be shared and characteristics of the cloud computing entities (e.g., cloud computing platform and/or cloud computing platform area) for the list. For example, in one embodiment, processing logic may share standard data to a different cloud computing platform where existing customers exist, or may pre-share data based on geographic area (e.g., share weather data based on cloud computing platform area) and/or other features.

At block 1616, processing logic receives the list request. In one embodiment, the request is associated with a customer account that is an account that is part of the cloud computing platform and/or cloud computing area. For example, in one embodiment, the request may be associated with a customer account on a different cloud computing platform and/or cloud computing platform area that is different from the cloud computing platform and/or cloud computing platform area associated with the list. Processing logic determines whether the provider customer account is allowed in the cloud computing platform, the cloud computing platform region, and/or the VPC associated with the listing request. For example, in one embodiment, a provider may have information that is not allowed to exceed a certain area (e.g., security of data, personally identifiable information, government restrictions, and/or other types of restrictions). If not, processing logic will return an error. If the provider customer account is allowed, then processing logic creates a customer account list request at block 1618. In one embodiment, if the request is for a customer in a different cloud computing platform, cloud computing platform region, and/or VPC, processing logic creates a provider account in the cloud computing platform and/or cloud computing platform region so the data provider can share data with the requesting customer.

At block 1620, processing logic shares data using the secure view associated with the consumer. In one embodiment, processing logic shares data by copying the data to a cloud computing platform and/or cloud computing platform area associated with the consumer that issued the original list request using the secure view. In one embodiment, processing logic may replicate an entire data share or portions of a data share. In this embodiment, processing logic may infer which portions of the data are to be shared based on characteristics (geography, time, etc.) of the requesting consumer. At block 1622, processing logic sets up the task for frequency replication. In one embodiment, by setting these tasks, data shared with the cloud computing platform and/or cloud computing platform region may be refreshed periodically so that the data provider or consumer does not need to manually refresh the data.

FIG. 17 is a process flow diagram of a method 1700 for sharing data with a VPC. For example, processing logic may be implemented as switching manager 124. Method 1700 may begin at step 1702 where processing logic receives a list request from a consumer using VPC. In one embodiment, processing logic shares data using an account of a previously created VPC. At block 1704, processing logic copies data to the consumer's VPC using the account. In one embodiment, processing logic may replicate an entire data share or portions of a data share. In this embodiment, processing logic may infer which portions of the data are to be shared based on characteristics (geography, time, etc.) of the requesting consumer. In this embodiment, the consumer sees the data sharing through a user interface associated with the VPC account. The consumer may create a database from the shared data. At block 1706, processing logic sets up the task for frequency replication. In one embodiment, by setting these tasks, the data shared with the VPC can be refreshed periodically, so that the data provider or consumer does not need to manually refresh the data.

Fig. 18 is a block diagram of an example computing device 1800 that may perform one or more operations described herein, according to some embodiments. Computing device 1800 can be connected to other computing devices in a LAN, an intranet, an extranet, and/or the internet. The computing device may operate in the capacity of a server machine in a client-server network environment or a client machine in a peer-to-peer network environment. The computing device may be provided by a Personal Computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single computing device is illustrated, the term "computing device" shall also be taken to include any collection of computing devices that individually or jointly execute a set (or multiple sets) of instructions to perform the methodologies discussed herein.

The example computing device 1800 may include a processing device (e.g., a general purpose processor, PLD, etc.) 1802, a main memory 1804 (e.g., synchronous Dynamic Random Access Memory (DRAM), Read Only Memory (ROM)), a static memory 1806 (e.g., flash memory and data storage device 1818), which may communicate with one another via a bus 1830.

The processing device 1802 may be provided by one or more general-purpose processing devices, such as a microprocessor, central processing unit, or the like. In an illustrative example, the processing device 1802 may include a Complex Instruction Set Computing (CISC) microprocessor, Reduced Instruction Set Computing (RISC) microprocessor, Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 1802 may also include one or more special-purpose processing devices such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), network processor, or the like. In accordance with one or more aspects of the present disclosure, the processing device 1802 may be configured to perform the operations described herein to perform the operations and steps discussed herein. In one embodiment, the processing device 1802 represents the cloud computing platform 110 of fig. 1. In another embodiment, processing device 1802 represents a processing device of a client device (e.g., client device 101-104).

The computing device 1800 may further include a network interface device 1808 that may communicate with a network 1820. The computing device 1800 may also include a video display unit 1810 (e.g., a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)), an alphanumeric input device 1812 (e.g., a keyboard), a cursor control device 1814 (e.g., a mouse), and a sound signal generation device 1816 (e.g., a speaker). In one embodiment, video display unit 1810, alphanumeric input device 1812, and cursor control device 1814 may be combined into a single component or device (e.g., an LCD touch screen).

The data storage device 1818 may include a computer-readable storage medium 1828, on which one or more sets of instructions, for example, for performing operations described herein, may be stored according to one or more aspects of the present disclosure. Private data exchange instructions 1426 may also reside, completely or at least partially, within the main memory 1804 and/or within the processing device 1802 during execution of the private data exchange instructions 1826 by the computing device 1800, the main memory 1804, and the processing device 1802, which also constitute computer-readable media. The instructions may further be transmitted or received over a network 1820 via the network interface device 1808.

While the computer-readable storage medium 1828 is shown in an illustrative example to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform the methodologies described herein. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

Unless specifically stated otherwise, terms such as "receiving," "creating," "determining," "sharing," "providing," "specifying," or the like, refer to the actions and processes performed or carried out by a computing device that manipulate and transform data represented as physical (electronic) quantities within the computing device's registers and memories into other data similarly represented as physical quantities within the computing device memories or registers or other such information storage, transmission or display devices. Furthermore, as used herein, the terms "first," "second," "third," "fourth," and the like refer to labels used to distinguish between different elements and do not necessarily have an ordinal meaning according to their numerical designation.

Examples described herein also relate to an apparatus for performing the operations described herein. The apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer readable non-transitory storage medium.

The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with the teachings described herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. As indicated in the description above, the required structure for a variety of these systems will appear.

The above description is intended to be illustrative, and not restrictive. While the present disclosure has been described with reference to particular illustrative examples, it will be appreciated that the present disclosure is not limited to the described examples. The scope of the disclosure should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," "including" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Thus, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

It should also be noted that, in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

Although the method operations are described in a particular order, it should be understood that other operations may be performed between the described operations, the described operations may be adjusted so that they occur at slightly different times, or the described operations may be distributed in a system that allows processing operations to occur at various intervals associated with processing.

Various units, circuits, or other components may be described or claimed as being "configured to" or "configurable to" perform a task or tasks. In such contexts, the phrase "configured to" or "configurable to" is used to denote a structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs one or more tasks during operation. In this way, a given unit/circuit/component may be said to be configured to perform a task, or may be configured to perform a task, even when the unit/circuit/component is not currently operating (e.g., not turned on). Units/circuits/components used with the "configured to" or "configurable" language include hardware-e.g., circuitry, memory storing program instructions executable to implement operations, and so on. Stating that a certain unit/circuit/component is "configured to" perform one or more tasks, or is "configurable to" perform one or more tasks, is obviously not intended to call 35u.s.c.112, paragraph six, for that unit/circuit/component. Additionally, "configured to" or "configurable to" may include general-purpose structures (e.g., general-purpose circuitry) that are manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in a manner that enables performance of the tasks in question. "configured to" may also include adapting a manufacturing process (e.g., a semiconductor manufacturing facility) to manufacture a device (e.g., an integrated circuit) suitable for accomplishing or performing one or more tasks. It is expressly intended that "configurable" does not apply to blank media, an unprogrammed processor or unprogrammed general purpose computer, or an unprogrammed programmable logic device, programmable gate array, or other unprogrammed device, except where there is accompanying programmed media that gives the unprogrammed device the ability to be configured to perform the disclosed functions.

Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a Random Access Memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages. Such code may be compiled from source code into computer-readable assembly language or machine code suitable for the device or computer on which the code is to be executed.

Embodiments may also be implemented in a cloud computing environment. In this specification and the appended claims, "cloud computing" may be defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services), which can be quickly configured (including via virtualization) and published (leased) with minimal management effort or service provider interaction, and then scaled accordingly. The cloud model may be composed of various features (e.g., on-demand self-service, extensive network access, resource pooling, fast-elasticity, and scalable services), service models (e.g., software as a service ("SaaS"), platform as a service ("PaaS"), and infrastructure as a service ("IaaS")), and deployment models (e.g., private, community, public, and hybrid clouds). The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or flowchart block or blocks.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the embodiments and its practical application, to thereby enable others skilled in the art to best utilize the embodiments and various modifications as may be suited to the particular use contemplated. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (30)

1. A method, comprising:

receiving data sharing information from a data provider for sharing a data set in a data exchange from a first cloud computing entity to a set of second cloud computing entities;

creating, by a processing device, an account with each of the set of second cloud computing entities in response to receiving the data sharing information; and

sharing the data set from the first cloud computing entity with the set of second cloud computing entities using at least the corresponding account of the second cloud computing entity.

2. The method of claim 1, wherein the data exchange includes a plurality of data lists provided by a plurality of data providers, the plurality of data lists referencing a plurality of data sets stored in a data storage platform, the data set being one of the plurality of data sets, and the data provider being one of the plurality of data providers.

3. The method of claim 1, wherein the first cloud computing entity is a first cloud computing platform and at least one of the set of second cloud computing entities is a cloud computing platform different from the first cloud computing platform.

4. The method of claim 3, wherein the account with the second cloud computing entity is a provider account of the second cloud computing platform.

5. The method of claim 1, wherein the first cloud computing entity is a first region for a cloud computing platform having a plurality of regions, and at least one of the set of second cloud computing entities is a second region for the cloud computing platform different from the first region.

6. The method of claim 5, wherein the account for the second cloud computing entity is a provider account for the second region of the cloud computing platform.

7. The method of claim 1, further comprising:

determining a frequency of updating the data set shared with the set of second cloud computing entities.

8. The method of claim 1, wherein the sharing of the data set comprises:

determining a set of one or more objects of the shared data set to be replicated by the set of second cloud computing entities; and

replicating the set of one or more objects with the set of second cloud computing entities.

9. The method of claim 1, wherein the account is associated with a customer and the shared data set is customized for the customer.

10. The method of claim 1, wherein the shared data set is a subset of a database managed by the data provider.

11. The method of claim 1, wherein the shared data set references at least one object in a second database different from the first database used to store the shared data set.

12. The method of claim 11, further comprising replicating the at least one object to the set of second cloud computing entities.

13. A non-transitory machine-readable medium storing instructions that, when executed by one or more processors of a computing device, cause one or more second processors to:

receiving data sharing information from a data provider for sharing a data set in a data exchange from a first cloud computing entity to a set of second cloud computing entities;

creating, by a processing device, an account with each of the set of second cloud computing entities in response to receiving the data sharing information; and

sharing the data set from the first cloud computing entity with the set of second cloud computing entities using at least the corresponding account of the second cloud computing entity.

14. The machine-readable medium of claim 13, wherein the data exchange includes a plurality of data lists provided by a plurality of data providers, the plurality of data lists referencing a plurality of data sets stored in a data storage platform, the data set being one of the plurality of data sets, and the data provider being one of the plurality of data providers.

15. The machine-readable medium of claim 13, wherein the first cloud computing entity is a first cloud computing platform and at least one of the set of second cloud computing entities is a cloud computing platform different from the first cloud computing platform.

16. The machine-readable medium of claim 13, wherein the account with the second cloud computing entity is a provider account of the second cloud computing platform.

17. The machine-readable medium of claim 13, wherein the first cloud computing entity is a first region for a cloud computing platform having a plurality of regions, and at least one of the set of second cloud computing entities is a second region for the cloud computing platform different from the first region.

18. The machine-readable medium of claim 17, wherein the account for the second cloud computing entity is a provider account for the second region of the cloud computing platform.

19. The machine-readable medium of claim 13, wherein the instructions further cause the computing device to:

determining a frequency of updating the data set shared with the set of second cloud computing entities.

20. The machine-readable medium of claim 13, wherein the instructions further cause the computing devices to share the data set by:

determining a set of one or more objects of the shared data set to be replicated by the set of second cloud computing entities; and

replicating the set of one or more objects with the set of second cloud computing entities.

21. The machine-readable medium of claim 13, wherein the account is associated with a customer and the shared data set is customized for the customer.

22. The machine-readable medium of claim 13, wherein the shared dataset is a subset of a database managed by the data provider.

23. The machine-readable medium of claim 13, wherein the shared data set references at least one object in a second database different from the first database storing the shared data set.

24. The machine-readable medium of claim 23, wherein the instructions further cause the computing device to:

copying the at least one object to the set of second cloud computing entities.

25. A system, comprising:

a first cloud computing entity; and

a set of second cloud computing entities;

a data exchange to:

receiving data sharing information from a data provider for sharing a data set in the data exchange from a first cloud computing entity to a set of second cloud computing entities;

in response to receiving the data sharing information, creating an account with each of the set of second cloud computing entities, an

Sharing the data set from the first cloud computing entity with the set of second cloud computing entities using at least the corresponding account of the second cloud computing entity.

26. The system of claim 25, wherein the data exchange includes a plurality of data lists provided by a plurality of data providers, the plurality of data lists referencing a plurality of data sets stored in a data storage platform, the data set being one of the plurality of data sets, and the data provider being one of the plurality of data providers.

27. The system of claim 25, wherein the first cloud computing entity is a first cloud computing platform and at least one of the set of second cloud computing entities is a cloud computing platform different from the first cloud computing platform.

28. The system of claim 25, wherein the account with the second cloud computing entity is a provider account of the second cloud computing platform.

29. The system of claim 25, wherein the first cloud computing entity is a first region for a cloud computing platform having a plurality of regions, and at least one of the set of second cloud computing entities is a second region for the cloud computing platform different from the first region.

30. The system of claim 29, wherein the account for the second cloud computing entity is a provider account for the second region of the cloud computing platform.

Images