-
Notifications
You must be signed in to change notification settings - Fork 528
HugeGraph Tasks V2.0
For Students & 开源之夏扩展的完整版本, 开源之夏原有任务不受影响, 这边是全新扩展出的更多任务, 随时更新ing
注: 开始任务前, 请务必先使用 + 阅读一下已有的 HugeGraph 相关文档/文章/Slide (参考资料), 把主流程和背景大概清楚后, 再开始阅读源码
下列任务基本都位于 Server 主仓库 (github.com/apache/hugegraph), 基本都是核心的数据结构/存储结构/性能优化/新增功能/分布式存储这几块, 不同于开源之夏 OSPP 列表已有的任务(且 OSPP 活动限定一个 task 仅可 1 人参与), 特点如下:
- 下面新增的所有任务(不包括进阶要求)都是有大量的已有源码 + 设计文档可参考的, 大幅降低了参与的门槛 + 难度/工作量 (文档会同步到 Wiki)
- 给出了每个任务的评估难度/工作量等, 大家可根据个人情况自由选择(1 ~ N个, 无限制), 另建议每个任务 1 个同学参与 (组队至少按子项拆分)
- 多数任务有基础/进阶两个部分, 完成任一部分皆可获得奖金, 更灵活
- 在 OSPP 中提交了任务/中选的同学, 也可同时参与这部分新增任务 (前提是有余力)
- 需要注意同样需要提交基本的
proposal和时间规划/背景说明, 有类似的 task 结项要求 (proposal 可简洁清晰化) - 新增任务报名截止日期为 7 月 1号前, 鼓励大家提前准备/报名, 任务被提前确认预订后会及时更新状态为"已预订"
总体来说, 新增的任务是为了让更多的同学有机会参与开源/HugeGraph, 只是参与方式 + 任务量安排/门槛上更加灵活, 目前支持下面 2 种, 大家可以根据个人倾向自行选择:
任务参与方式:
- CCF协会 开源活动中参与模式 (限制是需要在 CCF 专属的代码平台[类似 gitee]进行提交与审阅等, 同步更新较为麻烦, 奖金等结算周期长)
- Apache HugeGraph 基金会直接分配模式, 社区独立的任务模式 (无额外第三方平台, 灵活性最高)
注: 因与 OSPP 官方沟通后, 平台已经不允许再新增/修改任何 Task, 所以目前先考虑这两种方式, 有更好的方式或者平台提交任务可随时告知
在之前开源之夏的分布式存储任务基础上, 诚邀熟悉分布式存储/RocksDB/LSM 的同学参与其他相关任务, 这里会持续更新拆分 (或是有意报名 OSPP 对应项目担心落选的同学也可联系报名)
背景:
HugeGraph 之前的元信息是存储在第三方的存储组件中, 没有单独的元信息存储节点(PD), 现在会引入新的 PD 节点(已有), 我们需要做的是让当前的 Server 的元信息能(可选)存储于 PD 之上, 并优化之前冗余/非必要的表结构, 进行 table struct 的整合, 最后是对异步等 Server Task 的存储进行拆分和优化
核心任务:
-
Graph Schema 信息存储到元数据中心 (PD(Place Driver), 也可简单理解为
meta-server)关键描述: schema 等图的元信息的存储移植到元数据中心 PD 存储，后端存储不再使用m store存储 [依赖 PD]
-
存储表结构优化缩减到 6 个 (原 10 +)
关键描述: 移除
s store更改表映射关系，减少为:g+v、g+oe、g+ie、g+index、g+task、g+olap -
任务存储结果拆分
关键描述: 任务结果单独存储到
task_result表中任务信息查询，只有查询单个任务时，才会 mergetask_result表的结果信息 -
分布式异步任务调度器
关键描述: 能支持多节点 server 运行时的任务(分布式)调度 [已有核心代码实现, 依赖 PD]
技能要求:
- 熟练在 Java + Linux 下开发, 理解当前 HugeGraph 的基本图(点边)存储结构和设计实现 + 读写流程
- 了解分布式系统中 MetaServer/PD 的设计作用和基本通信方式, 熟悉 etcd/zookeeper/RPC 更佳
- 需要有较强的源码阅读 + 问题分析/解决能力 (任务已有大量源码实现可参考/复用, 亦有基本的设计文档)
mentor: imbajin
Difficulty: middle (3 星⭐)
Size: middle (3 星⭐)
Bonus: 8k/10k (核心/全部完成)
背景:
HugeGraph 原本的边设计存储结构可参考已有文档, 那么之前的设计存在一些图定义上的不便之处, 例如 likes 作为一类 EdgeLabel, 只能唯一作用与两个 VertexLabel 之间(例如 Teacher–like–>Student), 然后其他的 VertexLabel只能选择单独新建其他名字标示 likes, 比如 (Student –like2 –> Dog), 从而边与边之间缺乏一种继承关系, 每个 EdgeLabel 都是孤立的, 在此背景下, 我们对 EdgeLabel 的存储结构进行优化调整, 使其能支持"父子边 & 通用边" 的 2 个功能 (进阶项: 可以对 VertexLabel 也进行类似的思考与优化)
核心任务:
-
边 Schema 支持"父子边"继承关系/功能
关键描述: 边存储的
rowkey结构增加子边类型,完成适配, 并思考新增了字段后产生的影响, 优化边的查询 -
支持 general 边(类型)
关键描述: 增加 general 边类型，定义
schema时不再需要指定边的source/target的vertexlabel类型
技能要求:
- 熟练在 Java + Linux 下开发, 理解当前 HugeGraph 的基本图(点边)存储结构和设计实现 + 读写流程
- 熟悉当前 HugeGraph 图点边存储的细节以及利弊点, 能结合需求思考图设计的考量点
- 需要有较强的源码阅读 + 问题分析能力 (任务已有大量源码实现可参考/复用, 亦有基本的设计文档)
mentor: cx/待定
Difficulty: middle (2.5星⭐)
Size: middle (3 星⭐)
Bonus: 3k (完成进阶项则奖金翻倍)
背景:
了解了 HugeGraph 的读/查询流程之后, 可知道我们主要提供两种查询方式 :① Gremlin/Cypher 的通用图语言查询 ② 单独的 RESTful 图算法(例最短路径/K 步邻居/相似性等), ①和②各有利弊, 那么这个的任务是对 ② 的大量已有算法进行优化可功能上的扩展: 例如减少它灵活性上的不足, 在查询返回结果里允许自定义过滤属性/跳过不必要的搜索/提前停止等, 以此优化查询性能, 它的另一个进阶的任务是可使得 OLTP 算法都能并行去执行 (目前大部分是串行/单线程模式)
核心任务:
-
通用的 OLTP 算法优化
关键描述:
- 所有 OLTP 算法 API 支持顶点和边的属性过滤 (减少不必要的图搜索 + 返回数据量大小)
- 所有 OLTP 算法 API 支持顶点和边完整信息跳过/返回 (当前版本仅返回点边id, 或部分属性)
- 所有接口返回中增加 statistic 统计信息（例如: 遍历的顶点、边数量和耗时）
-
kout算法查询增加DFS模式 (原本仅有BFS模式) -
(进阶) 算法实现过程中，支持批量 + 并发(多线程)执行
技能要求:
- 熟练在 Java + Linux 下开发, 理解当前 HugeGraph 的基本图(点边)存储结构和设计实现 + 读写流程
- 熟悉当前 HugeGraph 的 OLTP 算法的基本设计和典型实现原理,
- 需要有较强的源码阅读 + 问题分析能力 (任务已有大量源码实现可参考/复用)
mentor: pzy/待定
Difficulty: middle (2.5星⭐)
Size: middle (2星 ⭐)
Bonus: 3k/8k (完成基础/进阶任务)
背景:
数据库中基本的概念是, 主键之外, 属性的查询要么需要进行全表扫描, 要么需要建立对应的**(二级)索引**; 在 HugeGraph 中, 图的 unique 索引可用于数据查询移除 NoIndexException，如未完全命中索引，则可考虑使用某个索引+ConditionQuery.test的方式过滤， 如完全没有索引，则进行全表扫描+ConditionQuery.test方式过滤三种类型A、B、C， A、B建立了基于属性x的索引，当执行 g.V().has(x, ?)时，需要查询到A、B索引结果和C的非索引结果
核心任务:
-
对部分命中(未完全命中)的查询进行优化, 避免抛出异常
关键描述: 一个图查询如果部分命中索引, 应该基于命中索引后的部分再做"扫表"查询, 而不应直接抛出异常 or 直接扫全表
技能要求:
- 熟练在 Java + Linux 下开发, 理解当前 HugeGraph 的基本图(点边)存储结构和设计实现 + 读写流程
- 熟悉当前 HugeGraph 图索引存储的细节以及利弊点, 能结合需求思考图设计的考量点
- 需要有较强的源码阅读 + 问题分析能力 (任务已有大量源码实现可参考/复用)
mentor: wcb
Difficulty: hard (4星⭐)
Size: middle (2星 ⭐)
Bonus: 3k
背景:
HugeGraph 现在主要的查询语言 Gremlin 源自图查询语言框架 Tinkerpop, 它的 OLTP 查询基本都是使用的"单线程 + DFS"的查询方式, 自然在复杂的查询中就会显著遇到瓶颈, 业内有阿里的 GAIA: A System for Interactive Analysis on Distributed Graphs Using a High-Level Language 论文对这个问题进行了深入的探讨和重构, 我们需要部分实现图 Gremlin 查询的并行化
核心任务:
-
了解基本 Gremlin 查询性能分析方式 + 支持部分语句(
step算子)下的 Gremlin 并行化关键描述:
-
HugeGraphStep中点/边查找支持批量+并发查询 -
HugeVertexStep中临接点/边的查询支持批量+并发查询
-
-
在 Tinkerpop 社区/issue 中寻找/探索进一步的规划和可能方案尝试
-
包括不限于复用 GAIA-X 中的部分优秀设计/更好的设计方案, 对现有的单 step 并行进行更深的改造 (可选, 加分项)
技能要求:
- 熟练在 Java + Linux 下开发, 理解当前 HugeGraph 的基本图(点边)存储结构和设计实现 + 读写流程
- 了解任何一门图查询语言, 熟悉
Tinkerpop Gremlin则更佳 (有教程可学习入门) - 有基本的 Paper 阅读能力 + 良好的调研和沟通能力
- 需要有较强的源码阅读 + 问题分析能力 (任务已有大量源码实现可参考/复用, 亦有基本的设计文档)
mentor: suzhaojun
Difficulty: middle (3星⭐)
Size: low (1星 ⭐, 已有 9成源码实现)
Bonus: 3k (加分项完成上升至 12k 起)
注: 进阶项任务难度上升至 5 星⭐, 工作量上升至 4 星⭐, 建议感兴趣的同学先阅读一下论文看看理解情况.
补充 ing
任务描述:
- 增加
arthas server内嵌服务接口 (也就是说启动 HG Server 后可以直接使用 Arthas 动态观测/perf/debug, 无需单独安装) - 按照图名称、接口名称计算请求总数、成功数、失败数、平均响应时间、最大响应时间 (接口返回格式兼容
Prometheus即可) - 增加白名单监控信息
补充 ing
任务描述:
- 按照顶点和边label和属性过滤生成一张子图增加子图Job
- auth Server删除system graph删除更新权限接口增加租户管理员
- 增加schema模板，创建图空间时，可指定schema模板查询schema groovy格式返回属性改名
核心是参考 docker-issue, 完成 TODO ✅ 项待完成部分
mentor: coderzc/imbajin
Difficulty: low (1.5星⭐)
Size: middle (3星 ⭐, 需要调试和测试)
Bonus: 3~6k (视 TODO 项完成数)
备注: 如果熟悉 k8s, saas 化的同学, 可以完成后承接下一个 K8s/SaaS 化的任务 (独立拆分出来)
背景:
JanusGraph(前身叫Titan 算是分布式图存储的第一代奠基), 社区以海外用户为主, 但是整体结构上其实殊途同归, 也同为 Java 语言开发, 和 HugeGrpah 的关系类似 "LevelDB" VS "RocksDB", 所以我们希望推动两个社区的更多的复用和合作, 首先就可以从 JG 的功能 --> HG 开始
任务描述:
- 根据已有资料和文档, 梳理最新版 JG 代码新增的功能特性 (比较重要的)
- 移植核心的 feature/bug-fix 等到 HG 中来
mentor: javeme/imbajin
Difficulty: middle (2.5星 ⭐)
Size: middle (3.5星 ⭐, 需要阅读两边的源码, 调试和适配)
Bonus: 3~12k (视合并项/完成数)
备注: 同时熟悉两个社区结构和设计的同学是最佳, 这部分也是基于已有代码进行适配和优化
补充 ing, 先列一下关键点
- 支持高频属性值的常量枚举编码
- 增加按需延迟反序列化类BackendProps包裹原始字节
- 序列化将各bytes替换为bytebuffer减少碎片
- 堆外内存优化gremlin dedup/emit等等step
- 邻接边的缓存结构更加精细化，比如以顶点Id为key，增加命中率
- 优化带目标点id条件的邻接边查询
- 优化根据顶点查边时，如果顶点类型无该类型边则直接返回空
mentor: zyxxoo/javeme
补充 ing
补充 ing
-
已有的代码 + 文档参考在哪? 什么时候可以参与/报名/开始任务, 可以提前开始参与提交代码么?
A: 参考代码也在 GitHub (原 HugeGraph Org 下), 初步重构 + 设置好权限后, 在 6.1 前后就会公开给可参与的同学, 然后不同于 OSPP 的任务有开始时间, 新增任务可以随时开始, 完成即可提前结束, 确认完成后即可结项领取对应的开源礼品 + 奖金等
-
新增的任务是否也需要等截止期才能确定是否选中? 可否提前联系 mentor, 待定的 task 联系谁?
A: 不是, 不同于 OSPP, 新增的任务可以被提前预订选择, 提交了 proposal 之后, 导师和同学都很认可, 则确定无误即可提前占坑(6.10之后), 已确定任务的 task 会更新为 "已预订", 方便同学及时了解状态
Documentation license here.