【作者介紹】

• 戚名鈺：快手安全-移動安全組，主要負(fù)責(zé)快手安全情報(bào)平臺的建設(shè)
• 倪雯：快手?jǐn)?shù)據(jù)平臺-分布式存儲組，主要負(fù)責(zé)快手圖數(shù)據(jù)庫的建設(shè)
• 姚靖怡：快手?jǐn)?shù)據(jù)平臺-分布式存儲組，主要負(fù)責(zé)快手圖數(shù)據(jù)庫的建設(shè)

【公司簡介】

快手是一家全球領(lǐng)先的內(nèi)容社區(qū)和社交平臺，旨在通過短視頻的方式幫助人們發(fā)現(xiàn)所需、發(fā)揮所長，持續(xù)提升每個人獨(dú)特的幸福感。

一. 為什么需要圖數(shù)據(jù)庫

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，在處理復(fù)雜數(shù)據(jù)關(guān)系運(yùn)算上表現(xiàn)很差，隨著數(shù)據(jù)量和深度的增加，關(guān)系型數(shù)據(jù)庫無法在有效的時間內(nèi)計(jì)算出結(jié)果。

所以，為了更好的體現(xiàn)數(shù)據(jù)間的連接，企業(yè)需要一種將關(guān)系信息存儲為實(shí)體、靈活拓展數(shù)據(jù)模型的數(shù)據(jù)庫技術(shù)，這項(xiàng)技術(shù)就是圖數(shù)據(jù)庫（Graph Database）。

相比于傳統(tǒng)關(guān)系型數(shù)據(jù)庫，圖數(shù)據(jù)庫具有以下兩個優(yōu)點(diǎn)：

第一點(diǎn)，圖數(shù)據(jù)庫能很好地體現(xiàn)數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系

從上面的圖模型可以看出，圖數(shù)據(jù)庫的目標(biāo)就是基于圖模型以一種直觀的方式來展示這些關(guān)系，其基于事物關(guān)系的模型表達(dá)，使圖數(shù)據(jù)庫天然具有可解釋性。

第二點(diǎn)，圖數(shù)據(jù)庫能很好地處理數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系：

• 高性能：傳統(tǒng)關(guān)系型數(shù)據(jù)庫在處理關(guān)聯(lián)關(guān)系數(shù)據(jù)時主要靠 JOIN 操作，而隨著數(shù)據(jù)量的增多和關(guān)聯(lián)深度的增加，受制于多表連接與外鍵約束，傳統(tǒng)關(guān)系型數(shù)據(jù)庫會導(dǎo)致較大的額外開銷，產(chǎn)生嚴(yán)重的性能問題。而圖數(shù)據(jù)庫從底層適配了圖模型的數(shù)據(jù)結(jié)構(gòu)，使得它的數(shù)據(jù)查詢與分析速度更快。
• 靈活：圖數(shù)據(jù)庫有非常靈活的數(shù)據(jù)模型，使用者可以根據(jù)業(yè)務(wù)變化隨時調(diào)整圖數(shù)據(jù)結(jié)構(gòu)模型，可以任意添加或刪除頂點(diǎn)、邊，擴(kuò)充或者縮小圖模型等，這種頻繁的數(shù)據(jù)schema更改在圖數(shù)據(jù)庫上能到很好的支持。
• 敏捷：圖數(shù)據(jù)庫的圖模型非常直觀，支持測試驅(qū)動開發(fā)模式，每次構(gòu)建時可進(jìn)行功能測試和性能測試，符合當(dāng)今最流行的敏捷開發(fā)需求，對于提高生產(chǎn)和交付效率也有一定幫助。

基于以上兩個優(yōu)點(diǎn)，圖數(shù)據(jù)庫在金融反欺詐、公安刑偵、社交網(wǎng)絡(luò)、知識圖譜、數(shù)據(jù)血緣、IT 資產(chǎn)及運(yùn)維、威脅情報(bào)等領(lǐng)域有巨大需求。

