Unleash Innovation with the NetApp AI Data Engine

Hey everyone. So I'm Tori Sunland. I work on product at NetApp AI product, specifically, uh, Arin and i's our technical fellow.

We're gonna spend the next 43 minutes and 43 seconds talking to you guys about this AI data engine. Love for it to be a discussion. So please, you know, interrupt, ask questions, et cetera.

Um, prefer if you didn't throw things, but questions are very welcome. Uh, alright, here we go. I'm gonna do a quick level set.

Just spend a few minutes, why are we building, building this, this, this, what are the're trying to address what are from customers, et cetera. Uh, talk about some product outcomes. And then Orin's gonna take over and gonna talk about the architecture and design and some of the design principles.

And, uh, again, love for this to be a discussion. So, first up, this is news to no one in this room. The promise of AI for enterprises is enormous.

You've all heard eye popping numbers. I'm gonna share just a couple more. 78% of businesses now report that they use AI for at least one business function.

92% of executives say that they're gonna continue to increase their AI spending over the next three years. 5 trillion. This is one of the much more conservative numbers that I was able to find, which is why I felt a little more comfortable putting in a slide.

This is from a, a study from McKinsey, and this is the projected incremental global economic impact of AI for enterprises, for generative AI specifically. So that's the promise, but it's a tale of two cities because the reality is for a lot of enterprises, this is not the case yet. Uh, maybe you guys saw MIT published a, a study that's been widely circulated, talked to a lot of, uh, CIOs, CTOs, 95% reported that their AI projects have failed to deliver any sort of measurable impact to profit or loss for their business.

95%, 85% of projects while the companies we talk to fail to ever even make it to production. AI projects two times the failure rate of non-AI projects and 30% never get past proof of concept. And a lot of these aren't small proofs of concept.

These are dozens of full-time employees, sometimes more months, sometimes longer, just to get to a proof of concept that isn't viable. So this is the reality for so many enterprises today. Why is that?

We've talked to a lot. We've heard from over 1200 SMEs from different enterprises on their experience with ai. Sat down, had very detailed conversation with over a hundred data flows, tools, platforms, use cases, and talked to dozens of analysts, read countless reports, I'm sure like yourselves.

And really consistently what bubbles to the top, the biggest blockers for widespread adoption by enterprises of AI are these five items. And they're all related to data and data infrastructure. The, the context of this is, um, I think that stage two or maybe even three in AI implementation or stage one is experimentation or sandbox, if you like.

Step two is maybe, uh, um, a sort of a maturation, like where's this gonna go? How's it gonna fit? Um, because failure in those stages are is, is very common right now, if you want to, if you wanna categorize failure as we're not gonna pursue this line anymore, right?

I I I am treating a lot of the data we hear, or a lot of the data points we hear right now about 80% failure and that sort of thing, skeptically, because I don't, I can't tell if it comprehends this fact that this is a really new area with tons of experimentation, a lot of investment where the outcome is not some kind of business outcome, but, but learning and iterating. So can you, can, can you comment on the use of the word fail on this Slide? Not their studies though.

So I would, I would assume just not to complete, right? It's not, it's Gartner studies, it's ZA studies. It's MIT studies.

I don't care who the source is though, man, because like, I wanna see those questionnaires, see what, see what was actually asked. It's just like public polling where, you know, how many of your AI projects do not go into production might be related. I don't disagree with you, it's just, it's not NetApp studies.

Yeah. So, uh, also NetApp studies showing 85% failure rate from all the customers we've talked to. So very close.

Now you're on the hook. Explain what a failure is. Now.

I cover I know I was really kind of you. Here I am. Uh, it's a great question.

There's unquestionably a dichotomy. These are all self-reported numbers, of course for all the companies we've talked to. You're right.

There are those that are kind of much more sandboxed contained proofs of concept. However, in all cases these originated from and were kind of widely known and visible to kind of leadership in the company because particular business problem, they thought AI would be a good fit. Yeah, that's, that's another kind of failure again.

'cause the failure begins with the please go add AI to this mm-hmm. Mandate though. Okay.

Yeah. So there's absolutely a spectrum, no question about it. Um, that is kind of the spectrum or spread we see of, of things that are characterized as failures.

The other thing you brought up, which is an interesting point, as you kind of called it phase one, phase two, phase three, some of these actually are big impediments even to the experimentation stage. So let me go through these five. Hey, that's, that's a good perspective t yeah, yeah, Yeah.

Lemme go through these five and then let's circle back and talk about that specifically. Is that okay? So I'll go through them quickly again, please keep the questions, comments coming.

