Nebula Graph 在微眾銀行數(shù)據(jù)治理業(yè)務(wù)的實踐

本文為微眾銀行大數(shù)據(jù)平臺：周可在 nMeetup 深圳場的演講這里文字稿，演講視頻參見：B站

自我介紹下，我是微眾銀行大數(shù)據(jù)平臺的工程師：周可，今天給大家分享一下 Nebula Graph 在微眾銀行 WeDataSphere 的實踐情況。

先來說下圖數(shù)據(jù)庫應(yīng)用背景。

WeDataSphere 圖數(shù)據(jù)庫架構(gòu)是基于 JanusGraph 搭建，正如邸帥在演講《NebulaGraph - WeDataSphere 開源介紹》中提及的那樣，主要用于解決微眾銀行數(shù)據(jù)治理中的數(shù)據(jù)血緣問題。在使用 JanusGraph 過程中，微眾銀行發(fā)現(xiàn) JanusGraph 本身依賴組件較多，數(shù)據(jù)存儲在 HBase 中，索引存儲在 Eleasticsearch 中，而因為受分布式高可用和兩地三中心架構(gòu)規(guī)范要求，要搭建一套完整的圖數(shù)據(jù)庫系統(tǒng)涉及技術(shù)點(diǎn)較多，比如高可用問題，再加上三個組件串聯(lián)，需要解決很多技術(shù)問題。而且，本身 JanusGraph 這塊數(shù)據(jù)寫入性能也存在問題，當(dāng)然本身我們對 JanusGraph 的優(yōu)化也較少，主要集中在參數(shù)調(diào)整和安全性能提升。

當(dāng)時用這套系統(tǒng)處理的數(shù)據(jù)量大概是每天 60 萬個點(diǎn)，百萬級的邊，差不多一天要花 5 個小時左右才能完成寫入。這就導(dǎo)致業(yè)務(wù)方需要使用血緣數(shù)據(jù)時，大數(shù)據(jù)平臺不能及時提供。

至于微眾銀行大數(shù)據(jù)平臺為什么選用 Nebula Graph，微眾銀行早期調(diào)研過一些商用、開源的圖數(shù)據(jù)庫解決方案，測試部分這里不做贅述，可以參考下 Nebula Graph 社區(qū) 美團(tuán)、騰訊云安全團(tuán)隊和 Boss 直聘 做的性能測評。

這里說下剛才 60 萬個點(diǎn)、百萬級別邊這個場景的情況，在單節(jié)點(diǎn)低配機(jī)器部署情況下，微眾銀行導(dǎo)入數(shù)據(jù)基本上在 20 分鐘內(nèi)完成。Nebula Graph 的寫入性能非常好，微眾銀行大數(shù)據(jù)平臺這塊業(yè)務(wù)對查詢的性能要求并不高，Nebula Graph 也能滿足大數(shù)據(jù)平臺這塊的查詢要求。

微眾銀行的圖數(shù)據(jù)庫選擇還有一個重量考核點(diǎn)，高可用和容災(zāi)的架構(gòu)支持。這個考核項，Nebula Graph 本身的架構(gòu)存在一定優(yōu)勢，符合微眾銀行行內(nèi)硬性的架構(gòu)要求和規(guī)范。加上大數(shù)據(jù)平臺本身旨在構(gòu)建一個完整的數(shù)據(jù)流生態(tài)，Nebula Graph 提供了一些大數(shù)據(jù)相關(guān)開源組件，比如：Connector，Exchange，這些工具能很好地同大數(shù)據(jù)平臺進(jìn)行結(jié)合。

