本?整理? 悅數(shù)圖數(shù)據(jù)庫 x 阿?云計(jì)算巢專場中眾安保險(xiǎn)的?數(shù)據(jù)應(yīng)??級專家曾?帶來的分享，視頻? 鏈接,。

?家好,，我是眾安數(shù)據(jù)科學(xué)應(yīng)?中?的曾?，今天很?興在這?可以跟?家分享悅數(shù)圖數(shù)據(jù)庫在眾安資產(chǎn)的實(shí)踐,。

01 基于事件的數(shù)據(jù)資產(chǎn)平臺設(shè)計(jì)

在了解這?切之前,，我們需要先知道什么是資產(chǎn)管理平臺以及它可以解決什么樣的問題。

資產(chǎn)管理平臺是全域的元數(shù)據(jù)中?,，它可以對數(shù)據(jù)資產(chǎn)進(jìn)行管理監(jiān)控,，解決企業(yè)內(nèi)部的數(shù)據(jù)孤島問題，挖掘數(shù)據(jù)價(jià)值并對業(yè)務(wù)賦能,。它主要解決我們數(shù)據(jù)找不到,、數(shù)據(jù)從哪?取，排查路徑?,、數(shù)據(jù)復(fù)?率低這四個(gè)非常核?的關(guān)鍵問題,。

設(shè)計(jì)目標(biāo)

對于資產(chǎn)管理平臺,，我們有三個(gè)?常重要的設(shè)計(jì)?標(biāo)——

• 強(qiáng)擴(kuò)展：是指實(shí)體關(guān)系定義、資產(chǎn)操作以及資產(chǎn)查詢的擴(kuò)展性,。
• 低耦合：是指資產(chǎn)平臺與其他系統(tǒng)對接時(shí),，對接入系統(tǒng)業(yè)務(wù)流程零影響。
• 高時(shí)效：是指需要近實(shí)時(shí)的數(shù)據(jù)采集,、快速的數(shù)據(jù)處理和查詢性能,。

核心功能

數(shù)據(jù)資產(chǎn)管理平臺核?功能包括以下三個(gè)：

• 類型定義：需提供?個(gè)抽象的設(shè)計(jì)定義不同的實(shí)體/關(guān)系，以及它們包含的屬性,。每個(gè)定義的實(shí)體/關(guān)系均需要定義唯一性約束,，用于數(shù)據(jù)判重。在此基礎(chǔ)上我們可以擴(kuò)展一些定義類型,，比如標(biāo)簽,、術(shù)語、標(biāo)簽傳播等等,。
• 元數(shù)據(jù)采集：主要有通過周期性,、流式和手工錄入三種方式進(jìn)行數(shù)據(jù)采集。
• 元數(shù)據(jù)管理：數(shù)據(jù)存儲常見的選型是關(guān)系型數(shù)庫存儲定義或數(shù)據(jù),，搜索引擎存儲數(shù)據(jù),、變動記錄、統(tǒng)計(jì)類信息,，圖數(shù)據(jù)庫則負(fù)責(zé)關(guān)系查詢。數(shù)據(jù)分析常見的場景是數(shù)據(jù)地圖,、血緣及影響性分析,、全鏈路血緣分析。數(shù)據(jù)應(yīng)用則是在相關(guān)數(shù)據(jù)采集到平臺后,，可以快速實(shí)現(xiàn)資產(chǎn)割接,、數(shù)據(jù)安全管理以及數(shù)據(jù)治理等更高層次應(yīng)用需求。

類型定義

借鑒于開源系統(tǒng) Apache Atlas 和 DataHub,，我們來初步了解類型定義設(shè)計(jì)的核心要素,。

Atlas 的類型定義模式是一套基于 JSON 的 TypeSystem，可以自定義擴(kuò)展,，它的核心概念是實(shí)體,、關(guān)系和屬性，并在此基礎(chǔ)上擴(kuò)展出分類,、術(shù)語,、業(yè)務(wù)數(shù)據(jù)等定義設(shè)計(jì)。

DataHub 則采用 Avro 進(jìn)行事件模型的定義,、PEGASUS 建模語言進(jìn)行實(shí)體,、關(guān)系和屬性的建模，值得一提的是 Aspect 這個(gè)概念，其描述實(shí)體特定方面的屬性集合,，同一實(shí)體關(guān)聯(lián)的的多個(gè) Aspect 可以獨(dú)立更新,，相同的 Aspect 也可以再多個(gè)實(shí)體間共享。DataHub 預(yù)置了一些實(shí)體和關(guān)系模型,，我們可以復(fù)用這些模式或自定義新模型,。

