Schiphol Group’s Transformation to Unity Catalog

Summary

• Europe's Largest Airport Transformation: Schiphol Group, Europe's third-busiest airport, elevated its data operations by transitioning from standard Databricks setup to Unity Catalog's advanced governance capabilities.
• Seamless Large-Scale Migration: The migration spanned hundreds of workspaces with continuous availability, requiring strategic planning, governance frameworks, and safeguarding data integrity.
• Practical Migration Lessons: This video shares hands-on experience, proven migration methods, and practical insights for complex, rapidly-evolving organizations transitioning to Unity Catalog governance.

Schiphol Group’s Transformation to Unity Catalog

Talk by Jelle Katsman, Senior Product Manager Data Platform, Royal Schiphol Group ; Shasidhar Eranti, Manager, Field Engineering, Databricks ; Suvadeep Sinha, Solutions Architect, Databricks
Discover how Europe’s third-busiest airport, Schiphol Group, is elevating its data operations by transitioning from a standard Databricks setup to the advanced capabilities of Unity Catalog. In this video, we will share the motivations, obstacles and strategic decisions behind executing a seamless migration in a large-scale environment — one that spans hundreds of workspaces and demands continuous availability. Gain insights into planning and governance, learn how to safeguard data integrity and maintain operational flow, and understand the process of integrating Unity Catalog’s enhanced security and governance features. Attendees will leave with practical lessons from our hands-on experience, proven methods for similar migrations, and a clear perspective on the benefits this transition offers for complex, rapidly evolving organizations.
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

What is Schiphol Group and its data scope?

Schiphol Group, officially Royal Schiphol Group, is Europe's third-busiest airport operator. The company owns and operates the three major airports in the Netherlands plus stakes in Brisbane and Hobart airports, and runs terminal 4 of JFK in New York. They manage data across hundreds of workspaces.

Why did Schiphol Group migrate to Unity Catalog?

Schiphol Group transitioned to Unity Catalog to elevate its data operations with advanced governance capabilities, enhanced security features, and improved control mechanisms. The migration was motivated by the need for better data management at scale and enterprise-grade governance for complex operations.

What challenges did Schiphol Group face during migration?

Key obstacles included executing a seamless migration across hundreds of workspaces while maintaining continuous availability. The organization had to plan carefully, establish governance frameworks, and safeguard data integrity throughout the transition process.

What migration benefits has Schiphol Group achieved?

The transition provided Schiphol Group with integrated Unity Catalog security, enhanced governance features, and improved operational visibility. The implementation delivered practical benefits for their complex, rapidly-evolving organization and serves as a model for similar large-scale migrations.

Full transcript

