一、RDF 和屬性圖

首先來介紹 RDF 和屬性圖。大家知道世界萬物是普遍聯(lián)系的，Internet 帶來了信息的連通，IoT 帶來了設(shè)備的連通，像微信、微博、抖音、快手這些 APP 帶來了人際關(guān)系的連通。隨著社交、零售、金融、電信、物流等行業(yè)的快速發(fā)展，當(dāng)今社會(huì)支起了一張龐大而復(fù)雜的關(guān)系網(wǎng)，在人們的生產(chǎn)和生活過程中，每時(shí)每刻都產(chǎn)生著大量的數(shù)據(jù)。隨著技術(shù)的發(fā)展，我們對這些數(shù)據(jù)的分析和使用也不再局限于從統(tǒng)計(jì)的角度進(jìn)行一些相關(guān)性的分析，而是希望從關(guān)聯(lián)的角度揭示數(shù)據(jù)的一些因果聯(lián)系。這里的關(guān)聯(lián)，指的是相互連接的 connectivity，而不是統(tǒng)計(jì)意義上的 correlation。

(資料圖片僅供參考)

關(guān)聯(lián)分析的場景也非常多，覆蓋我們生活的方方面面。比如從社交網(wǎng)絡(luò)分析里，我們可以做精準(zhǔn)營銷、好友推薦、輿情追蹤等等；金融領(lǐng)域可以做信用卡反欺詐的分析，資金流向識(shí)別；零售領(lǐng)域，我們可以做用戶 360 畫像做商品實(shí)時(shí)推薦，返薅羊毛；電力領(lǐng)域，可以做電網(wǎng)的調(diào)度仿真、故障分析、電臺(tái)因子計(jì)算；電信領(lǐng)域，可以做電信防騷擾，電信防詐騙；政企領(lǐng)域，可以做道路規(guī)劃、智能交通，還有疫情精準(zhǔn)防控；在制造業(yè)，我們可以做供應(yīng)鏈管理、物流優(yōu)化、產(chǎn)品溯源等；網(wǎng)絡(luò)安全行業(yè)，可以做攻擊溯源、調(diào)用鏈分析等等。

以上只是列舉了一些常見的分析場景。事實(shí)上，關(guān)聯(lián)分析的應(yīng)用遠(yuǎn)遠(yuǎn)不止于這些場景，還有很多其它場景。比如企業(yè)的股權(quán)穿透分析，公安的安全案情分析，還有生物醫(yī)藥領(lǐng)域的基因分類和新藥研發(fā)等等，這里就不一一贅述了。

在做關(guān)聯(lián)分析的時(shí)候，我們往往需要一個(gè)圖模型來描述。常見的圖模型分為 RDF 和屬性圖兩種。RDF 圖中用點(diǎn)來表示唯一標(biāo)識(shí)的資源或者是字面量的值，邊則用來表示謂詞。點(diǎn)和邊之間組成一個(gè) SPO 的三元組。屬性圖中，點(diǎn)表示實(shí)體，邊表示關(guān)系，屬性是點(diǎn)或邊上的一個(gè)鍵值對。

相比之下，RDF 的優(yōu)勢是可以支持多值屬性，因?yàn)樗膶傩砸彩且粋€(gè)點(diǎn)，所以一個(gè)點(diǎn)連出去，可以有多值的屬性。也可以通過四元組的方式前面加上一個(gè)圖的描述，來實(shí)現(xiàn)動(dòng)態(tài)圖。并且 RDF 開始的比較早，所以有一個(gè)比較統(tǒng)一的標(biāo)準(zhǔn)。

屬性圖的優(yōu)勢在于它兩點(diǎn)之間可以表示同類型的多條邊，因?yàn)樗谶吷鲜强梢杂袇^(qū)分屬性的，邊上的屬性值也能讓邊上的表達(dá)能力更豐富。并且它支持復(fù)雜的屬性類型，比如 list、set、map 等。

隨著行業(yè)的發(fā)展，我們看到越來越多的可能。知識(shí)圖譜的表示在逐漸用屬性圖來完成。今年將正式投票、明年發(fā)布的 GQL 標(biāo)準(zhǔn)，也是基于屬性圖的一個(gè)查詢語言標(biāo)準(zhǔn)。當(dāng)然也有少量的圖數(shù)據(jù)庫是用 RDF 模型來做的，但是未來更多的新型圖數(shù)據(jù)庫都會(huì)用屬性圖模型。