First off, operationalization, this is far less relevant to experimentation, stage production, AI systems, companies we've talked to, again, we have the external data from studies, uh, internal from these over a thousand, uh, enterprise, we've heard from what the companies we've heard from 13 or more is the average number of different tools and platforms they have to deploy, integrate, maintain, to get an end-to-end AI pipeline, right? All the way from data discovery, search cleansing, prep, feature extraction, training, tune all the way to inferencing 13 or more. So the operationalization of a true production.

AI pipeline's very complicated. This is a big stumbling block. Second is, and this is where experimentation also gets hit, is data silos.

When you look at specific failure vectors, number one for all the companies we talk to, is just being able to find and access the right data. And that's true of experimentation as well as actual production systems. There's a good reason for that.

And that is simply as companies, we have big complex global data states, right? Different clusters, uh, different data centers, different topology on-prem, hybrid, uh, cloud hybrid and for good reason. Those historically represent silos.

Different data owners. Data stewards. The problem then is if you have a practitioner with a specific business problem, they want to go determine the viability, do some experimentation, finding the data that is available and owned by the company that can be brought to bear is a huge challenge.

Data management's a huge challenge. This can, uh, afflict experimentation to a limited degree as well. Again, companies, we talked to GK from the main stage.

He said six plus copies, that's external data from IDC companies. We talked to seven plus copies. Very close.

Problem is the same. Lots of copies of the same data sets as you take it through all those stages we just chatted about. That means exporting, synchronization, trying to govern and, and keep things up to date as a source.

Data changes. So your experimentation and production systems are still reflecting the up-to-date reality threats. All our data's always under threat.

Generative AI opens up new attack vectors, some of them pretty sophisticated. The vast majority of existing security solutions do not address them well. So companies are now left to build their own solutions for generative AI workloads or really try to customize off the shelf solutions is a big challenge.

And then finally, cost optimization. And this really is at the production scale, not the experimentation stage. Trying to manage through all these dimensions of complexity, doing it really high scale at manageable cost.

So you actually get a positive ROI is a big challenge. These are the five we consistently hear. And as I said, some of these afflict experimentation, particularly data silos and some of the data management pieces and others are kind of squarely related to, uh, production workloads.

Any disagreement with this? Would your guys' experiment? Uh, experience been different?

Otherwise we can, we can keep on cruising. Alright, I'm gonna keep cruising. Um, so that's the reality.

This is what I like to call the new reality. The AI data engine. You guys have already heard a lot about it sounds like you have a lot of questions.

Love to hear those. You have your storage, your data on one side, and you got your generative AI workload or application on the other. Those five big data, data infrastructure problems in between the NetApp data engine is intended, uh, is a unified platform that literally goes straight from your raw storage, logical extension, seamless extension of ONTAP Arena will talk more about this all the way up to data serving.

And not only is it a single platform, it's a single platform that addresses each of those five problems. Unified control, plane storage admins, IT admins, still just system manager. He's now show up as compute nodes as part of your storage cluster.

Finding the data, uh, break down those silos. We can, we will index whatever portion of your global data say you'd like. AI data engine will index it, create a searchable structured rich search semantics, uh, metadata catalog.

Again, a random will talk more about this current source. Data changes added, removed, updated single working copy end-to-end pipeline, always kept up to date in sync with the source data itself, wherever it lives in your global estate. Governance, security.

We will talk about details baked in day one. Purpose built for ai. Continuously classifies monitors gives you a lot of flexibility and power as far as policy attribute driven policies for all that rich metadata about all these files that it's constantly classifying and then gives you the ability to, uh, just define activities based on that.

Don't include this data for this particular AI app or set of users, obfuscate, redact, et cetera. And then finally, transformation. Marin will talk a lot about this, but rag single most common modality we hear from all of our customers for, for attempting to build generative ai, uh, app makes a lot of sense.

Uh, in order to do the retrieval leg of a rag pipeline, you need semantic search. Most common way to drive that now is with ve uh, vector indices. Vector embeddings going from raw data to vector embeddings, 10 to 20 x data bloat at a minimum.

All the companies we've talked to, we've heard much worse. You guys are smart. You can do the simple math.

If you've got tens of terabytes, hundreds of terabytes dataset or bigger, this quickly becomes a very significant cost and, and resource, uh, consumption vector. I have a basic question. Yeah, Of course.

So Does the engine only support NetApps storage sources and databases? Right? Yeah.

Great. Great question. Um, the, the short answer is at launch, just NetApp.

Okay. That's our initial primary focus. We have much broader vision.

Yeah. If you're interested and available, we actually have a breakout session today, 44 18. Okay.

Where we're gonna talk about that broader vision. GK started to lay out, he talked about this global metadata fabric. Yeah.