而快手安全情報(bào)則是通過整合移動端、PC Web 端、云端、聯(lián)盟及小程序等全鏈條的安全數(shù)據(jù)，最終形成統(tǒng)一的基礎(chǔ)安全能力賦能公司業(yè)務(wù)。

由于安全情報(bào)本身具有數(shù)據(jù)實(shí)體多樣性、關(guān)聯(lián)關(guān)系復(fù)雜性、數(shù)據(jù)標(biāo)簽豐富性等特點(diǎn)，因此采用圖數(shù)據(jù)庫來做是最為合適的。

二. 為什么選擇 Nebula Graph

通過收集需求及前期調(diào)研，快手安全情報(bào)在圖數(shù)據(jù)庫上最終選擇了Nebula Graph作為生產(chǎn)環(huán)境的圖數(shù)據(jù)庫。

2.1 需求收集

對于圖數(shù)據(jù)庫的選型來說，其主要需求是在數(shù)據(jù)寫入與數(shù)據(jù)查詢兩個方面：

1. 數(shù)據(jù)寫入方式：離線 + 在線
   • 需要支持天級的離線數(shù)據(jù)批量導(dǎo)入，每天新增寫入數(shù)據(jù)量在百億級別，要求當(dāng)天產(chǎn)生的關(guān)聯(lián)關(guān)系數(shù)據(jù)，小時級能寫完
   • 需要支持?jǐn)?shù)據(jù)的實(shí)時寫入，F(xiàn)link 從 Kafka 中消費(fèi)數(shù)據(jù)，并在做完邏輯處理之后，直接對接圖數(shù)據(jù)庫，進(jìn)行數(shù)據(jù)的實(shí)時寫入，需要支持的 QPS 在 10W 量級
2. 數(shù)據(jù)查詢方式：毫秒級的在線實(shí)時查詢，需要支持的 QPS 在 5W 量級
   • 點(diǎn)及邊的屬性過濾及查詢
   • 多度關(guān)聯(lián)關(guān)系的查詢
3. 部分基本圖數(shù)據(jù)分析能力
   • 圖最短路徑算法等

綜上所述，此次選型的適用于大數(shù)據(jù)架構(gòu)的圖數(shù)據(jù)庫主要需要提供 3 種基本能力：實(shí)時和離線數(shù)據(jù)寫入、在線圖數(shù)據(jù)基本查詢、基于圖數(shù)據(jù)庫的簡單 OLAP 分析，其對應(yīng)定位是：在線、高并發(fā)、低時延 OLTP 類圖查詢服務(wù)及簡單 OLAP 類圖查詢能力。

2.2 選型

基于以上的確定性需求，在進(jìn)行圖數(shù)據(jù)庫的選型上，我們主要考慮了以下幾點(diǎn)：

• 圖數(shù)據(jù)庫所能支持的數(shù)據(jù)量必須要足夠大，因?yàn)槠髽I(yè)級的圖數(shù)據(jù)經(jīng)常會達(dá)到百億甚至千億級別
• 集群可線性拓展，因?yàn)樾枰軌蛟谏a(chǎn)環(huán)境不停服的情況下在線擴(kuò)展機(jī)器
• 查詢性能要達(dá)到毫秒級，因?yàn)樾枰獫M足在線服務(wù)的性能要求，且隨著圖數(shù)據(jù)量的增多，查詢性能不受影響
• 能夠較方便的與 HDFS、Spark 等大數(shù)據(jù)平臺打通，后期能夠在此基礎(chǔ)上搭建圖計(jì)算平臺

2.3 Nebula Graph的特點(diǎn)

