作者：林岚｜OC 开发者生态编辑

开发者 Sem Sinchenko 使用 Apache DataFusion 实现了一套 图计算实验，在 5GB 内存限制下完成约 10.5 亿条边的 PageRank，并在 10GB 内存下处理约 19.6 亿条边的弱连通分量计算。

一句话结论：这项实验没有让十亿级图计算突然变快，而是证明只要把随机访问改造成批量扫描、允许中间结果落盘，许多原本要求整图进内存的任务也能在普通机器上完成。

传统图算法常把节点、边和邻接关系常驻内存，这对 NetworkX、igraph 等单机库很自然，但图一大就先撞上容量上限。Sinchenko 采用类似 Pregel 的批同步思路，把每轮计算表达为扫描、连接和聚合，让 DataFusion 负责查询规划、排序合并连接、内存池和磁盘 spill。

PageRank 测试使用 Graphalytics 的 graph500-26 数据集，包括约 3280 万个节点和 10.5 亿条边。进程被 systemd-run 限制到 5GB 内存，DataFusion 内存池设置为 4GB；15 轮迭代约用 30 分钟，结果在给定容差内与基准答案一致。

弱连通分量测试更重：原始 Twitter 图约有 5258 万节点、19.6 亿条有向边，算法需要把边对称化，处理中间规模超过 30 亿条边。作者在 10GB 内存、无交换分区并限制 CPU 的环境中完成计算，并与 Graphalytics 标准结果核对。

代价很明确。磁盘外算法会反复读写 Parquet 和中间结果，速度通常比足够内存中的专用图库慢。作者也记录了 FairSpillPool 在极端压力下可能死锁，以及排序合并连接不能复用磁盘预排序等问题。这个项目更像容量可行性证明，不是已经胜过 Spark 或专用图系统的完整基准。

它真正有价值的地方，是重新划分工程选择。很多团队不是每天做实时图查询，而是偶尔跑去重、关系聚类、PageRank 或离线风控。如果任务能接受几十分钟到数小时，先用嵌入式查询引擎和本地磁盘处理，可能比搭一套分布式集群更便宜、更容易复现。

关键事实

• PageRank：约 3280 万节点、10.5 亿条边、5GB 内存限制、约 30 分钟
• 弱连通分量：约 5258 万节点、19.6 亿条原始边、10GB 内存限制
• 核心方法：批量扫描、连接、聚合和中间结果落盘
• 主要限制：单人实验、速度不是目标，仍存在 spill 死锁和重复排序问题

OC 判断

先别把“笔记本处理十亿级图”理解成分布式系统已经没用。这里换来的不是免费性能，而是用更多顺序 I/O 和等待时间换更低内存。对批处理任务，这笔交换可能非常划算；对低延迟交互查询，它仍然不合适。

为什么重要

• 对开发者：先确认任务是否真的需要随机访问和实时响应，再决定要不要让整张图常驻内存。
• 对小团队：离线图分析可以先从 DataFusion、DuckDB 一类嵌入式引擎验证，不必立即上集群。
• 对 DataFusion：稳定的 spill、排序复用和内存压力测试将决定它能否承担更多图工作负载。

参考来源

• Algorithms on billion-scale graph using 10GB RAM
• Apache DataFusion features
• Apache DataFusion configuration and memory-limited queries