螞蟻 TuGraph-DB 數據庫查詢引擎技術
一、圖查詢語言介紹
首先來介紹一下圖查詢語言的發展歷程，大致可以分為三個階段：圖數據庫起步、圖查詢語言起步和圖查詢語言迭代。
第一個階段從 2000 年開始，當時還沒有圖查詢語言。Neo4j 希望以 network 的形式，也就是圖的形式，去構建數據。當時圖數據庫的概念還不普遍，當然圖的概念可以回溯到上世紀 70 年代甚至更早。在這一時期沒有查詢語言，因此是使用 Java API 去做，使用 2-3 個接口獲取點，然后基于一個點，獲取它一度的初邊，以這樣的形式描述一個圖查詢。現在看來，無論是 TuGraph 還是 Neo4j，圖查詢的過程都是遵循最初做圖查詢的思路，就像 TuGraph 最初也是先有一個 API 的層次，再在上層搭建查詢語言。
第二個階段是圖查詢語言的起步和發展階段。最早是 Gremlin，然后是 Neo4j 于 2011 年發布的第一個版本的 Cypher。2012 年 Cypher 成為聲明式語言，也就是大家現在習慣使用的通過起點和路徑描述查詢的方式。2015 年后圖查詢語言有了迅猛的發展，先是 Oracle 的 PGQL，之后 Neo4j 將 Cypher 開源為 openCypher。2017 年前后 TuGraph 開始加入進來，也是以 openCypher 的標準做了查詢語言。2018 年 Cypher 形式化語義的論文發表 Cypher2018。大部分現已成熟的查詢語言、圖數據庫，都是在這十年間如雨后春筍般發展起來的。
第三階段就是我們現在正在經歷的圖查詢語言迭代階段。2019 年開始，GQL 成為了國際標準，開始致力于統一不同圖查詢語言的標準。到了 2023 年，TuGraph 也開始逐步實現 GQL。
上圖中羅列了各種查詢語言及其廠商。這些查詢語言可以分為兩大類：聲明式（Declarative）和命令式（Imperative）。
聲明式圖查詢語言，包括常見的 Cypher、PGQL、G-CORE，當然 G-CORE 沒有具體的實現，但是它的設計是源自于 Cypher 的。這種聲明式的語言更加類似于 SQL，更強調查詢的目的，而不是查詢的過程，比較依賴于查詢優化。
命令式的語言，比如 GSQL 和 Gremlin。嚴格意義上講，它們是混合式的，因為也會有 select from 嵌入在自己的語句里面。從形式上看，它們更像 Python 這樣的語言，因此它們會做的事情更多，這也就意味著用戶學習和使用成本會更高。其實與聲明式語言的區別在于，具體優化過程是由人來做還是機器來做。比如如果對圖了解很多，能直接寫圖的存儲過程，那么使用 GSQL 就會更方便。命令式語言最大的特點就是能寫更復雜的圖計算能力，例如 page rank。當然，用存儲過程去做，再嵌入聲明式的語言，也可以實現類似的能力。
再來講一下前面提到的國際標準 GQL。GQL 在設計上參考了 openCypher、PGQL、GSQL 和 G-CORE，但其核心思想基本上都來自于 openCypher 語言，所以它是一個聲明式語言。螞蟻內部，TuGraph 和 GeaFlow 兩個產品都有接入 GQL。長期來看，GQL將會統一聲明式查詢語言。十年后，就像關系型數據庫只有 SQL 語言一樣，圖數據庫聲明式語言中也會只剩下 GQL 這一種語言。
現階段，GQL 還有很多問題，語義方面還沒有討論得非常明確，描述能力也比較有限。比如 FINBENCH，就是看查詢語言或者圖數據庫有哪些瓶頸。上圖中展示了 FINBENCH 里面的 complex-read1，金融場景里面查資金流向是比較常見的，比如從一個起點查一個賬戶，訪問出度1-3度的邊，就是一個不定跳的過程，如果是資金交易，會有時間要求，比如這筆轉賬流水是一個時間遞增的序列，現在的聲明式語言還不能很清晰地描述這種不定跳加時間遞增的情況。
考慮到 GQL 將會在圖數據庫領域實現標準化，螞蟻現在對 GQL 支持的力度是很大的，除了 TuGraph、GeaFlow 能支持 GQL，其它一些還沒有開源的產品基本上也以 GQL 為方向去做接入。
二、查詢引擎介紹
接下來介紹 TuGraph 4.0 圖查詢引擎。
其實在 4.0 版本發布之前，我們 GQL 的語法文件就已經開源了，放在 TuGraph family 里面。4.0 版本實現了 GQL 的能力，當然能力仍比較有限，目前支持 SNB 和 FINBENCH 所有的 SHORT 查詢。具體實現可能和開源的語法文件有一些變動，這也是我們認為 GQL 本身不成熟的地方，現在是兩個分叉，未來一兩年之后，這兩個分叉再合并。
近期我們有兩項重要的計劃，第一是完善 GQL 語法的支持范圍，目前僅支持 SNB 和 FINBENCH 的一些最基礎的東西，之后會盡快增加比如 DDL 等更多方面的支持。另一件事是架構上的改造，引入一套全新的 GEAX 優化引擎，其目的是希望做一套更通用、對開源社區更友好的優化引擎。
其它方面的計劃包括，加入更加完善的 Test Suite 和相應的工具，以及使用查詢語言去打榜 SNB 或者 FINBENCH。
提到 SNB 和 FINBENCH，基準測試對于數據庫或者查詢引擎來說都是非常重要的，但并不是衡量一個查詢語言的唯一標準。查詢語言的評價維度包括性能、描述能力、健壯性和查詢優化等等。
比如查詢優化，最簡單 Cypher 寫法 1 相較于寫法 2 更易優化。如果要打一個很好的榜單，一定會用寫法 1 的形式，因為寫法 2 不一定會優化到，但最終用戶使用寫法1的體驗和效果可能會很差。因此我們對于查詢語言的要求會比打榜更高一些。
TuGraph 的具體使用方法，可以參見以下鏈接：
三、架構及演進計劃
下面介紹一下現有的架構，以及后期在架構層面可能會做的改動。
上圖是 TuGraph 現在最原始的架構。查詢進來，解析到 AST，然后可能有一些驗證，到 Planner 出來一個執行計劃，根據一些 Schema 信息或者一些統計信息進行優化，之后放入一個執行引擎里面去執行。
目前有兩個最大的問題，第一是要支持多個查詢語言 Cypher 和 GQL。萬幸的是，雖然 GQL 是一個全新的查詢語言，但其總體思想來自于 Cypher，體系上可以理解為一樣，因此我們可以做到對兩種語言的支持。
另一個問題是要支持更多的存儲引擎，目前 TuGraph 是一個簡單的單機版本，螞蟻內部已經有分布式的圖數據庫和一些圖計算系統，需要將這些不同的存儲引擎都接到我們的查詢引擎之上。
關系型數據庫和圖數據庫的層次是比較接近的，因此我們參考了 Calcite 系統。Calcite 是一個完整的查詢處理系統，能夠提供 DBMS 所需要的許多常用功能，甚至可以接近一個圖數據庫系統，支持完整的查詢語言的優化、解析、驗證。我們參考它的架構去做一個類似的處理系統，實現更豐富的算子，在圖的優化上能做得更多。
參考這個架構，我們會做 TuGraph 下一個版本的查詢引擎的改造，這個改造是在整個執行引擎之上的一層改造。參見上圖，右邊是 Data Processing System，和 Calcite 的設計類似。左邊 GeaX 中有幾個核心的模塊，第一個就是圖語法表示（GST），Quary 解析完之后，這里加了一層抽象，這層抽象能夠保證同時支持兩個相似的語言，比如 Cypher 和 GQL。同時有一套獨立的邏輯算子，能夠描述整個查詢，有單獨的優化器，這里的優化器也支持可插拔的功能。這樣整個系統就分為了兩部分，前面的查詢語言的處理，以及后面的計算和存儲。
GeaX 為 TuGraph 提供處理和優化圖查詢語言的能力，其特點包括，架構與 Calcite 相似，支持查詢語言解析、校驗、優化。嚴格意義上 GeaX 不算是一個圖計算引擎，因為它把計算的部分全部剝離了，最終產出的是一個邏輯執行計劃。另外，GeaX 支持多語言，支持不同的優化器，這些優化器是可插拔的，不同類型的優化器有不同的規則。GeaX 的目標不僅僅是作為一層查詢語言接在 TuGraph 上，還能夠實現輕松地將 GQL 查詢語言接到任何一個圖相關的引擎上，比如一個人一個月就能夠為 GraphScope 提供 GQL 的能力，這樣也為 GQL 成為統一的圖聲明式查詢語言提供幫助。
通過上圖的對比可以看出，GeaX 和 Calcite 在框架設計上是比較接近的，當然具體優化器的能力會有不同，這也正是 GeaX 框架的優勢之一，可以放不同的優化器在這里。
這個架構是我們未來 3-6 個月要去做的事情，現在已經邁出了第一步，實現了 geax-front-end。目前 parser 這一層已經實現。大概在 3-6 個月左右會有一版迭代，可能會有 GeaX 的出現。我們希望能做一個很簡單的 play ground 給用戶用，用戶能在對 TuGraph 沒有很多了解的情況下，嘗試去看 GQL 的查詢語言生成的邏輯執行計劃是什么樣的，通過看邏輯執行計劃，判斷這個查詢是不是復雜，是不是可以去增加一些優化規則。
