产品实践
一首古诗带来的图数据库大冒险
因为图数据库的增长趋势一直位列前茅,每年都有媒体预测今年是“图年”。作为曾经的图数据库从业者,Nebula Hackthon 2021 的参赛队伍临江仙的队长王二铁(王建奎),一直在思考,为什么长期火爆的图数据库市场,一直没有真正引爆。在 2018 年图数据库输给了区块链,2019 年又遇到了 5G,随后疫情开始了。在王二铁看来图数据库目前主要还是面向 toB、toG 的市场,在 toC 领域,几乎没有图数据库相关的案例,这也是为什么图技术难以被大众所熟知的原因。
于是,一个新意的 idea 冒出了,这将是一个非常好,而且还算好玩的 C 端案例。它是什么呢?便是本次介绍的「一首古诗带来的图数据库大冒险」。
念起
有次二铁陪同小朋友上画画班,空闲之余刷到了苏轼的《临江仙 风水洞作》:
四大从来都遍满,此间风水何疑。故应为我发新诗。幽花香涧谷,寒藻舞沦漪。
借与玉川生两腋,天仙未必相思。还凭流水送人归。层巅余落日,草露已沾衣。
因为读不懂这首诗词,体会不到其中的意境美。作为老二次元的王二铁借由动漫迷中的「圣地巡礼」,想到用诗词巡礼的方式--回到古诗词的创作地,亲身体验诗词的意境和美景。结合图数据库,把中国古诗词放到图谱里,通过【作者搜索】关联出他所有的诗词,并关联出所有的创作地点,这就形成了一条【诗词巡礼】的旅游路线;通过【地点搜索】关联出当地所有的古诗词创作地,这就形成了一个充满文化气息的诗词城市。
基于路线、地理位置也可以衍生出更多的玩法。例如一个作者的城市足迹图,也许就是他的升迁史;同一个地点,如果有多个作者留有诗篇,那可以互相印证和学习。结合图,还有更多的玩法可以继续挖掘。
而除了「圣地巡礼」这一主功能之外,二铁还加了另外一个功能--本命诗。idea 也是来源于一首诗词,王之涣的《凉州词》:
黄河远上白云间,一片孤城万仞山。
羌笛何须怨杨柳,春风不度玉门关。
一首包含他家小朋友名字的古诗,突然让小朋友有了学习该诗的兴趣,于是他决定加入本命诗,古诗和人亲近、建立熟悉感之后,成为他记忆的一部分。
圆梦
古诗大冒险项目实现思路主要是将中国古诗词放到图谱里,诗词的图谱需要包含作者(姓名、朝代、字、号)、诗词(诗词名、内容、创作地址、经度、维度)、城市,其他再包含古代城市和现代城市的映射、古人朋友圈等等,形成一张完整的图谱。 数据源,需要涉及到诗词库、百度汉语、旅游网站、坐标提取系统等等;经过数据加工、数据聚合以及图数据库的建模,将数据导入图数据库中,一个简单的诗词图谱就形成了。然后通过 Java Web提供接口服务,通过小程序提供用户服务。整体流程就通了。
整体实现主要分成 3 步:
- 数据处理,数据处理是整个项目最难的点。这部分需要首先明确产品层面的需求,根据需求进行图数据库建模,再根据建模结果反推需要哪些数据支撑,然后寻找数据源,并进行数据采集和 ETL 处理。最终形成图数据库中需要的几个文件,例如:vertex-诗词.csv、vertex-作者.csv、vertex-城市.csv、edge-诗词-作者.csv、edge-诗词-城市.csv。
- 系统开发,系统开发是把第一步建设的图谱,实际的在图数据库中创建并导入数据的过程。因 Nebula 完备的产品功能和周边工具,使得这一步的开发比较简单。项目中使用到了 NebulaGraph 图数据库进行数据存储,NebulaGraph Studio 进行图数据库建模和语法调试、NebulaGraph Importer 进行数据导入,NebulaGraph Java Client 进行 API 服务的开发。
- 小程序开发,系统开发之后会形成几个 API,小程序侧调用 API 端口,然后进行前端的可视化展示。其中需要地图的 SDK,结合收集到的坐标,就可以在地图上展示出诗词的创作地点。
这个项目看似很简单,但暗藏玄机。整个项目实现起来会遇到 2 个难点。其中一个还是数据,因为系统本身并不复杂,代码量并不多,核心还是对数据的理解,以及一个好的产品 sence。当然也遇到一个天坑问题,就是一些好的古诗词找不到创作地点或者历史上存在争议,比如陈子昂的《登幽州台歌》。第二个难点算技术上的广度,就是从一个 idea,到产品化实现,要熟悉一整条技术路线。其实也并没有多深的技术,但是需要一种不甘于只做螺丝钉的独立开发思维。
他说
一首古诗带来的图数据库大冒险的有意思的点除了它的 idea 之外,和技术实现之外。更多的产品细节也是让人眼前一亮,像是地理位置的处理方式。
拿临江仙·风水洞作为例,故事标志性坐标便是风水洞,如何定位这个风水洞呢?各地都有「风水洞」,根据苏轼的过往经历,最后匹配定位到了杭州锦绣风水洞。通过抽取风水洞的地理坐标,将这首古诗还原到了该诗圣地。而这块的实现也经历了一番小波折,大家都知道 NebulaGraph v2.6 开始支持的 GEO 功能,一开始二铁他们考虑要不要用 GEO,而不是存经纬度。但转念一想,项目本身并不需要用到强大的 NebulaGraph GEO 功能,加上项目赶时间(比赛设有代码截止提交时间),故没尝试新的 GEO 功能。
说到后续的项目规划,王二铁表示,“图数据库中更核心的最短路径、三角计数、社区发现等算法并没有用到,大家可以发挥想想来给我们提想法,当然更欢迎自己来实际体验和实现”。
续缘
戳链接可查看其项目设计文稿:https://github.com/Jerrick/a-tour-of-poetry/blob/main/README.md。BTW,二铁曾作客 NebulaGraph Podcast 分享他本次实践的心路历程,阅读本文的你可以戳链接听该期 Podcast 哦:http://xima.tv/1_etO1vh?_sonic=0
交流图数据库技术?加入 Nebula 交流群请先填写下你的 Nebula 名片,Nebula 小助手会拉你进群~~