Secure Retail Data Sharing at Scale with Databricks OpenSharing

Summary

• Databricks OpenSharing and clean rooms provide two complementary solutions for secure, governed retail data collaboration: OpenSharing for direct partner data access without copying data, and clean rooms for multi-party analysis with privacy preservation.
• Walmart built Scintilla Cloud Feeds using OpenSharing to serve 65-plus datasets to thousands of suppliers, eliminating API overhead, batch delays, and restatement processing complexity while maintaining 100% data parity and governance.
• Retailers can use Databricks' permission model to control exactly what each partner can see, enforce per-partner access rules, and ensure competing brands sharing the same platform cannot access each other's data.

Secure Retail Data Sharing at Scale with Databricks OpenSharing

Retail data sharing is broken. Spreadsheets, SFTP, fragmented APIs, and no control. Databricks OpenSharing and clean rooms solve this by enabling secure, governed data collaboration without copying data. this video covers both solutions, their architecture, governance, and when to use each one.
Walmart shares a real-world case study of building Scintilla Cloud Feeds using OpenSharing to serve 65 plus data sets to thousands of suppliers. Learn how they eliminated API overhead, batch delays, and restatement processing complexity while maintaining 100% data parity and governance. The session covers reference architectures, permission models, best practices, and the path to multi-party data collaboration at enterprise scale.
🤝

Chapters

• 00:00 Retail Data Sharing Challenges at Scale
• 02:55 OpenSharing vs Clean Rooms Solutions
• 05:08 OpenSharing Reference Architecture
• 08:20 Clean Rooms for Multi-Party Collaboration
• 14:37 Governance Best Practices and Curation
• 20:41 Walmart Data Ventures Strategy
• 22:03 Scale Challenge: 65 Data Sets for Thousands
• 25:06 Evolution from APIs to Cloud Feeds
• 28:39 Cloud Feeds Implementation and Efficiency

FAQs

What is Databricks OpenSharing and how does it work for retail data sharing?

Databricks OpenSharing is a governed data sharing protocol that allows retailers to give partners access to data without physically copying it out of the retailer's data environment. This video explains that traditional methods like SFTP and APIs mean data leaves the retailer's control once shared, whereas OpenSharing maintains governance over the data even after access is granted.

How does Walmart use Databricks OpenSharing for supplier data?

Walmart built Scintilla Cloud Feeds using OpenSharing to deliver 65-plus datasets—including transactions, inventory, and campaign performance—to thousands of suppliers. This video describes how this approach eliminated the API overhead and batch delays of the previous solution while maintaining 100% data parity and governance controls.

When should retailers use OpenSharing versus clean rooms?

This video positions OpenSharing as the right choice when a retailer needs to share data with many external partners efficiently at scale, while clean rooms are better suited for multi-party collaborative analysis where no party should see the other's raw records. The two solutions are complementary, with OpenSharing handling data distribution and clean rooms handling privacy-preserving analytics.

What are the main challenges in retail data sharing that Databricks addresses?

Retailers today share data through spreadsheets, SFTP, and HTTP APIs, which means data is copied outside the retailer's environment with no ongoing control. This video outlines additional challenges including varying refresh-rate SLAs across partners, sensitive PII in customer data, and the need to prevent competing CPG brands from seeing each other's information—all of which Databricks OpenSharing's permission model addresses.

Full transcript