Yeah. And he talked about all these different data sources and having attached compute and storage and then this global global semantic knowledge graph so you could traverse and find Yeah. And that's where we start to pull in these, these other data sources in addition to that.

So That's just a launch scope. Absolutely. The plan.

Okay. Thank you. Absolutely.

That makes a, that's a great, that's a great question actually. Alright, with that you see the NVIDIA logo, we're gonna talk about that more very, uh, strategic partner we co-developed this with, but I'm gonna hand off a random to start to dive into the details. Good afternoon.

This is a, uh, I'm a technical fellow. I actually architected both a FX and a ID. Um, so you have heard, heard about A FXI think in the morning.

Uh, we'll talk about this part. Um, we'll quickly get into how we took disaggregation to the next level. Right?

We announced a FX, this insight. Um, and where what we are doing is we are making the storage controllers decouple from the shelves so that you could add capacity, uh, sorry, capacity independent of the performance. So if you need performance, you add controllers.

If you need capacity, uh, you add shelves and everything is stitched together with high performance interconnect over redundant pair of switches. And this high performance interconnect is 200 gig plus ethernet. And, um, NVME over rocky, uh, NVME over fabrics, uh, with Rocky.

Um, so this is what we launched. Now where we have gone one more or taken one more step is we have added these data compute nodes in addition to the storage controllers that can now do the data processing for a ID or any form of AI related workflows. So, and these data compute nodes are actually armed with Nvidia GPUs as well to do all sorts of data crunching for, uh, guardrails, vectorization and others.

Okay? And again, they're all connected to the same cluster. Uh, it's the same cluster network.

So it's the same secure boundary, same trust boundary as your cluster. So you do not have to think of doing anything, uh, extraordinary to maintain your security posture. Uh, this also ensures that we have high bandwidth connectivity inside the cluster so you get all of the performance.

And thirdly, it is the same ONTAP experience that people are used to. It still uses the same ONTAP management, uh, gateway for people to manage it. Uh, so it gives the same experience.

People do not have to learn another platform in addition to what they already know. So are the dcns running a, a version of ontap or is it separate? The dcns are, in terms of the os, it's not running exactly ONTAP per se, because the ONTAP does the storage functions, the file system functions.

This does more of the data functions. Um, so these data compute nodes actually are run on Linux and we have microservices spun up on them. But they do talk with ONTAP a lot, as I will talk through you in in the upcoming slide.

So, So the data flow, so those actually, even though they're connected to switch a, switch B, they're still clients of the controllers. They don't talk to the disc shells themselves? They are.

So they don't come through the cluster externally visible cluster ip? No. They, they go through the switch the cluster network.

Cluster network, yes. To Talk to the nodes, yes. But they don't talk to the shelves themselves At launch.

They're not talking to the shelf going ahead. What this allows us to do is, because I know the data layout on the shelf, I know how right this software knows how OnTab works. So I can talk to the shelf if need before optimization Eventually Yes.

Eventually, Yeah. To probably different hardware or better hardware to, to go and, okay. Any other question on this one?

Okay, so let's go through the building blocks of this AI data engine. Um, so as Tori said, there are two different personas who are going to access this engine, right? One is people who set up the infrastructure, set up the platform, set up the hardware, um, set up the volumes right for them.

We have the ONTAP system manager. So this is typically going to be your IT admin or the storage admin or setting up your infrastructure for your operations. However, we also have an a ID console where you have data engineers and data scientists coming up and creating workspaces and other stuff like collections, data collections that I will talk about in the up upcoming slides.

Okay? So the first thing in the series of sequence of steps that we have is the metadata engine. So what this metadata engine does is it decouples the file system metadata and lays it out in a very structured queryable fashion accessible out of band, right?

Um, so that you can create all of the data through rest APIs. You could also add things like apart from the file system tags, you can add custom tags. Say that this is picture of Shrek, for example.

This is a picture of Shrek with a grumpy face, for example. You could add those custom annotations so that you can use those tags to search on your dataset, which typically if you go through the file system metadata interface, you are not allowed to add too many custom tags. So this allows us to add those custom tags.

It also allows us to take it out of band so that the file system IO is not impeded because of metadata operations. Okay? So we lay it out in a very well-defined, highly granular and custom annotate annotatable fashion, and we store it persisted in an ONTAP volume so that we can query it.

It gets all of the ONTAP resiliency in terms of preserving the data, in terms of updating, uh, data, right? We have all the two phase two phase commits going on so that the, this and the actual file system are kept in sync at real time. Okay?

So this never lacks the file system. This is what the file system is, even though it's out of bed. Okay?

Um, We have a data sync and change detection engine. So what that does is, so the beauty of this architecture is I can attach all of your current deployments to this AI data engine. So if you have a NetApp estate and Tori said future, we'll go ahead and look.

