TuGraph Analytics（內(nèi)部項目名GeaFlow）是螞蟻集團開源的分布式實時圖計算引擎，即流式圖計算。通過SQL+GQL融合分析語言對表模型和圖模型進行統(tǒng)一處理，實現(xiàn)了流、批、圖一體化計算，并支持了Exactly Once語義、高可用以及一站式圖研發(fā)平臺等生產(chǎn)化能力。

開源項目代碼目前托管在GitHub，歡迎業(yè)界同仁、大數(shù)據(jù)/圖計算技術(shù)愛好者關(guān)注我們的項目并參與共建。

項目地址：https://github.com/TuGraph-family/tugraph-analytics

GeaFlow論文【SIGMOD 2023】：GeaFlow: A Graph Extended and Accelerated Dataflow System

概覽

本文希望通過一張圖描述清楚TuGraph Analytics的整體架構(gòu)脈絡和關(guān)鍵設計思路，以幫助大家快速對TuGraph Analytics項目的輪廓有個整體的認識。閑言少敘，直接上圖。

TuGraph Analytics開源技術(shù)架構(gòu)一共分為五個部分：

• DSL層：即語言層。TuGraph Analytics設計了SQL+GQL的融合分析語言，支持對表模型和圖模型統(tǒng)一處理。
• Framework層：即框架層。TuGraph Analytics設計了面向Graph和Stream的兩套API支持流、批、圖融合計算，并實現(xiàn)了基于Cycle的統(tǒng)一分布式調(diào)度模型。
• State層：即存儲層。TuGraph Analytics設計了面向Graph和KV的兩套API支持表數(shù)據(jù)和圖數(shù)據(jù)的混合存儲，整體采用了Sharing Nothing的設計，并支持將數(shù)據(jù)持久化到遠程存儲。
• Console平臺：TuGraph Analytics提供了一站式圖研發(fā)平臺，實現(xiàn)了圖數(shù)據(jù)的建模、加工、分析能力，并提供了圖作業(yè)的運維管控支持。
• 執(zhí)行環(huán)境：TuGraph Analytics可以運行在多種異構(gòu)執(zhí)行環(huán)境，如K8S、Ray以及本地模式。

DSL層

DSL層是一個典型的編譯器技術(shù)架構(gòu)，即語法分析、語義分析、中間代碼生成(IR)、代碼優(yōu)化、目標代碼生成（OBJ）的流程。

• 語言設計：TuGraph Analytics設計了SQL+GQL的融合語法，解決了圖+表一體化分析的訴求。具體語法設計可以參考文章：DSL語法文檔
• 語法分析：通過擴展Calcite的SqlNode和SqlOperator，實現(xiàn)SQL+GQL的語法解析器，生成統(tǒng)一的語法樹信息。
• 語義分析：通過擴展Calcite的Scope和Namespace，實現(xiàn)自定義Validator，對語法樹進行約束語義檢查。
• 中間代碼生成：通過擴展Calcite的RelNode，實現(xiàn)圖上的Logical RelNode，用于GQL語法的中間表示。
• 代碼優(yōu)化：優(yōu)化器實現(xiàn)了大量的優(yōu)化規(guī)則（RBO）用于提升執(zhí)行性能，未來也會引入CBO。
• 目標代碼生成：代碼生成器Converter負責將Logical RelNode轉(zhuǎn)換為Physical RelNode，即目標代碼。Physical RelNode可以直接翻譯為Graph/Table上的API調(diào)用。
• 自定義函數(shù): TuGraph Analytics提供了大量的內(nèi)置系統(tǒng)函數(shù)，用戶也可以根據(jù)需要注冊自定義函數(shù)。
• 自定義插件: TuGraph Analytics允許用戶擴展自己的Connector類型，以支持不同的數(shù)據(jù)源和數(shù)據(jù)格式。

Framework層

Framework層設計與Flink/Spark等同類大數(shù)據(jù)計算引擎有一定的相似性，即提供了類FlumeJava（FlumeJava: Easy, Efficient Data-Parallel Pipelines）的統(tǒng)一高階API（簡稱HLA），用戶調(diào)用高階API的過程會被轉(zhuǎn)換為邏輯執(zhí)行計劃，邏輯執(zhí)行計劃執(zhí)行一定的優(yōu)化（如ChainCombine、UnionPushUp等）后，被轉(zhuǎn)換為物理執(zhí)行計劃，物理執(zhí)行計劃會被調(diào)度器分發(fā)到分布式Worker上執(zhí)行，最終Worker會回調(diào)用戶傳遞的高階API函數(shù)邏輯，實現(xiàn)整個分布式計算鏈路的執(zhí)行。