最后一點(diǎn)，回歸到人的問題——微眾銀行同開源社區(qū)的交流等同于跟其他技術(shù)人的交流。和 Nebula Graph 社區(qū)交流過程中發(fā)，微眾銀行發(fā)現(xiàn)不管是在 PoC 微信群，還是在 Nebula Graph 社區(qū)論壇上提問題，官方反饋非常及時。印象較深的一點(diǎn)是，有一天晚上 10 點(diǎn)多，大數(shù)據(jù)平臺在 Nebula Graph 研發(fā)人員指導(dǎo)下優(yōu)化了一個參數(shù)，我們在微信群里和 Nebula Graph 反饋，這個參數(shù)調(diào)整之后解決了生產(chǎn)問題，Nebula Graph 研發(fā)同學(xué)還給我們發(fā)了一個 666 的表情。[手動狗頭] 哈哈哈哈挺好。

OK，下面來講解下 WeDataSphere 架構(gòu)，主要集中在架構(gòu)設(shè)計中所考慮的點(diǎn)。

上圖和大多數(shù)應(yīng)用的層級劃分類似，從上往下看，應(yīng)用層產(chǎn)生數(shù)據(jù)，通過數(shù)據(jù)交換層的各種工具，同底層的圖數(shù)據(jù)庫系統(tǒng)交換數(shù)據(jù)。應(yīng)用場景方面這里不作詳細(xì)介紹，在本文后面會詳細(xì)地講解金融行業(yè)的應(yīng)用情況。

從行業(yè)來看，中間的數(shù)據(jù)層一般分為三個部分：批量數(shù)據(jù)、流式數(shù)據(jù)和在線數(shù)據(jù)。而數(shù)據(jù)交換方面，微眾銀行大數(shù)據(jù)平臺基于 Nebula 提供的開源方案做了接入優(yōu)化，底層則使用 Nebula Graph 圖數(shù)據(jù)庫系統(tǒng)。此外，微眾銀行大數(shù)據(jù)平臺還有一套運(yùn)維自動化系統(tǒng)叫 Managis，基于 Managis 構(gòu)建了自動化部署工具，Nebula 配置也是在類 CMDB 系統(tǒng)中管理。

服務(wù)監(jiān)控模塊，微眾銀行大數(shù)據(jù)平臺內(nèi)部使用 Zabbix 監(jiān)控，通過寫腳本調(diào)用 Metric HTTP 接口，將監(jiān)控指標(biāo)傳輸?shù)?Managis Monitor (Zabbix) 系統(tǒng)中。

總體的架構(gòu)如上圖所示，從上至下的 4 層架構(gòu)體系。

回到用戶層面，搭建這套系統(tǒng)在銀行架構(gòu)規(guī)范下如何提供給用戶使用，保證服務(wù)穩(wěn)定性以及可用率，是大數(shù)據(jù)平臺的首要考慮條件。通過借鑒 WeDataSphere 之前計算存儲組件的成功經(jīng)驗，例如 HBase、ES 等組件，如果業(yè)務(wù)方的系統(tǒng)對穩(wěn)定性和一致性有所要求，業(yè)務(wù)接入端需要實現(xiàn)雙寫功能；針對數(shù)據(jù)一致性方面，大數(shù)據(jù)平臺做了 T+1 的數(shù)據(jù)寫入校正。當(dāng)然這種雙寫方式接入，業(yè)務(wù)端會存在改造和開發(fā)成本。

后期，基于大數(shù)據(jù)平臺開源的解決方案 Linkis 提供的 Orchestrator 模塊實現(xiàn)編排、回放、高可用。業(yè)務(wù)端無需了解具體的技術(shù)實現(xiàn)細(xì)節(jié)，通過調(diào)用大數(shù)據(jù)平臺的 SDK 接入 Linkis 的 Orchestrator 解決方案實現(xiàn)高可用和數(shù)據(jù)的雙讀雙寫功能。目前這塊功能尚在開發(fā)中，會在近期開源。

上圖為異地容災(zāi)過程，主要依賴于 Nebula Graph 本身提供的容災(zāi)特性，比如：Checkpoint。目前，大數(shù)據(jù)平臺的具體操作是每天將 Checkpoint 做數(shù)據(jù)備份同步到上海的容災(zāi)集群。一旦主集群出問題，即刻切換系統(tǒng)到上海災(zāi)備集群，等主集群恢復(fù)后，將數(shù)據(jù)同步到主集群。

