Forecasting at Databricks: One Framework Behind Consumption and Infra Cost

Summary

Databricks data scientists built a unified forecasting framework used internally for both consumption forecasting and infrastructure cost forecasting, addressing the shared challenges of stakeholder trust, model accuracy under hierarchy, and data signal quality.
The framework prioritizes explainability and defensibility through decomposition by business dimension and a human-in-the-loop planning app on Databricks Apps that lets domain owners review forecasts, apply overrides, and inject domain knowledge before finalization.
The backend uses AI_Forecast() scheduled on LakeFlow Jobs for automated model selection across hundreds of thousands of cost dimensions, with Unity Catalog and Metric Views forming the governed data backbone and Genie Code enabling plain-English cost overage diagnosis.

Forecasting at Databricks: One Framework Behind Consumption and Infra Cost

Consumption forecasting and infrastructure cost forecasting at Databricks share three challenges: trust and stakeholder adoption, model accuracy under hierarchy and outliers, and data signal quality. We addressed them on a unified Databricks-native stack. For trust and adoption: a self-serve human-in-the-loop Databricks App lets infra cost owners review recommended forecasts and inject inorganic shifts the model won’t see, while AI/BI dashboards and Genie Agents let users self-serve insights, and decomposition keeps consumption forecasts explainable. For model accuracy: Unified Forecasting Framework, the backend behind AI_Forecast() function scheduled on Lakeflow Jobs validates model selection across the hierarchies. For data and signal quality: Unity Catalog, Metric Views, and Lakeflow form the governed data backbone for cost forecasting and the feature-selection substrate for consumption. Attendees leave with Databricks-native patterns for forecasts domain owners self-serve and leadership defends.
Talk By: Alex Wang, Sr. Data Scientist, Databricks ; Ginger Holt, Sr Staff Data Scientist, Databricks

Chapters

FAQs

What challenge motivated Databricks to build this forecasting framework?

The framework was motivated by observing a six-month gap between when accuracy improvements were made to a forecast model and when business stakeholders actually adopted and trusted it. The team found that technical accuracy alone was insufficient—forecasts also need to be explainable, defensible in executive reviews, and diagnosable when anomalies occur.

How does the human-in-the-loop planning app improve forecast adoption?

The planning app built on Databricks Apps allows infrastructure cost owners to review recommended forecasts and inject knowledge about inorganic shifts—such as known one-time events—that the model would not otherwise account for. This collaborative construction process significantly increases stakeholder trust compared to an adversarial handoff of a finished model output.

What is the AI_Forecast() function and how does it fit into the framework?

AI_Forecast() is a Databricks function that automates model selection and validation across forecast hierarchies, forming the backend of the unified forecasting framework. It is scheduled on LakeFlow Jobs to run across hundreds of thousands of infrastructure cost dimensions, selecting the most accurate model for each series without requiring manual experimentation.

How does the framework help domain owners understand cost overages?

A Genie Code agent layer allows domain owners to ask plain-English questions about cost overages and receive contextualized explanations grounded in the Metric Views and Unity Catalog data backbone. This brings self-serve diagnostic capability to non-technical stakeholders who need to defend forecast numbers in finance reviews.

Full transcript

