Alexandre Bertails: The Netflix Unified Data Architecture – Episode 40

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS

At Netflix, Alexandre Bertails and his team have adopted the RDF standard to capture the meaning in their content in a consistent way and generate consistent representations of it for a variety of internal customers.

The keys to their system are a Unified Data Architecture (UDA) and a domain modeling language, Upper, that let them quickly and efficiently share complex data projections in the formats that their internal engineering customers need.

We talked about:

• his work at Netflix on the content engineering team, the internal operation that keeps the rest of the business running
• how their search for “one schema to rule them all” and the need for semantic interoperability led to the creation of the Unified Data Architecture (UDA)
• the components of Netflix’s knowledge graph
• Upper, their domain modeling language
• their focus on conceptual RDF, resulting in a system that works more like a virtual knowledge graph
• his team’s decision to “buy RDF” and its standards
• the challenges of aligning multiple internal teams on ontology-writing standards and how they led to the creation of UDA
• their two main goals in creating their Upper domain modeling language – to keep it as compact as possible and to support federation
• the unique nature of Upper and its three essential characteristics – it has to be self-describing, self-referencing, and self-governing
• their use of SHACL and its role in Upper
• how his background in computer science and formal logic and his discovery of information science brought him to the RDF world and ultimately to his current role
• the importance of marketing your work internally and using accessible language to describe it to your stakeholders – for example describing your work as a “domain model” rather than an ontology
• UDA’s ability to permit the automatic distribution of semantically precise data across their business with one click
• how reading the introduction to the original 1999 RDF specification can help prepare you for the LLM/gen AI era

Alexandre’s bio

Alexandre Bertails is an engineer in Content Engineering at Netflix, where he leads the design of the Upper metamodel and the semantic foundations for UDA (Unified Data Architecture).

Connect with Alex online

• LinkedIn
• bertails.org

Resources mentioned in this interview

• Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix
• Resource Description Framework (RDF) Schema Specification (1999)

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Knowledge Graph Insights podcast, episode number 40. When you’re orchestrating data operations for an enormous enterprise like Netflix, you need all of the automation help you can get. Alex Bertails and his content engineering team have adopted the RDF standard to build a domain modeling and data distribution platform that lets them automatically share semantically precise data across their business, in the variety of formats that their internal engineering customers need, often with just one click.

Interview transcript

Larry:
Hi, everyone. Welcome to episode number 40 of the Knowledge Graph Insights podcast. I am really excited today to welcome to the show, Alex Bertails. Alex is a software engineer at Netflix, where he’s done some really interesting work. We’ll talk more about that later today. But welcome, Alex, tell the folks a little bit more about what you’re up to these days.

Alex:
Hi, everyone. I’m Alex. I’m part of the content engineering side of Netflix. Just to make it more concrete, most people will think about the streaming products, that’s not us. We are more on the enterprise side, so essentially the people helping the business being run, so more internal operations. I’m a software engineer. I’ve been part of the initiative called UDA for a few years now, and we published that blog post a few months ago, and that’s what most people want to talk about.

Larry:
Yeah, it’s amazing that the excitement about that post and so many people talking about it. But one thing, I think I inferred it from the article, but I don’t recall a real explicit statement of the problem you were trying to solve in that. Can you talk a little bit about the business prerogatives that drove you to create UDA?

Alex:
Yeah, totally. There was no UDA, there’s no clear problem that we had to solve and really people, won’t realize that, but we’ve been thinking about that point for a very long time. Essentially, on the enterprise side, you have to think about lots of teams having to represent the same business concepts, think about movie actor region, but really hundreds of them really, across different systems. It’s not necessarily people not agreeing on what a movie is, although it happens, but it’s really what is the movie across a GraphQL service, a data mesh source, an Iceberg table, resulting in duplicating efforts and definitions at the end not aligning. A few years ago, we were in search for this one schema kind of concept that would actually rule them all, and that’s how we got into domain modeling, and how can we do that kind of domain modeling across all representations?

Alex:
So there was one part of it. The other part is we needed to enable what’s called semantic interoperability. Once we have the ability to talk about concepts and domain models across all of the representations, then the next question is how can we actually move and help our users move in between all of those data representations? There is one thing to remember from the article that’s actually in the title, that’s that concept of model once, represent everywhere. The core idea with all of that is to say once we’ve been able to capture a domain model in one place, then we have the ability to project and generate consistent representations. In our case, we are focused on GraphQL, Avro, Java, and SQL. That’s what we have today, but we are looking into adding more support for other representations.

