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

Abstract

Shared data in data exchange across multiple cloud computing platforms and/or regions of cloud computing platforms is described. An example computer-implemented method can 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 also include creating an account with each of the set of second cloud computing entities. The method may 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

This application claims the benefit of US Patent Application Serial No. 16/814,875, filed March 10, 2020, under 35 U.S.C. §119(e), which claims US Provisional Application Serial No. 62, filed January 28, 2020 /966,977, the disclosures of these applications are hereby incorporated by reference in their entirety.

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 can include one or more tables that contain or reference data that can be read, modified, or deleted using queries. Databases may be used to store and/or access personal 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 required to allow other parties to perform queries against a set of data.

Brief Description of Drawings

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

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

1B is a block diagram illustrating an example virtual warehouse.

Figure 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.

3 is a schematic block diagram of components for implementing data exchange according to an embodiment of the present invention.

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.

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

4C is a diagram illustrating a security view for enabling private sharing of data according to an embodiment of the present invention.

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 present invention.

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

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

8 is a block diagram illustrating a network environment in which data providers can share data via cloud computing services.

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

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

11 is a diagram illustrating an example tunneling of data lists between two private data exchanges.

12 is a diagram illustrating an example data query and delivery service in accordance with some embodiments of the present invention.

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

13B is a block diagram of an example system of a cloud computing service that shares data with data exchanges across multiple regions of the cloud computing service.

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.

15 is a process flow diagram of a method for creating a list in a data exchange where the list is available in different cloud computing services and/or in multiple regions with cloud computing services.

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

17 is a process flow diagram of a method for sharing data with a virtual private cloud (VPC).

18 is a block diagram of an example computing device that can perform one or more operations described herein, according to 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 might have a dataset that includes the buying habits of millions of customers over the past decade. This dataset can be quite large. If the online retailer wishes to share all or part of this data with another entity, the online retailer may need to use old and slow methods to transfer the data, such as File Transfer Protocol (FTP), or even copy the data to physical media , and then mail the physical media to another entity. This has several drawbacks. First, it's slow. Copying terabytes or petabytes of data can take days. Second, once the data is passed, the sharer has no control over what happens to the data. The recipient may change the data, copy it or share it with other parties. Again, the only entities interested in accessing such large data sets in this way are large corporations that can afford the complex logistics of transferring and processing the data, and the high price of such troublesome data transfers. As a result, smaller entities (e.g., "mom and pop shops") or even smaller, more flexible, cloud-centric startups are often too expensive to access that data, even though it may be a valuable. This may be because raw data assets are often too crude and full of potentially sensitive data to sell directly to other companies. Data owners must perform data cleansing, de-identification, aggregation, joins, and other forms of data enrichment before they can be shared with another party. This is time consuming and expensive. Finally, due to the above reasons, traditional data sharing methods do not allow scalable sharing, making it difficult to share data assets with many entities. Traditional sharing methods also introduce delays and delays to all parties accessing recently updated data.

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

Private data exchange may be facilitated by cloud computing services such as SNOWFLAKE, and allow data providers to offer data assets under their own brands in private online marketplaces directly from their own online domains (eg, websites). Private data exchanges can provide entities with a centralized, managed hub to list data assets shared internally or externally, inspire data collaboration, and maintain data governance and audit access. With a private data exchange, data providers are able to share data without duplicating data between companies. Data providers can invite other entities to view their data listings, control which data listings appear in their private online marketplace, who can access the data listings, and how others can interact with data assets connected to the listings. Think of it as a "walled garden" market, where visitors to 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 spending habits of millions of individuals in several different categories. Their datasets can include data in the following categories: online shopping, video streaming, electricity consumption, car usage, internet usage, clothing purchases, mobile app purchases, club memberships, and online subscription services. Company A may wish to make these datasets (or subsets or derivatives of these datasets) available to other entities. For example, a new clothing brand might want to access datasets related to consumers' clothing purchases and online shopping habits. Company A may support a page on its website that is or functions essentially like a private data exchange, where data consumers (e.g., a new clothing brand) can browse, explore, discover, visit, and potentially purchase directly from Company A data set. In addition, Company A can control who can enter the private data exchange, who can view a particular list, what actions an entity can take with respect to the list (eg, view only), and any other suitable actions. Additionally, data providers can combine their own data with other datasets from, for example, public data exchanges, and use the combined data to create new lists.

A private data exchange can be a suitable place to discover, combine, cleanse, and enrich data to make it more profitable. A large company may aggregate data from its various branches and departments in a private data exchange, which may be of value to another company. Additionally, participants in private ecosystem data exchanges can work together to connect their datasets together to create useful data products 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 scalable 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. The example cloud-based storage resource provides 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 can be expensive to implement in private data storage systems. Exemplary cloud-based computing resources are available on demand and can be priced based on actual usage levels of the resources. Typically, cloud infrastructure is dynamically deployed, reconfigured, and decommissioned in a rapid manner.

In the described systems and methods, the 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 using any data storage architecture and using any language to store and retrieve data within a data storage and retrieval platform. The systems and methods described herein also provide a multi-tenant system that supports isolation of computing resources and computing resources between different customers/clients and between different users within the same customer/client. data.

1A is a block diagram of an example computing environment 100 in which the systems and methods disclosed herein may be implemented. Specifically, a cloud computing platform 110, such as AMAZON WEB SERVICE ^™ (AWS), MICROSOFT AZURE ^™ , GOOGLECLOUD ^™ , etc., may be implemented. As is known in the art, cloud computing platform 110 provides computing and storage resources that can be acquired (purchased) or leased and configured to execute applications and store data.

Cloud computing platform 110 may host cloud computing services 112 that facilitate data storage (eg, data management and access) and analytical functions (eg, SQL queries, analytics) and other computing capabilities (eg, SQL queries, analytics) on cloud computing platform 110 For example, secure data sharing among users of cloud computing platform 110). Cloud computing platform 110 may include a three-tier architecture: data storage 140 , query processing 130 and cloud service 120 .

Data storage 140 may facilitate storing data on 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 certain embodiments, to load data into cloud computing platform 110, data tables may be horizontally divided into large, immutable files, which may be similar to blocks or pages in traditional database systems. Within each file, the values for each property or column are grouped together and compressed using a scheme sometimes referred to as hybrid columnar. Each table has a header that contains, among other metadata, the offset of each column within the file.

In addition to storing table data, data store 140 also facilitates storing temporary data generated by query operations (eg, joins) and data contained in large query results. This can allow the system to compute large queries without out-of-memory or out-of-disk errors. Storing query results in this way simplifies query processing because it does not require server-side cursors as in traditional database systems.

Query processing 130 may handle query execution within an elastic cluster of virtual machines (referred to herein as a virtual warehouse or data warehouse). Accordingly, query processing 130 may include one or more virtual warehouses 131, which may also be referred to herein as data warehouses. Virtual repository 131 may be one or more virtual machines running on cloud computing platform 110 . Virtual repository 131 can be a computing resource that can be created, destroyed or resized at any time as needed. This feature enables the creation of "elastic" virtual warehouses that can expand, contract or close based on user demand. Extending a virtual repository involves generating one or more computing nodes 132 to a virtual repository 131 . Shrinking a virtual repository involves removing one or more compute nodes 132 from virtual repository 131 . More compute nodes 132 can result in faster computation times. For example, a data load that took 15 hours on a system with four nodes might take only 2 hours on a system with 32 nodes.

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

FIG. 1B is a block diagram illustrating an example virtual warehouse 131 . Exchange manager 124 may facilitate data sharing between data providers and data consumers using, for example, a private data exchange. 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 (eg, different businesses or individuals). User data may include a user database 152 of data stored and accessed by the user. The user database 152 may be subject to access control such that after authentication with the cloud computing service 112, only the owner of the data is allowed to change and access the database 112. For example, data can be encrypted so that it can only be decrypted using decryption information possessed by the owner of the data. Using the exchange manager 124, certain data from the user database 152 subject to these access controls can be shared with other users in a controlled manner in accordance with the methods disclosed herein. In particular, a user may designate a share 154, which may be shared in an uncontrolled manner in a public or private data exchange, as described above, or with a specific other user in a controlled manner. "Share" encapsulates all the information needed to share data in a database. Shares can include at least three pieces of information: (1) permissions that grant access to the database and schema containing the objects to be shared, (2) permissions that grant access to specific objects (eg, tables, security views, and security UDFs) permissions, and (3) consumer accounts shared with the database and its objects. When data is shared, it is not copied or transferred between users. Sharing is done through cloud service 120 of cloud computing service 110 .

Sharing data can 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 security user-defined functions (UDFs). A read-only database can then be created using the information provided in the share. Access to this database can be controlled by the data provider.

The shared data can then be used to process SQL queries, which may include joins, aggregations, or other analysis. In some cases, a data provider may define a share such that a "secure connection" is allowed to be performed with respect to the shared data. A secure connection can be performed so that analysis can be performed on the shared data, but the actual shared data cannot be accessed by data consumers (eg, recipients of the share). The secure connection can be performed as described in US Application Serial No. 16/368,339, filed March 18, 2019.

User devices 101-104, such as laptop computers, desktop computers, mobile phones, tablet computers, cloud-hosted computers, cloud-hosted serverless processes, or other computing processes or devices, are available for access through a network 105, such as the Internet or a private network Virtual warehouse 131 or cloud service 120.

