![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/PR/ITPUB%20%E5%88%9B%E6%96%B0%E4%BA%A7%E5%93%81%E5%A5%96_%E7%94%BB%E6%9D%BF%201.jpg)

近日，由国内知名的 IT 技术社区 IT168 举办的 2022 年度技术卓越奖评选结果正式公布，**国产开源分布式图数据库 NebulaGraph 获得“ 创新产品奖”，再次说明了用户和媒体对其产品能力的充分肯定**。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/PR/20230111105837.jpg)

# 创新是国产数据库的生存之道

在今年 DTCC2022 中国数据库技术大会上，有专家强调创新是国产数据库的唯一出路。在近几年国产数据库突破的进程中，包括云原生、分布式、开源、融合等新的技术趋势层出不穷，只有将新技术与不断升级的用户需求创造性地融合，并在真实的使用场景中反复锤炼，才能创造出市场真正需要的优秀产品。

作为一款 100% 自主研发的开源分布式图数据库产品，NebulaGraph支持阿里云、亚马逊云（AWS）、微软云（Azure）等公有云平台及私有化、公私混合等多种灵活部署方式，发布以来被众安、腾讯、美团、京东、微众银行、小红书、快手等 1000 多家企业竞相采用，广泛应用于金融风控、实时推荐、知识图谱等业务场景。

除此之外，NebulaGraph 也在积极探索与产业链上下游生态伙伴的合作，致力于为各行各业提供更成熟优质、便捷易用的图数据库解决方案，过去几年中已在互联网、通信业、金融业、制造业等多个行业场景中成功落地。

# NebulaGraph 获得用户和媒体广泛认可

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/PR/IMG_1554.PNG)

▲  NebulaGraph 荣获 ITPUB 2022年度创新产品奖

**NebulaGraph v3.3.0 是一个可靠的分布式、线性扩容、性能高效的图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时的图数据库解决方案**。作为一款为实时决策打造的图数据库，NebulaGraph v3.3.0 拥有强大的原生图引擎来提供低延迟的读写和高吞吐量，确保高并发访问、快速的图遍历和有效的内存使用，其 Shared-Nothing 分布式架构和计算与存储分离的设计，可以按需在集群中增加更多节点或服务而不影响性能，满足不同业务场景计算存储容量的不同需求。

目前，NebulaGraph 已通过 ISO27001、ISO9001、CMMI3 认证、中国信通院图数据库基础能力专项评测及图计算平台基础能力专项评测，并完成了与多个国产操作系统、CPU的全面兼容适配，真正做到 100% 自主可控。 2022年，NebulaGraph 正式加入关联数据基准委员会（LDBC），参与制定图数据行业标准。

此次入选 ITPUB 年度创新产品奖是 NebulaGraph 继 2021年获奖后再次上榜。据悉， ITPUB 评选的奖项是由行业 CIO/CTO 大咖、技术专家及 IT 媒体三方联合考察并多方审核认定的，**本次获得 ITPUB 2022创新产品奖无疑再次印证了 NebulaGraph 是用户、媒体和行业专家认为的极具优势的图数据库产品**。

> 想了解更多图数据库可以帮助金融、互联网、制造行业用户解决实际问题？欢迎点击 [下载](https://www-test.nebula-graph.com.cn/download-white-book) 查看 NebulaGraph 最新应用案例集～

国产开源分布式图数据库 NebulaGraph 获得“ 创新产品奖”，再次说明了用户和媒体对其产品能力的充分肯定。

再获殊荣！图数据库 NebulaGraph 荣获 ITPUB 2022 创新产品奖

我们如何在表格源中对数据建模并将其 ETL 到 NebulaGraph？本文向我们展示了一个使用 dbt 的端到端示例。

利用 dbt，基于表结构的 Nebulagraph 图建模与 ETL

> 青藤云安全是一家主机安全独角兽公司，看名字就知道当前很大一块方向专注云原生应用安全，目前主营的是主机万相/容器蜂巢产品，行业领先，累计支持 800万 Agent。当前公司基于 NebulaGraph 结合图技术开发的下一代实时入侵检测系统已经初步投入市场，参与了 2022 护网行动，取得了不错的反响。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/%E5%85%A5%E4%BE%B5%E6%A3%80%E6%B5%8B%E7%B3%BB%E7%BB%9F1.jpg)


本文将简单介绍基于图的入侵检测系统，抛砖引玉，期望能有更多优秀人才参与挖掘图与安全的结合应用。

## 入侵检测的现状与挑战

### 主流入侵检测系统

入侵检测一直是安全研究的一大方向，青藤的万相和蜂巢两套产品分别为基于主机和容器的主机入侵检测产品，它们的原理都类似，如下图。

![入侵检测系统架构图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-01.png)