• 高階API：TuGraph Analytics通過Environment接口適配異構(gòu)的分布式執(zhí)行環(huán)境（K8S、Ray、Local），使用Pipeline封裝了用戶的數(shù)據(jù)處理流程，使用Window抽象統(tǒng)一了流處理（無界Window）和批處理（有界Window）。Graph接口提供了靜態(tài)圖和動態(tài)圖（流圖）上的計算API，如append/snapshot/compute/traversal等，Stream接口提供了統(tǒng)一流批處理API，如map/reduce/join/keyBy等。
• 邏輯執(zhí)行計劃：邏輯執(zhí)行計劃信息統(tǒng)一封裝在PipelineGraph對象內(nèi)，將高階API對應的算子（Operator）組織在DAG中，算子一共分為5大類：SourceOperator對應數(shù)據(jù)源加載、OneInputOperator/TwoInputOperator對應傳統(tǒng)的數(shù)據(jù)處理、IteratorOperator對應靜態(tài)/動態(tài)圖計算。DAG中的點（PipelineVertex）記錄了算子（Operator）的關(guān)鍵信息，如類型、并發(fā)度、算子函數(shù)等信息，邊（PipelineEdge）則記錄了數(shù)據(jù)shuffle的關(guān)鍵信息，如Partition規(guī)則（forward/broadcast/key等）、編解碼器等。
• 物理執(zhí)行計劃：物理執(zhí)行計劃信息統(tǒng)一封裝在ExecutionGraph對象內(nèi)，并支持二級嵌套結(jié)構(gòu)，以盡可能將可以流水線執(zhí)行的子圖（ExecutionVertexGroup）結(jié)構(gòu)統(tǒng)一調(diào)度。圖中示例的物理執(zhí)行計劃DAG被劃分為三部分子圖結(jié)構(gòu)分別執(zhí)行。
• 調(diào)度器：TuGraph Analytics設計了基于Cycle的調(diào)度器（CycleScheduler）實現(xiàn)對流、批、圖的統(tǒng)一調(diào)度，調(diào)度過程通過事件驅(qū)動模型觸發(fā)。物理執(zhí)行計劃中的每部分子圖都會被轉(zhuǎn)換為一個ExecutionCycle對象，調(diào)度器會向Cycle的頭結(jié)點（Head）發(fā)送Event，并接收Cycle尾結(jié)點（Tail）的發(fā)回的Event，形成一個完整的調(diào)度閉環(huán)。對于流處理，每一輪Cycle調(diào)度會完成一個Window的數(shù)據(jù)的處理，并會一直不停地執(zhí)行下去。對于批處理，整個Cycle調(diào)度僅執(zhí)行一輪。對于圖處理，每一輪Cycle調(diào)度會完成一次圖計算迭代。
• 運行時組件：TuGraph Analytics運行時會拉起Client、Master、Driver、Container組件。當Client提交Pipeline給Driver后，會觸發(fā)執(zhí)行計劃構(gòu)建、分配Task（ResourceManagement提供資源）和調(diào)度。每個Container內(nèi)可以運行多個Worker組件，不同Worker組件之間通過Shuffle模塊交換數(shù)據(jù)，所有的Worker都需要定期向Master上報心跳（HeartbeatManagement），并向時序數(shù)據(jù)庫上報運行時指標信息。另外TuGraph Analytics運行時也提供了故障容忍機制（FailOver），以便在異常/中斷后能繼續(xù)執(zhí)行。

State層

State層設計相比于傳統(tǒng)的大數(shù)據(jù)計算引擎，除了提供面向表數(shù)據(jù)的KV存儲抽象，也支持了面向圖數(shù)據(jù)的Graph存儲抽象，以更好地支持面向圖模型的IO性能優(yōu)化。

• State API：提供了面向KV存儲API，如get/put/delete等。以及面向圖存儲的API，如V/E/VE，以及點/邊的add/update/delete等。
• State執(zhí)行層：通過KeyGroup的設計實現(xiàn)數(shù)據(jù)的Sharding和擴縮容能力，Accessor提供了面向不同讀寫策略和數(shù)據(jù)模型的IO抽象，StateOperator抽象了存儲層SPI，如finish（刷盤）、archive（Checkpoint）、compact（壓縮）、recover（恢復）等。另外，State提供了多種PushDown優(yōu)化以加速IO訪問效率。通過自定義內(nèi)存管理和面向?qū)傩缘亩壦饕矔峁┐罅康拇鎯υL問優(yōu)化手段。
• Store層：TuGraph Analytics支持了多種存儲系統(tǒng)類型，并通過StoreContext封裝了Schema、序列化器，以及數(shù)據(jù)版本信息。
• 持久化層：State的數(shù)據(jù)支持持久化到遠程存儲系統(tǒng)，如HDFS、OSS、S3等。

Console平臺

Console平臺提供了一站式圖研發(fā)、運維的平臺能力，同時為引擎運行時提供元數(shù)據(jù)（Catalog）服務。

