Degree Centrality
Introduction
The Degree Centrality algorithm can be used to find popular nodes within a graph. The degree centrality measures the number of incoming or outgoing (or both) relationships from a node, which can be defined by the orientation of a relationship projection. If a projection contains directed relationships, only outgoing relationships of a node are counted (the out-degree). For more information on how relationship orientations influence the algorithm result, see the setting an orientation section.
It can be applied to either weighted or unweighted graphs. In the weighted case the algorithm computes the sum of all positive weights of adjacent relationships of a node, for each node in the graph. Non-positive weights are ignored.
It can be applied to heterogenous graphs, however the algorithm will not calculate degree centrality per relationship type. Instead it will treat the graph as homogenous, as indicated by the algorithm traits.
For more information on this algorithm, see:
Use-cases
The Degree Centrality algorithm has been shown to be useful in many different applications. For example:
-
Degree centrality is an important component of any attempt to determine the most important people in a social network. For example, in BrandWatch’s most influential men and women on Twitter 2017 the top 5 people in each category have over 40m followers each, which is a lot higher than the average degree.
-
Weighted degree centrality has been used to help separate fraudsters from legitimate users of an online auction. The weighted centrality for fraudsters is significantly higher because they tend to collude with each other to artificially increase the price of items. Read more in Two Step graph-based semi-supervised Learning for Online Auction Fraud Detection
Syntax
This section covers the syntax used to execute the Degree Centrality algorithm.
CALL Neo4j_Graph_Analytics.graph.degree(
'CPU_X64_XS', (1)
{
['defaultTablePrefix': '...',] (2)
'project': {...}, (3)
'compute': {...}, (4)
'write': {...} (5)
}
);
1 | Compute pool selector. |
2 | Optional prefix for table references. |
3 | Project config. |
4 | Compute config. |
5 | Write config. |
Name | Type | Default | Optional | Description |
---|---|---|---|---|
computePoolSelector |
String |
|
no |
The selector for the compute pool on which to run the Degree Centrality job. |
configuration |
Map |
|
no |
Configuration for graph project, algorithm compute and result write back. |
The configuration map consists of the following three entries.
For more details on below Project configuration, refer to the Project documentation. |
Name | Type |
---|---|
nodeTables |
List of node tables. |
relationshipTables |
Map of relationship types to relationship tables. |
Name | Type | Default | Optional | Description |
---|---|---|---|---|
mutateProperty |
String |
|
yes |
The node property that will be written back to the Snowflake database. |
relationshipWeightProperty |
String |
|
yes |
Name of the relationship property to use as weights. If unspecified, the algorithm runs unweighted. |
orientation |
String |
|
yes |
The orientation of the relationships. Can be 'NATURAL', 'REVERSE', or 'UNDIRECTED'. |
For more details on below Write configuration, refer to the Write documentation. |
Name | Type | Default | Optional | Description |
---|---|---|---|---|
nodeProperty |
String |
|
yes |
The node property that will be written back to the Snowflake database. |
Examples
In this section we will show examples of running the Degree Centrality algorithm on a concrete graph. The intention is to illustrate what the results look like and to provide a guide in how to make use of the algorithm in a real setting. We will do this on a small social network graph of a handful nodes connected in a particular pattern. The example graph looks like this:
CREATE OR REPLACE TABLE EXAMPLE_DB.DATA_SCHEMA.USERS (NODEID STRING);
INSERT INTO EXAMPLE_DB.DATA_SCHEMA.USERS VALUES
('Alice'),
('Bridget'),
('Charles'),
('Doug'),
('Mark'),
('Michael');
CREATE OR REPLACE TABLE EXAMPLE_DB.DATA_SCHEMA.FOLLOWS (SOURCENODEID STRING, TARGETNODEID STRING, SCORE DOUBLE);
INSERT INTO EXAMPLE_DB.DATA_SCHEMA.FOLLOWS VALUES
('Alice', 'Doug', 1.0),
('Alice', 'Bridget', -2.0),
('Alice', 'Charles', 5.0),
('Mark', 'Doug', 1.5),
('Mark', 'Michael', 4.5),
('Bridget', 'Doug', 1.5),
('Charles', 'Doug', 2.0),
('Michael', 'Doug', 1.5);
With the node and relationship tables in Snowflake we can now project it as part of an algorithm job. In the following examples we will demonstrate using the Degree Centrality algorithm on this graph.
To run the queries in this section, there is a required setup of grants for the application, your consumer role and your environment. Please see the Getting started page for more on this.
We also assume that the application name is the default Neo4j_Graph_Analytics. If you chose a different app name during installation, please replace it with that.
Run job
Running a Degree Centrality job involves the three steps: Project, Compute and Write.
CALL Neo4j_Graph_Analytics.graph.degree('CPU_X64_XS', {
'defaultTablePrefix': 'EXAMPLE_DB.DATA_SCHEMA',
'project': {
'nodeTables': [ 'USERS' ],
'relationshipTables': {
'FOLLOWS': {
'sourceTable': 'USERS',
'targetTable': 'USERS'
}
}
},
'compute': {
'relationshipWeightProperty': 'SCORE'
},
'write': [{
'nodeLabel': 'USERS',
'outputTable': 'USERS_CENTRALITY'
}]
});
JOB_ID | JOB_START | JOB_END | JOB_RESULT |
---|---|---|---|
job_fbf4a243f3ed46c2895f5d1673911a4b |
2025-04-29 11:41:43.604000 |
2025-04-29 11:41:50.077000 |
{ "degree_1": { "centralityDistribution": { "max": 6.000030517578124, "mean": 2.8333396911621094, "min": 0, "p50": 1.5, "p75": 6.000022888183594, "p90": 6.000022888183594, "p95": 6.000022888183594, "p99": 6.000022888183594, "p999": 6.000022888183594 }, "computeMillis": 14, "configuration": { "concurrency": 2, "jobId": "c70c50fd-6cb1-4c43-b92a-1ce283073aac", "logProgress": true, "mutateProperty": "degree", "nodeLabels": [ "*" ], "orientation": "NATURAL", "relationshipTypes": [ "*" ], "relationshipWeightProperty": "SCORE", "sudo": false }, "mutateMillis": 2, "nodePropertiesWritten": 6, "postProcessingMillis": 75, "preProcessingMillis": 10 }, "project_1": { "graphName": "snowgraph", "nodeCount": 6, "nodeMillis": 334, "relationshipCount": 8, "relationshipMillis": 633, "totalMillis": 967 }, "write_node_property_1": { "exportMillis": 2325, "nodeLabel": "USERS", "nodeProperty": "degree", "outputTable": "EXAMPLE_DB.DATA_SCHEMA.USERS_CENTRALITY", "propertiesExported": 6 } } |
The returned result contains information about the job execution and result distribution. Additionally, the centrality score for each of the seven nodes has been written back to the Snowflake database. We can query it like so:
SELECT * FROM EXAMPLE_DB.DATA_SCHEMA.USERS_CENTRALITY;
Which shows the computation results as stored in the database:
NODEID | SCORE |
---|---|
Alice |
6.0 |
Bridget |
1.5 |
Charles |
2.0 |
Doug |
0.0 |
Mark |
6.0 |
Michael |
1.5 |
Here we can see that the Alice
and Mark
nodes have the highest degree centrality, which means that the total weight of the outgoing relationships from these nodes is the highest.
Setting an orientation
By default, node centrality uses the NATURAL
orientation to compute degrees.
For some use-cases it makes sense to analyze a different orientation, for example, if we want to find out how many users follow another user.
In order to change the orientation, we can use the orientation
configuration key.
There are three supported values:
-
NATURAL
(default) corresponds to computing the out-degree of each node. -
REVERSE
corresponds to computing the in-degree of each node. -
UNDIRECTED
computes and sums both the out-degree and in-degree of each node.
CALL Neo4j_Graph_Analytics.graph.degree('CPU_X64_XS', {
'defaultTablePrefix': 'EXAMPLE_DB.DATA_SCHEMA',
'project': {
'nodeTables': [ 'USERS' ],
'relationshipTables': {
'FOLLOWS': {
'sourceTable': 'USERS',
'targetTable': 'USERS'
}
}
},
'compute': {
'orientation': 'REVERSE'
},
'write': [{
'nodeLabel': 'USERS',
'outputTable': 'USERS_CENTRALITY_REVERSE'
}]
});
SELECT * FROM EXAMPLE_DB.DATA_SCHEMA.USERS_CENTRALITY_REVERSE;
NODEID | SCORE |
---|---|
Alice |
0.0 |
Bridget |
1.0 |
Charles |
1.0 |
Doug |
5.0 |
Mark |
0.0 |
Michael |
1.0 |
Here we can see that the Doug
node has the highest in-degree, which means that it is followed by five other users.
The Alice
node has the lowest in-degree, which means that it is not followed by any other user.