本⽂整理⾃ 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 天免費使用中，點擊鏈接來搭建自己的資產管理系統吧！