Hello. Hello everyone. Uh welcome to the session. So we are going to talk about uh skippipo's journey how they moved their uh pipelines from high meta store to unity catalog. So we have a datab bricks team who are working closely with them uh on this migration journey. So I'm the manager for specialist architects team based in Amsterdam and uh yeah I was also like involved closely with the skippole group in terms of designing planning and architecting the migration.
So also have Sua with me here. Yeah. So hi everyone uh solutions architect uh at data bricks and I was working with uh ELA and his team very closely throughout the whole process of uh migration. Okay. Yeah. Hi everyone. Thanks for joining. At least we got some more people in the room. So we have more people attending than we have prevent presenting. So uh that's that's always a good good sign. Um yeah, let me uh start with a question from my end.
Who has never heard of before? Okay, last week. Well, good. Well, that's good. Well, at least we have one person who will uh and judging by your response, you're not here by accident. So that's uh that's also uh that's also quite uh quite good. Uh yeah, so let me start with a short introduction about myself. Uh these guys come in Paris. So I needed to bring some reinforcements on the screen as well. So this is my family, married to.
I have two kids, a golden retriever and a rabbit. We couldn't get the rabbit to pose on the screen. So uh you're going to have to do it with half of a golden retriever. Um I've been working uh at uh script hall for about a year and a half now. Uh and I've been in IT for about 30 years. Um started out an engine as an engineer. Uh I was actually quite bad at it. So uh what do you do when you're bad when you're bad at engineering?
You become a product manager. And that's what I've been doing for the last 15 15 years. So yeah, that's me. Um within Skipple, I'm responsible for the data platform. Um and uh yeah, we do a lot of cool cool stuff at uh atripple. Um is Group. That's our official company name. We own uh the three major airports in the Netherlands. Plus we have a minor stake in one other airport in the Netherlands. So basically just all of them.
Um we also have a minor stake in in in Brisbane airport and airport. So we're quite international. Uh and we run terminal 4 of JFK here in the in the in the states. Um and we have some strategic partnerships with uh yeah some airports across the world. Uh and as a couple of weeks also with Copenhagen airport. So there's a couple people from Copenhagen airport here. So nice to see you guys. Um last year we processed about or like there like 76 million passengers passed through. um um uh well 76 across all our airports in the Netherlands and 67 u million across Skipple airport but it makes us the fourth largest airport in Europe and 17th largest in um in the world.
We have about 27 square kilometers of space. Um um and if you if that like it's hard to imagine that kind of uh square footage. Uh so uh maybe a question for you guys. How many uh how many soccer pitches would this be? So 27 square kilometers. There's a prize. So if you get it right, you you get a prize. 900. Well, it's not even close. It's Yeah, it's 4,500 soccer pitches. Uh so that's a lot of a lot of square square footage, a lot of runways uh to uh that we uh that we that we cover.
Um and you can imagine that all of this uh square footages, all of this infrastructure, all these passengers and all these flights generate a lot of data. So uh we do we do pretty cool stuff with data on our on our platform. Um and I I want just wanted to give you some examples so you have a bit of a context of what we're talking about and uh when we go into the technical details a bit more uh why we uh we use them. Um so we use data for baggage mainly at least from our platform we use it for baggage prediction.
Uh so uh we want to make sure that we have the right people in the right place to take off your luggage when you travel uh via scripple uh and make sure that it gets process processed in time. Um we've created an application called deep turn created within our department. This is uh this uses uh AI machine learning uh and data from our platform historical data but also real-time data in the form of cameras that we point towards on uh on every gate.
Uh and we use it to predict turnaround time of our aircraft. So uh and that really uh is really important because our square footage is I mean it's big but we have a limited amount of space and if an aircraft is late then it has all kinds of consequences down the line or with like uh food trucks who want to deliver the food cleaning people uh all that kind of stuff. Um and that makes it makes it really important to predict that uh that part.
We alo also offer it as a as a product. Uh so uh if you happen to own an airport uh or planning to buy one, let me know. Then I can hook you up with uh with our application uh application later. Last one is pack flow. We call it pack passenger flow. Uh and it's quite interesting that we we we track all of the passengers across our 650,000 square meters of uh of terminal space. Uh and we track uh to predict uh yeah time uh waiting times and reduce security uh waiting times.
So there's a lot of data uh and to be honest we were struggling a bit with our data uh because it's um uh we have like 20 different data data teams doing all kinds of nice and very cool stuff on data bricks uh but uh it's not always governed quite well and sometimes we don't know who accesses what data um um and that's yeah that was really problem so what are you going to do if you can't uh call Houston or you can't call the Ghostbusters you call data bricks so we called when we called Zuva and we said look we have a problem please help us out with our uh our data governance data management and they said well the answer is yeah the answer is unity catalog right so basically uh as you saw like the data landscape is quite wide and there are multiple teams uh with siloed architectures and you know fragmented governance so yeah so that's the main background of why skippol wanted to move to UC it's not just like the technology upgrade but also a lot of uh business reasons for that.
So what UC can do uh of course it it brings the enterprisewide governance it brings everything to the uh central manageable uh platform where you can set access rules uh govern different teams federate the governance uh delegate to the right uh teams in the right way. uh but not just that I think the bigger vision is also uh harmonize your data fast and bring it to the UC but in the future it will eventually enable all the new use cases like the genai or the semantic models or you know the intelligence part of the data.
So one part is migration definitely but it also kind of setting the skippole for the next uh you know wave of use cases that they can build. Uh maybe I will pass it on to Sua to explain how did we really uh you know uh adapt the UC to the skipples architecture uh you know. Yeah. So uh the primary thing that unity catalog unlocks for Skipfall is like mentioned unified governance and data management right so that was the biggest driver behind this.
However, this also brings in built-in lineage as you all saw as you have already probably been using. Uh the data governance team plays a very big part in this in this user journey. We'll talk about it in the later as well. And then you have they start using new features primarily the lakehouse monitoring which was very crucial to understand the data quality understand the data drift. So that these were some of the biggest drivers that motivated Skipfall to move to UC.
So here's a solution architecture on some of the tools that fall uses as a as a platform. This is not all by the way. Uh but here you see the main thing that I want you guys to take away is the medallion architecture naming. So the naming is actually landing turnaround and takeoff very airportish. Uh yeah and then UC sits on top of the whole architecture governing the data and then Calibbra serves as the enterprise data architecture in this whole space.
Yep. Next slide. Yeah. So uh if you look at migration of unity catalog right so uh it's not just like okay moving your pipelines moving your data but there is lot of different components you see also integrating if you look from preuc era like you know where we have high meta stores like workspace users identities or networking setup right so there is lot of different components UC is trying to bring into one place uh so there is like we have divided like the whole journey into four phases that you see here.
So the planning is key because uh organically uh you might have grown different objects in your use cases. It's not just pipelines and data but also the different uh type of pipelines what exactly the pipelines are doing and the how they're interacting with the data in the background. Uh so what we have here is basically uh a tool called UCX. Uh so this is a in-house datab bricks tool that we have built in the field for you to first discover all your assets.
Uh so this is pretty crucial because in enterprise world you know you might have you know uh things which would have been developed and gone unnoticed. Uh so the UCX will help you first discover what exactly are the candidates that you have to migrate and once you have this overall picture of different assets different interactions that you know each pipeline is having or the components then you sit and you know figure out like how do we do this right so start with discovery and then uh I think one of the key aspect also is to pick the right use case for first migration uh it could be like your toughest workspace case.
I think everyone has one in their deployments. Uh or it could be like one of your biggest use case where a lot of your business critical things are going on. So the finding this pilot use case is key after you discover like whole landscape. Start with what is your right candidate for migration because this is where you will try to test things uh learn adapt and you know and then move into the uh you know learn and build on top of things.
So once you do all this uh we get into the design phase. So there are as I said there are different components here. So first thing is identity management. So you see is actually bringing identity along with data governance in one place. And if you see how data bricks used to do identity management before it was completely like at the workspace level and workspace admins was managing all the identities directly from your cloud providers.
So what you see is tied to is also like a new uh layer what we have built is called account admin layer where identities are centralized into datab bricks account panel which then becomes your identities for the UC which you can use with so basically UC doesn't work with your previous identities and it's very important to first figure out like how do you want to centralize your identities uh and once we have it then you go to the data part like what is the right strategy for you?
Do you want to clone the data or depends on what type of data formats you use? uh how much data you have you know all those kind of things and then you also design like how you want to organize your datas right like the catalog schemas because it's a different world once you move away from hive meta store and it's a good world right and then you go to actually the governance part because when we think of UC we jump into the governance but there are few things which you first figure out what how do you set the foundations for the future and that's where like the design aspect of these basic components what UC is bringing into one one space and then uh UC also provides you a layer for setting up all these infrastructure in a very centralized way through uh infrastructure as code.
So UC has support for like Terraform you know the Terapform provider what data bricks has has all the support for UC interactions that you can do. So we highly recommend to use these layers to set up the foundational platform for you know to be to be compatible with the future you know expansion in the enterprise scale and then uh the meta stores uh so this is a bit shift away from what you would have been used to before UC because earlier you know every workspace had a meta store and here UC is combining this to like one meta store basically uh we don't want you to think about like what is my meta store about?
You know, just think of it as a layer uh or a service in the background which has information about all of your you know data sets, tables, uh who are the users, right? And because we are taking this away uh from the old architecture so data bricks now has better capabilities for you to uh you know what we're trying to build on top of uh unity catalog layer like all the AI stuff uh what we announced and there is also a difference in how your uh data interactions happen.
So earlier it used to be like each cloud has its own way of accessing the data. It could be like service principles identity uh you know like the in the ADLS it's a different world in S3 you need to do set of different things IM roles all those kind of things you see is also bringing those uh into standard objects like what we call as storage credentials. So these are all like the foundational infrastructure pieces that you know you can automate uh when you migrate uh to the UC.
So once we figure out like all the plans uh for the foundation pieces we go to the up upgrade. So in upgrade you can actually see uh you know we strongly recommend picking one workspace uh can split this into like different layers. So there can be a guidance what we usually do when data bricks is closely working with customers is we set up the guideline like how your upgrade should happen you know at the workspace level.
So this is like generic recommendations uh what we give but depending on what workspace is doing what type of jobs there can be some changes. So here what you see in upgrade is the standard uh set of steps that you follow for every workspace that you want to migrate uh but it can also change depending on the use case. uh for example uh for skippole like the first workspace what we picked or the use case is CDP this is central data platform and it has like lot of you know tweaks which we had to consider or have a different step in the process but at the high level you can see we start with uh you know the upgrading the workspace identities this is pre-step for any UC work that you do and UC doesn't really work with your previous identities which are in workspace And this can be this is automated completely using the same UCX which I talked about and you can just like have to do it before starting anything for migrating to UC.
And then uh from the design you pick like what are the cataloges that you want to have uh have them created set up your credentials automate your from your Terraform scripts what we have built right and then decide a strategy like how you move the data. Is it through like the deep clones or you just uh copy the data you know or you know the using the seas? Uh so this is like the choice that you have to make depending on the formats size you know all the different things.
Uh and finally like once you have the data uh once you have the identities uh once you have the uh cataloges everything ready then uh you go to the other objects of the workspace like your jobs dashboards uh or you know the other parts like the clusters everything else. So basically it looks like there are too many things but once you have UCX run and you figure out like how to do uh the migration for each component once it's just a repetitative process for everything you can easily automate uh you know using the deployment scripts.
Uh then we go to the transition uh so this is where you really go into the business logic try to change things if you really have to change uh depending on your access patterns. Uh I think one of the biggest access pattern what we see is basically you know accessing your data with like the file parts right like the direct ads parts uh I think that's something we will uh we strongly avoid once you move to UC you you basically can't do it anymore you just have to use the table names and that keeps the storage uh that removes the storage uh coupled with the table names right so you just operated the table names.
Don't worry about like how the storage is mapped in the background where it is you know that's something for like the service like the UC to figure it out. Uh yeah and then once you have jobs and everything upgraded uh you move the consumers like the end consumers uh so you can either go from uh I think what what we usually recommend you go from uh left to right so you can easily uh switch the consumers at the at the gold layer for example and then figure out like all the things in the background so the business users uh won't be affected too much uh during the migration.
And that's pretty important uh for uh for also the skippipole when we did this so that you know there's no change for your business in the day-to-day operations. Uh what then so we do recommend to leave your data like you know uh in the old uh fashion right like the stale data where you eventually stop uh ingesting the data into your old tables. So there is a a phase where you end up probably end up with like multiple jobs uh trying to ingest the same data but one processing and writing to the new tables in UC one is the old way of you know directly the high meta store.
So we'll go into the details of that and the last step is actually cleanup right. So this is uh this is something like we neglect but uh there are also features what we are introducing now for example there is a built-in feature now uh where you can actually decommission like the DBFS uh from the workspace and eventually uh we'll also get to the high meta store decommissioning. So as of now it's still available but uh eventually we are rolling out things where you can just hide the hive meta store completely from the workspace.
Uh yeah so these are like the highle steps uh what uh we have tailored for skippole and how the migration happens. So I think if you see the planning and cleanup is just like the one step uh like you do it once and then the transition is where you iterate over multiple workspaces uh depending on uh how many workspaces you have. Uh so if you go into the design like the model how it works. So at the UC level uh we have different personas.
So one is account admin right. So this is like the universal role what UC has introduced. Uh it kind of uh can control uh identities and also the data part and we also have something called metas store admin who is more like a super user for all the data in your meta store. So this is like another persona. So and then we also have the old workspace admins who are still managing each workspace access cluster management all those kind of things.
And finally we also have billing admins which is a kind of a new thing uh you know we enable it through like uh system tables uh which is again backed by UC in the background. So these are different roles what UC introduces but maybe I'll ask a like how did we map this to skips you know uh roles and responsibilities. Well it's a very unexpected question. Um yeah so uh I think one of the strategies we chose uh also on advice of data bricks is that we have one central team who is responsible for like being the driver behind the UC migration in our case it's our data foundation platform technology team we couldn't find a shorter name for it so uh so this is it um uh so this is the central team who who provides a role as a as an account admin and also it helps us to get better governance on that uh on that And um we also uh yeah for the for the metas store admin role we have a team of data governance consultants data stewards.
So we want them to be responsible for uh yeah the metas store administration making sure that uh that we have the right setup there and the workspace admins uh well well we just named them workspace admins but it's actually our data data product teams. uh now currently they have their own workspaces and we want to have have them to keep their own workspaces so they can have the freedom to develop the very cool products data products that I showed before uh but also do it within the limits that we uh that we provide uh yeah and lastly um with regards to the cost management I mean it's also one of our uh our key drivers is you want to uh we want to improve use more data but then we don't have unlimited budget uh or it will be very expensive or even more expensive expensive if you fly through Scripple.
Uh we want to prevent that. Um so we have to keep control of our cost. So within Scripple we have a dedicated uh Azure uh cost manager uh who keeps track of all our Azure costs including data bricks and uh our my data foundation platform platform technology team actually we call it the PTT um works closely together with him to make sure that we have this um uh this setup right. Um but yeah but so if you would translate this to a uh uh like like a design how would this look?
Yes. Yeah. So before before I uh do that uh how do you conceptualize this like how do you see this design coming through for skiff the entire catalog design? Um yeah, for us it was important that um we want to kind of shift away a bit from what we used to use before. So we we also chose to do a um uh like a redesign of our catalog. So uh before there was just like this one one big I met the store and we just put everything in one place and now we're kind of working towards uh uh having different uh different subp parts.
So we're moving towards having cataloges for our different business units. So that's one part of it. Uh and yeah, we also had a requirement of having these uh cataloges available on different workspaces. So that was also something that we uh uh we yeah we we said um and also we want to give them people the the freedom to to play around. I think that's basically what we uh yeah envisioned. Right. So that's how the vision gets translated into this design of the of the cataloges.
So here you have like workspaces for each uh if each each like one catalog per per workspace and that also follows the SDLC life cycle as well. And if you look at the middle pillar that goes into the vision of skill to eventually have the federated governance. So you follow the hubspoke model where all the data products are published into the hub. So that's the federated governance where it follows the SDLC life cycle as well.
So the SDLC is very important across both the both the designs and then there's the platform technology team that YA referred to as the PTT. They are responsible for enabling the sandboxes for it could be for teams for different departments for genai use cases. So that's how the whole catalog design was was done. Yeah. So for the for the domain shared catalog it's it's pretty straightforward. So you have the catalog external location and the storage credential.
So the external location points to one one storage account. Basically this is where all the all the data products get get published and the storage credential the access connector points to one single container within that storage account. However, if you look at the cataloges per workspace which are private to each of the workspaces, you have three different external locations all using the same storage credential but each of them pointing to different containers that follows the SDLC of that workspace itself.
So that's how the design of both the different type of uh workspaces were set up and but it follows the same approach. Yes, slide. Yeah. and uh the permission design. So if you look carefully at the schema so the catalog I explained right it's it follows the SDLC you have the dev stage and production and the entire thing is owned by the data manager the data owner however you want to call it but the schema if you see uh so LZ stands for landing zone TA is take turnaround and uh TO is and to is takeoff so the first two schemas you have LZ and TA those are most more more source aligned.
So those are the source aligned data products which get published in those schemas and then the turnaround and take off product those are more domain aligned data products. So that's where the central team comes in who's the hub where they get the source aligned data products and convert them into domain aligned data products. Yeah. Uh now the permission design for the domain shared cataloges. Now what happens when you have to segregate permissions based on a star schema model?
There's multiple different interlinks between dimensions and facts. That's that's that's very tricky to implement. So this is what we came up with. So the schema reader group gets access to read on the schema level and then individual dimensions and the facts they are we created separate groups for each of the star schemas and that's how the access was granted on a particular star schema on a particular dimensional model to segregate the users but still enable the interoperability between the tables and the groups.
Right? This is this is the approach that we also recommend when migrating from UC from hive meta store to UC. So there's a there's a there's a phased approach over here. And uh at one point of time there will be a double run between the old environment and the new environment. So if you look at the top that's the new workflow and if you look at the bottom that's the old workflow. So ultimately the consumer remains the same.
The data is read from the Kafka topic. In the center you have the schema registry which has which enforces the schema and then you have spark structure streaming jobs that sends data to both the workflows and for the end user for consumer there is no difference between the new workflow and the old workflow because they are the ones who are validating the data that they get from YSD team. uh maybe I'll chip in here a bit on like how did we manage to migrate your streaming jobs which were like you know running continuously from old system to new system.
So there is a catch here right like you can of course set up new jobs uh start reading the source and then ingesting the data but uh we wanted to make sure like when you make this transition we don't you don't really lose your historical data because it should still be available uh for the consumers when they switch to the new system. So here what you really see is basically we're going into the structure streaming internals uh a bit where how the you know Kafka tracking happens in the stream.
So basically it goes to the uh like how spark works is basically goes to each Kafka partition uh checks at uh what are the offsets you have read and you know just process process it in the batch like what is left from the previous offset. So uh what we have what we did here is basically to look at your current stream state uh to understand where exactly your Kafka snapshot is read until that point and we map it to uh exact like the offset in the delta table like what was the commit which was corresponding to your Kafka offset.
So this you can this trick you can apply for if your source is Kafka and your sync is delta. And these offsets are basically uh what we use uh in the new streams. Uh because in a way what we what we end up doing is we take snapshot uh from your previous delta table which has your historical data. We migrate to the new table. But when we start stream on this new table, you don't want to read your you know historical data again because it's already processed right.
So when you start this new stream so we you actually end up setting this starting offsets which will say I have processed until this comet in delta but only process the new data after this point. So that is your like daily data what you're ingesting uh you know ignoring or historical data. So this we typically uh use it for you know disaster recovery or high availability uh compliance uh systems but here I think it's it's very relevant because if you have a streaming job and you know you if you want to keep continuity of the job when you migrate to unity catalog so you need to you know uh map those offsets and track it properly so that you don't end up with lot of duplicates when you move to the new system.
Yeah. So uh with this uh I'll probably give to LA to kind of summarize like uh you know the next steps here. Next steps. Yeah. Okay. So um I think for us it's it's uh like at least if how I look at it the technical part is easy relatively easy at least. So obviously when you have like very cool engineers as you guys uh helping us out makes things a lot easier as well. Um but uh you start out with the technology, you make the proper design and then you start start working for according to the phase approach that told about.
Um and I think the next uh yeah the next next step is where it gets exciting at least according to me is uh getting uh new processes in place getting the data data governance processes in place getting teams to work in a different way accessing stuff in a different uh in a different way. I think that's yeah that's something that we're really working towards. Uh we are kind of in the middle of our migration. Uh so uh you have to come back next year.
Uh we'll do another presentation on the on the completion of the of the whole migration. U but yeah there is the that's where the key uh the key process is is get people on board seeing the value of uh of this of the new features that Unity catalog brings. um uh and then yeah in the end uh getting um um enterprise governance because that's what that's what our goal is. So that's u yeah that's that's what it is. Yeah.
And I if I can summarize it then um our our yeah our journey the things that we just discussed I think for us the key was the collaboration with data bricks and I'm not just saying that because they will kick me out if I say something else. So um um no it's I I really mean it and I only say stuff I mean it that's how we how we work work. Um I think for us it really helps that we had one data brick solution architect with us for two days a week helping us making the right designs uh also uh with the preparations towards that point that really helped us uh us a lot.
The other thing that we uh and that I would definitely recommend if you do any kind of migration to Unity catalog is have one central team and be responsible for this part. Uh with us it's the platform technology team makes it really good to uh uh to have one one place people can reach out to contact and and drive the the change towards this one governance model. I think that's the uh that's the thing. Um yeah, we also have a couple of challenges of course u as I said the last part getting people uh on on board and uh implementing a new way of working.
These are all uh all quite uh something that we still need to need to tackle. Um we have to keep the business running um because everyone uh still wants to fly so and get their luggage and uh and do all the different things. So we have to make sure that we keep the keep the well I would say keep the boat afloat but that's uh the wrong analogy. So keep the airplane flying that's the better the better one. Um and also uh we took the opportunity to change to a new governance model that's maybe not something you would do and at least I try to kind of keep projects as as small as we can but yeah here it was very very necessary and we'll reap the benefits for it.
Um yeah in the end uh apart from all the other benefits that we have uh that having better cost attribution better cost control um yeah that kind of helps us uh getting along so um yeah I think that's uh that's about uh about it

Learn more about the Databricks Data and AI platform.