图（Graph）作为数据结构，在计算机科学里存在了半个多世纪。“图工程”（Graph Engineering）并不是边界明确的正式学科名称，本文把它作为一个工作定义：围绕图的建模、存储、查询、计算、学习、运维与验证形成的系统工程。图规模、消费者和时效性要求扩大之后，这些原本分散的工作需要放进同一套方法中讨论。

图工程的学科定位

图工程在本文中承载两层含义。第一层是以图数据为中心的系统工程，涵盖建模、存储、查询、计算和学习全链路。第二层来自 AI Agent 领域：有些框架直接采用有向状态图，有些采用 crew、conversation、handoff 或普通工作流抽象；"图"是分析这些编排关系的统一视角，但并非每个框架的字面核心。两层含义的交叉点是 Agent 以知识图谱或代码图作为上下文源。计算引擎的细节见《图工程综述》，Agent 编排的边界见《Coding Agent 领域的 Graph Engineering》。

与传统数据工程的关键分野在于：

  • 分区目标通常难以精确求解。关系型数据常按主键 hash 或 range 分片；图分区需要同时考虑负载、割边和具体查询模式，许多形式属于 NP-hard 问题，工程上依赖 METIS、hash-by-vertex、edge-cut 或 vertex-cut 等启发式方案。
  • 超级节点（supernode）的度累积。社交网络里的热门账号、金融网络里的清算或归集节点会形成极高扇出。关系型系统同样会遇到热点键和高扇出外键，但图遍历会在每一跳放大这个问题。
  • 实体解析先于入库。关系型 ETL 通常假设主键唯一性由源系统保证；知识图谱和身份图谱的入库前置步骤是实体解析（entity resolution），把多个数据源里指向同一实体的记录合并为一个节点。
  • 工具成熟度不均衡。主流图数据库已经提供执行计划和监控能力，但跨引擎的基准、数据质量约束和可重复测试仍不如 SQL 生态统一。

图数据库：存储层的格局

数据模型之争：LPG vs RDF

标记属性图（Labeled Property Graph, LPG）和资源描述框架（RDF）是图数据的两大建模范式。LPG 把属性直接附着在节点和边上，查询直觉、开发友好，Neo4j/TigerGraph/NebulaGraph 都属于此阵营。RDF 把一切建模为主-谓-宾三元组，天然支持 OWL 本体推理和跨数据集的语义互操作，适合需要形式化知识表示的场景（生命科学、政府开放数据、学术知识图谱）。

工程选型的实际判据往往不是理论优雅度，而是：查询是否以路径遍历和属性过滤为主、是否需要本体推理或跨知识库联邦查询、数据约束如何表达，以及团队是否已有 Cypher、Gremlin 或 SPARQL 经验。"几跳以内"不是 LPG 的统一优化边界，必须结合具体引擎、索引和查询形状验证。

主流引擎概览

Neo4j 的当前产品线同时提供 composite database、面向特定拓扑的分片工作流和向量索引，但这些能力的版本、部署形态和许可证边界不同，不能笼统归为一个"5.x 分布式特性"。评估时应分别核对 Community、Enterprise 与 Aura 的限制。

TigerGraph 以 GSQL 和 MPP 架构面向深度遍历与并行图分析，并提供托管云形态。定价、产品名称和云服务能力变化较快，选型时应以当前合同与官方文档为准。

NebulaGraph 是中国团队主导的原生分布式图数据库，存储层基于 RocksDB，查询层使用 nGQL。nGQL 与 openCypher 有相似语法，但兼容范围需要按版本和具体语句核对，不能把它等同于 ISO GQL。

Amazon Neptune 的产品族支持 LPG（openCypher/Gremlin）和 RDF（SPARQL）工作负载，Neptune Analytics 另提供面向分析的内存优化能力。两种数据模型和查询接口可以并存，但并不意味着一条查询可以任意混用 LPG 与 RDF 语义。

