一、圖查詢語言介紹

首先來介紹一下圖查詢語言的發(fā)展歷程，大致可以分為三個(gè)階段：圖數(shù)據(jù)庫起步、圖查詢語言起步和圖查詢語言迭代。

第一個(gè)階段從 2000 年開始，當(dāng)時(shí)還沒有圖查詢語言。Neo4j 希望以 network 的形式，也就是圖的形式，去構(gòu)建數(shù)據(jù)。當(dāng)時(shí)圖數(shù)據(jù)庫的概念還不普遍，當(dāng)然圖的概念可以回溯到上世紀(jì) 70 年代甚至更早。在這一時(shí)期沒有查詢語言，因此是使用 Java API 去做，使用 2-3 個(gè)接口獲取點(diǎn)，然后基于一個(gè)點(diǎn)，獲取它一度的初邊，以這樣的形式描述一個(gè)圖查詢?，F(xiàn)在看來，無論是 TuGraph 還是 Neo4j，圖查詢的過程都是遵循最初做圖查詢的思路，就像 TuGraph 最初也是先有一個(gè) API 的層次，再在上層搭建查詢語言。

第二個(gè)階段是圖查詢語言的起步和發(fā)展階段。最早是 Gremlin，然后是 Neo4j 于 2011 年發(fā)布的第一個(gè)版本的 Cypher。2012 年 Cypher 成為聲明式語言，也就是大家現(xiàn)在習(xí)慣使用的通過起點(diǎn)和路徑描述查詢的方式。2015 年后圖查詢語言有了迅猛的發(fā)展，先是 Oracle 的 PGQL，之后 Neo4j 將 Cypher 開源為 openCypher。2017 年前后 TuGraph 開始加入進(jìn)來，也是以 openCypher 的標(biāo)準(zhǔn)做了查詢語言。2018 年 Cypher 形式化語義的論文發(fā)表 Cypher2018。大部分現(xiàn)已成熟的查詢語言、圖數(shù)據(jù)庫，都是在這十年間如雨后春筍般發(fā)展起來的。

第三階段就是我們現(xiàn)在正在經(jīng)歷的圖查詢語言迭代階段。2019 年開始，GQL 成為了國(guó)際標(biāo)準(zhǔn)，開始致力于統(tǒng)一不同圖查詢語言的標(biāo)準(zhǔn)。到了 2023 年，TuGraph 也開始逐步實(shí)現(xiàn) GQL。

上圖中羅列了各種查詢語言及其廠商。這些查詢語言可以分為兩大類：聲明式（Declarative）和命令式（Imperative）。

聲明式圖查詢語言，包括常見的 Cypher、PGQL、G-CORE，當(dāng)然 G-CORE 沒有具體的實(shí)現(xiàn)，但是它的設(shè)計(jì)是源自于 Cypher 的。這種聲明式的語言更加類似于 SQL，更強(qiáng)調(diào)查詢的目的，而不是查詢的過程，比較依賴于查詢優(yōu)化。

命令式的語言，比如 GSQL 和 Gremlin。嚴(yán)格意義上講，它們是混合式的，因?yàn)橐矔?huì)有 select from 嵌入在自己的語句里面。從形式上看，它們更像 Python 這樣的語言，因此它們會(huì)做的事情更多，這也就意味著用戶學(xué)習(xí)和使用成本會(huì)更高。其實(shí)與聲明式語言的區(qū)別在于，具體優(yōu)化過程是由人來做還是機(jī)器來做。比如如果對(duì)圖了解很多，能直接寫圖的存儲(chǔ)過程，那么使用 GSQL 就會(huì)更方便。命令式語言最大的特點(diǎn)就是能寫更復(fù)雜的圖計(jì)算能力，例如 page rank。當(dāng)然，用存儲(chǔ)過程去做，再嵌入聲明式的語言，也可以實(shí)現(xiàn)類似的能力。

再來講一下前面提到的國(guó)際標(biāo)準(zhǔn) GQL。GQL 在設(shè)計(jì)上參考了 openCypher、PGQL、GSQL 和 G-CORE，但其核心思想基本上都來自于 openCypher 語言，所以它是一個(gè)聲明式語言。螞蟻內(nèi)部，TuGraph 和 GeaFlow 兩個(gè)產(chǎn)品都有接入 GQL。長(zhǎng)期來看，GQL將會(huì)統(tǒng)一聲明式查詢語言。十年后，就像關(guān)系型數(shù)據(jù)庫只有 SQL 語言一樣，圖數(shù)據(jù)庫聲明式語言中也會(huì)只剩下 GQL 這一種語言。

