5.3 图算法与图数据科学：让算法接管深度遍历

5.3 图算法与图数据科学：让算法接管深度遍历

本节摘要：变长路径解决"有没有路"，图算法解决"路里有什么结构"——谁是枢纽、哪些节点抱团、两点之间最短的是哪条。本节介绍图数据科学库（GDS）的投影模型与四大算法族，完整演练一次"建投影、跑 PageRank、写回结果"的流程，并划清"裸 Cypher 与算法"的分工线。

2.3 节说过：深度无界的遍历不交给裸 Cypher。交给谁？本节给出答案——图数据科学库（Graph Data Science，GDS），一组在图上高效运行的成熟算法。

一、GDS 的心智模型：投影、算法、写回

GDS 不直接在原库上跑算法，而是先把图投影到内存里的分析专用副本，跑完把结果写回原库。三步的心智图：

第一步 投影（Project）：把关注的节点/关系装进内存分析图
第二步 算法（Compute）：在投影上执行，输出分数/社区/路径
第三步 写回（Write）：结果作为新属性落回原库节点，供 Cypher 查询
​

图：GDS 三步流程与负载隔离

投影的好处是双重的：分析负载与在线查询负载隔离；投影可以做"只装某种关系"的裁剪，算法只看它该看的子图。

二、四大算法族速览

选型口诀：找关键节点用中心性，找团伙用社区，找路用路径，做推荐用相似度。第 7 章的场景实战会各取所需。

三、完整演练：给演员图跑 PageRank

在 Movie 沙盘上回答"谁在合作网络里最有影响力"。合作网建模为：两位演员共同出演同一部电影，则连一条 CO_ACTED 关系。

// 第一步：构建合作网关系（若尚未存在）
MATCH (a:Person)-[:ACTED_IN]->(m:Movie)<-[:ACTED_IN]-(b:Person)
WHERE a <> b
MERGE (a)-[r:CO_ACTED]->(b)
ON CREATE SET r.weight = 1
ON MATCH  SET r.weight = r.weight + 1
​

建立合作网：共 N 条 CO_ACTED 关系（weight = 合作次数）
​

// 第二步：建内存投影（gds 图目录，名为 coact）
CALL gds.graph.project(
  'coact',
  'Person',
  { CO_ACTED: { orientation: 'UNDIRECTED', properties: 'weight' } }
)
​

投影完成：节点 130+，关系数百条，占用内存几百 KB
（生产图上这里是亿级，投影规格决定内存预算）
​

// 第三步：跑 PageRank 并流式返回前十
CALL gds.pageRank.stream('coact', {
  relationshipWeightProperty: 'weight'
})
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).name AS 演员, round(score, 3) AS 影响力
ORDER BY 影响力 DESC LIMIT 10
​

演员            | 影响力
----------------|-------
"Tom Hanks"     | 2.417
"Keanu Reeves"  | 1.983
"Carrie-Anne Moss" | 1.522
...
​

// 第四步：结果写回原库，之后用普通 Cypher 就能查
CALL gds.pageRank.write('coact', {
  writeProperty: 'influence',
  relationshipWeightProperty: 'weight'
})
YIELD nodePropertiesWritten
​

nodePropertiesWritten: 130
之后：MATCH (p:Person) WHERE p.influence > 2 RETURN p.name —— 原生 Cypher 可查
​

四、裸 Cypher 与算法的分工线

不是所有图问题都需要 GDS。分工判据看遍历形状：

局部问题（一跳两跳、路径已知）      → 裸 Cypher（第 2 章的全部技能）
全局问题（全图排名、整体社区划分）  → GDS 算法
最短路径且权重明确、可在线响应      → 两者皆可：小图 Cypher，
                                     大图或要权重导航用 gds.shortestPath
​

成本上也要算账：投影需要内存（规格与图规模成正比）、算法执行是批量作业——GDS 适合离线或准实时（分钟级）计算，不适合毫秒级在线查询里现算。在线推荐的标准架构是"GDS 离线算好写回 + 在线 Cypher 直查结果属性"，第 7 章推荐系统一节就是这个模式。

💡 运维提醒：投影常驻内存。gds.graph.list 定期盘点，用完的投影 gds.graph.drop 释放——分析库的内存泄漏多半来自"建了投影忘了删"。

五、选算法前的三个自问

拿到分析需求，先过三问再翻算法手册：

一问：输出是什么？—— 分数（中心性）、分组（社区）、
     路径（寻优）、还是配对（相似度）
二问：图多大、跑多频？—— 决定投影规模与是否常驻
三问：结果给谁用？—— 进推荐服务（写回属性），
     还是给人看（流式返回 + 可视化）
​

三问答完，算法族的候选通常只剩一两个。算法选型的难点从来不是"记不住几百个算法"，而是"说不清业务问题属于哪一族"——这也是 7.1 与 7.2 两个场景反复演示的问题翻译过程。

本节要点回顾

• GDS 三步：投影 → 算法 → 写回，分析与在线负载隔离；
• 四大算法族对应四类问题：中心性、社区、路径、相似度；
• 投影可裁剪（只装相关节点与关系），规格决定内存预算；
• 分工线：局部遍历裸 Cypher，全局结构 GDS，在线毫秒查询不现算；
• 结果写回为节点属性，让算法产出融入普通查询。

内核与算法齐备。下一章盘点生态工具与云端部署形态——站在内核之上做选型。