?作者 ｜ 霖霧，攜程數(shù)據(jù)開(kāi)發(fā)工程師，關(guān)注圖數(shù)據(jù)庫(kù)等領(lǐng)域。?

背景

2017年9月攜程金融成立，在金融和風(fēng)控業(yè)務(wù)中，有多種場(chǎng)景需要對(duì)圖關(guān)系網(wǎng)絡(luò)進(jìn)行分析和實(shí)時(shí)查詢(xún)，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)難以保證此類(lèi)場(chǎng)景下的關(guān)聯(lián)性能，且實(shí)現(xiàn)復(fù)雜性高，離線關(guān)聯(lián)耗時(shí)過(guò)長(zhǎng)，因此對(duì)圖數(shù)據(jù)庫(kù)的需求日益增加。攜程金融從2020年開(kāi)始引入大規(guī)模圖存儲(chǔ)和圖計(jì)算技術(shù)，基于nebula構(gòu)建了千億級(jí)節(jié)點(diǎn)的圖存儲(chǔ)和分析平臺(tái)，并取得了一些實(shí)際應(yīng)用成果。本文主要分享nebula在攜程金融的實(shí)踐，希望能帶給大家一些實(shí)踐啟發(fā)。

本文主要從以下幾個(gè)部分進(jìn)行分析：

• 圖基礎(chǔ)介紹
• 圖平臺(tái)建設(shè)
• 內(nèi)部應(yīng)用案例分析
• 痛點(diǎn)與優(yōu)化
• 總結(jié)規(guī)劃

一、圖基礎(chǔ)

首先我們來(lái)簡(jiǎn)單介紹下圖相關(guān)的概念：

1.1 什么是圖

在計(jì)算機(jī)科學(xué)中，圖就是一些頂點(diǎn)的集合，這些頂點(diǎn)通過(guò)一系列邊結(jié)對(duì)（連接）。比如我們用一個(gè)圖表示社交網(wǎng)絡(luò)，每一個(gè)人就是一個(gè)頂點(diǎn)，互相認(rèn)識(shí)的人之間通過(guò)邊聯(lián)系。

在圖數(shù)據(jù)庫(kù)中，我們使用 （起點(diǎn),邊類(lèi)型,rank,終點(diǎn)) 表示一條邊。起點(diǎn)和終點(diǎn)比較好理解，表示一條邊兩個(gè)頂點(diǎn)的出入方向。邊類(lèi)型則是用于區(qū)分異構(gòu)圖的不同邊，如我關(guān)注了你，我向你轉(zhuǎn)賬，關(guān)注和轉(zhuǎn)賬就是兩種不同種類(lèi)的邊。而rank是用來(lái)區(qū)分同起始點(diǎn)同終點(diǎn)的不同邊，如A對(duì)B的多次轉(zhuǎn)賬記錄，起點(diǎn)、終點(diǎn)、邊類(lèi)型是完全相同的 ，因此就需要如時(shí)間戳作為rank來(lái)區(qū)分不同的邊。

同時(shí)，點(diǎn)邊均可具有屬性，如：A的手機(jī)號(hào)、銀行卡、身份證號(hào)、籍貫等信息均可作為A的點(diǎn)屬性存在，A對(duì)B轉(zhuǎn)賬這條邊，也可以具有屬性，如轉(zhuǎn)賬金額，轉(zhuǎn)賬地點(diǎn)等邊屬性。

1.2 什么時(shí)候用圖

（信息收集于開(kāi)源社區(qū)、公開(kāi)技術(shù)博客、文章、視頻）

1）金融風(fēng)控：

• 詐騙電話的特征提取，如不在三步社交鄰居圈內(nèi)，被大量拒接等特征。實(shí)時(shí)識(shí)別攔截。（銀行/網(wǎng)警等）
• 轉(zhuǎn)賬實(shí)時(shí)攔截 （銀行/支付寶等）
• 實(shí)時(shí)欺詐檢測(cè)，羊毛黨的識(shí)別（電商）
• 黑產(chǎn)群體識(shí)別，借貸記錄良好用戶(hù)關(guān)聯(lián)，為用戶(hù)提供更高額貸款、增加營(yíng)收

