一、流圖計算引擎 TuGraph-Analytics

TuGraph-Analytics 是螞蟻自研的實時圖計算引擎，目前廣泛應(yīng)用于螞蟻金融風控、知識圖譜等業(yè)務(wù)場景。其形態(tài)接近于 Spark 或 Flink 這樣的計算引擎，具有分布式流圖計算的能力，類似于 Spark GraphX 和 Tiger Graph。但與它們最大的區(qū)別是 TuGraph-Analytics 是個流圖計算引擎，它具備流批一體的能力，能處理流式圖數(shù)據(jù)，也能做批量的圖的分析，另外也具備圖的 OLAP 分析的能力。

上圖中列出了 TuGraph-Analytics 的發(fā)展歷程，16 年就已經(jīng)立項，當時基于內(nèi)部的流式計算引擎擴展了圖的能力，實現(xiàn)了初代的流圖計算引擎。18 年進一步完善引擎能力，主要是支持離線圖仿真的能力以及圖 OLAP 能力，發(fā)展成為多計算形態(tài)的圖計算引擎。22 年朝著云原生的圖計算引擎架構(gòu)發(fā)展，支持了存算分離，同時也支持了云原生的 K8s 部署方式，到 23 年 6 月份項目正式對外開源。

TuGraph-Analytics 的整體架構(gòu)如上圖所示，主要分為 DSL 層、API 層、runtime層、存儲層以及云原生的 K8s 層，另外還提供了 GeaFlow Console 開發(fā)環(huán)境。

這里需要說明一下，對外開源品牌叫 TuGraph-Analytics，項目名字叫 GeaFlow，所以項目代碼里面還能看到 GeaFlow 這樣的名稱。

整個引擎的核心能力主要分為以下幾部分：

• 圖構(gòu)建能力：圖構(gòu)建是將原始數(shù)據(jù)轉(zhuǎn)成圖數(shù)據(jù)，比如日志數(shù)據(jù)，目前支持實時圖構(gòu)建和離線圖構(gòu)建。
• 圖查詢服務(wù)：圖的 OLAP 探索的能力。
• 實時圖計算：增量圖計算的能力。
• 圖仿真計算：離線圖的特征計算能力。
• 圖表融合查詢語言；支持 SQL+GQL 圖表融合分析能力。
• 一體化圖研發(fā)平臺 GeaFlow Console。

應(yīng)用場景主要包括以下三個：

• 離線的圖仿真計算：離線的圖特征計算，主要將 Hive 或 ODPS 中的歷史數(shù)據(jù)通過構(gòu)圖引擎寫到圖存儲，然后做圖的特征計算，主要做算法特征驗證，幫助快速上線圖特征。
• 實時圖計算：增量實時圖計算能力，將實時數(shù)據(jù)源的數(shù)據(jù)切成很多個小的窗口，這些窗口數(shù)據(jù)會形成增量圖，叫 △G，△G 會和全量的底圖做增量圖計算。主要場景是一些對實時性要求比較高的需求，比如實時交易環(huán)的查找，去判斷一筆交易是不是套現(xiàn)行為。
• OLAP 分析：將各種數(shù)據(jù)源的數(shù)據(jù)進行實時的構(gòu)圖，寫到圖存儲中，然后通過 OLAP 服務(wù)來提供分析查詢，基于圖 OLAP 能力可以做多維度關(guān)系查詢。

二、TuGraph-Analytics DSL

接下來介紹 TuGraph-Analytics DSL。目前流行的語言非常多，有 Gremlin、Cypher、GSQL、ISO/GQL 和 PGQL 等，其實還沒有真正的圖的標準語言。

目前 GeaFlow 里面主要采用了兩種語言，Gremlin 和 ISO/GQL。

• Gremlin 是 Apache 的開源項目，目前在業(yè)界使用非常廣泛。
• ISO/GQL 是 ISO 制定中的圖查詢標準語言，它吸收了主流圖查言語的優(yōu)點，寫法上更接近 SQL。

上圖中最下面兩行分別是這兩種寫法的例子。

TuGraphy-Analytics 提供了一套圖表一體的融合編程能力，支持 SQL+GQL 和SQL+Gremlin 兩種圖表融合的編程方式。