Larry:
Interesting. And I think every enterprise will have its own mix of data structures like that that they’re mapping things to. I love the way you use the word, project. I think different people talk about what they do with the end results of such systems. You have two concepts you talk about as you talk about this, the notion of mappings, which we’re just talking about with the data stuff, but also that notion of projection. That’s sort of like once you’ve instantiated something out this system, you project it out to the end user. Is that kind of how it works?

Alex:
Yes, so we do use the term, projection, in the more mathematical sense, and more people would call that denotations. So essentially, once you have a domain model, and you can reason about it, and we have actually, a formal representation of the domain models, maybe we’ll talk about that a little bit later. But then you can actually define how it’s supposed to look like, the exact same thing with the same data semantics, but as an API, for example, in GraphQL, or as a data product in Iceberg, in the data warehouse, or as a low-compacted Kafka topic in our data mesh infrastructure as Avro. So for us, we have to make sure that it’s quote, unquote, “the same thing,” regardless of the data representation that the user is actually interested in.

Alex:
To put everything together, you talked about the mappings, what’s really interesting for us is that the mappings are just one of the three main components that we have in our knowledge graph, because at the end of the day, UDA at its core is really a knowledge graph which is made out of the domain models. We’ve talked about that. Then the mappings, the mappings are themselves objects in that knowledge graph, and they are here actually to connect the world of concepts from the domain models through the worlds of data containers, which in our case could represent things like an Iceberg table, so we would want to know the coordinates on the Iceberg table and we would want to know the schema. But that applies as well to the data mesh source abstraction and the Avro schema that goes with it.

Alex:
That would apply as well, and that’s a tricky part that very few people actually try to solve, but that would apply to the GraphQL APIs. We want to be able to say and know, oh, there is a type resolver for that GraphQL type that exists in that domain graph service and it’s located exactly over there. So that’s the kind of granularity that we actually capture in the knowledge graph.

Larry:
Very cool. And this is the Knowledge Graph Insights podcast, which is how we ended up talking about this. But that notion of the models, and then the mappings, and then the data containers that actually have everything, I’m just trying to get my head around the scale of this knowledge graph. You said this is not just, but you tease it out, it doesn’t have to do with the streaming services or the customer facing part of the business, it’s just about your kind of content and data media assets that you need to manage on the back end. Are you sort of an internal service? Is that how it’s conceived or?

Alex:
That’s a good question. So we are not so much into the binary data. That’s not at all what UDA is about. Again, it’s knowledge graph podcast, for sure, but even more precisely, when we say knowledge graph, we really mean conceptual RDF and we are very, very clear about that. That means for us, quite a few things. The knowledge graph, in our case, needs to be able to capture the data wherever it lives. We do not want necessarily to be RDF all the way through, but at the very core of it, there is a lot of RDF. I’m trying to remember how we talk about it. But yeah, so think about a graph representation of connected data. And again, it has to work across all of the data representations, but we want to make sure that we have enough information about the structure and the constraints of that data wherever it is. That’s where the domain models are.

Alex:
At the core of everything, we do have this domain modeling language, which is called Upper. As I said, it’s domain modeling, so maybe that term is not very well known, but it starts with concept modeling, which is what a lot of people would say, “Oh, is that an ontology?” Yeah, kind of, but we need something a lot more precise. So for us, first, we need to be able to reason about the concepts that are in all the domains, and we need to be able to organize them into domains, and that’s how we end up with domain modeling. So it is a conceptual framework which is entirely built on top of RDF as a framework. But where RDF would be, anybody can say anything about any topic, that’s really what RDF was all about. With Upper, if you say something, you have to mean it, and we have to agree on what the meaning is so that we can enable all of that semantic interoperability that we were talking about.

Alex:
So in practice, what that means is we have a piece of that knowledge graph. It’s always conceptual RDF, sure, but there is one piece that would be materialized RDF, where you have actual RDF triples that we have to store somewhere, and that’s really the center of that knowledge graph. And then as you’re getting closer and closer to the instance data, what people in the RDF world we call instance data, for us actually, we don’t even try to materialize that. It’s more like the virtual knowledge graph that some people have been doing in a few places. And for us, when we look at SQL, Avro, GraphQL, or whatnot, if you squint a little bit, we absolutely want to see everything as if it was conceptual RDF. That’s how we can actually describe, and make it work, and move in between those representations.