2）股權(quán)穿透

• 影子集團(tuán)、集團(tuán)客戶(hù)多層交叉持股、股權(quán)層層嵌套復(fù)雜關(guān)系的識(shí)別（天眼查/企查查）

3）數(shù)據(jù)血緣

• 在數(shù)據(jù)倉(cāng)庫(kù)開(kāi)發(fā)過(guò)程中， 會(huì)因?yàn)閿?shù)據(jù)跨表關(guān)聯(lián)產(chǎn)生大量的中間表，使用圖可直接根據(jù)關(guān)系模型表示出數(shù)據(jù)加工過(guò)程和數(shù)據(jù)流向，以及在依賴(lài)任務(wù)問(wèn)題時(shí)快速定位上下游。

4）知識(shí)圖譜

• 構(gòu)建行業(yè)知識(shí)圖譜

5）泛安全

• ip關(guān)系等黑客攻擊場(chǎng)景，計(jì)算機(jī)進(jìn)程與線程等安全管理

6）社交推薦

• 好友推薦，行為相似性，咨詢(xún)傳播路徑，可能認(rèn)識(shí)的人，大v粉絲共同關(guān)注，共同閱讀文章等，商品相似性，實(shí)現(xiàn)好友商品或者咨詢(xún)的精準(zhǔn)推薦
• 通過(guò)對(duì)用戶(hù)畫(huà)像、好友關(guān)系等，進(jìn)行用戶(hù)分群、實(shí)現(xiàn)用戶(hù)群體精準(zhǔn)管理

7）代碼依賴(lài)分析

8）供應(yīng)鏈上下游分析

• 如汽車(chē)供應(yīng)鏈上下游可涉及上萬(wàn)零件及供應(yīng)商，分析某些零件成本上漲/供應(yīng)商單一/庫(kù)存少等多維度的影響（捷豹）

1.3 誰(shuí)在研發(fā)圖，誰(shuí)在使用圖

（信息收集于開(kāi)源社區(qū)、公開(kāi)技術(shù)博客、文章、視頻）

目前國(guó)內(nèi)幾家大公司都有各自研發(fā)的圖數(shù)據(jù)庫(kù)，主要滿足內(nèi)部應(yīng)用的需求，大多數(shù)都是閉源的，開(kāi)源的僅有百度的hugegraph。其他比較優(yōu)秀的開(kāi)源產(chǎn)品有Google Dgraph, vesoft的nebula 等，其中nebula在國(guó)內(nèi)互聯(lián)網(wǎng)公司應(yīng)用非常廣泛。結(jié)合我們的應(yīng)用場(chǎng)景，以及外部公開(kāi)的測(cè)試和內(nèi)部壓測(cè)，我們最終選擇nebula構(gòu)建金融圖平臺(tái)。

二、圖平臺(tái)建設(shè)

2.1. 圖平臺(tái)建設(shè)

我們的圖平臺(tái)早期只有1個(gè)3節(jié)點(diǎn)的nebula集群，隨著圖應(yīng)用場(chǎng)景的不斷擴(kuò)充，需要滿足實(shí)時(shí)檢索、離線分析、數(shù)據(jù)同步與校驗(yàn)等功能，最終演化成上述架構(gòu)圖。

1）離線圖：主要用于圖構(gòu)建階段（建模、圖算法分析），通過(guò)spark-connector同集團(tuán)的大數(shù)據(jù)平臺(tái)打通，此外我們還將Nebula提供的數(shù)10種常用圖算法進(jìn)行工具化包裝，方便圖分析人員在spark集群提交圖算法作業(yè)。