通過兩個(gè)開源系統(tǒng)的類型定義設(shè)計(jì)，我們不難看出實(shí)體,、關(guān)系,、屬性是元數(shù)據(jù)系統(tǒng)當(dāng)中最基礎(chǔ)的三個(gè)核心類型定義的元素?；谡w的架構(gòu),、內(nèi)部數(shù)據(jù)模型場景、數(shù)據(jù)存儲選型,、學(xué)習(xí)成本等方面因素的考慮,，眾安數(shù)據(jù)資產(chǎn)平臺的類型定義是參照 Apache Atlas 的 TypeSystem 設(shè)計(jì)，定義一套獨(dú)立的類型定義系統(tǒng),。

實(shí)體類型定義 EntityDef 的核心要素是類型名稱,、父類型名稱和屬性列表。

對于類型名稱,，需要單租戶下約束唯一,；對于父類型名稱，其實(shí)就是對一些公共屬性集的復(fù)用,，類似于 Java 類的繼承機(jī)制,，我們可以通過獲取父類型及其超類的所有屬性。目前為方便類型解析,，一個(gè)實(shí)體僅能定義一個(gè)父類型,。對于屬性列表，一個(gè)實(shí)體可以有 1~n 個(gè)屬性,，且至少有一個(gè)唯一性屬性,。

關(guān)系定義 RelationshipDef 的核心要素是定義名稱、關(guān)系類別,、起始/結(jié)束端點(diǎn)定義和屬性定義,；

對于類型名稱，需要單租戶下約束唯一,；對于關(guān)系類別,，根據(jù)是否容器關(guān)系和端點(diǎn)實(shí)體生命周期分為三類。

• Association 關(guān)系：是一種非容器關(guān)系,，比較典型的例子是調(diào)度作業(yè)的依賴關(guān)系,，兩者之間不為包含關(guān)系,，且生命周期獨(dú)立。
• Aggregation 關(guān)系：是一種容器關(guān)系,，但端點(diǎn)實(shí)體的生命周期獨(dú)立,，比如我們的報(bào)表系統(tǒng)，數(shù)據(jù)模型和畫布關(guān)系,，畫布包含模型,，但模型可以獨(dú)立于畫布而出存在，生命周期獨(dú)立,。
• Composition 關(guān)系：是一種容器關(guān)系,，且端點(diǎn)生命周期完全一致，最直觀的例子是表和列之間的包含關(guān)系,，刪除表的時(shí)候列實(shí)體自動被刪除,。

對于端點(diǎn)定義 RelationshipEndDef，端點(diǎn)即是實(shí)體關(guān)系中關(guān)系實(shí)體的映射,，所以需要定義來源和目標(biāo)兩個(gè)端點(diǎn),。每個(gè)端點(diǎn)定義需要端點(diǎn)的實(shí)體類型名稱以及是否為容器。如果關(guān)系類別是?個(gè)容器類型的關(guān)系的話,，需要設(shè)置某?個(gè)端點(diǎn)容器標(biāo)志為 true,，此時(shí)邊方向是子項(xiàng)實(shí)體指向容器實(shí)體。如果關(guān)系類別是非容器的關(guān)系的話,，所有的端點(diǎn)容器標(biāo)志都需要設(shè)置為 false,，此時(shí)邊方向是端點(diǎn) 1 實(shí)體指向端點(diǎn) 2 實(shí)體。

對于屬性列表來,，一個(gè)關(guān)系可以有 0~n 個(gè)屬性,。同實(shí)體屬性定義不同的是，關(guān)系定義可以不配置屬性定義,。

屬性定義 AttributeDef 核心要素是名稱、類型,、是否可選,、是否唯一屬性、是否創(chuàng)建索引,、默認(rèn)值等內(nèi)容,。對于屬性類型，因 NebulaGraph 圖庫支持的類型有限,，僅支持基礎(chǔ)數(shù)據(jù)類型,。是否支持索引創(chuàng)建，是指創(chuàng) Nebula tag/edge schema 的時(shí)候,，對于某個(gè)屬性是否創(chuàng)建一個(gè) tag/edge 索引,，以支持在特殊查詢場景下的數(shù)據(jù)查詢,。