新生代值得关注的有：PuppyGraph（直接查询数据湖表中的图关系）、FalkorDB（源自 RedisGraph 路线的图引擎，面向低延迟查询和 GraphRAG），以及 LadybugDB 等嵌入式图数据库。原 KuzuDB 仓库已于 2025 年 10 月归档，只适合维护存量版本；新项目应评估仍在维护的后继分支或替代方案。

查询语言标准化：GQL 的里程碑

ISO/IEC 39075:2024（GQL）是 SQL 之后新的 ISO 数据库查询语言标准，吸收了 Cypher、PGQL、G-CORE 等既有属性图语言与研究成果，定义图模式匹配、路径变量和图构造等能力。不同语言对标准的影响并不等于现有方言可以直接互换。

GQL 对工程实践的影响类似于 SQL-92 之于关系型数据库——在此之前，每换一个图数据库就要重学一种查询语言；标准化后，至少核心的模式匹配语义有了跨引擎的可移植性。不过 2026 年中的现实是：完整实现 GQL 规范的引擎仍然有限，多数引擎处于"部分兼容"或"roadmap 中"状态。

与 GQL 并行的是 SQL/PGQ（ISO/IEC 9075-16:2023），它允许在关系表之上定义属性图并使用图模式匹配。Oracle 已提供相关实现；截至 2026 年 8 月，PostgreSQL 18 尚未包含 SQL/PGQ，PostgreSQL 19 Beta 文档才出现原生 property graph 支持。标准已经发布，不代表所有关系型数据库已经可用。

图计算引擎：从 Pregel 到流批一体

计算范式演进

图计算引擎解决的核心问题是：当图大到单机放不下时，如何在分布式集群上高效执行 PageRank、连通分量、最短路径等全图算法。

Pregel/BSP（Google, SIGMOD 2010）确立了以顶点为中心的编程模型和整体同步并行（Bulk Synchronous Parallel）执行模式。每个顶点在一个超步（superstep）内处理消息、更新状态、发送消息，超步之间有全局 barrier 同步。Apache Giraph 曾是其重要开源实现，但已经进入 Apache Attic。

GAS/PowerGraph（CMU, OSDI 2012）针对 Pregel 在重尾度分布图上的性能问题提出 Gather-Apply-Scatter 三阶段模型。少数超级节点收到的消息量远超平均值时，vertex-cut 可以把其邻接边分散到多个机器，再通过镜像同步顶点状态。

Push/Pull 混合模型（Gemini, OSDI 2016）进一步优化通信效率。核心思想借鉴自 Ligra（PPoPP 2013）：活跃前沿稀疏时用 push，前沿稠密时用 pull，避免无效边扫描或消息构造。Gemini 由清华大学团队开发，其实验原型和论文公开，但公开代码与可直接部署的完整产品不是一回事。

主要框架

GraphScope（阿里巴巴/GRAPE 团队）是当前功能最完整的图计算平台，包含三个子引擎：GAE（图分析引擎，基于 GRAPE 的 auto-parallelization）、GIE（交互式查询引擎，兼容 Gremlin/Cypher）、GLE（图学习引擎）。部署在 Kubernetes 上，支持从 Vineyard（内存数据管理系统）直接读取图数据，避免序列化开销。

Plato（腾讯）是 C++ 实现的高性能图计算框架，设计思路受 Gemini 启发，在腾讯内部支撑社交网络分析和推荐系统的离线图计算任务。其源码在 2020 年开源后更新频率下降，但核心的通信优化思路（自适应 push/pull + NUMA-aware 内存布局）仍有参考价值。

Apache GeaFlow（Incubating） 代表流图计算（streaming graph computation）方向：在图持续变化时维护状态并执行增量计算，减少反复导出全图快照的成本。其项目名、代码仓库演进与 TuGraph-family 有历史关系，但当前官方名称仍是 Apache GeaFlow。

Spark GraphX 仍是 Spark 4.x 文档中的内置 RDD 图 API，优势是复用现有 Spark 数据管线；没有一手依据证明它已进入官方维护模式。Flink Gelly 则已在 Flink 1.17 开发周期被移除，不能再与 GraphX 并列为当前可选库。

