图（Graph）作为数据结构，在计算机科学里存在了半个多世纪。但"图工程"（Graph Engineering）作为一个独立的工程学科被讨论，是最近五六年的事。这个转变类似于数据工程从 DBA 工作中独立出来的过程——当图的规模从百万节点膨胀到百亿、当图的消费者从算法研究员扩展到业务开发者、当图的时效性要求从离线 T+1 压缩到实时毫秒级，一套横跨存储、计算、查询、学习的系统工程方法论就必然成形。

图工程的学科定位

图工程在 2026 年的语境里承载着两层含义。第一层是本文的主题：以图数据为中心的系统工程，涵盖图的建模、存储、查询、计算和学习全链路。第二层含义来自 AI Agent 领域——LangGraph、CrewAI 等框架把 Agent 的编排抽象为 DAG（有向无环图），"Graph Engineering"在这个语境下指的是 Agent 工作流的 DAG 设计。两层含义的交叉点是：越来越多的 Agent 系统把知识图谱作为上下文源（GraphRAG），图存储与 Agent 编排在生产系统中开始共生。

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

  • 分区是 NP-hard 问题。关系型数据按主键 hash 或 range 分片，确定性强；图数据的最优切割是 NP-hard，工程上只能用启发式近似（METIS、hash-by-vertex、edge-cut vs vertex-cut），不同切割策略对不同查询模式的性能影响可达数量级差异。
  • 超级节点（supernode）的度累积。社交网络里明星账号的关注者可达亿级，金融网络里中心节点的交易边在峰值时段持续膨胀。关系型数据库没有"某一行的外键引用数量爆炸"这个问题。
  • 实体解析先于入库。关系型 ETL 通常假设主键唯一性由源系统保证；知识图谱和身份图谱的入库前置步骤是实体解析（entity resolution），把多个数据源里指向同一实体的记录合并为一个节点。
  • 测试和可观测性工具链不成熟。SQL 数据库有成熟的慢查询分析、执行计划可视化、数据质量框架；图数据库的等价工具在 2026 年仍处于早期阶段。

图数据库：存储层的格局

数据模型之争：LPG vs RDF

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

工程选型的实际判据往往不是理论优雅度，而是：查询模式是否需要超过 3 跳的路径遍历（LPG 引擎通常优化到 3-6 跳）、是否需要与外部知识库做联邦查询（RDF + SPARQL 的强项）、团队是否已有 Cypher/Gremlin 经验。

主流引擎概览

Neo4j 在 5.x 系列中持续强化分布式能力（composite database、sharding）和向量索引支持，同时将商业重心转向 Aura 云服务。社区版与企业版的功能差距在集群、安全和 ops 特性上持续拉大。

TigerGraph 以其 GSQL 语言和 MPP（大规模并行处理）架构在深度遍历场景（6+ 跳的欺诈检测环路）上表现突出。其 2025 年的定价调整和 Savanna 云服务的推出反映了与 Neo4j Aura 正面竞争的策略。

NebulaGraph 是中国团队主导的原生分布式图数据库，存储层基于 RocksDB，计算层支持 nGQL（兼容 openCypher 子集）。其 GQL 支持进度在国产图数据库中领先。

Amazon Neptune 的双模引擎同时支持 LPG（openCypher/Gremlin）和 RDF（SPARQL），省去了选型时二选一的焦虑。Neptune Analytics（2024 年 GA）加入了图分析算法的内置执行能力。

新生代值得关注的有：PuppyGraph（零拷贝查询数据湖中的图数据，不搬迁原始数据）、FalkorDB（基于 Redis 的图引擎，主打 GraphRAG 场景的低延迟）、KuzuDB（嵌入式图分析引擎，采用列式存储+向量化执行，适合单机分析场景和快速原型验证）。

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

ISO/IEC 39075:2024（GQL）是 SQL 之后第一个新的 ISO 数据库查询语言标准。它整合了 Cypher、PGQL、GSQL、G-CORE 四种方言的设计经验，定义了完整的图模式匹配、路径变量、图构造等语法。

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

与 GQL 并行的是 SQL/PGQ（SQL:2023 扩展），它允许在传统 SQL 查询中嵌入图模式匹配子句。这条路径的意义在于：不需要迁移到专用图数据库，就能在 PostgreSQL、Oracle 等关系型引擎上执行图查询。对已有大量关系型资产的企业而言，这可能是图技术的最低摩擦入口。

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

计算范式演进

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

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