Agent 埋在主机/容器侧，接收服务端下发的规则结合采集的原始事件（进程/网络连接/文件读写等），通过安全专家编写规则，比如：进程文件 MD5/文件 MD5/执行命令行/机器学习等特征，命中当做告警报出来，相关告警上报到服务端；另外全量的原始事件也上报给服务端日志收集系统，入库保存到 SIEM 系统。

这套系统一旦告警上报到服务端，安全人员会拿当前告警相关信息到 SIEM 中查询告警发生时刻前后相关的事件，必要时登录相关机器查看相关信息，综合判断当前攻击告警是否有效并做相关处置。

这套系统是当前入侵检测的主流架构，但是也存在诸多问题：

1. 基于单事件+规则做单点检测，可能造成大量误报（规则太松）或漏报（规则太严）
2. 同一次攻击触发的告警可能过多，安全分析人员分析溯源工作量巨大
3. 同一次告警相关原始事件需要借助 SIEM 人工分析，缺乏可视化手段

### 图与安全研究方向

其实，可以看到这里的几个问题点本质上都是独立去看待每个告警和事件，实际上一次攻击相关的告警/事件应该是彼此关联的，这里很自然想到用图去把这些原始事件/告警关联起来整体分析。事实上，这也是当前安全研究的一个热门方向——溯源图，借助溯源图我们做如下多方面的安全分析和检测：

#### 1.图检测

传统安全解决的类似 IOC 检测，也就是单点判断，针对进程/网络连接/文件等实体判断是不是安全的；实际攻击面临的问题，可能各个点都检测不出来，但实际行为是危险的——1 个规则写不全，就算规则能写出来，比如命中某个命令行，但是触发告警很多，最终也无法应用。也就是要综合判断各种组合关系，这是图擅长的事情，也就是安全中图检测的问题——把所有相关的事件放在一张图中来综合判断分析是否为有效攻击。

**图检测研究很早，但是面临计算量和算法的双重挑战，目前行业应用很少，基本上组合判断都还是序列检测方式**。问题是序列规则能写多少确定规则，规则太多也有问题，无法应用；刚才提到确定规则，无法很好模糊匹配，也就是挖掘，安全中规则太确定就可以被绕过，黑客很聪明且借助自动化攻击更容易绕过这些规则。

#### 2.图关联和溯源

刚才提到告警，也就是当前所有安全产品面临的另一个问题——要不是规则命中不了，要不就是规则命中太多，我们叫**告警淹没**，安全运营处理能力有限，可能一天 100 个告警还好，如果一天甚至一小时 10000 条告警就没法处理了，那和没告警没差别。

这其实是一个安全中关联分类和溯源的问题：

1. 一次攻击会产生很多告警，比如：暴力破解登录，用了恶意文件，执行了恶意命令等等，关联分类把一次攻击中相关的告警关联在一起，这是图擅长的事情。这些告警关联在一起，还可以综合评判也就是多个告警联合判断当前攻击是否有效；
2. 每个告警只会告诉你当前你是进程、文件、网络有问题，那这个问题是如何发生的，黑客是怎么进来的，文件是从哪里下载的，先干了什么后干了什么。安全产品需要帮助客户完成这个分析过程，目前行业是借助 SIEM/THP/SOC 等安全产品，所有原始事件都上传保存，找安全专家，从告警开始查原始事件日志，看告警前发生了什么，哪些有关系可能导致攻击，这个过程短则几分钟，长甚至数个小时。**安全是个对抗过程，早就是优**——越早发现越早对抗，封禁或隔离，否则就算发现也为时过晚。可以把相关的原始事件实体（进程/网络等）入图，借助图可以可视化探索和溯源整个攻击过程，这就是图溯源的过程，学术叫因果图、溯源图。

#### 3.图知识图谱和预测

我们知道**当前安全从根本上讲还是基于规则或者说先验知识**，每种漏洞/木马/攻击工具/攻击过程/攻击组织都有它的特征，前几种规则还比较好描述，攻击过程、攻击组织等就很难完整描述了。

目前的主流做法是基于安全框架构建知识库，当前主流有 Kill Chain/ATT&CK 等框架，这是美国国防部主导的网络攻击战争相关两家公司提出的安全分析框架，相当于划分了攻击的战术和具体攻击技术的映射，这个具体如何实施比较难。安全学术界，比如：伊利诺伊大学/普渡大学近两年都在研究类似问题，也就是安全知识库（安全知识图谱）的构建。有了这个完善的知识库，就可以完成安全的终极设想，比如：我知道你的攻击过程/攻击组织，是不是就可以在攻击真正开始前，好比你打仗刚拿起枪冲到阵地上，判断你是要朝我开枪，预判直接击毙。

### 国内外现状

目前基于图的入侵检测系统，真正率先投入到实战中的是美国的安全明星公司——Crowd Strike，它完全基于图构建安全系统，现在相当于做了图检测和图关联溯源这两块的事情，目前估值 670 亿美元。云计算巨头 AWS 和 Azure 都在跟进它的方法。国内基于图做入侵检测系统的，目前有公开资料的是微步在线和深信服，他们相当于做了部分图关联和溯源的工作。