中国团队在图计算领域的集中贡献

2015 年之后，清华（Gemini、GridGraph）、阿里（GraphScope/GRAPE）、腾讯（Plato）、蚂蚁（GeaFlow）在图系统论文和开源项目上形成了密集产出。超大规模社交关系、交易网络和推荐数据提供了直接工程动机，但用户量和交易峰值属于持续变化的业务指标，不能在缺少日期和财报口径时当作系统能力证明。

知识图谱：从构建到 LLM 融合

构建流水线

知识图谱的构建是一个多阶段管线：命名实体识别（NER）→ 关系抽取（RE）→ 实体链接（Entity Linking）→ 知识融合（Knowledge Fusion）→ 质量评估。2024-2026 年间，LLM 开始进入其中多个阶段：

  • NER 和 RE 可以用 LLM 做 few-shot/zero-shot 抽取，但专用模型仍适合稳定、高吞吐的已知类型；
  • 实体链接可以让 LLM 参与候选排序，但仍需要候选生成、别名库和可校验标识；
  • 矛盾检测可以利用 LLM 做语义判断，但结果需要来源、置信度和人工或规则校验。

代价是成本、延迟和可重复性。LLM 是否优于传统 NER 取决于领域、标签体系、模型和提示词，不能用一个未注明基准的 F1 结论概括。较稳妥的组合是让轻量模型或规则处理高频稳定类型，LLM 处理长尾候选，再用约束和抽样审计控制质量。

工业级知识图谱

Google 在 2020 年公开的 Knowledge Graph 规模是超过 50 亿实体、5000 亿事实；这是带日期的公开口径，不代表 2026 年实时规模。Wikidata 的实体与陈述数持续变化，应链接实时统计页。OpenAlex 的官方统计页在 2026 年 7 月显示约 3.17 亿 works；其帮助中心采用更宽口径时会出现更高数字，因此引用时必须说明统计页面和日期。

这些大型知识图谱都要处理持续更新、长尾质量和跨语言对齐。头部实体的属性往往相对完整，长尾实体的信息则更稀疏，也更容易过时。

GraphRAG 与 KG+LLM 融合

GraphRAG（Microsoft, arXiv:2404.16130）主要面向需要全局理解的查询，例如"这篇文档集的主要主题是什么"。传统向量 RAG 可能漏掉与查询不直接相似、但在逻辑上相关的信息。GraphRAG 先把文档预处理为实体-关系图，再基于社区检测（Leiden 算法）生成分层摘要，用于回答这类全局问题。

工程上的关注点是索引成本。GraphRAG 需要实体关系抽取、社区检测和多层摘要，官方仓库也明确提醒索引可能昂贵；成本随模型、提示词、文本密度和缓存策略变化，不能写成统一的每百万 token 单价。原始论文主要验证全局 sensemaking 问题，不足以证明它在所有简单事实查询上必然弱于向量 RAG。更准确的定位是：GraphRAG 优先解决跨文档、全局主题和关系聚合问题，局部事实检索仍应保留向量、关键词或混合索引。

KG+LLM 融合在 2024-2026 年催生了 LightRAG、HippoRAG 等多种检索结构。分析机构对 context graph 的采用比例有过预测，但在缺少可公开核对的原始报告、样本和定义时，不宜把百分比写进技术判断。项目规划应回到可验证问题：关系查询是否真的提升答案质量，索引成本和陈旧数据风险是否可接受。

图神经网络：从研究到生产

框架生态

PyG（PyTorch Geometric） 适合 PyTorch 生态中的 GNN 研究和原型开发，算子与数据集覆盖广。DGL（Deep Graph Library） 及 DistDGL 面向图采样和分布式训练，但后端支持范围应按当前版本核对。NVIDIA WholeGraph + cuGraph 提供 GPU 加速的图采样、存储与分析能力。框架选择取决于模型算子、采样方式、硬件和部署栈，而不是 GitHub stars。

生产落地模式