實(shí)體的判重是資產(chǎn)平臺類型定義的關(guān)鍵設(shè)計(jì)，我們首先看看開源產(chǎn)品的設(shè)計(jì)理念,。

Atlas 類型定義系統(tǒng)當(dāng)中,，所有實(shí)體都繼承于?個(gè)?實(shí)體 Referenceable，它只有?個(gè)唯一屬性 QualifiedName,，且被標(biāo)記為了唯?的屬性,。所有繼承于它的實(shí)體類型屬性中均沒有唯一屬性。QualifiedName 沒有用固定格式,，在 Atlas 內(nèi)置的幾個(gè) Hook 中,，主要格式為 xxx@meta-namespace。在 Hook 寫入時(shí)指定,，上圖的例子就定義的是某個(gè)集群,、某個(gè)存儲卷在的唯一性標(biāo)識。

DataHub 實(shí)體唯一性標(biāo)志是 URN,，也叫作唯?屬性資源名稱,。它有一定的生成規(guī)則，即 urn:<namspace>:<Entity Type>:<ID> 命名空間默認(rèn)設(shè)置為 li,，類別則是實(shí)體定義名稱,，ID 是指唯一屬性集合拼接，可以嵌套 URN,，上圖的例子一個(gè)數(shù)據(jù)集,，代表某個(gè) Kafka 集群下的 Topic。

基于兩個(gè)開源項(xiàng)目分析,，不難看出唯一性判斷均是基于唯一屬性來處理,，兩者均是在 Ingest 擴(kuò)展中進(jìn)行了固定格式的定義寫入，而不是基于實(shí)體定義中多個(gè)明確代表唯一屬性進(jìn)行靈活的拼接處理,，其拼接的字段晦澀難以解析,。

眾安設(shè)計(jì)了一套唯一性判斷定義方式，即某個(gè)實(shí)體注冊時(shí),，先判斷實(shí)體定義是否有 Composition 類別關(guān)系的邊定義引用,。如果不存在該關(guān)系類別定義，則直接從實(shí)體定義的屬性定義中檢索 isUnique=true 的屬性,。如果存在改關(guān)系類別定義,，那當(dāng)前實(shí)體的唯一性屬性將不足以約束其唯一性，還需要帶上邊定義的容器實(shí)體的唯一屬性才可以保證,。這是一個(gè)遞歸的過程,，可能需要傳入多個(gè)實(shí)體的唯一性屬性才可以判斷。比如注冊一個(gè) MySQL 表,，除了表實(shí)體的表名稱之外,，還需要 MySQL 庫實(shí)體的 Host,、端口、數(shù)據(jù)庫名稱等唯一屬性才是完整的為唯一屬性列表,。

在獲取了唯一屬性列表后,，還需要加上租戶和類型定義名稱，繼而生成某一租戶下對應(yīng)的唯一實(shí)體標(biāo)志,。

操作需要三個(gè)流程,，首先需要把唯?性的屬性列表，根據(jù)其對應(yīng)的類型名稱跟屬性名稱進(jìn)行一次正序排序,，然后對租戶,、類型定義名稱、唯一屬性 key 進(jìn)行一次正序排序,，生成一個(gè)可讀性高的唯一名稱,。其次，因唯一名稱可能較長,，需要進(jìn)行一次 32 位摘要后進(jìn)行存儲,，并加以索引進(jìn)行查詢，可以提升整體查詢的有效性,。最終全局的資產(chǎn)唯一 ID,，則是用 Snowflake 算法生成的唯一 ID。因摘要算法有效概率重復(fù),，故使用分布式 ID 生成算法生成 ID,，用于數(shù)據(jù)存儲。

資產(chǎn)采集

流式采集有非常好的優(yōu)勢,，可以通過消息隊(duì)列,，實(shí)現(xiàn)系統(tǒng)間解耦，實(shí)現(xiàn)數(shù)據(jù)的準(zhǔn)實(shí)時(shí)上報(bào),，同時(shí)對事件消息也有良好的擴(kuò)展性,。周期性采集是流式采集的?個(gè)補(bǔ)充，它包括兩種?式基于 ETL 或系統(tǒng)接口的主動推送,，或類似數(shù)據(jù)發(fā)現(xiàn)系統(tǒng)的數(shù)據(jù)主動拉取,。