二、圖數(shù)據(jù)庫存儲(chǔ)的核心目標(biāo)

不論是用 RDF 還是用屬性圖，作為一個(gè)圖數(shù)據(jù)庫，它的核心目標(biāo)是什么？或者說數(shù)據(jù)庫存儲(chǔ)需要解決的一個(gè)根本問題是什么呢？那些需要用關(guān)聯(lián)分析的圖場景，往往是一些數(shù)據(jù)規(guī)模大、關(guān)聯(lián)跳數(shù)深、實(shí)時(shí)要求高的場景。

完成一個(gè)圖查詢或者圖分析的核心操作，就是鄰居的迭代遍歷。單獨(dú)的訪問點(diǎn)或者邊，或者上面的屬性并不是這里的關(guān)鍵。僅僅是單獨(dú)訪問，使用傳統(tǒng)的數(shù)據(jù)庫也可以提供很好的性能。在關(guān)聯(lián)分析當(dāng)中，不論是從一個(gè)起始點(diǎn)若干跳數(shù)內(nèi)的鄰域網(wǎng)絡(luò)進(jìn)行分析，還是對全圖進(jìn)行一些完整的計(jì)算，最核心的操作都是迭代遍歷某個(gè)點(diǎn)的所有邊，也就是所謂鄰居的迭代遍歷。在關(guān)系型數(shù)據(jù)庫中是依賴外鍵，通過建立索引等方式來完成的。

在圖數(shù)據(jù)庫中，會(huì)直接存儲(chǔ)邊數(shù)據(jù)，也就是所謂的實(shí)現(xiàn) index-free adjacency。寫入的時(shí)候，保證一個(gè)點(diǎn)和它直接相連的邊總是存儲(chǔ)在一起。查詢的時(shí)候，迭代遍歷一個(gè)點(diǎn)的所有鄰居可以直接進(jìn)行，不需要依賴于其它數(shù)據(jù)結(jié)構(gòu)，從而可以大幅提升鄰居迭代遍歷的性能。

這里是跟關(guān)系型數(shù)據(jù)庫做的一個(gè)深點(diǎn)查詢的性能對比，用的是 who-trust-whom 的一個(gè)公開數(shù)據(jù)集，這個(gè)數(shù)據(jù)集也不是很大，約 7.5 萬點(diǎn)，50 萬邊。我們想知道一個(gè)信任的人這樣一個(gè)多跳關(guān)聯(lián)的查詢結(jié)果。使用關(guān)鍵性數(shù)據(jù)庫的時(shí)候，對比了加索引和不加索引的情況?？梢钥闯?2 跳的時(shí)候加索引可以明顯提升關(guān)系型數(shù)據(jù)庫的查詢速度，到 3 跳的時(shí)候提升就不多了， 4 跳以上的時(shí)候加不加索引都會(huì)變得很慢。而使用圖數(shù)據(jù)庫，查詢性能一直會(huì)保持在一個(gè)非常快的水平。這就是圖數(shù)據(jù)庫的 index-free adjacency 的特性，能夠大幅提升鄰居查詢的速度。

根據(jù)實(shí)現(xiàn)免索引連接的方式，可以把圖數(shù)據(jù)庫分成三類。

第一類是使用原生圖存儲(chǔ)的方式，它的數(shù)據(jù)存儲(chǔ)層就直接實(shí)現(xiàn)了免索引連接。上面的處理計(jì)算層和業(yè)務(wù)層都是以完全圖的結(jié)構(gòu)來描述，并且也不依賴于第三方存儲(chǔ)組件，所以這種實(shí)現(xiàn)免索引連接的性能是最高效的。

第二種方式是非原生存儲(chǔ)，數(shù)據(jù)存儲(chǔ)層使用的是一個(gè)第三方的開源存儲(chǔ)組件，但是它在處理過程中實(shí)現(xiàn)了近似免索引連接，在大多數(shù)情況下也能提供不錯(cuò)的性能。它的問題是由于使用了第三方存儲(chǔ)組件，在某些場景下可能做得不是最優(yōu)化。

