Build Computer Vision Labeling Apps with Databricks and Streamlit - My pick

Summary

Bridgestone built a computer vision labeling application on the Databricks Data and AI platform in three weeks using Streamlit, achieving 50% time savings in the labeling workflow and a 20% improvement in computer vision model performance through higher-quality training data.
The evolution from Azure web apps to native Databricks applications using Streamlit eliminated infrastructure overhead for data scientists, while LakeBase provided the real-time transactional database performance required for interactive label submission and retrieval.
A FastAPI backend was introduced to improve scalability beyond pure Streamlit, and Unity Catalog governs all labeled data and model artifacts to ensure full traceability across the computer vision retraining cycle.

Build Computer Vision Labeling Apps with Databricks and Streamlit - My pick

Replace costly third-party labeling platforms with a custom application built entirely on Databricks. See how Bridgestone built a computer vision labeling app in 3 weeks using Streamlit, achieving 50% time savings and 20% model performance improvement with unified governance through Unity Catalog.
This talk covers the evolution from Azure web apps to native Databricks applications, demonstrating how Streamlit simplifies front-end development for data scientists without infrastructure overhead. Learn how LakeBase enabled real-time database performance, how Fast API backends improve scalability, and why consolidating your data platform eliminates integration costs and governance complexity. Includes practical takeaways on internal app deployment, team scaling, and production readiness.
🤝

Chapters

FAQs

How did Bridgestone build a computer vision labeling app on Databricks?

Bridgestone's data science team built the labeling application using Streamlit as the front end within Databricks Apps, with LakeBase handling the real-time database operations needed for label storage, feedback collection, and model retraining data management. The team completed the implementation in three weeks, significantly faster than their previous Azure web app development cycle.

Why did Bridgestone choose Databricks Apps over Azure web apps for computer vision labeling?

The previous Azure web app approach required separate infrastructure management and created integration complexity between the labeling system and the Databricks platform where models and training data resided. Moving to native Databricks Apps with Streamlit eliminated this integration overhead and allowed data scientists to build and maintain the application without dedicated web infrastructure expertise.

What impact did the labeling app have on Bridgestone's computer vision models?

By streamlining the labeling and feedback collection workflow, Bridgestone achieved 50% time savings in the data validation process and a 20% improvement in computer vision model performance. The improvement came from enriching training data with more consistently labeled examples that could be fed back into the retraining pipeline more efficiently and at higher volume.

How does LakeBase improve performance in a Databricks labeling application?

LakeBase provides real-time OLTP database performance within the Databricks Data and AI platform, handling the transactional read and write operations that a labeling application requires when users submit and retrieve individual labels interactively. Unlike Delta Lake, which is optimized for analytical batch workloads, LakeBase supports the low-latency row-level access patterns of an interactive labeling interface.

Full transcript

