Tracking Data and AI Lineage: Ensuring Transparency and Compliance

Summary

• Data Lineage Importance: Lineage tracking is essential for compliance, data discovery, and impact analysis in modern data platforms.
• AI Lineage Integration: Tracking lineage through model training, evaluation, and inference phases ensures transparency in ML development workflows.
• Governance and Usage Insights: Lineage system tables enable impact analysis, usage insights, and end-to-end visibility of data and AI assets.

Tracking Data and AI Lineage: Ensuring Transparency and Compliance

Talk by Murt Neemuchwala, Product Manager, Databricks ; Prithvi Kannan, SWE, Databricks
As AI becomes more deeply integrated into data platforms, understanding where data comes from — and where it goes — is essential for ensuring transparency, compliance and trust. In this video, we’ll explore the newest advancements in data and AI lineage across the Databricks Platform, including during model training, evaluation and inference. You’ll also learn how lineage system tables can be used for impact analysis and to gain usage insights across your data estate. We’ll cover newly released capabilities — such as Bring Your Own Lineage — that enable an end-to-end view of your data and AI assets in Unity Catalog. Plus, get a sneak peek at what’s coming next on the lineage roadmap!
Here’s more to explore:
Unified and open governance for data and AI: https://www.databricks.com/product/unity-catalog
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

FAQs

Why is data lineage important?

Data lineage is important for three main uses: compliance (tracking where data comes from and where it flows), data discovery (understanding data context and trust signals), and impact analysis (tracking the effects of pipeline failures or data quality issues).

What is Unity Catalog's role in lineage?

Unity Catalog provides lineage capabilities that help track data spread down to the field level, especially for sensitive information and PII protection.

What new capabilities are being released?

The video highlights newly released capabilities like Bring Your Own Lineage, which enables an end-to-end view of data and AI assets in Unity Catalog.

How does lineage apply to AI workflows?

Lineage for AI tracks data movement through model training, evaluation, and inference phases to ensure transparency and compliance in ML development workflows.

Full transcript

