Introduction to Graph Analytics and Graph Database | Data Analytics | Community Webinar

Key Takeaways

Thanks everybody for joining Scott and myself. I hope everyone can see my screen here. Um my name is Griffin Marge. I'm a graphic account executive uh at Tiger Graph. Been at Tiger for about a year and a half and spent a majority of my career in the data AI and cloud integration space. Um and I'm joined by my wonderful colleague Scott. Scott, if you want to do a brief intro for the crowd here. Uh I'm a solutions manager where effectively that means that we make machine learning work in business uh environments and today we're going to spend a few seconds talking about how fraud is an example of how you can put it to use. Nice to meet everybody. See everybody virtually. Thanks Scott. Now before we get started I I don't want to assume that everybody here is familiar with graph analytics or graph databases. Um some of you might be working with them today. others. This might be the first time you're hearing about it. Um, but what I will assume is that almost everybody has seen some sort of true crime documentary or one of the many CSIs that is out there where they ultimately will have one of these thread diagrams. And detectives use these, right, to understand relationships and connections between pieces of evidence. How a uh victim might be connected to a location, might be connected to a motive, etc., etc. And the reason they use these is because it intuitively mimics the way that people think. I won't say everybody, but most everybody does not think in rows and columns as as human beings, right? We think in connections and relationships. And that is very similar to the ways that graph databases store data. So graph is how we think. uh graph is is a very natural model for interconnected data in a very organic way of modeling that data to understand relationships, connections and transactions. So just like a human being would take in data points and then connect them in their head to provide insights, a graph database works the same way. So taking in location, profile, browsing history, purchase data, understanding the both direct and indirect relationships between that data to then derive deeper insights. Now the reason that a lot of organizations are taking advantage of graph today is it's really three-fold, right? One, it's the deluge of data. Organizations are dealing with more and more data by the day. uh but they're also needing to ask much more complex questions of that data and the systems that they have built in the past are are not really up to the task of being able to interact with the connected data that organizations are dealing with today. So when it comes to challenges like recommending next best actions, detecting fraud, which we'll get into a little bit later today, identifying supply chain weaknesses, these are all what we consider graphshaped problems, right? where the relationships, the connections in the data matter just as much as the data itself and traditional relationalbased systems were not built to to answer these sort of complex questions. Now the key difference with a graph really comes down to how the data is stored. Graph stores the data in a different way than you would with a key value or document or a relational database. The graph database will actually store the data as pre-connected entities. So you can almost think of it as from a relational perspective having that data being pre-joined from the schema level, right? And why that matters is when you have applications that rely heavily on AI or machine learning and they require wider and deeper analytics, having those connections enable you to address those connected data challenges, right? things like fraud detection, supply chain, customer journey or customer 360 applications. These are great examples of where graphic sells. All right. And and again touching back to the idea of the interconnected data. Having that data connected at the schema level enables you to understand those relationships whether it is one hop away or one data point away or it's 10 hops away. It gives you the ability to really explore the connectedness within your data sets. whether that's a singular system or you're bringing in data from a number of different systems. Now, I'll I'll ask you guys not to cheat here. So, so stick with me on the left side of the screen here as we look at kind of the relational database view. But I think one way to really understand the difference between graph and traditional database systems is visually, right? So, when we look on the left here, if we're just looking at David and Sally, at first glance, right, I I don't see any connections, right? They don't live in the same location. They don't have the same Apple product. They don't bank at the same institution. And within a relational database, aside from what you see here on the rows and columns, you can't very easily model any sort of indirect relationships. You can't run queries across data sets without slow joins and and oftentimes very computationally expensive joins depending on what you're bringing together. And you can't add new relationships without schema changes. Now when we flip the script, right, or kind of flip the perspective to a graph mindset, we can start to understand that the relationships really matter in this data, right? When we first looked at David and Sally, there was nothing bringing them together. When we take a graph view, we can very easily start to see that David is connected with Sally in a number of different ways, right? So David is siblings with Lisa. Lisa has a watch. Boom. So does Sally. David resides in Los Angeles. So does Steve. Steve is co-workers with Sally. So, graph really flips the script from data points or facts to the relationships that connect them. Um, again, that's what's going to enable faster queries at greater depth as you start to connect more data and understand the relationships across them. Now, I think a lot of you on are are familiar with AI and ML. I think that's not very much of a stretch, but one of the areas that graph is having a a very big impact is in the world of AI and ML, right? And graph ML is is a term that's popping up in a lot of organizations. Um, and what graph databases do at a 30,000 maybe even a 50,000 foot view is it makes your models faster and more accurate. Right? And this is, you know, a number of analysts saying that graph is going to play a major role over the next few years in terms of any sort of innovations that come into the data analytics and AI space. And there's a there's a few reasons why graph makes sense for AI and machine learning. The first being richer, smarter data. So, not only does it enable you to connect all of these different data sets and break down the data silos that you might be dealing with, but if you're only training your models on the data points, you're technically throwing out half your data, right? Within a graph, you can actually treat the relationships or the connections in your data as data points themselves. So, you're actually able to train your models on a more holistic vision of what your data is actually telling you. The second piece is then being able to ask deeper, more complex questions. Right? So, back to the David Sally example, you can start to look for those implicit or non-obvious relationships and easily and quickly search far and wide across your data sets because it is that interconnected entity down to the schema level. Another point is accelerated performance, high-speed queries, and then also graph powered algorithms. And then the last piece, explainable AI is is a buzzword, but I'm seeing it being uh more and more applicable in data scientists and machine learning engineers lives, right? Being able to explain the results that you get. With a graph, you can very easily and visually start to understand how your model got to a specific answer. So being able to understand how each individual data point is connected enables you to trace back and forth and understand okay because Scott is connected to Griffin is connected to Nathan that's why we got this output. So it gives you a very easy way to explain the results of your models. Now, staying on the same thread as graph, machine learning, and AI, there's a number of different algorithms specific to the idea of graph that you can take advantage of. And if there are any math or statistics majors out there, you might be familiar with graph theory. And that's what a lot of these algorithms are are based off of, right? And I'll I'll dive into a few of these. And and in each of these bullet points, I'll call them algorithm families. There's a number of different permutations of of each of these, right? But these are some of the more popular algorithms that organizations are taking advantage of today. So centrality essentially assigns numbers or rankings to each of the vertex or or nodes some people call them and their corresponding position within the network. So when you think about uh centrality, you can think about it in terms of finding influencers in a social network or influencers within a customer data set, right? Classification, it actually classifies the vertices into sets according to some external rule that that you might have set, right? So classification can help you understand the maximum amount of tasks that can be performed together without them overlapping. So when you're thinking about something like manufacturing optimization, this is a great sort of algorithm family to take advantage of. Community um one very popular algorithm Louane who some of you might have might have worked with before. This helps you group the vertices so that each group is very densely connected. And if we go back here again when we think about community detection and the ability to understand, you know, how they're very very closely related, you can start to see how they will bubble up. So community detection Lou veain can help you identify fraud communities, right? You would think someone who's more connected to fraud is more likely to commit some sort of fraudulent activity. Uh graph machine learning or graph embeddings, they actually convert the topology of each vertex into a fixed-sized vector of decimal values. And what you can then do is take those graph features and actually put them within your machine learning models. Path very straightforward, right? What's the shortest path from A to B? So when you're thinking route optimization or even something like understanding moneyaundering networks this is a sort of algorithm you might be using similarity again just like its name what's the similarity between pairs of items um you know finding similar users finding similar customers for recommendations topological link prediction predicting the existence of a link between two entities so something that might not be very apparent in your data how can we predict a connection between two different data points and then frequent pattern mining Right? Finding these patterns that occur most frequently within your graph. One good example of this is being able to predict stuff like customer churn. Right? There's patterns that lead lead up to a customer churning or abandoning their cart. And as you identify those, you can take kind of an intervention approach as you start to identify that pattern and stop them before that churn occurs. So, this isn't the limit of the types of algorithms that you can run within a native graph database, but these are some of the more common ones that organizations are using when it comes to solving some of the business challenges that they're looking to today. And that kind of leads into this slide, and this will be the last one, and we'll we'll take a break to to do some of the Q&A, but these are some of the common use cases that organizations are taking advantage of graph for. And it's definitely not limited to these. It feels like there's a new use case for graph that pops up every other day, but these are some of the core ones where graph has really outshined some of the legacy systems that um a lot of these have have been built on top of. So things like entity resolution, customer journey or customer 360 applications, recommendation engines. I'm sure everybody has bought something on Amazon. When you go to your cart to check out, there will always be, hey, people also bought this. That's a graph algorithm running in the background. supply chain understanding you know how that entire value stream comes together in the form of the digital twin right how do my suppliers uh link up with my manufacturing operations what do my demand numbers mean upstream and downstream fraud and AML that's one Scott's going to dig a little bit deeper on so I I won't steal his shine on that one and then more broader use cases right the idea of data fabric cyber security AI and machine learning graph is really touching every industry every sort of function um and really enabling again those deeper analytics where the relationships in your data matter just as much as the data points themselves. So with that I'll take a Q&A break. I know I just talked to everybody uh probably talked your ears off. So I'll pause here and Nathan if there's anything out there for us Scott and I are are willing to field it. Yeah. So so one of the questions we had was what type of specific problems um is graph analytics best equipped for? as I think and Scott did answer it in the in the chat, but and you also just covered it. Um, uh, there is a question about like which softwares are best for this. Um, yeah, so there's a number of different graph offerings out on the market, right? And it it really does depend on what you're trying to do. Um, again, there's there's graph platforms that are built for smaller data sets. There are graph platforms like tiger graph that are built for larger data sets. Um I do have some resources at the end of this deck that kind of does a breakdown of the pros and cons. So when this recording does go out the slides will be available as well. Um but again it it boils down to the challenge you're trying to solve. And really I would take the approach of thinking it from a graph versus non-graph perspective. A graph shaped problem is one where those relationships matter, right? And and again, that's where I think a lot of people are starting is understanding those relationships, those connections in my data matter. I need to flip the script from, you know, a data view to a relationship view. Um Scott, I don't know if you have anything anything to add to that as well. Yeah, I think there's, you know, if you back all the way out, which is I'm not sure what kind of graph to use. There are really several categories. There's something called a triple store which is typically used for ontologies and hierarchies. It's good at things like document management and and sort of those kinds of things. It's very bad at what we just talked about is something called a property graph. Property graphs are very highly connected data inensive uh databases. So for instance, things that they're good at are things like risk, prediction of behavior, past patterns looking like new pattern, right? They're very different. So if you tried to use a triple store for those kinds of things, they wouldn't do very well. By the same token, a property graph is very poor at document management. So when you start to look at that, those use cases for uh customer 360 are cross-ell and upsell. Amazon and those guys do that every day, all day. They own every piece of data. They use hundreds, thousands, millions of different attributes or features to come to the determination that Griffin and Scott will buy a blue stapler. Um, instead of just saying, "Eh, feels like we should sell Scott a blue stapler, right? There's there's a lot of, you know, connect the data behind the scenes." So, that's a very long answer, Griffin, to Yes. I have a few thoughts. No, perfect. I I appreciate it. Okay, perfect. So, we do have a couple more questions coming in. Um, but I want to make sure that we're able to get through the whole presentation and not just answering questions the whole time. So, I'm going to ask like two more and then Okay, everyone else, we will save them for the end. We'll make sure to cover them at the end. Um, uh, so um, uh, and maybe just you may have just answered this, but I was doing an operations thing and so I wasn't listening, so I'm hoping I'm not just repeating a question here. Um, is this related to a knowledge graph? This is a knowledge graph. Yep, that's what we're talking. Short answer, yes. And then, uh, can we see an example of how a graph DB is structured like a hands-on kind of look? And I think you maybe you're about to do this in the demo. Uh, but this person's familiar with SQL and uh, doesn't quite Oh, where' it go? There it go. Doesn't quite get how graph data is stored. I can do a I'll do a chalk talk uh, version of it. So, I'll do my best. Yes. Okay. Perfect. Um, okay. And then, uh, last question. This should be pretty quick. Is there a free certification for Tiger Graph like they have for, and I hope I'm saying this right, Neo4j? Yes. Yes, there is. And that'll be included in in kind of the resources slide that'll get sent out with this recording, but there is a free certification. Um, we have our our resource hub that has documentation uh certification around Tiger and also the GSQL language which is what we use to query data within Tiger. Um, both of those are are free and you get a a nice LinkedIn certification to add uh as well. Um, but again that that'll be included in the resources section. Okay, perfect. And for those of you who uh maybe you're not listening like me, um we will share out the recording uh of this uh presentation as well as uh res resources that um uh Griffin and Scott are going to have available for us at the end of their presentation. So if you're in Zoom with us, you'll get an email from us. It'll also be shared on social media, YouTube, and my colleagues will also post a link on how you can just find the recordings on data science website. So, um, uh, with that, let's uh, let's go ahead and continue and we'll save the rest of the questions for the end. Yep. Scott, I will I'll pass the screen to you. So, I'll stop share here. Super. Um, so one of the things we want to do then is let's double click on a use case. Now there was a previous discussion or question around how do these use cases and what things are are these kinds of property or knowledge graphs useful for what we see is what I'd call the the degrees of Kevin Bacon or the degrees of use cases. We call it a tree of pain. So for instance I'm going to now spend some time talking about fraud and AML, right? Why does this use case stand out to us? Well, what we see then is it it's a onetwo punch. It both decreases cost and it is very similar mathematically to customer 360. Why? Why is that? Well, if you look at fraud, if I have a historical transaction in your bank for two years, you can see things that I do that are considered normal. Suddenly I start transacting more frequently with different zip codes, larger amounts, other kinds of things. I'm juxtaposing a good pattern and a bad pattern. The difference between a customer 360 or a cross-ell and an upsell. So should I sell Scott a um some sort of stock or a bond or whatever it is? I want to look at his historical transactions to figure out is he more likely to buy the product I'm going to recommend mathematically identical with what Griffin just gave us from those graph algorithms. The only difference is one is a good customer path and one is a bad customer path. So what we see in this chart then is whether your business or or your customer that you're working with or or wherever it is if they want to do positive use cases graph is very good at that things like risk upsell what's the propensity to buy churn those kinds of things all that same math that Griffin just showed us all go into risk and segmentation the risk or likelihood of you stealing mathematically is the same as what we talked about as buying a blue rigid on Amazon. It's the same math. Now, if I can be 80%, let that marinate for a minute, 60 to 80% more accurate in a fraud cycle, meaning I could tell people quicker and more accurately that this is more likely fraud versus something normal, huge lift. I can both decrease cost or fines or I can make more money for the bank, right? Because all of us have been in that situation where you get a call and said, you know, is this fraud? Well, no, that's not fraud. I've just stopped you from spending money on my credit card. So that's uh you know that's basically losing money right. So now we can start to see how these use cases fit together right and and there are thousands of use cases but again if we use that idea of connected data we can now start to see regardless of who you are whether you're a true executive. Let's say you're executive and you just said all those great words that Griffin and I just said who cares, right? I want to see that I'm lowering my cost for finding fraud. I want to make sure that I'm not uh uh quagmired in fraud and I want to be able to separate quite frankly the false positive between what my system tells me as fraud and what my human beings are actually telling me as fraud. That's where the tiger platform comes in. And what I'm going to show you now is how can a lay persons, let's say I don't know anything about that, but I want to use the power of machine learning. I want to use the power of those network analytics that Griffin showed me um to go do that. Now for those of the folks on the phone, you're probably in this lower part. So you may be in the analytics or the IT and the platform. So I'm going to show a little bit of the top one and then somebody had talked about a data model. Uh so we'll get into that. But the key here then is everyone now can touch the power and can can start to to drive that. So again what are we doing? Well, if I could combine machine learning. So today perhaps a lot of you have machine learning that you've already written in Python or Jupyter notebooks or whatever it is. What if you could take what you've already done but now connect it to a graph model and you may have existing SQL systems or NoSQL systems or you have standard boolean logic. What if I could bring those three things together that is in the fraud world or some of these other customer 360 that is why a graph database can bolt on. You don't have to throw out all your SQL. You don't have to throw out all your NoSQL. You're using it in addition to create this greater lift. And again, whether I'm a technician or an IT or a developer or machine learning person, there are tools, meaning there is the Tiger Graph Studio and then a machine learning workbench where I can plug it in. Right? That's my view. But if I'm a business user, I just want to know it's 80% more accurate. And we're going to show what those look like. And again, we could have thousands and some of our customers, they have hundreds of separate data systems. We have to connect it and then we have to find the needle in the haststack. And many times we have to figure out which haststack is the needle even in. Right? And that's why fraud is such a good fit for these kinds of solutions. Now somebody had said hey show me a a representative data model. Well in this data model that I'm showing here I am showing and this is both the logical and the physical data model. So the beauty of this is when Griffin said this is the way we think. This is also the way we design the data model. So what do I do? I have a node which is an account. I have linkages or relationships. Now I can save data on those nodes and vertices or nodes and edges. And I can say um that this phone number is connected to this account. Well, this phone number is also connected to a specific um device and is now connected to a payment. Well, that payment goes to another account. And as I go through this, what I start to realize then is the fraud is not hidden at the number one hop, two hop, three hop. It's hidden at the four, five, 6, 7, 8, nine, 10 hops deep. So why does that matter? Our fraudsters now have gotten so sophisticated, they know how to replicate this. So it looks normal. So when we look at now in in in our next iteration of this and again uh I'm old so I'm used to a product called Irwin which is what we used to use for SQL databases the tiger graph data and data model look like a logical data model but they are actually a physical data model. So again I'm able to go through this in five milliseconds. Why? Because this pre-join that Griffin mentioned is loaded up into memory. And if I'm able to load this entire network plus every transaction you've ever done, good and bad, I can now, as you can see, run that algorithm for centrality of fraud, uh, a neighborhood of connected people that are trying to be fraudulent. So, what I've done now is I've loaded all that up in memory. I've run those algorithms, and again, my business user um doesn't know anything about how these hops happen. And so as I step through this now, I can show the user in five milliseconds, by the way, this is perhaps a fraudulent transaction. Stop it and investigate it. There is a real problem. And that accuracy is what we brought to the table to do this kind of a connection. So any questions on that? What I'm going to do is I'm going to show you the business version and then we'll come back to this. Okay. Now, when I'm a business user, I just talked about a really a fair amount of complicated elements. But what I'd like to do now is I'd like to build a trigger. Remember that box that had machine learning, boolean, and then graph. Well, in this case, what I'd like to do uh is actually come over here and I want to build an alert. An alert, a trigger, right? Could be good, could be bad. I'm going to fill out some highle information. But where it starts to get really juicy now is I can literally drag and drop in this case anything that's in my data or basic data block uh in my up uh upstream systems could be uh 10 20 30 of these systems and you can see I could have branch or transaction or or excuse me crypto or verification or a blacklist. So what I've done then is I've said I'm aware now of uh Ukrainian scams that are coming through. What I want to do is look for any transaction where there is perhaps a female, right? And it's coming from a geography. So I'm overlaying uh time and space here. The second thing that I can do is remember those connections with three hops. So again, Griffin, Scott, Nathan uh are are within those connections and I'm using now that graph or network algorithm called Louvane. Show me any communities where these things are happening on a repetitious basis or they are linked. And then finally, I'm saying where someone is on a blacklist. Fran, we are aware of that there is a Francis that's out there um that's on a blacklist. Well, what I want to do is trigger this to say not only show me that person, but show me other people that are perhaps connected. Then what I want to do is look for transactions that are looping. meaning they went to me, they went to Griffin, and then they went back uh to Nathan. And maybe Nathan is is our central uh uh sort of bad actor, if you will. Then I can use things for shortest path. So again, I can build any of these that I want. I can grab fuzzy matching. I can I can go build as many of these things as I need to. So what am I doing? I'm now allowing a lay person that didn't know how to build the fuzzy matching, which we can build in our system. Um but now they're using this power um to go do that. Now the next step is how do I know that this is good? How do I know that my model is trained properly? Well, I can simply run that. What I'm going to do now is I'm going to go run that uh demographic and I can say well this model based on these attributes here um I did find four connections and I found that it was fairly accurate. I can go back and tune it. I can add some more logic, right? I can make this model even stronger um to go do that. Well, now that I've done that, that's great. But what am I really trying to do? I am trying to find where these things intersect. Those connections as Griffin showed us. Remember that crazy board as we call it, right? Well, in one mouse click, I basically found those interconnections. And I have found that not only is Francis a customer, but it looks like there's an open case here and there's some geography and there's multiple transactions, right? And so when I do this and I can zoom back, I can start to see now that crazy board, right? I can see where these things are in time and space. I can zoom in on them and I can start to go look at those. Well, that's pretty fantastic. This normally takes much, much more time and human power to go do that. Now, if I wanted to, I could say, well, show me this in time and space. And that's what I've done here. As I see here that um there are moments in time. First of all, Fran is an employee. And you see that this is red for Fran that's a customer. Now, I have run a risk algorithm over the top that says, why did this come to my attention? Well, Fran, as we saw in that alert, has been listed for risk. Fran is both a customer and an employee. That is super bad. The second branch of this is there is a group or a community of people that Fran has potentially been linked to, which is also very bad. Now, if you notice over on the right, I have the ability to introspect this now in the next stop. What I then see is sure enough, I can see over here that well, there was a branch that Fran went to and there are other employees. Well, as you can see, as Griffin laid out, what I've done now is I've started to show this growing connection. Well, let me fast forward for you and obviously tadada or or whatever you may want to say here. I have now found that this was a much larger aspect. There was a ring through this branch of what looks like customers and employees. And what it appears that the graph has found for me is there are series of hidden accounts. there is even a family member that has been brought into this uh a group of people and that these employees were effect building fake loans with fake customers and then they were both connecting the money and then Fran who was on a blacklist is the center of this hub. Now most of our customers when they do this it takes a lot of time to write the machine learning to make those connections it may take weeks but what we've done now uh is build this in a very simplistic uh and easy to digest way and remember that graph where everybody has a place to play now I could put these in dashboards right so if you have Tableau or other kinds of things but what I'm showing you then is those things like risk or account scores or transactions or other elements remember all of that is inside of tiger graph loaded up into memory. So I can now start to slice and dice that data in a very fast uh and very fast way. Now this is not a exhaustive demonstration but I hope that was helpful uh about how these things went through. Now my last step was someone uh off the cuff there said hey could you show me what a data model looks like here? And so what we see then is this is a live part of the tool. It's called Tiger Graph Studio. And what you see then is this is the data model. It looks just like that version that a business user would see, but there's a bit more here. You can see that I can write queries. Um I have a person node. I have uh an address node. Uh and so on so forth. Now we saw those in the other business user interface, but I wasn't able to see the query or the rest endpoint behind how I did that. So in this case what we may see is a super user um that may build the data model write the queries and then a business user consumes them. So I hope this uh answers the question of what a data model might look like and then in our uh previous uh diagram over here it looks very similar to this um except for what you see then is it's just got a few more uh uh pieces of attributes and again this is secure by role. So with that I'll open the floor for questions. Perfect. Sounds good. So, our first question is from Ahmed. Um, I think Ahmed is on one of our live streams. Um, how do open-source platforms that embed graph-based AI compare with the enterprise software such as Tiger Graph? Well, I'll give you my two cents and then I'll um I'll share with you. So, one of my backgrounds is I actually am part of the Janis Graph open source user group. What you find is unfortunately graph databases are not like SQL databases or NoSQL. They do not come from the same code branch. So what happens in open source is they could be a graph engine, meaning I could run those algorithms, but I'm not very good at saving the data inside of a an atscale uh database. Well, a Janus graph for instance is very good at saving that topology map, meaning what's connected to what. But if I wanted to run a graph algorithm, I would have to go write it my very own in a Spark uh sort of a query and then I would have to again run the performance, the sharding, the read and the write. I would have to do all of those things on my own because it's open source. So the beauty of that is you don't pay anything. Um and there's a fairly rich community of that. The downside is you are now on the hook for things that Tiger quote unquote does for free. things like load balancing, things like scaling out and up, cluster management, the ability to run reads, writes, updates, um, and those graph algorithms with a drag and a drop, an IDE that allows you to do what I just did, um, in three or four minutes versus a Janus graph is really more like a line command. Now, again, your use case matters, right? So, if you're doing very simple or light kinds of things, maybe an open source works. Maybe you want to show your boss or executives before you go spend money. um that graph is a useful tool in general um before you go uh do those kinds of things. So that's kind of a quick answer. Griffin, your thoughts? No, I I think you hit the nail on the head. I mean that you can kind of go across not just graph but any sort of software, right? And there is the open-source verse enterprise readiness kind of paid for software tool that you can buy. Um but I I think you made a good point in terms of people who are maybe just starting out, right? You can go out and play with open source. Tiger Graph actually has a free a free tier on on cloud that you can spin up and play with. Um, but I think that that is a good place to start, right? Especially as you're exploring graph and how it might make sense for your organization. Nathan, I think you're on mute. Always on mute. We live in a remote world and I can't remember to unmute myself. Um I think I've mentioned this before in these that uh every morning my team has a meeting and uh every morning I forget to unmute myself before I start talking. So um uh but before I lose it in the chat, do you use any embedding techniques for your graph? So the answer is yes and no and it depends on the use case. Many times we do use embedding um for more advanced um kinds of of uh prediction and analysis and risk. Um so that is something that Tiger has a separate uh machine learning workbench and and that we can integrate those and we can do those kinds of things. We can do it outside and then as we call it decorate the graph by taking the answers and then we typically get an uplift by combining that with graph databases. And so there are some some definite use cases that lend themselves to that things like the traveling salesman um in sort of multiple kinds of real time uh shortest path and and sort of again logistics and transport. So there are those kinds of things for sure. Griffin, nothing to add. That was perfect. Okay. And then um are are y'all concerned with the ethical implications of identifying individuals as more likely to commit fraud based on algorithms? So that is always a very thorny subject and the answer is there's always concern, there is always planning and there's always vision. Now one of the things that machine learning can do is can have drift or bias. Graphs are no different, right? So we still you know there standard laws of physics and coding and and those kinds of things still apply. So absolutely it's a concern. One of the things that we try and do though and that's why we look at these pre-joins and there's a second question that I'll answer with this one as well is we can have millions or billions of pre-joined connections. We're looking for empirical connected data of historical components, attributes, and features and then running the math over the top of those to try and determine probabilistic as well as deterministic um outcomes of why this is decided to be risky. So there may be in those nodes and edges one connection to a person that is fraudulent. Um that may be mild but if I get two hits, three hits and five hits, I can now use those individual risk scores on those nodes and edges to then create a higher rubric of saying well your account was overdrawn. You're connected to Griffin and he is known within three hops to be fraud and he is verified with uh Interpol as being a fraudster. you have suddenly started doing a lot of transactional deposits in Bellarus and we know that there is um a connection in your transfer chain of something else that is you know not just simply saying hey I'm ethically thinking that you know you're a person of interest and I'm sort of labeling you no I'm using that deterministic data to go do that and again humans are always and that's the other key component here that we didn't really talk about is the human is always in the loop the human is telling the graph database that this was interesting, this was useful, this was helpful. Right? A lot of these uh fraud and AML systems today are really uh enormous uh concatenated boolean logic. If this, then this, else, if then. And over years, what happens is you get a house of cards and they all collapse. And so there are just horrible kinds of things to say, well, that's never what I meant. I never intended that to be the case. Right? That's why the graph as the more data you connect it, it actually gets stronger. It gets more accurate. Now, the human always needs to correct the system. This is not an AI, this is not uh chat, you know, GPT where, you know, Elon Musk is going to taint me and, you know, take over. The human in these kinds of fraud systems is always in the loop. So, yes, we're always concerned, but that's why this accuracy has has proven to be very, very, very useful. Okay, perfect. And the next question was about pre-joins, but I think you answered it. Is there anything else you want to uh add to that? No, Griffin and I can post some uh LDBMS uh sort of sizing. So, trillions of nodes uh massive terabytes of data in these joins are very common. Um and you know, everybody's always trying to get bigger and stronger and so we'll we'll post some of those out there. So, you know, yes, there is a logical connectivity to those, but today there's very few um that we've sort of blown the roof off because it's too large. Okay. And then uh continuing with the conversation on pre-joins, how do you avoid duplicate records when pre-joining? Well, that is uh again standard laws of uh data data loading apply. So if you notice the nodes and the vertices, the interesting thing is if I have a table, I can load the data into the node which could be a table, right? It has attributes that look like a table or the relationship. So for instance, if I have a phone number, do I want to load it on the connection between Griffin and Scott or do I want to load it on the node for Griffin? So there is a uh certainly a decision to be made because then if I'm running a lot of queries perhaps I want to put it on the edge. If I'm running it as a standard attribute and I want to run a risk calculation on the person maybe I want to leave it in the field. So the answer is it depends and we would absolutely want to make sure we do that because we don't want to duplicate that. Another fun fact for tiger graph is it is typically a compressed data. One of the patents that Tiger holds is the ability to take a terabyte of connected data and turn it into 500 gigabytes. Now, your mileage may vary. Asterisks uh apply here, which is your compression can be larger or smaller, but the point of a graph database is the tiger graph uses the graph database to create a compressed data set. Why? Because those relationships are what we're saving, not the full table and the one to many and some of the overhead we get in a relational database. Okay, sounds good. This next one's a little bit of a longer one and there might be parts of it that I'm not sure if you can actually answer or not. So, here we go. Um, hi, just would like to understand, do you have any customers from Climate Institute? This is the one I'm not sure if you're going to be able to answer or not. Um, yes. So, believe it or not, we're using not the Climate Institute, but we're using it in energy for what? We're trying to predict massive weather outages on an electrical grid, which is a network, which is a graph. And if I know that a weather incident is coming and I can look at the graph and say, "What happened the last time I had one inch of snow? What happened the last time I had 10 feet of snow? Where are the more likely electrical grid connections to fail?" That is an exact one to one for climate, microclimate, and then sort of tying that together. We also do that in trucking and transport. How is the weather going to help me reroute or airlines as we've all been stuck in airports, right, to go do that? Those are fantastic graph. Now, I'm using the weather data over here and all of its connections and historical impacts and sort of things that have happened combining that with a live where are my airplanes and pilots and where is my electrical grid. So, the answer is yes. um we do then very much use that relational data set to overlay that um to be able to give the predictions of where should I put my repair vehicles, where should I put spare parts and then more importantly do I redirect airplanes or people or things like that so that I can avoid hundreds of millions of dollars of losses um from those kind of things. So I think the answer is very close to yes for most everything you put there. Um and did we actually do it for climate? That's probably the thing that uh we would have to look at. Okay. And Scott, just to add to that real quick, um and again, we'll we'll have the resource hub in the the resources that you guys can go out to, but actually recently at our graph AI summit, we had a speaker talk about mapping scope 3 data for environmentally sustain sustainable supply chains. Tongue twister. Um but that that session is recorded. Um if you just type in scope 3 within the search bar, it'll be the first thing to pop up. Um, but again that that link to the resource hub will be there in uh in the slides. Sounds good. And and just to uh read out the rest of the question because I think Scott I think you answered every single question on the in that in that paragraph but the rest of the question was any use cases of uh using graph for climate data fault detection forecasting or root cause investigation and also what is the main rationale of using graph as customer or of using graph as customers usually have very wellestablished relational databases already and I I'll go back to the electrical grid. The number one thing they're looking for is fault detection and root cause investigation, right? Those are the number one, two, and three, right? How do I look back at a fire uh that was generated from a downed power line? How do I get that out for that fault the next time so it never happens again? Environmental and everything else that goes with it. How do I forecast and use every single uh sensor at my uh at my disposal? Is it a weather sensor, a wind sensor, a guywire on the strain on the uh the tower? All those things have to go into trying to find the root cause and forecasting the next time. So the answer is as many real-time sensors, as much data that we can do, whether it's climate or or related to climate kind of a thing, 100% of that we try and ingest. So that that says that we can do it in real time. So another thing that a tiger graph can do is do these things in real time to be able to tell you in that massive pre-join you got a problem or not a problem or you should worry about it a little bit but not go overboard right so that's kind of for the fault the forecast and the root cause um and then you know look relational databases are here forever whether anybody tells us they are or not same thing with no SQL they all serve a purpose right graph databases don't do things that old older or even newer SQL or hybrid SQL and NoSQL databases do right a graph database does things like those connected the risk those algorithms in real time much better than those other ones but if I could combine every asset in an electrical grid that's in a relational database with this prediction andor capacity planning and forecasting and root cause now what I can do is I have the power of both and that's why almost 100% of the the places we see this. Nobody throws out SQL. Nobody throws out time series. They're all there. And so the cool kids call it the polyglot or the multi- data source um to go do that. That is 100% of the case when we go do these. Okay. And um couple more questions here. Uh is that connector for visualization tools for things like PowerBI and Tableau? Um so if you think about PowerBI and Tableau, they do a great job of of SQL joins looking in the rear view. Tell me the last 12 months of things that I did. Well, there the data is very flat. If I wanted to say what were the dependencies, what were those connected parts that caused that thing to happen? Graph uh graph databases are good at that. Tableau and PowerBI are not. So, we have created those. It's called the tiger graph workbench where they could be I frame. So you could take that connected graph widget, plug it into a PowerBI or a Tableau so that they're there. Or you could use the dashboard that we have in our workbench to plug in your existing PowerBI uh or Tableau dashboards that that again people have spent a lot of money and worked in a lot of ways uh to be able to do that. So again, it's it's mix and match uh for what your use case is. Okay. And then I think this question this next person asked two questions, but I think they're all the same question. Um, so is is there a possible integration for piping a graph output to a CRM for messaging based on triggers? Absolutely. So today that uh data model screen that I showed you there is a natural rest endpoint. Every single what's called GSQL which is the code language that we use. So graph query language um allows us to write that code. Well, as soon as you write a a a a GSQL query, you are able to then push a button and it creates a REST endpoint. So, absolutely, we can connect to it. We can also do exports. We can do hybrid interfaces like I talked about. So, that same widget that I showed there can actually sit inside of your Salesforce.com. So, show me all the connections of this person uh for their supply chain. Where is their order and what are the dependencies in in their order? I could pop that into a a CRM and so it feels like I'm still in Salesforce, but I'm showing that deeply connected GSQL query inside of Tiger Graph. I've queried both of the databases at the same time and and they live together. Okay. Uh three more questions and then we'll be done. Um uh uh going back to open-source graph platforms, Griffin, I know you mentioned that um there is a free tier on Tiger Graph, but do you have any uh or or do you know of any open source graph platforms? Like can you name any? Yeah, so like Scott had mentioned, Janice Graph is the one that comes to mind and and again Scott is a big contributor to that community. Um, that is the one that we most often come across from an open source perspective. Um, there are other uh, open source graphs out there. Scott, I don't know if any other ones come to mind. It's typically Janice when we run into people who are doing stuff on the open source side. Yeah, they're um, the problem with these is every day somebody is coming out with a new open source. You know, typically with open source you like to look for one that's been around for a long time, which is why Jansgraph is sort of the leader out there. um you know it's hard to keep up with all the new products that open source you know ones that are out there. There's also, you got to be careful. There's a lot of a lot of people that have gone down trying to commercialize them and then they've open sourced them, which is um some level of I don't want to say that they've reached some either commercialization wall where you know they've been defeated because nobody wanted to buy their cool product, right? Um so you can go out and you can Google those. There's a couple of resources that we can put out there as well. So I think there's 125 or more graph databases. And again we mentioned today there are triple stores. There are um you know on there's there's every kind of one that's out there that that is everything from a hybrid to a triple store to um some of the things we talked about today were a property graph. So there's a lot of them out there. Janis graph you can't go wrong. The primary programming language there is something called Gremlin. Gremlin is actually a programming language on its own. There's something called Tinker Pop. Um, and again that all came from a grad student stream out there. So there's a lot of things that that provide goodness there. There's a fair amount of documentation. The only problem with that as we mentioned before is Gremlin is a is is a is not just a query language. It's a programming language. So now if you know Python or Java or C++ or whatever it is, you've got to go kind of learn another dialect of a programming language just to write a query as opposed to a GSQL is more like a uh friendly and easier to use query language for the graph. So Gremlin, you get both. Some people love that. Um and if you're, you know, a grad student, man, maybe that's your jam. Um so that's my two cents on that. Okay. And then uh second to last question, are there any use cases for I'm hoping I reading's hard man. Are there use cases for simplicial structures or higher categories not only data in nodes and in edges but in richer topological structures? Is any of this implemented in the software? So that is that is in reference to what we keep talking about a triple store or an ontology database or an owl formatted database. Those are things like Orango, Stard Dog, etc., and perfectly good products. Um, just a radically different approach on how you do things. Now, remember that statement where I said if you'd have, you know, one terabyte, um, and the way a property graph and tiger graph, it's able to compress that down to 500 600 gigabytes. A triple store says it in the name. You take one terabyte and you create three terabytes. Why? because you're saving all of those things in that ontology or data model. Um, and there's some other things maybe we can do is talk about the differences between those, but that's why those are slightly better and and a bit faster for things like document management. Why? Because it's saved in all three nodes. Therefore, searching and queuing for ontologies is a little faster. Ask it to run a risk algorithm and it comes to a grinding halt. Right? That's why when you look at these knowledge graphs and some of the other ones, they're they're optimized for two different styles of use case. So if you're looking for those kinds of things, I would direct you to look more at a at a triple store. And again, there's there's many commercial products out there as well. Okay. And our final question, uh, what advice would you give for a new grad student trying to seek roles in companies using GraphML? Is this experience a must-have or can it be p picked up? um most of the classes that I've seen is they're teaching today and we've hired people that are coming right out of college with um the theory of graph graph uh sort of you know the capability of of graph some people have actually gone beyond that and said I want to use graph databases for prediction of x or y right so it's not a it's not a mustave it's certainly a great to have and and what you'll find right now is if you just simply have a graph methodology or even some graph capability or even gone out and played with a tiger graph and gotten your certification or advanced graph or whatever it is, you're already ahead of about 80% of the market, right? Because a lot of people today, you know, you talk to executives and and some of them will admit this and some of them won't. They'll say, "Oh, a graph. You mean a pie chart?" No, no, that's not that's not what we're talking about, right? So, you know, anything that you can go in that direction is great. Okay, perfect. Sounds good. So, that's where we're going to end it today. Do you guys want to go over your resources really quick before I take over? Uh yeah, Scott, if you don't mind pulling back up your screen real quick. Uh let me go back and find that here. Yeah. So if you guys want to take a screenshot of of this or I guess of the last slide, Scott, if you go back real quick, if you guys have any questions, you want to reach out to us directly, can definitely find us on LinkedIn. Um obviously our emails below. Uh and again, this will get sent out. Nathan and the team will we'll get this out to you. But the next slide are some of the resources that we had mentioned, right? So, spinning up a a free tier within TGCloud, the overarching fact sheet, our our blog and resource hub. So, that's where you can find everything from benchmarks to um the certification courses, uh demo library, and then analyst report. So, again, we'll get this sent out to everybody. Um but, uh again, if you just want to go on tiger.com, there's a lot of good resources out there, whether you're looking to get started with the free tier or you're looking to dive deeper into some of the use cases that graph supports. Sound good? Well, thank you both for being here with with us