現(xiàn)階段，GQL 還有很多問題，語義方面還沒有討論得非常明確，描述能力也比較有限。比如 FINBENCH，就是看查詢語言或者圖數(shù)據(jù)庫有哪些瓶頸。上圖中展示了 FINBENCH 里面的 complex-read1，金融場(chǎng)景里面查資金流向是比較常見的，比如從一個(gè)起點(diǎn)查一個(gè)賬戶，訪問出度1-3度的邊，就是一個(gè)不定跳的過程，如果是資金交易，會(huì)有時(shí)間要求，比如這筆轉(zhuǎn)賬流水是一個(gè)時(shí)間遞增的序列，現(xiàn)在的聲明式語言還不能很清晰地描述這種不定跳加時(shí)間遞增的情況。

考慮到 GQL 將會(huì)在圖數(shù)據(jù)庫領(lǐng)域?qū)崿F(xiàn)標(biāo)準(zhǔn)化，螞蟻現(xiàn)在對(duì) GQL 支持的力度是很大的，除了 TuGraph、GeaFlow 能支持 GQL，其它一些還沒有開源的產(chǎn)品基本上也以 GQL 為方向去做接入。

二、查詢引擎介紹

接下來介紹 TuGraph 4.0 圖查詢引擎。

其實(shí)在 4.0 版本發(fā)布之前，我們 GQL 的語法文件就已經(jīng)開源了，放在 TuGraph family 里面。4.0 版本實(shí)現(xiàn)了 GQL 的能力，當(dāng)然能力仍比較有限，目前支持 SNB 和 FINBENCH 所有的 SHORT 查詢。具體實(shí)現(xiàn)可能和開源的語法文件有一些變動(dòng)，這也是我們認(rèn)為 GQL 本身不成熟的地方，現(xiàn)在是兩個(gè)分叉，未來一兩年之后，這兩個(gè)分叉再合并。

近期我們有兩項(xiàng)重要的計(jì)劃，第一是完善 GQL 語法的支持范圍，目前僅支持 SNB 和 FINBENCH 的一些最基礎(chǔ)的東西，之后會(huì)盡快增加比如 DDL 等更多方面的支持。另一件事是架構(gòu)上的改造，引入一套全新的 GEAX 優(yōu)化引擎，其目的是希望做一套更通用、對(duì)開源社區(qū)更友好的優(yōu)化引擎。

其它方面的計(jì)劃包括，加入更加完善的 Test Suite 和相應(yīng)的工具，以及使用查詢語言去打榜 SNB 或者 FINBENCH。

提到 SNB 和 FINBENCH，基準(zhǔn)測(cè)試對(duì)于數(shù)據(jù)庫或者查詢引擎來說都是非常重要的，但并不是衡量一個(gè)查詢語言的唯一標(biāo)準(zhǔn)。查詢語言的評(píng)價(jià)維度包括性能、描述能力、健壯性和查詢優(yōu)化等等。

比如查詢優(yōu)化，最簡(jiǎn)單 Cypher 寫法 1 相較于寫法 2 更易優(yōu)化。如果要打一個(gè)很好的榜單，一定會(huì)用寫法 1 的形式，因?yàn)閷懛?2 不一定會(huì)優(yōu)化到，但最終用戶使用寫法1的體驗(yàn)和效果可能會(huì)很差。因此我們對(duì)于查詢語言的要求會(huì)比打榜更高一些。

TuGraph 的具體使用方法，可以參見以下鏈接：

三、架構(gòu)及演進(jìn)計(jì)劃

下面介紹一下現(xiàn)有的架構(gòu)，以及后期在架構(gòu)層面可能會(huì)做的改動(dòng)。

上圖是 TuGraph 現(xiàn)在最原始的架構(gòu)。查詢進(jìn)來，解析到 AST，然后可能有一些驗(yàn)證，到 Planner 出來一個(gè)執(zhí)行計(jì)劃，根據(jù)一些 Schema 信息或者一些統(tǒng)計(jì)信息進(jìn)行優(yōu)化，之后放入一個(gè)執(zhí)行引擎里面去執(zhí)行。

