本⽂整理⾃ NebulaGraph x 阿⾥雲端計算巢專場中眾安保險的⼤資料應⽤⾼級專家曾⼒帶來的《眾安資產在 NebulaGraph 的應⽤實踐》分享，影片⻅連結。
⼤家好，我是眾安資料科學應⽤中⼼的曾⼒，今天很⾼興在這⾥可以跟⼤家分享 NebulaGraph 在眾安資產的實踐。
01 基於事件的資料資產平臺設計
在瞭解這⼀切之前，我們需要先知道什麼是資產管理平臺以及它可以解決什麼樣的問題。
資產管理平臺是全域的後設資料中⼼，它可以對資料資產進行管理監控，解決企業內部的資料孤島問題，挖掘資料價值並對業務賦能。它主要解決我們資料找不到、資料從哪⼉取，排查路徑⻓、資料復⽤率低這四個非常核⼼的關鍵問題。
設計目標
對於資產管理平臺，我們有三個⾮常重要的設計⽬標——
- 強擴充套件：是指實體關係定義、資產操作以及資產查詢的擴充套件性。
- 低耦合：是指資產平臺與其他系統對接時，對接入系統業務流程零影響。
- 高時效：是指需要近實時的資料採集、快速的資料處理和查詢效能。
核心功能
資料資產管理平臺核⼼功能包括以下三個：
- 型別定義：需提供⼀個抽象的設計定義不同的實體/關係，以及它們包含的屬性。每個定義的實體/關係均需要定義唯一性約束，用於資料判重。在此基礎上我們可以擴充套件一些定義型別，比如標籤、術語、標籤傳播等等。
- 後設資料採集：主要有透過週期性、流式和手工錄入三種方式進行資料採集。
- 後設資料管理：資料儲存常見的選型是關係型數庫儲存定義或資料，搜尋引擎儲存資料、變動記錄、統計類資訊，圖資料庫則負責關係查詢。資料分析常見的場景是資料地圖、血緣及影響性分析、全鏈路血緣分析。資料應用則是在相關資料採集到平臺後，可以快速實現資產割接、資料安全管理以及資料治理等更高層次應用需求。
型別定義
開源系統 Apache Atlas
借鑑於開源系統 Apache Atlas 和 DataHub，我們來初步瞭解型別定義設計的核心要素。
Atlas 的型別定義模式是一套基於 JSON 的 TypeSystem，可以自定義擴充套件，它的核心概念是實體、關係和屬性，並在此基礎上擴充套件出分類、術語、業務資料等定義設計。
DataHub 則採用 Avro 進行事件模型的定義、PEGASUS 建模語言進行實體、關係和屬性的建模，值得一提的是 Aspect 這個概念，其描述實體特定方面的屬性集合，同一實體關聯的的多個 Aspect 可以獨立更新，相同的 Aspect 也可以再多個實體間共享。DataHub 預置了一些實體和關係模型，我們可以複用這些模式或自定義新模型。
透過兩個開源系統的型別定義設計，我們不難看出實體、關係、屬性是後設資料系統當中最基礎的三個核心型別定義的元素。基於整體的架構、內部資料模型場景、資料儲存選型、學習成本等方面因素的考慮，眾安資料資產平臺的型別定義是參照 Apache Atlas 的 TypeSystem 設計，定義一套獨立的型別定義系統。
實體型別定義 EntityDef 的核心要素是型別名稱、父型別名稱和屬性列表。
對於型別名稱，需要單租戶下約束唯一；對於父型別名稱，其實就是對一些公共屬性集的複用，類似於 Java 類的繼承機制，我們可以透過獲取父型別及其超類的所有屬性。目前為方便型別解析，一個實體僅能定義一個父型別。對於屬性列表，一個實體可以有 1~n 個屬性，且至少有一個唯一性屬性。
關係定義 RelationshipDef 的核心要素是定義名稱、關係類別、起始/結束端點定義和屬性定義；
對於型別名稱，需要單租戶下約束唯一；對於關係類別，根據是否容器關係和端點實體生命週期分為三類。
- Association 關係：是一種非容器關係，比較典型的例子是排程作業的依賴關係，兩者之間不為包含關係，且生命週期獨立。
- Aggregation 關係：是一種容器關係，但端點實體的生命週期獨立，比如我們的報表系統，資料模型和畫布關係，畫布包含模型，但模型可以獨立於畫布而出存在，生命週期獨立。
- Composition 關係：是一種容器關係，且端點生命週期完全一致，最直觀的例子是表和列之間的包含關係，刪除表的時候列實體自動被刪除。
對於端點定義 RelationshipEndDef，端點即是實體關係中關係實體的對映，所以需要定義來源和目標兩個端點。每個端點定義需要端點的實體型別名稱以及是否為容器。如果關係類別是⼀個容器型別的關係的話，需要設定某⼀個端點容器標誌為 true，此時邊方向是子項實體指向容器實體。如果關係類別是非容器的關係的話，所有的端點容器標誌都需要設定為 false，此時邊方向是端點 1 實體指向端點 2 實體。
對於屬性列表來，一個關係可以有 0~n 個屬性。同實體屬性定義不同的是，關係定義可以不配置屬性定義。
屬性定義 AttributeDef 核心要素是名稱、型別、是否可選、是否唯一屬性、是否建立索引、預設值等內容。對於屬性型別，因 NebulaGraph 相簿支援的型別有限，僅支援基礎資料型別。是否支援索引建立，是指創 Nebula tag/edge schema 的時候，對於某個屬性是否建立一個 tag/edge 索引，以支援在特殊查詢場景下的資料查詢。
實體的判重是資產平臺型別定義的關鍵設計，我們首先看看開源產品的設計理念。
Atlas 型別定義系統當中，所有實體都繼承於⼀個⽗實體 Referenceable，它只有⼀個唯一屬性 QualifiedName，且被標記為了唯⼀的屬性。所有繼承於它的實體型別屬性中均沒有唯一屬性。QualifiedName 沒有用固定格式，在 Atlas 內建的幾個 Hook 中，主要格式為 xxx@meta-namespace。在 Hook 寫入時指定，上圖的例子就定義的是某個叢集、某個儲存卷在的唯一性標識。
DataHub 實體唯一性標誌是 URN，也叫作唯⼀屬性資源名稱。它有一定的生成規則，即 urn:<namspace>:<Entity Type>:<ID> 名稱空間預設設定為 li，類別則是實體定義名稱，ID 是指唯一屬性集合拼接，可以巢狀 URN，上圖的例子一個資料集，代表某個 Kafka 叢集下的 Topic。
基於兩個開源專案分析，不難看出唯一性判斷均是基於唯一屬性來處理，兩者均是在 Ingest 擴充套件中進行了固定格式的定義寫入，而不是基於實體定義中多個明確代表唯一屬性進行靈活的拼接處理，其拼接的欄位晦澀難以解析。
眾安設計了一套唯一性判斷定義方式，即某個實體註冊時，先判斷實體定義是否有 Composition 類別關係的邊定義引用。如果不存在該關係類別定義，則直接從實體定義的屬性定義中檢索 isUnique=true 的屬性。如果存在改關係類別定義，那當前實體的唯一性屬性將不足以約束其唯一性，還需要帶上邊定義的容器實體的唯一屬性才可以保證。這是一個遞迴的過程，可能需要傳入多個實體的唯一性屬性才可以判斷。比如註冊一個 MySQL 表，除了表實體的表名稱之外，還需要 MySQL 庫實體的 Host、埠、資料庫名稱等唯一屬性才是完整的為唯一屬性列表。
在獲取了唯一屬性列表後，還需要加上租戶和型別定義名稱，繼而生成某一租戶下對應的唯一實體標誌。
操作需要三個流程，首先需要把唯⼀性的屬性列表，根據其對應的型別名稱跟屬性名稱進行一次正序排序，然後對租戶、型別定義名稱、唯一屬性 key 進行一次正序排序，生成一個可讀性高的唯一名稱。其次，因唯一名稱可能較長，需要進行一次 32 位摘要後進行儲存，並加以索引進行查詢，可以提升整體查詢的有效性。最終全域性的資產唯一 ID，則是用 Snowflake 演算法生成的唯一 ID。因摘要演算法有效機率重複，故使用分散式 ID 生成演算法生成 ID，用於資料儲存。
資產採集
流式採集有非常好的優勢，可以透過訊息佇列，實現系統間解耦，實現資料的準實時上報，同時對事件訊息也有良好的擴充套件性。週期性採集是流式採集的⼀個補充，它包括兩種⽅式基於 ETL 或系統介面的主動推送，或類似資料發現系統的資料主動拉取。
對於以上兩種⽅式還沒有達成的採集，可以用過人工補錄的形式進行填寫，以支援注入對接系統無法支援上報或部分血緣無法解析等場景，提升資料完整度。
下面給大家介紹一下眾安後設資料系統⼏個版本採集流程的迭代——
V1.0 版本是完全基於 T+1 的離線 ETL，我們會把資料開發⼯作臺、排程系統以及阿⾥雲 MaxCompute 後設資料載入到數倉後，透過 ETL 處理推送到後設資料平臺，因資料量不大一個支援遞迴的關係型資料庫即可滿足要求。若資料量較大，則可以透過搜尋引擎和圖資料庫進行擴充套件。
隨著業務的發展，資料開發對於後設資料的時效性要求會越來越高，比如分析師建立的臨時資料想 T0 就直接分享給其他部門使用，以及後設資料整體數量越來越大，處理耗時較長，獲取的時間越來越晚。
基於以上需求，我們在後設資料平臺開了⼀層 API，在資料開發工作臺進行表操作時，或排程系統建立排程任務時，會呼叫介面將資料同步給後設資料平臺。同時晚上我們依然會有離線的 ETL 進行資料補充，兩者結合起來進行資料來源的資料查詢服務。
介面模式也會有一定的弊端，在各個對接的業務系統中，會有大量的同步巢狀流程，後設資料服務不可用或執行時間過長，例如系統發版時的業務中斷，建立一個數百列的表引發的介面超時等，均會影響正常業務流程。
於是我們參考各類開源後設資料平臺設計思路，設計了基於流式事件的後設資料平臺，基於不同的事件，對接系統透過訊息佇列上報後，實現系統間解耦。資產平臺基於不同事件進行分類處理，並將最終的資料儲存到搜尋引擎、關係型資料庫，以及圖資料庫當中。
平臺架構
下⾯給⼤家介紹⼀下眾安資料資產平臺的架構，我們將平臺分為了 5 個子系統。
- Portal 服務對接前端，提供通用的實體頁面佈局配置介面，實現配置化的頁面佈局。同時轉發請求到 Core Service 進行處理，比如查詢、型別定義等。
- Discovery 服務主要就是週期性的採集服務，透過配置定時的採集任務，並實現後設資料的定時採集。
- 系統 SDK 所有服務對接資產平臺，均需要透過 SDK 進行對接，包括 Discovery 服務、資料超市、報表平臺、開發⼯作臺、資料標籤平臺等，SDK 提供了統一的事件拼裝、許可權管理、事件推送等功能，可以極大的提升平臺間互動的開發效率。
- Event 服務負責消費訊息佇列中的訊息，進行事件的解析和資料持久化。
- Core 服務提供統一的查詢 API、標籤 API 以及型別定義的 API 來實現查詢跟型別定義的管理。
同時我們提供了統一的資料儲存層模組 Repo，來實現查詢器和統一資料處理器的相關處理，其內部提供了資料庫及相簿的擴充套件 SPI，以便實現相關擴充套件。
我們將資產平臺的事件抽象為以下三種：
- 後設資料事件 MetadataEvent，包括實體/關係的增刪改查等子事件。
- 後設資料異常事件 FailMetadataEvent，在處理 MetadataEvent 時失敗了，比如型別定義不存在或事件順序有問題，我們會統一生成一個後設資料異常失敗事件，可以基於此事件做異常資料落庫或告警通知。
- 平臺事件 PlatformEvent，包括使用後設資料平臺觸發的埋點事件，包括實體的收藏、查詢、使用以及安全分級等事件，其中一部分會做按天級別的統計處理，以便在平臺上可以看到類似的統計資訊。
事件進⾏處理，需要關注以下三點：
- 分而治之，因為整體的事件的資料量會⽐較多，為了保證效能需要按照 Event 類別和影響，使⽤不同的訊息佇列。對於我們剛才介紹的三種型的事件，我們實際使用了三個 Kafka Topic 進行訊息推送。
- 訊息的順序，對於後設資料相關事件，訊息消費需要嚴格保證有序，如何來保證有序呢？我們⽬前採⽤的⽅案是由 Kafka Topic 單分割槽模式來解決的，為什麼不⽤多 Partition 呢？因為實體跟關係之間的註冊有可能是會分到不同的 Partition 上來進⾏處理的，因為非同步消費處理有可能不同分割槽的資料產生消費堆積，有機率出現不同的分割槽，消費註冊事件先到，實體註冊事件後到的情況，導致廢訊息的出現。
- 最終一致性，因為事件 Event 的非同步處理，我們只能保證資料的最終⼀致性。
好，那講完了事件的消費流程，我們下⾯就要來看資料持久化的流程。我們的資料事件從訊息佇列拿到之後，會被我們的事件服務 Event Service 所消費，Event Service 中的事件處理器在消費資料的時候會⽴刻對這個資料進⾏⼀份資料的儲存，它會存到關係型資料庫⾥⾯，作為⼀個審計的回溯⽇志。
在儲存完回覆⽇志之後，事件處理器就會開始對事件進⾏處理，如果事件處理異常的話，根據特定的這種事件型別，我們會有選擇的把⼀些異常的事件放到異常事件的訊息佇列⾥⾯，然後供下游的系統進⾏訂閱通知，或者是做內部後期的問題排查。
如果事件處理成功了之後，我們會把資料丟到聯合資料處理器當中。那聯合資料處理器內部其實就是我們對關係型資料庫以及相簿的資料進⾏了⼀個整體的事務的包裹，以便兩者之間出現失敗的時候，可以對資料內容進⾏回滾。
那在資料持久化當中，我們的關係型資料庫跟相簿當中分別儲存了什麼內容呢？像關係型資料庫當中，我們往往儲存了實體跟關係的資料，包括屬性跟這種實際的這種名稱的⼀些定義，同時還儲存了實體的統計類的資訊⽤於分析，還有型別定義的資料⽤於各種各樣資料的這樣⼀種校驗。那相簿當中主要就是點邊的這種關係⽤於圖譜的查詢。
資產的查詢分析整合於 Core Service 模組中，目前有兩大場景分類，資料地圖和血緣分析。
資料地圖類檢索，一般是分查詢，我們定義一套類似於 ES DSL 風格的查詢介面請求，透過查詢解析器，翻譯成要查詢的關係型資料庫語句，目前因為資料量還在PG的承受範圍內，我們並沒有使用 ES。同時使用、收藏、查詢的統計類記錄和變動記錄，也是存放於 PG 當中，透過指定介面查詢。
血緣分析類查詢，一般是關係查詢，我們也透過類似於 ES DSL 風格的查詢介面請求，透過查詢解析器，翻譯成圖資料庫所識別的 nGQL 或 Cypher 語句，包括 N 跳關係查詢、子圖查詢、屬性查詢等。
對於⼀些特殊場景查詢需求，比如資料大盤，或特定實體的擴充套件事件，我們透過或定製化查詢的方式進行處理。
02 NebulaGraph 在眾安資產平臺的實踐
圖資料庫選型
我們在做⾃主化平臺開發之前，對熱門開源專案的圖資料庫選型做了調研。
選型主要考慮兩⽅⾯的因素，資料庫架構和資產平臺設計的匹配性。
在架構因素⽅⾯，核心因素是讀寫效能、分散式擴充套件、事務支援和第三方依賴。對於 Neo4j 來說，雖然它的效能讀寫效能⾮常優越和原⽣儲存，但是因為 3.x 版本之後，社群版已經不再⽀持分散式模式，所以說肯定不能達到我們預期的要求。JanusGraph 和 NebulaGraph 均支援分散式擴充套件和存算分離架構，但前者的儲存、索引均依賴於第三方元件，帶來大量額外運維工作，其支援分散式事務，而 NebulaGraph 不支援分散式事務處理。
資產平臺設計的匹配性因素，核心因素是資料隔離、屬性及 Schema 數量上線、屬性型別、查詢語言等。
JanusGraph/Neo4j 社群版屬性集均不支援強 Schema，這意味著更靈活的屬性配置。同時，屬性型別也支援諸如 map、set 等複雜型別。NebulaGraph 屬性集雖然有強 Schema 依賴，但屬性和 Schema 數量沒有上限，也支援 Schema 的修改，唯一美中不足的是不支援 map/set 等複雜型別屬性，這將對型別定義和系統設計有一定的影響，以及對潛在的需求場景有一定的約束。三種資料庫均有通用的查詢語言、以及可以基於 GraphX 進行圖演算法分析。
為什麼選擇 NebulaGraph
基於以下四點的考慮，眾安選擇了 NebulaGraph——
第⼀是分散式的存算分離架構，可以以最優的成本，快速擴縮容相關服務。
第二是外部元件依賴較少，⽅便運維。
第三是卓越的讀寫效能，在19 年年底眾安金融風控場景，我們對 NebulaGraph 就進⾏了⼀定的效能測試，我們在純 nGQL的 insert 這種寫入方案下，透過 DataX 可以實現 300w record/s 的資料寫⼊速度，這個是一個非常驚人的資料同步的體驗。
第四是資料儲存格式，因為眾安有大量的子公司租戶，需要進行資料的儲存隔離，如果是其他產品就需要部署多套相簿，或一套相簿資料裡打租戶標籤。NebulaGraph可以使用圖空間的方式實現天然的資料隔離，大大簡化了我們開發的工作量。
NebulaGraph 阿⾥雲部署模式
因為眾安沒有獨立機房，所有的服務均依賴於阿里雲金融雲，基於阿⾥雲 ECS 的能力，可以快速實現伺服器以及伺服器上儲存資源的彈性擴收容。實際部署中，我們將 graphd 跟 mated、 storaged 進行了分開部署，避免大量查詢導致記憶體過高，影響到其他圖資料服務的穩定性。
graphd 佔用了 2 臺 4C 8G 伺服器，metad/storaged 佔用了 3 臺 4C 16G 伺服器。當前資產平臺的實體數量在 2,500w 個左右，邊資料在 4左右，主要為資料集型別資料。
我們使用每臺 ECS 使用了兩塊 200G 的 ESSD 進行儲存，根據 NebulaGraph 的推薦，磁碟的數量越多，圖空間 Partition 的擴充套件的數量就可以越多，可以獲得更好的併發處理能力。
眾安在NebulaGraph中的模型設計
下面介紹一下基於 NebulaGraph 的模型設計。
對於實體定義來說，對應 NebulaGraph 的某一個 Tag，其相對於其他圖資料庫類似於 Label 概念，就是某個屬性集的名稱，透過 Tag 可以更快檢索倒到某一個實體點下的屬性，型別定義的 Tag 必須同這一型別的點 ID 進行強繫結，註冊時需要進行相關校驗。另一個屬性集的概念是公共標籤，公共標籤可以做很多事情，比如業務屬性集、實體標籤等。公共標籤在 NebulaGraph 當中也對應一個 Tag，這個 Tag 可以繫結到多種不同的實體，比如環境公共標籤，可以賦給 MySQL 資料來源實體，也可以賦給 MaxCompute資料來源實體等。
對於關係定義來說，對應 NebulaGraph 中的某個 Edge Type，型別定義中的來源目標端點的實體型別，必須同這一型別的點 ID 進行強繫結，註冊時需要進行相關校驗。
對於資料隔離來說，上述實體和關係模型，透過 NebulaGraph 的圖空間進行隔離，在眾安內部的多個租戶實體下，比如保險、小貸、科技等，會在租戶初始化時建立指定圖空間，後續的型別定義均在租戶圖空間下進行。
最後我們再來看⼀下模型設計的繼承關係。我們所有的實體根節點是⼀個叫做 Asset 的實體定義，我們將一些公共屬性定義其中，包括名稱、展示名稱、備註、型別等；
基於 Asset 型別，我們實現了對接平臺的各種資產實體，報表平臺裡的模型、檢視、畫布、⻔戶等實體，資料超市裡的路由 API、資料 API 以及外部擴充套件 API 等實體，開發工臺裡的排程任務、流計算任務、工作空間、檔案等實體，以及兩個比較特殊的資產屬主實體和服務資產實體。
另一個特殊的實體是資料集實體，我們將不同資料來源資料來源、表、列等資訊均定義了獨立的資產實體定義，以便實現不同資料來源的差異化屬性展示。
我們最終的全鏈路資料資產，均是透過資料集及其子類自定義實現串聯，從而實現跨平臺的鏈路分析。比如排程作業的庫表血緣，可以關聯到報表平臺的資料模型，也可以關聯到數倉的 Data API 依賴的 Table Store 的某張表等等。
03 未來展望
2022年年底，眾安基本上已經實現了各個平臺的各種資產的註冊跟上報的過程。
2023年，我們將在圍繞資料資產割接、資料安全管理和資料治理三個方面進行擴充套件性開發。
- 資料資產割接，將站在使用者實體的角度上，快速識別個人關聯的資料資產，時間屬主資產切換和離職交接功能。
- 資料安全管理，基於資產平臺的能力做出多種擴充套件，遷移內部老後設資料系統的表分級、許可權審批功能；內部脫敏規則配置平臺及 SDK，擴充套件支援基於表分級資料加密和白名單策略等。
- 資料治理，基於資產平臺的全鏈路血緣分析能力，觀察資產熱度、使用等關鍵指標，清理無效作業和重複計算作業，實現降本增效，減少雲平臺使用費用。
要來感受同眾安科技一樣的圖資料庫體驗嘛？NebulaGraph 阿里雲端計算巢現 30 天免費使用中，點選連結來搭建自己的資產管理系統吧！