1. 高性能：提供毫秒級讀寫
2. 可擴(kuò)展：可水平擴(kuò)容，支持超大規(guī)模圖存儲
3. 引擎架構(gòu)：存儲與計(jì)算分離
4. 圖數(shù)據(jù)模型：點(diǎn)（vertex）、邊（edge），并且支持點(diǎn)或邊的屬性（properties）建模
5. 查詢語言：nGQL，類 SQL 的查詢語言，易學(xué)易用，滿足復(fù)雜業(yè)務(wù)需求
6. 提供了較為豐富和完善的數(shù)據(jù)導(dǎo)入導(dǎo)出工具
7. Nebula Graph 作為開源圖數(shù)據(jù)庫產(chǎn)品，在開源社區(qū)具有良好的活躍度
8. 相較于 JanusGraph 和 HugeGraph，Nebula Graph查詢性能有極大的提升

正是基于Nebula Graph的以上特點(diǎn)以及對我們使用場景和需求的恰好滿足，因此最終選擇Nebula Graph作為我們生產(chǎn)環(huán)境的圖數(shù)據(jù)庫來使用。

三. 安全情報(bào)的圖數(shù)據(jù)建模

如下圖所示，從情報(bào)的角度來看，安全的分層對抗與防守，從下到上，其對抗難度是逐漸增加的：

每一個平面上，之前攻擊方與防守方都是單獨(dú)的對抗，現(xiàn)在利用圖數(shù)據(jù)庫之后，可以將每一個層次的實(shí)體ID通過關(guān)聯(lián)關(guān)系串聯(lián)起來，形成一張立體層次的網(wǎng)，通過這張立體層次的網(wǎng)能夠使企業(yè)快速掌握攻擊者的攻擊方式、作弊工具、團(tuán)伙特征等較全貌的信息。

因此基于安全數(shù)據(jù)的圖結(jié)構(gòu)數(shù)據(jù)建模，可以將原來的平面識別層次變成立體網(wǎng)狀識別層次，能幫助企業(yè)更清晰準(zhǔn)確的識別攻擊與風(fēng)險(xiǎn)。

3.1 基本圖結(jié)構(gòu)

安全情報(bào)的圖建模主要目的是希望判斷任何一個維度風(fēng)險(xiǎn)的時候，不單單局限于該維度本身的狀態(tài)與屬性去看它的風(fēng)險(xiǎn)，而是將維度從個體擴(kuò)展為網(wǎng)絡(luò)層面，通過圖結(jié)構(gòu)的數(shù)據(jù)關(guān)系，通過上下層次（異構(gòu)圖）及同級層次（同構(gòu)圖）立體去觀察該維度的風(fēng)險(xiǎn)。

以設(shè)備風(fēng)險(xiǎn)舉例：對一個設(shè)備而言，整體分為網(wǎng)絡(luò)層、設(shè)備層、賬號層和用戶層這四個層面，每個層面都由其代表性的實(shí)體 ID 來表達(dá)。通過圖數(shù)據(jù)庫，可以做到對一個設(shè)備進(jìn)行立體的三維層次的風(fēng)險(xiǎn)認(rèn)知，這對于風(fēng)險(xiǎn)的識別會非常有幫助。

如上圖所示，這是安全情報(bào)的基本圖結(jié)構(gòu)建模，以上構(gòu)成了一個基于安全情報(bào)的知識圖譜。

3.2 動態(tài)圖結(jié)構(gòu)

在基本圖結(jié)構(gòu)之上，還需要考慮的是，每一種關(guān)聯(lián)關(guān)系的存在都是有時效性的，A 時間段內(nèi)關(guān)聯(lián)關(guān)系存在，B 時間段內(nèi)該關(guān)聯(lián)關(guān)系則未必存在，因此我們希望安全情報(bào)能在圖數(shù)據(jù)庫上真實(shí)反映客觀現(xiàn)實(shí)的這種不同時間段內(nèi)的關(guān)聯(lián)關(guān)系。

這意味著需要隨著查詢時間區(qū)間的不同，而呈現(xiàn)出不同的圖結(jié)構(gòu)模型的數(shù)據(jù)，我們稱之為動態(tài)圖結(jié)構(gòu)。