[00:09] Hello everybody, especially you guys in the front. Keep it down a little bit, would you? Uh, thank you. Um, uh, hopefully you guys are enjoying a nice uh, exciting week. Um, this is my fifth um, time attending this summit and every
[00:27] year it's super exciting. It's it's an honor for me to be here and actually be able to present for the first time after fi my fifth time coming here. So I was pretty excited. I wasn't really asked to present. It was Greg and then I said I'm going to tag along and just do like the
[00:43] intro piece. So we'll get to that in a second. Um so we're going to talk a little bit about uh data bricks apps and how we use it to facilitate facilitate model retraining. And uh I'll start by introducing myself. Uh my name is Tim
[00:59] Hansen. Uh I am the director of uh of mobility solutions dealing with data integrations and intelligence for Bridgestone uh tires. And uh I have uh my lead data scientist Greg. Yeah. So I'm Greg Eless. I'm a lead data
[01:15] scientist on Tim's team. Um mostly focus on manufacturing um vision use cases right now. Thank you. Uh, and so we're going to talk a little bit about so I'm going to do the fluff stuff and Greg's going to do the real meaty meat and potatoes
[01:31] stuff. Uh, and uh, what what was our Bridgestone journey with data bricks? Um, so before I hop into this piece about eight years ago, we looked at trying to figure out what data science uh, uh, platform should we use. You
[01:48] know, we looked at different platforms. I'm not going to name anything else, but it was like $100,000 for five licenses without infrastructure. And then we decided, well, we have this uh pay as you go platform we can use. Uh and and we started using it just to kind of
[02:04] explore our data science uh um journey. And I had counterparts we deal with global, right? That said, this isn't a data science application platform, blah blah blah. Uh so long long story short,
[02:19] we proved them wrong. I mean obviously data bricks has evolved and uh one of the things we had to solve for is how do we get uhme feedback for our data science models or machine learning models. Um and so even before Greg
[02:35] joined my team, we were working on this. I inherited some of this but we have to collect the feedback. We got to validate the labels um and and make sure the model's performing um continue to enrich the training data um and convert that to
[02:52] insights, retrain and then keep measuring impact. What's the precision recall of the models? And so in general uh this is a continual process. And so how do we do that? The first example I'm going to show you is where we came from and then
[03:07] Greg's going to lead us to where we are now and where we're heading. So um we created a uh what we called tagger and I remember my background is solutions architecture. So I remember looking at this and it was an Azure web app that
[03:23] had a SQL backend and we had to manage I'm like who is going to manage this and maintain it? The data scientists uh and it was quite it was quite the challenge but we had a data scientist that actually created it. uh and it did work well um for what it was, but it was so challenging to
[03:40] manage, right? Uh it was able to uh uh label uh uh slow leaks. This this happened to be for a slow leak uh model for tires, Bridgestone tires, and uh it was more complex than people realized, but you have to kind of like how do we validate that there's a slow leak,
[03:56] right? We tried to get customers to validate uh and we were unsuccessful to get a lot of active feedback from customers and from the fleets. So we had to do a lot of thememes looking at the data and so we created this tagger app and it basically allowed us to kind of
[04:11] go through and validate is this a slow leak tag all these things and and try to then provide that feedback into the model to improve performance. Uh and it also had to support multiple sources. So we had um some PC's that we were doing in UAT
[04:31] environment lower environment and so we had UAT data we had some sandbox data we had some data streaming in production so we had to be able to accommodate all those different environments which is a new use case that we could use for lakebase and we'll talk about that some
[04:46] other time maybe next year u so in in general we created this Python dash app we had SQL server but it was disconnected from our backend data bricks tables that was used to use that we used to train the models right and
[05:02] then track uh the performance and so it was a pain right we had to figure out we got to keep synchronizing data from data bricks which is where all of our data was stored to SQL production data u data
[05:17] go through and have this app show us the data kind of mark it up, bring the data back, put it in the model. So it was really it was really a pain. So basically this was painful but it worked but that's what we had at the time. And
[05:33] so um we we then realized every year I come here I bring something back from data bricks and it's something big like oh lakehouse last year was data bricks apps. So uh you'll see these come together but like uh with the lakehouse
[05:49] we were told oh we could use SQL endpoints and replace the SQL server infrastructure as a service and so we switched to the the SQL endpoints and we did testing and it was more performant and easier to manage uh than than a SQL
[06:07] infrastructure as a service or SQL as a service uh within Azure. Um so we switched to that. It allowed us to use the Unity catalog and capture directly in the model inference uh and all the labels which helped us a lot. Uh so it
[06:23] was a it improved our process, it improved our performance and it was cost savings. So it was pretty exciting. So I'm going to try to keep myself to uh 10 minutes here. Uh and so all of these things advancements helped us lead into the next direction where we were
[06:39] heading. uh uh and so this unlocked single source of truth tying more models into our ML flow and our backend retraining uh we were able to do scaled performance with with the lakehouse uh
[06:55] and then like I said the unity cat governance uh and simplified operations but um I made this slide this morning so it's a long it's a long story I must have deleted an extra slide when I submitted and I use AI to generate this fancy being tired to happy and I thought
[07:13] it was so fantastic I threw it on this slide deck but um so really data bricks apps right so now we don't have to think about an Azure web app that we have to manage the infrastructure as a service we have to manage the user login we have to manage
[07:30] all these things outside bring it all in I am so happy to get away from managing infrastructure uh and be able to bring it together in one place so that that native uh integration build in security oneclick deploy and Greg's going to go into more
[07:46] detail on this um and I will pass it over to you. Thank you. Cool. So I'm going to get into um how data bricks apps actually save the day for us. Um as Tim mentioned, we have a
[08:03] lot of um use cases where we have our a lot of our data that we collect that we need to use for uh machine learning uh training is um it comes from um all these manufacturing processes come from fleets all these disparate sources and
[08:19] we have to get them in front ofmemes because there's a lot of ex really the insights we get are from the experts who know like okay I can look at this time series and see that there's a there's a slow leak or whatever. So I'm going to talk a little bit more about um a specific vision use case we had. Um but
[08:36] one thing I want to uh mention first is if you remember my title from the beginning extra credit I'm a data scientist. I'm not a infrastructure engineer. I'm not a front-end developer not a full stack engineer. So why am up am I up here talking about how to build
[08:52] an app? Well, I think that's one of the, you know, great things about data bricks apps is you don't have to be an expert in any of these things to deploy an app that actually um works and creates a lot of business value. So part of the talk is also just hopefully to inspire
[09:08] everyone here to see like oh when you get back after this conference maybe this is one of the talks that you see and think about oh yeah maybe I'll I'll play around data bricks apps see see what I can do. Great. So yeah let's zoom out first. um what was the problem statement? So if
[09:26] you're in a large enterprise like we are I'm sure this happens a lot to you is that there's projects that get started you know PC they get stopped and so what happens in that in that situation well sometimes you build a model um in 2020 and then it sits there for 5 years so
[09:43] and then someone comes back to you 5 years later and said hey uh do you guys still have that model does it work and we go well the people who built it are gone now but let's see maybe it does still work. So um originally this uh we had a computer vision model that was basically um detecting um anomalies from
[10:01] tires uh from images of tires in manufacturing plants. Um so you can see the architecture here. Um basically we have we're collecting images in the plants. We're uploading them to the cloud. Um then within uh we were the original model was built using Azure
[10:16] custom vision. Um so that actually is a pretty nice platform for um general um computer vision tasks. Um so in there you can upload the images um you can create tags and um label them within that platform. So I think it supports um
[10:33] object detection image classification uh you can even train you can train the whole model basically the whole end to end in there. Um which is great which was great in 2020 but now we're in data bricks. uh we're managing all our machine learning um workflows and everything and our models in ML flow on
[10:49] the data platform and there's not really a great way to link those two together. In other words, uh we found some pain points pretty quickly. Um so as Tim
[11:05] mentioned, the challenge has always been how do we synchronize the data between custom vision and data bricks or whatever service it is. we want to run all our machine learning in in ML flow and data bricks. How do we get the data into there to do that? Um the other
[11:22] challenge was so Azure custom vision was pretty great for like general computer vision um like I said use cases but there's not really a great way to customize if you need more than that. So our challenge was um our our images um
[11:39] were not necessarily one image to one label. um there's multiple images of the tire and you kind of need the whole picture of all the images to make a decision. So within custom vision there was not really a good way to do that. Um, basically the the SMMES, they need
[11:54] to see all the images of the same tire kind of in the same screen. Trying to do that in custom vision not really possible. And then even just tracking which images come to the same tire, you lose all the metadata in between them. It's kind of a pain. And then one other challenge is like not all
[12:09] plants could support inference offsite. So we're publishing publishing our models through Azure Cubs and vision APIs. it's not really going to support all our um all our plants.
[12:24] Um and so th this is really these two pain points are really the main ones that we're going to talk about today and why data bricks apps helped us to solve them. So when we're looking at building um a labeling solution or using a labeling solution, we kind of came up with these
[12:40] three different um um solutions. So, first we had Azure Custom Vision. And to be clear, I'm not I'm not trying to say anything bad about Azure Custom Vision. Um, it's a pretty good platform, but it wasn't really a great fit for our use case. So, I've
[12:55] kind of already talked about it, but um, we had a pretty tight timeline, like we're trying to collect data pretty pretty soon. Um, we had a pretty much the whole workflow to get the data into our cloud, but once it's there, like how do we actually use it? So, with Azure Custom Vision, um, it was going to be
[13:11] fast to deploy because we already had it ready. um low cost. Um the cons I kind of already talked about uh you can't really customize too much and it was difficult to integrate with our data bricks platform. Um so we also looked at some open source um I'm sure if anyone's done this before
[13:27] there's there's plenty of other open source and outside computer uh vision labeling platforms um and they're there can be low medium cost. So that's a good that's a good but um we we ran some cons there too. So slow deployment time. So being in a big uh enterprise, you can't
[13:43] just fire up a contract with another company and then you know get it up in like a couple days. Uh it's got to go through approvals uh security. It's got to go through uh you know might have to do an architecture review. Got to figure out how to integrate it with your um
[14:00] your identity platform. That's not going to be a fast process. Um kind of the same challenge as Azure custom vision. it was difficult to integrate. So it's really we're going to have the same problem like even if we're running in our own infrastructure or
[14:15] we're running if we're have an enterprise plan we're running on their infrastructure we're still going to have to figure out a way to get that data into our platform and you know I didn't research every single platform but I couldn't of the main ones I didn't find I couldn't find a good way to do that to get it into data bricks uh natively it
[14:32] was going to require some work. Um the one of the benefits though is they're a lot more customizable than um Azure custom vision. All right, so let's get to data bricks apps. Um as you'll notice there's a lot of pros and not a lot of cons. So low cost. So um within data
[14:49] bricks apps for the smallest compute size I believe it's 0.5 DBU per hour which is pretty pretty reasonable. Um it's fully integrated obviously. So you're in the data bricks platform already. Your data is already there. Data bicks apps gives you out of the box service principle. You can add that give
[15:04] that service principle whatever permissions you need. That's it. It's already within the app. You don't have to do any extra work. And then this is the big one. This is really big for us is it needed to be fully customizable. um talking with the s I don't know I
[15:19] think this is kind of a cliche at this point but for if you're in data science if you when you you know when you're learning it you get all these maybe when you're in school or or doing independent stuff Kaggle say you get all these labelled data sets they're perfect you
[15:34] get to run all these cool models try all these different things uh real world the challenge is usually just labeling the data um so yeah um we needed something fully customizable. And where I'm going with that actually is um you know these
[15:51] aren't just the people who are labeling our data aren't just you know someone we found on the street. These are like expert engineers. So if you're making them click a bunch of buttons it's a very tedious process and they're just not going to give you as probably the data that you want. Um the only con was you got to build it yourself. So were we
[16:08] going to be able to do this? Uh spoiler alert. Yes. Um data bricks apps one. So the main benefit we saw um was all our data was already on data bricks like Tim said. So integration
[16:23] especially data scientist not an integration engineer uh I don't want to build integrations. I want to spend my time um analyzing data building models. Uh so why why would we need to build another integration if we don't need to? It's already there. Um this is a big one too. Data bricks is already approved by it. So all that stuff I talked about
[16:40] earlier don't have to worry about it because we already have it. Um it's already met all security concerns. It's already gone through all the architecture reviews. We're already using it. So why not why using why bring in another platform? Um and like I said, fully customizable interface. This is a big that was a big
[16:56] one. Um so the only unknown was how quickly could we deploy it? Well, uh turns out what not long. So within 3 weeks, um we were actually able to build a full labeling solution with
[17:12] Streamlit. So again, I'm going to come to this theme a lot. Data scientist, not front-end developer. I don't want to write JavaScript. I've I've moonlighted in a lot of different things in my career. Um, but I think one of my core values is when I get to a point where I
[17:28] have to start writing JavaScript. That's usually where I draw draw the line. It's no way I'm not doing that. Um, so Streamlit, it's a great open source Python framework. You go data bricks apps. I think it's one of the first ones they they give a tutorial about how to use how to build an app. Uh if you're a Python developer, you can get something
[17:45] up up really quickly. It's it's crazy how simple it is. Um this app was definitely a lot more complicated than what you would typically see. Um so it's kind of cool. We kind of we kind of pushed Streamlet to the limits, but um it worked. It it it met our use case. Um
[18:00] and then deployed on data bricks apps. Um Tim said a lot of stuff close to my heart about not wanting to manage infrastructure. So when I mentioned moonlighting, I moonlighted for a little bit as a Kubernetes uh administrator. Um Kubernetes is a great great software
[18:16] obviously. Um but uh you know anyone's used it before. It's uh has a quite a reputation for being complicated and I found that to be true when I was trying to manage a cluster and also be a data scientist. Um I wouldn't recommend it. Um and then it's fully integrated with
[18:33] Unity catalog. So out of the box, we already have access to all our data with all the governance and everything. So custom off configuration, don't need it. Don't want it. Um, and I thought this was funny, too,
[18:49] but to when Tim was mentioning about being a um an architect, um, I've been to a lot of talks at these presentations. I wasn't able to go to the first couple days this year, but usually when something like comes up, there's a bunch of stuff going on. There's arrows. I remember last year I was at a talk. There was a a day in
[19:05] engineering one. Um, shout out to the engineers. You guys do a lot of really cool stuff, but that's not really what I want to do. Um, so I I just remember there being they showed like a a job and there was like all these tasks and there arrows going everywhere and I'm like, "Oh my god, I've never even seen I didn't even know you could do that." Um,
[19:21] but this was this is more of my speed where it's like we just get the data, we put in Azure storage, we link it to data bricks, and we put it in our app and that's it. That's all. Um, that's kind of the beauty of it.
[19:41] Um, and yeah, this here's really the impact. I mean, this is the first version of our app we built in like 3 weeks. There were a few edge cases maybe where we had to, you know, fix some stuff, but usually really quick. Uh, we over 1500 tires, which is a lot. Um, and over 20,000 images because there's
[19:56] multiple images of each tire. Um, and this was really like the key to making our SMMES happy and want want to continue doing this work for us was um, most pretty much any other uh, vision platform I saw, it was like you had to click the tag, click the tag, click the
[20:13] tag. So, luckily for us, we work for Bridgestone, which is normally pretty good at manufacturing tires. So, most of the tires are completely fine. There's there's nothing there. No anomaly. So, um, do I really want to make them click? There's like 90% of the tires are not no
[20:29] anomalies. Make them click 90 like 90% of 20,000. Uh no. So uh what I did is just there's a button you click it and it labels all of them as no anomaly. So that was just like a huge timesaver which none of the other apps supported for some reason.
[20:44] Um and then yeah it was a huge impact because with label data we able to do model retraining on data bricks um and improved our performance by over 20%. Which is a lot.
[21:00] All right. So, that was part one. So, now we're going to talk about part two. Um, and this is a bit of an ode to um my friend Claude. I think all of us have have met Claude or maybe maybe I have other friend maybe JP GPT, but you get
[21:15] the idea. Um, so we we did have a few issues with the with the new app. Um, Unity Catalog was not really designed for the latency required for web apps. Um, this was probably also like a symptom of me being a data scientist, not a true developer. Saving labels took
[21:31] kind of a long time. So, you'd hit the save labels and it would kind of spin for a few seconds. Um, probably like a combination of unity catalog, streamllet, and me uh being not not running the most efficient code. Um, but yeah, we we were we started off we
[21:48] rolled out to one plant. So we started getting images and manageable but we started we wanted to deploy to other plants so we can get more data different types of anomalies etc different types of tires. So we're getting more data that's not really going to be sustainable. Um and streamlet is a I
[22:05] mean I'm not going to say anything bad about streamlet that's it's a great framework but it is it can be a little brittle. So yeah spent an afternoon one day uh going through the streamlet source code to see if I can add some of these features that we were being asked to do. And long story short, it was not a good use of time because it was I
[22:22] quickly realized I was just going to have to write JavaScript anyway. So, so um this is where um lakebased really came was key for us. Um so I I don't know if I'm all of you were at the
[22:38] summit last year, but data data bricks had a lot about lakebased last year. I think I I haven't seen all the announcements this year, but looks like they have some even more cool stuff. Um, but anyway, I remember coming back after the conference last year and going into, oh, I'm going to try out this lake base and I was like, is this this post like
[22:53] compute this Postgress thing? Is that lake base? Is that what they're talking about? So, um, I kind of like just after that kind of just put in the back of my mind like I'll try this out later. What's more fully featured? Um, but anyway, a few a few months ago, we were talking to data bricks about this and uh, shout out to our account rep, David.
[23:09] He's like, "Have you guys just tried using lakebase?" And I'm like, "I haven't really looked at that in a while. Let me look at And I was like, "Oh, wow. There's a lot more features in this now." Um, so basically, you know, Lakebase, it's Postgress. That's what supports a lot of web apps. I don't
[23:26] know. I don't know if it's the most user relational database engine, but it's it's probably up there. Um, so yeah, obviously it's easily going to be able to handle the latency requirements for web apps, especially our app which doesn't have a ton of users. Um, this is one that I loved was the lakebased autoscaling uh scale to zero because our
[23:43] app is not using is doesn't have a lot of users. We can just set the database scale to zero. We're not paying for that database when it's not being used. I mean, that's a huge cost saving. Um, especially like sorry to keep going back to my moonlighting as a computer or Kubernetes administrator, but setting up
[23:59] scale to zero for web apps on that was not easy. It was not easy at all. This late base is just like I clicked two buttons and then it was it's working. Um and then um syncing Unity catalog um allows us to integrate with our existing model monitoring and dashboards. So I made a big I made a big
[24:17] mistake at the beginning when I we switched to Lake Base. I forgot that our all our dashboards were still using or connected to the um Unity catalog tables we're using for like monitoring and and things like that. So a couple days later I think our project manager is like hey why haven't we got any data in a couple
[24:32] days? And I look and I'm like, "Oh no, I forgot to to link those tables back together." And I was like, "Oh god, this is going to take forever, isn't it?" And then I looked and it was just like, "No, you can actually just do it within the dashboard and join those tables." And took like an hour or two. Um, so that was I mean this is just great.
[24:52] And then this is where this is where our friend uh my friend Claude really really came to bat for me. Um so um yeah so obviously data scientist didn't probably make the app with like the most uh let's say scalable architecture. So Claude
[25:10] he's just like hey you need to split this into a backend front end architecture. So we did that. Um it's actually it's pretty simple especially if you have some like familiarity with you know APIs. You don't have to be an expert, but you know, you can kind of just make sure he doesn't go off the rails, which he's a lot better at not
[25:26] doing these days. Um, but yeah, we created a new back end front architecture, so fast API, got the same Python, and then I can let Claude really focus on the the JavaScript front end because, um, like I said, it's core value. Uh, don't want to get too my hands dirty, too dirty in there. Um, and
[25:43] then another thing I wanted to highlight is, uh, data bricks hosted LLM. Um, that's pretty that's been like huge for us because we have, you know, we're big enterprises. We need to govern that somehow. We can't just let everybody there's hundreds of thousands of
[25:58] employees. We can't let everybody just, you know, send their data to the AI, especially we have highly secure data and things like that. So, with data bricks hosts, I never had to worry about any of that. It's I know my data is going to staying within data bricks. Um, and yeah, it's just
[26:14] it just made it so easy. It just it just Yeah, I I feel like I could probably keep coming back to this, but it's just it just makes it so much easier. And so now our app is a little bit more complicated. Um so we're getting data from the plant. It's going to Azure
[26:30] storage which is linked to Unity catalog. And now there's a lakebased instance. Um and then now our app is split into a fast API backend and a JavaScript front end which is pretty I guess one of the more modern architectures. Again, not an app expert.
[26:45] Um but yeah um basically we reduced the average time to label by over 50%. So it was taking them maybe like a little bit over a minute to label each tire. I think we reduced that to like 30 seconds something like that. You
[27:01] still have to look at the images. Um we labeled over 15,000 images in half the time. And um we've been working on other stuff so we haven't uh um done the whole model retraining loop yet. But I mean there's no way it's not going to improve the model. I mean we have more data.
[27:17] It's higher quality. Um it's just been this app has just been a huge impact for us. All right. So now I want to talk about our takeaways. Um so these these are like the kind of the considerations that we found um that
[27:34] data bricks apps have been a a good use case for. Um so again I don't know if there's been other announcements. I know they've been talking about potentially deploying apps to external users, but for now, if you have internal your apps just going to be employed to deployed to internal users, it's a great use case
[27:50] because you can just easily give them access to the app. It's either whatever your permissions framework is, you can just add them to a group or whatever and then they have access to the app through the same login that they use to log into data bricks. Anyway, they also support um individual user access. So, the app can
[28:06] use um like the individual users permissions. It's a little bit more involved, but um it's it's not that complicated. Um if your data already resides in data bricks, because then like I said, you don't have to build any more integrations. You're it's already there. Data bricks gives you so much out of the box with the app with the permissions
[28:22] and the service principles that you don't need to do anything really. You get an environment variable, your workspace client works right out of the box. Um and I would say if you're trying to scale to millions of users, maybe it's not the best choice. Um although I think
[28:38] that could be changing. I don't know. Um but yeah, they I think it if you really want to like have a vertically scaled app, I think they just still support just one one. Okay. Yeah, just one just one node for now. I I know they're working on that too. They've mentioned that. Um I think
[28:54] this is another big one is the quick prototyping. Um like you can build an app in an afternoon and deploy it. Uh I'm pretty sure probably a lot of people have already done that with um you know all these different app AI app services but within data like if you want to
[29:10] actually show it to somebody else just do it in data bricks. Um I think there's even some MCP servers. Um and the best part is too is like yeah you can get a prototype up but if you want to live past the prototyping phase is actually also it's not that much more
[29:26] work. You already have all the infrastructure deployed that you need. Um, and like I said, this one is especially um, dear to my heart is if you're not an infrastructure expert, you don't have to do all the infrastructure work. Uh, data bricks has already done it for you.
[29:42] Um, and then I also want to um, give a shout out to the data bicks apps team because they're they're really great. They they helped us a lot with developing this new version of the app. Um, and so if you have questions about um, data bricks apps or just want to take your app to the next level, like
[29:57] don't hesitate to reach out to your account representative and they'll probably connect you with uh, one of the members of the apps team and they're they're really helpful and really nice and um, yeah, just nothing but good things to say about them. Yeah. Am I still on?
[30:12] Yes. Making sure you're allowed to talk. Um my I just I'm very uh trying to be very conservative and taking up too much time because I could talk for hours as everybody knows. Um so the interesting thing is I I came back from the conference last year and
[30:28] we talked about database apps and I said I just said team we need to figure out how to use this. You know what I mean? This looks great. I'm excited about it. And this is Greg taking an initiative to just testing it out and saying wow. you know, and and before I knew it, he had this app created and not only did he
[30:43] create this app, uhmemes were excited about it. We were able to share across the organization, but then it trickled into R&D and other parts of the business so that people were like, well, we need to do the same kind of tagging for our tire, you know, analysis and all this stuff. So, it's really grown. Uh, but
[31:00] it's it's showing you that we could do a prototype in a couple weeks and be able to share it across an organization quickly. I mean, that's impressive because like it was only done internally, so it didn't look as pretty at the beginning. It was just like this, it worked. It was functional. It worked great, you know, and so like then we can
[31:16] continue to grow that and enhance it. But it really is nice to be able to prototype quickly uh use claude and and other tools on the back end uh to to vibe code stuff uh and then uh you know be able to share it across your organization. So it's impressive and and the costing in one
[31:34] place, right? all this infrastructure, you're trying to track your AWS or your Azure costs and then you're trying to track your data bricks and you're trying to figure out what everything costs. It's a little bit easier for us to manage and understand the full impact of these types of uh applications uh for us internally. So, it worked out quite
[31:49] well. So, yeah, and I'm glad you brought that up because I I forgot I wanted to mention that too is every time we've built an app, especially like from the data science team, like when we first started, you know, it was difficult to you know, how do people even use these models? It's like, are we going to send them a CSV file? So, we, you know,
[32:07] Streamllet came out and we're like, let's, I don't know, let's just try this out. But every time we've built an app, I it's just spread like people love it. Um, they just love getting in there and being able to um just, you know, play with the data, do like see the model predictions. And really, this app actually started as just I just wanted
[32:22] to see what the model predictions for certain tires were cuz like it was difficult. And then, you know, we was like, can we just add the labeling to this, too? And I was like, maybe let's try it. Um, yeah. I mean, it's Yeah, I'd recommend
[32:38] just trying it out if you've never had it before. And I think that's all we have. So, I think um if there's any I think we have some time for Q&A if anybody has any questions. Yes. when you're deploying the app and you in service
[32:55] is it are the end us based on uh when they log into data bricks it's doing a as user permissioning to your your catalog there's yeah there's two different ways
[33:10] to do it so you can have the app just act or just use the service principles permissions and so every user would just have those service principles permissions you can also uh restrict it to the um the user that's actually logged in. So that it includes like a token um in one of the headers I believe
[33:26] that your app gets and then you can use that token to um basically that's like the the token that you would use for like any databicks API requests. So restrict it to that and you can just uh generate that uh on your deployment. Yes. Yeah. Exactly. Like when you when you set up the app there's um you can
[33:42] turn off there's a setting I think that's on behalf of user authentication. So then you can um turn that on or off depending on which one you need. Hopefully I said that right. Data bricks apps. Data bricks experts over here. Okay, perfect. Are there any concerns of being locked
[33:58] into this infrastructure now and what what's your feeling on that? That's a good question. Um I think we're already in data bricks so much it's not really a big concern. I think it would it might be a concern if we ever wanted
[34:13] to like scale this to you know other or outside of the organization or to a lot more users but I think it would be okay in that in that circum that situation because then it's just we already have all the app code it's pretty similar but yeah then we'd have to figure out a
[34:29] little bit more of the integration pieces I can jump in on that one too because like answer that one so we as a company big company we can spend we have these workshops next week we have three days of workshop to discuss every piece. Is this company going to be better? This and we just sit there and we swirl about what we're
[34:46] going to use. If we just make a decision and use one platform, unified data platform, and get everybody to use it, we can really run together. And so we I want to get away from that like this piece over here, this piece over here, and manage it. And he he's our Yeah, I should also
[35:01] preface. He's our data bricks evangelist at this show. I know, but it's it's just easier for me. Yeah. Hi. uh love to talk. So I am a a machine learning engineer myself and I also deal with um unstructured data um sensor data
[35:19] specifically. So it's okay even a bit more trickier than than um images. Um so currently our solution is to use um an open- source like platform um label studio. I don't know if you Yeah. So, so I'm pretty sure that one
[35:36] handles a lot of like images, computer vision, um all that type of stuff as well. I just wondering um what's your thought process when you're choosing between like okay let me use a open source community um based like um
[35:52] platform and using their SDK versus like build this app uh yourself on data bricks. Yeah, I mean I think for that one was it was really just the customization piece we needed. So like if Label Studio meets all your needs, you you're probably fine just staying with that. I mean, and especially like if you're if you have a
[36:08] good like integration setup because those are the two really big challenges for us was always like the integration and then the customization. So in Label Studio, it it has a lot of good computer vision functionality. Um I'm not going to say I explored every feature, but I didn't it didn't really I couldn't
[36:23] figure out a good way to do exactly what the SMMES are asking you to do within label studio. So that kind of like was maybe the more the most deciding factor of why we ended up just building it ourselves because it's like and also just for us it was going to take if we wanted to use label studio it was going to take time a lot more time for us to
[36:40] get that partnership going and or or try to host it ourselves that would probably also take probably the same amount of time. So that's kind of how we end and we do uh streaming telematics data and sensor data right so we have where we're bringing 40 million records in a
[36:56] day and that data is just massive uh sometimes one herz sometimes 10 herz and you know it depends on the scenario like what do you need to look at how are you tagging like what's the model doing so with slow leak model we had to actually compare all the tires on an axle and do
[37:13] comparison of of temperature and the and the increase. There's a lot of complexity to it. So that we had to build an app for versus maybe some other things that might you know be more custom or not need custom but you can have something out of the box. Yeah. Yeah. Thanks. That's a good question.
[37:41] So this is a great talk. um like you I I have a feeling we have small a very small team and it I have that feeling here your your data scientist is building apps. So yeah can you speak to like the the ops side like the benefits to to putting all of this in one place from an ops
[37:58] perspective and like uh you will probably want to take vacation someday and things like that. Yeah, that's a good point. I think for this app it works because it's not a a super heavily utilized app. It's like they're not in there like eight hours a day labeling. It's like
[38:13] they go in like maybe once once a day and spend some time in there. If it ever scales past that, I think that's something we'd have to we'd have to figure out. I mean, we do have an op support team, so at that point it might just transition to them. Um, and we'll probably have to write instructions and things like that for them to to work
[38:30] through different scenarios, but maybe Tim has more on that. It's an evolution. I mean it was just a let's see what we can do and let's get you know UI and it was like wow 3 weeks we have this working app and everybody was blown away right and so we continued to grow it re rebuilt rebuilt the back
[38:46] end a little bit we've worked with some people but yeah I think we're going to need you know probably still eventually some extra support on some of that typically depending on the use case this one's not not as critical if we're going to do something more critical with a customer or something we'll have to look
[39:01] at that for sure Yeah, everything with this app is just geared towards this one project. So, it ever expands past that at that point, it's probably not just me managing everything and you know them messaging me like, "Oh, hey, you know, can you fix this?" I was like, "Ah, yeah, I'll fix that." But
[39:24] so, I was wondering if uh does this labeling app actually feed into something that triggers retraining for your models or Not yet, but it will. in the works. Yeah, that's in the works. Oh, that's a good that's a good question. Yeah, that's that's what we're working on. Thank you. Getting the automating the whole
[39:41] retraining process and a lot of new releases coming out this past week where we can do all kinds of auto wait trigger this auto retrain like all those kinds of things we'll start looking at I think to integrate. I'm trying to figure out what my takeaway is from this week because there was a lot of great stuff. So,
[39:57] I'll have to figure that out. Come back next year. Thank you. I appreciate you guys. Thanks everyone. Thank you. Thanks for coming to our talk.

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.