Simplifying Data Pipelines With Lakeflow Declarative Pipelines: A Beginner’s Guide

Key Takeaways

So we did a study with the economist about a year ago. Uh we were looking at surveys and trends across data teams around the world in data engineering, data science, machine learning and so on. And one of the most interesting takeaways from that study uh to me was that twothirds of organizations worldwide are fully dependent on data engineers for the creation and management of data pipelines. Fully dependent. Uh this may not be a surprise to many of you. I think it's an interesting stat. Um, there was another study that was done a year before that that surveyed data engineers and found that 97% of them report experiencing burnout in their day-to-day. To me, this is unsustainable. Uh, and it's also the reason that we made DT. Uh we made DT to simplify data pipelines not just for the data engineers that are tasked with bringing reliable data to the rest of the organization uh but for the ecosystem of data professionals around them that are increasingly tasked with doing some data engineering. So my name is Matt Jones. I'm a senior product marketer uh here at Data Bricks. I'm joined today by Brad Turnbot, a senior data engineer at 8451, one of our awesome customers. And uh let's jump right in. So this is our forward-looking statement that you're going to see dozens of times at Summit. Uh it basically says that anything forward-looking is non-binding. I hope you can read fast. So here's what we're going to cover today. We're going to keep it short and simple. going to give an overview of DT and kind of the key concepts behind why we built it the way we did. Gonna talk about best fit use cases for DT. Um the areas where we see customers really getting the most value from it today. Going to give an overview of what's new in DT. Uh and then we're going to talk about DT in the real world. So this is where going to talk about a couple customer case studies, but I'm really going to turn over the meat of that to Brad to talk about what 8451 is doing with in production. So, I want to start with this quote. This is from Carol Clemens, uh, who's the chief digital and technology officer at JetBlue, and she says, "You can have all the AI in the world, but if it's on a shaky data foundation, it's not going to bring you any value." All of your organizations are building for AI projects. They're building for BI projects. They're building for conventional data science and machine learning. They're building for new genai projects. And many of these new capabilities have a ton of power. But the quality of data going into it is what's going to channel that power in the right direction. Um, just so I get a sense of who's in the room today by show of hands, who here is a data engineer by title? Okay, awesome. How about who manages a team of data engineers? Okay. And then who is not a data engineer by title but has to do some data engineering as part of their job. Okay. Okay. Awesome. Thank you. So data is the key to unlocking the value from all these AI projects, right? But as you probably know, it's difficult to build and operate data pipelines. There's a lot more uh that goes into this than just the data you're working with and the transformation logic that you're applying. You know this because you have to work across data that's stored in your data lake and data in your data warehouse. You have to do this for BI projects, DSML projects. You have to incorporate streaming data for new real-time projects. Of course, there's this whole world of generative AI that we're all still kind of trying to figure out. And then you have to orchestrate across all this. Then you have operationalizing this, right? So you've got developer operations, devops, you've got things like CI/CD, version control, deployment infrastructure. Then you have data ops, got quality checks, data governance, data discovery, and then finally pipeline ops in production. How do you accommodate for backfills, dependency management, partitions, uh checkpointing and retries, schema evolution, all of these things, there is a world of operational complexity around your transformation logic. And this is why time and time again, the customers that we talk to, we ask what they're struggling with with operationalizing data pipelines. And these three things come up over and over again. So the first is development is labor intensive. There are all of these things that you have to plan for when you're coding and developing data pipelines. And this leads to bottleneck productivity for the organization. both because as a data engineer you spend a lot of time building and second folks who want access to data are kind of bottlenecked by the limited uh talented resources of of data engineers who hold the key to unlocking the value from that data. This is a relatively scarce resource in many organizations. The second challenge area is operational complexity. So again, all that uh all the operational um complexity from the previous slide, right? When you put things into production, you don't set it and forget it, right? You have to constantly maintain and monitor uh all of these things and try to scale them. And we talked to teams that are constantly in firefighting mode and having to deal with uh things breaking in production or not being able to scale. uh or having to incorporate new data sources on the fly. And then finally, siloed batch and streaming. Many teams that we talk to have separate systems for their batch data and their streaming data. And this makes it difficult to evolve data pipelines as needs evolve. So again, this is why we built DT. DT is built to make reliable data pipelines easy. And DT is one of three products that form our LakeFlow data engineering solution. We announced LakeFlow at Summit last year. We've been hard at work building and stitching things together since then. And this week we're actually going to be announcing the general availability of LakeFlow uh in all these areas. So, LakeFlow Connect helps you uh through simple native managed connectors bring data into your data intelligence platform. DT helps you easily build and operate those data pipelines. And then LakeFlow jobs helps you orchestrate. I put brackets around DT because if you tune in to the Thursday keynote, uh you'll see we're actually going to be rebranding this. So, don't get too comfortable if you're not already with the name DT. We will be rebranding. Um, I would just say stay tuned for the Thursday keynote to see why. There's a couple really exciting reasons behind that rebrand. So, this is the vision of DT to solve these three challenge areas. Instead of labor intensive development, we've built DT to deliver more simplified pipeline authoring. So this helps data engineers be more agile with development. It democratizes the pipeline authoring process or parts of it to other data professionals and it just makes your teams more agile and able to unlock more value from more data. Second is intelligent operations at scale. Um, we've built DT to automate a lot of the operational heavy lifting behind these pipelines. You can't automate everything away. You can't automate everything that you could procedurally program in Pispark, for example, but you can you can create a declarative pipelining tool that does about 80% of what you could procedurally code with say 20% of the effort. And then finally, because it's built on the Spark structured streaming API, uh you get unified batch and streaming. Switching from batch to streaming pipeline is as simple as changing a single line of code. And this helps you be more flexible for evolving pipeline needs. So I uh I think this is yeah I I want to talk about a couple reasons that uh we've made pipeline authoring uh simple or a couple ways that we've made it much simpler. Uh one is that DT is built on a declarative framework. So uh declarative programming of course is where you say what needs to be done and the system figures out how to do it. So you don't have to imperatively code line by line the how behind the what. So we've built DT as a declarative framework. Um I I I had a slide that's a great example of this uh that shows a change data capture example where in imperative Spark code you would need 24 lines of code for this particular example. uh and I'm a product marketer so a lot of the technical nuance behind that example is lost on me but uh the person who made it is the person who made DT so you can trust him uh and then the DT example when you're doing the declarative lines of code it's just five lines of code you use the apply changes API and uh a couple more uh specifics again I don't have the slide here but uh DT helps you compress the lines of code that you would need uh for many different use cases. The second way that we've made pipeline authoring much simpler is through this new IDE for data engineering. This is going into public preview this week. So, prior to this um you would have to code your pipelines in a notebook and then plug it into the DT UI. There you would have your your DAG and be able to monitor uh pipeline runs in production. Now we've brought everything into one place and we we kind of started working towards this a year ago. We knew we needed to improve the developer experience of developing a notebook. So we started bringing in more in context things like uh like the DAG and you could validate and do dry runs from the notebook. Uh but this is kind of a whole reinvention of the process. So this brings um this brings your code uh other files you might be working in uh the DAG and sample data all together in one place. We've got about a hundred customers using this in private preview. Um they unequivocally love it. Um there's a quote that will be in our Thursday keynote from a uh a customer at Rolls-Royce who's been using this that says this is how data pipeline development should work. Um, and we've got this quote from uh my colleague UA at block who says you know with the adoption of DT the time it's taken to uh define and develop a streaming pipeline has gone from days to hours. So DT makes this so much easier particularly with the declarative framework and the new IDE for data engineering. Second intelligent operations at scale. So again because of the declarative framework DT is able to automate things like dependency management incrementalization you don't have to handcode an incremental framework uh for processing data incrementally um it's built on serverless infrastructure by default so you don't have to manage or provision infrastructure uh it has the uh recovery and backl handling guarantees of spark which it's built on and uh it includes things like observability out of the box. So this customer uh Vera from Hinge Health says their data engineers are happy because they have less troubleshooting. Their data scientists are happy because we can meet our SLAs's. And by the way, this helps us optimize our costs because we're not spending time in unplanned downtime or resolving issues or firefighting. And finally, um I essentially explained this earlier, but uh batch and streaming, it's built on the Spark streaming unified API. So you have workloads that are best to optimize for latency, you have workloads that are best to optimize for cost, you have workloads that are somewhere in between where you need performance that is good enough and beyond that you just want it to be as cheap as possible and uh DT makes it easy to do that. So, um, Martin from Heineken says, you know, most of our DT pipelines are written as batch, but it literally doesn't matter to us. If you want streaming, you just declare a streaming pipeline. It's that easy. Okay. Uh, now I want to talk about best fit use cases. And this is, uh, I think this is an older version of the deck. So, this is before I did a little bit of reshuffleling, but this is that declarative example. uh you've got 24 lines of code uh for the spark imperative program and then the same thing with DT um the declarative code you just need five lines of code and it takes care of that automatically. Um and again this is this is an example of change data capture. This is probably the number one use case for customers using DT today. Uh automatic change data capture. So DT makes it super easy to stream change records from any data source supported by data bricks which is essentially anything you can bring data from streaming sources message buses cloud storage uh structured unstructured semistructured data so on it's a simple declarative apply changes API you can use this in SQL or Python same goes for all of DT SQL and Python compatible autom automatically handles out of order events, automatically deals with schema evolution, and you can use this for sedd type one and type two. And Brad's actually going to talk about an SEDD type 2 example uh for 8451's use case. Uh the second kind of ideal use case like sweet spot for DT is streaming data flow. So whether these are streaming pipelines for say real-time analytics or whether you are working with an operational use case where milliseconds matter like fraud detection or alerting uh DT just makes it super easy to start setting up and running data pipelines. Um almost exactly 50% of pipelines running in production on DT today are streaming. So customers love uh DT for streaming and it makes it very easy. And finally, SQLbased ETL. Um so I talked about kind of being able to not only make data engineers more productive but also expand the ability to build and maintain data pipelines or part of data pipelines to other personas. So we've made it very easy for SQL analysts or analytics engineers to do these sort of last mile aggregations and gold table maintenance. Um it's the same framework in DT as DBSQL. Uh it's all DT under the hood. It's a just a couple simple abstractions called streaming tables which you can declare in a few lines of code to bring in the data you need and then materialized views which materialized views are not a new concept but they run very smoothly in DBSQL. Uh they're also a core building block of DT pipelines outside of DBSQL. Um so very easy to operationalize this uh with SQL or a SQL skill set. um takes care of things like scheduled automatic refresh. Uh it's all managed by Unity catalog and you can monitor runs with query history. Okay, want to talk about what's new and revamped in DT. Uh so what's been revamped in DT? We've brought in interoperability with uh thirdparty sources and syncs. So you can uh in private preview now you can sync data to whatever external uh data warehouse you need or rather read from external data warehouses. Uh you can also bring in custom data from uh a custom data source API. We just put out a blog about this a couple months ago and Shell has an amazing use case so you should read that blog. Uh full Unity catalog compatibility. So um things like rowle security and column masking and the ability to publish to multiple cataloges and schemas from a single pipeline. So fully compatible with unity catalog you get that governance guarantee that you get with the rest of the lakehouse. Uh also delta par. So anything you can do in delta you can do in DT. This includes things like liquid clustering deletion vector time travel support cost and performance. uh in the last say 9 to 12 months we've been really laser focused on making this as coste effective and performant as possible. We've released some new um serverless innovation. We've uh actually just recently tweaked the pricing model so um on average pipelines will be uh significantly cheaper. And then we've done kind of a full uh a fullscale revamp of the error messages and docs just to make it uh supremely easy to troubleshoot and get started with DT. Then there's some really exciting things that are brand new in DT. So one is the IDE for data engineering that I showed earlier. Um we've got a whole breakout session on this new IDE. So be sure to check that out. We'll also be covering it in the Thursday keynote. Serverless compute modes. So when we initially went general availability with serverless compute for data pipelines uh almost exactly a year ago this is initially um the goal was to kind of optimize for performance right but again you have many workloads that you don't need to optimize for performance you need them to be good enough and then beyond that you you want them to be as cheap as possible so we've launched a standard mode for serverless compute as opposed to the initial performance mode uh which helps you do that The guarantee is that um your pipelines will be no more expensive than running on classic compute, but then you don't have to manage the infrastructure and the performance is really really good as well. Um I had kind of mentioned custom sources and syncs, but we're expanding more and more the places that you can bring in data from and where you can sync data to. And then real time mode. This is this one's super exciting. We're going to talk about this in the Thursday keynote as well. Um, if any of you were around for data and AI summit back in 2022, we announced project light speeded for uh just kind of nextgen streaming and uh Apache Spark structured streaming. And of course, because DT is built on structured streaming, it's able to leverage many of these benefits. Real time mode has been kind of a concerted effort over the last year to take subsecond streaming down to millisecond level streaming again for those operational use cases where milliseconds matter. So we've got some some brand new benchmarks that we're really excited to debut in the keynote. Um certain operations we can uh accommodate in the you know single milliseconds. So please stay tuned for that. Um, I touched on serverless compute. Just wanted to show kind of a comparison of when you might want to choose performance mode versus standard mode. Uh, I won't spend much more time on this because I already kind of covered it, but essentially standard mode is what you should use. It's in public preview now. What you should use if you want a more costoptimized mode of serverless compute. uh but performance is performance mode is really incredible for those uh you know performance sensitive workloads. Okay, want to give um just a few like customer success examples of DT in the real world and then uh we can get the marketing guy off the stage and turn things over to the data engineer to talk about how it actually works in the real world. Um so we've had a number of analysts uh give some high praise to data bricks. Um, of course we are one of the leaders for data lakeouses. So, you know, kind of the the highest up and to the right there, as you might expect. Uh, but also cloud data pipelines. Uh, we've been named a leader there by Forester. Uh, we've been named a leader for stream processing by IDC. I actually just had a recent buyer guide come out where we were uh the highest scoring performer for streaming data platforms as well. Um, so lot lots of nice things from the analysts. We have over 4,500 customers using DT pipelines in production today. This is across all industries and verticals across all company sizes. Um, we have lots of great customer stories up on the website. I want to highlight a couple of my recent favorites. So, um, this is Miracle. He's a uh senior engineering manager at NFCU and he says he loves the declarative programming model of DT. It's able to help his team hide the complexity of modern data engineering under that model. We love to hear that because of course that's why we've built DT so his engineers uh can focus on what matters the most to the business while DT takes care of what's underneath the surface. And they're doing this at scale. They're doing this across billions of streaming events. It's helped them literally reduce their uh their time and effort spent on pipeline maintenance by 99% and it's really boosted their development with velocity. So they've been able to take a brand new real-time application to market in as little as six weeks. Um I food is a recent story we published as well. This is uh kind of like the Door Dash of Brazil. Uh they're huge in Brazil. um they were struggling with uh errors and operational uh issues in production with their previous framework. DT helped them move from frequent errors to near zero errors. Um Diago says it's helped their team focus on strategic initiatives instead of firefighting. Um so it's helped them reduce costs as well. Um, a lot of this is just from moving to to data bricks from their kind of legacy infrastructure, but also they've reduced their maintenance efforts by 70% and they're spending less time coding. Uh, here's a story from uh PaloAlto Networks. Kind of similar thing. Um, you know, they've been able to boost development time, spend less time troubleshooting in production. Uh, but I think at this point it would be best to turn things over to my favorite customer example, uh, which is 8451. And, uh, so I will let Brad take it away with that. Thank you very much. Hello. I'm Brad. I'm a data engineer at 8451. Uh so what I'm going to try and do is just kind of give you a lightning demo of how we've used DT to kind of uh get rid of the operational overhead that we as data engineers face on a on a day-to-day. Um so at 8451 we're data science insights and media company. Uh we help create more personalized and relevant experience for over 60 million Kroger households. So like I said, I'm a data engineer. I'm on a pure data engineering team and kind of the nature of our team's work is we help a lot of different data science and media teams within 8451 uh with their use cases. So a uh data science team might come to us and say we need a digital communications data set so we can make sure we're sending the right communications at the right time to the right customers and through the right modalities. or a marketing team might come to us and say, "We need a um we need a loyalty strategy rewards data set so we can show customers the the value they're getting from being a Kroger Boost member." So, the nature of our team's work is we get to build a lot of data pipelines from scratch. Uh and over the past few years, this is something we've been using DT to do. Uh so what I'm going to do is I'm going to talk about using DT and specifically how it's helped us with our software development life cycle, how it's helped us with uh how we govern and expose our data through data observability, uh how it's helped us make sure we're publishing reliable data, and how it's helping us monitor our processes through pipeline observability. So here is our use case that we use DT for not too long ago. So we had a uh data science team come to us and they were trying to measure the efficacy of a new digital marketing intervention that they were rolling out and what they discovered is while they were trying to measure it they weren't getting the results they were expecting for pre and post measurement. So they did some digging and realized that through a set of circumstances customers are able to migrate to their households. And because they were doing this during the intervention, this team was trying to measure the the effect of it was throwing off their results. So they came to us and they said, can you build us a data set where we can see our users and the households that they align to and uh the dates for those relationships so we can measure our our intervention effectively. So we said, "Yep, sure thing. We'll build you a type two slowly changing dimension." In this case, we use DT to build this out. So I'm going to skip this. So starting from scratch, uh we got this new project. Where do we start? So we use data bricks asset bundles. And so from um not having a repo created, the first thing we go is we go and we clone kind of our team's template which has the recipe for deploying a fully functioning DT pipeline through all of our environments. So it's tagged, it's already tracked, it's preconfigured with kind of our our standard DT cluster that we want to use and it's configured to publish to Unity catalog. So all we need to do when we start a new project is we kind of clone this template. We clone our recipe and we change the name to the notebook that's going to hold kind of our new DT pipeline. So what I like about this approach is uh we can go from not having a pipeline created to having a pipeline created, deployed using all of our engineering best practices in really just a few minutes. And then once it's out there, we can mess it up, we can destroy it, we can redeploy it all really easily with this data bricks asset model. So once we have gone and created our uh just skeleton pipeline, it's empty at this point. We've got a notebook. It's got nothing in it. Uh, I lied a little bit. I cheated with this one and gave us a source table. In this case, we're trying to build a sedd. This source table just has users and our households that they align to and the date at which we learned about those relationships. Uh, so all we need to do with this empty notebook is we'll go with DT. We'll define a streaming target table which is going to be our SEDD2. And then we're going to use DT's apply changes. And all we're going to do is say we want it to look for changes in households over our user ID and we want you to store it as a sedd2. And that's pretty much it. And because in our data bricks asset bundle we defined our cluster. We defined it to write to UC we can within DT's development environment just attached to our same cluster that we're going to use and we run this in a production productionalized setting and we can validate and run our pipeline. Matt mentioned the new uh DT authoring pipeline experience. This is the old one and I really like this one even. So uh so I'm excited to to use the new one. So we're able to run our pipeline from within our notebook and because within um our data bricks asset bundle we also configure it to publish to unity catalog. The second we run our pipeline our sedd2 is immediately discoverable across the enterprise. So what this means is we get everything else from Unity catalog like our data governance, our auditing, our table lineage. Um so right out of the box we can have that without having to do any extra work as data engineers. One thing I really liked when I was doing this example is this AI suggested description. So we can have um analyzing trends, patterns, behaviors of users within different households allowing for effective decision- making based on historical data. That's probably better than I would have written it and I probably just accept that as is if it was made with this uh with this uh configuration. So once we have published our data in catalog users able to find it and access it, we need to see who is using it. So if we have a publishing delay or we discover a data quality issue, we're able to make sure we're communicating with the right stakeholders. So this is something that because our data is in unique catalog, we can use table lineage for. In this example, I just grab a subset of fields. But what this fully allows us to see is who's querying our data, how and when they're querying it, and even if they're using our table to produce any of their downstream data assets. So if they're using our SED2 and we discover that there's a data issue, we can make sure we communicate and coordinate with them because we've got this table lineage to see who is actually using our data. And then if we need to go in and we need to put some data quality in, that's where we use DT's expectations. So rather than just like a generic catchall for duplicates or primary keys, we use expectations to get much more granular checks on our data. So in this example, all I do is I say on our source table, I can go in and say we expect there to be no duplicates in a given file that we receive. So users are unique within a given file. and I can apply that expectation on a uh on a particular table. So what I like about this is um we can do these granular expectations on different tables at different points in our pipeline. So you can imagine that rather than just having a single source table here, if we had 10 source tables from 10 different teams, we could go in and we could add specific expectations based on the characteristics of the data from these 10 different teams. And we could uh dive into this pipeline if needed and see exactly where our expectations failed. We could just alert kind of uh give our team a notification if they failed or we could fail our pipeline or we could quarantine those records off somewhere else and we could handle them with some other chunk of logic. So it's really easy to jump in here and see exactly where our process failed if it did. Skip this. So once we have our data published, we know it's reliable because we have expectations. Uh we want to make sure our pipelines are healthy and running as expected. So to do that, what we do is we publish DT's event log into Unity catalog. So the event log is something that we don't really have to set up. DT just gives it to us for free and it gives us information like when table or when pipeline updates start when table updates start uh who started a pipeline update if there's any errors in the pipeline and on what table they occur on. So with this we can take this and because it's kind of given up to us for free in Unity catalog we could take it into maybe like a data brick genie space and we can ask Genie to create a incident reporting visualization for us because this table gives us that information. Or we can go and we could create an alert off it. So if a table update is taking abnormally long amount of time, we could alert our team to go and dive into it. And then finally, if we do need to go and we need to dive into a specific update, what we can do is we can use DT's query history. So in query history, we can dive into our pipeline. We can check a specific table, see the statement that was executed within Spark, see the aggregate metrics for it, and then dive deeper into Spark's logical and physical plan, and see uh specifically the resources that are used for these different operations. So, if you've ever like read through vanilla Spark logs before, seen the physical logical plans, it's not easy reading. And this is a much more consumable and navigable way to get into that if we need to check specifically these updates are happening at different points along the way in our pipeline. So at that point I think we've pretty much gone and we've started from scratch and we uh got our pipeline out the door fast with our data bricks asset bundles. Then we iterated through it quickly with DT's development environment and then we used our DT expectations to make sure we're publishing reliable data and we monitored our pipelines with DT's event log debug with query history. Uh so all this to say at 8451 we have 100 and counting tagged and tracked DT pipelines using some flavor of these patterns. And what it's really helped us do is reduce the amount of time we're spending on traditional like data engineering overhead tasks and instead focus on just working on solving business problems and doing what provides value. And uh last point here I will just give a little teaser is that um I didn't mention in this use case but I have some colleagues presenting tomorrow who have used DT for streaming and some really great low latency streaming use cases. So, if you're interested in DT for low latency streaming, kind of like what Matt talked about, uh, I encourage you to check out the presentation tomorrow. So, thanks. I'll hand it back to you, Matt. Yeah. Awesome. Thanks, Brad. So, thank you all for bearing with us. Um, it was a, you know, an older version of our slides that synced to the podium, but we got through it. Um, so thanks for bearing with us through that. I want to leave y'all with some kind of next steps and resources. Uh if you're interested in learning more about DT or taking your next steps here, um certainly check out the website, the documentation, lots of great resources for getting started. I want to specifically highlight this getting started guide that, uh my colleague Frank put together. Uh he keeps it updated and maintained. This is an awesome way to learn how to write your first DT pipeline. uh just a simple kind of step-by-step instructional guide. So, please do check that out. That's online. Um I also want to highlight uh the other DT sessions that we have going on uh at summit. So, again, if you're interested in kind of doubleclick uh information in any of the areas that we talked about, these are going to be your best next steps. So uh right after this uh my colleague Stephen Yu is talking about top performance and cost optimizations for DT. Uh so Stephen is a solutions architect. He's got lots of uh years and years of real world experience working through this stuff with customers. Um so if you're interested in that, please go to his session. Uh Stephen's awesome. You will not regret that. Um then later this afternoon there's a session on getting data from anywhere into DT getting it to anywhere you need it to go kind of a double click on that part of DT sources and syncs and then later today if you're interested in SQL first ETL if you are coming from more of the data warehouse world and uh or you just prefer SQL um you can go see my colleague Paul talk about building easy efficient data pipelines in SQL with DT again kind of those last mile transformations and aggregations this is a great fit for Wednesday uh we've got a session talking about the new DT editor in depth by the PM who uh led the creation of it um and then we've got a session dedicated to mastering change data capture with DT uh that is uh led by Raju uh please go to that one if you're interested in change data capture he's going to get into the ins and outs of how that works And then finally, um, like if you go to one other DT session, I would say this is the one not to miss, uh, on Thursday at 12:30. So, Michael Armbrust, who literally created DT, he's our distinguished engineer, um, he, uh, you know, in addition to DT created Spark SQL, uh, he created Delta Lake, um, structured streaming, a number of other things. Michael has a prolific background. literally wrote the book on DT and this is going to be him going through the definitive kind of best practices and uh how to work with different use cases in DT at a very technical deep dive level. Um so uh I would recommend going to that uh certainly the keynote on Thursday as well. Um and then yeah Brad do you want to highlight uh the other couple 8451 presentations that you all have going on? Yeah. So the the presentation I was talking about with DT and streaming is that change data feed and a streaming data flow. So that one's tomorrow at 520. Get some colleagues who get some great use cases and we'll take you through a more in-depth demo. So that's an interest. Check it out. Yeah. Thanks Brad. So again, thank you so much for sticking with us today. We sincerely appreciate each and every one of you coming to our session and showing up for data and AI summit. Um, if you enjoyed the session, please complete your survey. If not, this has been Snowflake Summit. We will see you guys later. Thank you.