Larry:
That’s so interesting.

Alex:
And projections is just that, it’s moving in between, that’s really the main thing here.

Larry:
Yeah, it’s great. I’m thinking this is some kind of big meta knowledge graph now because it’s really a knowledge graph to manage your models, is the main intent of it. Like you said, you’re concerned with the mappings, and the projections, and empowering people to do something with this. Just maintaining the model sounds like plenty of work right there though. You were talking about RDF, we talked earlier and you talked about, “Yeah, we’ve bought RDF,” in the way that when enterprises make that buy versus build decision, you bought RDF. Can you talk a little bit about that decision?

Alex:
Well, that’s actually a fascinating story, which predates me joining the team. So it all started with that one schema problem statement. That was actually one of the very famous memos that was written internally before I joined. Once you articulate the problem that way and… Well, again, into the world of ontology. At the time, the team was looking around and deciding, “Okay, do we have to build something new or can we buy something out there on the market and we would just deploy internally?” Very quickly, it was clear that there was nothing that would do exactly what we wanted, especially with all of the core data representations that we cared about. But people had already identified that there was that thing called RDF, actually the RDF stack, that would provide a lot of the answers.

Alex:
So in this case, we didn’t really end up buying a solution. We actually bought a standard in which was coming with decades of engineering and a lot of work to actually boost out the project. So in the end, it’s only half joking, it’s actually very serious, we do say that we bought RDF even though it’s a WTC standard. Yeah, that’s part of it. But now to be fair, we do not believe that all of the answers were in RDF, and we did have to spend a lot of engineering, time, and resources into operationalizing RDF in that enterprise setting. I don’t want to make it sound like everything was already there, but conceptually, yes, definitely everything was there.

Larry:
Interesting. A common story in RDF adoption is there’s some little pocket in an enterprise where somebody’s doing something and other people go, “Wow, that worked well.” Was there any prototypical initiative that kicked it off or something that was already happening?

Alex:
Not exactly. That’s actually another piece of internal Netflix history, how do we get there? So initially, the investment in that area was more GraphQL. Federated GraphQL is actually more correct in this case. For many, many years, there was a thinking and a bet that GraphQL would be that connective layer that would allow us to move in between the representations. Obviously, it doesn’t work once you understand that GraphQL is more about API schemas and federating that, which is already good. So there was a big investment that was happening on the one hand.

Alex:
Then once people started to think in terms of ontologies, there was a few years ago, obviously wanted to adopt RDF, and the very first thing that they tried was SHACL. SHACL was really seen initially as a potential framework that we could use for that domain modeling, even though we were not really talking about it that way at the time. We have pretty much three teams working on that UDA initiative. Three very motivated teams really wanting to deploy RDF and SHACL. And yet, I can tell you there were three very different styles of writing ontologies. We were still talking about ontologies at the time, to the point that it was absolutely impossible to enable the semantic interoperability that we actually wanted to have.

Alex:
We had to go back to the drawing board and we had to say, “Okay, can we constrain that SHACL just enough so that we can get what we want?” And once we got started on that path, essentially we’re thinking that maybe we need a Upper ontology that would be concerned with the constraints, the rules, and the grammar to talk about that. Little by little, we’re like, “Okay. Well, it’s no longer SHACL. It’s really something that is much more intentional and much more opinionated around how do we even organize all of that?” We had to answer questions like, “What is the information architecture?” We had to answer, “How do we even put that in the hands of end users?” So yeah, it’s really that RDF to SHACL, to that Upper ontology that gave us Upper itself, which is now its own thing within the UDA ecosystem.

Larry:
Yeah, can you describe Upper? It implies Upper ontology, like, BFO or gist or something like that, but it’s not that. I want to get your canonical definition of it.

Alex:
Yeah, so that’s interesting. In my opinion, I’m speaking for myself here, lots of those Upper ontologies, for me, I would call them more like Uber ontologies. There is a desire to put a lot of stuff in there in order to get started. The goal for Upper, and they have very good reasons for that, is actually to be as minimal as possible. It has to be consistent with itself and it needs to enable extensions. So we were targeting that safe core that would give us just enough expressive power to do that domain modeling, and then from day one, make sure that we support federation. That was really another piece that we think is actually absolutely missing from all of the ontological frameworks out there. There is no concern with how do you actually deploy them in a enterprise setting?

