一、流圖計算引擎 TuGraph-Analytics

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

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

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

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

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

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

應用場景主要包括以下三個：

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

二、TuGraph-Analytics DSL

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

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

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

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

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

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

上圖展示了 DSL 的整體架構。

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

其特點包括：

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

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

下面簡單介紹一下 DSL 的執行流程：

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

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

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

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

三、數倉加速場景應用

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

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

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

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

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

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

之后就可以通過 OLAP 服務或者圖計算作業來做圖計算。

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

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

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

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

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

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

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

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

目前支持的場景包括：

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

四、總結與規劃

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

圖本身就是一種關系，應用場景不應該只局限于傳統的典型的圖算法領域，其它數倉的關系型代數領域也會有應用場景。

接下來的規劃主要包括：

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