We have bigger plans, but for now, if you, if you have a NetApp data estate, you can attach it to AI data engine. And the simplest thing you have to do is set up a Snap mirror schedule. Once you set up a snap mirror schedule data automatically starts syncing because we have a data sync and change detection engine running here.

By the way, this is, this is a snap meter target. So there is snap meter, some part of snap meter code running, and then we have snap diff also running on this one. So even though the in entire ONTAP suite is not running, we have some parts of running here so that we could do the change detection once data is synced, right?

And you could sync it, your snap meter schedules could be an hour, a few minutes, days, whatever your data change rate is. And because it is snap meter, and I think all of you are aware what Snap mirror can do in terms of efficiency, in terms of security, in terms of incremental data updates, you get all of those benefits. So, so are you, you're snap marrying from the data, the external NetApp data estate into the A FX cluster?

Yes. You're not snap marrying it into the dcns? No.

And the Dcns aren't showing up as a snap mirror target. It's the A FX. It's the A FX.

Yes. Yeah, that was unclear. Thanks.

Okay. Thank you. So This goes, I think this is a dumb question, but where does the A IDE live?

Does it live on a FX system? The a ID lives on an extended A FX cluster, but on DCN nodes, these are separate nodes. Okay.

So and so where can that data be then? Is it it's on a server or it's on the, The data is stored on the A FX cluster as you were saying. Right?

But because it's all connected through the internal switches, the D CNS can view that data can Go back. And so the, Okay, let me show you through the other diagram. So if you look at this, um, this is actually the snap mirror target, which is the A FX nodes.

The DCN nodes are where your data engine is running, but since they're all interconnected to the same cluster, I get it. So on the other side, on the next side, what, what I'm trying to get to, so this is all living on, uh, A FX, but this, but then you can snap in o other versions of NetApp Yes. Or Not?

Yes. Because your A FX nodes in that cluster is running ontap, all of ontap. So they can act as a SNAP major target.

And the dcns are pre-provisioned appliances or They are. I think That's, that was where I thought you were going with it was I kind of got a little cluster dcs you're running aid, I'll call it aid. Mm-hmm.

Um, is, are they pre-provisioned appliance, like Currently at launch they're in appliance, right? Mm-hmm. It's s NetApp appliance.

But very soon after the launch we will try to go the OEM route because we do understand that to run the latest and greatest models you need the new GPU architectures. And so we would like to qualify it on other hardware, uh, that has the latest GPU architectures. That be great.

Yeah. That's Question I didn't know I was supposed to Ask. So you are gonna allow lots of OEM third party OE em stuff to connect to your internal cluster switches.

We'll have to maintain an interoperability metrics so that what we support, but yes, we are, we are going to open it up and run more and more use cases, allow other hardware, bring your own hardware on this platform. And so the actual metadata lives on the A FX? Yes.

The volume, the metadata volume lives on the A FX, but the software that accesses that metadata is running on the DCN nodes, Which is, uh, interesting in terms of chattiness mm-hmm. Of, uh, these protocols and metadata, uh, searches against standard file system protocols, tree walks, et cetera. Mm-hmm.

All that traffic now really much richer search semantics, all that load we saw, I think it was like 70% of NFS traffic and typical workloads related to metadata queries. Show me the tree, walk the tree. Who owns this?

When was it updated? All of that. Now you get much richer, uh, query semantics and you, you point all of those queries to these data compute nodes.

So not only does it not burden down your storage controllers, it actually helps lift, uh, a good amount of load off your storage controllers on these dedicated devices. 'cause most of our customers do a lot of LS does a lot of find, find minus, you know this. Right?

And they turn out to be file system three walks that kind of, uh, congestive protocol iPath. Now they're doing rest APIs to understand all of their metadata. So the protocol iPath is kind of decongested since You brought up congestion.

Um, you have the D CNS connected to the cluster network. Mm-hmm. And I'm, and they're clients of the nodes.

They're gonna make requests of the nodes for data that will go to the storage path, which is the same connection from the nodes that it's servicing the dcns. Mm-hmm. So they're basically, so the nodes have, I'm thinking well, two but one to each cluster.

However, you know, it's, it's wired up. Your dcns are making the request storage nodes talk to the storage on that same path, storage nodes talk back to the nodes, it then talk back to the dcns on that. All coming over the same paths.

You're not concerned with congestion there. See, this is an internal network so we can design to the load. It's the front end network congestion that I was talking about.

Yeah, no, no, I get it. Yeah. So, uh, in this, we have designed it enough so that we have for the required SLAs, we have enough bandwidth.

Okay. So you have SLAs published. Got it.

