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

背景

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

本文主要從以下幾個部分進行分析：

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

一、圖基礎(chǔ)

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

1.1 什么是圖

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

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

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

1.2 什么時候用圖

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

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

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

2）股權(quán)穿透

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

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

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

4）知識圖譜

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

5）泛安全

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

6）社交推薦

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

7）代碼依賴分析

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

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

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

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

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

二、圖平臺建設(shè)

2.1. 圖平臺建設(shè)

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

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

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

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

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

2.2. 遇到的問題

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

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

2）版本升級問題：

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

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

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

數(shù)據(jù)治理是近年來比較熱的一個話題，他是解決數(shù)倉無序膨脹的有效手段，其中數(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)過了哪些過程和階段；主要解決 ETL 過程中可能產(chǎn)出幾十甚至幾百個中間表導(dǎo)致的復(fù)雜表關(guān)系，借用數(shù)據(jù)血緣可以清晰地記錄數(shù)據(jù)源頭到最終數(shù)據(jù)的生成過程。

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

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

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

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

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

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

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

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

3.3 實時反欺詐圖

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

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

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

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

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

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

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

4.1 查詢性能問題

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

4.1.1 犧牲寫性能換取讀性能

首先，我們來看看這樣的一個需求: 查詢id關(guān)聯(lián)的手機號 ，需要滿足對于這個手機號關(guān)聯(lián)邊不超過3個。這里解釋下為什么要限制關(guān)聯(lián)邊數(shù)量， 因為我們正常個體關(guān)聯(lián)邊數(shù)量是有限的，會有一個對于大多數(shù)人的p95這樣的閾值邊數(shù)量，超過這個閾值就是臟數(shù)據(jù)。為了這個閾值校驗， 就需要對每次查詢的結(jié)果再多查詢一跳。

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

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

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

4.1.2 池化連接降低時延?

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

這里貼下代碼供參考：

public class SessionPool {
    /**
     * 創(chuàng)建連接池
     *
     * @param maxCountSession 默認創(chuàng)建連接數(shù)
     * @param minCountSession 最大創(chuàng)建連接數(shù)
     * @param hostAndPort     機器端口列表
     * @param userName        用戶名
     * @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 查詢端優(yōu)化?

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

4.2 邊熱點問題

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

4.3 一致性問題

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

五、總結(jié)與展望

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