Alex:
Today, it’s still very much RDF on the web. You kind of have those ontologies deployed somewhere, a lot of them on the w3c.org website. But there is very little guidelines on how to work together and doing that at the scale of the enterprise. In our case at Netflix, we’re thinking about hundreds and hundreds of domain models and teams having to work together to achieve that. So that’s Upper. In terms of how it works, well, there is no approximation anywhere. For example, when we say Upper is a domain modeling language, the first question that we have to answer is, what is a domain model? Once you say that, it means that Upper has to be self-describing. It has to tell you what a domain model is. Then if you want to push it a little bit more, say, well, you want to define Upper as a domain model, so now Upper has to be self-referencing.

Alex:
The last piece is, like I was hinting at earlier, you want to build on safe foundations, you want to make sure that there is a governance story which applies to Upper itself. So okay, Upper tells you what a domain model is, that tells you part of the story. But if Upper itself is a domain model, how do we make sure that Upper is self-governing? It needs to be able to say it is invalid, it is not valid. Is it self-consistent? Is it enough to actually get and bootstrap the entire thing? That bootstrapping story is actually extremely important for what Upper is, because it means that now any tool, any projection that we define on top of any domain model, because Upper is a domain model, then it applies to Upper.

Alex:
That has very profound implications, because now we say, “Okay, we can project Upper like any domain model and then open to a Java API.” We can project Upper to a GraphQL API, and that means that the actual API that is used by our UI is actually automatically generated from Upper, the domain model itself. It sounds weird, it sounds too crazy, it sounds impossible, but that’s actually the way it works. We do not write really, a specific code for Upper. We actually derive everything from the domain model.

Larry:
Did it surprise you when it worked? It sounds like what you just described was like when you hit start, or go, or whatever, and you’re like, “Wow, it actually can describe itself and govern itself.”

Alex:
Surprised? Yes and no. So knowing the sense that theoretically it should work, I’ve known for a very long time that that was supposed to be possible. Now, in order to get there, it took us a long time. It’s a weird experience because you want… So we use SHACL in order to validate everything, and is the SHACL runtime telling us everything is valid? So the validation report is essentially empty. There is no violations. So you walk towards, okay, you increase the expressive power of Upper. You work on fixing all of the violations against itself, and then one day the system says everything is valid, and then you know, okay, I have it. I have enough expressive power to express Upper in itself, and it is valid because Upper itself is saying everything is okay now. So yeah, that was one moment when that happened, and that was really, “Okay, now after so many months of working on that, we know it works, and now we can actually go to the second phase of the project.” But yeah, there was some surprise, but we had to do it.

Larry:
You’ve been doing RDF stuff for a long time, so I’m imagining there’s a fair amount of experience and expertise that went into that hypothesis. I was kind of joking about it being a surprise. You said a lot of this stuff predates you. Did you get the job because you’re an RDF old hand, or how did that unfold?

Alex:
No, that’s not how it happened, which is even better honestly. So in my case, I’ve been involved in the RDF world for a very long time. So by training, I am actually more in computer science, and I was trained in formal logic, but in the context of proof of programs. It’s another kind of logic that is not the same as the RDF semantics. I was doing another kind of formal semantics. But my first job was actually at the French National Library, and that’s where I learned that there’s something called information science. Very quickly, I was interested in that intersection between these two semantic world. I ended up doing a lot of that at the W3C, actually very, in many ways, similar to what Upper is concerned with. I’ve been involved in that RDB to RDF working group. I was one of the editors of the direct mapping. That’s really the first time that I became interested with semantic interoperability, even though I didn’t even know that was a term at the time.

Alex:
And then I did a few more things on the RDF side, and I became a lot more interested in the operational world, so I worked on the Linked Data Platform, LDP. And then for a very long time, I didn’t do any of that in my career. I was at Netflix doing something very different. That project started and I heard about some people doing some RDF, I said, “Hey, you guys maybe need some help? I’m interested,” and I just joined the team. But no, they were doing RDF before. I just happened to be in the right place at the right time, and there was a role for me, and that was just perfect for everyone.

Larry:
I love serendipity. That’s so awesome.

Alex:
That’s the right word, yeah.

Larry:
Yeah, that’s so great. Hey, but one thing I want to talk about too, my whole intent in this podcast is to help people do awesome stuff like this. I’m just wondering if there are any take homes or… There’s so much to this that I don’t even know where to start with a question, but are there any insights that you discerned in this process that you think would help other people, especially who are tackling a really big project like this?