第三種方式就是完全非原生的存儲(chǔ)，底下可能是一個(gè)關(guān)系型數(shù)據(jù)庫，或者是一個(gè)文檔型或者其它類型的數(shù)據(jù)庫，它的存儲(chǔ)層其實(shí)并不是真正地實(shí)現(xiàn)了免索引連接，而是處理成通過索引或者一些其它技術(shù)手段，向上表達(dá)了一個(gè)圖模型的查詢接口。這種其實(shí)只是在接口層上實(shí)現(xiàn)了圖的一個(gè)語義，而底下的存儲(chǔ)和計(jì)算層都不是完全地使用免索引連接，所以它的性能也會(huì)相對低一些。

三、圖數(shù)據(jù)庫存儲(chǔ)的主流技術(shù)方案

前文中已經(jīng)明確了數(shù)據(jù)庫存儲(chǔ)的核心目標(biāo)就是實(shí)現(xiàn)免索引連接。那么接下來就來看一些具體實(shí)現(xiàn)免索引連接的主流技術(shù)方案。這里主要介紹不同方案的設(shè)計(jì)思路，并不局限于某個(gè)產(chǎn)品的具體實(shí)現(xiàn)細(xì)節(jié)。

首先我們能想到的最直接的一個(gè)方案，就是用一個(gè)數(shù)組把每個(gè)點(diǎn)上的邊按照順序一起存儲(chǔ)。在這一存儲(chǔ)方案中，點(diǎn)文件就是由一系列的點(diǎn)數(shù)據(jù)組成的。每個(gè)點(diǎn)的存儲(chǔ)內(nèi)容包括點(diǎn)的 ID、點(diǎn)的 Meta 信息，以及這個(gè)點(diǎn)的一系列屬性。在邊文件中，是按照起始點(diǎn)的順序存儲(chǔ)點(diǎn)上對應(yīng)的邊，每條邊存儲(chǔ)的內(nèi)容包括終止點(diǎn) ID、邊的 Meta 信息、邊的一系列屬性。這里所謂的 Meta 信息包括點(diǎn)邊的類型、方向，還有一些為了實(shí)現(xiàn)事務(wù)的額外字段，這對于整體的存儲(chǔ)來說不是特別重要，在這里就不詳細(xì)展開了。在這個(gè)存儲(chǔ)方案中，可以直接從起始點(diǎn)開始遍歷相鄰邊的所有數(shù)據(jù)，讀取性能是非常高的。

這種存儲(chǔ)需要處理的一個(gè)比較棘手的問題，就是數(shù)組變長的情況。這里的變長是由很多因素導(dǎo)致，比如兩個(gè)點(diǎn)可能屬性數(shù)量不一樣，屬性本身如果是字符串，長度也會(huì)不一樣。屬性長度不一樣會(huì)導(dǎo)致每條邊的存儲(chǔ)空間也不一樣，這樣在邊文件中就不能用一個(gè)簡單的數(shù)組來進(jìn)行尋址了。如果僅僅是屬性導(dǎo)致的變長，還是有比較簡單的解決方案的，比如可以把屬性單獨(dú)的再放到另一個(gè)存儲(chǔ)文件中，這樣點(diǎn)文件和邊文件里面的內(nèi)容，是不是定長的呢？其實(shí)也不一定，因?yàn)槊總€(gè)點(diǎn)上邊的數(shù)量也是不一樣的，所以在邊文件里面，每個(gè)點(diǎn)觸發(fā)的邊序列的總長度也是不一樣的。所以還是要處理數(shù)組變長的問題。

解決思路一般是兩種，一種是使用額外的一個(gè) offset 的記錄，相當(dāng)于是用一個(gè)偏移量記錄，來記錄每一個(gè)點(diǎn)或者邊的起始位置。這個(gè)記錄本身就可以是定長的了，因?yàn)樗莻€(gè) offset 值?；蛘呤翘崆皠澐趾靡恍╊~外的區(qū)域，來預(yù)留給它增長的空間。