Yes. Um, is it a single metadata store for the entire FX cluster or can I have multiples or It is a single instance of metadata store. And since you are, um, let me play this out a little bit, since you're also connecting it to other deployments, right?

This actually serves as the global metadata store for all of your NetApp deployments. So you can now browse all of your data sets from one single pane of glass. How do you feel that's going to scale from, uh, from the point of view of, well, I asked about this earlier as well.

So you've as this metadata is going to need to be versioned controlled. Mm-hmm. And I'm gonna be able to prove lineage Yes.

And all sorts of things. So yes, as a, as a singular store, that feels like a bit of a limitation. I would want to be able to break that out based on different data sets or different, um, sources or other things so that I can control some of those version You are asking, you're asking questions two steps ahead.

Okay. Which is awesome, by the way. And that is where our vision to the knowledge graph goes, right?

So we believe that this centralized metadata store at a point will not scale. That's, that's where decentralization comes in. So going ahead when we introduce A IDE and bring it, uh, to the brownfield, right?

And, uh, have its support AFS at the time, all the metadata could live within the afs, but your single indexed engine, which is your knowledge graph, that's the thing that's going to reside on A IDE. So you are basically using that index, like internet crawlers. Mm-hmm.

Right? You used to page rank everything and it would show you. So that's our concept of the knowledge graph.

So that's why I said you are jumping two steps ahead. Going ahead. Our knowledge graph is an indexed view of all your data estate and the detailed metadata would reside within the individual clusters.

Okay. Awesome question. Any other questions on this one?

Okay, I will move on because we have 18 more minutes. Alright, so the other important step here is vectorization. And vectorization is basically you can say that, Hey, this is my data estate.

I have a workspace, which is my data that is that I want to really make use. And from that workspace we have, another step that we take is creating a data collection. So once you say, Hey, this is my data of interest, I want to create a data collection, you can take your data collection and vectorize all of that means you're taking your data sets, you're chunking them, and you are embedding them and storing the embeddings in ONTAP volumes again, stored on the fx.

But the engine, the vectorization engine is, is running on the data compute nodes. So what it really does is it now, uh, opens it up, opens your data up for semantic searches, right? Because unstructured data, as you know, there is no schema.

And to establish correlation, you need to do semantic searches. And that is what our vectorization engine does, is enables it to do semantic searches. And we take it very seriously as to the fact that Tori touched upon that there is a 10 to 20 x data bloat every time you do vector embeddings.

And I could go through the math with you why it is, uh, bloating that much. But we take that very seriously for us. We reduce that bloat by about five x because we do a series of steps to quantize the vectors to do a chunk deduplication and then lay it out in a very friendly manner for storage compression to compress it, right?

So we take three steps to reduce the data set by about five x, but we also do one thing called re-ranking. When you're doing the retrieval, it is basically giving you back the accuracy because people might ask, if you're quantizing, you might lose the accuracy. So what we do is when we are doing the nearest neighbor searches, instead of doing K nearest neighbor searches, we do three K to 4K nearest neighbor searches.

So that we give you, and then we reran it so that you get your accuracy back. So that way we kind of compress the data set. Like if a hundred terabyte could become, uh, 10 times a thousand terabytes, for us it would be 200 terabytes.

What, what about backing up and restoring the data set? So the two ways to look at this, yes, we will do back up and restore, right? Uh, because that's part of all the, all the regulations and compliance to look at this one.

That's a fast follow, but you can always recreate your data because it's your source data is a snap mirror target residing on the fx. You can recreate your vector embeddings if you want. That's, and so first of all, um, all the optimizations you're doing do, is that regardless of the embedding model that's used?

Yes. So no matter what mode, No matter what mode Are you able to upload your own embedding models Today we use uh, NVIDIA models, Right? And well, yeah.

And let's say I take an I fine tune an NVIDIA model. Can I use my fine tuned Nvidia? So yes, we would have to do that going ahead because industries like healthcare, for example, need it.

They need it. They a absolutely have to fine tune it, modify it based on their requirements mm-hmm. And their regulations.

So yes, in the future we would have to open it up and allow customers to bring their own models. But you have to, you know, coine that with them. But the embeddings themselves are kept on the dcns Kept, kept operated by the cns, kept on the apex volume.

Okay. So if it's on the A XX volume Okay. Along with the same data, right?

Yes. So there's a snapshot mm-hmm. And I get an updated embedding model.

Mm-hmm. I rerun my embedding and, and I may wanna keep my older embeddings because for lineage and all that kind of stuff. Absolutely.

That now stays in snapshot. And I now have, especially if it's five x instead of 20 XI have five XI, I might have a, a huge snapshot usage from embedding to embedding. 'cause I have my snapshot blocks still used.