2）線上圖：經(jīng)過(guò)離線圖分析確定最終建模后，會(huì)通過(guò)spark-connector將數(shù)據(jù)導(dǎo)入線上圖。通過(guò)對(duì)接qmq消息（集團(tuán)內(nèi)部的消息框架) 實(shí)時(shí)更新，對(duì)外提供實(shí)時(shí)檢索服務(wù)。  同時(shí)也會(huì)有T+1的hive增量數(shù)據(jù)通過(guò)spark-connector按天寫(xiě)入。

3）全量校驗(yàn)：雖然 Nebula Graph 通過(guò) TOSS 保證了正反邊的插入一致性，但仍不支持事務(wù)，隨著數(shù)據(jù)持續(xù)更新，實(shí)時(shí)圖和離線(hive數(shù)據(jù))可能會(huì)存在不一致的情況，因此我們需要定期進(jìn)行全量數(shù)據(jù)的校驗(yàn)(把圖讀取到Hive，和Hive表存儲(chǔ)的圖數(shù)據(jù)進(jìn)行比對(duì)，找出差異、修復(fù)），保證數(shù)據(jù)的最終一致性。

4）集群規(guī)模：為了滿足千億節(jié)點(diǎn)的圖業(yè)務(wù)需求，實(shí)時(shí)集群采用三臺(tái)獨(dú)立部署的高性能機(jī)器，每臺(tái)機(jī)器64core / 320GB / 12TB SSD ，版本為nebulav2.5，跨機(jī)房部署。離線集群64core /320GB /3.6TB SSD * 12  ，測(cè)試集群 48core/ 188GB/5T HDD * 4.

2.2. 遇到的問(wèn)題

在nebula應(yīng)用過(guò)程中，也發(fā)現(xiàn)一些問(wèn)題，期待逐步完善：

1）資源隔離問(wèn)題，目前nebula沒(méi)有資源分組隔離功能 ，不同業(yè)務(wù)會(huì)相互影響；如業(yè)務(wù)圖A在導(dǎo)數(shù)據(jù)，業(yè)務(wù)圖B線上延遲就非常高。

2）版本升級(jí)問(wèn)題：

• nebula在版本升級(jí)過(guò)程中需要停止服務(wù)，無(wú)法實(shí)現(xiàn)熱更新；對(duì)于類(lèi)似實(shí)時(shí)風(fēng)控等對(duì)可靠性要求非常高的場(chǎng)景非常不友好。此種情況下如需保證在線升級(jí)，就需要配備主備集群，每個(gè)集群切量后挨個(gè)升級(jí)，增加服務(wù)復(fù)雜性和運(yùn)維成本。
• 客戶(hù)端不兼容，客戶(hù)端需要跟著服務(wù)端一起升級(jí)版本。對(duì)于已有多個(gè)應(yīng)用使用的nebula集群，想要協(xié)調(diào)各應(yīng)用方同時(shí)升級(jí)客戶(hù)端是比較困難的。

三、內(nèi)部應(yīng)用案例分析

3.1 數(shù)據(jù)血緣圖

數(shù)據(jù)治理是近年來(lái)比較熱的一個(gè)話題，他是解決數(shù)倉(cāng)無(wú)序膨脹的有效手段，其中數(shù)據(jù)血緣是數(shù)據(jù)有效治理的重要依據(jù)，金融借助nebula構(gòu)建了數(shù)據(jù)血緣圖，以支撐數(shù)據(jù)治理的系統(tǒng)建設(shè)。

數(shù)據(jù)血緣就是數(shù)據(jù)產(chǎn)生的鏈路，記錄數(shù)據(jù)加工的流向，經(jīng)過(guò)了哪些過(guò)程和階段；主要解決 ETL 過(guò)程中可能產(chǎn)出幾十甚至幾百個(gè)中間表導(dǎo)致的復(fù)雜表關(guān)系，借用數(shù)據(jù)血緣可以清晰地記錄數(shù)據(jù)源頭到最終數(shù)據(jù)的生成過(guò)程。

圖 a 是數(shù)據(jù)血緣的關(guān)系圖，采用庫(kù)名 + 表名作為圖的頂點(diǎn)來(lái)保證點(diǎn)的唯一性，點(diǎn)屬性則是分開(kāi)的庫(kù)名和表名，以便通過(guò)庫(kù)名或者表名進(jìn)行屬性查詢(xún)。在兩張表之間會(huì)建立一條邊，邊的屬性主要存放任務(wù)的產(chǎn)生運(yùn)行情況，比如說(shuō)：任務(wù)開(kāi)始時(shí)間，結(jié)束時(shí)間、用戶(hù) ID等等同任務(wù)相關(guān)的信息。

圖 b 是實(shí)際查詢(xún)中的一張關(guān)系圖，箭頭的方向表示了表的加工方向，通過(guò)上游或者下游表我們可以快速地找到它的依賴(lài)， 清晰明了地顯示從上游到下游的每一個(gè)鏈路。

如果要表達(dá)復(fù)雜的血緣依賴(lài)關(guān)系圖，通過(guò)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)需要復(fù)雜的SQL實(shí)現(xiàn)（循環(huán)嵌套），性能也比較差，而通過(guò)圖數(shù)據(jù)庫(kù)實(shí)現(xiàn)，則可直接按數(shù)據(jù)依賴(lài)關(guān)系存儲(chǔ)，讀取也快于傳統(tǒng)DB，非常簡(jiǎn)潔。目前，數(shù)據(jù)血緣也是金融BU在圖數(shù)據(jù)庫(kù)上的一個(gè)經(jīng)典應(yīng)用。

