一、圖查詢語言介紹

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

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

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

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

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

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

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

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

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

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

二、查詢引擎介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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