• 左邊的例子是通過 With 語句定義觸發(fā)的起始點表，然后觸發(fā)下面這個 MATCH 語句的查詢，語句結(jié)果再經(jīng)過 SQL 的邏輯做過濾聚合，最后寫到結(jié)果表中，整個過程就可實現(xiàn)圖和表的一體化編程。
• 右邊是 SQL+Gremlin 的例子，它是在 SQL 里面嵌入了 Gremlin 的查詢，先在 from 里面定義一個 request 語句，然后觸發(fā)上面的 Gremlin 查詢。

上圖展示了 DSL 的整體架構(gòu)。

• 最上面是語言層，包括 SQL，GQL，Gremlin 這些語言。
• 下面是 Parser 模塊，將文本語言轉(zhuǎn)成統(tǒng)一的語法樹。
• 再下面一層是邏輯執(zhí)行計劃層，將語法樹轉(zhuǎn)成統(tǒng)一的邏輯執(zhí)行計劃，在轉(zhuǎn)換過程中做類型的推導以及校驗。
• 轉(zhuǎn)換后的邏輯執(zhí)行計劃會交給下面優(yōu)化層做優(yōu)化，優(yōu)化好的邏輯執(zhí)行計劃再轉(zhuǎn)給后面的物理執(zhí)行計劃層。
• 在物理執(zhí)行計劃層，通過 DAG Builder 轉(zhuǎn)成 DAG 圖的方式來運行，在這個 DAG 圖里面存在兩種類型的算子，一種是 Table Operator，也就是表處理的算子；另外一種是 Graph Operator，也就是圖處理的算子。
• 在外圍還有一些 Connector 模塊，這些是插件體系，主要是支持對外部數(shù)據(jù)源的讀取，比如 Hive、Kafka 等數(shù)據(jù)源。
• 另外，也支持擴展的自定義能力，包括自定義的 UDF 以及 UDGF，UDGF 就是制定圖算法的接口。

其特點包括：

• 具備圖表一體化的分析能力：既能處理圖的數(shù)據(jù)，也能處理表的數(shù)據(jù)。
• 具備分布式執(zhí)行能力：整個引擎采用分布式執(zhí)行框架。
• 多種圖語言的支持和多數(shù)據(jù)源的接入：目前主流 Hive，HDFS，Kafka 以及 Hudi 這些數(shù)據(jù)都能支持。
• 內(nèi)置豐富的圖的算法庫。
• 支持自定義的擴展能力：可以自定義 Connector、UDF 或圖的算法。

我們在 19 年支持 SQL+Gremlin 的編程方式，21 年加入了 ISO/GQL，22 年支持了 SQL+ISO/GQL 這種融合編程的方式。

下面簡單介紹一下 DSL 的執(zhí)行流程：

• 一段文本過來之后，會通過 Parser 模塊轉(zhuǎn)成語法樹。
• 然后 Validator 模塊會對語法樹進行類型和語義的校驗，同時會做語法樹上的類型推導，得到帶類型的 AST 語法樹。
• 接下來會交給 LogicalPlanConverter 邏輯執(zhí)行計劃轉(zhuǎn)換器，將語法樹轉(zhuǎn)成 LogicalPlan。
• 之后會將 LogicalPlan 交給優(yōu)化器，優(yōu)化器里面包含很多優(yōu)化規(guī)則，規(guī)則會將執(zhí)行計劃改寫，來生成更優(yōu)的 LogicalPlan。
• 再交給物理執(zhí)行計劃轉(zhuǎn)換器，轉(zhuǎn)成一個 PhysicPlan。
• 最后再交由 DAG Builder 轉(zhuǎn)成 DSL 運行時的 DAG。

上圖就是運行時的 DAG 圖，整體的運行是以 DAG 圖的方式去執(zhí)行的，與主流的計算引擎 Spark、Flink 等的 DAG 圖是類似的，區(qū)別在于它既有表的算子，也有圖的迭代算子：