3.2 風(fēng)控關(guān)系人圖

關(guān)系人圖常用于欺詐識(shí)別等場(chǎng)景，它是通過(guò) ID、設(shè)備、手機(jī)標(biāo)識(shí)以及其他介質(zhì)信息關(guān)聯(lián)不同用戶(hù)的關(guān)系網(wǎng)絡(luò)。比如說(shuō)，用戶(hù) A 和用戶(hù) B 共享一個(gè) WiFi，他們便是局域網(wǎng)下的關(guān)系人；用戶(hù) C 和用戶(hù) D 相互下過(guò)單，他們便是下單關(guān)系人。簡(jiǎn)言之，系統(tǒng)通過(guò)多種維度的數(shù)據(jù)關(guān)聯(lián)不同的用戶(hù)，這便是關(guān)系人圖。

構(gòu)建模型時(shí)，通常要查詢(xún)某個(gè)時(shí)點(diǎn)（比如欺詐事件發(fā)生前）的關(guān)系圖，對(duì)當(dāng)時(shí)的圖進(jìn)行模型抽取和特征構(gòu)建，我們稱(chēng)這個(gè)過(guò)程為圖回溯。隨著回溯時(shí)間點(diǎn)的不同，返回的圖數(shù)據(jù)也是動(dòng)態(tài)變化的；比如某人上午，下午各自打了一通電話， 需要回溯此人中午時(shí)間點(diǎn)時(shí)的圖關(guān)系，只會(huì)出現(xiàn)上午的電話記錄，具體到圖，則每類(lèi)邊都具有此類(lèi)時(shí)間特性，每一次查詢(xún)都需要對(duì)時(shí)間進(jìn)行限制。

對(duì)于圖回溯場(chǎng)景，最初我們嘗試通過(guò)HIVE SQL實(shí)現(xiàn)，發(fā)現(xiàn)對(duì)于二階及以上的圖回溯，SQL表達(dá)會(huì)非常復(fù)雜，而且性能不可接受（比如二階回溯 Hive需要跑數(shù)小時(shí)，三階回溯Hive幾乎不能實(shí)現(xiàn)）；因此嘗試借助圖數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)，把時(shí)間作為邊rank進(jìn)行建模，再根據(jù)邊關(guān)系進(jìn)行篩選來(lái)實(shí)現(xiàn)回溯。這種回溯方式更直觀、簡(jiǎn)潔，使用簡(jiǎn)單的API即可完成，在性能上相比Hive也有1個(gè)數(shù)量級(jí)以上的提升（二階回溯，圖節(jié)點(diǎn)：百億級(jí)，待回溯節(jié)點(diǎn)：10萬(wàn)級(jí))。