在動態(tài)圖結(jié)構(gòu)的設(shè)計(jì)上，涉及到的一個問題是：在被查詢的區(qū)間上，什么樣的邊關(guān)系應(yīng)該被返回？

如上圖所示，當(dāng)查詢時間區(qū)間為 B、C、D 時，這條邊應(yīng)該要被返回，當(dāng)查詢時間區(qū)間為A、E時，這條邊不應(yīng)該被返回。

3.3 權(quán)重圖結(jié)構(gòu)

在面對黑灰產(chǎn)或者真人作惡時，往往會出現(xiàn)這種情況：就是一個設(shè)備上面會對應(yīng)非常多的賬號，有些賬號是不法壞人自己的常用賬號，而有些賬號則是他們買來做特定不法直播的賬號。為配合公安或法務(wù)的打擊，我們需要從這批賬號里面精準(zhǔn)區(qū)分出哪些賬號是真實(shí)壞人自己的常用賬號，而哪些賬號只是他們買來用于作惡的賬號。

因此這里面會涉及到賬號與設(shè)備關(guān)聯(lián)關(guān)系邊的權(quán)重問題：如果是該設(shè)備常用的賬號，那么表明這個賬號與這個設(shè)備的關(guān)系是較強(qiáng)的關(guān)系，則這條邊的權(quán)重就會高；如果僅僅是作惡/開直播的時候才會使用的賬號，那么賬號與設(shè)備的關(guān)系則會比較弱，相應(yīng)權(quán)重就會低一些。

因此我們在邊的屬性上，除了有時間維度外，還增加了權(quán)重維度。

綜上所述，最終在安全情報(bào)上所建立的圖模型是：帶權(quán)重的動態(tài)時區(qū)圖結(jié)構(gòu)。

四. 基于圖數(shù)據(jù)庫的安全情報(bào)服務(wù)架構(gòu)與優(yōu)化

整體安全情報(bào)服務(wù)架構(gòu)圖如下所示：

安全情報(bào)服務(wù)整體架構(gòu)圖

其中，基于圖數(shù)據(jù)庫的情報(bào)綜合查詢平臺，軟件架構(gòu)如下圖所示：

情報(bào)綜合查詢平臺軟件架構(gòu)圖

注：AccessProxy 支持辦公網(wǎng)到 IDC 的訪問，kngx 支持 IDC 內(nèi)的直接調(diào)用

4.1 離線數(shù)據(jù)寫入優(yōu)化

針對所構(gòu)建的關(guān)聯(lián)關(guān)系數(shù)據(jù)，每天更新的量在數(shù)十億級別，如何保證這數(shù)十億級別的數(shù)據(jù)能在小時級內(nèi)寫入、感知數(shù)據(jù)異常且不丟失數(shù)據(jù)，這也是一項(xiàng)非常有挑戰(zhàn)性的工作。

對這部分的優(yōu)化主要是：失敗重試、臟數(shù)據(jù)發(fā)現(xiàn)及導(dǎo)入失敗報(bào)警策略。

數(shù)據(jù)導(dǎo)入過程中會由于臟數(shù)據(jù)、服務(wù)端抖動、數(shù)據(jù)庫進(jìn)程掛掉、寫入太快等各種因素導(dǎo)致寫 batch 數(shù)據(jù)失敗，我們通過用同步 client API、多層級的重試機(jī)制及失敗退出策略，解決了由于服務(wù)端抖動重啟等情況造成的寫失敗或?qū)?batch 不完全成功等問題。

4.2 雙集群 HA 保證與切換機(jī)制

在圖數(shù)據(jù)庫部分，快手部署了在線與離線兩套圖數(shù)據(jù)庫集群，兩個集群的數(shù)據(jù)采用同步雙寫，在線集群承擔(dān)在線 RPC 類的服務(wù)，離線集群承擔(dān) CASE 分析及 WEB 查詢的服務(wù)，這兩個集群互不影響。

