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

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

先來說下圖數據庫應用背景。

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

當時用這套系統處理的數據量大概是每天 60 萬個點，百萬級的邊，差不多一天要花 5 個小時左右才能完成寫入。這就導致業務方需要使用血緣數據時，大數據平臺不能及時提供。

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

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

微眾銀行的圖數據庫選擇還有一個重量考核點，高可用和容災的架構支持。這個考核項，Nebula Graph 本身的架構存在一定優勢，符合微眾銀行行內硬性的架構要求和規范。加上大數據平臺本身旨在構建一個完整的數據流生態，Nebula Graph 提供了一些大數據相關開源組件，比如：Connector，Exchange，這些工具能很好地同大數據平臺進行結合。

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

OK，下面來講解下 WeDataSphere 架構，主要集中在架構設計中所考慮的點。

上圖和大多數應用的層級劃分類似，從上往下看，應用層產生數據，通過數據交換層的各種工具，同底層的圖數據庫系統交換數據。應用場景方面這里不作詳細介紹，在本文后面會詳細地講解金融行業的應用情況。

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

服務監控模塊，微眾銀行大數據平臺內部使用 Zabbix 監控，通過寫腳本調用 Metric HTTP 接口，將監控指標傳輸到 Managis Monitor (Zabbix) 系統中。

總體的架構如上圖所示，從上至下的 4 層架構體系。

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

后期，基于大數據平臺開源的解決方案 Linkis 提供的 Orchestrator 模塊實現編排、回放、高可用。業務端無需了解具體的技術實現細節，通過調用大數據平臺的 SDK 接入 Linkis 的 Orchestrator 解決方案實現高可用和數據的雙讀雙寫功能。目前這塊功能尚在開發中，會在近期開源。

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

下面來介紹下 Nebula Graph 在大數據平臺 WeDataSphere 數據治理系統中的應用。

先簡單地介紹一下 WeDataSphere 數據治理系統，它包括 數據建模工具 元數據管理系統 數據脫敏系統 數據質量管理系統

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

當中比較關鍵的組件叫數據地圖，主要為整個銀行的數據資產目錄，它采集各個數據源的數據，通過 WeDataSphere 對數據進行加工存儲，最后返回一份全行完整的數據資產 / 數據字典。在這個過程中，大數據平臺構建了數據治理的規范和要求。

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

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

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

再用微眾銀行內部的自動化運維工具 AOMP 每日從各個節點導入數據存儲到 Hive ODS DB。在這個過程中，大數據平臺對 Hive 進行 ETL 加工同現有數據進行關聯分析得到導入圖數據庫的 DM 表。最后使用 Nebula Graph 提供的 Spark Writer 從 Hive 中將點和邊的數據寫入圖數據庫對應 Schema 中。

以上便是數據加工過程。

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

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

上圖是一個數據過程，上面有個 db_id，比如：158364，通過一個 job_id，例如：0555261f733b4e90824343b19810a73d 構建起了一個圖結構。

這是數據治理的實時查詢和批量分析架構，主要通過 ETL 加工血緣數據再寫入到數據存儲系統中。而上圖中的 Metadata Service 會根據實時分析需求通過 SDK 調用圖數據庫，將查詢的返回結果傳給前端做展示。

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

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

以上，Nebula Graph 在 WeDataSphere 數據治理過程中的應用情況介紹完畢。

在邸帥在演講《NebulaGraph - WeDataSphere 開源介紹》中，WeDataSphere 提供兩層數據連接和擴展能力，前者是一站式數據業務開發管理套件 WeDataSphere，后者是計算中間件 Linkis 用于連接底層的基礎組件。而 Nebula Graph 也基于 WeDataSphere 這兩層功能同現有數據業務進行結合，打通數據開發流程。

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

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

現在來介紹下 Linkis 數據處理流程：

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

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

第三個階段：執行。

上面整個過程的實現邏輯是可復用的，做數據應用接入時，只需建立中間件同底層引擎的連接，數據經過 Orchestrator 模塊會自動分發到對應的執行引擎做數據處理。

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

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

USE nba;
GO FROM 100 OVER follow;

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

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

未來的話，大數據平臺這邊會基于 Nebula Graph 2.0 開放的功能和架構搭建更加自動化、更加穩定的技術架構，服務好更加關鍵的業務。

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

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