In the description below, actions are attributed to users, in particular consumers and providers. It should be understood that such actions are performed with respect to devices 101-104 operated by such users. For example, a notification to a user may be understood as a notification sent to devices 101-104, input or instructions from a user may be understood as received through a user's device 101-104, and user interaction with the interface should be understood as is the interaction with the interface on the user devices 101-104. Additionally, database operations (connection, aggregation, analysis, etc.) attributable to a user (consumer or provider) should be understood to include cloud computing service 110 performing such actions in response to instructions from the user.

Figure 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. Exchange manager 124 may operate with respect to some or all of the illustrated exchange data 200, which may be stored on the platform (eg, cloud computing platform 110) on which exchange manager 124 is executed, or at some other location. Exchange data 200 may include a plurality of lists 202 describing data shared by a first user ("provider"). List 202 may be a list in a private data exchange or a public data exchange. Access control, management, and governance 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: the identifier of the sharer who shared the data, the URL associated with the sharer, the name of the share, the name of the table, the category to which the shared data belongs, how often the shared data is updated, the Table of Contents, the number of columns and rows in each table, and the names and descriptions of the columns. Metadata 204 may also include examples that help users use the data. Such examples may include a sample table or view (which includes a sample of the rows and columns of a sample table), a sample query that can be run against the table or its possible results, a sample view of a sample table, a sample visualization based on table data ( e.g. charts, dashboards). Other information included in metadata 204 may be metadata for use by business intelligence tools, textual descriptions of the data contained in the table, keywords associated with the table to facilitate searching, bloom filters for data in certain columns, or Other full-text indexes, links (eg, URLs) to documents related to the shared data, and a refresh interval indicating how often the shared data is updated (or an indication that the shared data is continuously updated) and the date the data was last updated.

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

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

It should also be noted that the default function of list 202 is to share that the referenced data cannot be exported or copied by consumers. Optionally, 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, discussed below) may be performed with respect to the shared data such that viewing and exporting of the shared data is not permitted.

In some embodiments, once a user is authenticated with respect to list 202, a reference to the user (eg, the user identifier of the user's account in virtual repository 131) is added to access control 206 so that the user will subsequently not need to Further authentication provides access to the data referenced by list 202 .

List 202 may define one or more filters 208 . For example, filter 208 may define specific user identifiers 214 of users who may view references to listing 202 when browsing directory 220 . Filter 208 may define the categories of users (users in a particular industry, users associated with a particular company or organization, users within a particular geographic region or country) that may view references to listing 202 when browsing catalog 220 . In this manner, the same components may be used by the exchange manager 124 to implement private exchanges. In some embodiments, excluded users in the excluded access list 202 (ie, adding the list 202 to the excluded user's consumption share 156) may still be allowed to view a representation of the list while browsing the catalog 220, and may be further Access to list 202 is permitted to request, as described below. Requests by such excluded users and other users to access the list may be listed in an interface presented to the provider of list 202 . The provider of the list 202 can then review the requirements for access to the list and select the extended filter 208 to grant access to the excluded user or category of excluded users (eg, users of excluded geographic regions or countries).

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

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

List 202 may further include usage data 210 . For example, cloud computing service 112 may implement a points system, where points are purchased by users and consumed each time a user runs a query, stores data, or uses other services implemented by cloud computing service 112 . Thus, usage data 210 may record points consumed by accessing shared data. Usage data 210 may include other data, such as the number of queries, the number of aggregations performed for each of the types of shared data, or other usage statistics. In some embodiments, usage data for the user's list 202 or lists 202 is provided in the form of a shared database (ie, the exchange manager 124 adds a reference to the database that includes the usage data to the user's consumption share) to users.

The list 202 may also include a heat map 211, which may represent the geographic locations where the user clicked on that particular list. The cloud computing service 110 may use the heatmap to make replication decisions or other decisions about listings. For example, a private data exchange can display a list containing weather data for the US state of Georgia. Heatmap 211 may indicate that many users in California are selecting the list for Georgia weather. Given this information, the cloud computing service 110 can replicate the listing and make the listing available in a database whose servers are physically located in the western United States so that consumers in California can access the data. In some embodiments, entities may store their data on servers located in the western United States. Certain listings may be popular with consumers. The cloud computing service 110 can replicate this data and store it on servers located in the eastern United States so that consumers in the Midwest and East Coast can also access the data.

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 human resources (HR) list containing HR data for internal employees on a private data exchange. HR data can contain ten types of HR data (eg, employee number, health insurance selected, current retirement plan, job title, etc.). 100 people in the company (e.g. everyone in the HR department) have access to the HR list. The management of the HR department may want to add an eleventh type of HR data (for example, employee stock option plans). Instead of manually adding it to the HR list and granting access to that new data to each of the 100 people, management could simply apply the HR label to the new dataset, and that HR label could be used to categorize the data For HR data, list it with the HR list and give 100 people access to view the new dataset.

List 202 may also include version metadata 215 . Version metadata 215 may provide a way to track how a dataset has changed. This can help ensure that the data an entity is viewing does not change prematurely. For example, if a company owns the original dataset and then publishes an updated version of that dataset, the update may interfere with another user's processing of the dataset because the update may have a different format, new columns, and possibly a different Other changes that are not compatible with the user's current processing mechanism. To remedy this, cloud computing service 112 may use version metadata 215 to track version updates. The cloud computing service 112 can ensure that each data consumer has access to the same version of the data until they accept an updated version that does not interfere with the current processing of the data set.

Exchange data 200 may further include user records 212 . User record 212 may include data identifying the user associated with user record 212 , eg, an identifier (eg, repository identifier) of the user who has user data 150 in service database 128 and is managed by virtual repository 131 .

User record 212 may list shares associated with the user, eg, reference list 202 created by the user. User record 212 may list shares consumed by the user, such as reference list 202 created by another user and 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 refer to the user record 212 in its sharing or consumption sharing.

Exchange data 200 may further include directory 220 . Catalog 220 may include a listing of all available listings 202, and may include an index of data from metadata 204 to facilitate browsing and searching in accordance with the methods described herein. In some embodiments, the list 202 is stored in a directory as a JavaScript Object Notation (JSON) object.

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

In some embodiments, the directory 220 is available on the Internet such that it is searchable by a search engine such as BING or GOOGLE. The directory may be subject to search engine optimization (SEO) algorithms to increase its visibility. Potential consumers can thus browse the catalog 220 from any web browser. Exchange manager 124 may expose a Uniform Resource Locator (URL) linked to each listing 202 . The web page below each URL can be searchable and can be shared outside of any interface implemented by exchange manager 124 . For example, a provider of a listing 202 may publish the URL of its listing 202 in order to facilitate use of its listing 202 and its brand.

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

Validation module 302 may validate the information provided by the provider when attempting to create listing 202 . Note that, in some embodiments, the actions attributed to the validation module 302 may be performed by a human reviewing the information provided by the provider. In other embodiments, these actions are performed automatically. Validation module 302 may perform or facilitate a human operator to perform various functions. These functions may include: verifying that the metadata 204 is consistent with the shared data it references; verifying that the shared data referenced by the metadata 204 is not pirated data, personally identifiable information (PII), personal health information (PHI), or other undesired or illegal sharing data. Confirmation module 302 may also facilitate verifying whether data has been updated within a threshold period of time (eg, within the last twenty-four hours). Validation module 302 may also facilitate verifying that the data is not static or available from other static public sources. Validation module 302 may also facilitate validating that the data is not just a sample (eg, the data is complete enough to be useful). For example, geographically restricted data may be undesirable, while aggregation of otherwise unrestricted data may still be useful.

Exchange manager 124 may include search module 304 . Search module 304 may implement a web interface accessible by a user on one or more user devices 101-104 to invoke searches for search strings with respect to metadata in catalog 220, receive responses to searches, and select searches for A reference to the list 202 in the results to add it to the consumption share 156 of the user record 212 of the user who performed the search. In some embodiments, the search may be performed by a user through SQL commands in a SQL interpreter executed on cloud computing platform 102 and accessed through a web interface on user devices 101-104. For example, a search share may be performed by a SQL query against the catalog 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 listings 202 for the user based on other listings 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 leads to recommendations for a second source of weather data. Recommendations can be made based on different points: one list is used for data in one domain (geographical region, technical field, etc.), resulting in listings in different domains (different geographical region, related technical field, etc.) for complete coverage of user analytics .

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

Switch manager 124 may include connection module 308 . The connection module 308 manages the integration of shared data referenced by the user's consumption shares 156 (ie, shared data from different providers) with each other and with the user database 152 of user-owned data. In particular, the connection module 308 can manage the execution of queries and other computing functions with respect to these various data sources so that their access is transparent to the user. The connection module 308 can further manage access to the data to enforce restrictions on the shared data, for example, so that analysis can be performed and the results of the analysis displayed without exposing the underlying data to the data consumer (where the restrictions are indicated by the access control 206 of the list 202) .

The exchange manager 124 may further include a standard query language (SQL) engine 310 programmed to receive queries from users and execute them on data referenced by the queries, which may include the user's consumption shares 156 and the user's owned User data 112 . 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.

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

The method 400 can include the provider entering 406 metadata. This may include a user on the provider's device 101 - 104 entering metadata into fields of a form in a web page provided by the exchange manager 124 . In some embodiments, the metadata may be entered 406 through 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 list 202 , such as access control 206 and parameters defining filter 208 .

The provider 402 may then invoke the submission of the form and input data on the devices 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 validation 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 means of a notification through a web interface, through which the metadata is submitted at step 406.

If the metadata and shared data have not been successfully verified 408 and confirmed 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.

Exchange manager 124 may further create 412 list 202 including the data submitted at step 406 and may further create entries in directory 220 . For example, keywords, descriptive text, and other information items in the metadata can be indexed to facilitate searching.

Note that steps 406-412 may be performed by means of an interface provided to provider 402. Such interfaces may include any suitable features, including elements for entering data (eg, elements 204-210), and elements for generating lists of data. Additionally, the interface may include elements for publishing the data listing, or unpublishing the data listing so that the listing is not viewable by at least some other users. The interface may also include elements for updating the 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 pending requests to add data or add members to the data exchange. The interface may also include an indication of the number and other non-identifying information related to the data consumers accessing a given list, as well as an indication of usage patterns of the data referenced by the list by the data consumers of the list.

Another user acting as consumer 404 can then browse 414 the catalog. This may include accessing web pages that provide a directory search interface. This web page may be outside of the virtual repository 131 , ie accessible by users who are not logged into the virtual repository 131 . In other embodiments, only users logged into virtual repository 131 can access the search interface. As described above, browsing of catalog 220 may be performed using a query to SQL engine 310 referencing catalog 220 . For example, user devices 101-104 may have a web-based interface to SQL engine 310 through which queries for catalog 220 are entered by consumers 404 and sent to SQL engine 310.

In response to the consumer's browsing activity, the exchange manager 124 may display the catalog and perform 416 a search on the catalog to identify the listing 202 with metadata corresponding to the query or search string submitted by the consumer 404 . The manner in which this search is performed can be according to any search algorithm known in the art. In the case of SQL queries, 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 devices 101-104 of the consumer 404, 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 the consumer 404 may select to invoke the metadata display. In particular, any item of the metadata 204 of 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 Figure 4A may be private exchanges or public exchanges. In particular, those listings 202 that are displayed and searched 416 during browsing 414 and that can be viewed by consumers 404 may be limited to those listings having a filter 208 indicating that the listings 202 may be viewed by consumers 404, the consumer's organization, or Some other category to which the consumer 404 belongs is viewed. Where the exchange is public, then in some embodiments, the consumer 404 is not required to meet any filtering criteria.

The method 400 may include the consumer 404 requesting 418 to access data corresponding to the list 202 . For example, by selecting an entry in the list on consumer 404's device 101-104, this invokes the transmission of a request to exchange manager 124 to add list 202 corresponding to the entry to consumer 404's user record 212 consumption in 156 shares.

In the example shown, the list 202 of selected entries has access controls 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 one or both of the following: (a) authenticate (login) 424 consumer 404 with provider 402; Payment for referenced data. The interaction can 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, the data warehouse module may provide a discount to the provider 402 due to the credits consumed by the consumer 404 when accessing the provider's shared data. The credits may be units of use purchased by the user that are then consumed in response to the services of the virtual warehouse 131 used by the consumer 404 (eg, queries and other analysis performed on data hosted by the virtual warehouse 131 ). The interaction may take place directly between the devices 126 of the consumer 404 and the provider 402 , or may be performed through the exchange manager 124 . In some embodiments, exchange manager 124 uses access control information 206 to authenticate consumer 404 such that interaction with provider 402 is not 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 the provider 402 determines that the consumer 404 is authenticated and authorized to access the data referenced by the list 202 , the provider 402 may notify 426 the exchange manager 124 that the consumer 404 may access the data referenced by the list 202 . In response, the exchange manager 124 adds 428 a reference to the list 202 to the consumption share 156 in the user record 212 of the consumer 404 .

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

In some embodiments, this may be accomplished using a "single sign on" approach, wherein the consumer 404 authenticates (logs in) once with the cloud service 120 and then enables the consumer 404 to access the service database 158 Consumer 404 data in . For example, exchange manager 124 may present an interface to cloud service 120 on consumer 404's devices 101-104. The consumer 404 enters authentication information (username and password, certificates, tokens, etc.) into the interface, and this 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 can then identify the user data 150 for the user account and create a database referencing the data. A reference to this database will then be added to the consumer 404 consumption share 156 .

In some embodiments, user authentication with respect to the virtual warehouse 131 is sufficient to authenticate the user with respect to the cloud service 120, such that in view of the prior authentication of the consumer 404, steps 422, 424 are omitted. 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 interaction with provider 402 is not 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 exchange manager 124 and step 426 is omitted. Once the consumer 404 is authenticated and/or provided with the required payment, the exchange manager 124 executes step 428 .

In some embodiments, adding the list 202 to the consumer's 404 consumption share may further include receiving from the consumer 404 an approval of the terms presented to the consumer 404 . In some embodiments, where the terms of the agreement are changed by provider 402 after consumer 404 has added listing 202 according to method 400 or other methods described herein, exchange manager 124 may require consumer 404 to agree to the change terms before allowing it to continue accessing 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 this database can then be added to the consuming share 156, and the database can then be used to process queries referencing the data referenced by the shared record. Adding 428 data may include adding data filtered according to filter 208 . For example, data referenced by list 202 and associated with consumers 404, an organization of consumers 404, or some other classification of consumers 404 (eg, a filtered view of the data).

In some embodiments, adding the list 202 to the user record 212 may include changing the access control 206 of the list 202 to reference the identity data 214 of the consumer 404 such that attempts to access the data referenced by the list 202 will be permitted by the exchange manager 124 and implement.

The consumer 404 may then enter 432 the query into 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 . The SQL engine 310 then processes 430 the query using the database created at step 428 and returns the results to the consumer 404, or creates a view, materialized view or other data that the user can access or analyze. As described above, the data shared by the consumers of the query operation may have previously been filtered to include only data related to consumers 404 . Thus, different consumers 404 adding the same list 202 to their consumption share 156 will see different versions of the database referenced by the list 202.

Referring to Figure 4B, in some embodiments, the data structures shown may be used to implement private sharing of data and filtering of data based on the identity of the consumer 404. For example, the provider's 402 service database 158 may include a customer map 434 that includes entries for the customer identifiers 436 of users of services provided by the provider 402 (eg, services implemented by the server's cloud service 120), and an entry for the customer identifier 436 as an identifier for authentication using the authentication interface 120 . The customer mapping 434 may map each customer identifier 436 to a warehouse identifier 438 , the user identifier used by the user to authenticate to the virtual warehouse 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 (eg, the single sign-on method described above).