• 標準化API：平臺提供了標準化的RESTful API和認證機制，同時支持了頁面端和應用端的統(tǒng)一API服務能力。
• 任務研發(fā)：平臺支持“關(guān)系-實體-屬性”的圖數(shù)據(jù)建模?；谧侄斡成渑渲?，可以定義圖數(shù)據(jù)傳輸任務，包括數(shù)據(jù)集成（Import）和數(shù)據(jù)分發(fā)（Export）?；趫D表模型的圖數(shù)據(jù)加工任務支持多樣化的計算場景，如Traversal、Compute、Mining等?；跀?shù)據(jù)加速器的圖數(shù)據(jù)服務，提供了多協(xié)議的實時分析能力，支持BI、可視化分析工具的接入集成。
• 構(gòu)建提交：平臺通過任務和作業(yè)的獨立抽象，實現(xiàn)研發(fā)態(tài)與運維態(tài)的分離。任務開發(fā)完成后執(zhí)行發(fā)布動作，會自動觸發(fā)構(gòu)建流水線（Release Builder），生成發(fā)布版本。任務提交器（Task Submitter）負責將發(fā)布版本的內(nèi)容提交到執(zhí)行環(huán)境，生成計算作業(yè)。
• 作業(yè)運維：作業(yè)屬于任務的運行態(tài)，平臺提供了作業(yè)的操縱（啟停、重置）、監(jiān)控（指標、告警、審計）、調(diào)優(yōu)（診斷、伸縮、調(diào)參）、調(diào)度等運維能力。作業(yè)的運行時資源會由資源池統(tǒng)一分配和管理。
• 元數(shù)據(jù)服務：平臺同時承載了引擎運行時的元數(shù)據(jù)服務能力，以實現(xiàn)研發(fā)與運維的自動化。元數(shù)據(jù)以實例維度進行隔離，實例內(nèi)的研發(fā)資源可以根據(jù)名字直接訪問，如點、邊、圖、表、視圖、函數(shù)等。
• 系統(tǒng)管理：平臺提供了多租戶隔離機制、細粒度用戶權(quán)限控制，以及系統(tǒng)資源的管理能力。

執(zhí)行環(huán)境

TuGraph Analytics支持多種異構(gòu)環(huán)境執(zhí)行，以常見的K8S部署環(huán)境為例，其物理部署架構(gòu)如下：

在TuGraph Analytics作業(yè)的全生命周期過程中，涉及的關(guān)鍵數(shù)據(jù)流程有：

• 研發(fā)階段：Console平臺提供了實例下所有的研發(fā)資源的管理，用戶可以在創(chuàng)建任務前，提前準備所需的研發(fā)資源信息，并存儲在Catalog。
• 構(gòu)建階段：任務創(chuàng)建完成后，通過發(fā)布動作觸發(fā)構(gòu)建流水線，用戶的JAR包、任務的ZIP包等會上傳到RemoteFileStore。
• 提交階段：作業(yè)提交時，Console會根據(jù)作業(yè)的參數(shù)配置、運行時環(huán)境信息，以及遠程文件地址等創(chuàng)建KubernetesJobClient，既而會拉起Client Pod，Client會拉起Master Pod，Master會拉起Container Pods和Driver Pod。所有的Pod拉起后，Client會把作業(yè)的Pipeline發(fā)送給Driver執(zhí)行，Driver最終通過Cycle調(diào)度的Events與Containers交互。所有的Pod啟動時都會從RemoteFileStore下載版本JAR包、用戶JAR包、作業(yè)ZIP包等信息。Driver對DSL代碼編譯時，也需要通過Console提供的Catalog API操作Schema信息。
• 運行階段：作業(yè)運行時，各個組件會上報不同的數(shù)據(jù)和信息。Master會上報作業(yè)的心跳匯總信息，Driver會上報作業(yè)的Pipeline/Cycle指標以及錯誤信息，Container會上報作業(yè)的Offset、指標定義以及錯誤信息等。RuntimeMetaStore存儲作業(yè)的Pipeline/Cycle指標、Offset、心跳匯總、錯誤等信息。HAMetaStore存儲各個運行組件的地址信息。DataStore存儲State數(shù)據(jù)和作業(yè)FailOver時所需的元數(shù)據(jù)信息。MetricStore存儲運行時指標信息。
• 監(jiān)控階段：Console會主要查詢RuntimeMetaStore和MetricStore存儲的信息用于作業(yè)的運行時監(jiān)控。
• 清理階段：作業(yè)重置/刪除時，Console會對作業(yè)的RuntimeMeta、HAMeta以及部分Data做清理操作。

總結(jié)

希望通過以上的介紹，可以讓大家對TuGraph Analytics開源技術(shù)架構(gòu)有個比較清晰的了解，我們非常歡迎開源社區(qū)的技術(shù)愛好者參與到項目的建設中來。

如果您對TuGraph Analytics項目比較感興趣，歡迎動動手指直達我們的GitHub倉庫github.com/TuGraph-family/tugraph-analytics，為我們的項目加一顆Star?！揪W(wǎng)絡不暢可以嘗試使用VPN訪問】

如果您對該項目的發(fā)展有好的建議和意見，歡迎大家提交Issue到開源社區(qū)，或者通過以下方式與我們直接聯(lián)系。

文章來源地址http://www.zghlxwxcb.cn/news/detail-664292.html

到了這里，關(guān)于一張圖讀懂TuGraph Analytics開源技術(shù)架構(gòu)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！