為了解決這種數(shù)組存儲(chǔ)變長的問題，我們自然也可以想到用類似鏈表的方式來存儲(chǔ)。在鏈表方式的存儲(chǔ)模式中，點(diǎn)和邊全部存的都是 ID，包括點(diǎn) ID、邊 ID、屬性 ID 等等。通過屬性 ID ，可以在另外一個(gè)屬性存儲(chǔ)里面找到它的位置以及具體的值。因?yàn)榇娴亩际?ID，所以每個(gè)點(diǎn)和每條邊的數(shù)據(jù)長度就是固定的了。通過 ID 可以直接計(jì)算出偏移量，然后用偏移量的位置去讀取數(shù)據(jù)。所以每個(gè)數(shù)據(jù)本身也不需要保存自身的ID，因?yàn)槠屏康奈恢檬悄軌蚍赐瞥鰜碜陨?ID 的。

這是一個(gè)鏈表存儲(chǔ)下進(jìn)行邊迭代的例子。

假設(shè)有一個(gè)起始點(diǎn) A，需要迭代它的所有邊。首先在點(diǎn)文件中找到點(diǎn) A 的首個(gè)邊，α。然后去邊文件中找到 α 對應(yīng)偏移量的位置，就可以讀出這條邊的數(shù)據(jù)?？梢钥吹剑且粋€(gè)從點(diǎn) A 到點(diǎn) B 的邊，A 是一個(gè)起始點(diǎn)，我們就去找起始點(diǎn)下一條邊的 ID，就找到邊 θ。然后去邊 θ 的位置，找到偏移量，就找到邊 θ。這里我們看到它是一個(gè) C 到 A 的邊，A 是終止點(diǎn)。我們就去找終止點(diǎn)的下一條邊，是 ω。再去找到邊 ω 的位置，看到是起始點(diǎn) A 終止點(diǎn) D，通過這樣的方式就可以不斷地去迭代邊。

我們看到，用鏈表存儲(chǔ)的方式很好地解決了數(shù)組變長的問題，因?yàn)樾略鲞叺臅r(shí)候，只需要新增固定長度的結(jié)構(gòu)組成鏈表即可。每一次迭代也是在 O(1)的時(shí)間內(nèi)直接找到了下一條邊，也不依賴于外部的索引或者其它結(jié)構(gòu)。

這看似是一個(gè)比較好的方案，但實(shí)際的使用中，也存在著一些問題。不要忘記，現(xiàn)在討論的是一個(gè)存儲(chǔ)格式，而不是一個(gè)內(nèi)存結(jié)構(gòu)。存儲(chǔ)格式意味著最終是要在磁盤 IO 上進(jìn)行讀寫的。在鏈表存儲(chǔ)方案下，每一次邊迭代的時(shí)候，由于邊 offset 的位置是隨機(jī)的，所以會(huì)有大量的隨機(jī)讀操作。而磁盤對于隨機(jī)讀操作并不是很友好。所以雖然這里理論上的迭代鄰居找到下一條邊的復(fù)雜度是 O(1)，但 O(1) 的單位時(shí)間是磁盤隨機(jī)讀的時(shí)間，而不是順序讀的時(shí)間，這兩者在性能上是會(huì)有非常大的差別的。所以使用這種鏈表的存儲(chǔ)方式，通常來說會(huì)依賴一個(gè)非常高效實(shí)現(xiàn)的緩存機(jī)制，需要把大量的磁盤數(shù)據(jù)放到內(nèi)存緩存中來讀，在內(nèi)存中進(jìn)行隨機(jī)訪問的性能就會(huì)提升很多。

除了基于數(shù)組和鏈表的方法，還有其它一些格式可以實(shí)現(xiàn) O(1) 時(shí)間的邊迭代。比如，使用 LSM-Tree 的存儲(chǔ)結(jié)構(gòu)，這個(gè)結(jié)構(gòu)是一種順序?qū)懕P多層結(jié)構(gòu)的 KV 存儲(chǔ)。這里只簡單介紹一下它的工作原理。