Customer mapping 434 may further include a reference 440 to entitlement table 442 , which 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 ID 436 mapped to it. The entitlement table 442 may further define the columns of the table 444 that can be accessed with the customer ID 436 . The entitlement table 442 may further define a row or type of row based on one or more filter criteria of the table 444 accessible using the customer ID 436 . The entitlement table 442 may further define the schema of the table 444 that can be accessed using the customer ID 436 .

Thus, list 202 of tables 444 may specify that access to data table 444 is performed as defined by customer mapping 434 . For example, referring to FIG. 4C, when a consumer 404 requests to add a list 202 to a database for which access is defined according to the customer mapping, the exchange manager 124 may map the customer 404's warehouse identifier 438 according to the customer identifier 436 and entitlement table 442 to create a secure view 446. A secure view may be generated by performing an inner join of the data table 444 (or part of a data table as specified in the entitlement table 442) of the database specified in the entitlement table 442, filtered according to the customer identifier 436, such that the join results only Data for specific customer identifiers 436 is included, and only those portions of the database specified in entitlement table 442 (table 444 and/or portions of table 444). A secure view can be generated in a manner as described in U.S. Application Serial No. 16/055,824, filed August 6, 2018 and entitled "SECURE DATA SHARING IN A MULTI-TENANT DATABASE" and filed on January 7, 2019 and entitled "SECURE DATA SHARING IN A MULTI-TENANTDATABASE" US Application Serial No. 16/241,463.

FIG. 5 illustrates an alternative method 500 for sharing data that 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 changes to access control 206 are 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 . Figure 5 shows that if the list 202 is viewable (ie, as described above, the filter criteria allow the consumer 404 to view), the consumer 404 can 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.

6, in some embodiments, the method 600 may include the consumer 404 browsing the catalog from the exchange manager 124 and selecting the list 202 as described for other methods described herein (eg, see FIGS. 4A and 5), Bidirectional sharing of data referenced by the list ("shared data") and additional data in the user database 112 ("user data"). Note that in some embodiments, the list 202 of providers 402 does not reference any specific data (eg, specific tables or databases), but rather provides execution services with respect to the data provided by consumers 404 . Therefore, in such cases, as described below, "shared data" can be understood to be replaced by "provided services".

In response to the request, exchange manager 124 implements 604 peer-to-peer sharing of shared data with respect to consumer 404 and provider 402. This may be performed as described above with respect to Figure 4A, eg, including authentication of the consumer 404, and possibly filtering the shared data to include only data associated with the consumer 404, as described above. Exchange manager 124 may further implement peer-to-peer sharing of user data with respect to 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 the consumer share 156 of the provider 402, and (b) the consumer 404 does not need to create a list 202 for user data, and the user data does not need to be listed in the catalog 220.