Alex:
Yes, there are so many actually. So many things that I’ve learned working on that. One thing that comes to mind, which has surprised quite a few people, is the marketing. I know that people in our world don’t really like to hear about marketing, but something that we learned the hard way is when we try to sell ontologies internally and people just… It didn’t work. It didn’t resonate with people. People were feeling very dumb, as if they were expected to already know what that is. They would look on Google and find very confusing answers. It would be very hard for people to relate with what we were doing. One thing that we had to do, that we were forced to do, is going back to the drawing board and decide, “Okay, do we think that these people are dumb or not trying hard enough, or is it on us to try to adapt to them?”

Alex:
That’s how we ended up with domain modeling as a concept, because that was really the one thing in the middle of everything, and what are we trying to tell people to do or to pay attention to? And how can we find something that is more accessible to them? Turns out we’ve been talking about domain-driven design, for example, as a way to explain what it was, but domain was not part of the answer. Ontology itself surprisingly doesn’t have the kind of precision that is expected from a system when you have to say, “I’m taking an ontology and I do something with it.” I need to say what’s not an ontology, for example. So between these two aspects of making the concept more accessible, and getting the kind of precision that was missing, and that whole marketing story… And honestly, just overnight, once we decided to talk about domain model, everything changed from our perspective.

Alex:
So yeah, back to your question, how do we do that kind of fun project? I think it’s really important to keep in mind that there are users, there are business problems, and you have to be mindful of that first. You have to make it relatable to people. You have to solve real problems. If your identity is around ontologies and after 20 years, you’re still not able to convince the entire world that ontologies are the best thing ever, maybe you need to change your tune. That would be my advice.

Larry:
And one thing I’d love to talk just a little bit about, when you mentioned the users and customers, we were talking a little bit before, and this would be a whole other podcast to talk in detail about this, but you have two model customers. The one I’d really like to talk about is the Primary Data Management platform. Was that the main consumer persona you had in your head as you were doing this or?

Alex:
Yeah, definitely. Let me allow you to give an example in case people haven’t read the article yet. So think about finance, for example, and they come in, and they say, “Hey, we have that concept of a region, and we want to make sure that everybody at Netflix is adopting that definition.” The way that it works, and that’s really what they want it to be able to do, they would define the domain model for region using Upper, then that thing could be embodied in UDA and in PDM, which is built on top of PDM, primary data management, but really taxonomy and reference data management. So then people go into that taxonomy system and they can start describing the domain model as a taxonomy or related taxonomies, and on the hood, it’s using SKOS very much. And then from there, because we have enough information in the domain model, they can derive automatically, a UI where the same finance people can start and manage their reference data.

Alex:
Then with one click, they say, “Hey, UDA, please distribute the data everywhere. Please create that GraphQL API where people can interact with the region data, and now it’s actually federated on the GraphQL enterprise gateway, so other APIs can actually use that as well. And then they say, “Yeah, but same data, actually want it to be available in the data warehouse, so please make it happen.” So now all of a sudden, there is a Iceberg table that everybody can use in order to do a join on that using the region information. So that’s really that at the end of the day. For the PDM people, it means with just one model and one data source with reference data, they can project everywhere automatically through UDA. That’s really the core value here.

Larry:
That’s so powerful. That’s awesome. Hey, Alex, I can’t believe it. We’re coming up on time already, but before we wrap up, is there anything last, anything you want to make sure we share or revisit from the conversation?

Alex:
Let me think. That’s going to be funny. The thing that comes to mind is I would invite people to go back to the RDF specification that was published in 1999, the very first one, and I would ask them to read just the first two paragraphs of the introduction. It’s gold. It’s pure gold. I think it’s been forgotten. But if people want to understand really, the potential of RDF, especially in this age of gen AI, LLM, and all of that, and the kind of problems that could actually be solved with conceptual RDF, I would recommend to just read these two paragraphs. I won’t say too much more about it, but that would be my call to action for everyone out there.

Larry:
I will definitely link to that in the show notes. Hey, one more thing for the show notes, if folks want to stay in touch or follow you online, Alex, what’s the best way to connect?

Alex:
Quite a few options. People can find me very easily on Google. Just Google for Bertails and you’ll find my website, or otherwise, same on LinkedIn. There is probably very few of us, so that should be easy to find me.

Larry:
Okay. I’ll put those in the show notes as well. Well, thank you so much, Alex. This was a very fantastic conversation.

Alex:
My pleasure. Thank you.