青藤云安全的万相和蜂巢在入侵检测深耕多年，已经取得了行业认可的安全检测能力，所以选择**从图关联和溯源入手，基于 NebulaGraph 结合图技术开发的下一代实时入侵检测系统，先重点解决告警淹没和关联溯源的痛点问题**。

## 青藤云安全下一代入侵检测系统

### 检测原理架构图

如下，核心是上报的攻击告警和部分原始事件统一在图中实时关联。

![检测原理架构图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-02.png)

### 产品效果

经过关联引擎关联处理输出的就是攻击事件，一个攻击事件可能关联多个攻击告警并可视化呈现出来，当前产品效果图如下：

同一次攻击利用恶意文件和木马

![同一次攻击利用恶意文件和木马](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-03.png)

敏感容器挂载

![敏感容器挂载](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-04.png)

自定义脚本检测

![自定义脚本检测](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/intrusion-detection-architecture-05.png)

### NebulaGraph 的优势

选择 NebulaGraph 主要基于如下考虑：

1. 图查询的刚需，特别是关联和溯源时多级进程关系查询，借助 Cypher查询图数据库能够比借助 SQL 在关系数据库中查询多级关系容易多；
2. 大规模存储，涉及到大量事件和告警的存储；
3. 高性能查询场景需求，关联需要保证近实时，当前相关查询都在 ms 级别；

得益于 NebulaGraph 的良好性能，关联引擎以近实时的方式入图和计算关联，入图部分是青藤自己基于 Flink 打造的实时入图组件，只需要更改配置文件即可完成图点边映射入图。

## 下一步研究方向和计划

当前青藤云安全新入侵检测主要支持单机和部分多机场景的关联和溯源，下一步重点是借助图支持更多多机关联的场景，特别是一些典型的安全攻击场景（反弹/横移），进一步以图赋能安全，为客户提供更好的服务。

当然，当前在将 NebulaGraph 应用到图安全应用过程中，也遇到了很多问题，提一些建议供参考。

### 1.下推优化

在开发过程中，极关心查询效率问题。我们在使用过程中，最大的问题就是下推优化，比如一颗发散的进程树，同时指定根节点和叶子节点，语句书写顺序不同就可能导致查询从叶子节点开始还是根节点开始，查询效率千差万别，最后不得不只指定叶子节点条件强制从叶子节点开始查。

MATCH 性能本质上也是下推优化问题，这个问题遇到也很多，目前我们的做法是对于部分已经查询过语句维持一个缓存池，也注意到官方企业版其实提供了部分缓存功能，这个点要是能考虑加到社区版就好了，是一个实际应用刚需。

### 2.实时场景一些技术需求点

因为我们是基于 NebulaGraph 做实时关联，一个较大的问题是如何实现一致性和速度的平衡——因为目前 NebulaGraph 实现的是最终一致性，写入图后其实是不知道到底是否真实入图完成。在实际应用中，关联引擎需要在下游轮询等待判断当前的点边是否真正的入图完成。这个对于实际使用和性能都会造成一定影响，是否有更好的方式值得思考。

另一块其实还是效率相关的问题，我们可以看到一些竞品 TigerGraph/TuGraph 都提供了自定义匹配/遍历算法和能力，比如：在我们多机关联场景中就遇到这种需求，目前只能通过拆分多条路径然后拼接起来的实现方式，效率和速度无疑是打折扣的。

### 3.TOB 部署

另一个，感受较深的是 NebulaGraph 对 TOB 部署的痛点。安全这个行业，目前国内还是走现场部署的较多，特别是国企和政务相关对上 SaaS 相对敏感，那么面临的问题就是效率和成本的问题——

**第一个是单机部署**，默认生产版本是为云设计的存算分离分布式部署方式，对于 TOB 部署还是太繁琐，且资源占用相对也较其他数据库多。

**第二个是 HDD 部署**，成本考虑，很多公司特别中小公司安全预算有限，很难提供 SSD 环境，更别说官网要求的大容量 SSD 高配置机器，也就是针对 HDD 和低配机器的优化上需要考虑更多。

以上，为青藤云安全团队工程师文洲带来的分享。

---