對于以上兩種?式還沒有達(dá)成的采集，可以用過人工補(bǔ)錄的形式進(jìn)行填寫,，以支持注入對接系統(tǒng)無法支持上報(bào)或部分血緣無法解析等場景，提升數(shù)據(jù)完整度,。

下面給大家介紹一下眾安元數(shù)據(jù)系統(tǒng)?個(gè)版本采集流程的迭代——

V1.0 版本是完全基于 T+1 的離線 ETL,，我們會把數(shù)據(jù)開發(fā)?作臺、調(diào)度系統(tǒng)以及阿?云 MaxCompute 元數(shù)據(jù)加載到數(shù)倉后,，通過 ETL 處理推送到元數(shù)據(jù)平臺,，因數(shù)據(jù)量不大一個(gè)支持遞歸的關(guān)系型數(shù)據(jù)庫即可滿足要求,。若數(shù)據(jù)量較大，則可以通過搜索引擎和圖數(shù)據(jù)庫進(jìn)行擴(kuò)展,。

隨著業(yè)務(wù)的發(fā)展,，數(shù)據(jù)開發(fā)對于元數(shù)據(jù)的時(shí)效性要求會越來越高，比如分析師創(chuàng)建的臨時(shí)數(shù)據(jù)想 T0 就直接分享給其他部門使用,，以及元數(shù)據(jù)整體數(shù)量越來越大,，處理耗時(shí)較長，獲取的時(shí)間越來越晚,。

基于以上需求,，我們在元數(shù)據(jù)平臺開了?層 API，在數(shù)據(jù)開發(fā)工作臺進(jìn)行表操作時(shí),，或調(diào)度系統(tǒng)創(chuàng)建調(diào)度任務(wù)時(shí),，會調(diào)用接口將數(shù)據(jù)同步給元數(shù)據(jù)平臺。同時(shí)晚上我們依然會有離線的 ETL 進(jìn)行數(shù)據(jù)補(bǔ)充,，兩者結(jié)合起來進(jìn)行數(shù)據(jù)源的數(shù)據(jù)查詢服務(wù),。

接口模式也會有一定的弊端，在各個(gè)對接的業(yè)務(wù)系統(tǒng)中,，會有大量的同步嵌套流程,，元數(shù)據(jù)服務(wù)不可用或執(zhí)行時(shí)間過長，例如系統(tǒng)發(fā)版時(shí)的業(yè)務(wù)中斷,，創(chuàng)建一個(gè)數(shù)百列的表引發(fā)的接口超時(shí)等,，均會影響正常業(yè)務(wù)流程。

于是我們參考各類開源元數(shù)據(jù)平臺設(shè)計(jì)思路,，設(shè)計(jì)了基于流式事件的元數(shù)據(jù)平臺,，基于不同的事件，對接系統(tǒng)通過消息隊(duì)列上報(bào)后,，實(shí)現(xiàn)系統(tǒng)間解耦,。資產(chǎn)平臺基于不同事件進(jìn)行分類處理，并將最終的數(shù)據(jù)存儲到搜索引擎,、關(guān)系型數(shù)據(jù)庫,，以及圖數(shù)據(jù)庫當(dāng)中。

平臺架構(gòu)

下?給?家介紹?下眾安數(shù)據(jù)資產(chǎn)平臺的架構(gòu),，我們將平臺分為了 5 個(gè)子系統(tǒng),。

• Portal 服務(wù)對接前端，提供通用的實(shí)體頁面布局配置接口,，實(shí)現(xiàn)配置化的頁面布局。同時(shí)轉(zhuǎn)發(fā)請求到 Core Service 進(jìn)行處理,，比如查詢、類型定義等,。
• Discovery 服務(wù)主要就是周期性的采集服務(wù),，通過配置定時(shí)的采集任務(wù)，并實(shí)現(xiàn)元數(shù)據(jù)的定時(shí)采集,。
• 系統(tǒng) SDK 所有服務(wù)對接資產(chǎn)平臺，均需要通過 SDK 進(jìn)行對接,，包括 Discovery 服務(wù),、數(shù)據(jù)超市,、報(bào)表平臺,、開發(fā)?作臺,、數(shù)據(jù)標(biāo)簽平臺等，SDK 提供了統(tǒng)一的事件拼裝,、權(quán)限管理,、事件推送等功能,，可以極大的提升平臺間交互的開發(fā)效率,。
• Event 服務(wù)負(fù)責(zé)消費(fèi)消息隊(duì)列中的消息，進(jìn)行事件的解析和數(shù)據(jù)持久化,。
• Core 服務(wù)提供統(tǒng)一的查詢 API,、標(biāo)簽 API 以及類型定義的 API 來實(shí)現(xiàn)查詢跟類型定義的管理。

