Episode Transcript
[00:00:04] Speaker A: All right, welcome to the True Data Ops podcast. In this episode, I'm your host, Kent Graziano, the Data warrior. In each episode, we'll bring you a podcast covering all things related to data ops with people that are making data ops happen today. Now, if you've not yet done so, please be sure to look up and subscribe to the Dataops Live YouTube channel. That's where you're going to find all the recordings from our past episodes. If you missed any of the prior episodes, you still got plenty of time to catch up. But better yet, go to truedataops.org and subscribe to the podcast. Then you won't miss any of the future sessions. Now, my guest today is doctor Shantona Tooley, who's actually a real scientist. She has a PhD in physics and nuclear science, but she's also more importantly for this show. She's an expert data scientist and data engineer, and she's the director and head of data at Upsol. Welcome to the show.
[00:01:00] Speaker B: Thank you, Ken. Thank you for having me.
[00:01:03] Speaker A: So, yeah, you and I met very recently here back in end of January in Austin at day to day Texas, one of the biggest data shows in Texas that, you know, I discovered a number of years back there, held at the University of Texas. Great opportunity to meet and mingle and listen to some of the leading thought leaders really, in the data space about all things related to data and AI and, you know, everything that we talk about these days. So it was great to get to meet you there. I'm glad you're able to come on the show.
But for the folks who weren't there, you know, maybe you could give us a little bit about your background in data management and, and what you do at upsell.
[00:01:48] Speaker B: Yeah, happy to.
Yeah. So, as you said, I am a physicist by training physics and math is sort of what I learned in school and then I worked in.
Oh, hi. LinkedIn user.
Someone on LinkedIn says hi.
I. So, yeah, I got my PhD from UC Davis, but I was working with the heavy ion group at the CMS experiment at, which is we were doing, we were analyzing data from nuclear collisions to answer questions about the strong force and early universe, what happened after the big bang. So that was a lot of fun. And it was also a lot of data, really massive data sets, both at the time of creation of the time of generation. So, like, the data engineering challenge of how do you process data that's created so fast was really fun. And then even when you do collect some subsample of the data cleverly subsample of the data. You still have so much data between that and the signals that you're looking for, which are vanishingly tiny. So a lot of data reduction feature engineering, really fun work, and then finally some simple ML modeling to actually extract the signal from the background. So I did that end to end a few times over. And then the last analysis, I was leading people to the test, and we ended up doing a baseline comparison for various kinds of effects. And hopefully, or, I mean, it helped in constraining some of the parameters in the strong nuclear force equation. So it was. It was nice to see sort of the effect of that as well.
And then moving on from my physics career, I did some work as. As an NLP ML engineer, where I started thinking about sort of operationalized production workloads in an industry context. Obviously, we were working at CERN with, like, really massive data and really important questions, but there was always this fallback of, we can review this, we can revise this and make changes or improve this and publish new papers on it. Whereas in the industry, it's often sort of your users are consuming the product that you're working on. So a lot of learnings there. And then since then, I've sort of gotten deeper into tooling. So, tooling in the data space. I worked at astronomer as a data scientist, which is a managed airflow service. So, workflow orchestration, thinking about how do we build the best version of an workflow orchestrator so that everyone can get value out of it. And on that thread, I'm now at up solver, which is also a.
Someone called it earlier today, a computational data lake, which I think is actually a really good one. So we offer a data lake as a fully managed service on top of Apache Iceberg, and we also have a hive version, and you can do declarative transformations within that data lake, as well as access it through, you know, any query engine or warehouse or database that supports iceberg.
[00:05:35] Speaker A: Wow. Okay, well, that's quite fascinating. So part of your, you know, your PhD study, you were leading that team at CERN study, if I read this right, it was ultra relativistic collisions.
[00:05:51] Speaker B: Right?
[00:05:51] Speaker A: That's what was.
So you're going to have to explain to this non physicist what. What the heck that means. What's ultra relativistic? Theory of relativity equals MC squared and all that, but what's ultra relativistic?
[00:06:07] Speaker B: Yeah, I mean, when you get closer and closer to the speed of light, like, you kind of have to come up with new words for describe, describing the range that you're in.
So that's where the ultra part comes in. But, yeah, I mean, we accelerate the. Or at certain we would. And other vertical colliders, you sort of start with, you know, everyday material. So in our experiments that start with a little capsule of lead, your lead metal, and then starting from there, extracting away the electrons so that you're left just with the ions and then accelerating those over and over again. So you've got a linear accelerator, and then you have a circular one and then a bigger circular one and a bigger one. Ultimately, you're at within the main tunnel in the LHC, and it's going at very, very close to the speed of light. So that's where the ultra relativistic part comes in, and then the collisions happen. And this collision medium that's produced from that heavy, like, really high energy deposit is many orders of magnitude hotter than the center of the sun. So it's, you know, that's the scale and stuff are kind of really fun to think about sometimes.
And, of course, it vanishes as well, because that much energy deposited in one place, like, it creates really heavy particles that you wouldn't see in everyday situations, but you did see after the big bang, and then those very quickly decay into their daughter particles, and those decay and so on. So the whole thing also vanishes really quickly. And the trick is to capture everything that happened within that very quick, very energetic collision using a bunch of detectors around that collision.
[00:07:51] Speaker A: Wow. Yeah. So part of that is that generated a lot sensor data. And you said you add to, you're basically doing data pipe. Had to build data pipelines to handle, like, multiple terabytes of data back when you're doing that. So tell us a little bit about that experience specifically around the data, what it taught you about managing data.
[00:08:18] Speaker B: Yeah.
Scale is such a funny thing to think about. So the data at the time of production, we're coming in at petabytes per second. Petabytes per second. So that's a whole other challenge of how do you even, like, how do you don't have the bandwidth to collect or process or store that kind of data? So how do you come up with, like, use your physics knowledge and prior knowledge about the detector to design a filtering system that works at the hardware level that filters out the events that you're not interested in and only lets through the data? That's actually that you know you're going to use in your analysis, and that's going to be impactful. So that's one challenge.
And then you know, the data comes in. And when you're eventually doing your analysis, after the data have been processed a few. A few levels, it's still. Yeah, like tens, 20 terabytes of data, usually per data set that you would analyze to, you know, make some sort of meaningful conclusion. And usually it's, you know, a few together that would tell you, give you a complete picture of different kinds of physics. So the massive data challenges are both similar and different from smaller scale data challenges. So this is what I mean.
They're similar in that.
Sorry. If you hear a puppy barking, you.
[00:09:44] Speaker A: Hear the puppy, that's okay.
Yeah.
So the going on behind me now, squeezing the yard work.
[00:09:58] Speaker B: The similarities, of course, are like, when you think about data ops or operations within a pipeline, is the thing that you care most about is that it's sustained process, it has high uptime, it's highly available.
You don't just want the thing to happen that you have planned for to happen or written to happen, but that is seven craft out in unexpected or weird ways, and we don't have to keep going back to it. So, again, like, you know, I guess the saving grace for the big, big particle physics data was that we in some. In some senses, we had the flexibility to go and run the analysis again. Now, of course, it's computationally very expensive. You're definitely, like, you don't want to make mistakes, but because it's, you know, a lot of using up, a lot of compute every time it runs, but also, it's better to be. To be, you know, right and wrong, obviously.
And then part of it, we didn't have that saving grace. Right. Like, when the data are coming in in real time, we have to be able to do something or trigger on the data and collect the data, because otherwise, you've just wasted, like, literally billions of dollars in accelerating the. Employing these protocols.
I think of operations as. I can't get away from thinking of operations at the hardware level as well and at the real time level as well, because that sort of, we would sit in the control rooms when we. The first couple of days of data collection and just be there.
Everyone, everyone on the team would be there ready to respond. And that sort of incident response is very ingrained in the way that I think about data ops as well.
So there were lots of lessons learned, I think, as a physicist, that helped transfer over in terms of how to think of operational data pipelines that. That have really helped me.
[00:12:16] Speaker A: Yeah, so it's. Yeah, seven pillars. Talk about monetary as well as automated monitoring, automated testing that sounds like that was definitely a big piece of what you needed to do, especially not only you're talking about data at this massive scale, but the massive deposit.
Creating the data. Right. Not even collecting, just a massive policy. Creating the data using the accelerators there, sir, makes that pretty critical that you really kind of get your operational ducks in a row, right?
[00:12:56] Speaker B: Yeah, yeah, exactly.
Exactly. Because in industry, the data is sort of being created, and whether or not you collect the data and, you know, sort of monetizes. It's kind of a weird word, but, like, get something out.
People are the. Your customers are using your product, and they're gonna. All of that is going to happen, whereas in an experimental setting, you're explicitly creating or having an event that then creates a data.
[00:13:24] Speaker A: So, yeah, monetary, antiperson, SV reproducible as well. Right? This is science.
Hypotheses.
Retest them and compare the results, I guess, from the various tests to try to come up with your conclusions. Yeah, yeah.
[00:13:45] Speaker B: So, yeah, I think so.
[00:13:46] Speaker A: You. You guys probably are pioneering things in the data ops world before anybody even thought of the world where data ops.
[00:13:55] Speaker B: I mean, I don't know about that. I mean, it's been a few years, so I don't even feel. Feel that comfortable, like, sharing that sentiments with the folks that are currently at CERN. But, I mean, yeah, there are lots of pioneering technology that did come out of CERN for sure.
But, yeah, I mean, the pillars of operations, definitely, it's the same rate.
[00:14:19] Speaker A: It's sort of.
[00:14:20] Speaker B: You have to.
So the two things that you mentioned just now. So, monitoring. Absolutely. So when I said we would sit in this control room, and I'll be there, like, screens everywhere. Actually, there's a movie that I've shared before. It's called secrets of the universe that our research group got to take part in, where there are some scenes where you can see there with all the screens that are in the control room that are showing in real time with all the detector sectors, and how many of the detectors are working correctly, how many are down, because sometimes that'll happen. You can't just go in while the particles are colliding and switch out a detector part. Right.
And then sometimes you can't even do it in a few month time scale because there's enough runs are commissioned that these have to happen that you just sort of. Okay, this is a known issue, and that's another thinking critically about errors and error modes. Like, in what ways can things go wrong? And, I mean, what do we do in these very specific. When things go wrong in these specific ways. And also, like, what are my known knowns and what are my unknowns? That sort of way of thinking is super, super important.
[00:15:44] Speaker A: Yeah, I forgot you'd been in that movie, secrets of the universe. I think on your LinkedIn profile, there's the clip of you. You've actually had to get it on your profile somewhere. I found it because I watched. I watched that clip. That was pretty interesting having you talk about that. Where, where can, where does that movie show up? Is it like, on Netflix or somewhere? Where, do you know where?
[00:16:10] Speaker B: No, I believe it's still only shown at select IMAX theaters. But there is a website, secrets of the universe, where you can go to see clips and other stuff and also where it's. Where it's being.
[00:16:25] Speaker A: Okay, good, good. So that's secretsoftheuniverse.com dot. Yeah. So, yeah, encourage people to go take a look at that. Especially. I mean, everybody's watching this podcast is into data, and so as she's been explaining here, there's a lot of data involved in studying the universe. So that's a fascinating feel.
So I want to switch gears just a little bit here.
One of the hot topics out at datade, Texas, was, of course, talking about data products. I mean, this is kind of a new concept that got popularized with the advent of Shimak Gagani's theories on data mesh. What's your take on data products and how it fits into the data that we're dealing with today?
[00:17:12] Speaker B: Yeah, I think it's super helpful as a framework to think through data and data deliverables.
So the way that I think of data products is like the specific deliverables that are consumed on a regular basis. So very similar to an operationalized, user facing product where you need to think about the maintenance day to day and serve something relevant and fresh to the end users. It's the same idea, except your data products are probably going to be used internally almost always, but you still need to come at it with that mindfulness of there are users, even if it's just Steve from the finance department, there are certain expectations that Steve is going to have and need in order to be able to do his job well, that rely on the state of deliverable that he's looking at on a regular basis. So it can be dashboards, it can be reports, it can be just datasets that are in some way processed that help get to an answer quickly, and especially at larger teams, if you have different teams owning different parts of the pipeline, which is a reality that like it's, you know, I like to have end to end ownership, but the reality is like a certain scale, you sort of have to split it up. Then the data products would also be the things that are handed off to the, to the next team. And again, it's all about the SLA's, right? Like what is the agreement you have between the producer and the consumer? And what are you doing on the producer size to me side to maintain those agreements? And what are you doing on the consumer side side to like how are you following up on that, on that like living relationship with the producer side? Because things can change and will change and you can't just be like, oh, you broke this. You know, I was expecting this schema and you broke it and, you know, it's done. Like, you can't, it's something that you have to like collaborate on and work, work towards. So I think, I think data products.
[00:19:23] Speaker A: Are of a collaborative feedback loop.
[00:19:26] Speaker B: Yep, exactly. But it's the product mindset I think is extremely important. And I've been, you know, delving into product more and more, you know, as I progress in my career. And the sort of, it's not even, it's not even like the rigidity of thinking. It's, it's like a clarity of thinking. I think that product folks have that, like they're very good at like defining the what's and the whys and stuff.
And bringing that into a data practice is actually quite revolutionary. Like, I've seen it happen in front of me. It's, don't do it for the sake of doing it or for the sake of the technology or because it's flashy or something like that. Do it because it serves some purpose for someone else. That mindset is priceless.
[00:20:12] Speaker A: Yeah. I think as technologists we tend to think of the how and sometimes don't think about the why. Right. And I think that it is very valuable. I mean, even in early agile days, you had product owners, but now it's starting to get adopted even better. I think. Like I said, that interface really with the, I'll say, the business requirements. Why are we doing, right, we're collecting this data.
People want to analyze it. Well, how do they want to analyze it? Why are they, what's the value of doing this analysis and making sure that we're delivering on that rather than which data pipeline tool are we using?
We pick the data pipeline tool based on, as you said, the SLA, the data contract, the requirements of what we're trying to deliver and be more focused on that rather than on necessarily using the latest tool off the shelf. Right. It might not be the right thing to solve the problem. So, yeah, I think that's a good perspective. I do like that. I mean, we've got, you work for a software company. I used to work for Snowflake. We had product management. Even from a software perspective, you had people that was, they were thinking about, what's the end user experience with our software? What problems are we going to help them solve? And then the engineering department had to figure out how to make that happen. And if we start doing that in the data world with, like you said, delivering data sets, you know, if it's, you know, like, say, end to end consumer on the other end or to intermediate stages. Yeah, I like that. In bigger organizations, you know, certain things, people own this part of the data and have to deliver it that assert cadence with a certain level of quality. But you still have to have that feedback loop that we know that are the customers getting what they need? And the customers might be another data engineer in your organization. It might not be an end business user, right?
[00:22:16] Speaker B: Yeah, yeah, exactly. And I mean, being mindful of the end user is really important as well. Right? Just as you said, if my job, if, let's say there's a centralized data team, and within the team, my job is to produce the data, the relevant data products for other teams, let's say marketing, finance, etcetera. And each of those teams have their own, like, many data engineering function, right? Maybe it's one person, maybe it's a couple of people, then it's, the data product is going to look different based on like, the level, the technical level, the data expertise level and so on and so forth of those individuals. And it's, it has to be a collaboration because no one wants to be given something that they don't have, like any flexibility with, or autonomy with, like that. That would be an uninteresting job, right. If someone were to say, okay, this is exactly the KPI that you're looking for. This is what you need. You know, you sort of run with it. That's not how that works. It has to be a conversation, a back and forth, and all of these, like, that's why I like data products so much, is all of these are actually product, product ways of thinking as well. It's your, you're doing the user research, you're sitting down with your state, with whoever you're going to be serving, like, we call them stakeholders in data world. But even even more, I think higher level is like users, the folks that want something out of, you know, out of the data organization, and you discuss with them their needs, their wants, their, or even more broadly, their problems. Like what is the top saying that you're trying to solve right now? Whether or not it has anything to do with data, let's put that aside. That's secondary. What are you working on? What are your creed mandates for the next six months? And then starting from there, sort of filtering that down into where can we come in? Where can we help as a data organization? And then going from there to actually drafting something that's close to a PRD, like a product, product requirements, because we do, like, I think another thing we do not very well as data change is documentation. I mean, this is across the board kind of like, you know, you could, you could say who, who does documentation worst? And you can't find an answer to that. But, you know, at least on an engineering side, it's sort of one of the, one of the core pillars. But I think as data scientists, which we did mean shop come in with us, will that sort of talk for a rigor, necessarily, and not that it maps perfectly well, but I do think that sometimes documentation can be a weak spot for data teams. And so starting at that initial requirements gathering level and really documenting all of that, thinking of it as a PRD, then turning that into an engineering requirements documentation PowerPoint, that's where the help comes in. How are we actually going to solve it and then going from there and building out the data products, that sort of strategic and organized thinking is very good.
[00:25:21] Speaker A: Yeah. And the challenge is, of course, doing it in an agile manner so that it's not taking years to do these things, that we're going to deliver useful products, that we got to do it in a much shorter time period. And you say BRD. It takes me back to early, early days of my career where we'd sit literally months meeting with people and writing up brds and getting sign offs and all of that before we ever turned it over to engineering. And that just, you know, projects took literally took years.
And as we all know, by the time we built anything, the requirements had actually changed because this is a change that was talking a couple of decades ago. Now things move so much faster. Now there's just no way you could get away with it because things would just be changing so fast that we have to be even more agile in building the products and keeping it really boils down to me, scope control, right. It's making sure that we've scoped the project to something that's doable in short term that is going to deliver some value.
[00:26:25] Speaker B: Yep. So exactly.
[00:26:28] Speaker A: Automation.
What's your take on that? And you know, do you think we're going to see more like AI assisted automation in trying to deliver this? Because I think at this kind of scale and speed, I don't know how we do it without any kind of automation.
[00:26:44] Speaker B: Great question.
So top level, I'm very pro automation. I mean that's the name of the game with any sort of software product is you're just doing, you're making abstractions and you're doing automation so that individuals have to do less of the, the repetitive work and can focus more on the creative aspects of the job.
So yes to automation. And that's why I like workflow management tools. I like the sort of storage management tools.
So that at the end of the day really what you should be thinking, what as a data developer you should be thinking about is the thing that you want to get done, not the house. And it should be optimized in the backend. Anyway, with that said, the other part of your question was AI. And not to say something controversial here, but I'm a little bit careful when talking about AI because I think it's still, because I'm afraid of overhyping it, but maybe I should reformulate how I think about that. But basically I'm with you.
[00:27:58] Speaker A: I don't disagree with you on that.
[00:28:04] Speaker B: I think we're getting there. I think we're getting there in terms of leveraging AI, automate some of our work. I do think that the functions that we have today, that folks have today are not going to go away, but their jobs are going to get easier. Um, because there is, and I mean, you know, sort of the coding, coding helper is an example of that. Right? Like it's sort of like um, just, just something that, that helps you do the thing that you're trying to do. So I think, I think we're getting there where it's going to be more prevalent. Um, but I'm a little bit, uh, I guess, I guess the one thing to say is that like um, it's not going to replace every part of the function and that's the point, right. Is again the, the sort of a lot of the creative outlets and a lot of the clever problem solving, I think at least in the short term, is going to be left to humans. And super interesting. I mean, I think most people are saying I don't have something totally interesting to add in this discourse here, maybe the one thing I'll say is, even if the entirety of it is done by AI, that's a big if. But that would be not a bad thing, right? Because I mean, we're in a post scarcity economy basically, so we can just go do the things that we want to do that we get true enjoyment from. And if that's like writing data pipelines, great, you can ignore the AI and just spread your own pipelines. Or if that's like reading a book under a tree, then you can go do that because the AI will take care of all the other stuff.
[00:29:51] Speaker A: Yeah, I think we still have to be involved on at least the, on either end, saying what the AA is going to do and reviewing what it did do.
[00:29:59] Speaker B: Right.
[00:30:00] Speaker A: And doing our due diligence, making sure that we're actually achieving the goals. Back to the monitoring and testing. Right. I think even if we automate generating all of our code, which I think it's entirely possible, in the next number of years, we're going to see even more of that. I mean, code generators, as you know, have been around for a long time now. We're getting these kind of copilot things and a natural language interface where we could tell it what we wanted to do and it writes the code for us. There's going to be quite a bit of work still in making sure that the code is really doing what we wanted it to do. And part of that is understanding how to talk to the AI. Right. To, to articulate what you're really trying to do, what you want it to do. So, yeah, I think. I think we'll get there, but like you said, automation, we definitely got to do automation in order to handle the amount of data and the speed at which we're having to do things.
Yeah, there's no way around that. Organizations that have a bunch of engineers who are. The only thing they're doing is coding, is like, you have to code everything by hand, I suspect. You know, they're, they're going to fall behind in the long.
[00:31:19] Speaker B: Possibly, like, I'm not.
Yes, I mean, I agree with what you're saying, but with the caveat that you don't have to.
Like, if you are today finding yourself sort of coding with 95% of your day as coding, that doesn't mean that you're going to be, you know, irrelevant in five years. It just means.
[00:31:39] Speaker A: Oh, yeah, yeah, yeah. No, as an individual, no.
[00:31:41] Speaker B: Right.
It's time to think about the strategic level as well. So actually that's.
I know we have a question up here, but, I mean, that's.
[00:31:50] Speaker A: I was.
[00:31:50] Speaker B: I've been thinking about this recently, is how do you divide up the kinds of roles that exist at a. In a business? I think, like, you know, I've always worked at startups, so I like usually, you know, thinking very cross functionally and stuff. And I think it comes down to, like, strategic and tactical.
And I think a common mistake that folks make is think that tactical is execution and strategic is not execution. And that is just completely false. It's, you know, if you're doing it at the tactical level, you might be doing more execution. Like, for example, if you're in the coding field, you might be doing a lot more coding. But a strategic goal, like saying, oh, this is what needs to be done. There's a lot of work execution involved in doing the due diligence and doing the experimental work, the sort of hypothesis testing work that gets you to, okay, this is the right decisions strategically that we need to take. So it's a tangent, but that's something that can sort of help mine for me recently.
[00:32:57] Speaker A: Yeah. Okay, you want you to take this question.
[00:33:00] Speaker B: Um, the work you did at CERN is at a different scale than what you did after. Do you miss it? There's excitement in both worlds. What excites you the most now? Um, I I miss parts of it. Um, but, like, I think a lot of the parts that I. That I miss, I can still, like, talk about and, like, it was fun while it lasted, and I'm very happy for those experiences and for those learning. So an example would be like, working with such massive data and, like, the kind of pressure of this better not break as we're starting the run because that it's like, you know, again, many billions of dollars wasted and, you know, a month of detector time and stuff, there are parts that I do not miss, mostly having to do with.
Again, there's a pro and a con. So for at least at CERN, and I know this is true at a few other places as well, the reviews are endless. So, going back to what you were saying, kent, about, like, getting sign offs on prds and stuff, getting sign offs on an analysis, it's like a chain that is never ending. So, you know, you have, you review from the working group and then from the bigger working group and then from the collaboration and like, and so on and so forth. So the.
And part of, again, that's good because you really have to have high confidence in the results that you're publishing when the signals are so rare and, like, you're talking about like fundamental laws of physics. But on the other hand, part of it does become bureaucracy. Part of it becomes like, oh, someone wants the color to be changed on a plot and that sort of thing happens as well so that I don't miss as much.
[00:34:41] Speaker A: All right, well, we kind of ran out of time, which I kind of figured we would because you got so many interesting things to talk about. Are you going to be speaking at any events in the near future where people might get to hear you talk.
[00:34:54] Speaker B: About some other things? Yeah, so I'm a little bit, I have conference fatigue a little. So I've been staying away for the last couple months a little bit. But I will be at Snowflake Summit where I'm not doing a talk, but I'm planning to do sort of a hallway chats thing, especially with, because up solver is very invested in iceberg right now. And I mean, a lot of people are talking about iceberg and Snowflake is going to have some cool iceberg talks as well. So the plan is to sort of catch those speakers and experts after their talk to have a deeper drill down discussion or takeaways kind of discussion. So I'll be doing that in the snowflake summit and a few of the conferences that I'm going to be at, but nothing super, super immediate coming up.
[00:35:45] Speaker A: So if you want to catch up with what she's going to be doing here, here's her LinkedIn profile. Please connect. And you can, I assume, like everybody, if you're speaking somewhere, you're going to post about it and so people will find out that way.
[00:36:01] Speaker B: Yeah, exactly.
[00:36:02] Speaker A: Yeah. Awesome. Very good. All right, well, fortunately we got to cut the show now, so, but thank you so much for being my guest today. It's been wonderful having you on. Great conversation.
Love talking about things that a little different, occasionally getting to talk about relativistic physics and nuclear science I think is very cool. And the fact that there's data everywhere and we're dealing with data all the time. So again, thank you very much for being here today.
Thank everyone else for joining the show today. Livestream or if you're watching it on a replay, be sure to join me again in two weeks. My guest is going to be industry analyst, advisor, consultant and the founder CEO of Bark Doctor Carsten bank.
As always, be sure to like the replays on today's show and tell all your friends about the True Data Ops podcast. And don't forget to go to truedataops.org and subscribe to the podcast so you don't miss any of these future episodes. So until next time, this is Kent Graziano, the data warrior, signing off for now.