這個(gè)圖忽略了像寫 WAL 這樣的細(xì)節(jié)，是 LSM 樹讀寫的核心操作流程。LSM 樹是一種常用的鍵值存儲(chǔ)結(jié)構(gòu)，處理寫請求的性能很高。它的讀寫操作流程如下：當(dāng)一個(gè)請求進(jìn)來的時(shí)候，直接寫入內(nèi)存中的一個(gè) MemTable，如果 MemTable 沒寫滿，就直接返回請求。因此它處理寫請求的性能是很高的。當(dāng) MemTable 滿的時(shí)候，會(huì)生成一個(gè)不可寫的、只讀的 Immutable MemTable，同時(shí)生成新的可寫的 MemTable，以供后續(xù)使用。然后 Immutable MemTable 就會(huì)寫到磁盤上，形成一個(gè) SST 文件。SST 文件在寫盤的時(shí)候，會(huì)根據(jù) Key 排序，從而實(shí)現(xiàn)順序的邊迭代。其落盤結(jié)構(gòu)的 SST 文件也是分層來組織的。從內(nèi)存中直接寫出來的第 0 層達(dá)到一定數(shù)據(jù)量大小的時(shí)候，或者觸發(fā)某種條件的時(shí)候，就會(huì)進(jìn)行一個(gè)歸并排序，歸并排序就是一個(gè) Compaction 的過程。合并出來的第一層的 SST 文件，都是按照 Key 的順序?qū)懪诺?。讀取的時(shí)候是先去內(nèi)存中的 MemTable 查找，找到了就返回，如果沒有找到就去第 0 層的 SST 文件中查找，找不到再去第 1 層，這樣逐層查找，一直到找到需要讀取的 Key 為止。

使用 SST 文件進(jìn)行存儲(chǔ)的一個(gè)關(guān)鍵就是設(shè)計(jì)邊的 Key。因?yàn)樵?SST 文件中，Key 是有序排列的，所以我們需要通過 LSMTree 來實(shí)現(xiàn)免索引連接的能力。關(guān)鍵點(diǎn)就是合理地設(shè)計(jì)邊的 Key，使一個(gè)點(diǎn)所有邊在排序后是相鄰的。說起來比較拗口，其實(shí)實(shí)現(xiàn)起來并不難。

我們看一下這個(gè)例子。只要把邊 Key 的最高位放起始點(diǎn) ID，那么后面無論是邊的其它什么信息，都可以讓從起始點(diǎn) ID 出發(fā)的邊自然地排序排在一起。這里也可以加入一個(gè)編號(hào)的字段，因?yàn)閮牲c(diǎn)之間，起始點(diǎn)和終止點(diǎn) Meta 這些是固定的，編號(hào)字段加入之后，就可以支持在兩點(diǎn)之間同類型的多條邊共存。因?yàn)檫@是一個(gè) KV 結(jié)構(gòu)。如果只有起始點(diǎn)、終止點(diǎn)和 Meta，兩點(diǎn)之間同類型的邊只能存在一條。所以比如轉(zhuǎn)賬交易或者是訪問記錄這些具有事件性質(zhì)的邊要存多條，可以加一個(gè)編號(hào)。當(dāng)然也不一定都是必須從起始點(diǎn)開始來做邊的 Key。

比如在例 2 中，把 type 邊類型放在高位。它就可以先以 type 進(jìn)行劃分，后面才是起始點(diǎn)。這種方法也比較適合在分布式場景下按類型做分片，這樣同一類型的邊就會(huì)排在相鄰的分片中，有利于提高分布式查詢的性能。使用這個(gè)方式，有非常高的寫入性能，并且讀取的時(shí)候也能提供免索引連接的能力。

但是其實(shí)它也并不完美，也有很多問題需要克服。首先是讀性能，在讀的時(shí)候，如果內(nèi)存沒有命中，下面是一個(gè)逐層的 SST 文件，去找 Key 的最壞情況，可能要把所有層的 SST 文件全部找完，才能找到合適的 Key。所以它的免索引連接是比較依賴于Compaction 操作的。只有在理想情況下，比如在一個(gè)完整的 Compaction 完成的情況下，它才能真正實(shí)現(xiàn)免索引連接，否則會(huì)在各個(gè) SST 文件內(nèi)部去查找。在整體上，它并沒有完整地達(dá)到不去利用其它結(jié)構(gòu)就能夠進(jìn)行快速的領(lǐng)域迭代。

而做 Compaction 又是一個(gè)有比較大的磁盤 IO 的操作，并且如果使用的是第三方的存儲(chǔ)結(jié)構(gòu)，那么做 Compaction 的操作是不受圖數(shù)據(jù)庫本身控制的，可能是由一些其它的機(jī)制觸發(fā)的，比如是在前臺(tái)負(fù)載壓力比較大的情況下觸發(fā)了 Compaction，這樣實(shí)際在使用的時(shí)候會(huì)出現(xiàn)一些瓶頸，所以必須要對第三方存儲(chǔ)進(jìn)行比較深度的改動(dòng)，才能夠更好地優(yōu)化。

