Securing Data Collaboration: A Deep Dive Into Security, Frameworks, and Use Cases

Summary

• Delta Sharing security internals: Bilal and Alghali dive into how Delta Sharing enables real-time, governed data exchange across organizations without exposing underlying infrastructure or credentials.
• Cleanrooms for private analytics: Cleanrooms let multiple parties analyze shared data without exposing individual records, enabling consortium analytics and competitive insights while preserving privacy.
• Private exchanges and marketplace: Databricks Marketplace enables secure data and model sharing through private exchanges, letting organizations monetize datasets and AI models with partners.

Securing Data Collaboration: A Deep Dive Into Security, Frameworks, and Use Cases

Talk by Bhavin Kukadia, Work hard, have fun, make money, Databricks ; Bilal Obeidat, Principal Product Specialist, Databricks ; El Ghali Benchekroun, Specialist Solutions Architect, Databricks
this video will focus on the security aspects of Databricks Delta Sharing, Databricks Cleanrooms and Databricks Marketplace, providing an exploration of how these solutions enable secure and scalable data collaboration while prioritizing privacy. Highlights: Use cases — Understand how Delta Sharing facilitates governed, real-time data exchange across platforms and how Cleanrooms support multi-party analytics without exposing sensitive information Security internals — Dive into Delta Sharing's security frameworks Dynamic views — Learn about fine-grained security controls Privacy-first Cleanrooms — Explore how Cleanrooms enable secure analytics while maintaining strict data privacy standards Private exchanges — Explore the role of private exchanges using Databricks Marketplace in securely sharing custom datasets and AI models with specific partners or subsidiaries Network security & compliance — Review best practices for network configurations and compliance measures
Here’s more to explore:
Open data sharing for data, analytics, and AI: https://www.databricks.com/product/delta-sharing
A new approach to data sharing: https://www.databricks.com/resources/ebook/a-new-approach-to-data-sharing
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

FAQs

How does Delta Sharing enable secure data exchange?

Delta Sharing allows organizations to share live data with partners without copying it. Recipients access real-time data through credentials without seeing underlying infrastructure, maintaining security and reducing data duplication.

What are Cleanrooms and when are they used?

Cleanrooms enable multiple parties to run analytics on shared data without exposing individual records. They're used for consortium research, competitive analysis, and regulated data sharing where privacy is paramount.

How does Databricks Marketplace work?

Marketplace is a governed platform for sharing datasets, models, and analytical assets. Organizations can discover, evaluate, and access data products through private exchanges or public marketplace listings.

What compliance and network security measures are important?

This video covers security frameworks, dynamic view controls, best practices for network configuration, and compliance measures ensuring data sharing meets regulatory requirements like GDPR and HIPAA.

Full transcript