同時集群的狀態(tài)監(jiān)控與動態(tài)配置下發(fā)模塊是打通的，當(dāng)某一個集群出現(xiàn)慢查詢或發(fā)生故障時，通過動態(tài)配置下發(fā)模塊來進(jìn)行自動切換，做到上層業(yè)務(wù)無感知。

4.3 集群穩(wěn)定性建設(shè)

數(shù)據(jù)架構(gòu)團(tuán)隊(duì)對開源版本的 Nebula Graph 進(jìn)行了整體的調(diào)研、維護(hù)與改進(jìn)。

Nebula 的集群采用計(jì)算存儲分離的模式，從整體架構(gòu)看，分為 Meta，Graph，Storage 三個角色，分別負(fù)責(zé)元數(shù)據(jù)管理，計(jì)算和存儲：

Nebula 整體架構(gòu)圖

Nebula 的存儲層作為圖數(shù)據(jù)庫引擎的底座，支持多種存儲類型，我們使用 Nebula 時選擇了經(jīng)典模式，即用經(jīng)典的 C++ 實(shí)現(xiàn)的 RocksdDB 作為底層 KV 存儲，并利用 Raft 算法解決一致性的問題，使整個集群支持水平動態(tài)擴(kuò)容。

存儲層架構(gòu)圖

我們對存儲層進(jìn)行了充分的測試、代碼改進(jìn)與參數(shù)優(yōu)化。其中包括：優(yōu)化 Raft 心跳邏輯、改進(jìn) leader選舉和 log offset 的邏輯以及對 Raft 參數(shù)進(jìn)行調(diào)優(yōu)等，來提升單集群的故障恢復(fù)時間；再結(jié)合客戶端重試機(jī)制的優(yōu)化，使得 Nebula 引擎在用戶體驗(yàn)上從最初的故障直接掉線改善為故障毫秒級恢復(fù)。

在監(jiān)控報(bào)警體系上，我們構(gòu)建了對集群多個層面的監(jiān)控，其整體監(jiān)控架構(gòu)如下圖所示：

集群監(jiān)控架構(gòu)圖

包括如下幾個方面：

1. 機(jī)器硬件層面 cpu busy、磁盤 util、內(nèi)存、網(wǎng)絡(luò)等
2. 集群每個角色 meta、storage、graph 服務(wù)接口監(jiān)控、partition leader上線狀態(tài)及分布的監(jiān)控
3. 從用戶角度對集群整體可用性的評估監(jiān)控
4. 集群各角色 meta、storage、rocksdb、graph 的 metric 采集監(jiān)控
5. 慢查詢監(jiān)控

4.4 對超級節(jié)點(diǎn)查詢的優(yōu)化

由于現(xiàn)實(shí)圖網(wǎng)絡(luò)結(jié)構(gòu)中點(diǎn)的出度往往符合冪律分布特征，圖遍歷遇到超級點(diǎn)（出度百萬/千萬）將導(dǎo)致數(shù)據(jù)庫層面明顯的慢查詢，如何保證在線服務(wù)查詢耗時的平穩(wěn)性，避免極端耗時的發(fā)生是我們需要解決的問題。

圖遍歷超級點(diǎn)問題在工程上的解決思路是：在業(yè)務(wù)可接受的前提下縮小查詢規(guī)模。具體方法有：

1. 查詢中做符合條件的 limit 截?cái)?/li>
2. 查詢按一定比例進(jìn)行邊采樣

下面分別描述具體的優(yōu)化策略：

4.4.1 limit 截?cái)鄡?yōu)化

【前提條件】

業(yè)務(wù)層面可接受每一跳做 limit 截?cái)啵缛缦聝蓚€查詢：

# 最終做limit截?cái)?go from hash('x.x.x.x') over GID_IP REVERSELY where (GID_IP.update_time >= xxx and GID_IP.create_time <= xxx) yield GID_IP.create_time as create_time, GID_IP.update_time as update_time, $^.IP.ip as ip, $$.GID.gid | limit 100
# 在中間查詢結(jié)果已經(jīng)做了截?cái)啵缓笤龠M(jìn)行下一步
go from hash('x.x.x.x') over GID_IP REVERSELY where (GID_IP.update_time >= xxx and GID_IP.create_time <= xxx) yield GID_IP._dst as dst | limit 100 | go from $-.dst ..... | limit 100