• 表算子，比如 source 讀源頭的數(shù)據(jù)，project 做投影的運算，filter 做過濾，sink 寫結(jié)果表。
• 圖的迭代算子 Iterator Operator，圖計算是采用類似 VC 的迭代計算框架，計算會分成很多輪的迭代，上一輪迭代會給下一輪的 Active 點發(fā)消息，激活下一輪的迭代計算。比如這里的語句在迭代里面會進一步展開成右側(cè)下面的這個 DAG，每一個節(jié)點就是一個計算邏輯，比如 out 就是去取出邊，in 取入邊，where 做過濾，這樣就可以將 Match 語句在這個迭代里做邏輯展開。

另外說明一下實時圖計算是如何運行的。Source 定義了一批圖查詢的起點，比如數(shù)據(jù)存放在 Kafka 中，數(shù)據(jù)源的數(shù)據(jù)會被切成很多個小的窗口，然后 window by window 地觸發(fā)整個執(zhí)行流程，從而實現(xiàn)流式圖計算。

三、數(shù)倉加速場景應(yīng)用

接下來介紹用圖來做數(shù)倉加速場景，數(shù)倉場景存在的問題主要包括：

• 多表 join 的性能問題，數(shù)倉會有非常多的多表 join，join 的問題是開銷比較大，計算時會進行大量的 shuffle，尤其是當表特別多的時候，另外計算本身開銷也非常大。
• 實效性比較差，想做 Adhoc 其實是比較困難的，另外離線處理的時間也會比較長，尤其是 join 非常多的時候，很難算得動。

對于這些問題，數(shù)倉場景通常會使用寬表解決，就是把這些表提前做 join 物化，后面 join 的時候直接查這個寬表，就能起到加速的效果，然而寬表會存在下面這幾個問題：

• 加工成本比較高，需要做一次大規(guī)模數(shù)據(jù)的 join。
• 寬表本身存儲成本就比較高，因為 join 會做笛卡爾積運算，對于那種多對多的 join 展成寬表之后，存儲放大是非常嚴重的。
• 靈活度不夠，比如生成好一張寬表以后，需要再加一張表，那么整個寬表只能重新生成。
• 實時性難以滿足，如果想做多表的實時 join，在流計算里做 join，會存儲左右兩邊的狀態(tài)，當 join 特別多的時候，狀態(tài)對性能影響非常大，實時性很難被滿足。

圖加速的解決方案為，首先利用圖定義實體之間的關(guān)系，因為圖天然就是一種關(guān)系，在圖里面用點來代表實體，用邊來代表關(guān)系。比如商品交易的圖中，有用戶和商品兩種類型的實體，對應(yīng)圖里面就是兩個點，另外還有用戶和用戶的關(guān)系以及用戶和商品之間的交易這兩種行為，這兩種行為就是圖中的兩條邊，這樣就可以用圖定義出實體和實體之間的關(guān)系。

有了圖的定義之后，就可以利用圖來物化這種關(guān)系，從而加速查詢。物化關(guān)系就是把邏輯上的圖，通過圖構(gòu)建，轉(zhuǎn)成物理的圖。比如將用戶、商品、交易、關(guān)系等數(shù)據(jù)通過構(gòu)圖引擎寫到圖存儲中。

之后就可以通過 OLAP 服務(wù)或者圖計算作業(yè)來做圖計算。

這樣做的好處是可以做實時的物化點邊的關(guān)系，同時利用圖物化結(jié)構(gòu)可以提高整個查詢的性能，可以做多表關(guān)聯(lián)實時的查詢，另外相比寬表還可以靈活添加點邊，且原有的結(jié)構(gòu)不需要做任何改動。

建立一個圖的模型，利用圖去定義關(guān)系模型，有兩種方式：

• 手動建模，就是人工去分析系統(tǒng)里面哪些是實體哪些是關(guān)系，把圖定義出來，比如用戶交易圖里面，就會有用戶和商品兩種點，有 trade 和 relation 兩個邊。
• 自動建模，就是根據(jù)語句的關(guān)聯(lián)性，以及根據(jù)數(shù)倉中現(xiàn)有的一些模型，分析關(guān)聯(lián)關(guān)系自動建模，但目前主要采用的還是手動建模的方式。

有了圖模型之后，就可以將數(shù)倉表的數(shù)據(jù)寫到圖里面去，可以使用實時和離線兩種構(gòu)圖方式，同時也支持多種外部數(shù)據(jù)源的寫入，圖構(gòu)建好之后就可以使用圖查詢語言查詢想要的結(jié)果，比如計算同一個人群以及商品類目下交易的排序，通過 SQL 可能是三次 join 加上 group by limit 的方式，如果用 GQL 則是 Match 的方式，寫法還是比較簡潔的。