下面用一個(gè)例子說(shuō)明：如圖(a)，點(diǎn)A分別在 t0 、t1、 t2 時(shí)刻建立了一條邊 ，t0、t1、t2為邊rank值，需要返回tx時(shí)的的圖關(guān)系數(shù)據(jù)，只能返回 t0、 t1 對(duì)應(yīng)的 點(diǎn) B、C ，因?yàn)楫?dāng)回溯到tx時(shí)間點(diǎn)時(shí)候，t2還沒(méi)有發(fā)生；最終返回的圖關(guān)系為 t0 和 t1 時(shí)候，VertexA ->VertexB 、 VertexA -> VertexC （見(jiàn)圖 (c) ）。這個(gè)例子是用一種邊進(jìn)行回溯，實(shí)際查詢(xún)中可能會(huì)涉及到 2~3 跳，且存在異構(gòu)邊（打電話是一種邊，點(diǎn)外賣(mài)又是一種邊，下單酒店機(jī)票是一種邊，都是不同類(lèi)型的邊），而這種異構(gòu)圖的數(shù)據(jù)都具有回溯特征，因此實(shí)際的關(guān)系人圖回溯查詢(xún)也會(huì)變得復(fù)雜。

3.3 實(shí)時(shí)反欺詐圖

用戶(hù)下單時(shí)，會(huì)進(jìn)入一個(gè)快速風(fēng)控的階段：通過(guò)基于關(guān)系型數(shù)據(jù)庫(kù)和圖數(shù)據(jù)庫(kù)的規(guī)則進(jìn)行模型特征計(jì)算，來(lái)判斷這個(gè)用戶(hù)是不是風(fēng)險(xiǎn)用戶(hù)，要不要對(duì)該用戶(hù)進(jìn)行下單攔截（實(shí)時(shí)反欺詐）。

我們可以根據(jù)圖關(guān)系配合模型規(guī)則，用來(lái)挖掘欺詐團(tuán)伙。比如說(shuō)，已知某個(gè) uid 是犯欺團(tuán)伙的一員，根據(jù)圖關(guān)聯(lián)來(lái)判斷跟他關(guān)系緊密的用戶(hù)是不是存在欺詐行為。為了避免影響正常用戶(hù)的下單流程，風(fēng)控階段需要快速響應(yīng)，因此對(duì)圖查詢(xún)的性能要求非常高（P95 <15ms)。我們基于nebula構(gòu)建了百億級(jí)的反欺詐圖，在查詢(xún)性能的優(yōu)化方面進(jìn)行了較多思考。

此圖 Schema 為脫敏過(guò)后的部分圖模型，當(dāng)中隱藏很多建模信息。這里簡(jiǎn)單講解下部分的查詢(xún)流程和關(guān)聯(lián)信息。

如上圖為一次圖查詢(xún)流程，每一次圖查詢(xún)由多個(gè)起始點(diǎn)如用戶(hù)uid、用戶(hù)mobile等用戶(hù)信息同時(shí)開(kāi)始，每條線為一次關(guān)聯(lián)查詢(xún)，因此一次圖查詢(xún)由幾十次點(diǎn)邊查詢(xún)組成，由起始點(diǎn)經(jīng)過(guò)一跳查詢(xún)和2跳查詢(xún)，最終將結(jié)果集返回給風(fēng)控引擎。