[00:08] All right, welcome everybody. Thanks for joining us this morning. Um, we're going to talk to you about forecasting at Data Bricks. So, raise your hand if you've ever built a forecast. A lot of people. Great. Okay. Ra, keep
[00:20] your hands raised. Raise your hand if you've ever used a forecast. Okay, not quite everybody yet. Um, raise your hand if you're interested in the financial forecast of Open AI or SpaceX
[00:33] or Anthropic. Oh, there we go. Okay. All right. All right. So, hopefully that covers everyone. Um, Alex and I were both data scientists at Data Bricks and u we're here to share a forecasting
[00:45] framework with you that we built and we use every day. Um this talk our plan is to first describe at a high level this this forecasting framework and then walk you some of the some uh through some of
[00:58] the operational details on applying this framework at scale for uh managing infrastructure cost uh for engineering teams.
[01:12] Um okay I'm I'm Ginger Hol uh again a data scientist at data bricks. have more than 25 years of uh forecasting experience in many different industries including energy, finance, retail, technology.
[01:24] Um, and often forecasting is a first use case for data scientists when they're working uh with business partners. Uh, to me forecasting it never gets boring or monotonous because things are things
[01:36] are always changing. All right, over to Alex. >> Yeah, hi everyone. Uh this is Alex Wang and uh I also like Ginger I'm a big fan of forecasting working in the industry for more than 10 years. Um previously
[01:49] compared to you know data bricks I mean previously to data bricks I work at Amazon and Lmon apply forecasting to demand and capacity planning.
[02:05] >> All right great. So George box said all all models are wrong but some are useful. uh what he didn't say that even some useful models are get rejected by the finance team because they can't defend the numbers in in in a CFO
[02:18] review. So I'm going to start out. Let's do a quick audience poll. So grab your phones. Uh we're going to answer this question. What's the hardest thing about forecasting work?
[02:31] There are five options um in that survey. So pick whichever one resonates with you um on a day-to-day basis. First one is communicating uncertainty
[02:44] to non-technical forecast consumers. Second option is anomalies. Third option is um having unavailable or lowquality data.
[02:56] uh choosing the right model or the fifth option is getting forecast consumers to trust, understand and adopt the forecast. All right, so vote your
[03:08] honest experience. There are no wrong answers here. Um if you've never built a production forecast, just vote the the one you think should be the answer. Um and what you answer is going to kind of emphasize uh what I highlight in the
[03:23] rest of this this talk. So, I've got my own vote in mind and we'll we'll see if the room agrees.
[03:42] Oh, they randomized the choices here. Okay, that's that's good. These guys know what they're doing. Okay. Yeah. So pretty there's a there's a tie here between uh unavailable or lowquality data that's kind of getting more votes
[03:55] getting people to trust and adopt the forecast and communicating uncertainty. All right, thank you. Thanks for thanks for participating in that. So
[04:07] uh who voted uh for getting forecast consumers to trust the forecast? All right, so that that was my vote. So whatever you voted the punch line is um
[04:19] most forecasting talks are about this this left uh line here the red line. Um this talk is going to be about that black line which is the adoption. So the
[04:32] red line measures model accuracy right we want to increase uh the accuracy of our model. Um this talk is focused on that black line or the adoption line. So months ago we had uh improved uh the
[04:46] accuracy of our forecast quite a bit. Let's say we had an 80% uh reduction in error. Uh but the gap forecasts the the finance consumers uh of the forecast
[04:58] didn't want to adopt that forecast and there was a big six-month gap in before adoption and they kept publishing the the old number. So the gap is in between the
[05:11] accuracy improvement and the adoption. That's what uh we're going to talk about today and how to get that curve that to shift that black curve um to the left. Uh because accuracy is really table
[05:23] stakes here. It gets you to the conversation uh but it doesn't win that conversation. Okay. When forecasters get asked how good is a forecast, we reach for our
[05:37] vocabulary like mate, RMSSE, bias, etc. Uh the all these this word cloud is generated from our our forecasting codebase. Um so we're proud of these numbers. We tune them for a living.
[05:51] Um here's the problem. This is what finance hears. It's not a a signal. It's jargon,
[06:03] whether to anchor their hiring plan to the forecast, whether to commit their cloud spend based on this forecast or to put this number in front of the board of directors.
[06:15] None of those terms actually answer the question, is this forecast worth adopting? And can I stand behind it uh in a room when somebody pushes back on the number? And that's the gap here, right? Accuracy
[06:29] metrics describe how accurate the forecast is, but they don't say anything about how to defend that number to other people, right? It can still have an optimal MATE or whatever error metric
[06:42] you're using, but it can still be unadoptable because the moment somebody asks why did that number move or that's not what I expected, then that metric is
[06:54] not going to get you the answer to that question. So we stopped leading with accuracy and we started asking a different question which was not how good the model is but what the model a forecast can tell you.
[07:08] And so refraraming that uh gave us three properties. So that six-month gap between the accuracy improvement and the adoption came down to to three things we had to
[07:20] build into the forecasting process. So and these properties are not model properties. um these are properties of what the model can tell you. So the model has to be able to answer
[07:33] the question why did that number move in a language that uh your stakeholders can understand um explainable. So that's the explainable pro uh property. Why did that number move? Second property is u
[07:47] defensible. So the model has to be able to with withstand the question but that's not what I expected. not by getting more accurate but having a clear uh reproducible reason for what
[08:01] why the model is telling you what it is. And then the third property here is diagnosible. When the model is wrong, which we know uh all models are wrong, there has to be a clear place to look to find out what
[08:15] broke and what to override or change in your model. So again, accuracy is how you get that conversation started. And these three properties are are what's gonna uh get the conversation
[08:28] finished. So let me let me show you what each one of those looked like for us. Okay. The first property of explainable and the test is whether you can answer
[08:41] that question that most common question that finance asks um why did the number move without saying well the model updated. In this case, here's in this example, we
[08:53] have the forecast in April. So, we call it a vintage because it it was shipped or uh you know, produced on a certain day. So, our forecast in April was 312 million. And then by our next vintage,
[09:06] the next month when we update um our number, we get we went from 312 to 325 million. So instead of one move number, we hand back five named signed pieces of what is
[09:21] contributing to that delta. Right? So I've got plus 9 million from the stronger actuals that came in throughout the month of April. I've got a trend revision maybe mean reversion, right?
[09:34] That's decreasing that by four million. I've got a Q4 seasonality component that's going to increase the forecast by three million and then I've got a cohort
[09:47] of new customers who joined that is going to increase my forecast by by 5 million. So u the point is that explanability isn't a property of the model itself.
[09:59] It's whether uh the model can tell you uh why that number moved. And the second property here, defensible. This is a situation where somebody asks, well, that's not what I
[10:12] expected. And you need more than just conviction, right? So, one example you can show is um how your model beats some some very obvious alternatives on the same history. So, our finance team uses
[10:26] a lot of historical growth metrics like month over month or month over month growth, quarter over quarter, year-over-year, etc. And you can show how your model compares to those, you know, naive forecast or
[10:41] consensus forecasts from groups of stakeholders or, you know, kind of some basic u growth historical growth metrics, right? And the the model is adopted not
[10:53] because we like it. It's adopted because it wins wins the bake off. So it's defensible. The third property here is um diagnosible. So even a good forecast gets doubted and
[11:07] the question is whether or not you know where to look instead of relitigating that whole model development process. So here's our example. Um you can
[11:19] localize in two dimensions. You can show the error uh by horizon. Um like how many months out are you predicting? Right? that scale uh that vertical scale goes uh increases in horizon uh from top
[11:33] to bottom and then from left to right uh you have the uh forecast ventage. So the time you're making that forecast. So in this example here we have everything is green except for long long horizon
[11:46] forecast issued during this holiday period of November and December. And the reasoning here could be that, you know, basically holiday consumption
[11:58] slows down, people go on vacation, uh, right? So softer actuals could be leaking into your um your forecast accuracy at those longer horizons.
[12:11] So again, those three properties, explainable, defensible, diagnosible, not properties of the model itself, but properties of what the model um can tell you. All right. So if the change is really
[12:23] the question then here's the shift that answers it. We want to stop publishing just uh thinking about our deliverable as that final um published
[12:36] number right we want to ship a decomposition of that number. So uh this is a figure that your board sees or approves or reports or whatnot. Um but in order to answer that question
[12:50] of why did it change, we want to decompose it into two axes um not just one. The left panel here we have um our first decomposition is is where you slice that
[13:02] forecast. And you're going to slice that forecast by the dimensions your your business is organized around. In our case, we look at entity um like account or sub business unit, business unit,
[13:14] etc. We look at geography. We look at different product types. We look at different time horizons. And all of these are going to all uh combine multiplicatively. So you get,
[13:26] you know, all these cells that you're generating your forecast at. And um your decomposition is going to be different. That's that's the point here. But the shape is the same. Every slice is going
[13:38] to get a named number and a named owner. So nobody is staring at just a black box. And then the second axis here set of axes is uh the second decomposition
[13:52] which is how you build that forecast. And this is the one people miss a lot of times. And we're decomposing this number from the sources that actually know what's going to happen in the future.
[14:05] Right? So of course we have our statistical model based on historical data and patterns and and trends etc. So that's what data science owns. Um the second component here are these
[14:18] um human inputs. Examples of these would be new signed contracts from customers, planned product launches for example, uh things that history can't see like you know
[14:32] maybe doing a a promotion or discount. Everybody loves discounts, right? Um and then the third component here is acce these named exceptions and these are entities that we should be treating
[14:45] separately because we don't want to contaminate those growth patterns with uh the the other the other um statistical model, right? And these all combine additively
[14:58] for us. Again, data science owns the model. We may have some input from sales on you know future discounts etc. Those are the the the inputs and then some exceptions that we're going to make
[15:10] which we're going to like override or have different uh dynamics for for computing those forecast. All right. So then you put all of those um cells and combine those cells together and then that's what you get uh
[15:24] the publish number. So the model plus your inputs plus your exceptions.
[15:37] Okay. So, um the technical pieces in this framework really don't work unless the process around them works. Um this is a typical default pattern. I've been in a lot of different companies over the years and um experienced this sort of
[15:50] dynamic um many times. So, it's the handoff model. The data science team builds this um very robust, very statistically rigorous uh model for
[16:02] generating the forecast, hands it over to the business, whether that be finance, sales, etc., whoever your your stakeholders are. And then the stakeholders question the forecast, right? You get this adversarial loop,
[16:16] separate parties and the the stakeholders are end up questioning the model even when the model is good because it can't answer that question of of why did it change.
[16:31] Instead, this is the pattern that builds trust. This human in the loop pattern, right? And this pattern is built on that those technical components of the decomposition architecture, your input schema, uh the success criteria you're
[16:45] going to use to ship and adopt the forecast, the review cadence that you do, the retrospective um view on accuracy and attribution and all of those. And this uh component uh decomposition,
[16:59] it matches your org chart. So the right people are are owning the right components and that input schema is all co-designed uh with the people who are going to use it and input their their
[17:11] knowledge into the forecast again. So this is the the hardest this is the biggest shift. It's the cultural shift, right? Changing people's behaviors. Uh but I I believe it's also the highest leverage um change that you
[17:24] can do. All right. So a forecast only matters if the business is going to adopt it, right? We really care about that black that black curve and accuracy is not the
[17:38] bottleneck. Adoption is and it it spells out in these these five different um things that we've we've talked about so far. And this acronym is is adopt, which is what we want. We want the forecast
[17:50] adopted, right? So a we're going to agree on the framework first, the definitions, the data input channel, uh the success criteria, and we're going to settle all of this before the model even
[18:03] exists. And this is the cultural shift, right? It's the hardest one. You're you're building the forecast with finance and sales, not in this adversarial loop, and you're not handing it over to them. It's
[18:16] really this joint construction of the forecast. and think about not your final number as a deliverable. We're thinking about that decomposition as a de as the
[18:28] deliverable. So we're going to sh stop shipping just a plain number. The number is just the rollup of all of these components which you've um decomposed, right? And what you actually ship and you're
[18:41] able to defend is that breakdown underneath it. So, a d th those are the two that set it up, the whole cultural shift and and what you're actually going to deliver. And the next three are what that
[18:54] decomposition buys you. And those are our three properties. Kind of renamed them here in different terms to to make this adopt um acronym, but the O is the explainable property, right? We've got
[19:07] an owner for every slice. uh there's no um there's no black box and you're able to explain the forecast uh and and why the the number moved because you can you
[19:20] can have the these different components and explain um how each of those is contributing to the overall movement. The P is proving that it holds. So we're we're um producing uh prediction
[19:34] intervals, right? We've got our uh statistical back test that shows how we're beating um other other alternatives or baselines. And this is going to make our model defensible on
[19:48] the accuracy perspective. And the final one here is t to trace every move, right? And that attribution is going to localize that overall movement into um different components.
[20:04] And when we do a an investigation on on why the number moved instead of a two-day slack thread, right, we've got just two minutes of where where is that that underlying change coming from. All
[20:17] right, so that's our acronym that adopt. Um, and again, none of these properties are of the model itself. It's uh the properties of what the model can tell you. So that's the whole game. Now I'm
[20:29] going to pass it over to Alex who's going to walk you through some of those um operational details on how we built this um on data bricks and at scale really producing thousands of forecasts
[20:43] of all the infrastructure needs that our engineering teams uh need to to build the services. So over to you Alex.
[21:00] We're presenting our shared infrastructure framework and uh in my section I'm going to share how we scale the same framework explainable defensible diagnosible at infrastructure cost space. It is hard to operate the
[21:14] framework once the forecast breaks outside the notebook across hundreds hundreds of teams who doesn't actually own the notebook or build notebook. So firstly let's look at how the
[21:26] infrastructure cost is incurred at data bricks. On the left hand side of this slide you see there's a handful of shared infrastructure platforms. These are platforms Kubernetes compute storage
[21:40] networking data. So they are the platforms that actually receive the bills from cloud providers. But here's the catch. They receive the bill but they don't own the usage. So
[21:54] they own the platform efficiency. They own the unit cost of serving the usage. So in the middle of this graph you have hundreds of services and teams. They are
[22:08] the teams who build up the features the SQL the notebooks whatever you run on data bricks but they are the consumer of the platforms. And when you multiply them together,
[22:20] this is a hundreds of thousands of forecasting dimensions which is in this federated planning system. It is critical to get each dimension correct when you plan your
[22:33] cost. And give you example, you are not just forecasting Kubernetes compute. You are forecasting inch notebook team specific usage of CPU hour, memory hour,
[22:46] storage in AWS cloud and in pro environment in specific region. So there's hundreds of thousands of dimensions and when you have that man of
[23:01] dimensions no one can really eyeball it. So we have to build a end toend forecasting system to apply the framework that Ginger just introduced and I'm lucky as data scientist data
[23:14] bricks we got to build our work natively on the platform. So moving from left to the right you see the whole life cycle of our forecast. Firstly decomposition. This is a
[23:27] decomposing the cost into unit cost the usage and once that actual data are ready and decomposed they are validated. It fit into our forecasting pipelines
[23:39] and there we we develop shared components like the AI forecast functions and driver based forecast method and they are going through the back testings frameworks. The back
[23:52] testing framework are shared between usage and unit cost and we are able to re recommend what is the best forecast method for each of those hundreds of thousand dimensions using historical
[24:05] data to back test it. But I would say that's not the important step. The next step is the most critical is review and a plan because the model can only give
[24:17] you a draft. It's only the baseline. the model will never know you know yesterday lakebase launched in dice. So all those in inorganic things that are never show
[24:30] up in the history we need the service teams and platform teams to own their decisions to build in their business context into the forecast. So that's a review on a plan and once
[24:44] your forecast are becomes a plan you combine them into dollar the usage multiply unit cost and guess what is will start to drift from the first day
[24:56] you you publish your forecast and you have to set up your diagnosed pipelines to keep monitoring your forecast versus actuals and you want to create your alerting system to ask people to react
[25:08] to the deviations. So that's at a high level how our forecast you know flows from the front end of de composition to the end of diagnose and reaction and in this
[25:22] massive federated system to keep it explainable defensible diagnosible. We build a build this end to end system around three layers. The three layers
[25:34] starting with the people. So if you zoom out the entire system is built around one core component which is the people because we decompose each
[25:47] dollar into usage unit cost. Every single dollar gets a named owner of the forecast and actual the service team plan their usage on the platform and the
[25:59] platform teams owns their efficiency of the unit cost. So you might notice who don't own the forecast numbers the data science team
[26:11] and as data science team we own the three tooling layers we pro provide the self-s served tools. So that's how we scale the framework by keeping us
[26:25] outside of the final ownership of numbers but the people closest to the business decisions stay accountable of the forecast and we don't scale by having one centralized data science team
[26:39] review hundred thousand of rows of forecast. We scale by distributing the ownership and to distributing the ownership you build those three layers. And so that's the planning app, the data
[26:52] backbone and AI agent assistance. So I will walk through how we build those three layers. And starting with the planning app.
[27:07] So the planning app is the idea of the model can only gives you what they can predict based on history. It doesn't know about next month's product launch. Only the service team knows that. So to make the forecast truly explainable,
[27:21] defensible, the consumer has be able to has need to be to see what does your baseline model drafts, how does the actual looks like, what is your forecast compared to the actuals and then they
[27:34] can really own their decisions on oh maybe we should choose another forecast method or maybe we should layer in there's a new region launch next month. So that's we give them the tooling they
[27:47] can own their specific slice of the pie and that's why we develop this cost planning app as a single pane of planning glass for every single forecast
[27:59] forecast owners and on the app there's a two simple move you know the first move is they can review and override the forecast method you know they can choose what is the smart default recommended by
[28:12] back testing or they can choose another forecast method that is included in our forecast pipeline. They can also add any inorganic forecast changes because the model can only
[28:26] predict what is in your history. But what if there's a new product, there's no history, there's new region, there's no history. You still need them to add on top of your forecast. And once you
[28:38] let them to add up their usage you want to convert into dollars, right? Remember the decomposition framework the service team they don't own the they don't own the unit cost they only own their usage
[28:50] of CPU hours and the platform teams owns the efficiency. So you need to let them know all these region launch product expansions how much will that cost in terms of dollars.
[29:03] So what you know as a data scientist I'm very excited about this is this is everything I can build on my own using data bricks data bricks app and uh previously working at Amazon other
[29:16] companies I need to worry about I need to set up the security how should I control for who can access to the app who don't have access to the app you know so that's where I see database apps
[29:28] that has your single sign out built in that I don't need to configure you know that Azure active directory or any you know sign in for our stakeholders and everything people configured is unity
[29:41] catalog permission so not everyone has has a written permission to your backstage and all the changes are versioned so you know who made the change at what time in their forecast
[29:53] slice um so what I'm also looking very much looking forward to as you might already noticed in the previous two today's keynotes are the lakebase, right? So, lakebase is really the, you know, make
[30:06] this app more scalable. You know, people can written back in to the back lakebased database um to make it more concurrent and also the lakebased app um
[30:18] the database apps are enabling people to do the horizontal scaling. So, you're not only having one instance behind one app, you have multiple instance running behind it.
[30:30] So that's our planning app. And the second layer is what we call data backbone because you have a great app, you have a great interface. If the data
[30:42] underneath it is a mess, the whole system just falls apart. And to actually defend the forecast numbers, anyone need to able to need to be able to rerun the forecasting system. And they need to be
[30:56] getting the exact answer. And this requires a good data backbone which is scalable, governable. So in your old way, you have your
[31:08] staging table, you do your cleaning and then you generate forecast from notebook and share in your handoff mode a CSV file. But when you have hundreds thousand of time series, this doesn't work. You have to distributed your
[31:22] forecasting using apply dependence to apply same forecasting function across those number of forecast dimensions and you want to make sure everything's governed. So you use leak flow jobs to
[31:35] make sure everything's versioned. You track the lineage and this needs to be reproducible as the business are keep asking these questions like you know system A move to system to other team
[31:48] because of their reorgarch or the data platform team decide to change their dimensions because of you know their unit price change as a new product introduced. So those are all the scenarios you want to make sure your
[32:01] forecast is reproducible and you need a govern data pip data data govern uh pipeline to make sure everything is rerunable for anyone so that your forecast is defensible.
[32:15] So that explains the data backbone and lastly I think you know everyone sitting downstairs are already using all AI agents and you might notice like once
[32:28] your forecast becomes your plan there's 100 100% of times 100% chance your forecast will deviate from your actual you know all the forecasts are wrong all models are wrong right so how do you
[32:41] deal with that in the old ways as a data data scientists, you know, the forecast producing team, you'll receive a thousands of Slack messages, emails, people are ask you the questions why
[32:54] your forecast deviate and that's not scalable. So to keep your forecast truly diagnosable at scale and the question need to be answered by the C stakeholder
[33:06] team just in a chat box in a seconds. So instead of forcing the owners to go through checking the CSV file, checking the dashboard, we asked them to ask
[33:18] Genie in plain English and under the hood, here's our recipe. So firstly, we set up the diagnostic pipelines. They're running daily to detect the anomaly, detect anomalies in the cost, including
[33:32] the usage and the unit cost. And we attribute overage as much we can do. And we use metric views to make sure we layer in the business semantics. So your
[33:44] AI agent can better understand how we answer those business questions using the metric. And the genie code is the interface here. So you also build up
[33:56] your skills actually in fact we build over 10 skills for diagnosing our cost overage and those can be linked into your genie code. So with all that your data scientist can
[34:10] scale by building this off uh this tool and Dobby is free. You are free from responding to a thousand Slack messages and let people work on the chat box. So
[34:22] that's what real AI adoption looks like is agent agent grounded in your govern data and diagnosing a problem right at the point of action.
[34:39] So to wrap up, Ginger started this talk by pointing out the massive gap between a forecast being accurate and a forecast being adopted. We shared our framework to close the gap, making your numbers explainable,
[34:52] defensible, and diagnosible. Then we show you actually how to apply the framework at scale when you have hundreds of thousands of dimensions in infrastructure cost. And the secret is not a better algorithm
[35:05] engineer point out it's building natively on the platform to serve the actual forecast consumers the business owners to make sure humans in the loop of making the decisions. So by giving those owners self-s served tools a
[35:19] government data backbone a synthesized AI assistance and keeping them completely in a driver's seat when they log into a planning app. So when you combine all these together, you are not
[35:31] only just shipping a model, you are not just shipping a notebook, you are shipping a system that business actually trusts and adopts. And that's how the forecast finally got adopted.
[35:43] Thank you.

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.