這里的一個問題是，在數(shù)倉的場景下，使用 SQL 是更普遍的，畢竟 SQL 的發(fā)展更早，很多同學其實對 SQL 也更熟悉，數(shù)倉場景下也積累了很多歷史的 SQL，所以希望能把這些 SQL 無縫遷移到圖模型上來。

基于這個場景，我們提供了 SQL 自動轉(zhuǎn)圖查詢的功能，就是給定 SQL 以及圖模型，通過圖查詢轉(zhuǎn)換器轉(zhuǎn)換成圖的 plan，然后交給圖查詢引擎執(zhí)行。

這樣即可實現(xiàn) SQL 的無縫遷移，將其遷移到圖模型上來，然后利用圖的優(yōu)勢做查詢加速，當然這里也有一些限制，比如 SQL 的關(guān)鍵關(guān)系必須是定義在圖模型里面的，不能是任意自由組合的 join。

SQL 自動轉(zhuǎn)圖查詢的實現(xiàn)，首先需要有一個圖模型，比如有 v1、v2、v3 三個點，e1、e2、e3 三條邊，SQL 語句是 v1 join e1 join v2，首先會把它轉(zhuǎn)成關(guān)系代數(shù)，比如 LogicalJoin 這種方式，然后通過優(yōu)化器進行優(yōu)化改寫，把 join 轉(zhuǎn)成 Match，也就是圖中右下角這種形式，這樣就能實現(xiàn)把 SQL 語句轉(zhuǎn)成圖查詢的能力。

目前支持的場景包括：

• 單表查詢：對圖里單張點表做普通的關(guān)系查詢，雖然在性能上不一定是最好的，但從語義的完備性上講是需要有這個能力的。
• 點邊關(guān)聯(lián)關(guān)系：多度的關(guān)聯(lián)關(guān)系，比如點跟邊的關(guān)聯(lián)，再跟點的關(guān)聯(lián)，還有多邊的關(guān)聯(lián)。比如一個點有很多個邊，邊之間互相關(guān)聯(lián)的情況，join 類型目前支持 inner、left 和 right 這 3 種 join 方式。
• 復(fù)雜的關(guān)聯(lián)關(guān)系：嵌套的子查詢的關(guān)聯(lián)，比如圖中 v1 做一個 project，再和 e1 關(guān)聯(lián)，然后再做聚合，再和 v2 關(guān)聯(lián)。
• 其他不能轉(zhuǎn)換的語句，也能通過表的方式去處理。

四、總結(jié)與規(guī)劃

圖和數(shù)倉結(jié)合是一個非常新的方向，螞蟻內(nèi)部做了很多的嘗試和探索，未來希望能夠不斷完善，并覆蓋更多的場景，同時也希望借助開源的力量，推廣新的方案，得到業(yè)界更多的關(guān)注。

圖本身就是一種關(guān)系，應(yīng)用場景不應(yīng)該只局限于傳統(tǒng)的典型的圖算法領(lǐng)域，其它數(shù)倉的關(guān)系型代數(shù)領(lǐng)域也會有應(yīng)用場景。

接下來的規(guī)劃主要包括：

• 首先，進一步完善 SQL 轉(zhuǎn)圖查詢的能力，真正做到給一段 SQL，能夠使其完全無縫地在圖引擎中執(zhí)行。
• 另外在智能建模方面，繼續(xù)進行探索，也是為了降低使用的成本和用戶理解的成本。
• 性能優(yōu)化方面，第一是圖上的向量化執(zhí)行，目前圖的執(zhí)行普遍還是行式的執(zhí)行方式，存儲還是行存，未來希望在圖上做列式存儲和向量化計算，這對數(shù)倉分析的場景會更有利；第二是圖的CBO 優(yōu)化，圖里面 Match 的順序?qū)φ麄€性能影響非常大，未來也希望借助CBO 優(yōu)化器來進一步優(yōu)化組合順序來提升整體性能。
• 最后是開源開放，目前很多能力已經(jīng)對外開源，未來還會不斷完善，將更多的功能對外開放。