【優(yōu)化前】

對第二個查詢語句，在優(yōu)化前，storage會遍歷點(diǎn)的所有出度，graph 層在最終返回 client 前才做 limit n 的截?cái)啵@種無法避免大量耗時的操作。

另外 Nebula 雖然支持 storage 配置集群（進(jìn)程）級別參數(shù)max_edge_returned_per_vertex（每個 vertex 掃描最大出度），但無法滿足查詢語句級別靈活指定 limit 并且對于多跳多點(diǎn)出度查詢也無法做到語句級別精確限制。

【優(yōu)化思路】

一跳 go 遍歷查詢分兩步：

• step1：掃描 srcVertex 所有出度 destVertex（同時獲取邊的屬性）
• step2：獲取所有 destVertex 的屬性 value

那么 go 多跳遍歷中每跳的執(zhí)行分兩種情況：

• case 1：只執(zhí)行 step1 掃邊出度
• case 2：執(zhí)行 step1 + step2

而 step2 是耗時大頭（查每個 destVertex 屬性即一次 rocksdb iterator，不命中 cache 情況下耗時 500us），對于出度大的點(diǎn)將「limit 截?cái)唷固崆暗?step2 之前是關(guān)鍵，另外 limit 能下推到 step1 storage 掃邊出度階段對于超級點(diǎn)也有較大的收益。

這里我們總結(jié)下什么條件下能執(zhí)行「limit 截?cái)鄡?yōu)化」及其收益：

表注釋: N 表示 vertex 出度，n 表示 limit n，scan 表示掃邊出度消耗，get 表示獲取 vertex 屬性的消耗

【測試效果】

對于以上 case1 和 case2 可執(zhí)行「limit 截?cái)鄡?yōu)化」且收益明顯，其中安全業(yè)務(wù)查詢屬于 case2，以下是在 3 臺機(jī)器集群，單機(jī)單盤 900 GB 數(shù)據(jù)存儲量上針對 case2 limit 100 做的測試結(jié)果（不命中 rocksdb cache 的條件）：

以上測試結(jié)果表明，經(jīng)過我們的優(yōu)化后，在圖超級點(diǎn)查詢耗時上，取得了非常優(yōu)異的表現(xiàn)。

4.4.2 邊采樣優(yōu)化

針對不能簡單做「limit 截?cái)鄡?yōu)化」的場景，我們可以采取「邊采樣優(yōu)化」的方式來解決。在 Nebula 社區(qū)原生支持的“storage 進(jìn)程級別可配置每個 vertex 最大返回出度邊和開啟邊采樣功能”基礎(chǔ)上，我們優(yōu)化后，可以進(jìn)一步支持如下功能：

1. storage 開啟采樣功能后，可支持配置掃max_iter_edge_for_sample數(shù)量的邊而非掃所有邊（默認(rèn)）
2. graph 支持 go 每跳出度采樣功能
3. storage 和 graph 的“采樣是否開啟 enable_reservoir_sampling”和“每個 vertex 最大返回出度 max_edge_returned_per_vertex”都支持 session 級別參數(shù)可配

通過以上功能的支持，業(yè)務(wù)可以更靈活地調(diào)整查詢采樣比例，控制遍歷查詢規(guī)模，以達(dá)到在線服務(wù)的平滑性。

4.5 查詢客戶端的改造與優(yōu)化

開源的 Nebula Graph 有自己的一套客戶端，而如何將這套客戶端與快手的工程相結(jié)合，這里我們也做了一些相應(yīng)的改造與優(yōu)化。主要解決了下面兩個問題：