下面來介紹下 Nebula Graph 在大數(shù)據(jù)平臺 WeDataSphere 數(shù)據(jù)治理系統(tǒng)中的應(yīng)用。

先簡單地介紹一下 WeDataSphere 數(shù)據(jù)治理系統(tǒng)，它包括 數(shù)據(jù)建模工具 元數(shù)據(jù)管理系統(tǒng) 數(shù)據(jù)脫敏系統(tǒng) 數(shù)據(jù)質(zhì)量管理系統(tǒng)

元數(shù)據(jù)管理系統(tǒng)會對接數(shù)據(jù)建模工具、數(shù)據(jù)質(zhì)量管控系統(tǒng)、以及數(shù)據(jù)脫敏系統(tǒng)，最終提供給用戶一套前端的操作界面。

當(dāng)中比較關(guān)鍵的組件叫數(shù)據(jù)地圖，主要為整個銀行的數(shù)據(jù)資產(chǎn)目錄，它采集各個數(shù)據(jù)源的數(shù)據(jù)，通過 WeDataSphere 對數(shù)據(jù)進(jìn)行加工存儲，最后返回一份全行完整的數(shù)據(jù)資產(chǎn) / 數(shù)據(jù)字典。在這個過程中，大數(shù)據(jù)平臺構(gòu)建了數(shù)據(jù)治理的規(guī)范和要求。

這套數(shù)據(jù)系統(tǒng)降低了用戶使用門檻，直觀地告訴用戶數(shù)據(jù)在哪，如果某個用戶要審批數(shù)據(jù)，提交一個數(shù)據(jù)請求單便可提取他想要的數(shù)據(jù)，甚至在數(shù)據(jù)提取之前，系統(tǒng)告知用戶數(shù)據(jù)源是誰，可以找到誰要數(shù)據(jù)。這也體現(xiàn)了這套數(shù)據(jù)治理系統(tǒng)中數(shù)據(jù)血緣的能力：數(shù)據(jù)源是哪里，下游又是哪里。

上圖為數(shù)據(jù)治理系統(tǒng)的功能架構(gòu)，最下層為系統(tǒng)需要采集的數(shù)據(jù)，以及它對應(yīng)的數(shù)據(jù)存儲地方。在這個架構(gòu)中，大數(shù)據(jù)平臺采用 3 個底層存儲引擎：主要存儲元數(shù)據(jù)的 TiDB、存儲圖數(shù)據(jù)的 Nebula Graph、存儲索引數(shù)據(jù)的 ES。在底層存儲的上面，數(shù)據(jù)地圖提供了多個微服務(wù)提供給外部使用的請求接口。

下面講解下 WeDataSphere 數(shù)據(jù)治理系統(tǒng)中血緣數(shù)據(jù)的處理過程。我們通過各種組件 Hook 從 Hive、Spark、Sqoop 等任務(wù)腳本中解析輸入數(shù)據(jù)和輸出數(shù)據(jù)構(gòu)建血緣數(shù)據(jù)。例如：當(dāng)中的 Hive Hook 主要處理大數(shù)據(jù)平臺內(nèi)部的表與表之間的關(guān)系，我們通過 Hive 本身提供的 Lineage SDK 包裝了數(shù)據(jù)接口，構(gòu)建一個 Hook 去解析 SQL 語句的輸入數(shù)據(jù)和輸出數(shù)據(jù)，從而建立血緣關(guān)系記錄在 Log 中。Spark 類似，不過微眾銀行是自研 Spark 在 Drive 層的 Hook。Sqoop 這塊實現(xiàn)是基于 Sqoop 的 Patch 解析數(shù)據(jù)在 importer 和 exporter job 過程中提供的 Public Data，最終構(gòu)建關(guān)系型數(shù)據(jù)庫（比如：MySQL、Oracle、DB2）和大數(shù)據(jù)平臺 Hive 數(shù)據(jù)之間的流向關(guān)系。血緣數(shù)據(jù)生成之后寫入執(zhí)行節(jié)點(diǎn)，即 Driver 所在節(jié)點(diǎn)，從而形成 Lineage Log。