Um, I know fabric pool is not yet in a FX, but it's coming Very soon. Yes. I'm assuming fabric pool is the answer to how do I get that stuff Yes.

To something that I, so that I I could preserve my snapshots a lot more snapshots. Yes. Right?

I guess you have to. Yes. Right?

Yes. So that is why embedding it with the ONTAP technology gives us that advantage. Because I could do all of the workflows, all of the, uh, regulatory compliance needs.

I could serve all of that, right. Uh, and maintaining lineage, um, all of that is possible with ONTAP Tech. Great.

Okay. How do you, uh, ensure that the embeddings are secured and protected to the same level, the underlying data that they're vectorized because it's in the same, do you understand that? Awesome question.

So there are two ways, two ways of doing this, right? One is the axis and one is the embeddings themselves. Yeah.

Right? So the access would be preserved by the same identity and access management that the source volume is so that, you know, there is no data leak here. Yeah.

Only people authorized or services authorized can Data that to get through that whatever data access they Have to, to go go through your IDP authenticate yourself and then come That's good. Yeah. Right.

And the embeddings themselves, ONTAP has encryption technology. So if you enable the encryption, they're all all encrypted. Okay.

So that's another, uh, advantage we get by integrating this with ontap. Okay. And the third, but a very important piece is the guardrails.

This allows us to Put classification to your data sets. For example, you want to mask out P-I-I-P-H-I information. You could set policies and say, I want to mask out redact PII or PHI information.

You could do that. Like when you set up your, I said you have a workspace and then you create a data collection. So when you have a workspace and say, go scan the workspace and mask out or remove sensitive files before it makes it to the data collection, we could set those policies and whatever your policy is, we will do that and make sure, uh, all of the data that is now included in the embeddings is anonymized data because your models can come and query the data.

We have to keep the embeddings anonymized. Does It support both fully redacting, like just not serving up a credit card number, but also masking all but the last four? Yes.

So both of those removal And removal and reaction. Yeah. Is this a NetApp code or are you using the NIMS stuff that, that, that Nvidia publishes for the curation and, and guardrails?

'cause No, this, this part is NetApp code. It's your code. Okay.

Yes, Yes. So when they make, when a, a workspace is created mm-hmm. You know, and say, I have access to this data.

That's the data set I wanna build over here in my little workspace, I, I created, this is what I've been trying to wrap my head around. So when that happens, does the workspace have a copy of the data then for the data scientists to work on? Because you might have a piece, a set of data mm-hmm.

That two different, um, data scientists wanna work on, on two different ways. Yes. So you clone the workspace.

Okay. Okay. And that's, that's an untapped clone.

That's an yes. And so then two different data scientist teams can work off And then you can, um, restrict what they are able to see. Like she was asking different ways.

They, they, they set their own parameters based On their, each excuse may have or collection may have their own policies that you set. And so each set of users could view different things. And I use this example, if George and I are looking at the same set of documents, same financial documents of NetApp, we should see different, uh, you know, things and all that is possible because the policies are different and the privileges that George and I have are different.

Okay. So having said that mm-hmm. Obviously it's pretty powerful to allow, um, data scientists to be able to create their own workspaces, which are actually, um, snapshots of data sets.

So what from, for, for the data scientists to be able to do that, what kind of tools are there available on the, um, the operations side so they make sure they don't run outta space to host all the snapshots for all the workspaces? Okay, That's a very good question. So the tools will come from the AI platforms they use, like we are integrated with Domino data labs.

For example, if a data scientist is used this, all of their workflows come and call a snapshot inside our platform. So all that works. Now what happens is if you're running out of space as an example, uh, the usual space alerts go to the storage admin, right?

And the storage admin can then augment storage. Right? So, and you can set those thresholds as, as you do in ontap right?

To say that, Hey, I'm 80% full, send that They can, they can augment storage as well as they can, uh, if need be, they can remove data collections, embeddings, workspaces. They have the ability Or just snapshots. They can't, it doesn't matter.

But Yep. Did they have the ability, oh, sorry. They can remove the snapshots.

They can also look at, because your metadata is going to tell you which workspaces haven't been touched for a while. Maybe your project is over. Right.

So you can go ahead and remove the workspace as well. So, so I was gonna ask one more thing. Alright, go ahead.

Thank you. So does it have the ability for, to, to, is the only place they're allowed to create those, uh, workspaces on a FX or is it, can you boost, Can you explain The workspace creation is happening through, uh, the system manager. You create the workspace, but then the workspace can be used by the data engineer, and then the data engineer can create a further subset that we call as a data collection.

Right? And the data collection is, uh, to be used by the data engineer or the data scientist. So this, but that is visible through the a ID console.