目前有兩個(gè)最大的問題，第一是要支持多個(gè)查詢語言 Cypher 和 GQL。萬幸的是，雖然 GQL 是一個(gè)全新的查詢語言，但其總體思想來自于 Cypher，體系上可以理解為一樣，因此我們可以做到對(duì)兩種語言的支持。

另一個(gè)問題是要支持更多的存儲(chǔ)引擎，目前 TuGraph 是一個(gè)簡(jiǎn)單的單機(jī)版本，螞蟻內(nèi)部已經(jīng)有分布式的圖數(shù)據(jù)庫和一些圖計(jì)算系統(tǒng)，需要將這些不同的存儲(chǔ)引擎都接到我們的查詢引擎之上。

關(guān)系型數(shù)據(jù)庫和圖數(shù)據(jù)庫的層次是比較接近的，因此我們參考了 Calcite 系統(tǒng)。Calcite 是一個(gè)完整的查詢處理系統(tǒng)，能夠提供 DBMS 所需要的許多常用功能，甚至可以接近一個(gè)圖數(shù)據(jù)庫系統(tǒng)，支持完整的查詢語言的優(yōu)化、解析、驗(yàn)證。我們參考它的架構(gòu)去做一個(gè)類似的處理系統(tǒng)，實(shí)現(xiàn)更豐富的算子，在圖的優(yōu)化上能做得更多。

參考這個(gè)架構(gòu)，我們會(huì)做 TuGraph 下一個(gè)版本的查詢引擎的改造，這個(gè)改造是在整個(gè)執(zhí)行引擎之上的一層改造。參見上圖，右邊是 Data Processing System，和 Calcite 的設(shè)計(jì)類似。左邊 GeaX 中有幾個(gè)核心的模塊，第一個(gè)就是圖語法表示（GST），Quary 解析完之后，這里加了一層抽象，這層抽象能夠保證同時(shí)支持兩個(gè)相似的語言，比如 Cypher 和 GQL。同時(shí)有一套獨(dú)立的邏輯算子，能夠描述整個(gè)查詢，有單獨(dú)的優(yōu)化器，這里的優(yōu)化器也支持可插拔的功能。這樣整個(gè)系統(tǒng)就分為了兩部分，前面的查詢語言的處理，以及后面的計(jì)算和存儲(chǔ)。

GeaX 為 TuGraph 提供處理和優(yōu)化圖查詢語言的能力，其特點(diǎn)包括，架構(gòu)與 Calcite 相似，支持查詢語言解析、校驗(yàn)、優(yōu)化。嚴(yán)格意義上 GeaX 不算是一個(gè)圖計(jì)算引擎，因?yàn)樗延?jì)算的部分全部剝離了，最終產(chǎn)出的是一個(gè)邏輯執(zhí)行計(jì)劃。另外，GeaX 支持多語言，支持不同的優(yōu)化器，這些優(yōu)化器是可插拔的，不同類型的優(yōu)化器有不同的規(guī)則。GeaX 的目標(biāo)不僅僅是作為一層查詢語言接在 TuGraph 上，還能夠?qū)崿F(xiàn)輕松地將 GQL 查詢語言接到任何一個(gè)圖相關(guān)的引擎上，比如一個(gè)人一個(gè)月就能夠?yàn)?GraphScope 提供 GQL 的能力，這樣也為 GQL 成為統(tǒng)一的圖聲明式查詢語言提供幫助。

通過上圖的對(duì)比可以看出，GeaX 和 Calcite 在框架設(shè)計(jì)上是比較接近的，當(dāng)然具體優(yōu)化器的能力會(huì)有不同，這也正是 GeaX 框架的優(yōu)勢(shì)之一，可以放不同的優(yōu)化器在這里。

這個(gè)架構(gòu)是我們未來 3-6 個(gè)月要去做的事情，現(xiàn)在已經(jīng)邁出了第一步，實(shí)現(xiàn)了 geax-front-end。目前 parser 這一層已經(jīng)實(shí)現(xiàn)。大概在 3-6 個(gè)月左右會(huì)有一版迭代，可能會(huì)有 GeaX 的出現(xiàn)。我們希望能做一個(gè)很簡(jiǎn)單的 play ground 給用戶用，用戶能在對(duì) TuGraph 沒有很多了解的情況下，嘗試去看 GQL 的查詢語言生成的邏輯執(zhí)行計(jì)劃是什么樣的，通過看邏輯執(zhí)行計(jì)劃，判斷這個(gè)查詢是不是復(fù)雜，是不是可以去增加一些優(yōu)化規(guī)則。