同時(shí)我們提供了統(tǒng)一的數(shù)據(jù)存儲層模塊 Repo,，來實(shí)現(xiàn)查詢器和統(tǒng)一數(shù)據(jù)處理器的相關(guān)處理,，其內(nèi)部提供了數(shù)據(jù)庫及圖庫的擴(kuò)展 SPI，以便實(shí)現(xiàn)相關(guān)擴(kuò)展,。

我們將資產(chǎn)平臺的事件抽象為以下三種：

• 元數(shù)據(jù)事件 MetadataEvent,，包括實(shí)體/關(guān)系的增刪改查等子事件,。
• 元數(shù)據(jù)異常事件 FailMetadataEvent，在處理 MetadataEvent 時(shí)失敗了，比如類型定義不存在或事件順序有問題,，我們會統(tǒng)一生成一個(gè)元數(shù)據(jù)異常失敗事件，可以基于此事件做異常數(shù)據(jù)落庫或告警通知,。
• 平臺事件 PlatformEvent,，包括使用元數(shù)據(jù)平臺觸發(fā)的埋點(diǎn)事件,，包括實(shí)體的收藏,、查詢,、使用以及安全分級等事件,，其中一部分會做按天級別的統(tǒng)計(jì)處理,，以便在平臺上可以看到類似的統(tǒng)計(jì)信息。

事件進(jìn)?處理，需要關(guān)注以下三點(diǎn)：

1. 分而治之，因?yàn)檎w的事件的數(shù)據(jù)量會?較多,，為了保證性能需要按照 Event 類別和影響,，使?不同的消息隊(duì)列,。對于我們剛才介紹的三種型的事件,，我們實(shí)際使用了三個(gè) Kafka Topic 進(jìn)行消息推送。
2. 消息的順序,，對于元數(shù)據(jù)相關(guān)事件,，消息消費(fèi)需要嚴(yán)格保證有序，如何來保證有序呢,？我們?前采?的?案是由 Kafka Topic 單分區(qū)模式來解決的,，為什么不?多 Partition 呢,？因?yàn)閷?shí)體跟關(guān)系之間的注冊有可能是會分到不同的 Partition 上來進(jìn)?處理的,，因?yàn)楫惒较M(fèi)處理有可能不同分區(qū)的數(shù)據(jù)產(chǎn)生消費(fèi)堆積,，有概率出現(xiàn)不同的分區(qū),，消費(fèi)注冊事件先到，實(shí)體注冊事件后到的情況,，導(dǎo)致廢消息的出現(xiàn),。
3. 最終一致性,，因?yàn)槭录?Event 的異步處理，我們只能保證數(shù)據(jù)的最終?致性。

好，那講完了事件的消費(fèi)流程,，我們下?就要來看數(shù)據(jù)持久化的流程,。我們的數(shù)據(jù)事件從消息隊(duì)列拿到之后，會被我們的事件服務(wù) Event Service 所消費(fèi),，Event Service 中的事件處理器在消費(fèi)數(shù)據(jù)的時(shí)候會?刻對這個(gè)數(shù)據(jù)進(jìn)??份數(shù)據(jù)的存儲,，它會存到關(guān)系型數(shù)據(jù)庫??，作為?個(gè)審計(jì)的回溯?志,。

在存儲完回復(fù)?志之后,，事件處理器就會開始對事件進(jìn)?處理，如果事件處理異常的話,，根據(jù)特定的這種事件類型,，我們會有選擇的把?些異常的事件放到異常事件的消息隊(duì)列??，然后供下游的系統(tǒng)進(jìn)?訂閱通知,，或者是做內(nèi)部后期的問題排查,。

