Next we have Prashant Rao with Kuzu, a graph database management system for Python graph
data science.
All right.
Good afternoon, everyone.
So my name is Prashant.
I'm an AI engineer at Kuzu.
So I'll be talking about graph databases today.
Just a quick show of hands, how many people have worked with graph databases or heard
of them?
Fair number.
Okay.
So you're in the right room today.
So I'll outline a bit about what I'm going to cover.
I'll start with what graphs are for those who are not familiar.
And then when you need graph modeling, I'll also cover some of the features of a competent
graph database management system and what that means.
And that leads into the vision that Kuzu has, both as a GDBMS or that is a graph database
management system and as the go-to solution for graph data science.
And I'll end with a walkthrough on how Kuzu makes graph data science workflows easier
for the developer.
So the first question we must ask is, what are graphs or networks as they're sometimes
called?
They are an abstract representation of entities and relationships.
Essentially an entity is represented as a node and the way these are connected together
is represented by an edge, which is the relationship shown in this figure.
And as the figure in the bottom shows, these can get pretty complex and reveal really interesting
structures about connected data.
And that's exactly what we see in the real world.
Graphs are actually one of the most natural ways to represent data.
Social networks are of course something we are very familiar with, but graphs are very
prevalent in many other domains, all the way from drug interactions to molecular networks
to traffic networks.
In the world of finance, you analyze transactions for things like fraud and they also are very
common in knowledge graphs that encode factual information about the world.
Kuzu is a graph database management system, which is a class of database management systems.
So I'll start by giving a general overview about GDBMS.
You generally have three components to any database system.
You have the data model, you have the query language, and you have the system implementation.
From the data model perspective, graph data models differ from the conventional relational
data model in the sense that you typically represent the data as nodes and edges.
And you have key value properties on these nodes or edges.
In this example, with this triangle you see here, you have a cyclic relationship of transactions
between people, one, two, and three, where the nodes one, two, and three have property
information on the name and the edges have the amount of the transaction as a property.
So this is called the property graph model of graphs.
And it's very, very common and prevalent in the industry.
But there's also another data model called RDF, resource description framework, which
has a similar concept of subject, predicates, and objects, which represent a triple.
The triple is a basic unit of data in the graph, but it's the same idea as the property
graph model except the implementation is different.
From a query language perspective, every graph database management system needs a high-level
query language that's designed specifically with graph syntax.
And an example of this is shown here.
This is the Cypher query language, which Kuzu implements.
And incidentally, Cypher is the same language that was invented and popularized by Neo4j,
if anybody's used that before.
But what this example query snippet shows is you have node information, A and B, of
type account, and you're matching on those nodes.
And then you're running a query, a joint query equivalent in a way that reminds you a lot
of SQL.
It's very declarative and it's very high-level reminiscent of SQL.
From a system implementation standpoint, universally, I think it's hard to come with
a statement that covers all graph systems, but in general, they implement storage structures,
indices, and operators that are specific to graphs.
One example is the shortest path operator.
These are operators that are not prevalent in relational systems but are very common
in graph systems.
There are many reasons why you might need graph modeling, but I'll cover just a couple
of them in these next two slides.
For an example, let's take this query where we are trying to find direct or indirect possible
sources of money flow into a person's account from a particular location.
So in this example, the person is Alice, represented by node B in this Cypher query,
and we are matching on the owner of that account, which is Alice, but also matching
on account A, whose location is Canada.
The key here is that the middle portion, which is the transfer star, that star syntax
is a high-level general syntax called clean star.
It's used to implement indirect and recursive joins.
As you can see, the query is quite concise.
It's quite readable.
You can do this sort of query in SQL, but it's a recursive query and it's not as easy.
It's going to be a lot more verbose and not that easy to read.
One other example of this would be the shortest path query, which is a lot harder to do in
recursive SQL, but in Cypher, it's very, very straightforward.
It's just an additional clause that you add attached onto the previous query.
Another case where you need graph modeling is in heterogeneous data.
This example here shows an example of Dbpedia, which is a structured version of Wikipedia,
and we're taking this example of the location we're in right now, University, Liberator
and Brussels.
On the left is the way it's stored in structured form, where you have key value properties,
and each of these properties links to other properties.
But on the right, we schematically represent that as a graph.
As you can see, the university is linked to the city of Brussels.
It's also linked to the country of Belgium, what affiliations it has, and each of these
individual resources can be linked to other resources.
This actually expresses the power of a graph model, because doing this with a tabular form
of data would be almost impossible, because that's how Wikipedia is structured.
It's a lot of connected information.
This leads us to the question of what is a feature set of a competent graph database.
We list a few of them here, but I think it's very difficult to go through each of them
in the time we have.
We do have a blog post that covers this in much more detail.
It's called What Every GDBMS Should Do and Division.
But in a nutshell, every GDBMS has to support things like many to many growing joins, recursive
joins on top of heterogeneous data sets, for example, knowledge graphs.
Another thing that we can highlight here is the schema querying aspect, where in this last
example, you have account information and transaction edges, and you're able to query
on the type of the edge.
Let's say you have two different kinds of transactions.
You don't want each of those on either side of the middle node to be the same transaction
type.
You're able to say, you apply a predicate on the edge to say that you don't want nodes
of a particular type.
This is the sort of thing that you can't do in SQL.
You can only do this in a graph model.
The vision of Kuzu as a graph database management system is it aims to represent the state of
the art of how graphs should be stored, indexed, and queried.
It does this by being highly scalable to several terabytes of data.
It's very fast in terms of query speed.
It supports the property graph model, which we described earlier.
It also supports the RDF data model, which is going to be coming in the next release.
It does so via a high-level query language, Cypher.
It's easy to use and uses an embeddable architecture.
We like to think of ourselves as like duck DB or SQLite, but for graphs.
If you ever come across either of the other two relational systems, Kuzu is like a graph
analog to those systems.
I should also note here that Kuzu is based on many years of research at the University
of Waterloo.
It's now being developed in an independent company called Kuzu Inc, which we're from.
The other big vision that Kuzu has from a data science perspective, specifically graph
data science perspective, is to be the go-to back end for graph modeling and data science.
Essentially the vision here is if you look at the bottom half of this figure, you have
a lot of data sitting in disparate sources like data lakes, warehouses, relational databases
all the way from Postgres and many others.
There's a lot of interoperability challenges that you have with these data sources.
Even though you have structured data, in many cases working with them as a graph is quite
challenging because of the movement of data across the systems into a powerful graph database
back end.
Kuzu aims to be a simpler way and sort of an interface to that.
In the upper half, the aim of this is to make graph data science much more accessible
in the sense that we provide zero copy access to the data by writing out the format that
is native to those libraries.
For example, PyTorchumetric, NetworkX.
These are popular graph data science libraries and machine learning libraries in Python.
By being well integrated with the Python data science ecosystem, we believe this makes it
a lot more achievable.
I'll quickly walk through an example of how Kuzu makes graph data science easier in terms
of a workflow.
Let's consider this real world, a simple example, a toy example, where you have two different
data sources.
You have people and the movies that they watched.
You also have people and their friends and where they live.
These are two different data sets.
Your goal is to use the information from this data to build a movie recommender system
where a person who has watched certain movies gets recommended other movies.
There are many ways you can build such a recommendation system.
One we'll cover here is using a graph neural network, specifically using link prediction
where you're trying to predict a recommended edge between a person and a movie.
This is a very simple example where you have data set one which has the persons and the
movies with some additional metadata, could be age or any other attributes.
Then data set two has persons and what friends those persons have and where they live.
For those who have not worked with graph machine learning before, it's a very high level overview
in this slide where the goal of graph machine learning is to embed the nodes and the surroundings
space into a vector space.
The benefit of this is that it incorporates the structure of the graph based on the nodes
and their surrounding neighbors.
The idea is that you perform a computation on the graph nodes and transform the features
of that graph into a feature vector like the array shown there.
The idea is very similar to the kind of vectors that you may have seen in other domains like
computer vision or natural language processing where the only difference is that in those
domains you are considering the similarity between words in a sentence or pixels in an
image whereas in this case you're considering the similarity of the topology of the graph
itself.
All of that is great but when you're working with the data, you're immediately faced with
a problem.
The data you have might exist in different sources.
For example, the movies watch may exist in Postgres and the person friends may exist
in other structured data sources that you export to CSV or Parquet or something similar.
You need to bring them together to form a graph.
Conceptually, this is how a graph would look.
You have nodes that represent the persons.
You have edges that represent the movies that they watched in the first graph and then in
the second one you have edges that represent friendship between people and what cities
they live in.
The moment you do that, you have another problem where you potentially have overlapping data
or duplicate data between these two subgraphs.
In one of them you have the persons and the cities and the other ones you have persons
and movies.
Many of them might be the same people.
There is some deduplication logic that's required where you have to merge people with the same
attributes and there's some custom logic that needs to be put in terms of how you decide
whether something is a duplicate.
Once you do that, you have the final result where you have some nodes that are dangling
in the sense that they have no edges that attach them to other nodes.
These actually don't inform the machine learning model and would need to be removed.
To do all of this is actually quite tedious if you were to write your own custom logic
in your own language of choice.
Where Kuzu comes in and where it's very powerful is the ability to just install an embeddable
library using pip install Kuzu in Python.
Once you have that, you're very rapidly able to run query execution to create the tables,
load the data in and perform deduplication logic and dangling node removal using a high-level
query language like Cypher in a way that scales to the size of the data that you have.
In many ways, you don't have to worry about the scalability problem because now you have
a high-level query language supporting your operations in the middle stages.
Once you have all of the data and the features that are loaded into a graph, you essentially
can walk through this process where you not only have the data in the right form, but you're
able to actually encode the features into the graph and store that on disk.
One of the biggest limitations with PyTorch geometric is if you ever worked with it before,
is it's very memory intensive when you're working with large graphs.
Kuzu helps a lot in this regard by persisting the features onto disk.
That's exactly where I think we want to highlight this point.
I think we are almost out of time, but I'll wrap up by saying the key points to take away.
Kuzu is an in-process analytical graph database system, kind of like DuckTB is in the SQL
world, but for graphs.
It's highly scalable and optimized for multi-core parallelism and very well integrated with
the PyData ecosystem, including NumPy, PyAro, NetworkX, PyTorch, and so on.
It supports both the property graph model as well as the RDF graph model via Cypher,
a high-level query language.
It's embeddable and very easy to use from your application.
It's also accessible with other language bindings, not just Python.
If you come from other languages, those options exist as well.
That's it from us.
Kuzu is an open source, very permissive, licensed, MIT licensed project.
I'd love for everyone to give it a try and reach out to us on Discord.
We're always open to chatting more about graph use cases.
Thank you.