After step 606, either the consumer 404 or the provider 402 can access the shared data and user data. Queries can then be run against both, join them, perform aggregations on the joined data, or perform any other action or enrichment known in the art with respect to multiple databases.

In some embodiments, the two-way sharing may include or be requested to include by the consumer 404, the provider 402 also connects 608 the shared data and the user data to obtain the connection data, and employs adding 612 a reference to the connection data to the consumer 404's consumption share 156 (made by the exchange manager 124 ), returns 610 a reference to the connection data to the exchange manager 124 .

Therefore, the 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 shared data before or after the connection. Virtual repository 131 may perform step 608 in response to a request from consumer 404 to do so.

Note that the join result can be either (a) a new database as the join result, or (b) a join database view that defines a join that shares data and user data.

The results from step 608 (join, aggregate, analyze, etc.) may alternatively be added to the original share performed at steps 606, 608, e.g., define the view (materialized or unmaterialized) of the operation performed at step 608 ).

Virtual repository 131 may also perform steps 608-612 independently of the request made at step 602 in response to a request from consumer 404 or provider 402 to do so.

Note that in many cases there are many consumers 404 attempting to perform two-way sharing with the provider 402, and these consumers 404 may seek two-way sharing with respect to their user data, which may be in many different formats (schemas), which format (schema) may differ from the schema used by provider 402 for the shared data. Thus, step 608 may include a transformation step. The transformation step maps the source schema of the user data to the target schema of the shared data. The transformation may be a static transformation provided by a human operator. The transformation may be based on an algorithm that maps the column labels of the source schema to the 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, multiple training data entries can be specified by a human annotator, each entry including as input the source schema, and as output the mapping between the source schema and the target schema. These entries can then be used to train a machine learning or artificial intelligence algorithm to output a mapping to a target pattern given an input source pattern.

The data added to the share consumed by consumers 404 and providers 402 may then be manipulated by consumers 404 and providers 402, respectively, such as by performing queries against the data, aggregating the data, analyzing the data, or performing the operations described herein with respect to adding to users. Any other actions performed by the share of the consumption share 156 .

In certain embodiments, as described above, data providers can improve their relationships with business partners by enabling secure exchange of data in a two-way manner. Traditional two-way data sharing methods are difficult to achieve, and only very limited data sets can be shared via API, FTP, or file transfers between companies. This often brings huge costs, expenses, data latency, and even some security risks.

Data providers can instead host a private data exchange and invite their customers and partners to participate in the exchange. Customers and partners can access the data, eg in a secure view, and they can also push the data in the other direction. This could be sharing the data back to the host, or it could be listing the data so that other participants in the ecosystem can also safely share the data. Data from public data exchanges, other private exchanges, or other external sources may also be included.

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

Referring to Figure 7, the methods of sharing and consuming data as described herein enable enrichment of data and return the enriched data to an exchange. For example, Provider A may request 702 and exchange shared data (Share 1) in the same manner as the other methods described herein. Exchange manager 124 verifies, validates and adds 704 share 1 to directory 220.

The second provider B can then browse the catalog 220 and add 706 share 1 to its consumption share 156. Provider B may perform 708 operations on the shared data, such as joining it with other data, performing aggregations, and/or performing other analysis on Share 1, resulting in modified data (Share 2). Provider B may then request 710 to share Share 2 with the exchange described herein. Note that the connection of step 708 may include connecting to 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 hierarchy in which a larger list 202 of multiple users is reduced to a smaller number based on data from the larger number of lists 202 in number List 202.

Exchange manager 124 verifies, validates and adds 712 share 2 to directory 220. The process can be repeated 714 for Share 2 as Provider A, Provider B, or a different provider adds Share 2, generates modified data based on it, and adds the results back to the catalog in the same manner. In this way, users can gain access to a rich ecosystem of data and analytics. The sharing according to method 700 may be any sharing according to the methods disclosed herein, peer-to-peer sharing, private exchange sharing, or two-way exchange sharing.

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 provider A's list L1 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 process can include any number of steps. This may not be desirable in some cases (such that modification of list L1 to reference L3 is not allowed given that L3 is derived from L1). In other cases, such loops are allowed if there is a time delay in flushing the data referenced by each list. For example, L1 can reference L3, provided that L3 is not flushed until some time after L1 is flushed, and so a circular reference does not cause continuous updates of L1 and L3 indefinitely. The present disclosure also contemplates acyclic flow, so that list L1 is not affected by the use of list L1 by other providers.

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

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

Example

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

In a second use case, provider 402 creates reader accounts or reader/writer accounts for consumers 404 who are not yet users of virtual warehouse 131 . The account may be associated with the consumer's account data (see consumer mapping of Figure 4B discussed above). Consumer 404 can then log into the account and then access the provider's list to access consumer data 404 managed by provider 402 (see, eg, the discussion of FIG. 4A).

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

In a sixth use case, the list 202 may be shared on a subscription (eg, monthly) basis, or the list 202 may be accessed based on a price per query or credit boost multiplier. Accordingly, the exchange manager 124 can manage the processing of payments and access such that the consumers 404 are allowed access to data (subscriptions, per query, etc.) governed by the pricing model.

In a seventh use case, the exchange manager 124 implements a security function and a secure machine learning model (both training and scoring) that can be used to process private data, such that the consumer 404 is allowed to use the function or the results of the machine learning model, but not authorized to Access raw data processed by the function or by the machine learning model itself. Likewise, consumers of shared data are not allowed to export shared data. Nonetheless, consumers are allowed to perform analytical functions on the shared data. For example, the following security features can be implemented to enable viewing of customer shopping data 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 exchange manager 124 may provide usage statistics (eg, queries, credits used, tables scanned, tables hit, etc.) of the list 202 by one or more consumers 404 to the provider of the list 402.

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

a. Allow sharing of risk vectors, bad actors, IP whitelists/blacklists, live attacks in progress, known good/bad email programs, etc.

2. Healthcare

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