可以看到，各種實(shí)現(xiàn)免索引連接的存儲(chǔ)方式都不是一勞永逸的，而是有各自的優(yōu)勢和短板。通過數(shù)組的方式讀取速度快，但是寫入因?yàn)樯婕暗阶冮L的問題，可能會(huì)比較慢。通過 LSM 樹的方式寫入速度快，但是讀的時(shí)候又依賴于 Compaction 操作，在 Compaction 沒有完成的情況下，它的讀取速度也比較慢。通過鏈表的方式讀取和寫入速度都不占優(yōu)，但是它的靈活性卻最高，因?yàn)樗且?offset 形式的指針來實(shí)現(xiàn)的。

在實(shí)際商業(yè)圖數(shù)據(jù)庫的實(shí)現(xiàn)過程中，需要根據(jù)設(shè)計(jì)理念去做取舍。也可以結(jié)合兩種或者多種方案的優(yōu)點(diǎn)，在不同的數(shù)據(jù)形式下，靈活地實(shí)現(xiàn)不同類型的存儲(chǔ)。還有一些其它的問題，比如分區(qū)分片、反向邊一致性、如何支持事務(wù)、數(shù)據(jù)索引怎么做、數(shù)據(jù)過期等等，都是要解決的問題，實(shí)現(xiàn)起來還是比較復(fù)雜的。

四、Galaxybase 圖數(shù)據(jù)庫應(yīng)用實(shí)踐

接下來介紹 Galaxybase 圖數(shù)據(jù)庫的一些應(yīng)用實(shí)踐。

Galaxybase 是創(chuàng)鄰研發(fā)的國產(chǎn)高性能分布式圖平臺(tái)，它的特點(diǎn)是速度快、高擴(kuò)展、實(shí)時(shí)計(jì)算，支持一個(gè)知識(shí)中臺(tái)，并且安全自主可控。

使用原生分布式并行圖存儲(chǔ)，實(shí)現(xiàn)了存儲(chǔ)層的免索引連接，可以毫秒級完成傳統(tǒng)方案無法完成的深鏈分析，較同類技術(shù)有數(shù)百倍的提升。使用完全分布式的架構(gòu)，支持動(dòng)態(tài)在線擴(kuò)容，高效支持萬億級超級大圖。也內(nèi)置了非常豐富的圖算法，包括分布式圖算法和單機(jī)圖算法，不需要 ETL 就能實(shí)現(xiàn)實(shí)時(shí)圖分析。底層存儲(chǔ)包含數(shù)據(jù)壓縮的能力，可以優(yōu)化資源利用，節(jié)省硬件和維護(hù)成本。有一個(gè)可視化交互的知識(shí)中臺(tái)，便于業(yè)務(wù)理解和操作，幫助數(shù)據(jù)價(jià)值快速變現(xiàn)。同時(shí)也是完全自主可控的，全面兼容國產(chǎn)底層軟硬件。

這是 Galaxybase 的架構(gòu)圖，中間部分是整體的核心部分。底層使用了數(shù)據(jù)分片動(dòng)態(tài)壓縮的分布式存儲(chǔ)技術(shù)，支持屬性圖的存儲(chǔ)模型，并且實(shí)現(xiàn)了原生圖存儲(chǔ)。

存儲(chǔ)層之上是計(jì)算層，實(shí)現(xiàn)了內(nèi)置的圖計(jì)算引擎，包含了單機(jī)的圖算法和分布式圖算法，并且還可以由用戶來自定義一些定制化函數(shù)，來實(shí)現(xiàn)自己的高效算法。

再往上是接口層，支持 Java、Python、Go、Rest 的 API。并且可視化的模塊也可以以接口的方式嵌入到其它第三方頁面中。

左側(cè)可以看到，支持多源異構(gòu)數(shù)據(jù)，比如傳統(tǒng)關(guān)系庫、CSV 文件、HDFS、實(shí)時(shí)流數(shù)據(jù)等等，都可以直接進(jìn)行數(shù)據(jù)導(dǎo)入。

底層適配了各種操作系統(tǒng)，支持各種國產(chǎn)和非國產(chǎn)的主流操作系統(tǒng)。也支持國產(chǎn)的各種 CPU。