如果事件處理成功了之后，我們會把數(shù)據(jù)丟到聯(lián)合數(shù)據(jù)處理器當(dāng)中,。那聯(lián)合數(shù)據(jù)處理器內(nèi)部其實(shí)就是我們對關(guān)系型數(shù)據(jù)庫以及圖庫的數(shù)據(jù)進(jìn)?了?個(gè)整體的事務(wù)的包裹,，以便兩者之間出現(xiàn)失敗的時(shí)候，可以對數(shù)據(jù)內(nèi)容進(jìn)?回滾,。

那在數(shù)據(jù)持久化當(dāng)中,，我們的關(guān)系型數(shù)據(jù)庫跟圖庫當(dāng)中分別存儲了什么內(nèi)容呢？像關(guān)系型數(shù)據(jù)庫當(dāng)中,，我們往往存儲了實(shí)體跟關(guān)系的數(shù)據(jù),，包括屬性跟這種實(shí)際的這種名稱的?些定義,，同時(shí)還存儲了實(shí)體的統(tǒng)計(jì)類的信息?于分析，還有類型定義的數(shù)據(jù)?于各種各樣數(shù)據(jù)的這樣?種校驗(yàn),。那圖庫當(dāng)中主要就是點(diǎn)邊的這種關(guān)系?于圖譜的查詢,。

資產(chǎn)的查詢分析集成于 Core Service 模塊中，目前有兩大場景分類,，數(shù)據(jù)地圖和血緣分析,。

數(shù)據(jù)地圖類檢索，一般是分查詢,，我們定義一套類似于 ES DSL 風(fēng)格的查詢接口請求,，通過查詢解析器，翻譯成要查詢的關(guān)系型數(shù)據(jù)庫語句,，目前因?yàn)閿?shù)據(jù)量還在 PG 的承受范圍內(nèi),，我們并沒有使用 ES。同時(shí)使用,、收藏,、查詢的統(tǒng)計(jì)類記錄和變動記錄，也是存放于 PG 當(dāng)中,，通過指定接口查詢,。

血緣分析類查詢，一般是關(guān)系查詢,，我們也通過類似于 ES DSL 風(fēng)格的查詢接口請求,，通過查詢解析器，翻譯成圖數(shù)據(jù)庫所識別的 nGQL 或 Cypher 語句,，包括 N 跳關(guān)系查詢,、子圖查詢、屬性查詢等,。

對于?些特殊場景查詢需求,，比如數(shù)據(jù)大盤，或特定實(shí)體的擴(kuò)展事件,，我們通過或定制化查詢的方式進(jìn)行處理,。

02 悅數(shù)圖數(shù)據(jù)庫在眾安資產(chǎn)平臺的實(shí)踐

圖數(shù)據(jù)庫選型

我們在做?主化平臺開發(fā)之前，對熱門開源項(xiàng)目的圖數(shù)據(jù)庫選型做了調(diào)研,。

選型主要考慮兩??的因素,，數(shù)據(jù)庫架構(gòu)和資產(chǎn)平臺設(shè)計(jì)的匹配性。

在架構(gòu)因素??,，核心因素是讀寫性能,、分布式擴(kuò)展、事務(wù)支持和第三方依賴,。對于 Neo4j 來說,，雖然它的性能讀寫性能?常優(yōu)越和原?存儲,，但是因?yàn)?3.x 版本之后，社區(qū)版已經(jīng)不再?持分布式模式,，所以說肯定不能達(dá)到我們預(yù)期的要求,。JanusGraph 和悅數(shù)圖數(shù)據(jù)庫均支持分布式擴(kuò)展和存算分離架構(gòu)，但前者的存儲,、索引均依賴于第三方組件,，帶來大量額外運(yùn)維工作。

資產(chǎn)平臺設(shè)計(jì)的匹配性因素,，核心因素是數(shù)據(jù)隔離,、屬性及 Schema 數(shù)量上線、屬性類型,、查詢語言等,。

JanusGraph/Neo4j 社區(qū)版屬性集均不支持強(qiáng) Schema，這意味著更靈活的屬性配置,。同時(shí),，屬性類型也支持諸如 map、set 等復(fù)雜類型,。悅數(shù)圖數(shù)據(jù)庫屬性集雖然有強(qiáng) Schema 依賴,，但屬性和 Schema 數(shù)量沒有上限，也支持 Schema 的修改,，唯一美中不足的是不支持 map/set 等復(fù)雜類型屬性，這將對類型定義和系統(tǒng)設(shè)計(jì)有一定的影響,，以及對潛在的需求場景有一定的約束,。三種數(shù)據(jù)庫均有通用的查詢語言、以及可以基于 GraphX 進(jìn)行圖算法分析,。