All right, welcome everyone. Thanks for joining our session today on tracking data and AI lineage to ensure transparency and compliance within your organization. Um, your speakers for today, you have me. Uh. I'm a product manager here on our Unity catalog team. Uh, I look after lineage and access control. Um, and with me I have Pritzby. Uh Prince is an engineer on our machine learning team here. Um and we'll be talking about data and AI.
Awesome. Before we get started, just standard disclaimer. Uh the features that we talk about today may change slightly in nature before they hit your laptops. All right. So, we have a packed agenda today. Um we'll start out by giving you a quick overview of Lineage and Unity catalog. We'll then dive into our road map and upcoming launches that we're super excited about. Then we'll be talking a little bit about lineage for AI and how we're thinking about the importance of lineage in ML development workflows.
And then we'll talk a little bit about our lineage system tables uh to get additional insights u in data bricks. And as always, we'll be doing a bunch of live demos hopefully. So um uh looking forward to that. All right. So uh before we dive into lineage and unity catalog uh just want to talk about why data lineage is important and how we see it uh within data bricks. So we think data lineage is really important for three main uses.
The first is probably the one you'all are most familiar with which is compliance. So whenever an auditor comes and asks you uh where did this data come from and where has it flown in your organization, Lineage helps you kind of track this spread of data down to the field level and see especially when it comes to sensitive information where potential sensitive data or PII may have entered into various uh data assets. The second piece that we think lineage is really really useful for is for data discovery.
So lineage can be a tool where users can understand the context of their data, find which upstream sources it came from, uh where it's being consumed downstream in uh production dashboards and other people's queries which are all gives trust signals for users looking to use a particular data set for their analytics or data science use cases. And the third piece which we think lineage is super important for is for impact analysis.
So, anytime you have uh pipeline failures upstream, uh data quality issues, um things like deprecations, uh you want to be able to track that impact all the way downstream, not just in derived data sets, but also in queries, notebooks, dashboards that users may have set up on top of your uh tables. And so, we think the you can kind of track the impact of these failures downstream. And then similarly helps you do kind of root cause analysis. you may have a data quality issue downstream which was uh propagated from some stale or uh incomplete data upstream.
So these are kind of the three main pillars of why we think data lineage is super important. So a quick overview of data lineage in Unity catalog. Three things you need to know. Number one, um it's autocaptured at runtime um down to the column level and for all your read and write events against Unity catalog enabled compute. So um as long as you're using a UC cluster, anytime you do any kind of operation which reads a table, writes to a table, we'll be capturing that uh automatically.
Number two, we support queries in all languages. So not just SQL but if you're doing things in Python, R or Scola, uh we automatically capture for all those queries at runtime. And then lastly, we think this is the most important bit about lineage in Unity catalog. It's not just for your data assets, but also for your AI assets. So traditionally, most other um lineage services kind of have your typical tables and show you relationships between tables, views, and then the workflows that generated them.
We're really proud about lineage at Unity catalog where it covers all your AI assets. So things like um volumes where you would store unstructured data. Um then also for models. So if you're training them, doing inference of them downstream uh we capture all of those things which we'll talk a little bit more about a little bit later. and also all your kind of non-UC governed assets that may live in your workspace. Things like dashboards, workflows, notebooks, all of these kind of are captured within our lineage uh capability.
And then we're also including federated sources. So if you're federating from other database management systems, um we show this lineage downstream in Unity as well. And so you can see a lineage graph here and it kind of shows all the various types of assets, tables, volumes, models, dashboards, views, u federated assets uh in this lineage view. And you'll notice there's some external data assets also as part of this, which we'll talk a little bit more about with our bring your own lineage feature later in this talk.
All right, so what's new? Um, one of the things we're super excited about is data quality monitoring. So this is a feature that's now in beta. So you can find it um uh in your workspace already. And data quality monitoring essentially what we do is we will uh scan your all your tables once you enable it at the schema level for freshness and completeness and we kind of propagate this little dot icon everywhere in your catalog explorer and in your uh various data brick surfaces which gives you an indication on what the health of this table is.
This is super important when it comes to lineage because um we're coming soon is data quality monitoring being integrated with our lineage service. So you can kind of get a view of where quality issues occurred upstream. So for example, if you've enabled data quality monitoring and a pipeline um doesn't completely run and now you have incomplete data, you can go into your lineage graph, find a quality issue, find which upstream uh data source had this problem and then figure out what the downstream impact of this will be.
So we're super excited about data quality monitoring coming soon in lineage uh to power root cause and impact analysis in Unity Catalog. So we we talk a lot about lineage within data bricks and within within unity catalog but we obviously understand the flow of your data doesn't stop doesn't start or stop in data bricks. So you may have data being ingested from upstream sources, ERPs, CRM, operational databases, uh maybe some CFKA streams.
Um and then this data comes into your bronze layer and then as ETL and then eventually it may be consumed even outside of data bricks in external tools. So think BI tools like looker, Tableau, PowerBI or in uh you know downstream custom apps where you're querying this data. And one of the things we want to really make it easy for you to do is have that full source of truth for how your data is flowing in your organizations all within Unity Catalog.
So we're super excited to tell you about bring your own lineage which is a feature that's coming into public preview uh later this month. And there's basically two main use cases that we see for it. Um one is you can kind of annotate what your upstream first mile lineage as we call it. Um, so prior to data entering your bronze layer, where it came from, uh, you'll be able to kind of add in this metadata um, on potentially it hopped through multiple source systems, maybe it went to a cloud provider where you were doing some kind of ETL and then it came into UC.
Um, and then similarly on the last mile side of things, um, we know a lot of you kind of consume your Unity catalog data in your dashboarding or reporting tool of your choice. We want to make it really easy to add in this additional last mile context into UC lineage. So that way whenever your uh users go into the lineage graph, they can see that potential, you know, if they make a schema change to a table, it could break some downstream report that's uh outside of data bricks.
And so um we make this super easy. And uh I'm going to do a quick demo on how we uh how bring your own lineage will work in data bricks. So, I'm going to switch over to my data bricks workspace here and um so I'm in the catalog explorer here and um kind of there's two steps to adding uh custom lineage within Unity catalog. Uh the first is we've introduced a new type of securable in UC to hold metadata specifically to be used in custom lineage.
So when I navigate to the external data tab, there's a new uh subtab called external metadata. Um so external metadata objects are essentially uh a way to represent uh things like tables, dashboards, reports and external systems within Unity catalog and you can add in uh certain metadata for these assets. So uh you can give it a name, select the system type of this asset, u the entity type, whether it's dashboard, table, etc.
Uh descriptions, you can specify the uh columns that are present in that object. any other additional properties. And once you've created this um let me go to an example one. So I have a external metadata object that represents a Salesforce accounts object. Um and once I've defined this in Unity catalog, I can create a lineage relationship uh based on it. So I'm going to create a custom lineage relationship where I'm saying the Salesforce object is upstream of one of my uh sales data sets.
And then I can even do kind of column level lineage specifications to show like which fields map to which things. So um whenever my consumers go into lineage graph, they'll kind of see this in the same way as they would u our autocaptured lineage. I was going to put something in here. Create got some failure, but let's see if it's still showing up. And in the lineage graph, this will show up similar to the autocaptured lineage where you can kind of see here's the relationships to this table and where it's being consumed downstream.
And similarly, you can do this for not only your upstream asset types, you can specify multiple levels of upstream data sources. You can also do kind of downstreams. You see there's like a Tableau dashboard here that's based on this table. Um, and it'll have the metadata that has been added in. All right, cool. Uh, let me go back to the slideshow. And so, um, we're launching Bring Your Own Lineage in public preview later this month.
And, uh, beyond the public preview, we have some additional things that we're currently working on. So, one of the things that um we're super excited for is um you must have heard in the keynote earlier today, our GA of LakeFlow. And as part of the LakeFlow suite of products, we have our lakeflow managed connectors. And so, if you use one of our lakeflow managed connectors to ingest data from the supported data sources, we'll automatically capture this first my lineage and we'll create these external metadata objects and link them in your lineage graph. so you don't have to go back and add them in via the UI or API after the fact.
Um, we'll also be working on adding custom lineage to our system tables. So, we'll talk a little bit about our linear system tables uh later on in this talk, but um any kind of lineage that you add in through this bring your own lineage feature will also be there for uh querying programmatically. And then lastly, we're looking at our north star is to have these kind of connectors and crawlers to all the common systems that um customers have data coming from and flowing to.
Uh and so uh then you'd just be able to kind of for example if you have a bunch of Tableau dashboards that are reading from Unity catalog tables, you can just give us your uh O and we'll be able to kind of crawl your Tableau instance and make those lineage connections. And that way whenever consumers go in to look at your tables in Unity catalog, they can see here's all the downstream reports and dashboards that are depending on it.
So when you're making things like schema changes, there's data quality issues um you know kind of the full downstream impact picture uh not only in data bricks but uh in external systems as well. All right, I'll hand it over to to talk a little bit about lineage and AI development. Thanks M. Uh so yeah, there's a lot of great features in Unity Catalog for Lineage. Uh but let's talk about how we can apply these to the AI development workflows uh that we know are ever more popular today.
So the first part that's really important is what happens when you create a new model. Typically you have to do some sort of training and that involves a training data set. And so it's really important to understand what training data set is associated with one particular model version. So for example, if I took a data set and I scrubbed it heavily, then I might get very good EBAL results, but I did that because I changed the data set.
And then I can't compare that model's results with the results from a previous iteration of that model that was trained on a different version of the data set. So this is super important and Unity catalog provides this right out of the box for us. Uh, and this is one of the things we're really excited about. The next piece of the training data set that I think is really important is understanding which sensitive fields were used in the training.
Uh this is really important for auditing purposes. For example, uh a customer may be looking at uh a series of data from their customers. Uh but then customers eventually will be able to like opt out of their training data being used. Uh and then we need to know that oh customer A's training data was being used in this model. They're no longer our terms of service with them are no longer allowing us to do so. we need to be able to remove this data.
So lineage allows us the ability to see where the data came from uh if any of this data is sensitive and uh allow us to take the right action on that. The next piece that's really cool is once you take this model uh and you decide that this is ready and you want to do something with it on data bricks typically people serve their models and uh if you do model serving on data bricks uh we have endtoend lineage to show you where this model is being served.
So in many organizations they have data scientists who are pushing the models uh new versions of the models into the Unity catalog and then they have like a machine learning engineering team or a deployment team that's basically responsible for setting up some of the serving infrastructure. Uh and so if you're a new data scientist and you're going to push a new version of the model, uh you can help answer the question of which applications are serving a previous version of the model, how do you communicate that update to this team uh and let them know that you know a new version of this model has arrived.
The last piece that's really interesting is tracking model performance through lineage. Uh so we all know that basically the model is only as good as the training data. Uh but sometimes your model can have really good performance in your training data set and then really poor performance when you deploy it in front of your customers. Uh so it's really important to know as early as possible that you're in that situation and maybe revert back to a previous version or make any necessary modifications.
So lineage helps us answer this question uh through the inference table from the model serving product. Uh we'll talk a little bit more about this in the demo in a couple minutes. Uh but basically all inputs and outputs of your serving endpoint are captured into an inference table and you can run a monitoring workload on that and evaluate the same quality that you would have done in your offline evaluations for production data.
And so if you have a training a model that's predicting fraud for example and that uh in the training data set was predicting fraud at uh 1% for example but then when you deploy it into production you start predicting fraud at 10%. Uh the monitoring workload would help you identify this gap and you use lineage to see this whole endto-end process uh and understand how your model performance has diverged and then maybe you need to take action accordingly.
So this lineage is mostly autocaptured on the product. Uh so if you have upstream data sets for the model training, these are all automatically captured within data bricks. Uh as well as feature tables and functions that are used when training the model version and the downstream assets of the model uh lineage is also captured. So the serving endpoints that you're using to power this end uh to power this model uh when you're serving it in your apps as well as the inference tables and the downstream data that's being created by these models are all auto captured on the platform.
So now I'm going to jump into a demo where we're going to talk about what it means to train some of these models. So we're going to start uh in a notebook here and uh what we're going to do is we're going to work off the taxi training data set. Uh so this is a pretty classic uh machine learning problem. We're going to try to predict the taxi fair price uh given a bunch of features like the distance and the time of day.
Uh this is a public data set from the New York City taxi data set record. Um so what we're going to do is find this data set on data bricks. Um so in data bricks we put it in this catalog. I have a taxi data set here. Uh and what we're going to do is we've already annotated the upstream lineage piece. Uh so if we go ahead and open this data set here, this is my catalog broad default taxi data set which has the data and I've already annotated this as coming from this New York City gov data set.
Uh this is an external metadata first mile lineage that my colleague just presented about. Uh so once we've made this association between these two uh data sources, we can go ahead and start training our data. Uh so what I'm going to do is I'm going to first open up this data set uh my taxi data set and let's take a look at it. Um and one of the things I noticed in my data set is that uh sometimes the fair amount can be really high.
For example, uh we can't see any examples here but I did some data science earlier and I found out that there are a lot of you know really large fair amounts. Maybe there was some extraneous circumstances or sometimes the fair amount is just zero. Uh basically this this data set is not cleaned in the way that I would have expected it to be. Uh so I went ahead and created a taxi data set cleaned version and we're going to go ahead and train models on this version.
Um so my teammate might come up to me later and ask me how did you clean this data set? Uh so just to demonstrate a little bit about that process. Uh we can open the lineage graph and we can see the relationship between the taxi data set and the clean version of it. Uh it's linked by this edge here. And if you open the query that's linked, we'll see that all I did was uh uh select from the original data set uh for all the examples where the fair amount is within three standard deviations of the average.
So that's just what I did to do my data cleaning. Uh and now I'm ready to do my ML modeling. So we'll jump into a notebook. Uh and today I'm going to use MLflow. Uh we just launched MLflow 3. 0 yesterday. Uh so we'll be using the latest and greatest features from MLflow. Uh if you're interested in this more uh feel free to check out the mlflow. org page and we can learn a little bit more about how the system works. Uh but for now we'll just jump right into the code.
So I'm going to pip install mlflow. I'm going to start my session and then I'm going to train this model. Uh we'll go through the model training code very briefly. Uh basically what I'm going to do is I'm going to load the data set from Unity catalog. I'm going to go ahead and select the fields that I care about. Uh so the fair amount that's the kind of prediction value. Uh and then the inputs are trip distance, pickup zip code, drop off zip code, and time.
We're going to go ahead and use a scikitlearn linear regression model. Uh just do a really simple model. fit call. Uh and then we're going to calculate mean squared error and log this model to MLflow. When we log this model to ML flow, we're basically packaging up this model with all the weights that are trained here. And then we're going to keep all this record about this model. So we'll go ahead and run this. And while the model is training, uh the really important piece we want to show here is that the data set that this model was trained on is a clean data set.
And that we should not compare the results from the clean data set with the uh with the other data set. Okay. And uh in classic lab demo fashion, we got an error. Let me just rerun this. Input x contains nad Let me take my uh data bricks assistant suggestion. All right. Uh so my model training doesn't work today, but that's okay. I have something prepared for us. Uh so we'll just go back and take a look here. Um so in my mlflow experiments, I can see the taxi training that I did a little little while earlier.
Uh and basically you can see that there's this model that I just trained um and it was trained on this catalog prod uh taxi data set clean and we see that this model and this data set are basically linked together in this way. If you click on this go to table you'll go right back to the unity catalog table. Uh and the thing that's really interesting is that we can see that the training data is actually associated with a certain model version. uh and so we know that you know this version was trained on the on the clean data set and another version was trained on the you know the uh raw data set but let's say we like this version and we I want to go now register to unity catalog so all we have to do is type in uh mlflow. register register model and we have this model registered in Unity catalog and when you register this model Unity catalog all the training data uh and all of the lineage from the training process is automatically pushed into the lineage graph.
So let's go ahead and open the lineage graph for this model. This is version four. This is the one that I just did set up right before the demo. Uh and you can see that it was trained on the clean data set. uh and we can trace this lineage graph all the way back from the clean data set to the original data set all the way back to the NYC gov the source of all this training data. Uh so this is really neat and really important.
It provides the end to end story. Uh and let's say now I think that my model is ready to be served and you know I'm happy with the results of it. I'll go ahead to the model serving tab here and go to my taxi test uh data set and I will select version 4 to serve. And when I'm in the serving endpoint, I'm going to hook up an inference table called taxi test payload that will capture the inputs and outputs of each request.
We can go ahead and fire a request into this model and see if it works. So, we try out a certain combination of pickup uh zip code, trip distance, etc. And we get a prediction $12. Let's put, you know, something large, maybe 20 miles for the distance, and we see it's going to be $60. Uh so this is really neat. We can have a model that works. Um, but let's talk about the lineage now. So when we go back to the catalog and we take a look at this model, we can now see that the inference table, this is the table that's going to store all the inputs and outputs for the model, now has a link back to the model itself.
So we can see that u oh sorry I clicked the wrong wrong table uh the payload table if we open the lineage tab here we will see that there's the payload table as well as the upstream model uh and you can see that for various models they all got written to the same payload table so we can compare you know uh the different results from the different models um and now we have this full end to end graph. So if we expand it all the way back, we now have from one end of the chart, we have this NYC gov data set.
We have the raw data set, the clean data set, the model and the inference table. And now if we're then notified uh maybe using the data quality monitoring uh and other techniques that you know our prod data has been compromised or that our prod data is showing you know poor model drift. uh then we know basically where the source of this is and we can go back up the chain and trace the origin of this data. So the last piece I think is really neat here is uh you can build really rich visualizations over the payload data.
So maybe I have uh some like my my executives are interested in how much usage is going through my AI system. Uh you know that's the talk of AI nowadays. People are making a lot of demos but how many of them are actually making it to production? how many customers are actually using them. So maybe I will create a PowerBI visualization for my executive and let's go ahead and show like let's pretend that I already made this associate this visualization and let's just link it into the payload table.
Uh so we can go back to the catalog uh and go to the external data and let me go ahead and associate uh this account insights report with our inference table. So we will say that this is an upstream relationship with the table and this is the payload table and I'll go ahead and say select and now when we open the lineage graph we can see that actually we have this end result like Tableau dashboard that we can show to our executives which is using this payload table.
Uh so all in all all in here uh basically with just a few clicks primarily autocaptured metadata we can see an end toend journey of all this model training um and it's really rich data set that's uh going to be really powerful as you move your model through production and uh eventually start to deploy out later versions of this model. Cool. All right, thanks. Um, so we're going to switch gears a little bit and talk a little bit about our lineage system tables.
Um, so we recently made these generally available. So these are available to everyone. Um, and there's three things we want to highlight about our lineage system tables. Um, so number one, uh, there's two different system tables. One for table level lineage and another for column level lineage. and um they record each read or write operation that users perform in Unity catalog in these tables. So in many ways they're kind of an audit table because it has all these records.
Um and so you can get a lot of great insights from these tables not only in lineage but other things in your data state. And the two main use cases that we've seen folks uh use these system tables for is number one to get a lot of usage insights. So because this has kind of every uh read or write operation against these UC tables and columns uh being recorded, you can kind of figure out what are the highest usage data sets in your data state.
What are the unused tables, unused columns that you may want to deprecate within a data swamp. All these uh insights can be captured through programmatically quering these uh lineage records. And the other piece that we think it's super beneficial for is for impact analysis. So, um, obviously the lineage graph is super useful for kind of navigating and seeing how things visually are related, but you may just want to kind of run a report which says, you know, we're deprecating this table.
Um, what are all the downstream derived data sets, views, uh, dashboards, queries, notebooks, who are the owners of these assets? Um, and in order to alert them for this kind of deprecation notice or maybe a schema change that will break things downstream. So you can kind of quickly get these insights through the linear system table. One of the pain points we've heard from customers is that uh they don't know kind of the types of queries that they should be running against these kind of system tables.
Um, which is why we've recently entered into private preview with a set of out-of-the-box dashboards that are powered by these lineage system tables which help you kind of address these most common use cases like doing impact analysis or getting insights into usage of specific fields from your production data sets. Um, so I'm going to go ahead and switch back over to do a quick demo actually on these dashboards. So uh the first one I'm going to focus on is this impact analysis dashboard which uh is based on our system table um which you can import today as part of our private preview.
Um, and the way this works is you can just specify a table name or a path that's been registered Unity catalog, a date range, a lineage depth, and a direction and kind of get a report that tells you here's all the downstream assets in that direction. Um, who last modified them, what's the depth of the relationship? So, not just like the first degree, but multiple degrees. Um, downstream as well. You can see what are the other like non data assets.
So things like uh notebooks or queries or dashboards that are based on these tables and see kind of the distribution of depth in those see things like the usage over time of that uh particular table you're looking at. U and what's really cool about these dashboards is they kind of get imported in your workspace as regular AIBI dashboards. So you can kind of go ahead and also see um the kinds of queries that we're running against these and you can modify these and kind of get a sense of how you should be potentially looking at querying these tables as well.
Um and so that's our impact analysis dashboard. Uh another dashboard that we have as part of these insights dashboards is around unity catalog usage. So um you may want to kind of just get high level insights into kind of what are the most used data assets and uh lineage is really good for this because the system tables record each read and write operation and so you can do things like filter by a catalog see what are the most used schemas see what are the most used tables within those.
So you can see like attributions table in our marketing. s schema is the most queried. Um you can kind of uh delineate by read operations versus write operations on tables. Uh date ranges for when these operations are run, which you know users or service principles are running these operations. Um and then based on that you can get like insights around how many you know high usage tables you have in your data state or how many unused tables.
So tables that are uh being written to but don't have any read operations downstream of them. And so you can kind of consider deprecating those assets or contacting those uh data owners of those to let them know that u you know there's a potential uh data swamp issue. And then similarly with your mostus tables you can kind of track down uh are these being uh is there good metadata around it? Are they discoverable for users?
Things like that as well. Um so a lot of great usage insights that we think folks can get from these system tables. Um and these out of the box dashboards uh similarly allow you to kind of see the kinds of queries that um you can run against them and then modify them and get inspiration to run kind of your own uh kind of analytics on top of them. All right, so um we're just wrapping up here. So uh a few things to take away.
We talked about a lot of different things in this talk. uh three key things that if uh to summarize number one lineage and unity catalog covers all your data and AI assets uh it's auto captured at runtime and all that will populate in your lineage graph and also in your system tables for programmatic access number two our new bring your own lineage capability that we launch that we are launching into public preview uh later this month uh will allow you to make Unity catalog the source of truth for uh endto-end data flows in your organization so through the new external internal metadata object in UC.
You can kind of catalog external objects and external systems and use those to add custom lineage. And then number three, we think the linear system tables are super super powerful um and should be leveraged for getting additional insights around usage, lack of usage and then doing things like impact analysis to report on uh changes like uh deprecations and uh quality issues. All right. Uh before you head out, uh don't forget to complete your survey to give us feedback on the summit.
And you can scan this QR code to continue your learning journey with all the different trainings and certifications that we have at Summit. Thank you everyone.

Learn more about the Databricks Data and AI platform.