Uh hi everyone. I work as a principal product specialist focusing on data collaboration for Databricks. Um I have been with Databricks since 2017, but I have been on data collaboration for the last uh 2 years. So, my role is really interesting role. It's kind of like I said between the field engineering I support the field engineering and our account team. And to make sure, you know, our client they understand the capability of the product and help them, you know, have an easy implementation.
Uh at the same time uh I provide feedback to the PM team and work closely with them on uh kind of private preview and make sure like our features are and our road map are well aligned with our clients' needs. So, if you have also like any use case, happy to chat with you after this or reach out to me. I'll be more than happy to work with you. I'm also joined by my colleague. Uh his part is going to be, by the way. So, I hope many of you speak.
Now, his part of our Databricks office. You want to kind of Yeah. Sure. Hello everybody. Nice to meet you. I am part of the specialist solutions architect team. I'm based in Paris. So, please forgive me uh for my accent. If you don't understand something, please forgive me again and please ask questions. I will try to do my best. Um I'm specialized on security, cloud infrastructure, DevOps, and I mainly work with EMEA southern EMEA customers, so uh customers, Spanish customers, Italian customers, and also Middle Eastern South Africa.
I'm happy to be with you today in San Francisco. Awesome. So, just to kind give you an idea what type of topics we're going to cover here. So, we're going to spend a quite bit of time to talk about the power of Delta Sharing. This is an enterprise ready product that you already if you are using Databricks, most likely you're already using uh Delta Sharing. It power many of the capabilities that some of our customer already using.
Uh also, the other part because we built this presentation as based on the kind lesson we learned from working with our enterprise customer is really choosing the right sharing product. So, we walk you through how to choose and build kind of Delta Sharing the strategy that works well and align well with your use cases. Uh after that, Al Ghali is going to cover the inside of Delta Sharing, the internals of Delta Sharing.
So, this is really a session for the practitioner. You don't have to be an expert in security or anything like that because we are also going to cover securing Delta Sharing in real-world scenario. I mean, we try to cover mostly 80% of the scenarios. So, this way hopefully we make it smooth journey uh for you. Uh and in the last two parts, I'm going to cover like the filter data sharing. Honestly, we get kind of questions like, "Okay, well, how could I use uh you know, dynamic views to provide uh uh horizontal, you know, data filtering or even sometime vertical data filtering kind, you know, uh hide some of these columns when I share my data."
Uh in the last part, we're also going to talk about the clean rooms security. Why clean rooms really like secure, what are the internals of the clean room. So, that will kind give you hopefully a good idea, you know, about data collaboration in general using uh Databricks product. Now, the power of Delta Sharing. Delta Sharing is an enterprise ready product. How many people here they use system tables? Awesome. So, if you are using system table, I think many of you they already know they are using Delta Sharing.
So, imagine like Databricks process all these uh metrics, data logs, every hour they refresh, you know, the kind of system tables, petabyte of data. And all of this is really powered by Delta Sharing. So, Delta Sharing is an enterprise ready product. It has been in the market for at least 5 years. And we also, you know, use it ourselves to provide our services to our clients. Uh I think all of you they know what's the system table, so you can read them, but someone really new kind of data.
The other part that we use Delta Sharing. This is why it's important really in order to use any of data collaboration product to start with Delta Sharing. It's kind of the foundation. Uh you will be using it clean room. Clean room is uh it will provide secure collaboration without exposing raw data, but it also leverage Delta Sharing. So, if you understand So, it's kind of like really required to understand the Delta Sharing if you going to want to use the clean room.
Now, uh we will have one, you know, like several slide on clean room, but you can use different languages, Python and SQL. Uh we support different cloud. And also it's built for privacy and compliance. We have one slide that will help you distinguish like when to use a clean room versus when to use Delta Sharing. Marketplace Marketplace, I believe, released almost 3 years ago. But, it also helped our customer to discover and access wide range of data sets.
So, we have many data partners, hundred data partners, who make their data available on Databricks. So, you can you can use it as part of your data processing. But, at the same time, I'm talking to customer often, they already have interesting data, and they want to monetize this data. So, using the Marketplace will help them generate leads, you know? But, instead of focusing on the infrastructure of data sharing, and each customer has different environments, so this way, really you leverage Databricks to kind, you know, immediately make this data is available, and then you only worry about the commercial transaction.
Uh so, that's kind like a great benefit, but Marketplace is also on top of Delta Sharing. Now, I know someone really nothing new in Delta Sharing, but this is slide is really worth it to double-check on the different scenarios of Delta Sharing. So, you could have Let's just start with the left side, you know? You will have a provider and the recipient. So, these for internal data sharing, they could be on different the cloud region.
To have an internal data sharing, and this could be if you have a different, you know, business function. As an example, you operate in West US, but you have your reporting team in Europe or in India. So, it is because Delta Sharing is well integrated with you see, you can use the UI, and if you click, you make the data available for your team, reporting team. And this is really First, this is not a copy of copy you don't make a duplicate copy of the data.
If you need to, you can. We provide four different ways to make this data replicated. At the same time, it is live sharing. So, you don't have to worry about that the data is stale or outdated and things like that. So, it's a great use case for internal use case, especially if you already on Databricks. And uh this is where the provider and the recipient are both on Databricks. The other use case, which is they could be in the same region or across regions.
But, you are sharing data with your partner. You have an external partner, and you always worry it's like, "Oh, do I do SFTP? Do I send it by email?" I mean, things like that. Now, if they are on Databricks, and if they are not even on Databricks, you can share this data with them. Uh the other the third use case, you can also share across cloud. We have this use case like many of our customer, as an example, they will have a business function on Azure, while they have a business function on uh like AWS for some reason, or they acquire a company on AWS.
So, they want to share this data. So, it's kind of like, you know, really a few clicks, you'll be able to share that data with them. Now, the last one on the right will enable you to share data with when the recipient they are not on Databricks. They could be on any platform. One thing here, I know open can be sometime, you know, confusing for some people. They don't need to be on Databricks, but you still need to use a Delta Sharing connector.
Now, the most common connector, everyone I think knows Python. So, they could be just using, you know, the Delta Sharing Python library, and immediately they will be able to access this data. Or you meet the client where they are. If they want to consume this data in Tableau, there's a connector for Tableau. You know, if there's a Power BI, there's a connector for Power BI. Now, remember, these connectors are created like, you know, the Power BI created by Microsoft.
They work, you know, with Databricks, the Tableau, the same thing. But, there are many different connectors. There is no one There isn't connector a lot of customer, they will just use the Python connector, download the data, and then they can just it to whatever uh system. Also, Delta Sharing, I mean, we view it as a unique offering for these capabilities. As you already saw from the previous diagram, it's open sharing across cloud, across region, across platform for maximum reach.
And remember, really like to share across region or across cloud, there isn't extra step or different step that you have to do. Uh it's also, because I mentioned it provide the lowest TCO. Why? Because it's a single copy of sharing. There is no data replication. Again, you can replicate if you need to or if makes sense to replicate the data, but this is why it's lowest TCO. It's a single copy across cloud, across region.
The third part it it's pretty can make it even more unique, it's AI ready. You can share not only tabular data, which is I think everyone familiar with Delta table. You can share AI model, notebook, and volume sharing. I honestly, my favorite is the notebook. Because you share data with another team. The data you usually like it's a data model. Could be 20 tables. But when you share a notebook, you can share with them SQL query that explain how the data need to be joined and need to be consumed.
Instead of you know, spending hours with them going over the you know, the semantic model and explain how it should be used. And then if you can give them an idea how what really the data metrics they can use, you know, from these notebooks. All of this is really available in the same place. Because if you are using the UI, you can select the notebook alongside, you know, the AI model uh and also the table. The last use case, this is really the privacy safe with flexible cross cloud cross cloud clear room.
So, if you really want to collaborate with another team or another org, but you don't want to share the underlying data. But both of you want to accomplish a particular, you know, task together, then you can use a clear room for that. And there is plenty use cases, you know, for that uh Now, this is the open data sharing ecosystem. So, if you see like on the top part is the Databricks provider, they are on Databricks and Delta Sharing require two things.
Like if you are using managed Delta Sharing, it's required that you use UC and Delta as a table format. But also, you know, we like we saw you can also now use external federated data. So, if you have data in another system in Snowflake or, you know, MySQL or, you know, any of the federated lakehouse, you can also share it internally. My point is, like, we try also to keep the product aligned with the new feature that Databricks uh provide.
Now, the lower part, if you see here, it's called open-source non-Databricks provider. So, Oracle has an example, Amperity. What that mean, these guys, they don't, as a provider, they don't use Databricks. You know, the Oracle use autonomous database. Amperity, they maybe have their own open-source Delta Sharing uh server, but they can still use Delta Sharing to share data with Databricks recipients. And we have that kind, you know, documented part of the documentations, kind of easy setup, and uh we uh require a combination a communication between the control plane and their Delta Sharing server.
Now, the recipient, as you see in this diagram on the top part, they can be a Databricks or they can be a non-Databricks recipient. As long as I again, there is a connector they can use, but everyone can use also the Python or the PySpark open-source connector as well. Now, this is really the most interesting part, choosing the right sharing product. Cuz talking to some of the customers sometime, we we we have to kind challenge them on the use case, make sure they are using the right use case uh the the right product for their use case.
Now, manage versus uh like open source Delta Sharing uh Delta Sharing. Now, Delta Sharing definitely an open source product and we embrace it and many customers they already using it. But, you need to take an informed decision when you can decide, "Okay, do I use managed Delta Sharing?" Managed mean you are using like the Delta Sharing that's in as part of Databricks. So, you need to think about these things. Like when you use managed Delta Sharing, the provider has to use Unity Catalog.
Now, the other benefit, you know, like with open source Delta Sharing, any provider can use as long as they own their own Delta Sharing server. So, it's really on the client to implement their own Delta Sharing. What's the benefit you get? So, you get a simplified setup. Uh you Databricks manage the infrastructure and the security and things like that. So, that's While, you know, on the other side with open source, provided flexibility, you know, Databricks dependency.
Now, there are different also feature like the hosting Delta Sharing server the service is really part of the control plane. It sit alongside UC because there's a a lot of communication between the two services. While if you're using open source, it's really on the client to set up that server. It's not difficult. Many clients do it. But, you need to understand it's really on you to secure that uh server. Now, also we uh in term of a scale, that managed Delta Sharing because we use a cloud token.
I know like in the all that documentation a lot of talk about pre-signed URL. And some customer they they confused the open source with the managed. Because the cloud token is something associated with Unity Catalog. This is how Unity Catalog work, you know? It's so the it give you better scale and we will be and the better way to support some of the new feature. We have a a whole slide on cloud token. But with open sharing you are limited to pre-signed URL.
Uh I think we skip a slide, right? This is the most important part. Also, when you selecting Delta Sharing versus SQL endpoint. SQL endpoint really you accessing the the serverless or the SQL endpoint to query the data. So, you need to decide is my use case Delta Sharing or is it something I could do with the SQL endpoint. Now, there is a big difference for that. Think about it like the SQL endpoint you own the compute and you just make this compute available for authenticated user.
But these authenticated user they authenticate in your workspace. So, it's a different use case. Delta Sharing is a Delta Sharing framework. You share a particular data set and the recipient you know, there is a whole authentication system for them and they can use even OIDC. Now we start support. So, there is like they use their own integrated identity provider, you know? And the recipient, and this is the most important thing, as a provider, if you use Delta Sharing, you don't pay for the compute.
They pay for their own compute. While with SQL endpoint, it's on you to make that compute available for them. So, my point here, you know, and the other part also in term of performance, because the SQL endpoint, they are running like SQL queries on Delta, you know? So, while with Delta Sharing, Delta Sharing is performant, but it will never be as performant as the SQL endpoint, because it's just different framework.
You don't get access to a lot of the like the Delta uh you know, engine that's kind of under capability that we need uh provided. So, the typical use case, external data sharing across organization, open sharing across cloud. Where while here, you know, SQL endpoint, it's it's mostly like serving internal BI user, fast interactive uh SQL analytics dashboarding. So, you really need to distinguish and think between these two use cases when you can, you know, build your data sharing strategy.
Uh The cost is a big deal. As I mentioned, as a provider, you pay for everything with a SQL endpoint. While here, if you are sharing with external user, depend on your deal, mo- uh they will be really paying for their own uh data. For their own compute. Now, this is kind of an easy one, really, how to distinguish between this is a Delta Sharing versus a Clear Room. I often get the question, "Hey, I shared this table, but I want to prevent the user from persisting the data.
The simple answer, no. You cannot do. Because Delta sharing, they could just say create table as select star from that table and boom, they persist the data. They can even create a materialized view. And so, if that's really your case, then you need to think, okay, well, I don't really trust this collaborator with the underlying data. So, I need to figure out like, okay, let's just discuss the use case, and then the clean room is a better fit for this.
Like, uh I work with a client. They said, "Look, we have a lot of They are an auto company, large auto company. Like, hey, you know, we have to this telemetric data. We have partners who want to train their AI models, but we don't want to share the data with them." So, they can train this in a clean room, bring their model, they you know, they train it, and then then the model is available for the auto company and other to use.
So, these are the use cases that you can start thinking of, you know, when talking about uh clean room. Clean rooms also, they have very industry-specific use cases. Like, in in media, they have a specific use cases, and other industry like a retail. So, clean room is kind of a better fit for these use cases. Now, D2D versus D2O. What's D2D? Databricks to Databricks. And Databricks to open. So, when you think about your data sharing, uh I always like, okay, well, many customers sometime they just jump D2O because the the recipient asked them, "Oh, you know, we just want this data to be shared with us.
It's just easier. You create it immediately and you know, I will just use a Python connector and download the data. However, this customer, they could be also on Databricks. So, if you can really do Databricks to Databricks, it's just like the performance, you know, will be better. It is better native experience. The governance is also integrated with UC. So, even in the recipient side, once they get the data, they can enforce their governance policies.
So, they can have this data internally decide who get access to it. While with D2O, it's kind of like they get the data. Anyone even can use the if they don't have if they are not using the IDC, anyone with the credential file can get access to this data. So, it's just a different experience. So, really think about it and try to figure out like okay, well, with this client, it makes sense like D2D versus D2 uh 2O. Now, yeah, go ahead.
Uh on the previous slide, um can the recipient or the provider be an on-prem database? With D2O, yes. Yeah, they can be because they can be anywhere the O. Mhm. Like you can run Python on a prem, but you need to have the network path Okay. clear to get access to the data. And that's actually a common use case cuz the O the open or other, they can be anywhere. Yeah, because we are our own print database or or the platform is Hadoop-based.
Yeah, so that the recipient can be anywhere. If they want to do like uh the provider also be on prem, usually open source work better. Like you could just use open source Delta Sharing because you are sharing internally. So, why would you need to go through Databricks? Unless you want to share with Databricks directly. Correct. Good question. Thank you. Yes. Yeah. Now, sharing ver- versus Now, this is a good a question.
When you do D2O, remember my first statement, with Delta Sharing the provider doesn't pay for the compute, the recipient. So, with all, like let's just assume I'm using uh Python connector. Python connector mean a library, right? So, where do you run that? You run it on a VM if it's in the cloud. You run it on your map. Right? So, that's really your compute. No. You are accessing the physical storage of the table of the data, then it's the compute in your side.
Yeah, that's kind one of the really uh big things I always clarify with client. Okay? Good. Now, Lakehouse Federation, I think many of you maybe familiar with Lakehouse Federation. It's really the client accessing their data in other system. Now, Delta Sharing is is kind like, okay, uh it it with Lakehouse Federation it's it's a different use case because with Delta Sharing the data has to be, you know, in Delta format.
It It also you have to use Can you see, but there is a comparison, you know, with Lakehouse Federation you most likely you access the data you ingest it the computer is also on the external uh system unless you are running it as part of a pipeline. But the authentication the use cases it's kind of like, you know, the compute with Delta Sharing as I mentioned it's really on the recipient side versus the external system.
Uh As as I mentioned, you know, the other part with Lakehouse Federation the org they're accessing their own data. You know, so while here with Delta Sharing if you are, you know, doing ex- external sharing you allowing a partner to access your own data. So you want this framework that enable you to to do that. That just kind, you know, I know it's kind of uh a simple use case, but it help you to clarify that. Yeah, it's live access, but you can also ingest it if you are running as part of the pipeline that require ingesting the data and Databricks side.
But it's live access, you are right. Good. Okay, in the interest of time we will allow enough Q&A, so we will move to the next part which is securing Delta Sharing and the great demos that my colleague prepared. Thank you, Bilal. Okay, so let's go inside inside Delta Sharing and understand also how data sharing works. So, first, let's just understand the security and functional flow of data sharing. Basically, when you share a data table using data sharing to a recipient, the data the data consumer wants to access that using data sharing.
So, let's assume that the consumer want to access that using Databricks or within with another compute. In that case, he will run a first table he will run just a first query against his table. So, when running this this query against the table, it will send a request to the control plane of the data provider in order to say, "Okay, I want to access and run select star on this specific shared table." Then, Unity Catalog and data sharing of the data provider will first authenticate the consumer, meaning that he needs to fetch first if the recipient is the right one, if he's authenticated, and also authorize it, meaning if he has the right to access to the specific table.
After that, um um the Delta Sharing server returns a temporary read access to the table root directory uh for an efficient query processing using a cloud token. It can be also a pre-signed URL, but basically right now, the standard is to use a cloud token. And also, it logs all the activities uh within the audit tables that can be then be uh seen within the system tables. After that, we just have the reply from the control plane, meaning that the Delta Sharing server will send back to the user to the recipient a token in order then to access it directly.
And the most important thing is that when you use Delta Sharing uh you need just to have direct access in terms of networking between the data recipient and the data directly. So, if you want your data recipient to access the data, he will have his short-lived token and then he should access that directly in terms of network path to access to the data in the right uh storage. It means it can be within an S3 bucket, ADLS, or anything else.
In terms of security, how do we secure Delta Sharing? What are the different security controls that we have within Delta Sharing? And also what kind of configuration we can have in place in order to achieve security. So, as I said, when a data consumer want to access to a table, the first part is that he is querying the table. And in that case, he will inherit all the uh properties that are in place within the control plane.
So, in that case, we will first authenticate the user, authorize the user using Delta Sharing and the Unity Catalog server. Then, second thing is that we have the possibility, me as a data provider, for example, to revocated the share at any time. Meaning that when I revocated the share at any time from the user, the user won't be able to access to live data at all. And that's also a good way to make sure that when I want to give short-lived access to a specific user, to some specific data, I can give him access to my to my uh to my table and then revocated it if I want.
Third thing that is really important is that when you want to access to data, it will also to the shared table, it will inherit all the properties that you have already in place between the Databricks compute or any other compute and the control plane of the recipient. So, again, if you want to secure the access by using, for example, what we call private link within the cloud, you just have to secure that as it is using private endpoint on Azure, endpoint on AWS or GCP.
And finally, the the last thing that we need to check is the control number four, how to secure access um with cross-environment data access. And in that case, we have different way to implement that according to the to the specific use case of the user. Let's assume that, for example, my user want to access some table in a cross-region format. In that case, he will be implementing VPC endpoint or private endpoint in order to access that.
If he wants to access that in a cross- cloud way, in that case, he should he can follow private endpoint private link path by implementing some mechanism with VPN, with direct connect link, with ExpressRoute on Azure in order then to link all the path between the consumer and the data access. Let's focus right now on how Delta Sharing is generating short-lived access to data. So, first, um when you use Delta Sharing open-source framework, it used what we call pre-signed URLs.
So, basically, pre-signed URLs are just short-lived URLs that are generated by your cloud providers, AWS, Azure, GCP, in order to give temporary access to data to any other recipient. It's signed by an an identity, meaning that when you want to access to some data using a pre-signed URL, it will assume an IAM role in order to access the data. And this is something that is automatically handled by Databricks and by the control plane in order to generate short-lived pre-signed URLs, might be by default 1 hour lifetime, and it's also signed by credential configured by Unity Catalog to access that.
Meaning that when you give a pre-signed URL using Delta Sharing Server, it will be something that will guarantee the unity of the provider and make sure that only this provider can use it. Right now, you have also the possibility to use that in with the second configuration um in another way called cloud token. Basically, cloud tokens are exactly the same mechanism that we implement within Unity Catalog. And in that case, we just regenerate short-lived token in order to access the data.
So, it can be Delta tables, it can be just tables within Databricks, it can be volumes, it can be machine learning model, etc. , etc. But it just generates scoped cloud IAM tokens to provide secure and temporary access to the tables. Basically, when you use cloud token, it improves also the performance, and that's why also we are suggesting right now to use cloud tokens instead of pre-signed URLs to make sure that the performance is improved as we give some other information like history and Delta logs within cloud token configuration in order to improve the capacity of Delta Sharing to handle big data.
And finally, it's enabled for sharing within the same account on a on Azure, AWS, or GCP. It will be soon also enabled for other use cases. Yeah, so when you use cloud tokens, these cloud tokens are generated, for example, on AWS using the STS service. So, it generate a short-lived token that is only tied to your use case, and then is just after not usable at all. So, that's why we are also suggesting to use cloud token because this cloud token has a fine-grained access and only limited access in terms of duration to the data.
Yeah, it live only for 1 hour, the cloud token. Yeah, so So, this is really the internal how it works, but also cloud token, this is generated by also leverage from the cloud provider live limited scope, but the system knows when to generate a new one, you know, and things like that. No, no, that's separate thing. I know you're talking about the path, the personal access token. This is totally separate. Yes. I mean, when when you use Delta Sharing, you share some Databricks assets.
So, in that case, the recipient is able to do whatever he wants with the with the with the data that is shared to him. But, the reason the provider is still able to monitor that by using system tables, and that's what I said just within within this this diagram is that when you provide and you query some data as a recipient, you have then the possibility as a provider to monitor all the queries that has been done by the consumer and also manage the share that you are providing to the recipient in order to make sure that he's using it in the right way.
So, using the system tables, you still have the possibility to monitor that. Yeah, yeah, you brought also a good point. You said like impacting the cluster. Remember, the cluster on the recipient's side. So, he's not overloading anyone. They get access. This is you see this diagram. Yeah. So, if you see the box here, this is the data plane on the recipient's side. The data plane has access to the storage. To the provider's storage.
So, the compute is on the recipient's side. This is actually a great feature. This is how Delta Sharing is scaled. So, you are not overloading the provider with I mean, the only thing will be like if it is the same storage and it's the storage account, you know, on the but that doesn't really happen. But, you do have as you see on the right side, the data consumer, they own the compute. So, if they run if they like they don't they didn't use the right capacity for the query, that's on them.
So, they are not impacting the provider. But, that will happen on the SQL endpoint. The SQL endpoint, that's on the provider's side. So, if they are running, you know, different queries, just the provider I to make sure that the capacity they approve. But also now it's kind also with serverless, it scale uh like the scale is managed self-managed by the service itself. The SQL endpoint, yeah, they can dedicate compute.
They should actually get compute on it. But that's on the provider side. It's not really Delta Share. And ask because if the session is being recorded, they'll never hear your question, right? So, yeah, if you have a question, please come to the I have a question. You mentioned uh you know, using Delta Sharing you will still be able to capture the queries that are getting fired on the shared data. Is it only if it is shared within the org or outside org also?
So, external Delta Sharing. So, if I'm doing if I'm sharing my data with an other another org, you know, using a service principle, will I be able to capture their metadata, like who all are firing the query and what queries are they firing? Even though they're not using our compute, right? Yeah, yeah, you capture because you see the queries that's happening. Even the usernames? Because it's live sharing. It's on the you know, so you will capture the query.
And if you look at the metadata, like many customers they created dashboard, they call it like data sharing consumption dashboard. So, they know what type of query and who fired these queries. Okay. Yeah, so there is a a great and that's actually this is why we recommend manage Delta Sharing if that's really your requirement because you cannot we are able to see their organization, you know, email IDs of the people who are using that.
It depends. If you are using G2O, for example, in that case you have multiple way to do that. You can provide to him a file with authentication file to do that and in that case you will be able to see the authentication file ID to that. If you are providing what we call token federation and we will check that just after, in that case it will be the ID of the user within the IDP. So, it depends also on what you configure, but yeah, you are always able to see the identity that is requesting the data using Delta Sharing.
Maybe we will just proceed and then we allow because we still have a great deal of Yeah, and then we will Sorry about that. And then we will allow plenty of time for Q&A. Yeah, we have plenty of time by the way for Q&A. Let's move into the fun part. We have four demos. Again, we have the live demo effect, so please forgive me if we have some some issue with that, but again, we will try to deep dive again into Delta Sharing and see multiple use cases in which we can use in a real world scenario real Delta Sharing.
So, let's focus right now into a first scenario. This scenario is what we call enterprise internal sharing or geo-distributed internal sharing for enterprise. Let's assume that right now I'm in I'm working in in a large enterprise shared analytics enterprise that data is originating from AWS EU West 1. And I want to share this data into another entity within my organization based in AWS EU Central 1. The consumer can consume this data using Databricks Serverless, Databricks Standard Compute, or by using any any other third-party tool.
In that case, it can be for example Power BI. Let's understand how it works. And as I said just before, the network flow will still will the same. So, the logical flow will still be like, I'm a user, I want to access to data, I will query the table, the control plane uh the of the data consumer will query the table to the control plane of the data provider. With Unity Catalog and Delta Sharing Server, it will first authenticate the user, authorize the user, log the activity, send back a token to the user, the data consumer, and then the data consumer should consume directly the data from the root uh storage of this data, basically S3 buckets, ADLS, etc. , etc.
And the main point of our session, so I mean, if you understand this main point, you can just leave the room after, is that when you want to access the data, the most important thing in terms of network and security is that the consumer should have access direct access to the data in terms of network part. What do I mean by that? Is that for example, if I want to access to data by using standard compute within Databricks workspace, in that case on AWS, for example, I will need in that case to have a a VPC endpoint interface, for example, in order to access endpoint directly to the data within the blob within the S3 bucket on AWS US 1.
So, network flow is the the same. Basically, I query the data, the data is then sent to the control plane uh to my control plane. Communication between control plane of the provider and the recipient, this communication is encrypted with TLS 1. 2 and with mutual TLS certificate validation to do that. And finally, metadata exchange and the compute plane will access to the data with direct access with short-lived token.
Basically, in order to access to in a cross region way uh with standard compute on Databricks to some data, the most efficient way is to uh implement private link access by using VPC endpoint S3 VPC endpoint interface. So, in that case, the provider should create a VPC endpoint interface uh pointing into uh the EU West 1 region on AWS in order then to access to the S3 bucket that is based, for example, in EU West 1. The data provider have also the possibility, it's not mandatory, it can be optional, but it's also a good practice to specify what we call S3 bucket endpoint policies also to whitelist only the consumer that can access to my data.
And that's also the goal of my test right now. So, I will go into my workspace. So, if you if I go here into my workspaces, I have two workspaces, one workspace in EU West 1, one workspace in EU Central 1. EU West 1 will be the data provider, EU Central 1 will be the data consumer. And as you see here, if I go into my workspace, I will try to go into my first workspace here, which is the one in EU West 1 and create uh a share.
So, in order to do that, that's easy. I just need to click first into catalog um and then click into into the top right uh button called data sharing. After that, I have the possibility to uh create a share. So, in order to do that, I just need to click into shared by me and click into share data. To do that, I just have to specify first a share name. So, for example, my share will be uh called Dice Security Share. I can specify which kind of table I want to share.
So in that case, I have a catalog here called airline prod and I want to share a specific table that contains all the airline data that I want to specify to my other business unit in EU Central one. So I just have to choose it. I have the possibility to also choose if I want to share that with history or without history. So if I share that without history, it will use pre-signed URLs. If I use with history, it will use cloud tokens.
After configurating that, I also have the possibility to specify some notebooks and as said, that's also a good practice to specify some notebooks data if I have a big share in order to give the possibility to the recipient to understand also the data that I want to share. In my case, I won't do that. And finally, I just have to specify the recipient. So the recipient here will be a new recipient. So I just have to specify the name of my new recipient.
In that case, it will be uh dice EU Central one workspace. We have the possibility to share that in a two-way. If I specify the recipient type as databricks, it will be D2D, databricks to databricks sharing. If I do that with D2O and specify click here into open, it will be D2O, databricks to other sharing. And in that case, I can specify anything else. We will come back to this uh scenario, but I will stay right now in D2D as I'm sharing data from one workspace in US one to one other workspace EU Central one.
And I just have then to specify the sharing identifier, meaning the identifier of the data consumer. So in order to check it, I need to go into the workspace of my consumer and ask my consumer to have this sharing identifier. So the consumer has to click here into catalog, click uh in the top left of the page into Delta Sharing, and then the sharing identifier is here in the top right of the page, and he can copy it.
The share The sharing identifier can also be changed. So, here if you click into add organization name, you have also the possibility to set uh a user-friendly identifier if you want. So, I click here into copy sharing identifier. I specify here the sharing identifier. Yep. And I create the recipient. And automatically the recipient is creating for me. Here it is, dice EU central one as authentication by Databricks, and I click into share the data.
Then, the share is in place. If I come back again into my EU central one workspace, the recipient side, I have the possibility here to see that the share has been created. This is this one from EU west one. And I can see also that my share is here. So, I can click into my share. I have the possibility to see the metadata associated to it. So, in that case, I have shared uh a table called Amadeus Airline Bronze, and I have the possibility to create a catalog on top of it.
So, I will call it as Airline Bronze. Click into create. And then a catalog is created. I can view my catalog. So, in that case, if I want to use standard compute, I will just choose uh my SQL warehouse pro. Might take some time to be up. Let's wait for it. But in that case, if the setup is good uh in terms of network configuration, I will be able to see here into the prod catalog and bronze airline bronze uh the data associated to it.
Yeah. What what do you mean exactly by system tables? We access that directly through the workspace. So, you can just click here into systems and you have the possi- Sorry? Yeah, exactly. Exactly. It's the provider. It means that all Yeah, exactly. You enable system table. And once you enable the in your workspace, you just access them like here, but you need just a compute on your side to run it, and you'll be able to access it.
So, we have the same schema for all system table across all customers. No, it doesn't use. Can we just table this after the Yeah. Yeah. Thank you. So, in terms of networking, what should I just check? Again, if I go into the AWS console, I need to check first if my compute is able to access that. And in order to check that, I need to check first the VPC associated to my workspace. So, if I go there into VPC, I can go into my VPC, check for the VPC of my workspace.
This is the VPC associated to it. And then I have the possibility to check if some resources, for example, VPC endpoint interface are created. In my case, it's not created, and I have the possibility to go into VPC endpoint interface in that case. So, I go just endpoint. Here it is. And then, create a new endpoint service. When I create a new endpoint service, I will have the ability to handle the request by using private link services on AWS on Azure Central 1 to point into the bucket on AWS side.
And in terms of security, the provider also has the possibility in AWS. So, if I go into my bucket, my root bucket of my data, uh to secure it also by using S3 endpoint policies. So, if I go into my S3 bucket, click here, and go into my bucket associated to my data, so, this one, I have the possibility here to click into permissions and specify a bucket policy. So, for this bucket policy, I can specify, for example, not this one.
Uh you this one, yeah. I can specify this VPC policy, for example, in order to specify the VPC uh source IP, meaning the IP addresses of my database workspace in order to make sure that only the standard compute IPs can access to my VPC to my uh S3 bucket again, or I have also the possibility to specify the VPC uh endpoint IDs the of the VPC uh endpoint that I have created in order to make sure that only data can be accessed through this VPC endpoint policy.
So, I can just copy it and go into my S3 bucket and paste it, and in that case, it will just uh control it. If I go back into my workspace again, I see that my SQL warehouse is up. If I refresh the page again, you will see that my SQL warehouse is able to access to the data to the sample data directly using Delta Sharing. It's coming. Is this communication on the backbone of AWS? Yeah, it's within the backbone of AWS.
Yeah, this is actually a good question. Often we get like a requirement like across region, I want, you know, this communication to be happening on the backbone of the cloud, you know, not really on the public internet. So, this is also a way to schedule that, to to configure that. So, your traffic across this region is happening on the backbone of AWS. And the same thing you can configure it on on Azure using cuz you can do the same thing like with VPC with the private link as well. private link endpoint.
Yeah, so again, it's taking some time to load all the data. I'm using a small SQL warehouse within a cross region setup, so that's why might take some time. My my table is big, so that's why it might take some time to load, but I will come back to it just after. Can you please use the mic? Yeah. Sorry. So, what about the service endpoint policies in Azure? It's the same. Basically, when you use service endpoint policy, it's like using on AWS S3 bucket policies.
So, you just have to specify the source subnets that are used in order to whitelist the subnet associated to the Databricks workspaces in order to consume the data and make sure that only this computer can access to this storage account. So, you have the possibility on Azure to specify service endpoint policies on the bucket side on the storage side also the possibility to create private endpoint to there to direct to have direct access to the data within the private link within the backbone of Azure.
Yeah. And I just want to point out this is really like if your storage point behind you have a strict requirements like around the your storage you know behind the firewall and things like that you do this configuration. It's still secure if you don't really have these requirement and you want to share internally it would just work out of the box. It's still secure and there is authentication between the two kind Databricks workspaces.
So just want to make sure this clear you but whatever your requirement is because you know with uh the network and we work with I mean we have 12,000 11,000 clients so each one has a but we have a patterns we already developed so we just easier for us to apply these patterns. Second use case, what if I use serverless compute instead of uh standard compute on AWS? Slight difference in that case the scenario will be that the compute that is within managed by Databricks within the Databricks AWS account.
So you will need to specify some other configuration on the serverless side to make sure that you can secure it. And in order to do that uh you will have first to create on AWS side what we call NCCs. So if I come back into my diagram you will see that the serverless compute is on uh is on the on the Databricks side and if you check that you have the possibility to create here what we call NCCs network configuration connectivity in order then to have a specific NAT gateway or a specific VPC endpoint in order to point directly again into the the underlying storage.
So, in order to set up that, you just have to go into the account console, create your NCC. So, I can go there into cloud resources, network, network connectivity configuration, specify the NCC that I want to create. In that case, it will be dice uh you central one NCC. Specify the region of my workspace my work my consumer workspace. So, it will be you central one. And then apply it to my workspace. So, go back to my workspace, search for my workspace, dice you central one, this one, and If I go back into my NCC, so, it's applying it.
If I go back into my NCC again, you will see that when I create an NCC, it creates for me uh this one, specific default tools. So, these default tools are the tables IPs that will be provisioned by the network configuration connectivities. Basically, uh stable Vnets, stable subnets, and stable IPs in order to whitelist them into the VPC and VP the sorry, the S3 bucket policy. So, again, I want to access my storage with the with the serverless compute.
I just have again to go into my VPC uh policy, and then specify here into the VPC into the source IP, the public IPs of my oops uh of my NCC. And then paste it into the the the S3 bucket policy and apply it. If I go back then into my uh workspace and then use the serverless compute, I have the possibility here to check that my table is available and shared. So, that is the second way to do that. Yeah. I just serverless IPs, right?
Yeah. Exactly. So, my question suppose did you whitelist that workspace endpoint as well along with serverless? Like where you are accessing that share from? Could you repeat your question? Sorry. Yeah, so you whitelisted that serverless IPs, right? Whatever they provided. But along with that, did you whitelist that workspace endpoint as well? Yeah, I I whitelist the workspace endpoint if I want to use standard compute.
And I whitelist also the serverless IP if I want to use serverless IPs. So, you have to whitelist both if you want to use both scenarios. And then we have a third scenario that can be also the same is if I want to share data to an external external consumer. In that case, for example, Power BI. I will do the demo just after, but in my case I want to use Power BI service or Power BI desktop and consume some shared data.
In that case, I have the possibility to create on my AWS account, for example, self-hosted Power BI gateway with the specific IP and then whitelist the subnets, the VPC, or the IPs of this data gateway in order then to access directly the data from EU West 1. So, let's assume that, for example, my Power BI instance is based in EU Central 1. I want to access data with Power BI in US one in a private way. In that case, I create a self-hosted Power BI gateway that will leverage also the same VS3 VPC endpoint interface on AWS in EU Central one in order then to access directly to the data.
And I will demo it just after with another another use case. So, let's assume right now that I am in another scenario. I I am in a geo-distributed external data sharing scenario. So, let's assume that I'm a major enterprise that want to share this data to a partner, for example, an external supplier, but by also providing some specific authentication. So, let's assume, for example, that I want to share data to consumer that is not using Databricks, but still handle the authentication by using that.
And in that case, you have the possibility to use what we call D2O, Databricks to other with authentication authentication type as OpenID Connect. So, in order to do that, I will try to set up D2O connection between EU West one and Power BI Desktop on Azure. So, I have here, for example, my VM in Azure with Power BI. I want to access to data and to be authenticated with my IDP, identity provider, which is Entra ID. How do I need to do that?
So, first, as a provider, I have to go into my share. So, I go back to my share. And then, I have the possibility to create to click here and add a new recipient. So, in that case, I click into create new recipient. I call it as Dice Open Sharing Power BI. And then, I can click into open. Two way to access that, first way to access that is by using tokens. It will generate for you files that can be used by any other consumer.
Second way to do that is to use a new feature called OIDC Federation token Federation in order to handle all the tokens with your own identity provider. So in that case, I will use OIDC Federation. I create the new recipient. I added to my table and then I can go into my recipient again and create what we call an OIDC Federation policy. So this is the way to federate all the tokens from your identity provider. In that case, it will be Entra ID to authenticate all the users for Power BI, for example.
So I create my policy. I will call it as Power BI policy. I specify here the issuer URL. So So in that case, if it's Entra ID, it will be uh login. microsoftonline. com /tenant ID/v2 v. v2. 0. To get the tenant ID, you need to ask that to uh your Entra ID administrator and you will get it here in Entra ID. So you can click into tenant ID, copy it and go back into the issuer URL. Then you have the possibility to authenticate some specific uh identities by using OIG sub group or ASP.
In that case, I want just to provide access to some specific groups on on my Entra ID. So I click here into group and in the subject type, I specify the ID of the group that I want to authenticate. So in that case, I go into Entra ID again. I search for the group that need to access to Power BI. Here, I search for it. So, for example, my group is called dice. It's this one. Then, I click into the object ID, which is the identifier of my group.
And I specify just here. And then, I have my my policy. Sorry. And then, you put this one. I have my policy uh I have my policy that has been created in order to access uh the the with using Power BI. So, it will generate for you an OIDC profile generation in the portal, so you can copy it and share it to the recipient. The recipient will be able to access all the information that should be used uh within Power BI in order then to connect.
So, click into you to you to M uh click here into the link, and then specify directly within Power BI. So, within Power BI, I need to go into get data. Click into uh more. Specify it as Delta Sharing, so it will use the Delta Sharing connector. Sorry. Connect. And then, I just have to specify the URL associated to it. Yep. Copy. Paste. And then, click to okay. Can we share large tables with this Power BI? Sorry, could you repeat?
Can you please go into the microphone? Sorry. Can we share large tables like kind of like one 10 million or or maybe like 1 billion rows because there is a limit with Power BI? Theoretically, yes, but it really depends on your use case and it also depends on the performance. So, with Power BI, for example, you have the possibility to query your data as said using a SQL warehouse endpoint or by using Delta Sharing. So, if you want to use Delta Sharing, in that case, you have the possibility to also query large tables, but in terms of performance, you will need also to understand the SLAs associated to access to the data.
And in that case, in terms of performance, if you need the performant compute, you might also expose that through a SQL warehouse instead of Delta Sharing. Yeah. I mean, keep in mind, this maybe with Delta Sharing, this is your recipient who could be your partner accessing the data with Power BI. With endpoint, it could be your own company, but it's still the network traffic if they are cross region. That's kind like of uh of a good delay.
Speed up things. What's that? I'm sorry. Uh the support for predicate push down on uh the SQL endpoint versus Delta Sharing, you mean? Uh okay. In terms of networking, if I'm using if I I'm pushing the report through Power BI service, in that case, it will leverage my data gateway that is hosted within AWS. If I want to access that directly from Azure or from my laptop, I will need again access direct access to the storage, which is my S3 bucket.
Uh the mic. Is there to leave for this URL? TTL? For the URL, yeah. No. So, the URL is just the URL that is pointing into the token federation server between your IDP and the server. So, in that case, the TTL is not associated to the URL associated to the token. And just you have a TTL that is associated to the tokens and is configurable within your IDP, meaning here Azure AD. I see. So, that can I mean, it expires after some period of time.
Exactly. Yeah, okay. Go ahead. Your turn. Yes. In the next a few slides, I mean, um I I think for both of them, maybe we spend 10 minutes is filter filter data sharing. This is really a talking about the views. So, you can share Delta table, but you can also share the views. And there are many really good use cases for views. It's a cross-platform view sharing. We just I 2 weeks ago, now we at the beginning we supported views if for serverless mostly.
And now we support them actually also if you use a standard uh cluster and also with open. So, you can use views and dynamic views to do that. Uh it enable I mean, the biggest really benefit is the dynamic filtering for each recipient. And then the next example as you see here, so you will have tables, the views, they could If you're familiar with SQL views, it's a great way to kind bring data from multiple tables together.
You can The recipient can be on Databricks or they can be other. Now, this is a good example. Uh so, if you all what you really need to if if you if you have to just assume sales data and you want to uh have the sales data uh secured by country the access to it and you have a cross recipient. So, excuse me. So, you have two options. You can create separate table and share them, which is a lot of work for you, or you can create a view and you specify like for each recipient you specify the properties as you see here country equals CA.
That's Canada, not California, by the way. So, so they can access this data. So, when the recipient and then when you create the view, you specify use the function current recipient and you specify the property country. So, when when the recipient who has a property Canada, they query that the view, they only see the data that associated that's relevant to them. That's kind of smart way to have what, you know, can use in SQL, some sort of like horizontal uh partitioning or horizontal filtering of the data.
So, this is one way. We are working also on supporting, I know one of question we often get like, "Okay, well, uh what about like uh the the function when you also have security on the on the column?" And uh because currently Delta Sharing doesn't support it. But I think you really need to use the the use case. You use with Delta Sharing you sharing data with external users and this is meant for the same table. You want to share it with a across multiple recipients where each recipient can access subset of the data.
So, this is a good use case for that. Now, the other way also, if you actually have you know the other property, like you can also use for the columns. As an example, you see here, we when we have the tier property. So, there is a paid or not paid. So, you can use like redacted, so they will not see so that column. So, this is a good way also to do some vertical filtering where some of the columns will not be uh appear.
They have specific as I mean use cases. If that's really your your ca that's really your use case, then you can Now, of course, you can view the best use case if you have data from three or four tables, and you just want to share the view with your customer without using the current user, you can still do that as well. But, views are supported uh across uh platform uh as well. Now, the last part which I'm can going to talk about clean room.
Here, I I just want to more focus, you know, on the security aspect, you know, of clean room on the use cases for them. It The clean rooms, they collabo they enable collaboration on sensitive data without compromising privacy. You don't share the underlying data with your customer. You know, you share it kind like so they can you can unblock specific use cases. Uh the In term of like security and the internal uh clean room, they provide like it's really a nice uh isolated runtime environment.
Also, with a clean room, the code has to be mutually approved. You and the collaborator Uh one thing also about clean room, there is no provider and recipient. There is collaborators and we support multi multi collaborators. Often there are only two or three collaborators, but you can have more. But they collaborate mutually approve code and use cases. It also prevent direct access to the other party data. That's kind like really the use case for this and it built on secure foundation.
So in a clean room, as you see, you have party one or collaborator one, party two they share data, they share notebooks. Uh in in in a in a clean room one thing I want to point out, clean room, they run on a serverless environment. So you inherited the serverless security capabilities, the strong capabilities in that environment. And data is being shared as you see in this slide, it's shared is through Delta Sharing, so with Unity Catalog.
So this is why clean room it's important, as I mentioned at the beginning of this presentation, you understand how Delta Sharing work and also we we have a slide about uh the serverless. Now, privacy through code approval. So when you share data in a clean room yes, they can say the other collaborator, they can't say, "Oh yeah, they share with me their own sales data." But when they click on it, they only see the metadata.
They cannot really see the actual data. And that's kind like different than the concept of uh Delta Sharing. Uh input data is temporarily accessible to the mutually approved code. When when you run that serverless job, it temporarily accesses data through Delta sharing, run the notebook, generate an an outcome that need approval, and then it can be shared with the other collaborator. So, and the data access and changes are needed locked.
So, this is kind to drive a transparency. You cannot run your own code, of course, because you could use your own code to, you know, display the data and things like that. So, it has to be approved by the other uh collaborator. Uh each clean room is dedicated and isolated. And I will come to kind some of the uh uh features in the private preview also to meet some of the requirements. Usually, like the for a clean room, we have more strict requirement.
Even some customer, they want a clean room to access the data uh or through private link, you know, endpoint and things like that. So, we support these use cases uh as well. Uh Uh the approval process, like it's implicit code approval. If you run if party one run the code of party two, that consider an implicit approval, but there is also an approval process. If if you change the code, if any of the party change the code, then it has to get pre-approved again.
Code, usually, it's run through just mainly notebook. So, every If you make a change, that's a new notebook, really, a new version of a notebook. So, it need that approval. This is slide mainly, if you look at it, it's really about talk about Delta sharing and how the data is being shared with the clean room. We already discussed this, and we already discussed kind of like a cloud token because this is running in Databricks isolated environment.
And one thing I I want to say like when you run the code in in a clean room, no one is administrator on that environment because you want you want that. It's managed by Databricks and then the outcome is generated and uh approved. So, no data is accessible unless you publish it. An approved code cannot access your data. And there's of course enough audit and governance in place. Manage egress via approval. So, uh the approval step allow you to review the code always, you know, for outbound data push.
Which mean really like if someone has display or select star from your table, you should be able uh to catch that. We also have a network policy for serverless egress control cuz often we get a requirement like, "Okay, in my clean room, I don't want to even allow internet access." Uh sometimes it's really difficult because some of them a library require downloading, you know, if you use NLTK, which is kind of an old library, I'm just using this as an example, it downloads some stuff, but they want to also prevent any internet access.
So, we have this as kind, you know, an off on off type of uh capability or feature. This is kind of give you like these are mostly really the serverless services capability because as I mentioned again, clean room run on a serverless environment, serverless. So, it inherited these capabilities. We're familiar with these issues. And these are actually also the clean room. So, the workload, there is no cross workload communication.
Why? Because it runs on serverless. This is kind of like also the security features of serverless. It run on dedicated compute once that's, you know, finished. It's kind of clean up and so it's not reassign or return to the pool. There is also verified by an independent third party and tested by Databricks. So, that's kind of give you really a good idea about I'm hoping like you walk out with from this session with good knowledge and understanding like level 200, you know, of this so you'll be able to use Delta Sharing.
As I mentioned, you know, my role is really to work with clients. Feel free through your account team to reach out to you. I'll be more than happy. I work with hundreds of our clients each year to help them leverage the product. Yeah, go ahead. Same here. So, we will use the I think we have 6 minutes to Q&A. Thank you. Thank you. Thank you so much. Thank you.

Learn more about the Databricks Data and AI platform.