為什么選擇 NebulaGraph

基于以下四點(diǎn)的考慮,，眾安選擇了悅數(shù)圖數(shù)據(jù)庫——

第?是分布式的存算分離架構(gòu)，可以以最優(yōu)的成本,，快速擴(kuò)縮容相關(guān)服務(wù),。

第二是外部組件依賴較少，?便運(yùn)維,。

第三是卓越的讀寫性能,，在19 年年底眾安金融風(fēng)控場景，我們對 NebulaGraph 就進(jìn)?了?定的性能測試,，我們在純 nGQL的 insert 這種寫入方案下,，通過 DataX 可以實(shí)現(xiàn) 300w record/s 的數(shù)據(jù)寫?速度，這個(gè)是一個(gè)非常驚人的數(shù)據(jù)同步的體驗(yàn),。

第四是數(shù)據(jù)存儲格式,，因?yàn)楸姲灿写罅康淖庸咀鈶?，需要進(jìn)行數(shù)據(jù)的存儲隔離，如果是其他產(chǎn)品就需要部署多套圖庫,，或一套圖庫數(shù)據(jù)里打租戶標(biāo)簽,。悅數(shù)圖數(shù)據(jù)庫可以使用圖空間的方式實(shí)現(xiàn)天然的數(shù)據(jù)隔離，大大簡化了我們開發(fā)的工作量,。

悅數(shù)圖數(shù)據(jù)庫 x 阿?云部署模式

因?yàn)楸姲矝]有獨(dú)立機(jī)房,，所有的服務(wù)均依賴于阿里云金融云，基于阿?云 ECS 的能力,，可以快速實(shí)現(xiàn)服務(wù)器以及服務(wù)器上存儲資源的彈性擴(kuò)收容,。實(shí)際部署中，我們將 graphd 跟 mated,、 storaged 進(jìn)行了分開部署,，避免大量查詢導(dǎo)致內(nèi)存過高，影響到其他圖數(shù)據(jù)服務(wù)的穩(wěn)定性,。

graphd 占用了 2 臺 4C 8G 服務(wù)器,，metad/storaged 占用了 3 臺 4C 16G 服務(wù)器。當(dāng)前資產(chǎn)平臺的實(shí)體數(shù)量在 2,500w 個(gè)左右,，邊數(shù)據(jù)在 4左右,，主要為數(shù)據(jù)集類型數(shù)據(jù)。

我們使用每臺 ECS 使用了兩塊 200G 的 ESSD 進(jìn)行存儲,，根據(jù)悅數(shù)的推薦,，磁盤的數(shù)量越多，圖空間 Partition 的擴(kuò)展的數(shù)量就可以越多,，可以獲得更好的并發(fā)處理能力,。

眾安在悅數(shù)圖數(shù)據(jù)庫中的模型設(shè)計(jì)

下面介紹一下眾安基于悅數(shù)圖數(shù)據(jù)庫的模型設(shè)計(jì)。

對于實(shí)體定義來說,，對應(yīng)悅數(shù)圖數(shù)據(jù)庫的某一個(gè) Tag,，其相對于其他圖數(shù)據(jù)庫類似于 Label 概念，就是某個(gè)屬性集的名稱,，通過 Tag 可以更快檢索倒到某一個(gè)實(shí)體點(diǎn)下的屬性,，類型定義的 Tag 必須同這一類型的點(diǎn) ID 進(jìn)行強(qiáng)綁定，注冊時(shí)需要進(jìn)行相關(guān)校驗(yàn),。另一個(gè)屬性集的概念是公共標(biāo)簽,，公共標(biāo)簽可以做很多事情，比如業(yè)務(wù)屬性集,、實(shí)體標(biāo)簽等,。公共標(biāo)簽在 NebulaGraph 當(dāng)中也對應(yīng)一個(gè) Tag，這個(gè) Tag 可以綁定到多種不同的實(shí)體，比如環(huán)境公共標(biāo)簽,，可以賦給 MySQL 數(shù)據(jù)源實(shí)體,，也可以賦給 MaxCompute數(shù)據(jù)源實(shí)體等。