b. Secure the multi-hospital database so that patients can share their information with multiple providers. (For example, if Patient A lives in California and goes on vacation to Florida, gets injured, and is treated in an emergency room, a Florida hospital might be able to access Patient A's records from a different hospital and provider).

Other industries may also benefit from private or public sharing of data in accordance with 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 for 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 with the second user, such as campaign metadata, current user events (session start/end for a particular user, purchases for a particular user, etc.). This can be achieved using the bidirectional sharing of Figure 6. This data (customer list + customer events from the first user) can be concatenated to better understand events for a particular user or group of users. As mentioned above, this data exchange can be performed without creating a copy or transferring the data - each user accesses the same copy of the shared data. Since there is no data transfer, data can be accessed in near real-time as customer events occur.

8 is a block diagram illustrating a network environment in which data providers can share data via cloud computing services. The data provider 810 may use the cloud computing service 112 to upload one or more datasets 820 into a cloud storage device. These datasets can then be viewed by one or more data consumers 101-104. Data providers 810 can use cloud computing services 112 to control, monitor, and increase the security of their data using the methods and systems discussed herein. In certain embodiments, the data provider 810 may implement a private data exchange on its own online domain using the functions, methods, and systems provided by the cloud computing service 112 . The data provider 810 may be any data provider such as, for example, a retail company, a government agency, a pollster, a non-profit organization, or the like. Data consumers 101 - 104 may be internal to data provider 810 or external to data provider 810 . Data consumers within the data provider may be employees of the data provider 810 . The data provider can be a bike-sharing company that provides bikes at a daily, monthly, annual, or trip-based fee. Bike-sharing companies may collect data about their users, such as basic demographic information and ride information, including ride date, ride time, and ride duration. This information may be made available to employees of the bike share company via cloud computing services 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. A data provider may create one or more lists 811 using the dataset 820 . Lists can be used for any suitable data. For example, consumer data companies may create lists called "video streams" that contain data related to the video streaming habits of a large number of users. The data provider may set a listing policy 821 regarding who can view the listing 811, who can access the data in the listing 811, or any other suitable policy. Such listing strategies 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 data provider's 810 network domain. For example, if the consumer data company's web domain is www.entityA.com, the private data exchange can be found at www.entityA.com/privatedataexchange. If the listing complies with one or more rules determined by cloud computing service 112 , private data exchange 812 may receive the listing 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 members at step 816 . Members may be data consumers 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, data consumers can only read data or share data. As another example, a data consumer can perform any combination of the above read or share operations on the data according to access control. Typically, data sharing does not involve changing shared data.

In some embodiments, the data consumer 801 may independently access the private data by navigating directly to the private data exchange 812 in a browser, or by clicking on an advertisement for the private data exchange 812, or through any other suitable mechanism Exchange 812. Private data exchanges may also be presented via custom or other code by accessing lists and other information via APIs. Data consumer 801 may need to request access at step 820 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. 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 can then start consuming the data as described above.

In certain embodiments, one or more data exchange administrator accounts may be designated by cloud computing service 112 . A data exchange administrator can manage private data exchange members by designating members as data providers 810 or data consumers 801 . Data exchange administrators can control the visibility of lists by choosing which members can see a given list. The data exchange administrator may also have other functions, such as approving listings before publishing them on a private data exchange, tracking usage of each listing in the listing, or any other suitable management 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. Providers can create lists, can test sample queries on the data below the list, can set access rights to the list, grant access to list requests, and track the usage of each list in the list and the data below the list. Data consumers 801 can access the private data exchange and browse the visible list that can be displayed as tiles. In order to consume the data below the list, the consumer can access the data immediately, or can request access to the data.

FIG. 9 is an example private data exchange 900 according to an embodiment of the present invention. Private data exchange 900 may be what a data consumer sees when navigating to a private data exchange on the network. For example, a data consumer can enter www.entityA.com/privatedataexchange into their browser. As discussed herein, an "entity A data exchange" may be a private data exchange facilitated by cloud computing service 112 and embedded in entity A's own network domain or application, or may be accessed via an API. Private data exchange 900 may include several lists for different data sets, such as lists A-L. Lists A-L may also be referred to herein as data directories, which may allow a visitor of the private data exchange to view all available listings in the private data exchange. These lists can be placed by administrators inside entity A. Providing a data catalog in this way can be used to combine the advantages of crowdsourced content, data quality, and an appropriate level of centralized control and coordination, which can overcome other enterprise data classification methods such as indexing and crawling. ) system) the challenge of slowing adoption. It allows users across the enterprise to contribute data, consume data from other groups, and connect data together to create rich data products for internal use and potentially for external monetization.

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 number of different categories. Their datasets can include data in the following categories: online shopping, video streaming, electricity consumption, car usage, internet usage, clothing purchases, mobile app purchases, club memberships, and online subscription services. Each of these datasets can correspond to a different list. For example, list A can be used for online shopping data, list B can be used for video streaming data, list C can be used for power consumption data, and so on. Note that data may be anonymized so that personal identity is not revealed. The list located below row 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 Entity A's approval before being added to private data exchange 900. The data consumer can click and view any list subject to the various access controls and policies discussed above with reference to FIGS. 2 , 4 and 8 .

In certain embodiments, as discussed with reference to FIG. 8, a data provider may invite members to access its private data exchange. A class of members may be physical and digital supply chain suppliers of data providers. For example, data providers can share data with suppliers on their inventory levels or the consumption of items provided by suppliers, so they can better serve the needs of the data provider. In addition, digital data providers can provide data directly into their private data exchange to make it immediately available and connected to internal enterprise data, saving both parties the cost of transferring, storing, and loading the data.

Some companies, such as hedge funds and marketing agencies, bring in data from many external sources. Some hedge funds evaluate hundreds of potential datasets each year. Private data exchanges can be used not only to connect purchased data, but also to evaluate new data assets. For example, a hedge fund could have potential data vendors list their data on their private exchange, and the fund could explore and "buy" the data in a private data store where they are the only customers. As discussed with reference to Figure 11, such internal data storage may also "tunnel" data assets from a public data exchange (eg, the SNOWFLAKE public data exchange).

As another example, an existing provider of a company's marketing data may list additional data sets that its customers can use on a trial basis via their private exchange, and if the customer finds them useful, the provider Full access is immediately available through the same exchange. These arrangements can lead to greater data depth, bi-directional and fresher data, and greater trust and transparency in the relationship between suppliers of data and physical goods and their customers.

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

In a private data exchange, data can be shared within the same entity as well as between different entities. Additionally, data sharing can be unidirectional, bidirectional, or multidirectional. In one embodiment, this can lead to as many as five primary use cases for sharing data: two-way inter-entity, two-way intra-entity, one-way inter-entity, one-way intra-entity, and multi-way multi-entity. An example of two-way inter-entity data sharing could be data sharing from a portfolio company to a parent company and between portfolio companies. An example of two-way intra-entity data sharing could be data sharing from a large company headquarters to different business units within that company, and also data sharing from business units to headquarters. An example of one-way inter-entity data sharing may be a large data provider (eg, the National Weather Service) that shares data with many different entities but does not receive data from those entities. An example within a one-way entity could be a large company that provides data to its corresponding business units, but does not receive data from those business units. In certain embodiments, data may be shared as a "peer-to-peer share" or "any share" of specific data. Peer-to-peer sharing of specific data may include private data exchange sharing between parent companies and specific portfolio companies. Any sharing may include private data exchange sharing from a parent company to numerous data consumers on a public exchange or within a private exchange.

In particular embodiments, the cloud computing service 112 may generate a private data exchange for an entity that is the owner of the data to be shared on the private data exchange. Cloud computing service 112 may designate one or more administrators of the private data exchange. These administrators can control access to private data exchanges relative 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, data consumer, exchange administrator, or a combination of these.

In certain embodiments, an exchange administrator can control viewing and access rights for private data exchanges. View permissions can include a list of entities that can view the list in the private data exchange. Access rights can include a list of entities that can access the data after a particular list is selected. 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 can include their own individual viewing and access rights. For example, List A may include a first list of entities that have access to the list on private data exchange 900 and a second list of entities that have access to the list. Looking at the list might just see that the list exists on a private data exchange. An access list allows you to select a list and access the underlying data for that list. Access can include viewing the underlying data, manipulating that data, or both. Controlling viewing permissions can be useful for data providers who do not want some users to even know that a list exists in a private data exchange. So when a user who doesn't have permission to view a particular list accesses a private data exchange, that user won't even see that list on the exchange. In certain embodiments, the viewing and access rights discussed above may be provided through an application programming interface (API). The exchange catalog can be queried and updated via an API. This could allow the data provider to display the list on their own app or website to anyone who visits. When a user wants to access or requests access to the data, the user can then create an account with the cloud computing service 112 and gain access. In some embodiments, the URL may be invoked when a user requests access to data in the list. This can allow integration with external request approval workflows. For example, if a user makes an access request, the data provider's external request approval workflow can be accessed and activated. The external request approval workflow can then operate normally to perform the external request approval process. In some embodiments, the list may not be listed, which means that the list exists but is not visible on the data exchange. In order to access unlisted listings, consumers can enter the global URL in their browser. This may require a unique URL for each list.

In certain embodiments, when creating a new private data exchange for a data provider, cloud computing service 112 may designate an exchange administrator (eg, a data transaction administrator as discussed above), and may also generate the following information about the private data exchange Metadata: The private data exchange's name (must be unique), display name, logo, a short description of the private data exchange, and an indication of whether the exchange administrator's approval is required to publish (eg Admin_Approval_for_Publishing). This could be a true/false statement. This can be set to true if the exchange administrator needs to approve lists submitted to private data exchanges before they are published. This can be set to false if the exchange administrator is not required to provide such approval. In this case, the provider can publish the data directly. If the exchange administrator has set Admin_Approval_for_Publishing to true, the exchange administrator can see the list of listings and choose which ones to preview and approve/reject. The owner of the private data exchange can be an account that pays for the private data exchange. This metadata information can 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 certain embodiments, an exchange administrator may add members to a private data exchange by inviting members (eg, 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 an exchange administrator adds members to a private data exchange, the exchange administrator can also specify one or more member types: exchange administrator, provider, or consumer. Exchange administrators can add and remove members from the private data exchange, as well as edit the metadata associated with the private data exchange. For each user, the exchange administrator can specify whether the user is an exchange administrator, a data provider, and a data consumer, or more 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 an exchange administrator deletes a member or simply changes a member's type from provider to consumer, existing listings published by that member may become unpublished from exchange. Additionally, existing shares that the member adds to the exchange are no longer considered part of the private data exchange. Lists posted by the member can be archived and are no longer visible to anyone (including the member) in the UI. If the same member (same account on cloud computing service 112) that has been deleted becomes a provider again, cloud computing service 112 may unarchive.

In some embodiments, the exchange administrator can specify category lists as well as edit existing lists. A category can 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, which includes a logo, a description of the provider, and the URL of the provider's website. When submitting a list, the provider may do the following: select which private data exchange to publish the data (eg, 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. Metadata can include the listing title, listing type (eg, standard or personalized), listing description, one or more usage examples (eg, title and sample query), listing category (which can be entered as free-form text), How often the list is updated, support emails/URLs, and documentation links. Providers can also set access rights to the list. The provider can allow the exchange administrator to control the visibility of the list, or the provider can retain that control itself. Providers can also associate shares with lists. For standard shares, the list can be associated with zero or more shares. Providers can associate shares with lists via UI or SQL. For personalized shares, when a provider provides a share in response to a request, the provider can associate the share with a list. When a provider wishes to publish a listing, depending on the private data exchange's publishing rules, the listing may first require the approval of the exchange administrator.

11 is a diagram illustrating an example tunneling of data lists between public data exchanges and private data exchanges. 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 listing on its private data exchange. For example, entity B may wish to include list F of public data exchange 1100 on its own private data exchange 1000. The data below list F can be tunneled from public data exchange 1100 to private data exchange 1000. In certain embodiments, data may be tunneled between the two private data exchanges. At times, a first data provider may wish to allow a 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 might have a business agreement to share list F on each of their private data exchanges. 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 titled "List F" would point to the same dataset stored in the cloud computing platform 110 . Tunnel 1015 is a representation showing that list F can be securely and easily shared between two or more data exchanges 1100 and 1000 . No data is copied or transferred during tunneling. Instead, each list contains pointers to the data referenced by list F discussed in this article.

In certain embodiments, a tunnel link may be done between the private data exchange and the public data exchange, and vice versa. For example, data exchange 1100 may be a public data exchange. Entity B can use the list listed on public data exchange 1100 on its own private data exchange 1000 via tunnel 1015 . In some embodiments, lists of data can be tunneled from one data exchange to another, and the underlying data can then be concatenated with another set of data, and a new list can then be generated from the combined set of data. By way of example and not limitation, the first data set may be listed on a private data exchange that includes NBA player shooting statistics for the last five years. The second dataset may be listed on a different data exchange that includes weather data over the same time span. The two datasets can be concatenated and listed as a new list in a private or public data exchange. Data consumers can then access this dataset to understand how the weather might affect a player's field goal percentage, subject to the viewing and access controls discussed in this article. Additionally, if the data is listed on a public data exchange (eg, a data exchange hosted by cloud computing service 112), the data may be tunneled to a private data exchange.

In some embodiments, tunneling of datasets can be used to create public or private "industry-wide" data exchanges. Many different entities may tunnel datasets to a "large ecosystem data exchange". If data exchange for private ecosystems really takes off, it could become so large and influential that it could become the standard place for data exchange, collaboration, and monetization across the industry. Each industry may have room for one or two "large ecosystem data exchanges." Once any one exchange gains significant traction, it has the potential to be the "go-to" for the industry. If more than one viable exchange emerges in an industry, their respective owners may decide to cooperate between their exchanges and trade some (but possibly not all) assets "across the tunnel" to reach a critical mass.

While industry consortia could host such exchanges through tunneling, it is very likely that one or two large players in each industry will quickly and broadly lead the ecosystem-private data exchange to become the de facto data exchange for their industry. This provides a huge incentive for companies wishing to become major players in their industry data to establish an internal data exchange as quickly as possible, and then quickly open it up to their suppliers, customers and partners.

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

global data sharing

As mentioned above, private data exchanges are 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 listings across multiple regions of a cloud computing platform and/or across multiple cloud computing platforms. In order for data providers to share datasets across multiple cloud computing platform regions and/or multiple cloud computing platforms, data providers need to set up accounts in different regions, log into each account to set up replication, and use tasks to refresh. The data provider needs to be shared with consumers in the target region, and the entire database needs to be replicated. The whole process adds a lot of overhead to the data provider. Additionally, 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 their VPC account. Alternative methods such as requiring customers to open multi-tenant accounts and keep shared data there place a burden on consumers. In one embodiment, a 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 for customers consuming this data) to enable cross-regional and cross-cloud data sharing.

In one embodiment, for global data sharing, there are two types of data: standard and personalized. Standard data represents the same data for every consumer. For example, there is no dynamic filtering of rows based on consumer accounts. In contrast, personalization data represents data that is unique to each consumer (or group of consumers). In one embodiment, the personalized 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 the data. In yet another embodiment, for data providers, this means that they can create views for some or all of their consumers, rather than for each consumer.

In one embodiment, the list of shared data may include metadata associated with zero or more shares, or a collection of database (DB) objects. Also, listings can be free data or paid data. In addition, data providers can determine whether the shared data is standard (in which every customer has access to the same shared data), or whether the shared data is personalized (in which data is shared on an individual or group basis), Grant consumers access to shared data. For personalization 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 customers to access the data. For example, in one embodiment, in a private exchange, gaining access to a share may require approval workflows even though the data itself is not personalized. Thus, in one embodiment, for standard data sharing, the data provider need not be in the request fulfillment loop. Any consumer account that discovers the list can access the data and use that data to create a database from it. Alternatively, for data shared by request, the data provider will need to explicitly add the consumer to the share.

In another embodiment, a standard share may exist in the context of a data exchange (whether public or private) because the data exchange represents its available membership base and how the list is discovered. In one embodiment, data shared by data providers is also referred to as data sharing. In one embodiment, the consumer should not really care about the underlying share type (eg, Standard or By Request). Also, consumers can always interact with standard lists. In this embodiment, the data provider must know the shares in order to create them. However, the data exchange will handle the creation of these shares.

In one embodiment, data sharing outside of exchanges is by definition sharing on request. Additionally, the data exchange may include unlisted or undiscoverable standard lists that have no entries in the data exchange. The active membership base for this is any Snowflake customer. However, the consumer cannot discover the listing because the data provider sends the listing URL. In this embodiment, anyone viewing the URL and logging into the data exchange can view the data and, for example, create a DB from a share.

In one embodiment, both standard listings and on-demand listings can be free or paid. If the data sharing is free, once the consumer accepts the provider terms, the consumer can create DBs from the shared data. If the data sharing is paid, the consumer can accept the terms and arrange to pay. Consumers can then create DBs from the share. In one embodiment, for standard listings, the data may or may not be available in the area: if the data in the area is not yet available, the consumer still hits fetch and can create a database from the share. At this point, the data exchange can let them know that the data will be available within a certain amount of time (for example, if it is in seconds, there can be a visual countdown, or a progress bar indication in the UI). In one embodiment, personalized data sharing may be of the type of share on request or list.

13A is a block diagram of an example system 1300 of multiple cloud computing platforms sharing data with data exchanges. In FIG. 13A, the system 1300 includes two distinct 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, data exchange 1306 is similar to the data exchange described above, except that 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, data providers share some or all of their data 1304 via a data exchange 1306, which is visible to data consumers in both cloud computing platforms 1302A-B. For example, in one embodiment, data consumers 1308 in different cloud computing platforms (eg, cloud computing platform 1302B) can view the list of data provider shares 1304 via data exchanges. If data consumer 1308 requests a list, in response, data exchange 1306 may create a provider account for data provider share 1304 in cloud computing platform 1302B and copy the data share to cloud computing platform 1302B. Using the data share 1310 replicated in the cloud computing platform 1302B, the data consumers 1308 can access the data. In one embodiment, 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 replicate. In another embodiment, the data exchange 1304 infers which parts the data provider shares 1304 to copy. In this embodiment, the data exchange may infer the objects shared by the data provider that need to be replicated, the frequency with which those objects need to be replicated, and/or the area of the consumer account and corresponding provider secondary account.

13B is a block diagram of an example system 1320 of a cloud computing platform that shares data with data exchange across multiple regions of the cloud computing platform. In Figure 13B, system 1320 includes a cloud computing platform with two distinct regions 1322A-B, where each cloud computing platform region 1322A-B may be a different geographic region of the cloud computing platform (eg, US West, US East, Europe, Asia and/or another type of geographic region). In one embodiment, each cloud computing platform area 1322A-B is coupled to a data exchange 1306. In one embodiment, data exchange 1306 is similar to that 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 area 1322A includes data provider shares 1304 . In this embodiment, data providers share some or all of their data 1304 via a data exchange 1306, which is visible to data consumers in both cloud computing platforms 1302A-B. For example, in one embodiment, data consumers 1308 in different cloud computing platform regions (eg, cloud computing platform region 1302B) may view a list of data provider shares 1304 via a data exchange. If data consumer 1308 requests a list, in response, data exchange 1306 may create a provider account for data provider share 1304 in cloud computing platform 1322B and copy the data share to cloud computing platform area 1322B. Using the data share 1310 replicated in the cloud computing platform area 1322B, the data consumers 1308 can access the data. In one embodiment, 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 are to be copied. In another embodiment, the data exchange 1304 infers which parts the data provider shares 1304 to copy. In this embodiment, the data exchange may infer the objects shared by the data provider that need to be replicated, the frequency with which those objects need to be replicated, and/or the area of the consumer account and 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 as well as entering/leaving a VPC. For example, in one embodiment, a data provider may provide non-personalized, on-demand data sharing within or outside of a data exchange, where consumers may be in different deployments. In one embodiment, this is a basic building block upon which some other type can be built. Another type of use case is a data provider for a standard list of many different consumers (eg weather data on a public or private exchange). A third use case type can be a data provider for personalized shares/lists. This use case type can be on a public data exchange, in a private data exchange, or outside the exchange (just data sharing). Finally, a use case type could be a consumer on a VPC wanting to access data sharing in a cloud computing platform. In one embodiment, an additional nuance is that the private data exchange adds providers by the data exchange administrator. Ideally, a data exchange administrator would like to not have to train a provider to manage the complexities of setting up replication to share data from that provider to other private exchange members that may be on different regions/clouds.

In one embodiment, a subscription data provider wants to share with a marketing data company whose primary account is on the same cloud computing platform, but in a different region, such as US-East, where its data is stored in the United States of America on the cloud computing platform - Selected tables and/or views on the western region. In this embodiment, the subscription data provider is a customer of the marketing data provider. The main objective of the Marketing Data Provider is to process and incorporate this information into the Marketing Data Provider's product. In one embodiment, the cost should affect the marketing data provider's data exchange account, but not the subscription data provider's account. 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 booking data provider is a customer of the marketing data provider, so the marketing data provider does not want the booking data provider to do the work. Additionally, the marketing data provider has views that reference 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 a marketing data provider requesting a data share via the data exchange, the data exchange creates an account in the cloud computing provider's US-East region and replicates the subscription data provider's relevant data share (e.g., the master indicated by the subscription data provider). data sharing and subordinate data). Figure 14 below further describes the sharing of data across cloud computing platforms and/or regions.

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

In another embodiment, a data provider wishes to replicate a customized set of data shares for consumers across different cloud computing platforms and/or regions. In this embodiment, the data provider only wishes to replicate certain tables of its database. The transportation analytics company's data is in a cloud computing service, where each table contains data for a specific dataset. The company shares specific datasets with customers based on the datasets they subscribe to. Transportation analytics companies want to model their data in cloud computing services independently of how the shares are created. Then, when a shipping analytics company creates a share for a specific customer, they only want to replicate those tables. Figure 14 below further describes the use of an approval workflow to share data across cloud computing platforms and/or regions.

In one embodiment, a standard listing on a public exchange may represent an increased opportunity for data exchange and/or cloud computing services. Paid standard sharing presents new revenue streams through monetization. In one embodiment, the consumer can experience the free or paid listing as immediately as possible. Since the provider does not explicitly add the consumer to the share, they are not in the user flow. In addition, data providers have also stated that it would be ideal to incur replication costs based on demand. For example, in one embodiment, a weather data provider has made a free subset of its data available as a free standard listing, and would like to have a paid standard listing where customers can pay for and get a predefined package right away. Third, for more customized packages, they want consumers to connect with them, and they will establish direct sharing with consumers. In this case, the most likely scenario is that the free listing is available in (almost) all regions. For a paid list, the data provider will want it to be available on any deployment as long as there is at least one paying user in that deployment, or if the cloud computing service covers the cost of replication. Note that while free shares and paid shares can be set as filters on the row (safe view within a share) or as completely separate shares, one case is that these are two separate shares. For example, a retail analytics provider creates different shares for different sets of objects for free and paid. In a paid share, this data provider would have the ability to let consumers choose which rows they want to create dynamically created packages. For example, consumers will select only the location data they want for "Type=McDonald's" and "State=CA" through the data exchange user interface, and thus only pay for the rows they get.

In one embodiment, the data replication described above can be used to handle various scenarios. For example, in one embodiment, a brand data provider is building its data-driven marketing solution on cloud computing services. They will provide standard and personalized sharing on an open exchange. They have hundreds of terabytes of data and can share it with hundreds of clients, most of whom are new to cloud computing services. Based on the datasets clients purchase 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 this automated shared pipeline to work across regions and clouds with little or no human effort. Additionally, brand data providers may also wish to share data into a VPC.

Customer relationship companies build mobile marketing campaigns and share results with customers via data exchange. In one example, activity data arrives at their 50TB event table at least every 15 minutes, and consumer-specific data will be shared with consumers. Additionally, the company wants to give their consumers a 15-minute delay (or less).

An equipment manufacturer wants to share machine health data with 200 dealers so they can take corrective action. Not a huge amount of data, but there is data coming out throughout the day, and they want to give their dealers latency and/or freshness guarantees. "I would expect remote data sharing to be a continuous stream of data, not a batch model." The company will set up secure views based on entitlement tables that map dealers to devices, so that each dealer only sees the rows relevant to them.

In another example and embodiment, a VPC customer wants to consume shares from data providers in a multi-tenant deployment. In one embodiment, a 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 financial company wants to consume marketing data from a company like a marketing company. However, when consuming data from these data sources directly, considerable effort is required to ingest the data, manage and maintain the ingestion process, and change the management of the underlying schema. Solving what is often referred to as the "first mile problem of data ingestion" can provide enormous benefits. Financial firms can have third parties process the data before ingesting it from the exchange. Additionally, financial companies have multiple business units (BUs) with different needs and visibility requirements for shared 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 controls. Furthermore, any solution to be considered must be easy to use (no additional coding and/or engineering time), robust (no fragile ongoing or maintenance processes). Figure 16 below further describes processing this type of workflow.

14 is a process flow diagram of a method 1400 for sharing data across multiple cloud computing services and/or across multiple regions with cloud computing services. Generally, method 1400 may be performed by processing logic, which may include hardware (eg, processing devices, circuits, special purpose logic, programmable logic, microcode, hardware of devices, integrated circuits, etc.), software (eg, processing instructions to run or execute on the device) or a combination thereof. For example, the processing logic may be implemented as exchange manager 124 . Method 1400 may begin at step 1402, where processing logic receives an indication for 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, data sharing available by request, and/or other types of data sharing as described above. Creating a list is further described in Figure 15 below. 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 of an account that is part of the cloud computing platform or region of the cloud computing platform. For example, in one embodiment, the request may be associated with a customer account for a different cloud computing platform and/or cloud computing platform region than the one associated with the listing Cloud computing platform and/or cloud computing platform region. Processing logic determines whether a provider customer account is allowed in the cloud computing platform and/or cloud computing platform region associated with the listing request. For example, in one embodiment, a provider may have information (eg, security data) that is not allowed outside a certain area. If not, execution proceeds to block 1406, where an error is returned. If the provider customer account is allowed, processing logic creates a customer account listing request at block 1410 . In one embodiment, if the request is for a consumer in a different cloud computing platform and/or cloud computing platform region, processing logic creates a provider account in that cloud computing platform and/or cloud computing platform region, thus The data provider can share the data with the requesting customer.

At block 1412, processing logic shares data. In one embodiment, processing logic shares data by copying the data to the cloud computing platform and/or cloud computing platform region associated with the consumer that issued the original listing request. In one embodiment, the processing logic may replicate the entire data share or portions of the data share. In this embodiment, the processing logic may infer which portions of the data are to be shared based on the characteristics of the requesting consumer (geography, time, etc.). In yet another embodiment, processing logic may be based on customer-customized data (eg, paid data represents a view as opposed to unpaid data, shared data is based on consumer's region, consumer's affiliation, and/or other types of feature). At block 1414, processing logic sets up tasks for frequency replication. In one embodiment, by setting up these tasks, data shared with different cloud computing platforms and/or cloud computing platform regions can be refreshed periodically so that data providers or consumers do not need to manually refresh the data.

In Figure 14, a consumer requests shared data across different cloud computing platforms and/or regions of cloud computing platforms. 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. 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 regions with cloud computing services. For example, the processing logic may be implemented as exchange 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 list of data may include the type of list (eg, standard or on-demand, whether free or paid, what data to share (eg, which tables, rows, etc. of the database to share), any sharing restrictions, data provider information, and/or other information for the listing. At block 1504, processing logic creates the listing in a data exchange. The processing logic may be based on the data to be shared and the cloud computing entity used for the listing (e.g., Cloud computing platform and/or cloud computing platform region) features, pre-replicate shared data. For example, in one embodiment, processing logic can share standard data to different cloud computing platforms where existing consumers exist, or can be based on Geographically pre-shared data (e.g., based on cloud computing platform regional shared weather data) and/or other features. At block 1508, processing logic sets tasks for frequency replication. In one embodiment, by setting these tasks, it is possible to Data shared with different cloud computing platforms and/or cloud computing platform regions is refreshed periodically so that data providers or consumers do not need to manually refresh the data.

In one embodiment, another type of sharing model is one in which the data provider provides the shared data to one or more third party entities before sharing the data with the consumer. This can be used to personalize shared data for consumers. 16 is a process flow diagram of a method 1600 for creating a list for personalized sharing in a data exchange, where the list is available in different cloud computing services and/or in multiple regions with cloud computing services. For example, the processing logic may be implemented as exchange manager 124 . The method 1600 may begin at step 1602, where at block 1602, processing logic receives a request from a data provider to create a list. In one embodiment, the data provider may create a standard list available to all customers, data sharing available by request, and/or other types of data sharing as described above. In yet another embodiment, the list may include a set of cloud computing platforms and/or cloud computing platform areas where the list may be visible. The list may be visible in all possible cloud computing regions and/or cloud computing platform clouds, or may be a subset of all possible cloud computing regions and/or cloud computing platform clouds. Additionally, the list may include other information (eg, 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 a rights map that maps consumer identifiers to data providers. Additionally, the list can include safe views of the data, which are 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 potential third parties. At block 1610, processing logic copies the data to the third party account. At block 1612, processing logic determines a safe view of the shared data for potential consumers. In one embodiment, the security view is used to create a secure way for potential consumers to access shared data. 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 pre-copy the shared data and entitlement table based on the data to be shared and the characteristics of the cloud computing entity (eg, cloud computing platform and/or cloud computing platform region) used for the listing. For example, in one embodiment, processing logic may share standard data to different cloud computing platforms where existing consumers exist, or may pre-share data based on geographic area (eg, share weather data based on cloud computing platform area) and/or or other characteristics.

At block 1616, processing logic receives a listing request. In one embodiment, the request is associated with a consumer account of an account that is part of the cloud computing platform and/or cloud computing region. For example, in one embodiment, the request may be associated with a consumer account on a different cloud computing platform and/or cloud computing platform region than the one associated with the List associated cloud computing platforms and/or cloud computing platform regions. Processing logic determines whether the provider customer account is allowed in the cloud computing platform, cloud computing platform region, and/or VPC associated with the listing request. For example, in one embodiment, a provider may have information that is not allowed outside a certain area (eg, security of data, personally identifiable information, government restrictions, and/or other types of restrictions). If not, the processing logic will return an error. If the provider customer account is allowed, processing logic creates a customer account listing request at block 1618 . In one embodiment, if the request is for a consumer in a different cloud computing platform, cloud computing platform region, and/or VPC, processing logic creates a provider account in that cloud computing platform and/or cloud computing platform region , so the data provider can share the 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 the cloud computing platform and/or cloud computing platform region associated with the consumer that issued the original listing request using a secure view. In one embodiment, the processing logic may replicate the entire data share or portions of the data share. In this embodiment, the processing logic may infer which portions of the data are to be shared based on the characteristics of the requesting consumer (geography, time, etc.). At block 1622, processing logic sets up tasks for frequency replication. In one embodiment, by setting these tasks, data shared with the cloud computing platform and/or cloud computing platform region can be refreshed periodically so that data providers or consumers do not need to manually refresh the data.

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

18 is a block diagram of an example computing device 1800 that can perform one or more operations described herein, according to some embodiments. Computing device 1800 may be connected to other computing devices in a LAN, intranet, extranet, and/or the Internet. The computing device may operate at the capabilities of a server machine in a client-server network environment or at the capabilities of a client in a peer-to-peer network environment. The computing device may be provided by a personal computer (PC), set-top box (STB), server, 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 the machine. Furthermore, although only a single computing device is shown, the term "computing device" should also be considered to include any collection of computing devices that individually or collectively execute a set (or sets) of instructions to perform the methods discussed herein.

Example computing device 1800 may include processing device (eg, general purpose processor, PLD, etc.) 1802, main memory 1804 (eg, synchronous dynamic random access memory (DRAM), read only memory (ROM)), static memory 1806 (eg, Flash memory and data storage devices 1818), which can communicate with each other via bus 1830.

Processing device 1802 may be provided by one or more general-purpose processing devices, such as microprocessors, central processing units, and the like. In an illustrative example, processing device 1802 may include a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a process implementing other instruction sets A processor or a processor that implements a combination of instruction sets. Processing devices 1802 may also include one or more special-purpose processing devices, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, and the like. In accordance with one or more aspects of the present disclosure, processing device 1802 may be configured to perform the operations described herein to perform the operations and steps discussed herein. In one embodiment, processing device 1802 represents cloud computing platform 110 of FIG. 1 . In another embodiment, processing device 1802 represents a processing device of a client device (eg, client devices 101-104).

Computing device 1800 may further include a web interface device 1808 that may communicate with network 1820 . Computing device 1800 may also include a video display unit 1810 (eg, a liquid crystal display (LCD) or cathode ray tube (CRT)), an alphanumeric input device 1812 (eg, a keyboard), a cursor control device 1814 (eg, a mouse), and a sound signal generating device 1816 (eg speakers). 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 (eg, an LCD touch screen).

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

Although computer-readable storage medium 1828 is shown as a single medium in the illustrative examples, the term "computer-readable storage medium" should be understood to include a single medium or multiple media that store one or more sets of instructions (eg, centralized or distributed databases and/or associated caches and servers). The term "computer-readable storage medium" should also be understood to include any medium capable of storing, encoding or carrying a set of instructions for execution by a machine and causing the machine to perform the methods described herein. Accordingly, the term "computer-readable storage medium" shall be considered to include, but not be limited to, solid-state memory, optical media, and magnetic media.

Terms such as "receiving," "receiving," "creating," "determining," "sharing," "providing," "designating," etc. refer to execution by a computing device, unless expressly stated otherwise. or implementing acts and processes that manipulate and convert data represented as physical (electronic) quantities within the registers and memory of a computing device into similar representations of the computing device memory or registers or other such information storage, transmission or Displays other data of physical quantities within the device. Furthermore, as used herein, the terms "first," "second," "third," "fourth," etc. refer to labels used to distinguish different elements, and do not necessarily have a numerical designation based on them. ordinal meaning.

The examples described herein also relate to apparatuses for performing the operations described herein. This 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 computer programs may be stored in computer-readable non-transitory storage media.

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 in accordance with the teachings described herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. As shown in the description above, the required structure for a variety of these systems will appear.

The above description is intended to be illustrative, not restrictive. Although the present disclosure has been described with reference to specific 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 (a)," "an (an)," and "the (the)" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "comprises", "comprising", "includes" and/or "including" as used herein designate the presence of the 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. Therefore, 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 the two figures may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

Although 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 such that they occur at slightly different times, or the described operations may be distributed over a period of time that allows In a system where processing operations occur at various intervals associated with processing.

Various units, circuits, or other components may be described or claimed to be "configured to" or "configurable to" perform one or more tasks. In such contexts, the phrases "configured to" or "configurable to" are used to denote structure by indicating that the unit/circuit/component includes structure (eg, circuitry) that performs one or more tasks during operation. In this way, a specified unit/circuit/component can be said to be configured to perform a task, or can be configured to perform a task, even when the specified unit/circuit/component is not currently operational (eg, not turned on). A unit/circuit/component used with the "configured to" or "configurable to" language includes hardware - eg, circuits, memory storing program instructions executable to implement operations, and the like. A statement that a unit/circuit/component is "configured to" perform one or more tasks, or is "configurable to" perform one or more tasks, is clearly not intended to invoke 35U.S.C. for that unit/circuit/component. 112, sixth paragraph. Additionally, "configured to" or "configurable to" may include general-purpose structures (eg, FPGA or general-purpose processor executing software) manipulated by software and/or firmware (eg, FPGA or general-purpose processor executing software) to operate in a manner capable of performing the tasks in question , general circuit). "Configured to" may also include adapting a manufacturing process (eg, a semiconductor fabrication facility) to manufacture a device (eg, an integrated circuit) adapted to perform or perform one or more tasks. It is expressly stated that "configurable to" does not apply to blank media, unprogrammed processors or unprogrammed general-purpose computers, or unprogrammed programmable logic devices, programmable gate arrays, or other unprogrammed devices, unless accompanied by an attribution to unprogrammed A programming device is configured as a programmed medium capable of performing the disclosed functions.

Any combination of one or more computer-usable or computer-readable media may be utilized. For example, computer readable media may include portable computer magnetic disks, hard disks, random access memory (RAM) devices, read only memory (ROM) devices, erasable programmable read only memory (EPROM or flash memory) devices, portable optical disk read only memory (CDROM), one or more of optical storage devices and magnetic storage devices. 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 will be executed.

Embodiments may also be implemented in cloud computing environments. In this specification and the appended claims, "cloud computing" may be defined as a method used to enable a pervasive, convenient, on-demand implementation of a shared pool of configurable computing resources (eg, networks, servers, storage, applications, and services). A model of network access that can be rapidly provisioned (including via virtualization) and released with minimal management effort or service provider interaction, and then scaled accordingly. Cloud models can consist of various characteristics (eg, on-demand self-service, extensive network access, resource pooling, rapid elasticity, and measurable services), service models (eg, software as a service ("SaaS") , Platform as a Service ("PaaS") and Infrastructure as a Service ("IaaS")) and deployment models (eg, private cloud, community cloud, public cloud, and hybrid cloud). 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 should also be noted that each block of the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented by special purpose hardware-based systems, or combinations of special purpose hardware and computer instructions, that perform the specified functions or actions. These computer program instructions may also be stored in a computer-readable medium, which can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including the instruction apparatus , the instruction means implement the functions/acts specified in the flowchart and/or one or more flowchart blocks.

For purposes of explanation, the foregoing description 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 teachings. The embodiments were chosen and described in order to best explain the principles of the embodiments and their 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 regarded 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 the processing device, an account with each of the set of second cloud computing entities in response to receiving the data sharing information; and The data set from the first cloud computing entity is shared with the set of second cloud computing entities using at least a 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 dataset is one of the plurality of datasets, and the data provider is 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 different from the first cloud computing Platform 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 multiple regions and at least one of the set of second cloud computing entities is a second area different from the first area for the cloud computing platform. 6. The method of claim 5, wherein the account with the second cloud computing entity is a provider account of the second region of the cloud computing platform. 7. The method of claim 1, further comprising: A frequency of updating the dataset shared with the set of second cloud computing entities is determined. 8. The method of claim 1, wherein the sharing of the dataset comprises: determining a set of one or more objects of the shared dataset to be replicated by the set of second cloud computing entities; and The set of one or more objects is replicated 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 dataset is customized for the customer. 10. The method of claim 1, wherein the shared dataset is a subset of a database managed by the data provider. 11. The method of claim 1, wherein the shared dataset references at least one object in a second database different from the first data database used to store the shared dataset. 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 the processing device, an account with each of the set of second cloud computing entities in response to receiving the data sharing information; and The data set from the first cloud computing entity is shared with the set of second cloud computing entities using at least a 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 referencing a plurality of data lists stored in a data storage platform a dataset, the dataset is one of the plurality of datasets, and the data provider is 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 different A cloud computing platform of a 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 wherein the set of second cloud computing entities At least one of is a second area for the cloud computing platform different from the first area. 18. The machine-readable medium of claim 17, wherein the account with 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: A frequency of updating the dataset shared with the set of second cloud computing entities is determined. 20. The machine-readable medium of claim 13, wherein the instructions further cause the computing device to share the dataset by: determining a set of one or more objects of the shared dataset to be replicated by the set of second cloud computing entities; and The set of one or more objects is replicated 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 dataset 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 dataset references at least one object in a second database different from the first data used to store the shared dataset database. 24. The machine-readable medium of claim 23, wherein the instructions further cause the computing device to: The at least one object is copied to the set of second cloud computing entities. 25. A system comprising: the first cloud computing entity; and a set of second cloud computing entities; Data exchange for: receiving data sharing information from a data provider for sharing data sets 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, and The data set from the first cloud computing entity is shared with the set of second cloud computing entities using at least a 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 dataset is one of the plurality of datasets, and the data provider is 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 different from the first cloud computing Platform 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 multiple regions and at least one of the set of second cloud computing entities is a second area different from the first area for the cloud computing platform. 30. The system of claim 29, wherein the account with the second cloud computing entity is a provider account of the second region of the cloud computing platform.

Images