GNN 在工业界的主要落地场景包括：

推荐系统。Pinterest 的 PinSage（KDD 2018）是在数十亿节点、数百亿边图上训练节点嵌入的早期工业 GNN 系统之一，用于 Related Pins 推荐。其工程贡献在于随机游走采样与 importance pooling，使 mini-batch 训练能够扩展到全图无法直接装入单个训练批次的规模。

金融反欺诈。GNN 可以把账户、设备、商户和交易关系联合建模，用采样、异构关系聚合和时间特征识别团伙模式。公开论文中的离线指标不能直接等同于支付系统的生产效果；涉及公司、产品、奖项和线上收益时，必须给出可核对的一手论文或工程案例。

社交网络基础设施。Meta 的 TAO（The Associations and Objects）是读优化的分布式图服务层。Meta 在 2022 年公开的 TAOBench 文章称，TAO 在多 PB 变化数据集上总计服务超过每秒 100 亿次请求。TAO 本身不是 GNN 系统，这个案例说明的是在线图服务的规模，不应拿来替代 GNN 训练或效果证据。

图基础模型的早期信号

2025-2026 年出现了图基础模型（Graph Foundation Model）的早期尝试——在大规模异构图上预训练通用的节点/边表示，下游任务通过少量标注做 fine-tuning。这个方向仍处于学术探索阶段，尚未出现类似 BERT/GPT 在 NLP 领域的"iPhone 时刻"。关键挑战在于：不同领域的图结构差异巨大（社交图 vs 分子图 vs 知识图谱），通用预训练目标的设计比文本和图像困难得多。

工程实践模式

图分区策略

分布式图系统的第一个工程决策是如何把图切开放到多台机器上。三种主流策略各有适用场景：

  • Hash-by-vertex：按顶点 ID 哈希分配，实现简单，但跨分区边比例高，适合顶点计算密集、边遍历较少的场景。
  • Edge-cut：最小化跨分区的边数量，适合需要大量邻居遍历的场景（如 BFS、n-hop 查询），但切割本身的计算开销不小。
  • Vertex-cut：将高度顶点的邻接表切分到多个分区，适合幂律度分布明显的图。PowerGraph 的 GAS 模型天然适配这种切割方式。

实践中的常见陷阱：选择了 edge-cut 但图的度分布呈强幂律 → 超级节点所在分区成为热点；选择了 hash-by-vertex 但查询模式是多跳遍历 → 每一跳都需要跨网络通信。

超级节点处理

度数极高的节点（社交网络里的明星、交易网络里的清算中心）是图系统的普遍痛点。工程手段包括：

  • 邻接表分片：将超级节点的边列表分散存储在多个分区，查询时并行聚合。
  • 虚拟节点拆分：将一个超级节点拆成多个虚拟节点，每个虚拟节点承载部分边，查询时透明合并结果。
  • 采样近似：对不要求精确结果的分析查询（如"这个节点的邻居中有多少比例是活跃用户"），用随机采样代替全量遍历。

图的测试策略

图系统的测试难度高于关系型系统。几个特有的挑战：

  • 确定性难保证：图算法（如 Louvain 社区检测）的结果可能因遍历顺序不同而产生合法的不同输出，传统的 assertEqual 不适用。
  • 测试数据构造成本高：构造一个能触发特定图算法 corner case 的测试图（如特定直径、特定度分布）比生成几行 SQL 测试数据困难得多。
  • 性能测试需要代表性拓扑：Erdős-Rényi 随机图与真实重尾图在局部性、前沿扩张和热点上差异很大。基准至少应包含真实图或能复现目标度分布、社区结构和属性宽度的合成图。

LDBC（Linked Data Benchmark Council）提供了一套标准化的图基准测试族：Graphalytics（6 种基础算法）、SNB Interactive（社交网络交互式查询 QPS）、FinBench（蚂蚁集团主导的金融图查询基准）。

业界案例

Meta TAO：社交图的分布式服务层