Remember we had two ways of access. One is the system manager for the storage it admin. One is the data engineer, data scientist coming through the ID console.

Can these workspaces be created, like created in the cloud? Or can they be hybrid? Yes, we should be.

So this, as you see right, this deployment, one of them could be in the cloud, right? And so we have a hybrid workspace from your data estate because most of our customers, enterprise customers have a hybrid deployment. Yes.

So if you're, uh, I'm pig making over one of her five questions ago was, um, that's a, that's a dig up there. So, um, if I've got two data scientists that wanna work on and create a workspace mm-hmm. Um, technically I could, and if they're working, starting with the raw data, they may want to choose two different embedding models for different purposes perhaps, or different versions of the same embedding model.

Can I have multiple, I guess I'm flex cloning it. I can, that's an independent volume. So I could have two different embeddings.

Yes. Is that how it would work? I'd have to have two different sets.

Customer may have text logical sets as well as images as well. Mm-hmm. So you need different embedding models for that as well.

Mm. Right. And right now for every data modality we have at launch, a single model, but we would soon need to look at those options that you're seeing because some data scientists might have, might be under a more stricter regulatory, uh, requirement and may need to drop in their model, or They're just snobs and they wanna use their own embedding mom.

Yeah. So we should we, we have to look into that as we look into the future. Yeah.

That Would never happen to all for reasonable People. Very reasonable. Yes.

Don't have any attitudes ever. Never. So, and data anonymization there, do you mean you're anonymizing the data or is that just referring to the redaction?

It is. Uh, one, one of them is the redaction. Yeah.

Right. So that's, that's the main one we have. Okay.

Yeah. Okay. So not differential privacy or one of the anonymizing tools or something like that.

The, that's something that we are looking at in the roadmap. Okay. Yep.

Okay. Thanks. And can we, so with the anonymization of the pieces, right, um, for auditing and compliance and other, can I prove that the data set was the same regardless of who saw what?

So are there any cryptographic hashes, Merkel trees, anything that I could use for audit purposes to say, while it looked different to them, it was the same data set and prove it? Yes. Our source data, the actual data is we are not going and modifying that.

Yeah. But there's no, rather than giving up the entire source data to an auditor to say yes, it was the same mm-hmm. I, I'd rather just give back some kind of proof that it was the same.

Yes. So that's, that's what I was trying to head at, is our, our source, we, we don't go and redact on the source itself. Yeah.

We update metadata for the user to say, which if it's a file, this file had sensitive information at offset X and length YI have redacted that. Okay. So whenever that user is coming and retrieving data, I am applying those rules.

But the actual source file is not, is still having the actual data set. Okay. Okay.

Um, and so if, if I've got lots of different versions of this, um, how am I able to track the lineage and, and the changes, what if I wanted to reproduce certain results? Mm-hmm. Uh, so this version of a metadata store, this, uh, version of the embeddings, um, I ran at these, this point in time.

Is there a way of us tracking that? Yes. So every time you are creating, so we actually feed off of the metadata engine for versioning because that's a single, um, view of the entire state and all of the vectors and the guardrails that we apply, we are versioning it and tagging it to the metadata version.

Okay. Okay. So you should be able to go back to previous versions and replay everything that the previous version had.

Perfect. Okay. Okay.

And again, the versioning is made possible because we are using ONTAP snapshots. Mm-hmm. Okay.

So they're all built into the workflow. And so just to confirm, the NetApp data estate, that is the A FX and then also, um, NetApp cloud resources, A FF has Okay. All of all of NetApp deployments.

Yes. And storage grid will be fast following with storage grid as well. It's not only on tap.

That's what I, okay. One back onto the metadata engine. Um, if I work in a specific field, um, financial markets, uh, healthcare web, can I, can I bring in existing ontologies or taxonomies that I may have already built, um, to fast forward the, the metadata?

Uh, are, are you talking offsetting policies? No, no. I mean, like bringing in my own RDF or JLD that I've already created.

So I've, I've already written ontologies for the data that I have. Mm-hmm. So rather than having that all redone, I want to just bring my classifications in.

And you would like to upload your classification so that Yeah. Yeah, that's a good suggestion. We can look into that and that That would work really well with two-way.

Right. So I've got my ontologies that I've been developing. Yes.

And then you've got the ones that you are learning. Yes. Um, and they could feed back into my ontologies.

That's actually an awesome suggestion because we are just, that's why updating the metadata is important. Exactly. Right.

Because you are updating your metadata and asking us to kind of align with your metadata. Yeah, Exactly. Yeah.

And then, then my ontology might improve based on that. Yes. And things like the Azure information protection, which we've already, you know, spent all this money doing.