系統(tǒng)會(huì)將用戶(hù)的信息，轉(zhuǎn)化為該用戶(hù)的標(biāo)簽。在圖查詢(xún)的時(shí)候，根據(jù)這些標(biāo)簽，如 uid、mobile 進(jìn)行獨(dú)立查詢(xún)。舉個(gè)例子，根據(jù)某個(gè) uid 進(jìn)行一跳查詢(xún)，查詢(xún)出它關(guān)聯(lián)的 5 個(gè)手機(jī)號(hào)。再根據(jù)這 5 個(gè)手機(jī)號(hào)進(jìn)行獨(dú)立的 2 跳查詢(xún)，可能會(huì)出來(lái) 25 個(gè) uid，查詢(xún)會(huì)存在數(shù)據(jù)膨脹的情況。因此，系統(tǒng)會(huì)做一個(gè)查詢(xún)限制。去查看這 5 個(gè)手機(jī)號(hào)關(guān)聯(lián)的 uid 是不是超過(guò)了系統(tǒng)設(shè)定的熱點(diǎn)值。如果說(shuō)通過(guò) mobile 查詢(xún)出來(lái)關(guān)聯(lián)的手機(jī)號(hào)、uid 過(guò)多的話，系統(tǒng)就會(huì)判斷其為熱點(diǎn)數(shù)據(jù)，不進(jìn)行邊結(jié)果返回。（二階/三階回溯，圖點(diǎn)邊：百億級(jí))。

四、痛點(diǎn)及優(yōu)化

在上述應(yīng)用場(chǎng)景中，對(duì)于風(fēng)控關(guān)系人圖和反欺詐圖，由于圖規(guī)模比較大（百億點(diǎn)邊），查詢(xún)較多，且對(duì)時(shí)延要求較高，遇到了一些典型問(wèn)題，接下來(lái)簡(jiǎn)單介紹一下。

4.1 查詢(xún)性能問(wèn)題

為了滿足實(shí)時(shí)場(chǎng)景2跳查詢(xún)p95 15ms需求，我們針對(duì)圖schema和連接池以及查詢(xún)端做了一些優(yōu)化：

4.1.1 犧牲寫(xiě)性能換取讀性能

首先，我們來(lái)看看這樣的一個(gè)需求: 查詢(xún)id關(guān)聯(lián)的手機(jī)號(hào) ，需要滿足對(duì)于這個(gè)手機(jī)號(hào)關(guān)聯(lián)邊不超過(guò)3個(gè)。這里解釋下為什么要限制關(guān)聯(lián)邊數(shù)量， 因?yàn)槲覀冋€(gè)體關(guān)聯(lián)邊數(shù)量是有限的，會(huì)有一個(gè)對(duì)于大多數(shù)人的p95這樣的閾值邊數(shù)量，超過(guò)這個(gè)閾值就是臟數(shù)據(jù)。為了這個(gè)閾值校驗(yàn)， 就需要對(duì)每次查詢(xún)的結(jié)果再多查詢(xún)一跳。

如圖(a)所示，我們需要進(jìn)行2次查詢(xún)，第一跳查詢(xún)是為了查詢(xún)用戶(hù)id關(guān)聯(lián)的手機(jī)號(hào)， 第二跳查詢(xún)是為了保證我們的結(jié)果值是合法的（閾值內(nèi)），這樣每跳查詢(xún)最終需要進(jìn)行2跳查詢(xún)來(lái)滿足。如圖給出了圖查詢(xún)的gsql 2步偽碼，這種情況下無(wú)法滿足我們的高時(shí)效性。如何優(yōu)化呢？看下圖(b) ：

我們可以將熱點(diǎn)查詢(xún)固定在點(diǎn)屬性上，這樣一跳查詢(xún)時(shí)就可以知道該點(diǎn)有多少關(guān)聯(lián)邊， 避免進(jìn)行圖 a 中（2）語(yǔ)句驗(yàn)證。還是以圖 (a)為例，從一個(gè)用戶(hù) ID 開(kāi)始查詢(xún)，查詢(xún)他的手機(jī)號(hào)關(guān)聯(lián)，此時(shí)因?yàn)槭謾C(jī)號(hào)關(guān)聯(lián)的邊已經(jīng)變成了點(diǎn)屬性（修改了 schema），圖(a) 2 條查詢(xún)語(yǔ)句實(shí)現(xiàn)的功能就可以變成一條查詢(xún) go from $id over $edgeName where $手機(jī)號(hào).用戶(hù)id邊數(shù)據(jù) <5 | limit 5。