再用微眾銀行內(nèi)部的自動化運(yùn)維工具 AOMP 每日從各個節(jié)點(diǎn)導(dǎo)入數(shù)據(jù)存儲到 Hive ODS DB。在這個過程中，大數(shù)據(jù)平臺對 Hive 進(jìn)行 ETL 加工同現(xiàn)有數(shù)據(jù)進(jìn)行關(guān)聯(lián)分析得到導(dǎo)入圖數(shù)據(jù)庫的 DM 表。最后使用 Nebula Graph 提供的 Spark Writer 從 Hive 中將點(diǎn)和邊的數(shù)據(jù)寫入圖數(shù)據(jù)庫對應(yīng) Schema 中。

以上便是數(shù)據(jù)加工過程。

上圖為大數(shù)據(jù)平臺的整體數(shù)據(jù)模型，中間的 DATA 大表為 Hive 加工后的應(yīng)用表，將上面的點(diǎn)、邊信息寫入 Nebula Graph Schema 中，包括處理某個 SQL 語句的 job_id，數(shù)據(jù)源 src_db_id，數(shù)據(jù)下游 dst_db_id 等等數(shù)據(jù)信息。

相對而言上圖比「數(shù)據(jù)治理系統(tǒng)血緣圖模型設(shè)計 1/3」圖更直觀，Schema 左側(cè)為點(diǎn)，右側(cè)為邊，一個 job 對應(yīng)某個 SQL 語句或 Sqoop 任務(wù)。舉個例子，一個 SQL 語句會存在多個輸入表，最終寫入到一個輸出表，在圖結(jié)構(gòu)中呈現(xiàn)便是 job 入邊和 job 出邊，對應(yīng) source table 和 destination table。表和 DB 本身存在 Contain 關(guān)系，而微眾銀行基于自己的業(yè)務(wù)增加了表和表的直接 Join 關(guān)系，可查詢表和表之間關(guān)系，比如：一度關(guān)系。

上圖是一個數(shù)據(jù)過程，上面有個 db_id，比如：158364，通過一個 job_id，例如：0555261f733b4e90824343b19810a73d 構(gòu)建起了一個圖結(jié)構(gòu)。

這是數(shù)據(jù)治理的實時查詢和批量分析架構(gòu)，主要通過 ETL 加工血緣數(shù)據(jù)再寫入到數(shù)據(jù)存儲系統(tǒng)中。而上圖中的 Metadata Service 會根據(jù)實時分析需求通過 SDK 調(diào)用圖數(shù)據(jù)庫，將查詢的返回結(jié)果傳給前端做展示。

在應(yīng)用場景這塊，主要有兩個場景，一是實時查詢，以某個表為起始節(jié)點(diǎn)，遍歷上游和下游表，遍歷完成后在 UI 中展示。具體的技術(shù)實現(xiàn)是調(diào)用 Nebula Java Client 連接 Nebula Graph 查詢得到血緣關(guān)系。二是批量查詢，當(dāng)然批量查詢所需的血緣數(shù)據(jù)已構(gòu)建好并存儲在 Nebula Graph 中。針對批量查詢，這里舉個例子：有一個部門的表，在某個時刻處于出現(xiàn)異常，會影響一批表，要找到這個部門的表，首先我們得找到它到底影響了哪些下游表，把這個完整的鏈路追蹤出來后挨個確認(rèn)這些表是否修復(fù)。那么這時候就需要做批量查詢。具體技術(shù)實現(xiàn)是通過 Nebula Spark Connector 連接 Nebula Graph 批量將點(diǎn)和邊數(shù)據(jù)導(dǎo)入到 Spark 封裝為 DataFrame，再通過 GraphX 等圖算法批量分析得到完整的血緣鏈路。

