一、流圖計(jì)算引擎 TuGraph-Analytics

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

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

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

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

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

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

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

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

二、TuGraph-Analytics DSL

接下來介紹 TuGraph-Analytics DSL。目前流行的語(yǔ)言非常多，有 Gremlin、Cypher、GSQL、ISO/GQL 和 PGQL 等，其實(shí)還沒有真正的圖的標(biāo)準(zhǔn)語(yǔ)言。

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

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

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

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

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

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

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

其特點(diǎn)包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目前支持的場(chǎng)景包括：

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

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

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

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

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

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