對于關(guān)系定義來說,，對應(yīng)悅數(shù)圖數(shù)據(jù)庫中的某個(gè) Edge Type,，類型定義中的來源目標(biāo)端點(diǎn)的實(shí)體類型，必須同這一類型的點(diǎn) ID 進(jìn)行強(qiáng)綁定,，注冊時(shí)需要進(jìn)行相關(guān)校驗(yàn),。

對于數(shù)據(jù)隔離來說，上述實(shí)體和關(guān)系模型,，通過悅數(shù)圖數(shù)據(jù)庫的圖空間進(jìn)行隔離,，在眾安內(nèi)部的多個(gè)租戶實(shí)體下，比如保險(xiǎn),、小貸,、科技等，會在租戶初始化時(shí)創(chuàng)建指定圖空間,，后續(xù)的類型定義均在租戶圖空間下進(jìn)行,。

最后我們再來看?下模型設(shè)計(jì)的繼承關(guān)系。我們所有的實(shí)體根節(jié)點(diǎn)是?個(gè)叫做 Asset 的實(shí)體定義,，我們將一些公共屬性定義其中,，包括名稱、展示名稱,、備注,、類型等；

基于 Asset 類型,，我們實(shí)現(xiàn)了對接平臺的各種資產(chǎn)實(shí)體,，報(bào)表平臺里的模型、視圖,、畫布、?戶等實(shí)體,，數(shù)據(jù)超市里的路由 API,、數(shù)據(jù) API 以及外部擴(kuò)展 API 等實(shí)體，開發(fā)工臺里的調(diào)度任務(wù),、流計(jì)算任務(wù),、工作空間、文件等實(shí)體,，以及兩個(gè)比較特殊的資產(chǎn)屬主實(shí)體和服務(wù)資產(chǎn)實(shí)體,。

另一個(gè)特殊的實(shí)體是數(shù)據(jù)集實(shí)體，我們將不同數(shù)據(jù)源數(shù)據(jù)源,、表,、列等信息均定義了獨(dú)立的資產(chǎn)實(shí)體定義,，以便實(shí)現(xiàn)不同數(shù)據(jù)源的差異化屬性展示。

我們最終的全鏈路數(shù)據(jù)資產(chǎn),，均是通過數(shù)據(jù)集及其子類自定義實(shí)現(xiàn)串聯(lián),，從而實(shí)現(xiàn)跨平臺的鏈路分析。比如調(diào)度作業(yè)的庫表血緣,，可以關(guān)聯(lián)到報(bào)表平臺的數(shù)據(jù)模型,，也可以關(guān)聯(lián)到數(shù)倉的 Data API 依賴的 Table Store 的某張表等等。

03 未來展望

2022年年底,，眾安基本上已經(jīng)實(shí)現(xiàn)了各個(gè)平臺的各種資產(chǎn)的注冊跟上報(bào)的過程,。

2023年，我們將在圍繞數(shù)據(jù)資產(chǎn)割接,、數(shù)據(jù)安全管理和數(shù)據(jù)治理三個(gè)方面進(jìn)行擴(kuò)展性開發(fā),。

• 數(shù)據(jù)資產(chǎn)割接，將站在用戶實(shí)體的角度上,，快速識別個(gè)人關(guān)聯(lián)的數(shù)據(jù)資產(chǎn),，時(shí)間屬主資產(chǎn)切換和離職交接功能。
• 數(shù)據(jù)安全管理,，基于資產(chǎn)平臺的能力做出多種擴(kuò)展,，遷移內(nèi)部老元數(shù)據(jù)系統(tǒng)的表分級、權(quán)限審批功能,；內(nèi)部脫敏規(guī)則配置平臺及 SDK,，擴(kuò)展支持基于表分級數(shù)據(jù)加密和白名單策略等。
• 數(shù)據(jù)治理,，基于資產(chǎn)平臺的全鏈路血緣分析能力,，觀察資產(chǎn)熱度、使用等關(guān)鍵指標(biāo),，清理無效作業(yè)和重復(fù)計(jì)算作業(yè),，實(shí)現(xiàn)降本增效，減少云平臺使用費(fèi)用,。

---

要來感受同眾安科技一樣的圖數(shù)據(jù)庫體驗(yàn)嘛,？悅數(shù)圖數(shù)據(jù)庫 x 阿里云計(jì)算巢現(xiàn) 30 天免費(fèi)使用中，點(diǎn)擊鏈接來搭建自己的資產(chǎn)管理系統(tǒng)吧,！