上圖為 WeDataSphere 實時查詢界面，因為涉及到敏感信息打了個馬賽克，以上圖的藍(lán)色表為中心數(shù)據(jù)，查詢下游的一度關(guān)系表和上游的一度關(guān)系表，大數(shù)據(jù)平臺構(gòu)建圖數(shù)據(jù)庫數(shù)據(jù)模型時加入了時間屬性，可以查詢特定時間，比如：某張表昨天到今天的血緣關(guān)系，可基于時間維度進(jìn)行數(shù)據(jù)過濾和檢索。

以上，Nebula Graph 在 WeDataSphere 數(shù)據(jù)治理過程中的應(yīng)用情況介紹完畢。

在邸帥在演講《NebulaGraph - WeDataSphere 開源介紹》中，WeDataSphere 提供兩層數(shù)據(jù)連接和擴(kuò)展能力，前者是一站式數(shù)據(jù)業(yè)務(wù)開發(fā)管理套件 WeDataSphere，后者是計算中間件 Linkis 用于連接底層的基礎(chǔ)組件。而 Nebula Graph 也基于 WeDataSphere 這兩層功能同現(xiàn)有數(shù)據(jù)業(yè)務(wù)進(jìn)行結(jié)合，打通數(shù)據(jù)開發(fā)流程。

上圖為 WeDataSphere 一站式數(shù)據(jù)應(yīng)用開發(fā)管理門戶 Studio 的數(shù)據(jù)處理流程。上圖的 Exchangis 為數(shù)據(jù)交換系統(tǒng)，讀取不同異構(gòu)數(shù)據(jù)源的數(shù)據(jù)導(dǎo)到大數(shù)據(jù)平臺，再通過 Maskis 系統(tǒng)做前置脫敏，遮擋敏感數(shù)據(jù)或進(jìn)行 Hash 轉(zhuǎn)換提供給業(yè)務(wù)分析人員使用。這個系統(tǒng)中有一個 Online 寫 SQL 環(huán)境 Scriptis，相關(guān)研發(fā)人員可以寫些 SQL 分析語句做前置數(shù)據(jù)處理，然后數(shù)據(jù)傳輸給系統(tǒng)中的機(jī)器學(xué)習(xí)工具 Prophecis 做建模處理。最后，數(shù)據(jù)處理完成后交付給 Qualitis 系統(tǒng)做數(shù)據(jù)質(zhì)量校驗，得到安全、可靠數(shù)據(jù)之后再由可視化系統(tǒng) Visualis 進(jìn)行結(jié)果展示和分析，最終發(fā)送郵件給報表接收方。

上圖為用戶可感知的一個流程，但整個處理流程會使用到底層技術(shù)組件，在 WeDataSphere 內(nèi)部主要通過 Linkis 這個計算中間件去解決和底層組件連接、串聯(lián)問題。除此之外，Linkis 還提供了通用的多租戶隔離、分流、權(quán)限管控的能力?；?Linkis 這個計算中間件，大數(shù)據(jù)平臺實現(xiàn)了 Linkis Nebula Engine 圖分析引擎，和 WeDataSphere 現(xiàn)有的大數(shù)據(jù)處理流程結(jié)合。

現(xiàn)在來介紹下 Linkis 數(shù)據(jù)處理流程：

第一階段：一個任務(wù)在 DataSphere Studio 提交后，進(jìn)入上圖所示 Entrance，這個組件主要用于任務(wù)解析和參數(shù)接收。

第二個階段：也是一個關(guān)鍵的準(zhǔn)備階段，進(jìn)入 Orchestrator 模塊，在上面 PPT 的「同城業(yè)務(wù)數(shù)據(jù)雙寫」章節(jié)說過 Orchestrator 模塊實現(xiàn)編排、分流、回放、高可用。編排會將一個 Job 拆分成 N 個細(xì)小的 Task，而這些 Task 對應(yīng)的資源申請需要連接底層 Linkis Manager，Linkis Manager 會把 Task 分發(fā)、映射到對應(yīng)的執(zhí)行引擎做數(shù)據(jù)處理，最后，通過 EngineConn Manger 連接到對應(yīng)執(zhí)行引擎，可見和 Nebula Graph 進(jìn)行數(shù)據(jù)交互的主要是 EngineConn Manger。