TAO 是 Meta 的在线社交图存储服务。公开资料可以确认其读优化、地理分布、分层缓存和最终一致性设计，以及 2022 年超过每秒 100 亿次请求、多 PB 数据集的口径；公开资料没有给出可通用于所有请求的"万亿边、亚毫秒"保证。其分片围绕对象和关联的访问模式设计，也不能简化成按 object-type 分库。

Pinterest Pixie：实时图游走推荐

Pinterest 公开的 Pixie 系统在数十亿节点、超过 1000 亿边的二部图上执行实时个性化随机游走，用近似 Personalized PageRank 生成候选。2017 年工程文章给出的目标与生产口径是单机每秒约 1000 次查询、P99 约 60 毫秒。这个数字属于当时的硬件、图快照和候选生成逻辑，不能视为所有在线图游走系统的基线。

金融反欺诈：实时多跳检测

金融反欺诈常把实时交易事件、有限深度邻域探索、风险子图特征和决策引擎串成一条链。"3-6 跳"和"数百毫秒"只能作为某个规则、数据规模和部署条件下的目标，不能由 GeaFlow 的产品定位直接推出。生产设计还要限制扇出、处理事件乱序，并把图信号与账户规则、设备指纹和模型评分合并。

未来趋势

GQL 标准的实际落地。ISO 标准已经发布，但各引擎的实现范围不同。未来所需时间无法用统一的"2-3 年"预测；新项目应把具体语法、事务语义和迁移测试纳入验收，而不是只看 roadmap 标签。

流批一体图计算。GeaFlow 代表的方向是在同一引擎中统一处理图的流式更新和批量分析，正在从金融反欺诈扩展到更多实时图场景（社交网络异常检测、供应链风险传导）。

KG+LLM 的组合检索。LLM 可以承担自然语言理解和生成，知识图谱可以提供结构化关系与来源路径，但图结构不会自动保证事实正确。GraphRAG 的变体仍在快速迭代，是否采用应由问答质量、索引成本、数据新鲜度和可追溯性共同决定。

图引擎与数据湖的融合。PuppyGraph 式的"零拷贝图查询"（在 Parquet/Iceberg 等数据湖格式上直接执行图查询而不搬迁数据）代表了一种降低图技术采用门槛的路径。对已有大量数据湖资产的企业，这可能比迁移到专用图数据库更现实。

SQL/PGQ 作为关系数据上的图视图。PostgreSQL 19 Beta 已出现原生 property graph 文档，PostgreSQL 18 及更早版本仍需要扩展或其他方案。它降低的是数据搬迁成本，不会消除图查询优化、热点和测试问题。

选型决策框架

面对具体的图工程需求时，可以从以下路径开始，但边数只用于估算，最终边界由属性宽度、查询形状、算法状态和硬件决定：

  1. 数据规模 < 1 亿边，查询以点查/短路径为主 → 评估图数据库（Neo4j/NebulaGraph/Neptune），或在已有 PostgreSQL 上尝试 AGE 扩展。
  2. 数据规模 > 10 亿边，需要全图算法（PageRank/社区检测/连通分量） → 评估图计算引擎（GraphScope/Plato/Spark GraphX）。
  3. 需要实时增量图计算（欺诈检测/异常传播） → 评估流图引擎（GeaFlow）或图数据库的 streaming ingest + trigger 能力。
  4. 需要从非结构化文本构建图 → 知识图谱构建管线（LLM 抽取 + 实体链接 + 图存储）。
  5. 需要图上的预测/分类/推荐 → GNN 训练管线（PyG/DGL + 分布式采样 + 在线推理服务）。
  6. 已有数据湖，不想搬迁数据 → 评估 PuppyGraph 或 SQL/PGQ 方案。

这些路径不互斥，也不要求全部采用。团队规模小、查询深度有限、数据仍能被 SQL join、LSP、倒排索引或向量检索有效处理时，先不要引入图数据库和图计算集群。只有关系本身成为主要查询对象，且现有方案在正确性、延迟或可维护性上出现可测量瓶颈，图工程的额外成本才有充分理由。

参考资料