A Simple, Managed Platform - Modern Feature Engineering on Databricks

Summary

Declarative Features on the Databricks Data and AI platform lets data scientists define what a feature is—source, entity, aggregation, and time window—and the platform handles correct computation in every context, eliminating the need to build and maintain separate batch and streaming feature pipelines.
The capability targets high-scale, low-latency use cases like fraud detection, recommendations, and pricing where classic ML drives production decisions, and uses a Lakebase-powered online store to serve features at the low latency these applications require.
Declarative Features launched in public preview as announced in this video, with auto-scaling computation, configurable freshness-versus-cost tradeoffs, and no additional charge beyond existing compute costs on the platform.

A Simple, Managed Platform - Modern Feature Engineering on Databricks

The hardest part of real-time ML is the feature plumbing. Teams spend time creating and maintaining fragmented pipelines rather than focusing on their ML capabilities. Declarative Features breaks that cycle. Define what a feature is (source, entity, aggregation, time window) and let the platform compute it correctly in every context. this video covers Declarative Features, our managed feature pipeline offering, and explains how they can take your ML platform into the next phase of growth.
Talk By: Ian Ackerman, Software Engineer, Databricks ; Nick Joung, Sr. Product Manager, Databricks ;

Chapters

FAQs

What are Declarative Features on Databricks?

Declarative Features is a managed feature engineering capability on the Databricks Data and AI platform that lets data scientists define features by specifying the source, entity, aggregation, and time window—and lets the platform handle computation. This eliminates the need to build and maintain separate pipelines for batch training and real-time serving.

How does Declarative Features support low-latency ML serving?

Declarative Features uses a Lakebase-powered online store to serve computed features at the low latency required by production ML applications like fraud detection and real-time recommendations. The platform auto-scales computation between batch and streaming modes based on the freshness requirements teams configure.

What use cases is Declarative Features designed for?

This video describes Declarative Features as purpose-built for classic ML use cases—fraud detection, product recommendations, and dynamic pricing—that require high-scale, low-latency, cost-efficient feature delivery. These workloads power user-facing applications in production and require consistent feature values between model training and serving.

What does Declarative Features cost on Databricks?

According to this video, Declarative Features has no additional charge beyond existing compute costs already in use on the Databricks Data and AI platform. Teams pay for the compute they run, and the managed feature pipeline infrastructure is included within that existing cost model.

Full transcript