在上面可以構(gòu)建一個(gè)圖智能中臺(tái)，包括圖工作流管理和可視化分析。在中臺(tái)之上，可以在各種的業(yè)務(wù)場景下提供不同的業(yè)務(wù)解決方案。

Galaxybase 的一個(gè)性能優(yōu)勢，是能夠高效地進(jìn)行分布式圖計(jì)算，并且實(shí)現(xiàn)了當(dāng)前最大規(guī)模的圖數(shù)據(jù)處理，實(shí)現(xiàn)了 5 萬億超大規(guī)模的分布式圖存儲(chǔ)。在線查詢僅使用了 50 臺(tái)機(jī)器的集群，出入度最大有 1000 萬的超級節(jié)點(diǎn)，6 跳的平均查詢時(shí)間僅為 6.7 秒。這是與中山大學(xué)攜手共建的一個(gè)圖計(jì)算項(xiàng)目。

Galaxybase 還具備非常高效的查詢性能。在 LDBC 的 SNB 測試?yán)锩?，去年我們做了一個(gè)官方的 Audit，打破了一項(xiàng)世界記錄，較之前的吞吐量提升 70%，平均查詢性能有 6 倍以上的提升，最高的 95 分位查詢性能提升達(dá)到 72 倍。

Galaxybase 支持非常豐富的圖算法，包括 57 種圖算法，其中 28 種已經(jīng)支持了分布式，其它一些分布式算法也正在實(shí)現(xiàn)中。我們也是首家完成信通院圖計(jì)算評測的一個(gè)圖計(jì)算平臺(tái)。

我們的產(chǎn)品里面還包括一個(gè)圖智能中臺(tái)，主要是通過可視化界面的方式來進(jìn)行交互式的探索，完成圖的一些定性分析，包括搜索頂點(diǎn)、點(diǎn)邊位置擴(kuò)展、查找路徑，還有各種混合的布局。布局模式有各種方式混合的搭配，還可以和自定義的地圖進(jìn)行匹配，支持時(shí)序演進(jìn)分析等功能。

Galaxybase 是一款完全國產(chǎn)自主可控的產(chǎn)品。內(nèi)核的存儲(chǔ)、計(jì)算、查詢的代碼完全都是自研的，不依賴于其它第三方開源框架。也完成了各種操作系統(tǒng)和 CPU 的國產(chǎn)信創(chuàng)適配認(rèn)證，并且獲得了信創(chuàng)的一些相關(guān)獎(jiǎng)項(xiàng)。

我們提供各種圖場景的解決方案，有很多合作伙伴，有很多已經(jīng)在金融、能源、教育、互聯(lián)網(wǎng)、政府多個(gè)行業(yè)中的頭部客戶落地的使用場景，并且已經(jīng)服務(wù)了幾年時(shí)間。

五、問答環(huán)節(jié)Q1：針對大 value，比如大于 4K 的數(shù)據(jù)，隨機(jī)讀取的時(shí)候會(huì)非常耗 IO，這塊有什么優(yōu)化嗎？

A1：一般來說，圖數(shù)據(jù)庫里如果是一個(gè)屬性值，單個(gè)屬性值大于 4K，其實(shí)我們不建議把它放到圖數(shù)據(jù)庫中來，因?yàn)閳D數(shù)據(jù)庫主要是做點(diǎn)邊的關(guān)聯(lián)鄰居查找的。如果單個(gè)屬性大于 4K，可能是一個(gè)很長的文本。在這個(gè)上面做圖的分析，價(jià)值并不大。如果這個(gè)是要作為一個(gè)存儲(chǔ)放進(jìn)來的話，最好是把它單獨(dú)放在一個(gè)另外的區(qū)域中，不要跟點(diǎn)邊正常的這些屬性來放在一起。

如果指的是點(diǎn)邊的結(jié)構(gòu)，可能某一個(gè)點(diǎn)的鄰居特別多，會(huì)就這種超級節(jié)點(diǎn)的情況把它存在一起。針對鄰居存儲(chǔ)的數(shù)量非常大的情況，涉及到一個(gè)圖切分的概念。通常情況下我們更多使用的是一個(gè)邊切割，所以所有點(diǎn)的鄰居都會(huì)存在一起，這樣能更高效地來訪問一個(gè)點(diǎn)的所有鄰居。

