本文為微眾銀行大資料平臺：周可在 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 這套圖資料處理的流程和系統中，以上是微眾銀行大資料平臺——周可的技術分享，謝謝。
喜歡這篇文章？來來來，給我們的 GitHub 點個 star 表鼓勵啦~~ ?♂️?♀️ [手動跪謝]
交流圖資料庫技術？歡迎報名參加 nMeetup 北京場，和 BOSS 直聘文洲大佬現場談笑風生，更有美團 NLP 技術大佬和你分享美團的圖資料庫技術實踐，以及知乎反作弊工程師和你聊 Nebula Graph 在知乎的應用。報名地址：nMeetup·北京場 ｜ 圖資料庫經驗之談