**谢谢你读完本文** (///▽///)

要来近距离体验一把图数据库吗？现在可以用用 NebulaGraph Cloud 来搭建自己的图数据系统哟，快来节省大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天免费使用中，[点击链接](http://c.nxw.so/8gMXe)来用用图数据库吧~

想看源码的小伙伴可以前往 GitHub 阅读、使用、(^з^)-☆ star 它 -> [GitHub](http://c.nxw.so/8yTlk)；和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能，留下[「你的名片」](http://c.nxw.so/9jvQN)一起玩耍呢~

本文将介绍青藤云安全基于 NebulaGraph 图技术开发的下一代实时入侵检测系统，该系统目前已经初步投入市场，参与了 2022 护网行动，取得了不错的反响。

基于图的下一代入侵检测系统

NebulaGraph Exchange 的性能如何？哪些参数调整下可以有更好的性能？本文带你了解 NebulaGraph Exchange 的最佳使用姿势。

从实测出发，掌握 NebulaGraph Exchange 性能最大化的秘密

LOOKUP 是图数据库 NebulaGraph 的一个查询语句。它依赖索引，可以查询点或者边的信息。本文将着重从源码的角度解析一下 LOOKUP 语句的一生是如何度过的。

读 NebulaGraph源码 ｜ 查询语句 LOOKUP 的一生

![NebulaGraph入选爱分析2022最佳实践案例](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/ifenxi01.png)

**在最近举办的“[2022爱分析·中国数据智能最佳实践案例](https://ifenxi.com/research/content/6219)”评选活动中， NebulaGraph 与普适智能联合打造的五矿期货一站式期货智能投资研究平台作为最佳实践案例成功入选**。该平台基于 NebulaGraph 性能高效的图技术底座能力，成功实现了深层次、复杂关联关系挖掘和可视化图谱分析，目前已在五矿期货产业链交易链路、投资事件分析、合规风控、客户画像分群、客户消费图谱等多个应用场景中落地。

作为在国内持续活跃的开源图数据库厂商， NebulaGraph 不仅拥有国内最大的 GitHub 开源图数据库技术社区， 而且在 DB-Engines 国内图数据库领域长期排名第一。目前，**开源分布式图数据库 NebulaGraph 已在全球拥有超过 1000 家企业用户，涉及金融、制造业、互联网、政府等多个行业**。

![NebulaGraph入选爱分析2022最佳实践案例](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/images/blogs/ifenxi02.png)

随着数字化进程的不断推进，数据已逐渐成为企业乃至国家数字经济发展的重要生产要素。面对日益激增的大规模数据和纷繁复杂的业务场景，如何借助数据智能融合大规模数据处理、数据分析与挖掘、机器学习、可视化等多种大数据和人工智能技术来解决实际的应用问题，正成为许多企业未来战略布局的抢先点。

在这一过程中，以 NebulaGraph 为代表的高性能、分布式图数据库产品正逐渐受到更多关注——越来越多的企业实践证明，通过对大数据实现的有效管理和分析不仅能够帮助企业打通数据链路，低成本高效率地规避潜在的业务风险，**更能在海量数据中发掘关联关系，让传统业务突破瓶颈，找出新的业务增长点，真正实现数据赋能和开源增效**。

了解案例详情，[《五矿期货-张剑锋：图数据库在金融期货行业的应用与实践探索》](https://www.nebula-graph.com.cn/posts/wukuang-graph-database-practice)











在最近举办的“2022爱分析·中国数据智能最佳实践案例”评选活动中， NebulaGraph 与普适智能联合打造的五矿期货一站式期货智能投资研究平台作为最佳实践案例成功入选。

NebulaGraph 入选 2022 爱分析《中国数据智能最佳实践案例》

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/open-source-summer-visual-screen.png)

## 初识开源之夏

### 结缘 NebulaGraph

Hello，⼤家好，我叫刘⽂豪。⽬前是⼀名计算机专业的研⼆研究⽣，就读于北京邮电⼤学。我很⾼兴能参与到这次的开源之夏项⽬中，加⼊到了 NebulaGraph 的社区建设中，并成功完成了可视化⼤屏项⽬的实现。

说起与开源之夏结缘，需要归功于我的好朋友男哥，他是我实验室的同⻔，在研⼀的时候给予了我很多帮助。他是⼀名技术控，对数据库、云原⽣、传统前后端开发等各个领域都有涉猎，在本次开源之夏的活动中参与了 KubeVela 社区的项⽬，取得了丰硕的成果。在今年上半年北京疫情冲击下，我们北邮经历了⼀段封校的⽇⼦，在百⽆聊赖之际，男哥向我们推荐了本次开源之夏的活动，成为了我开源之夏的引路⼈。

在选取开源之夏的项⽬时，我根据⾃身特点进⾏考虑——我研⼀时接⼿了实验室⼀个国家级项⽬的前端部分。在开发迭代过程中，与负责后端的男哥有许多交流。我当时认为⾃⼰对前端⽅向的⼯程化实现更感兴趣⼀些，也⾃学了很多前端领域的知识。但前端⽅向的特点是杂乱，加上国内前端⽣态建设良莠不⻬，很容易让⼈摸不清努⼒的⽅向。如果能找到⾏业内从业多年的⾼⼿亲⾃指导，将事半功倍。抱着试⼀试的态度，我主动联系了我的导师汪洋，浏览运⾏了 NebulaGraph Dashboard 的项⽬，甚⾄还发现了⼀个⼩ bug，提了⾃⼰在 GitHub 上的第⼀个 PR。

### 介绍下这是我的导师

汪哥给我的初印象是⽐较平易近⼈，⽽且反馈很快，不是那种⾼⾼在上的导师，能够亲⾃指导⼀些技术上 Google 不到的具体问题。在仔细考量对⽐之后（导师汪洋通过了考核🎉），我选择了 NebulaGraph 社区的可视化⼤屏实现的项⽬。

很多同学可能会认为，追求名字看上去“⾼⼤上”的项⽬才是正确的。⽽我认为，**⽆论是怎样的项⽬，能落地才是最重要的**。

我认为⼀个项⽬能否成功落地主要取决于两点：

1. 项⽬本身是否具有可⾏性；
2. 参与项⽬的⼈是否靠谱。

这两点也在最终敲定项⽬⼈选的⾯试时，双⽅达成了⼀致。

## “辛”而不酸的项目史

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/nebulagraph-dashboard-visual-screen.jpeg)

### 这可是可视化大屏

可视化大屏项⽬旨在帮助运维⼈员更直观、便捷地感知系统内的各项关键指标，设计出 NebulaGraph Dashboard 的 Community 版可视化⼤屏。

整个项⽬流程涉及**需求分析**、**原型设计**、**代码实现**、**合⼊仓库**等完整的软件开发流程，深⼊体验了企业内部产品的上线、开发流程。

在整个开发流程中，代码实施只是其中的⼀部分。导师汪洋考虑到⼯作量较⼤，尤其是起步的需求分析和原型设计部分，期望更多的开源⼒量加⼊本次项⽬开发中。这不是巧了，来⾃美国的宇晴⼩姐姐对这个可视化项目也很感兴趣，经过协商沟通，宇晴⼩姐姐也参与到了我们的项⽬开发中，我们组成了三⼈的开发⼩团队。

在起步阶段，我们做了详细的调研，仔细阅读导师汪洋提供的材料，敲定了设计蓝图、开发语⾔、框架、环境。我们选择重新设计仪表盘的整体布局，在打包⼯具的选择上，我们⽤ Vite 搭建了新的开发环境，没有使⽤旧的 WebPack 开发环境，提⾼了开发效率。

在具体的代码实施阶段，因为我跟宇晴的跨时区因素，**体验了⼀下近年很⽕的跨国团队的远程协作⽅式**——⼤家在项⽬沟通群中提出问题，明确各⾃的分⼯，采⽤“接⼒式”的开发模式，分别在各⾃时区的⼯作时间，在 NebulaGraph 社区提供的开发机上进⾏代码编写。我们也经常会在群⾥提前商量时间，来进⾏⼩组组会，确保项⽬的顺利推进。⼩组组会的形式和内容，也随着项⽬开发阶段的深⼊，不断地在做调整适应，做到了灵活性和有效性的统⼀。

## 开源之旅不停

虽然可视化大屏是一个开源之夏的项目，项目总有结项之日。但是，开源之旅不停，后续我将会从以下方面继续走我的开源之路：

* 优化 UI 设计、提升代码质量
* 更多参与开源社区的建设中

### 在开源之夏感受开源的魅力

本次活动，我亲身体会了 NebulaGraph 社区友好的开源氛围。

而我认为**开源社区的魅⼒在于，它不仅只为代码⾼⼿开放，还欢迎刚⼊⻔的⼩⽩**。我在参与到 NebulaGraph 的社区前，并没有从零开始完整地搭建过⼀个⼤型的前端项⽬，缺乏对所学前端知识的整合。

⽽宇晴⼩姐姐是转码选⼿，今年还⾯临着严峻的应聘形势。我们在整个项⽬开发过程中，互帮互助，相互⿎励，不仅攻克了⼀个个具体的问题，更收获了信⼼和彼此之间的友谊。这⼀切的根源在于，我们勇敢地迈出了最重要的第⼀步，选择主动参与到开源之夏的活动中，并且幸运地加⼊到了 NebulaGraph 社区。在 NebulaGraph 社区，⽆论是负责技术的汪哥，还是负责运营的迷⼈的⼩姐姐，都向我们展示出了他们积极、宽容、耐⼼的友好开源氛围，帮助我们顺利完成了第⼀步的开源之路。


### 在开源中提升自我

很明显的是**能⼒提升**，在整个项⽬的开发过程中，我们各⽅⾯能⼒都有所提升，具体体现在以下两点：

#### 技术和⽂档能⼒

我的调研技术⽅案、学习技术细节、应⽤技术解决具体问题的效率得到了显著提⾼。在实践中，⼀步步利⽤所学的零碎的技术知识，孕育出了完整的产品呈现。

开源之夏的官⽅组需要提供结项报告等书⾯材料，**我们没有敷衍了事，⽽是选择了使⽤全英⽂的书写模式**，认真地完成了组委会的要求。我认为**⽆论是为了社区层⾯的与国际开源社区接轨的需要，还是为了个⼈层⾯的⻓期职业发展的考量，选择主动提升英⽂技术⽂档的能⼒，都是必要且正确的**。

纵观前端发展的历史，⽆论是之前的 Flash、JQuery，还是如今的 Vue、React，都只是各个时期流⾏的代表技术⽅案。⽆论它们的设计多么精巧，代码多么规范，终有⼀天会被淘汰。掌握了对它们的使⽤，仅仅是达到了熟练运⽤“术”的⼯具层⾯。近年，前端各领域发展迅速，各种技术⽅案层出不穷，经常会有⼈调侃“学不动了” 。我也在刚⼊⻔的初期，陷⼊了努⼒⽅向的误区，以尝试各种新鲜的技术⽅案作为主要兴趣驱动点。随着项⽬的深⼊进⾏，我逐渐摸清了作为“道”的能⼒层⾯。我知道了作为职业⽣涯初期的菜⻦选⼿，应该着重养成良好的职业态度和职业习惯，⽽不是⼀味沉迷于粗浅地了解各种技术实现⽅案。加上⼤环境⻛云突变，对应届⽣就业趋势越发地不友好。如果只是将⾃⼰培养成专注“术”的技术熟练⼯，⽽不是关注“道”的技术爱好者，也将丧失⾃⼰作为应届⽣的优势。

#### 沟通和协作能⼒

在项⽬开发的过程中，如何进⾏有效的沟通和协作成为了⼀个很重要的议题，尤其是在社会分⼯⽇益精细化的今⽇。我们三⼈⼩团队均是拿出⾃⼰的业余时间来参与到项⽬中，关于沟通协作⽅式、各⾃时间安排上，都进⾏了多次的讨论和改进。开源对多数人来说是⼀项业余爱好的任务，很少有⼈能够全职从事其中。⽽能有机会在职业⽣涯未正式开始之前，就参与到有公司导师牵头的开源项⽬中，也算是⼀⼤幸事，希望能为⾃⼰未来的团队协作能⼒奠定⼀个良好的基础。

### 开源之外的友谊

感谢开源之夏官⽅提供这次机会，让我有机会接触到 NebulaGraph 社区，认识了运营⼩姐姐、汪哥和宇晴。我认为任何东⻄想要做成，关键在于“⼈”的部分。有优秀的⼈才，就会有良好的氛围，就能孕育出有意思的产品。我跟汪哥、宇晴的三⼈⼩群，也逐渐成为了⽆话不谈的地⽅。虽然我们三⼈背景、身份各异，但产⽣了⾮常良好的化学反应。希望在以后的⽇⼦⾥，⼤家能够铭记这段有意思的经历，砥砺前⾏，奋发向上。

在这个不确定性⼤⼤增加的时代⾥，努⼒制造⼀些确定的⼩温馨。希望⼤家之后继续为 Nebula 和其他开源社区添砖加瓦，贡献⾃⼰的⼒量，共同缔造⼀种良好的氛围，照亮⼀束光，指引前进的⽅向。

本文来自于开源之夏参与者的投稿，一起来看看来自北京邮电大学-计算机专业的研二学生刘⽂豪在这次项目中的收获与感受吧。

「开源之夏」分享：在可视化大屏中摸清技术方向

本文分享如何用开源、现代的 DataOps、ETL、Dashboard、元数据、数据血缘管理系统构建大数据治理基础设施。

如何轻松做数据治理？开源技术栈告诉你答案

本文将分享图算法在风控中的应用，包括图算法和风控简介、图算法在风控的演化、相应平台的使用心得以及未来展望。

图算法、图数据库在风控场景的应用

本文整理自 Sensoro升哲-产品副总裁-付刘伟 在 NebulaGraph 2022 年度用户大会上的分享。	

Sensoro升哲：图分析在城市治理服务的应用与落地

五矿期货是世界 500 强企业中国五矿集团旗下的金融企业，作为首家使用 NebulaGraph 图数据库的期货公司分享了知识图谱平台在期货投资领域的应用和未来实践方向的探索及心得。

五矿期货：图数据库在金融期货行业的应用与实践探索

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/ngql-cheatsheet-cn-01.jpg)

本文旨在让新手快速了解 nGQL，掌握方向，之后可以脚踩在地上借助文档写出任何心中的 NebulaGraph 图查询。

## 视频

本教程的视频版在[B站这里](https://bilibili.com/video/BV1PT411P7w8)。

## 准备工作

在正式开始 nGQL 实操之前，记得先**看过文档「快速入门流程」，部署、连接过 NebulaGraph，并且看过了「常用命令」**。如果你还没看过这两个文档，为了跟上进度，记得先快速过一遍，上面两个文档链接可在文末「参考资料」中获取。

### 我们的目标是

本教程目的在于让大家大概知道了 NebulaGraph 的查询语句后，解决“不知道什么样的查询应该用什么语句”的问题。

### nGQL 是什么

我们先强调一下概念：nGQL 是 NebulaGraph Query Language 的缩写，它表示 NebulaGraph 的查询语言，可以不严谨地分为这 5 部分：

- NebulaGraph 独有 DQL（Data Query Language）查询语句
- NebulaGraph openCypher DQL
- NebulaGraph DML（Data Mutation Language）写语句
- NebulaGraph DDL（Data Definition Language) Schema 语句
- NebulaGraph Admin Queries 管理语句

这里，作为简明教程一把梭，我们只关注前两个部分，后边的内容会在 Part 2 中介绍。

### nGQL 速查表 cheatsheet

大家可以保存下这份单页速查表，一次了解所有 nGQL 的用法。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/ngql-cheatsheet-cn.webp)

## NebulaGraph 独有 DQL

NebulaGraph 的独有读查询语句的设计非常简洁，对初学者非常友好。它结合了管道的概念，做到了只涉及了几个关键词就可以描述出大多数的图查询模式。**由于篇幅的问题，所有 DQL 查询语句的更多用法记得查阅本文的「参考资料」**。

简单来说，nGQL 的独有 DQL 一共分成四类语句：

- 图拓展 / 遍历：`GO`
- 索引反查：`LOOKUP`
- 取属性：`FETCH`
- 路径与子图：`FIND PATH` 与 `GET SUBGRAPH`

和两个特别的元素：

- 管道：`|`
- 引用属性: `$` 开头的几个符号，用来描述一些特定的上下文

### 用 GO 来图拓展 / 遍历

`GO` 的语义非常直观：从**给定的起点**，向外拓展，按需**返回终点**、起点的信息。

```sql
# 图拓展
GO 3 STEPS FROM "player102" OVER follow YIELD dst(edge);
   ───┬───      ───┬───────      ─┬────       ──┬────── 
      │            │              │   ┌─────────┘       
      │            │              │   │                 
      │            │              │   └── 返回最后一跳边的终点
      │            │              │                     
      │            │              └────── 从 follow 这个边[出方向]探索
      │            │                                    
      │            └───────────────────── 起点是 "player102"
      │                                                 
      └────────────────────────────────── 探索 3 步
```

这里只是做了一个简单的 `GO` 语法示例，像 GO 实现的反向、双向拓展，指定可变跳数遍历等，更多 GO 语句用法可查阅参考资料。

### LOOKUP 基于索引反查 ID

和 `GO` 的从已知的点出发相反，`LOOKUP` 是一个类似于 SQL 里 `SELECT` 语义的关键字，它**实际的作用也类似与关系型数据库中的扫表**。

`LOOKUP` **需要手动创建相应 TAG、边类型上索引才能进行相关查询**。

#### 为什么 `LOOKUP` 需要索引？

因为 NebulaGraph 中的数据默认是按照邻接表的形式存储，在分布式设计中，扫描一个类型的点、边是非常昂贵的，所以它被默认禁止了。NebulaGraph 索引的存在增加了类似于表结构数据库的排序数据，可以用来做像是 `SELECT` 的查询。

```sql
# 索引反查
LOOKUP ON player WHERE player.name == "Tony Parker" YIELD id(vertex);
          ──┬───  ──────┬──────────────────────────  ──┬──────       
            │           │          ┌───────────────────┘             
            │           │          │                                 
            │           │          └──────────── 返回查到点的 VID
            │           │                                            
            │           └─────────────────────── 过滤条件是属性 name 的值
            │                                                        
            └─────────────────────────────────── 根据点的类别/TAG player 查询
```

本文仅作 LOOKUP 语法的使用入门，关于索引原理和使用，比如：创建索引会有什么代价？索引会加速读么？记得查看文末的参考资料。

### FETCH PROP 获取属性

如字面意思，如果我们知道一个点、边的 ID，想要获取它上边的属性，这时候我们要用 `FETCH PROP` 而非 `LOOKUP`。

```sql
# 取属性
FETCH PROP ON player "player100" YIELD properties(vertex);
              ──┬───  ────┬─────       ─────────┬──────── 
                │         │         ┌───────────┘         
                │         │         │                     
                │         │         └─────── 返回点的 player TAG 下所有属性
                │         │                               
                │         └───────────────── 从 "player100" 这个点获取
                │                                         
                └─────────────────────────── 获取 player 这个 TAG 下的属性
```

### 路径查找 FIND PATH

如果我们要找到指定两点之间的所有路径，一定要用 `FIND PATH`。

```sql
# 起点终点间路径
FIND SHORTEST PATH FROM "player102" TO "team204" OVER * \   
     ──┬─────            ───────────┬─────────── ───┬───    
  YIELD│path AS p; ┌────────────────┘               │       
       │────┬────  │     ┌──────────────────────────┘       
       │    │      │     │                                  
       │    │      │     └───────── 经由所有类型的边出向探索
       │    │      │                                        
       │    │      └─────────────── 从给定的起点、终点 VID
       │    │                                               
       │    └────────────────────── 返回路径为 p 列
       │                                                    
       └─────────────────────────── 查找最短路径
```

### 单点子图 GET SUBGRAPH

和路径查找类似，如果我们只给定一个起点和拓展步数，用 `GET SUBGRAPH` 可以帮我们获取同样的 BFS 出去的子图。

```sql
# 单点 BFS 子图

GET SUBGRAPH 5 STEPS FROM "player101" \           
             ───┬─── ─────┬──────────             
  YIELD VERTICES AS nodes, EDGES AS relationships;
        ────┬───┼─────────┼───────────────────────
   ┌────────┘   │         │                       
   │            │         └─────── 从 "player101" 开始触发
   │            │                                 
   │            └───────────────── 获取 5 步的探索
   │                                              
   └────────────────────────────── 返回所有的点、边
```

### 利用管道和属性引用符

NebulaGraph 的管道设计和 Unix-Shell 的设计很像，可以将简单的几种语句结合起来，有强大的表达力。

```sql
# 使用通道
GO FROM "player100" OVER follow YIELD dst(edge) AS did  | \  
    ─────┬──────────────────────────────────────────── ─┬─   
  GO FROM│$-.did OVER follow YIELD dst(edge);           │    
         │────┬──     ┌─────────────────────────────────┘    
         │    │       │                                      
         │    │       └──────── 管道将左边的 AS 输出作为右边语句输入
         │    │                                              
         │    └──────────────── 从管道左边的 did 属性开始探索
         │
         └───────────────────── 第一个查询语句
```

除了以上的集中表达之外，NebulaGraph 独有查询语句还有聚合的表达参考 `GROUP-BY`，另外在文档里还有一个 `Cheatsheet`供大家查询一些复杂的例子。

## NebulaGraph openCypher DQL

从 NebulaGraph v2.0 起，openCypher 的 `MATCH` 语句也被 NebulaGraph 原生支持了。虽然 NebulaGraph 这里是一个“方言”，有一些使用细节差异。

```
MATCH <pattern> [<clause_1>] RETURN <output>  [<clause_2>];
```

MATCH 的基本表达是由 `(v:tag_a)` 包裹的点和 `-->` 或者 `<-[:edge_type_1]-` 表达的边组成的模式，再与 `RETURN` 结合表达输出。

如果你从 Cypher 的查询语言入门图数据库，可以从下边几个例子了解到若干 NebulaGraph 里的使用细节差异：

- 增加了 `WHERE id(v) == "foo"` 的表达；
- `==` 表达相等判断而不是 `=`；
- 点的属性表达需要填写 TAG，例如 `v3.player.name` 而不是 `v3.name`；

```
MATCH (v:`player`{name:"Tim Duncan"})-->(v2)<--(v3) \
    RETURN v3.`player`.name AS Name;

MATCH (v:`player`) \
    WHERE NOT (v)--() \
    RETURN v;

MATCH (v:`player`)--(v2) \
    WHERE id(v2) IN ["player101", "player102"] \
    RETURN v;

MATCH (m)-[]->(n) WHERE id(m)=="player100" \
OPTIONAL MATCH (n)-[]->(l) WHERE id(n)=="player125" \
    RETURN id(m), id(n), id(l);
```

以上，为本次简明教程的第一集。

## 参考资料

* 快速入门 NebulaGraph：[https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/1.quick-start-workflow/](https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/1.quick-start-workflow/)
* nGQL 常见命令：[https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/4.nebula-graph-crud/](https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/4.nebula-graph-crud/)
* GO 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/3.go/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/3.go/)
* 全方位讲解 NebulaGraph 索引原理和使用：[https://discuss.nebula-graph.com.cn/t/topic/8074](https://discuss.nebula-graph.com.cn/t/topic/8074)
* LOOKUP 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/5.lookup/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/5.lookup/)
* FETCH PROP 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/4.fetch/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/4.fetch/)
* GET SUBGRAPH 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/16.subgraph-and-path/1.get-subgraph/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/16.subgraph-and-path/1.get-subgraph/)
* 管道 ｜ 文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/4.pipe/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/4.pipe/)
* 引用符 $ 文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/5.property-reference/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/5.operators/5.property-reference/)
* GROUP-BY：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/8.clauses-and-options/group-by/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/8.clauses-and-options/group-by/)
* nGQL Cheatsheet：[https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/6.cheatsheet-for-ngql-command/](https://docs.nebula-graph.com.cn/3.2.0/2.quick-start/6.cheatsheet-for-ngql-command/)
* MATCH 语句文档：[https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/2.match/](https://docs.nebula-graph.com.cn/3.2.0/3.ngql-guide/7.general-query-statements/2.match/)

本文旨在让新手快速了解 nGQL，掌握方向，之后可以脚踩在地上借助文档写出任何心中的 NebulaGraph 图查询。

标签