• 連接池化：Nebula Graph 官方客戶端提供的底層接口，每次查詢都需要建立連接初始化、執(zhí)行查詢、關(guān)閉連接這些步驟，在高頻查詢場景中頻繁創(chuàng)建、關(guān)閉連接極大地影響著系統(tǒng)的性能與穩(wěn)定性。在實(shí)踐中，通過連接池化技術(shù)對官方客戶端進(jìn)行二次封裝，并對連接生命周期的各個階段進(jìn)行監(jiān)控，實(shí)現(xiàn)了連接的復(fù)用和共享，提升了業(yè)務(wù)穩(wěn)定性。
• 自動故障切換：通過對連接建立、初始化、查詢、銷毀各個階段的異常監(jiān)控和定期探活，實(shí)現(xiàn)了數(shù)據(jù)庫集群中的故障節(jié)點(diǎn)的實(shí)時發(fā)現(xiàn)和自動剔除，如果整個集群不可用，則能秒級遷移至備用集群，降低了集群故障對在線業(yè)務(wù)可用性造成的潛在影響。

4.6 查詢結(jié)果的可視化及下載

針對固定關(guān)系的查詢（寫死 nGQL），前端根據(jù)返回結(jié)果，進(jìn)行定制化的圖形界面展示，如下圖所示：

這里前端采用ECharts的關(guān)系圖，在前端的圖結(jié)構(gòu)數(shù)據(jù)加載及展示這里也做了一些優(yōu)化。

問題一：關(guān)系圖需要能展示每個節(jié)點(diǎn)的詳情信息，而 ECharts 提供的圖里只能做簡單的 value 值的展示。

解決方案：在原代碼上進(jìn)行改造，每個節(jié)點(diǎn)添加點(diǎn)擊事件，彈出模態(tài)框展示更多的詳情信息。

問題二：關(guān)系圖在點(diǎn)擊事件觸發(fā)后，圖會有較長時間的轉(zhuǎn)動，無法辨認(rèn)點(diǎn)擊了哪個節(jié)點(diǎn)。

解決方案：獲取初次渲染圖形時每個節(jié)點(diǎn)的窗口位置，在點(diǎn)擊事件觸發(fā)后，給每個節(jié)點(diǎn)位置固定下來。

問題三：當(dāng)圖的節(jié)點(diǎn)眾多時候，關(guān)系圖展示的比較擁擠。

解決方案：開啟鼠標(biāo)縮放和評議漫游功能。

針對靈活關(guān)系的查詢（靈活 nGQL），根據(jù)部署的Nebula Graph Studio進(jìn)行可視化的呈現(xiàn)，如下圖所示：

五. 圖數(shù)據(jù)庫在安全情報(bào)上的實(shí)踐

基于以上圖數(shù)據(jù)庫的結(jié)構(gòu)與優(yōu)化，我們提供了 Web 查詢和 RPC 查詢兩種接入方式，主要支持了快手的如下業(yè)務(wù)：

• 支持快手安全的溯源、線下打擊與黑灰產(chǎn)分析
• 支持業(yè)務(wù)安全的風(fēng)控與反作弊

例如，群控設(shè)備與正常設(shè)備在圖數(shù)據(jù)上的表現(xiàn)存在明顯區(qū)別：

對于群控設(shè)備的識別：

六. 總結(jié)與展望

• 穩(wěn)定性建設(shè)：集群 HA 能力實(shí)現(xiàn)跨 AZ 集群的實(shí)時同步、訪問自動切換，以保障99.99 的 SLA
• 性能提升：考慮改造 RPC、AEP 新硬件的存儲方案、優(yōu)化查詢執(zhí)行計(jì)劃
• 圖計(jì)算平臺與圖查詢打通：建設(shè)圖計(jì)算/圖學(xué)習(xí)/圖查詢的一體化平臺
• 實(shí)時判定：實(shí)時關(guān)系的寫入及實(shí)時風(fēng)險(xiǎn)的綜合判定

七. 致謝

感謝開源社區(qū)Nebula Graph對快手的支持。