[00:08] Good morning everyone. Um, thank you for coming here to our session on building secure retail data sharing at Walmart. Uh, my name is Harish Rajokalan. I'm a senior solutions architect at data bricks. I work with our retail customers and help them architect their data workloads on data bricks. With me we
[00:25] have Karan uh from Walmart data ventures. uh he'll be presenting the second half of the session. All right. Uh so what's our agenda for the next 40 minutes? Uh we will start with why data sharing in retail is hard
[00:40] harder than it should be. uh and then what are the two options that data bricks has uh to help you solve for it and then we'll walk through the architecture for uh open sharing um the use cases reference architecture and
[00:55] then we'll do the same for clean rooms and then we'll bring it all together with uh governance uh how how you can share the data through a control mechanism and then for the second half of the session uh Karan will come and present the Walmart central
[01:15] All right. So, retailers share all sorts of data with different types of partners. U from our observation in the field, these are the top four categories. It could be the transactions data or the customer and loyalty information, the inventory and supply chain data and
[01:32] campaign management and performance. And this data gets shared with the CPG brands, the ad agencies, the suppliers and the measurement teams. And each of these data flows has different requirements. The data
[01:49] comes with to the retailers through different means. It comes at different velocities. The data is often sensitive. It has very personally identifiable information of customers as well as very competitive information. So if a
[02:05] retailer is sharing data with the CPG brands, you don't want competing brands to see each other's data. Also, there will be different refresh rate SLAs that the retailers might commit with different partners. Some data needs to be shared with their partners multiple times a day. some
[02:22] other data might need to just be it'll be just fine to share it once in few months right and most of this data even today is shared through spreadsheets or SFTP shares or HTTP APIs and the problem with that is that the data gets copied
[02:39] everywhere so once the data leaves the retailer's data parameter often there is no control over the data for the retailer all right so this is the problem in retail data sharing and what
[02:55] options does data bricks have uh to solve for this? We have two services. One is open sharing and another is clean rooms. So with open sharing um you use this when you want to share data with a known
[03:12] partner. So you know the person whom you are sharing the data with. The data transfer is one way. There is no data movement, no copy, no replication, nothing,
[03:30] no copy, no replication. Uh it is crosscloud, crossplatform. So the retailer can be in AWS, the recipient can be in Azure, GCP, doesn't matter. You could be in USCs, they could be in central, again does not matter. and the recipient uh if you are sharing if you
[03:45] are a retailer and sharing uh data with your CPG brands they don't even need to have a datab bricks account to consume this data and then there is the other service clean rooms where there might be situations where you might not want to
[04:01] trust the other partner with your data right but you might want to do combined analytics and the output of that combined analytics is is what you need so that's when you you will use clean rooms. It allows for multi-party collaboration. So many retailers uh
[04:18] sorry many CPG brands and third parties can combine together and work on the same data set to get the output. And then um this runs in an centrally isolated environment that neither side controls. So you don't share the raw data only the mutually approved notebook
[04:35] runs on the data. The maximum thing that the other collaborating party can see in the clean room is the metadata of the data. That's it. And it's not the one or the other option. Um, often in a retail industry,
[04:51] both of these options will be used combined together depending on the use case. So, we'll look at each one of these options uh in in in in deeper. Uh, starting with open sharing. This will be the most common um feature that you'll
[05:08] use. Uh and this is like your workhorse for most of the use cases. And what are the retail use cases that open sharing solve for? Um it could be that retailers want to share their um sell through information, shelf
[05:24] availability and retail positions with their CPG brands. Usually this is done through SFTP. It replaces that. It helps with uh the CPG being able to plan for their promotions and forecast their demand easily.
[05:40] And then the second set of data could be the retailer sharing data with the ad agencies. So this could be uh data like campaign performance, audience reach and how how is the promotion behaving, right? The third one could be the brand
[05:56] supplier data where a a a retail brand could be sharing the information and demand forecast signals with their third party manufacturers and um third party partners. This helps them compress the planning cycle and plan for inventory
[06:12] better. The fourth use case is retailer building their first party data service for data monetization. So you have this data gold mine that you would want to monetize uh through subscription. Um so that's that's another use case. Um again
[06:28] Karan will be talking about this last use case more on his session. And why is open sharing very apt for these use cases? It comes down to three principles. One is that when you create
[06:43] a share, add your tables and then share that with your uh CPG partners. there is no data movement. So the data stays where it is and the CPG branch use it. The recipients just directly access the data from your uh object storage. It
[06:59] could be ADLS, S3 or GCS bucket. And what the open shining facilitates is the authorization and authentication and the the provisioning access to the data. Right? So the data stays in one place
[07:15] and the rule number two is that um it can be cross cloud. So you you you you can be in one cloud the other person can be in other cloud and it doesn't matter. And the third principle that uh helps it is um the control that you get over the
[07:32] data. So you can revoke rotate passwords whenever you want. You can restrict access to the data whenever you want. You get to see the audits. You get to control the row level, column level filters on the data set that you want,
[07:48] right? And um on the other side, the partners can just use their OIDC federation, bring their own authentication and access the data. They don't even have need to have a datab bricks account. So that is why open sharing uh is very apt for these use
[08:05] cases. All right. So now we saw um uh the problems of u data sharing in the retail industry. We saw the two options. We saw open sharing uh what it is, why it is
[08:20] being used. Now we'll see how it will be used through a reference architecture. So let's say this is a reference architecture of a retailer who wants to share data with their beverage brand. Let's call that beverage brand as Acme,
[08:37] right? So on on the left you have all the retail data sources um through which the retailers get the data. It could be the POSOS data that has all the basket sell through information all the transactions that happen at store level
[08:52] that comes in. Then you could have your inventory data in the SAP systems. You would be ingesting that through CDC uh into your lake. You could have u master datas at the skew level um uh and then store locator information and all those
[09:08] details and all these data reside in the bronze layer. It is a bit messy but it is operationally very important and no one except the retailers should have control over this data. You don't expose your bronze layer to anyone else. And
[09:23] then you build your silver layer from it which is often the facts in the dimensions table. You will get all these data, cleanse them up, uh ddup all those information and then form a confirmed entity with more defined schemas and then you build your sharable goal layer
[09:41] which has more defined schemas. Um it has uh rules and SLAs and all those things. This is the only thing that will get exposed to the um partners that you're sharing data with. And underlying this is the Unity catalog. So Unity catalog provides the
[09:58] full governance. It provides uh role level security. So you could have all the partner information in just one underlying table and you can define role level predicates saying that brand equal to acme. So even though um
[10:15] all the partners are reading from the same underlying tables, this role level security will just expose only the data that they are supposed to see from from from your side. And then uh it has uh Unity catalog also provides a service called as data
[10:30] classification which goes and analyzes tables for sensitive information and then it tags them uh for PII or other um sensitive information you can use that to define your column level masking. So even though the underlying table has
[10:46] informations um uh information related everything related to um customer you might want to mask a phone number or email address before sharing. So that is where the data classification plus the column level masking is very helpful. Then you have the lineage uh which helps
[11:02] you trace back which column maps to what table from what source. And then you have egress controls that restrict the flow of information uh outside. And then you have audit tracking that lets you track which uh partner access what
[11:18] information at what time from what IP address and all those details. Right? So you now get a very governed defined layer on the provider side. And then the centerpiece is the open sharing service previously known as delta sharing. So what it does is that you will set up a
[11:35] share that you want to share with your partner and you will add your tables, views and everything to it. On the open sharing side, it will create when the recipient requests for an access, it will create a single sign URL uh scoped to that data that they are supposed to
[11:50] see and the the partner on the other side will just use that to access your data. And then coming to the right you have the CPG brand. They can be in data bricks or they don't have to be in data bricks. But if they are in data bricks, the tables that you have shared will
[12:06] appear as a part of their unity catalog just like layer local table. That's it. So no no no data movement no overnight copies um uh you know no stale data problem or anything as soon as the retailer shares the data the consumer brands can access it
[12:23] then they will use that data with their own information first party services related to shipments or promotions and then transform that into uh business outcomes where they understand what is the onshelf availability for a
[12:38] particular retailer where do they need to redirect their inventory. Uh what is the impact of the ad spend on on a particular brand and how does that translate to sales and how how frequent they need to replenish uh their inventory and all this information and
[12:54] then you have the consumers at the bottom um where the business users can use apps or Genie or BI dashboards to access that information. So this is the reference architecture um for um open sharing. But there might
[13:12] be situations where uh you might not know the partner or you might not want to share your data directly with the partner because of competitive reasons or for some legal restrictions. Right? So that's where clean room comes into play. Um what are the common use cases
[13:29] that we see for clean rooms uh in the retail industry? First one is the retail media uh network measurements. This is when a brand wants to know u what is the impact of the ad spend that they have with the retailer. Uh I I did this ad
[13:46] with this retailer on their website. How how is this translating to sales? Right? Or it could be uh analyzing audience overlap. There could be three stakeholders, three partners who want to identify their high value, mutual high-v value customers, but they don't want to
[14:02] share the entire list of their customers with each other. So that's another use case for clean rooms. Or uh the third one is uh joint demand forecasting where the supplier and the u retailer um collaborate to forecast the demand but
[14:20] they don't want to share their entire operational data. These are the common use cases. And uh how does clean room help with these use cases? Uh the first ground rule is that when both parties are collaborating in the clean room, even though if one party owns the clean room,
[14:37] no one has an elevated priv privilege. It's like a no trust zone, both parties have equal privilege on the clean room. So that's that's the ground rule. And then when you create a clean room uh it it is a datab bricks managed environment where both parties can collaborate. It
[14:55] is isolated only the approved notebooks will run and when a notebook runs before a notebook runs both party need to um review the notebook and approve it. Even if one party does not approve it
[15:10] you cannot run that notebook on the clean room. And um it works on the underlying delta sharing protocol which is now open sharing. So both the parties the retailer on this side will share their customers customer purchase data uh but the data remains in their account
[15:28] and on the right we'll have the CPG uh partners who will bring in their campaign exposure data. Again the data for that stays in their environment itself. both gets delta shared to the managed environment and then the approved notebook runs and each party takes the
[15:45] output and then they can export it to their own environment without seeing other parties data. So uh again three governing principles um no trust equal privilege for all code approval required for any notebook to be run on the environment and it can work crosscloud
[16:02] cross region. So those are the defining principles. How does this translate to a reference architecture? Again um um the the the the problem statement here is that the brand might want to know the impact of
[16:18] the ad spend that they have with the retailer. So on the retailer side they will share the uh loyalty ID uh basket transaction information skew information and all those details. Uh and then they will mask the sensitive data right in
[16:33] this case the loyalty ID might need to be hashed right. So hashing is um a term for anonymizing the data. They will use something called a salt value that can be rotated. The salt value will be stored in a K KMS environment or or a key management system. And then what
[16:51] gets shared is the hashed loyalty ID. Uh then the store ID, the units, basket revenue and all those information. What stays private and hidden is the raw PII uh the cross brand information, the customer LTV, store level margins and
[17:07] all those information, right? And then you have the uh brands on the right side. Uh they will share their ad exposure table. And again here they will use the similar mechanism that the retailer used for hashing their environment and use it to their customer
[17:25] uh ID right. So the customer ID is hashed with the same salt value that is exposed on the KMS side. So now you have uh hash ids on both the places both use the same mechanism to hash the value. So when you just do a combined join on them
[17:40] uh you will get uh the the common values that are being shared on both sides. Right? On the clean rooms, you'll run a notebook that will join on the hash ID from both sides and then it will calculate the aggregate over the 14-day window and then uh you can group them by
[17:56] the DMA and and uh campaign information and the output if you see here uh the retailer will get the campaign lift. They will know the impact that their ad had had on a brand and similarly on the brand side they will have the
[18:13] information on the sales uplift because of the uh ad that they spend right both parties get their output and then they can export it to their own unity catalog and the output is um very aggregate only it is rate limited it is anonymized and
[18:30] then it's completely private So putting all these together, how does it look like in one reference architecture? You'll have the source data on the left. You have the control governance mechanisms for data sharing. And then you have the two options that
[18:46] we provide uh uh for sharing your information for the retail and then underneath technology is the open sharing, clean rooms and the marketplace. So what are the best practices for taking this to scale? Always share only
[19:01] the curated layer. Don't share the bronze or the silver layer. Um tag and classify data based on their sensitivity. Uh use tools like the data classification service that Unity catalog offers for that. Uh maintain clean room hygiene. U make sure only the
[19:17] approved notebooks run and then review the aggregates. The it's just easy to do a select star on everything on a clean room and then just get everything out. So be careful on what you want to limit the aggregation on and how to export the data. Handle PII information upstream.
[19:33] Um doing it down is a little difficult. And then treat every product as a sorry treat every data as a product life cycle. And how to make take it further and make it usable for business. Leverage tools
[19:49] like Genie, data bricks apps and marketplace uh for for the business users. So a quick summary uh pick the right tool for the right partner governance is the product control sharing is how it scales and then once the data is there
[20:07] make it easier for businesses to consume the data right so summary of what we saw um we saw about detailed data sharing the two mechanisms that data bricks has uh for sharing data we saw reference
[20:22] architectures on how you and share data through a control mechanism and then the use cases that map to it for the next section. I'll hand it over to Karan.
[20:41] Is it I probably don't need the mic but still uh it's a big room. All right. Good good morning everybody. Uh my name is Karan Sa. I am director at product management for Walmart data
[20:58] ventures. Uh we have built a product on open sharing that you heard Harish uh talk about although the in the reference architecture he did mention a retailer that is based on AWS. So I don't know who you were talking about. Um
[21:13] definitely not us. And uh that whoever laughed was probably paying attention because the rest of you were not. So talking about Walmart, I think this is no secret. Walmart is based on um
[21:29] Walmart is really focused on serving our customers uh through the channel of their choice. Um you know be it online on on the application in store. So we're really focused on serving our customer. Um, and while we're serving our
[21:45] customers, it's our duty to really get our suppliers and vendors the information that they need to be more efficient. And so we stood up data ventures uh several years ago. I it's already been six years, which blows my mind because time is just running. Um,
[22:03] and with data ventures, what we've done is we've tried to productize some of the the the data that all of our marketplace kind of uh generates. And Cintilla is our first flagship product uh which brings actionable insights and things
[22:20] that you need to to be more efficient um uh in in the Walmart marketplace. So Cintella if you talk about it uh there are there's plethora of information that we provide through various channels. Uh there is the question of you know what are our
[22:37] shoppers doing in our stores or various channels. It could be online on the app. So we're really giving you the information around what the basket looks like. You know, think about item affinity, what things are being bought together and things of that nature. Uh then there is digital landscape. Uh how
[22:54] is a customer on the online uh landscape kind of reaching what they're trying to to buy. So you know, think about keywords they use, how do they connect to the cart, how do it connect to the the checkout process and things of that nature. Through insight activation,
[23:11] we're also making sure that you utilize all of this information about shopper and activate ads uh for uh for various purposes. And it could be um onsite, off-site. On-site is all of our platform. You know, think about searched uh sponsored search displays on the
[23:27] homepage or off-site ads where you're going through a publisher to to reach your customer. Then there's customer perception. We have a massive panel of real Walmart shoppers that you can reach using customer perception product. Uh
[23:44] you can you know build think about questions that you want to ask your customer right if one of you gets like this wild idea of launching golden toilet paper for example how do you how do you know if the customer is actually going to buy? So you can use our
[24:00] customer perception product to reach those hundreds of thousands of Walmart real Walmart customers to get their opinion. And then finally which is what we'll talk about is channel performance. This is where it uh whatever you heard Harish talk about you know comes to life. Uh
[24:18] where we source data from various uh systems within Walmart uh to bring operational data and fulfillment metrics uh from all of our channels together and provide insights um to uh to our our our
[24:33] our customers and our suppliers. So really what channel performance is is a true omni uh sales data um and true omni platform fulfillment metrics. I won't get into each and every detail because I
[24:48] mean if you work with retail and CPG customers you probably know what I'm talking about. So I'll get I'll cut to the chase. I'll talk about how big the data is and really what the challenge that we're faced with. Just the store sales data if you look at it for a CPG brand we're looking at 3,830 and these
[25:06] are average numbers it keeps going up down depends on CPG customers you're looking at 3,000 to 4,000 distinct items through six service channels you know within the app also we have online pickup delivery shipping things of that
[25:22] nature and we have approximately and we continue to grow um we have 4,600 Walmart stores uh around the country and we're also international so that actually is just for us uh and we provide two years of historical data and
[25:39] there are about 30 KPIs that we're looking at this is just store sales and that is 5.5 gigs just for one day right let me put that into perspective we have 65 such data sets that we deliver every
[25:54] day so that times 65 data sets times thousands of suppliers that we're delivering it to. Right? So that we actually face a monumental challenge of how we supply this data to whoever wants
[26:10] to consume it. Do it in an efficient way uh cost effective it not just for us but also for whoever is consuming it. So uh six years ago I keep saying five but it's almost been six years now we launched APIs. prior to this so that we
[26:28] kind of ground oursel in how business was done before um Walmart had retail link and there was something called SDSS that was a UI based product where users would go and download the data and then use it for whatever they wanted to. Um
[26:44] over decades there was a need for uh the suppliers and vendors to get programmatic access to these data sets as we started training models and started doing machine learning. Today it's AI. So it's a completely different game and you'll you you'll see how we're
[27:00] getting ourselves ready for that world. Um so the so in the prior world uh the need for programmatic access to data actually led to development of certain bots which is essentially scraping machine if you think about that uh who would go to the
[27:17] UI download the data and then make it available for various databases data links that that our suppliers were setting up. So we launched APIs uh that would make that programmatic access easier to all of the 65 plus robust data
[27:33] sets that we we supply as a part of our charter. Um in which case we think about two API endpoints. One is where the status of the data availability is is provided. So the programs would pull that API endpoint and then get an answer
[27:50] whether the data is ready or not. So some data sets are available daily, some are weekly and things of that nature. Um once the data is available, they retrieve the data through the link that we've provided in the other API endpoint and then download it, carry out their
[28:06] ETL process, store the data somewhere, and then supply that to the consumer applications that are making that data insight available to their end consumer. While this was best-in-class at the
[28:22] time, as the use cases evolved, we evolved and uh we started working with suppliers that needed uh to challenge us in terms of use cases, right? We started to see that uh there are some opportunities as
[28:39] as we like to say it in the Walmart world, we don't say problems um of fragmented data access. So we have these 65 plus endpoints. You're pulling, you're downloading, and you're doing all of these things. So this fragmented data access architecture was cha I wouldn't
[28:57] say was bad. It was challenging for the the next generation of use cases that we're talking about. The data ingestion was obviously there was an overhead. We introduced the a bunch of API development requirement, data engineering requirements, all of those kind of things. So we didn't want our
[29:15] product to be expensive to consume, right? So we saw that there is an overhead that we've introduced and then of of course ultimately there's processing complexity. So you're you're downloading the data, carrying out your ETL process, you're using all of that
[29:30] compute storage, you even though you want only portion of that data, you'd still need to download the whole file, load it and and things of that nature. So there was there were some guiding principles that that led uh to us thinking about what is next uh in terms
[29:46] of uh delivering a product that really suits that next generation use cases. So we wanted to be tech agnostic as much as we love data bricks I'm sitting in their summit um we wanted to be tech agnostic. We didn't want to push anyone in a in a
[30:02] certain direction. Um so that was a core principle that we had to we had to kind of keep keep in mind. We wanted it to be skill inclusive. So we didn't want to introduce overheads that we we saw with API development and and things of that nature. So something that you know
[30:19] existing skill sets at the consumer ed can can can be utilized to consume this data. Um at Walmart governance is is very important. So we had to keep that in mind as well. And finally uh the all of this was super complicated. So we had
[30:36] to create an abstraction layer. So we hide all of that complexity um underneath our product. So what we did was we met up with Harish and team and the bunch of uh data bricks engineers and then we came up with what
[30:52] we now call as cloud feeds which is based on open sharing protocol which we used to call as delta share before. So what it does there is Walmart cloud which is not on AWS
[31:07] and there is all of these rich data sets that we have created that are sitting in a table. Um and what we're doing now is we've created for each of those tables we've created
[31:23] what we call as delta format or open format. Is that what you call now? open format that has enabled us to create unity catalog which we can now expose through this protocol uh by just sharing one dot share file which you can
[31:41] introduce into your own instance if you're using data bricks and get direct access to those tables think what what does that do for you don't have to now pull an API to check for status you don't have to download that data
[31:57] you're straight away reading from the table that we're updating and you don't exactly well like I said as much as I love data bricks you don't exactly need to be on data bricks you could be anywhere and still access those tables directly you can program your
[32:15] applications in the language of your choice to read directly from these tables right so from a benefits perspective what we saw was direct access um you don't have to download. So we've taken all of those ETL overheads out and
[32:32] uh you know we've we've reduced that that overhead and uh um I actually wanted to touch on the historical part in just the next slide but uh but of course like we we are also 100% at par
[32:48] with the API data feeds that we had before. So this is why I wanted to move to the next slide uh because this is one of the the key things that will make you understand how we're making it more efficient for you to consume the data.
[33:04] So there are a lot of historical restatements that take place in our in our data. I mean it's just by design, right? There will be accounting things that that will need to be taken care of. There will be inventory uh audits that take place that change the data that you already consume. So if there is a
[33:20] historical restatement that takes place, think about that from a Walmart scale, I'll have to generate those files again. You'll have to download those files again. As you can see in that process, rerun all your ETL. That is just a lot of overhead. Right
[33:36] now what we do is now since you're reading my tables directly, I just make those updates on those tables and your programs will directly read it from there. You don't need to do any of this that you were doing before. So it has changed the game right and
[33:51] what we've seen is because you're not downloading this data because you're not processing this we've reduced compute we've reduced storage and some of our customers and I don't know how many of you will be attending the uni liver session as well but they'll talk about how efficient this is this has made for
[34:08] them to consume data and um ultimately save a lot of compute and storage I won't give out the number they'll probably talk about it in their session so I won't steal their under there. Uh so what is more important is um are we at par with the
[34:24] data fields? I mean I don't know how many of you are from the CPG world but uh this is very important. I mean I've provided you with a more efficient product but is it at par with the data feeds? Yes. Now it is. We've introduced all uh of of the data sets that we had
[34:41] available through data feeds API um available in cloud feeds. And with this, I'm going to uh I'm going to finish by giving you some food for thought. All of the work that we've done with Open Share and creating a Unity catalog is actually
[34:57] getting us ready for the future. And what does the future look like? Because there is less movement of data. There's more governed movement of data. uh we're actually going to be able to help our customers and I say our customers at
[35:13] data ventures customers our suppliers and vendors get more access to data um be able to come to our tools and run queries that are more uh that are relevant to their business and get
[35:29] insights and take actions action faster with various data delivery mechanisms that we have u which could be through cloud feeds. In the future, we're also looking at maybe having BI link also through open sharing protocol and things
[35:45] of that nature. Ultimately, uh you're going to have data collaboration more efficient where you will be able to bring your data, combine it with some of our data that we could have not shared otherwise and generate insights that could help your business
[36:00] grow better. With that, I'll uh leave you with the QR code where you can read more about what we're doing. And uh with that, thank you very much.

Learn more about the Databricks Data and AI platform.