Fast and Efficient: When and Why to Use Data Graphs in Data CloudData Cloud is a data platform that brings all of your company’s data together. This gives every team a complete view of the customer, so they can automate and analyze it, make interactions more personal, and use trusted AI. Data Cloud creates this holistic customer view by turning volumes of disconnected data into a single, trusted model that’s easy to access and understand. This includes diverse data sets, like telemetry data, web engagement data, and more across your organization or your external data lakes and warehouses.

Data Cloud provides a variety of ways to act on this harmonized data. One of the ways you can consume this data is by directly querying the data in Data Cloud from an application by using Query APIs. However, because the data in Data Cloud is stored in table format, getting the data can involve joining multiple tables. This can be costly in terms of query time/billing cost. Data Graphs provide a simple solution to this by precalculating some of the needed data.

More generally, a data graph combines and transforms normalized table data from data model objects (DMOs) into new, materialized views of your data. Because the data is precalculated, you can get answers to your queries faster. Because the data is already calculated, you can query the data graph many times without having to run the underlying query again. This means you can build one and use it many times.

Let's dig deeper into this and try to understand why this matters.

At a basic level, data graphs become relevant because not all data is the same. Each data is unique in terms of business criticality, access patterns, frequency of access, change velocity, freshness requirements and so on. Here are some considerations that warrant the use of a data graph.

1. Frequency of Access: Your application is repeatedly accessing the same piece of data. In this case, instead of repeatedly querying the tables, a data graph pre-calculates the data so that it is built once and used many times.
2. Data needs to be joined with multiple tables: Your data is sourced from multiple DMOs, calculated insights (CIs), and Segment Membership DMOs. Because accessing data like this requires multiple joins, computing these joins once per query can be inefficient. Data graphs can help by precomputing this data once, allowing applications to access it multiple times rapidly.
3. Faster Query Time: Some access patterns require a fast lookup, for example, a query can be done in the context of a user action. For this kind of situation, it helps to precompute the data and make it readily available so that it can be retrieved fast.
4. Flexibility in Freshness Requirements: Many times, the application/use case doesn’t require the latest (freshest) data. Your use case can make do with data which is several hours old. Because data graphs are pre-calculated and are refreshed periodically, the precomputed data can be slightly older. Currently data graphs are refreshed once a day. For many scenarios/use cases, this can be sufficient. Realistically, there’ll be a few DMOs which will have strict freshness requirements. By mindfully combining those DMOs, which require less stricter freshness criteria into a data graph, we can achieve a good balance between freshness and efficiency.

To summarize, data graphs are ideally suited for fast and frequent data access from multiple DMOs that have less stringent freshness constraints.