GAS/PowerGraph（CMU, SOSP 2012）针对 Pregel 在幂律图上的性能问题提出了 Gather-Apply-Scatter 三阶段模型。核心洞察是：自然图的度分布遵循幂律，少数超级节点收到的消息量远超平均值，Pregel 的 all-to-one 消息模式在这些节点上成为瓶颈。GAS 通过 vertex-cut（将超级节点的邻接表分散到多个机器上）来缓解热点。

Push/Pull 混合模型（Gemini, OSDI 2016）进一步优化通信效率。核心思想借鉴自 Ligra（EuroSys 2013）的共享内存图框架：当活跃顶点比例高时用 push（活跃顶点主动向邻居发消息），比例低时切换为 pull（非活跃顶点主动拉取邻居状态）。Gemini 在清华大学陈文光团队开发，虽未完整开源（仅有 demo 代码），但其思想深刻影响了后续的中国图计算生态。

主要框架

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

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

GeaFlow/TuGraph-Analytics（蚂蚁集团）代表了图计算的另一个方向：流图计算（streaming graph computation）。其动机来自金融反欺诈场景——实时检测 6 跳以内的异常资金链路需要在图持续变化的同时执行增量计算，传统的"全图快照 + 批计算"模式满足不了秒级时效要求。GeaFlow 将流处理（类似 Flink 的 event-time/watermark 语义）与图遍历统一在同一引擎中。

Apache Flink Gelly 和 Spark GraphX 作为通用流批引擎的图计算库，优势在于与已有数据管线的无缝集成，劣势在于不如原生图引擎的遍历性能。GraphX 在 Spark 3.x 后进入维护模式，新项目建议评估 GraphScope 或直接使用图数据库的内置分析能力。

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

2015 年之后，图计算引擎领域出现了显著的中国团队集中贡献现象。清华（Gemini、GridGraph）、阿里（GraphScope/GRAPE）、腾讯（Plato）、蚂蚁（GeaFlow/TuGraph-Analytics）在系统论文和开源项目上形成了密集的产出。这与中国互联网公司面临的超大规模社交图和交易图直接相关——微信月活 13 亿用户、支付宝日交易量峰值数十亿笔，这些规模的图数据为图计算系统的研发提供了充足的工程动机和验证场景。

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

构建流水线

知识图谱的构建是一个多阶段管线：命名实体识别（NER）→ 关系抽取（RE）→ 实体链接（Entity Linking）→ 知识融合（Knowledge Fusion）→ 质量评估。每个阶段在 2024-2026 年间都经历了 LLM 的渗透：

  • NER 和 RE 从需要标注数据训练专用模型，转向 LLM few-shot/zero-shot 抽取；
  • 实体链接从依赖预训练实体嵌入，转向 LLM 直接做候选排序；
  • 知识融合中的矛盾检测开始利用 LLM 的推理能力判断两个三元组是否语义冲突。

代价是成本和延迟上升。一个典型的权衡是：LLM 抽取在长尾实体类型上的 F1 值显著优于传统 NER 模型，但单条抽取延迟从毫秒级涨到秒级，且 token 成本使大规模构建的经济性存疑。工程实践中常见的折中方案是：高频实体类型用轻量模型批量抽取，低频/长尾类型用 LLM 补充。

工业级知识图谱

Google Knowledge Graph 积累了约 80 亿实体和 8000 亿事实，是搜索结果右侧知识面板的底层数据源。Wikidata 作为开放社区维护的结构化知识库，拥有 1 亿+ 实体和 100 亿+ 三元组。OpenAlex（学术知识图谱）整合了 2.71 亿篇学术作品的元数据和引用关系。

这些大型知识图谱的共性挑战是：持续更新（知识的时效性衰减）、长尾质量（头部实体的属性相对完整，长尾实体的信息稀疏且容易过时）、以及跨语言对齐。

GraphRAG 与 KG+LLM 融合

GraphRAG（Microsoft, arXiv:2404.16130）的核心主张是：对需要全局理解的查询（“这篇文档集的主要主题是什么”），传统的向量相似度 RAG 会遗漏不与查询直接相似但逻辑相关的信息；把文档预处理为实体-关系图，再基于社区检测（Leiden 算法）做分层摘要，可以回答这类全局性问题。

工程上的关注点是成本。GraphRAG 论文发布时的预处理成本约为每百万 token 数十美元（使用 GPT-4），到 2026 年中随着 GPT-4o-mini、Claude 3.5 Haiku 等低价模型的普及以及开源替代方案成熟，实际成本已降至每百万 token 8-15 美元区间。但一个容易被忽略的事实是：对简单事实型查询（“X 是什么”），GraphRAG 的表现反而低于标准向量 RAG。GraphRAG 的优势集中在需要跨文档推理的复杂查询上。