這種設(shè)計(jì)的好處就是，在讀的時(shí)候可以加速驗(yàn)證過(guò)程， 節(jié)約了一跳查詢(xún)。帶來(lái)的成本是：每寫(xiě)一條邊，同時(shí)需要更新2個(gè)點(diǎn)屬性來(lái)記錄點(diǎn)的關(guān)聯(lián)邊情況，而且需要保證冪等（保證重復(fù)提交不會(huì)疊加屬性+1），當(dāng)插入一條邊的時(shí)，先去圖里面查詢(xún)邊是否存在，不存在才會(huì)進(jìn)行寫(xiě)邊以及點(diǎn)屬性 +1 的操作。也就是我們犧牲了寫(xiě)性能，來(lái)?yè)Q取讀性能，并通過(guò)定期check保證數(shù)據(jù)一致。

4.1.2 池化連接降低時(shí)延?

第二個(gè)優(yōu)化手段是通過(guò)池化連接降低時(shí)延。Nebula 官方連接池每次進(jìn)行查詢(xún)均需要進(jìn)行建立初始化連接-執(zhí)行查詢(xún)?nèi)蝿?wù)-關(guān)閉連接。而在高頻（QPS 會(huì)達(dá)到幾千）的查詢(xún)場(chǎng)景中，頻繁的創(chuàng)建、關(guān)閉連接非常影響系統(tǒng)的性能和穩(wěn)定性。且建立連接過(guò)程耗時(shí)平均需要6ms， 比實(shí)際查詢(xún)時(shí)長(zhǎng)1.5ms左右高出幾倍，這是不可接受的。因此我們對(duì)官方客戶(hù)端進(jìn)行了二次封裝，實(shí)現(xiàn)連接的復(fù)用和共享。最后將查詢(xún)p95從 20ms 降低到了 4ms。通過(guò)合理控制并發(fā)，我們最終將 2跳查詢(xún)性能控制在p95 15ms 。

這里貼下代碼供參考：

public class SessionPool {
    /**
     * 創(chuàng)建連接池
     *
     * @param maxCountSession 默認(rèn)創(chuàng)建連接數(shù)
     * @param minCountSession 最大創(chuàng)建連接數(shù)
     * @param hostAndPort     機(jī)器端口列表
     * @param userName        用戶(hù)名
     * @param passWord        密碼
     * @throws UnknownHostException
     * @throws NotValidConnectionException
     * @throws IOErrorException
     * @throws AuthFailedException
     */
    public SessionPool(int maxCountSession, int minCountSession, String hostAndPort, String userName, String passWord) throws UnknownHostException, NotValidConnectionException, IOErrorException, AuthFailedException {
        this.minCountSession = minCountSession;
        this.maxCountSession = maxCountSession;
        this.userName = userName;
        this.passWord = passWord;
        this.queue = new LinkedBlockingQueue<>(minCountSession);
        this.pool = this.initGraphClient(hostAndPort, maxCountSession, minCountSession);
        initSession();
    }
    public Session borrow() {
        Session se = queue.poll();
        if (se != null) {
            return se;
        }
        try {
            return this.pool.getSession(userName, passWord, true);
        } catch (Exception e) {
            log.error("execute borrow session fail, detail: ", e);
            throw new RuntimeException(e);
        }
    }
    public void release(Session se) {
        if (se != null) {
            boolean success = queue.offer(se);
            if (!success) {
                se.release();
            }
        }
    }
    public void close() {
        this.pool.close();
    }
    private void initSession() throws NotValidConnectionException, IOErrorException, AuthFailedException {
        for (int i = 0; i < minCountSession; i++) {
            queue.offer(this.pool.getSession(userName, passWord, true));
        }
    }
    private NebulaPool initGraphClient(String hostAndPort, int maxConnSize, int minCount) throws UnknownHostException {
        List<HostAddress> hostAndPorts = getGraphHostPort(hostAndPort);
        NebulaPool pool = new NebulaPool();
        NebulaPoolConfig nebulaPoolConfig = new NebulaPoolConfig();
        nebulaPoolConfig = nebulaPoolConfig.setMaxConnSize(maxConnSize);
        nebulaPoolConfig = nebulaPoolConfig.setMinConnSize(minCount);
        nebulaPoolConfig = nebulaPoolConfig.setIdleTime(1000 * 600);
        pool.init(hostAndPorts, nebulaPoolConfig);
        return pool;
    }
    private List<HostAddress> getGraphHostPort(String hostAndPort) {
        String[] split = hostAndPort.split(",");
        return Arrays.stream(split).map(item -> {
            String[] splitList = item.split(":");
            return new HostAddress(splitList[0], Integer.parseInt(splitList[1]));
        }).collect(Collectors.toList());
    }
    private Queue<Session> queue;
    private String userName;
    private String passWord;
    private int minCountSession;
    private int maxCountSession;
    private NebulaPool pool;
}