當(dāng)一個(gè)點(diǎn)的鄰居數(shù)量特別大的時(shí)候，這里可能都不只是 4K 量級，可能會(huì)有 400M 或者 4G 這樣的量級，這種情況下的切割就會(huì)形成單個(gè)非常大的文件。這種時(shí)候也可以考慮動(dòng)態(tài)的點(diǎn)切割的方式，就是把一個(gè)點(diǎn)的鄰居，再切割成多個(gè)存儲(chǔ)文件，存儲(chǔ)文件可以在不同的分區(qū)里，可以在不同的分片下，這樣就可以實(shí)現(xiàn)并行迭代的方式。

當(dāng)然這里的技術(shù)會(huì)更復(fù)雜，需要首先有對邊進(jìn)行唯一定位的能力，有這個(gè)能力之后，就可以在這一個(gè)點(diǎn)的所有鄰居邊上，再進(jìn)行進(jìn)一步的切割，然后把大文件再分成不同的小文件。這也是常見的處理超級節(jié)點(diǎn)的一個(gè)方式。

Q2：在查詢路徑時(shí)，如果有超級節(jié)點(diǎn)，返回所有的路徑會(huì)不會(huì)有問題？一般怎么處理？

A2：這要結(jié)合業(yè)務(wù)需求查詢所有路徑。比如有的圖很大的時(shí)候，全部路徑的數(shù)量會(huì)是一個(gè)天文數(shù)字，那么返回所有路徑可能就沒有意義了。這時(shí)候更好的方式是，要了解我們要路徑去做什么。在路徑上可能要做一些計(jì)算，或者做一些聚合，做一些其它的操作。在做這些計(jì)算的時(shí)候，就不是簡單地返回路徑，而是把路徑上面的計(jì)算也一起做了，得到一個(gè)最后的計(jì)算結(jié)果。如果是路徑數(shù)量沒有那么大的情況下，也是可以逐條返回的。通常我們可以用寫輸出一個(gè)文件或者其它的方式，來返回所有路徑。

Q3：底層數(shù)據(jù)壓縮對圖性能的影響有多大？

A3：肯定是有影響的，因?yàn)閴嚎s畢竟也要占 CPU，所以這其實(shí)是個(gè)可選項(xiàng)，要看我們的需求是對讀寫性能更敏感，還是對磁盤空間更敏感。因?yàn)橐灿幸恍?yīng)用，不是實(shí)時(shí)的情況下，其實(shí)對延遲沒有那么敏感，但它的數(shù)據(jù)量可能很大。這時(shí)候我們可以通過底層數(shù)據(jù)壓縮的方式來節(jié)省磁盤空間。當(dāng)然，如果是對實(shí)時(shí)性能要求比較高的情況下，肯定是不壓縮，直接讀寫性能更高。因此可以根據(jù)場景來決定。

Q4：怎么做無 ETL 的實(shí)時(shí)圖計(jì)算？如果直接從存儲(chǔ)層迭代出來的數(shù)據(jù)怎么解決一致性的問題？如果用 snapshot 就會(huì)有 ETL。

A4：可能要這樣解釋一下我們這個(gè)產(chǎn)品，它是存儲(chǔ)、計(jì)算都包含的，它是自帶了存儲(chǔ)層和計(jì)算層，所以用 snapshot 不需要 ETL 過程，相當(dāng)于我們自己的計(jì)算引擎可以去加載存儲(chǔ)里面的數(shù)據(jù)，也不需要再做一個(gè)數(shù)據(jù)清理或者是轉(zhuǎn)換的過程?？梢赃x擇你需要用的一些點(diǎn)邊類型或者屬性類型做篩選，去生成一個(gè)圖計(jì)算引擎。

一般我們在做一個(gè)圖計(jì)算的時(shí)候，其實(shí)都是在一個(gè) snapshot 上做圖計(jì)算，不然整個(gè)計(jì)算結(jié)果也沒有一致性。所以我們會(huì)加載圖存儲(chǔ)的某一個(gè)時(shí)間切片的一個(gè)時(shí)間點(diǎn)的 snapshot 到圖計(jì)算引擎中，來做圖計(jì)算。

關(guān)鍵詞：