更广泛地看，KG+LLM 融合在 2024-2026 年催生了一系列变体：LightRAG（轻量级双层图索引）、HippoRAG（模拟海马体的记忆检索）、TagRAG（标签驱动的图检索）。Gartner 在 2025 年预测到 2028 年超过 50% 的 AI Agent 将使用某种形式的上下文图谱（context graph）——这个预测的方向性判断可能合理，但具体百分比来自单一分析机构的估算，不宜作为硬性规划依据。

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

框架生态

PyG（PyTorch Geometric）（GitHub 24K+ stars）是 GNN 研究和原型开发的首选框架，覆盖了从经典 GCN/GAT 到最新的图 Transformer 的完整算子库。DGL（Deep Graph Library） 及其分布式版本 DistDGL 在大规模训练场景上有优势，支持 PyTorch 和 TensorFlow 双后端。NVIDIA WholeGraph + cuGraph 提供 GPU 加速的图采样和特征提取，适合嵌入超大图（百亿边级别）的工业训练管线。

生产落地模式

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

推荐系统。Pinterest 的 PinSage（KDD 2018）是最早的十亿级图上 GNN 推荐系统之一，在 30 亿+ item、2 亿+ 用户的二部图上训练节点嵌入，用于 Related Pins 推荐。其工程贡献在于随机游走采样 + importance pooling 的组合，使得全图训练变得可行。

金融反欺诈。蚂蚁集团的 RAOS（KDD 2025 最佳论文候选）在微信支付的异常交易检测中引入了风险感知的关系采样策略——不是均匀采样邻居，而是根据历史风险信号对邻居加权，减少正常交易节点对异常信号的稀释。

社交网络。Meta 的 TAO（The Associations and Objects）是支撑 Facebook/Instagram 社交图的分布式图服务层，峰值 QPS 达数十亿。虽然 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 是 Facebook/Instagram 社交图的核心存储服务，设计目标是在数十亿节点、万亿级边的规模上提供亚毫秒读延迟和每秒数十亿次查询吞吐。其架构要点：分层缓存（leader cache → follower cache → storage engine）、eventual consistency 模型（容忍短暂的读取不一致以换取吞吐）、以及按 object-type 分库而非按 graph partition 分库。

Pinterest Pixie：实时图游走推荐

Pixie 在 Pinterest 的 30 亿+ Pin、2 亿+ 用户、180 亿+ 边的二部图上执行实时个性化随机游走。与离线训练 GNN 嵌入不同，Pixie 在请求时实时从用户的历史 Pin 出发做短程随机游走（通常 3-5 步），根据游走命中频率排序候选 Pin。这种在线计算的优势是能即时反映用户最新行为，劣势是对图服务层的延迟要求极高（P99 < 100ms）。

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

蚂蚁集团和 PayPal 的反欺诈系统代表了图技术在金融领域的深度应用。典型模式是：实时交易事件触发 → 从交易节点出发做 3-6 跳邻域探索 → 匹配预定义的风险子图模式（如三角转账、扇出再汇聚）→ 风险评分输入决策引擎。GeaFlow 的流图计算能力使得这类多跳检测能在交易发生后数百毫秒内完成，而非传统的 T+1 批量跑批。

未来趋势

GQL 标准的实际落地。ISO 标准已发布，但从标准文档到各引擎的完整实现还有 2-3 年的过渡期。这个过渡期内，Cypher 仍将是事实标准（Neo4j 用户基数最大），但新项目值得关注 GQL 兼容性 roadmap。

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

KG+LLM 的深度共生。2026 年的趋势不再是"KG 或 LLM"的选择题，而是两者在生产系统中的分工趋于清晰：LLM 负责理解自然语言意图和生成，KG 负责提供结构化的事实锚点和可追溯的推理路径。GraphRAG 的变体还在快速迭代，但"用图结构增强 LLM 的事实性"这个方向已经站稳。

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

SQL/PGQ 作为图技术的最低摩擦入口。PostgreSQL 社区对 SQL/PGQ 的实现进度值得持续关注——如果主流关系型数据库原生支持图模式匹配，图技术的采用曲线可能出现拐点。

选型决策框架

面对具体的图工程需求时，一个粗粒度的决策路径：

  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 方案。

这些路径不互斥。一个成熟的图工程体系通常同时包含图数据库（在线查询）、图计算引擎（离线分析）、知识图谱管线（数据构建）和 GNN 训练服务（预测模型）四个组件，它们之间通过图数据的导入导出管道连接。

参考资料