Mm-hmm. I understand right now that doesn't, isn't integrated right. But yes.

Maybe something That's something that's something that's an awesome suggestion. We'll, we'll take it back. Tori and I will take it back.

Don't your customer come to you, you go to them. Yeah. Alright.

Okay. Um, and then we kind of talked about all of this, so I don't need to talk about anything this time. Uh, specifically on workspace data collections, access management, uh, we do have a very rich ISV ecosystem integration.

So we are integr, as I said, domino is one. There are others. Uh, we are working with Lang Chain and others.

There is plus Nvidia is is our strategic partner. Um, we wanted to be in the hands of as many AI practitioners as it can be. So we are not stopping people from using AI platforms that they want to.

We would like to integrate with all of that. That's, that's our story. Alright.

So Nvidia as the name, uh, as I just suggested, we have a very strong collaboration with N Nvidia for the models. Um, we are running their embedding models as well as the re-ranking models. And we would like to leverage all the innovation that they are doing, um, for this world because they're the leaders.

And again, our DCN nodes are powered by Nvidia GPUs and we are working to bring some of their newer tech, uh, like, uh, the Blackwell family and support that as well. So you see, see some of the stuff we have done with Nvidia, uh, and we will continue that. Nvidia, RTX Pro 6,000 server that you see is basically the newer Blackwell generation of GPUs that we have already integrated with.

It's not available as a product yet, but we have done the integration. You'll see, see that as a fast follow. Um, Can I have one note?

Yes. Yes. One quick note on that is, is a rhythm talked about right?

Nvidia, uh, best in the world compute for ai, huge investment in models and software to run on that compute, optimize, keep pushing the boundaries. As Orinda mentioned, uh, as part of our shipping software stack, we have their embedded models and it's not their off the shelf embedded models. We've actually co engineered and co-developed to optimize those models to run on our appliances.

And as part of our software pipeline, it is deeply embedded co-engineering and co-developed. It's, it's an element I'm really excited about and the results we're seeing are pretty fantastic as a result. Right.

And so I talked about the ecosystem integration. So we have, you know, full, you know, suite of AI platforms that we are integrating and some of these are very popular names as you can see. Um, so with 41 seconds left.

Okay. Uh, or I'm overtime maybe 44 seconds. Just a few takeaways.

Um, we haven't, you can, you can read that. I think the most important thing is we bring some of the value add of ontap. Like by integrating this with the ONTAP technology, you get to use things like snap meter and snap diff and part of the workflow, right?

So you have the most efficient delta engine and the most secure Delta engine that can, uh, look at all the change sets. Um, we are, I talked about the data gloat reduction by five x. So that's a huge benefit you get.

And then we are the only company that have one P with all the major hyperscalers. So if your data estate is across any of the hyperscalers, your workspace can reflect all of that. So a true hybrid workspace and then future ready, right?

We talked about knowledge graph and supporting agentic ai. We are already partnering with nvidia. Like those of you who saw the featured session that we had with Nvidia yesterday, like Carrie Brisky was on stage and we talked about some of the innovations we are bringing with Agentic ai, where eventually once you get the knowledge graph to be reflected from there, you just talk to agents, secure agents that go ahead and talk to your data and your data and the embeddings are transformed always in place.

Right? Any other question for Tori and I before we, um, wrap it up? I have many but we don't have time.

Yeah, seriously. Could, could we have like two more hours? Yeah.

Gotta get some real, real world. Uh, is this gonna be on, uh, lab on demand? It is.

It is already on the, the lab on demand, not the Guided one, like a real lab on demand with real stuff. Like, so there's a hands-on lab here. I know that.

Okay. And then, yes, stay tuned. We're absolutely have a Lab on demand version, uh, that's developed.

We already have gone through EAP programs like, so Nvidia, we have gone through EAP with them. We, we have other partners we are doing early access programs with. Cool.

Yes. With our negative three minutes. Can I make one final?

So I, I've had the good fortune of, of working really deeply in enterprise AI rolling back 15 years. So there's Microsoft, Google, not here at NetApp. NetApp as you guys know, you've proven intimately familiar with ONTAP and NetApp, right?

Rock solid Storage Systems, best in class industry, leading data management capabilities. Everyone knows Nvidia in terms of their compute and other software. That combination of storage plus data management, plus optimized software and models plus optimize compute hardware is really powerful.

What we've built together with Nvidia doesn't exist any anywhere else. It very, it is really unique and singular. I'm very excited about it.

Uh, and we really do think there's a huge leap forward for enterprises that are hitting all those problems we talked about before. And to top it off, we have more than a hundred exabytes of data. That's our opportunity.

Like a hundred exabyte plus data sitting with our customers. It's our responsibility to make that data ready for ai. I.