4.1.3 查詢(xún)端優(yōu)化?

對(duì)于查詢(xún)端，像3.3中的例圖，每一次圖查詢(xún)由多個(gè)起始點(diǎn)開(kāi)始，可拆解為幾十次點(diǎn)邊查詢(xún)，需要讓每一層的查詢(xún)盡可能地并發(fā)進(jìn)行，降低最終時(shí)延。我們可以先對(duì) 1 跳查詢(xún)并發(fā)（約十幾次查詢(xún)），再對(duì)結(jié)果進(jìn)行分類(lèi)合并，進(jìn)行第二輪的迭代并發(fā)查詢(xún)（十幾到幾十次查詢(xún)），通過(guò)合理地控制并發(fā)，可將一次組合圖查詢(xún)的 P95 控制在 15 ms 以?xún)?nèi)。

4.2 邊熱點(diǎn)問(wèn)題

在圖查詢(xún)過(guò)程中，存在部分用戶(hù)id 關(guān)聯(lián)過(guò)多信息，如黃牛用戶(hù)關(guān)聯(lián)過(guò)多信息，這部分異常用戶(hù)會(huì)在每一次查詢(xún)時(shí)被過(guò)濾掉，不會(huì)繼續(xù)參與下一次查詢(xún)，避免結(jié)果膨脹。而判斷是否為異常用戶(hù)，則依賴(lài)于數(shù)據(jù)本身設(shè)定的閾值，異常數(shù)據(jù)不會(huì)流入下一階段對(duì)模型計(jì)算造成干擾。

4.3 一致性問(wèn)題

Nebula Graph 本身是沒(méi)有事務(wù)的，對(duì)于上文寫(xiě)邊以及點(diǎn)屬性 +1 的操作，如何保證這些操作的一致性，上文提到過(guò)，我們會(huì)定期對(duì)全量HIVE表數(shù)據(jù)和圖數(shù)據(jù)庫(kù)進(jìn)行check，以 HIVE 數(shù)據(jù)為準(zhǔn)對(duì)線上圖進(jìn)行修正，來(lái)實(shí)現(xiàn)最終一致性。目前來(lái)說(shuō)，圖數(shù)據(jù)庫(kù)和 HIVE 表不一致的情況還是比較少的。

五、總結(jié)與展望

基于nebula的圖業(yè)務(wù)應(yīng)用，完成了對(duì)數(shù)據(jù)血緣、對(duì)關(guān)系人網(wǎng)絡(luò)、反欺詐等場(chǎng)景的支持，并將持續(xù)應(yīng)用在金融更多場(chǎng)景下，助力金融業(yè)務(wù)。我們將持續(xù)跟進(jìn)社區(qū)，結(jié)合自身應(yīng)用場(chǎng)景推進(jìn)圖平臺(tái)建設(shè) ；同時(shí)也期待社區(qū)版能提供熱升級(jí)、資源隔離、更豐富易用的算法包、更強(qiáng)大的studio 等功能。