第三個階段：執(zhí)行。

上面整個過程的實現(xiàn)邏輯是可復(fù)用的，做數(shù)據(jù)應(yīng)用接入時，只需建立中間件同底層引擎的連接，數(shù)據(jù)經(jīng)過 Orchestrator 模塊會自動分發(fā)到對應(yīng)的執(zhí)行引擎做數(shù)據(jù)處理。

數(shù)據(jù)加工處理流程如上所示，和 WeDataSphere 一站式數(shù)據(jù)應(yīng)用開發(fā)管理門戶 Studio 的數(shù)據(jù)處理流程類似：撈數(shù)據(jù) -> 大數(shù)據(jù)平臺 -> Qualitis 數(shù)據(jù)質(zhì)量校驗 -> 寫 SQL -> Hive / Spark 做復(fù)雜的數(shù)據(jù)加工處理，最終輸出之前進(jìn)行數(shù)據(jù)質(zhì)量校驗，通過 Nebula Graph 的 Spark Writer 寫到 Nebula。

這里，大數(shù)據(jù)平臺提供了一個 nGQL 編程界面，因為這時數(shù)據(jù)已寫入 Nebula Graph，進(jìn)入 nGQL 界面后執(zhí)行如下查詢語句：

USE nba;
GO FROM 100 OVER follow;

即可在界面返回圖數(shù)據(jù)庫 Nebula Graph 的查詢結(jié)果，同 Nebula Graph 官方提供的可視化工具 Studio 不同，WeDataSphere 的 nGQL 界面主要是處理數(shù)據(jù)流程的串聯(lián)問題，不涉及具體的可視化功能，后期微眾銀行大數(shù)據(jù)團(tuán)隊也會考慮和官方進(jìn)行可視化方面的合作。

最后一部分是未來展望，先來講下 WeDataSphere 這套圖數(shù)據(jù)庫系統(tǒng)在微眾銀行內(nèi)部的應(yīng)用，目前我們大數(shù)據(jù)平臺內(nèi)部主要是應(yīng)用 Nebula Graph 做血緣數(shù)據(jù)存儲和分析；其他業(yè)務(wù)部門也有實際應(yīng)用，例如：資管系統(tǒng)處理企業(yè)關(guān)系時有用到 Nebula；我們的 AIOPS 系統(tǒng)目前也在做這塊業(yè)務(wù)測試，主要是構(gòu)建運(yùn)維知識圖譜去實現(xiàn)故障的根因分析和解決方案發(fā)現(xiàn)；此外，我們的審計系統(tǒng)也在基于圖數(shù)據(jù)庫做知識圖譜構(gòu)建，相關(guān)部門目前在嘗試接入這套圖數(shù)據(jù)庫系統(tǒng)；我們風(fēng)控場景業(yè)務(wù)也已接入 WeDataSphere 圖數(shù)據(jù)庫系統(tǒng)進(jìn)行測試，接下來會有更多的業(yè)務(wù)方來做這一塊的嘗試。

未來的話，大數(shù)據(jù)平臺這邊會基于 Nebula Graph 2.0 開放的功能和架構(gòu)搭建更加自動化、更加穩(wěn)定的技術(shù)架構(gòu)，服務(wù)好更加關(guān)鍵的業(yè)務(wù)。

還有同 Nebula Graph 一起拓展圖分析這塊能力，接入到整個大數(shù)據(jù)平臺 WeDataSphere 這套數(shù)據(jù)處理流程中。

最后，最重要的，希望有更多合適的業(yè)務(wù)場景能夠接入到 WeDataSphere 這套圖數(shù)據(jù)處理的流程和系統(tǒng)中，以上是微眾銀行大數(shù)據(jù)平臺——周可的技術(shù)分享，謝謝。