[00:07] Thank you all for coming. Uh hope everybody's had a good summit so far. My name is Nick Jung. I'm the product manager on the feature store team and I'm joined by the tech lead on the same team, Ian Arian. We're really excited to tell you today about uh some of the stuff the team's been working on um over the last couple months.
[00:20] Um we'll go through a quick intro, tell you about some problems that happen if you if companies try and build feature stores on their own. uh talk you through data bricks's solution to that problem, show you a demo of the feature we're
[00:32] launching and uh send you off with a couple words, but let's start with who this is for. If you've been at any of the talks this week, I assume you've heard a ton about Gen AI and justifiably it's completely
[00:44] amazing. It's changing the way we write code, we work, we interact with the world. But let me tell you a secret. The genai is not the thing that's driving um like high-scale decisions
[00:56] across uh enterprises in production in userf facing applications. For that you need something that's um high high scale, low latency and uh cost
[01:09] sense and cost efficient use cases like fraud detection, recommendations and pricing power the lifeblood of companies in production today. And you need classic ML for that.
[01:21] And if you need classic ML, you need features. Features are the data layer, the context that lets your models make good decisions um in real time and drives revenue, drives engagement,
[01:33] lowers fraud, and uh makes you uh competitive as you bid and price. Maya is working on these problems. She's a data scientist working at a fintech. She's working on fraud detection and her
[01:46] job right now is to improve the fraud detection rate across our enterprise by 20%. As some of the people in this room can tell you, it's not an easy task. But she's got a secret weapon. Her manager just told her that um they are setting
[02:00] up a stream platform so that she can bring in the best freshest context for her models and so they can drive that number uh down. So my develops a strategy. She wants to use uh she wants to set a baseline
[02:13] establish what a what normal behavior looks like for a given user. And then she wants to uh that would be an example of that would be a transaction amount over the last year. She wants to contrast that with what's happening right now for for the same user. The
[02:26] average transaction amount but over the last 3 minutes. Besides that, she wants to add as much context as she can to make sure the model has all the information. As an example, the number of chargebacks over the last month that might s that might signal that
[02:39] somebody's having uh credit credit card ownership issues uh doing lots of uh having lots of disputes. So Maya's got a strategy, but she also has a technical problem. There's a
[02:51] classic uh issue that feature stores have to solve, which is they compute features twice in very different contexts. They have to be able to do stuff uh uh do uh support inference at the scale and speed of their business.
[03:04] That means uh tens of thousands of queries per second in tens of milliseconds. they uh right now they also need to be able to compute the same value months or years later for training the next model.
[03:19] But Ma is smart and she's undaunted. So she dives right in. She starts by building that batch baseline we talked about the one-year average transaction amount. She can write ETL pipeline for this because it's batch data and she uh back
[03:32] fills that to an offline store. Bang she's got her training data. She needs to support inference too. So she adds a low latency online store and syncs the data from offline into online. She's built her first feature.
[03:46] She moves on to number two, the 3minut average. She considers just outputting the stream of data directly to the online store, but she realizes that's going to be slow. She doesn't want to spend inference time or the that latency budget she's got computing the average
[04:00] over a bunch of raw data events. So she adds instead a stream processor. This can uh read the intake of the stream, compute signal ready uh or yeah, model ready signals and emit those directly to the online store so that lookups are
[04:13] fast. Um and now she's got an online uh inference pipeline powering that 3minut window. But she's also got to do training data. So she can dump that same stream to her offline store and write a separate pipeline, a second one
[04:26] in order to compute uh the training data across that same three-minute average. That's the second feature. Ma is flying. She moves on to number three and she realizes there's another thing she's got to solve. We said there was a month
[04:39] window for those for that chargeback feature and she doesn't want to wait the next 29 days for that full 30-day window to fill up. So instead, she writes a backfill from the online store to the uh the offline store to the online store
[04:52] that powers the first 29 days of data and then it hands off the stream processor and now Mike can build all three of her features. We're done, right? The talk's over. Um, Mai's got a bunch of problems, though.
[05:05] This system is really uh it's it's going to be very slow to build. Look at how many times she's got to build each stream feature. And she doesn't want one of these. She wants hundreds. If she has to uh implement each one of those
[05:17] hundred three times, it's going to slow her organization down. She's also inadvertently set up two new production systems. Outages or degradations in either of these at scale
[05:29] at low latency um are going to severely degrade Maya's ability to detect fraud in real time and um that's going to be fragile. These are things these are hard to operate at scale facing production.
[05:41] Finally, um we're showing uh you know she's got two online stores since she's working on fraud. She's working with uh PII sensitive user data and PII means governance and it means access controls. We've got two stores here in a bunch of
[05:54] different pipelines. And Mia's got to figure out how to do governance and access controls across all of it. That's going to be fragmented and all of these um are going to be issues for Maya as she attempts to scale her feature store. But but and this is actually a really
[06:07] good architecture. Maya's done a nice job building this, but it and the problems are not her fault. I talked to a lot of companies that uh that work on these and every one of them suffers from some set of those problems. Slow work or
[06:22] uh duplicate work means shipping features is slow. You've got to build across teams. You've got to build across systems and you've got to write the same feature again and again and again. These systems are fragile. They're production facing and they're mission
[06:35] critical outages. There's no silver bullet here. This is engineering work. This is on calls. This is SE reviews and maintenance. Finally, we showed one example of one
[06:47] feature store, but in actuality, every version, you know, it's kind of an abstract picture. In actuality, every version of that frankenstack has different components. Maybe they're using aerospike, maybe they're using Dynamo, maybe they've got some snowflake
[07:00] data over there, maybe there's other stuff in S3. This is these are commonly fragmented, which makes lineage discovery and versioning very challenging.
[07:13] Fortunately, and I suspect everybody who's in this room might recognize themselves somewhere on the screen. Fortunately for Maya, unfortunately for you, Data Bricks is launching feature views. By the way, for anybody who was at the Coinbase talk just now, um, I neglected to tell them we changed the
[07:26] name. So, declarative features are feature views. Sorry about the confusion. Um, feature views are the solution to the Frankenste. They are simple. It's a single abstraction that carries you through the full MLOps life cycle across
[07:39] training, inference, and into multi-use case. They come out of the box production ready with missionritical use cases in mind. That means industryleading stream performance as well as highcale reliability. And finally, like every
[07:52] data bricks product, they're deeply integrated into the platform. That means unity catalog for governance. And it means a production ready uh data science machine learning uh stack at your fingertips.
[08:04] Let me tell you about why it's simple. This is the slide we just showed. This is Maya's. We said it was a good feature store, but there's a lot to worry about here. And we talked through the problems in the new world with feature views.
[08:16] Maya has to think about this. There's one feature that encapsulates a view which shows or which tells the platform everything that it needs in order to support both training and inference across both batch and stream.
[08:29] But views don't do inference or training. So how does this really work? The view is the what? It encapsulates a source, a time window, an aggregation function, and it tells the platform how
[08:42] to compute um the feature value in different contexts. Those different contexts are taken care of by the managed platform. That's the how. That means at training, all Maya has to do is
[08:54] uh interact with an SDK that's purpose-built for um quick experimentation. And at inference, she just gets an endpoint to look up via HTTP uh her feature values. These are the main touch points with Maya's new feature store.
[09:07] Much less maintenance, much faster to build. Let me show you exactly how it works. The experimentation layer um is uh is a particularly powerful thing for data scientists like Maya. She can write
[09:20] that one feature and that one feature supports both batch and streaming data formats and it supports like I've said the full life cycle uh across training and inference and multi multi multi models.
[09:32] it it's particularly uh optimized for experimenting really quickly. She doesn't have to set up any ETL. There's no pre-work. Instead, she relies on the SDK to compute uh historic feature values that she can explore and generate point in time accurate uh data sets
[09:45] based on her labeled data frames. When she's ready, she can hand the um this feature out off to the manage platform by materializing it. And I'll leave you with Ian to tell you about how that
[09:57] works. >> Thanks, Nick. Uh Nick told us just how simple and easy it is to use feature views. Uh I'm going to dive a little bit more into the technology that underlies
[10:09] uh feature views to make it ready for production. So we had this view here before of the feature store. You have your input data and your output inference and training. Now let's peel back the layers here so we can see some
[10:21] of the technology. Um and the first technology I want to talk about is lakebased autoscaling. I'm sure folks over this conference have heard a lot about this. Uh Lakebase is a
[10:33] new database engine designed for the modern era. It separates the storage and the compute. Uh this allows really low uh cost as well as a lot of flexibility
[10:46] on autoscaling. Uh so the first part of that the storage is uh designed really great for our batch use case and we have great tools that allow us to quickly and
[10:58] efficiently sync that lakehouse batch features that are computed into the storage and make that available for online uh serving quickly. Um, and the compute I just talked about autoscaling
[11:11] in the name, it makes it really easy to react to when you have new uh, incidents or new uh, customers coming in that need your model inference. Uh, you can scale that up on the compute layer and support
[11:25] uh, read and write replicas uh, to ensure uh, write and read uh, separation there for updating the data. But we're not just Maya's not just interested in batch data. She's trying to solve her
[11:37] streaming problem. So we have been working on making sure that we have low latency rights for the online store. So she has her stream processing engine and
[11:49] we worked hard so that you can sync directly from that stream processing engine into lakebase. So previously you might have to have written your data to delta run a sync job that takes tens of
[12:02] seconds minutes. Now we can do this at uh milliseconds writing directly from your stream job into lakebased compute. This handles all the scalability across multiple workers on your streaming job.
[12:14] Um uh all things like that are taken care of. Um so now we have our streaming data and our batch data inside our online store inside lakebase. Uh now we need to use it for inference. Uh the
[12:26] good news is that all of the feature serving endpoints that you folks might have been used to uh for feature store our GA product here we've worked so we can integrate that same serving solution
[12:38] with um lakebase to serve feature views for streaming and batch features. So this means uh that scale that you're used to tens of thousands of QPS at tens of milliseconds supports this new
[12:51] feature authoring experience. So we've talked about lakebase but the other big key component technology that allows us um to move into streaming is
[13:03] uh spark uh structured streaming um and there are two big parts uh to any streaming job. There is uh some business logic processing part and then there's some stream aggregation. So the business
[13:16] logic part here, this is where you can do things like uh where you have your raw event data of transactions, user clicks, things like that. Allows you to do filtering, allows you to do massaging of that data so you can get it into the
[13:29] right format you want for your feature. And then it has stateful streaming aggregation local to the pipeline. This is a local Rox DB instance that allows us to uh check that full state of the
[13:42] history whether it's Maya's month-long feature or her three minute feature. Uh add this new event to that data and get the full aggregation. So the full accurate sum over the last month and we
[13:54] can write that into lakebase. Uh and again this gets back to what Nick mentioned. This ensures that we can have that lookup at the feature serving endpoint take that tens of milliseconds to meet your key uh latency there.
[14:09] Now, real-time mode is a special mode optimized for low latency. Uh so, Spark historically is a great processing engine, handles very good large batches
[14:21] of data, but it struggled in this real time uh milliseconds level. And so what it does is it will take each stream event and it will run this business logic aggregation and writing to to lakebase at each record level. So it's
[14:35] not waiting for batches to complete. It's not writing for different compute stages to be ready. It's going and flowing as quickly as your data is coming in. Um and now for the time it
[14:47] takes for that click that fraudulent data to land in the lake base. Before it might have taken Maya tens of seconds, minutes depending on her feature stack technology. Um, with real-time mode and
[14:59] spark streaming, we're able to do this in 200 milliseconds. So, that is a huge differentiator in terms of having your model react as quickly as possible. Is that a new fraudulent transaction? You
[15:11] can react 200 milliseconds. Is that a new user who just joined clicked around on the website? 200 milliseconds. You can design and update your model to give them better recommendations. But don't just take my word for it. Uh,
[15:24] as Nick mentioned, Coinbase is, uh, leveraging uh, real-time mode heavily and they're seeing 80% reductions in their latency for their streaming pipelines. Uh, this is a huge deal for
[15:36] their business since that means that uh, catching fraud, check catching bad transactions, uh, that's a key business differentiator for them. uh they're using this across hundreds of features and they've been a big partner in
[15:49] helping to evolve uh feature views as a product. Um but uh this real-time mode is great if you want that low uh latency, high
[16:01] freshness availability, but um that's not always what you need. Sometimes you want to be a little bit more cost-sensitive and trade off against um how you uh quickly you generate your
[16:13] features. Um, and this is where we will still support uh batch mode where you can take a subset of your streaming data, feed it through that same pipeline and process it in stages. Uh, this is
[16:26] called microbatch mode in Spark and this is great for tens of seconds. So, it's more efficient in terms of cost and compute that you can uh calculate this data in batches, but you have to trade off uh for those lower uh u higher
[16:40] latency use cases. Um and because feature views define the what the same feature view could be used in either way. Uh and the final mode of course is your uh batch data, right? Uh you'll
[16:54] have that same business logic, same aggregation. The same principles apply here in terms of what you're doing. Uh but this can work at the lakehouse scale. This is terabytes of data, years worth of of transactions, history. um
[17:09] will allow you to define that feature, materialize it, generate that full historical snapshot to store in your offline store um so that you can use it for quick back batch inference or training and we will incrementally
[17:22] compute new data as it arrives. This is great for tens of minutes uh hours or days of reaction to new data coming in where uh you incrementally compute the
[17:35] those transformations uh write it into your uh online store for for the new values that come in. Uh so this is great. Maya has her streaming pipeline here. It works uh all
[17:47] the way from business logic getting to the serving endpoint. Uh but she has this training that she needs to handle. And this is where um the feature store helps uh set up an ingestion job to copy
[18:00] that streaming data into the lakehouse. Uh and this is really key because it helps her satisfy, you know, a few different use cases. A big one is testing new streaming features. If she writes a new feature view, it has a
[18:14] different aggregation uh length. It has maybe instead of average, you're doing a sum. You can experiment and play around with that. uh having that uh historical data there and having that same logic
[18:26] power um the streaming and the uh offline uh logic let make sure that we can calculate that uh correctly point in time joins all that sort of thing that you need for training uh and it lets us
[18:39] back fill those features. So for that 30-day um feature, we can calculate those 29 days offline using that historic data and sync it into lakebase for serving.
[18:51] But uh I walk through all this complicated uh technology, all this good stuff in lakebase uh spark streaming feature serving endpoints. But again uh this is a managed system from us and you
[19:05] can put that all back behind the box and just think about the feature and declaring the sort of business value the feature logic that matters for you. Um yeah and of course this is integrated
[19:19] into the rest of the data bricks ecosystem. So we have our feature platform here. You have inference you have training. What does that look like? Well, the feature engineering client uh that that we have here uh lets you do
[19:32] those point in time accurate joins, lets you create those training sets and integrates with MLflow so that you can train and log those models and we have the lineage associated with that model
[19:45] such that uh when you go to serve that model uh it knows all the features associated. it knows where to look it up in u the online store and so all you have to do is feed in the query for the
[19:58] user certain request time features and it will give you the prediction fraud or not from Maya um and uh of course this is all backed and stored in unity catalog this means the feature object is
[20:12] a first class object in unity catalog you can govern that you can discover it there uh as well as the models that you train that rely on those features. Um,
[20:24] and so now I'm going to hand it back to Nick to walk us through Maya's story now that she has feature views. Thanks, Ian. >> Cool. So, we told you we'd fix Maya's problems, and we learned how that simple
[20:37] um managed solution can get her both a great developer experience end to end across the machine learning life cycle, and how uh the pipelines that come out of that managed platform are ready for production and how all of it sits inside
[20:50] of a wider uh data platform that covers governance and uh the you know, endto-end um data science journey. Um so, Maya's happy, but talk is cheap and uh we can prove it to you. Maya only h
[21:02] this is the whole API surface. Maya only really has to do kind of like three tasks to go end to end from an idea to production. And remember we said that this used to take teams of people weeks and months. Um you can do this in a
[21:15] notebook on data bricks in 10 minutes and we'll show you.
[21:29] Um cool. So uh for the demo we're just going to solve my problem. We're going to build the three features we talked about, that year-long average, that threeminute average, and the one-month uh count of chargebacks. And we're going to be working with the same data sets that Maya worked with. She's
[21:41] we've got the historic uh batch data and that recent transaction data coming out of Kafka. And this is our first feature. Features have sources, optional names.
[21:55] Um in this case, it's a delta table source, which tells you it's a batch source. Um, sorry, I should have mentioned we're building her first feature. Um, features have entities that tells us the primary key that we should
[22:07] be looking up. There's a time series column which tells us for a given row when should we count that as having historically happened. The really interesting stuff happens in the aggregation function though. We said that we wanted to build an average transaction amount over the last year
[22:20] and here we've got an average transaction amount over the last year. That's awesome. We can just use this. So if we scroll down, we will compute the feature which is going to generate a bunch of historic uh data that Maya can
[22:34] really dive into and get her hands dirty with identifying outliers, doing the work of a data scientist. She can also come back here and notice that I did something wrong in my definition. This is a sliding window, which means that it's going to refresh every 7 days, the last 365. It's more
[22:48] normal to make these one day. So let's do that. We can edit this because there's no pipelines running yet. and we'll just recmp compute the feature values from that new definition. So this is really fast to iterate over and explore.
[23:00] But I'll leave you to figure out the the details of the data and we'll move on to my second feature. Um this is a stream source. We'll come back to that uh thing in a minute. Um this is a stream source. Uh sorry. So
[23:12] same feature name source entity time series column and function. It looks pretty similar. Um but if you look closer there are a couple differences. First of all, we're using that stream source um which is which is pointing to Kafka instead of Delta. And what that
[23:25] enables is for us to use a rolling window across three minutes. So these are very different pipelines that run, but the same ab abstraction works in either case.
[23:39] And the um rolling window just to double click on it um is is the uh online right path that Ian mentioned earlier. It's the thing that keeps the freshest possible data available in the online store at all times. So when you look or when you look for it, you know that it's
[23:51] uh 200 millconds fresh. So that's the second feature. That's awesome. Moving on to number three. Um we uh we see again same uh same abstraction looks
[24:04] pretty similar, but there's a slight nuance here. The first two features we propose only are averaged over every single row in our data set, batch or stream. For a chargeback feature, we only care about a subset of the rows.
[24:17] Fortunately, stream source has a filter condition which lets us zoom into the uh rows which only have or which have chargebacks set to true and then we can do a count over that to generate the feature that we want. So, we've built Maya's uh full feature stack in just a
[24:31] few minutes here and we can load it all into a feature uh array just to keep moving. Um we're going to move on now to training and typically data scientists would have to you know go and write a
[24:43] bunch of uh uh joins here but instead we've or sorry we've got a training set which um has a couple users pre-populated and a fraud label pre-populated. This is obviously a toy um but typically you'd have to go write
[24:55] a whole bunch of uh joins here. In the new world you get this SDK function called create training set. You pass your training labeled data set along with these ephemeral features that we've defined in a notebook and you can just run this. We we push the point in time
[25:08] joins uh down under the hood for you and generate um training data across both batch and stream. So, we've got our user ids. We've got our fraud uh flags or sorry,
[25:20] excuse me, our fraud labels. And we've also got uh batch and stream data unified here. Um and behind the same API and something jumps out at me immediately. User 7 and 8 have a really
[25:32] high number for this average transaction amount over the last 3 minutes. Might be worth remembering that in a bit. Um but it gives me confidence for now that we're on the right track. So, let's productionize these features. I'll pass you back to Ian.
[25:44] >> Thanks, Nick. So we just walk through how easy it is to do the experimentation of this and this is really the domain of data scientists playing around in a notebook and so far everything we've shown doesn't require any external
[25:58] systems any production pipelines to maintain it all stays locally contained uh in that experiment environment. But now we're ready to go to production. And so what we're going to do is we're going to register these features into Unity
[26:11] Catalog. You take those same features that we had before. Uh you provide a catalog and schema and you can register them. Uh and these will now um show up in Unity catalog. And um that's great.
[26:26] We registered them. Remember their feature views. They're registered. You can discover them, but that still doesn't mean there's any pipelines or they're available for um production. So we need to materialize them. And so what
[26:39] does materializing look like? This means you're taking um you want to put them in your offline store and your online store. So here we provide uh the config where we want to store them uh to store
[26:51] the offline data and the online data. And here you're providing your uh online store name. This is uh the existing GA serving stack uh powered by lakebase uh that the data bricks feature store
[27:04] already has. So here we're materializing the batch features offline and online. So you can use it uh for batch inference or online inference. And for a streaming feature, same thing. You're going to take and uh specify that same uh
[27:17] lakebased location uh online store uh and and store and govern that in Unity catalog. Uh so we can run this uh to materialize these features. Um uh this will create the pipelines
[27:31] which then need to get spun up and start running. And in order to uh serve that you would uh create a feature spec uh sorry >> um oh and um yeah and uh before we go
[27:45] and look and serve it let's go ahead and look at um that data in UC. So this is the normal catalog explorer that you're used to seeing for all your tables and functions. Your feature will show up
[27:58] here. It has uh a nice summary of of what's available. This is the transaction. This is the slide, the entities, and it has a links to those online and offline materialized uh
[28:10] locations. Um so you can go look at those when they're materialized information like that. Uh and then the last step, now that these uh features are materialized and available, we can
[28:22] go create a feature spec uh to serve them and create an endpoint uh to go query. Um, this takes, you know, around uh 10 minutes. So, we're going to skip over that for the demo. And we already
[28:35] have an endpoint set up. Uh, and here you use the same uh API and functionality that you're used to for feature serving endpoints. You have the name, you have your input here. We're
[28:47] just taking a user ID and you can query it and get back that response. Super low latency. uh you can use uh the different uh features uh different users that
[28:59] we've talked about get different values. Um but it's hard to kind of see in a notebook how quick this is happening. So we have uh a bit of a demo here of some
[29:11] fraudulent data uh that's coming in. So let me explain the data set here. Uh this has uh 10 users uh here that are uh regularly getting um fraudulent data
[29:23] every 60 seconds. A different user is getting hit with fraud. Uh we're tracking on the lines here different feature values. Right here we have the average transaction amount. And we have in red highlighted when that fraud is
[29:36] going to occur. And what you can see is these uh feature values are sort of stable there for these users. not much transactions are are happening and then as soon as the window hits for fraud uh
[29:50] it instantly jumps up. We can see this is just about to happen uh for another user. So you can see that instantly climbs up. It's reacting in real time 200 milliseconds versus tens of seconds
[30:03] maybe minutes for batch things like that. You can react as your business right away uh for your models to take use of that feature. And the other thing to notice, we talked about the rolling windows. It's when features enter and
[30:15] when features leave. Um so those events leave, we can see um the values going down. Uh as those fraudulent transactions leave that 3minut window, uh the value corresponds down. This is
[30:27] tricky to get right to make sure that you're doing this sort of stateful management correctly. This all comes out of the box um in feature views. So um stepping back we've shown in this demo
[30:41] uh how simple it is to define. we took in our notebook going from uh those ideas of the batch streaming uh features defining them uh registering them materialized um we see how this is uh
[30:55] production ready um and able to use spark streaming real-time mode u um lakebase and uh integration shown in unity catalog.
[31:08] So um yeah to to close out uh and yeah so you might think uh how expensive is this going to be? Uh well if you already are
[31:20] running these uh feature uh pipelines you're Franken stack already. Um you're already paying for compute you're already paying for storage. We're not going to add any extra cost on that. That same compute uh compute and storage
[31:34] that's what we're going to charge you to run this. There's no extra charge on top of what you would pay for lakebase, uh, Spark streaming, uh, feature serving, etc. Um, and this is going to be available soon, uh, next week. It's
[31:47] going to be in public preview. Uh, this is available in beta for folks to try out and experiment with and, uh, start playing with features like Maya did so that you can start productionizing
[31:59] things next week. Thank you everyone.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.