🚀 Apache HugeGraph X OSPP
亲爱的开源爱好者们，
一年一度的「开源之夏」再次启航！🌞
Apache HugeGraph 社区面向全国高校学子发布项目任务，等待充满激情和技术实力的你来挑战！
🎯 任务方向覆盖：图数据库 AI Agent 分布式系统 向量检索 图计算等
📌 快速指南
• 🧠 背景：基于 Graph/AI 项目生态，结合 LLM/图计算/存储/向量等技术热点 • 📦 任务形式：围绕核心组件、工具链和未来演进方向完成社区 Tasks • 🧑🏫 导师支持：来自 HugeGraph PMC/Committer 的专属辅导 • 💼 成果认可：优秀同学有望直接晋升至 Apache Committer 额外社区🎁~
🔥 项目列表
1️⃣ 实现图计算系统 Vermeer 任务优先级调度器 📈
🧑🏫 导师：WenYuXuan (947901996@qq.com[1])
⌛ 期望完成时间: 240 小时
🧪 难度：进阶
📖 项目简介：
背景：
Vermeer 是一个 Go 编写的自研 HugeGraph 高性能分布式图计算框架(内存优先)。在图计算平台上，承载用户例行的图计算任务。
但目前 vermeer 的任务调度器只支持单个任务的发起和顺序的调度，而在真实的使用场景下，用户的使用方式是多样的，现有任务的发起方式需要用户自己包装逻辑。并且任务的大小和执行速度，在顺序调度的情况下会经常出现资源利用率较低的问题。并且在这其中包含了任务依赖关系，状态检查等问题。因此 vermeer 需要进一步完善任务调度器，以此实现更好的易用性。
本课题旨在设计并实现一种针对分布式图计算平台的优先级调度策略，通过结合任务资源占用大小、任务优先级等实现优先级调度策略，提高多用户多任务情况下的资源利用率。实现多种任务发起新特性，提升用户易用性。
预期目标：
1. 设计并实现一种适合图计算平台的优先级任务调度方案。 2. 优化图计算任务使用方法 3. 实现 batch 特性，支持用户一次性发起批处理任务，注意任务依赖检测。 4. 实现 routine 特性，支持用户发起周期性任务，并对周期性任务进行管理。
🔧 技术要求：
1. 熟悉 Go 语言编程，熟练掌握 Goroutines 等并发编程特性 2. 理解分布式系统的基本原理，包括容错机制、负载均衡等。 3. 熟悉常见/业内计算平台的任务调度策略 4. 熟悉常见图算法（如 pagerank、WCC 等）及其分布式实现方法 或 使用过分布式图计算框架（如 GraphX、Giraph、PowerGraph 等）者优先 5. 具有系统级性能优化经验或参与过分布式系统相关项目者优先
📝 备注：
项目备注 & 产出要求 & 成果仓库 & 支持架构请详见链接[2]
2️⃣ HugeGraph 支持向量索引存储与检索 💾
🧑🏫 导师：JackyYang (yang.jiaqi.hadoop@gmail.com[3])
⌛ 期望完成时间: 260 小时
🧪 难度：进阶
📖 项目简介：
随着 LLM/AI 快速发展，向量存储检索已经成为构建 LLM RAG/Agent 应用架构中的重要一环，进而催生了Milvus 等向量库的火爆，KV存储中 KVRocks/OB/ES/Neo4j 等 NoSQL 数据库也跟进支持向量检索，降低业务应用中的选型复杂度。
HugeGrpah 已经在社区业务中广泛应用，为了更好的整合支持业务使用向量场景，降低业务上手/使用门槛，决定引入向量存储检索和查询的能力。拓展此能力意义在于支撑 LLM 应用，拓宽原有场景使用方式。(也可以尝试用 Graph Embedding 来代替默认的 Text-Embedding, 准确性可能更高)
Steps:
1. 可以先实现单机版下的向量索引存储 + 查询 (基础) 2. 实现 HStore 分布式后端 (Raft) 下的索引 + 查询 (能力强的同学也可以直接基于分布式向量存储查询实现)
目标: 可根据向量 embedding 的结果, 找到子图 VertexID 或 Property，更好的是可以结合原生的图结构, 复用 Graph Embedding
PS:
• 向量索引可优先集成成熟的 Java 开源库进行开发 (例如 Apache Lucene, 也可参考 Elastic Search 实现分布式向量索引方式) • 如果有比较合适的 C++/Rust 可方便集成的库也可以选用 (参考 OB/KVRocks 等)
🔧 技术要求：
1. 熟悉 Java/C++ 至少一种强类型编程语言, 理解向量存储的原理和使用 2. 熟悉分布式系统相关基础知识 (Raft/VectorDB/Embedding) 3. 熟悉 KV/LSM/Graph 原理以及有开源贡献/个人博客等优先
📝 备注：
项目备注 & 产出要求 & 成果仓库 & 支持架构请详见 OSPP 官网链接[4]
3️⃣ Text2Gremlin 的数据生成和模型微调系统 📝
🧑🏫 导师：imbajin (0x00@imbajin.com[5])
⌛ 期望完成时间: 200 小时
🧪 难度：进阶
📖 项目简介：
背景:
通过 RAG/Agent 与数据库交互完成数据查询/调优等工作是业内的的落地趋势，其中重要的一环是Text2SQL/Text2GQL（这里 GQL 在 HugeGraph 里主要指的 Gremlin）类的任务
在面向图数据库的 Text2Gremlin 任务中，我们也面临训练数据少 + 数据生成/衍生难 + 数据标注成本高的 3 大核心问题，也感谢 TuGraph 社区已经提前做了不少相关的开源铺垫和实践, 已基于 Cypher 为主的图查询语言设计和实现了一个初版的基于 AST + LLM 组合的语料生成方案, 详见备注参考链接等说明[1][2][3]
但由于 Cypher 和 Gremlin 的 AST 结构相差很大, Gremlin 本身函数式的风格也更为灵活多变, 所以之前的系统版本还无法简单兼容 Text2Gremlin 的生成, 需要单独实现这块的 AST + Rule 逻辑
任务:
我们期望能在 TuGraph/XiYan 等社区的初版代码基础上, 来进一步共建和完善 Tex2GQL 的语料生成 + 模型微调的环节/社区生态, 让它支持 Gremlin 并能更好的适配例如常见 Qwen-Coder 等模型的快速微调, 并分 2 个大阶段来进行代码开发:
1. 实现给定 Schema + 基础/初始数据集的语料增强生成 (阶段一: 垂类生成/微调) 2. 实现基于 AST/RBO 的不限 Schema + 通用数据集的语料生成 (阶段二: 通用生成/微调)
希望有对此感兴趣和探索意愿的同学进行参与/共建, 欢迎提前沟通思路后再编写 proposal~ (实现方式/语言不限)
🔧 技术要求：
1. 熟悉至少 Python/Rust/Java 至少其中一种语言编程, 能快速理解和上手一个新的项目
1.1：熟练使用 AI Coder 工具 Prompt 工程加分2. 熟悉 AST/语法语义解析, 有较好的工程实践能力
2.1：有 DSL parser 经验, 或 NLP/语义分析经验更佳3. 了解至少 Text2SQL/Text2GQL 业内设计实现思路
3.1：有中小数据集 Qwen/ds/llama 模型微调相关更佳
📝 备注：
项目备注 & 产出要求 & 成果仓库 & 支持架构请详见链接[6]
4️⃣ 实现 HugeGraph Toolchain-Loader 的内外代码融合 🛠️
🧑🏫 导师：王哲 (spica@apache.org[7])
⌛ 期望完成时间: 150 小时
🧪 难度：基础
📖 项目简介：
Loader 是 HugeGraph (Toolchain) 中用于从"文本/传统数据库/Spark/Flink" 等数据源转为图数据的导入组件，目前存在以下的不足:
• 使用不够灵活，需要远程到服务器上命令行方式执行 (Docker 版本也稍有些繁琐) • 缺乏任务管理和监控的能力, 目前接近单词的的任务执行设计 • 有些 parse 和转换的地方没有充分利用并行化, 还有较多的性能优化空间 • 数据传输链接过长，多次的序列化反序列化，耗费 CPU 资源。在分布式环境下，这会成为 hugegraph 导入的性能瓶颈并且可能影响到线上实时的读取性能。
新的 V2 版本我们需要增数据导入服务，以服务化的方式可长期运行(不局限为一次性任务)，实现服务到服务的数据导入。具有以下几个优点:
• 实现核心链路的尽可能多的并行化, 可使用协程/虚拟线程方式进行优化 • 数据导入服务可选 bypass-mode 绕过 HugeGraph Server，实现 RPC 直接写分布式图存储 HStore • 有基本的监控能力，可以实现定时增量导入数据 • 以服务的形式运行在服务端，提供任务管理功能
本课题已有可参考的设计实现思路，大家可以在参考它的基础上进行更好的完善和优化 (仅供参考)
🔧 技术要求：
1. 熟悉至少 Java 相关编程基础, 对并发编程有了解和追求更佳 2. 具备能快速了解并上手开源项目的能力, 快速阅读对比不同源码的区别 3. 熟悉 AI Coder 工具或丰富的 LLM 提效经验优先 4. 有 Graph/DB/ 导入工具相关经验 or 参与开源项目项目者优先
📝 备注：
项目备注 & 产出要求 & 成果仓库 & 支持架构请详见链接[8]
5️⃣ 实现轻量高性能的 Agentic GraphRAG 架构
🧑🏫 导师：simon (3656562@qq.com[9])
🧪 难度：进阶
⌛ 期望完成时间: 240 小时
📖 项目简介：
背景介绍
目前，我们已经实现了一个基础的 GraphRAG(可支持 Text2GQL+子图查询+自定义图算法执行)，但它依赖于固定的 pipeline/workflow（例如，知识检索和图更新会复用类似的流水线），这导致在变化/复杂场景下灵活性不足, 扩展性也会十分受限。
于是我们旨在引入一种基于“动态感知、轻量级调度、并发执行” 为基本原则的智能化（Agentic）架构，将 GraphRAG -转变-> Graph Agent, 核心有以下几个问题：
1. 高效的意图识别：使其有效区分简单检索（如实体查询）和复杂操作（如多跳推理），哪些适合直接 Text2GQL, 哪些适合子图/OLAP 算法, 哪些可能需要综合多者。 2. 轻量高性能的任务编排：内存/计算资源可根据任务特性进行隔离调度，并且实现对 workflow 和 agentic 化的支持 (但要避免引入重度的 Agent 框架) 3. 智能重试机制：对于错误操作缺少自我修正能力, 期望能够结合 COT/快慢思考/自反思等机制, 实现一个可选择且灵活的 workflow, 尽可能让机制和策略解耦 (开发者也可以自行快速实现 DIY 版本)
该任务将包含三个核心部分：
1. 动态感知层
• 实现一个基于高效的意图分类器，该分类器能根据语义特征 + 复杂度用离线 + 在线(LLM) 组合的方式, 对任务进行分类（e.g: L1 简单检索 L2 路径推理 L3 OLTP算法 L4 OLAP算法等） • 通过支持 cache/规则匹配/小模型等方式，实现毫秒级的意图匹配, 并能在不同判断地进行复用
2. 任务编排层
• 引入一个合适/低耦合、高性能兼顾灵活性的工作流/任务流框架 • 可考虑直接使用成熟的 workflow 实现 (例如llamaindex/crewai), 也可引入优秀的 Rust/C++ 库(保证易用性和接口统一即可)
3. 并行与策略化
• 将传统的固定流水线解耦为可组合的 step 操作（实体召回 → 路径验证 → 上下文增强 → 结果精炼），并支持各功能/step 的灵活开关 • 支持自动降级，在查询流程 A 失败时触发回退策略（例如，如果 Text2GQL 查询超时，快速切换到替代方法） • 对于 workflow/pipeline 里并行的部分支持自动并行化, 提供良好开发支持 (同编排层) • 核心代码可全部重构为异步/协程实现方式, 配合事件驱动 flow 进行编程
业内已有大量实现参考方案与代码实现, 详情可见项目备注的参考链接🔗, 有问题可提前交流沟通~
🔧 技术要求：
1. 擅长 Python，并熟悉至少一种开源/闭源 LLM 模型
1.1：擅长异步编程 一门强类型语言更佳
1.2：有快速阅读源码能力2. 具有 LangGraph/RAGflow/LLamaindex/Dify 等至少一种 LLM RAG/Agent 框架的使用经验
2.1：了解 LLM 优化技术和 RAG 构建（具备 KG 提取/构建经验者优先）3. 具备较强的工程实践能力（问题抽象、数据处理、模型调优）
3.1：理解图算法（如社区发现、中心性、PageRank 等），有开源社区经验者优先
3.2：熟悉 GraphDB/Vector 使用或读写流程优先4. 关注业内 LLM 相关技术, 擅长使用 AI Coder/工具/MCP 或者 Prompt 工程同学优先
📝 备注：
项目备注 & 产出要求 & 成果仓库 & 支持架构请详见链接[10]
6️⃣ HugeGraph Gremlin 优化与 Java 17 支持 ☕️
🧑🏫 导师：vaughn (vaughn@apache.org[11])
🧪 难度：基础
⌛ 期望完成时间: 150 小时
📖 项目简介：
背景：
HugeGraph 现在主要的查询语言 Gremlin 源自图查询语言框架 Apache TinkerPop， 目前 HugeGraph 使用的是 3.5.1 的 TinkerPop, 它内置的 Groovy 引擎灵活但安全性欠佳, 想保证安全性需要牺牲不小的性能和写许多黑白名单, 对用户使用不友好
而 Gremlin 的新版本 3.7.x 已经正式支持了 Java17， 并更新了 Groovy 4 大幅改善了性能和安全性 ， 是一次意义重大的升级/提升， 完成它的适配意味着 HugeGraph 所有组件可以正式使用 Java17 的新特性， 不仅修复了大量 Gremlin查询的 Bug， 优化了不少 Perf/API/Security 相关的优化， 可以提升 HugeGraph 的性能表现。
我们希望完成 Gremlin 与 Java 新版的的升级适配, 并重构 HugeGraph 关于 Groovy Security 这块的代码逻辑.
🔧 技术要求：
1. 熟悉 Java 开发环境， 理解 HugeGraph 的基本图（点边）存储结构和设计实现 + 读写流程 2. 熟悉任何一门 FP/图语言， 熟悉 Tinkerpop Gremlin
则更佳 (推荐 Cookbook + LLM 上手)3. 了解 Tinkerpop Gremlin
框架, 或熟悉 AST 语法解析/ 函数编程优先4. 了解 Java17 的新特性/新 GC 的使用, 有性能分析经验更佳
📝 备注：
项目备注 & 产出要求 & 成果仓库 & 支持架构请详见链接[12]
引用链接
[1]
mailto:947901996@qq.com[2]
链接:https://summer-ospp.ac.cn/org/prodetail/25ec80379?list=org&navpage=org[3]
mailto:yang.jiaqi.hadoop@gmail.com[4]
链接:https://summer-ospp.ac.cn/org/prodetail/25ec80385?list=org&navpage=org[5]
mailto:0x00@imbajin.com[6]
链接:https://summer-ospp.ac.cn/org/prodetail/25ec80457?list=org&navpage=org[7]
mailto:spica@apache.org[8]
链接:https://summer-ospp.ac.cn/org/prodetail/25ec80475?list=org&navpage=org[9]
mailto:3656562@qq.com[10]
链接:https://summer-ospp.ac.cn/org/prodetail/25ec80515?list=org&navpage=org[11]
mailto:vaughn@apache.org[12]
链接:https://summer-ospp.ac.cn/org/prodetail/25ec80519?list=org&navpage=org
