導(dǎo)讀：你想知道百億級(jí)圖譜如何實(shí)現(xiàn)毫秒級(jí)查詢嗎？社區(qū)眾多的圖數(shù)據(jù)庫(kù)中如何才能挑選到一款適合實(shí)際應(yīng)用場(chǎng)景的圖數(shù)據(jù)庫(kù)呢？貝殼找房的行業(yè)圖譜480億量級(jí)的三元組究竟是如何存儲(chǔ)的呢？本文將帶你探索上述問(wèn)題并從中得到解答。本次分享題目為"分布式圖數(shù)據(jù)庫(kù)在貝殼找房的應(yīng)用實(shí)踐"，共分為以下五大塊內(nèi)容：

• 圖數(shù)據(jù)庫(kù)簡(jiǎn)介

• 圖數(shù)據(jù)庫(kù)技術(shù)選型

• 圖數(shù)據(jù)庫(kù)平臺(tái)建設(shè)

• 原理&優(yōu)化&不足

• 未來(lái)規(guī)劃

01

圖數(shù)據(jù)庫(kù)簡(jiǎn)介

先來(lái)看一個(gè)問(wèn)題：貝殼找房最大的圖譜——行業(yè)圖譜，目前量級(jí)已經(jīng)達(dá)了480億三元組，如此海量的圖譜數(shù)據(jù)究竟應(yīng)該如何存儲(chǔ)，如何查詢，才能滿足高并發(fā)場(chǎng)景下的毫秒級(jí)響應(yīng)，從而支持貝殼業(yè)務(wù)的快速發(fā)展呢？我們帶著這個(gè)問(wèn)題開始本次的分享。

1. 為什么需要圖數(shù)據(jù)庫(kù)？

貝殼的行業(yè)圖譜中包含了很多信息，比如房源、客戶、經(jīng)紀(jì)人、開發(fā)商、小區(qū)、地鐵、醫(yī)院、學(xué)校、超市、電影院等等；

我們假設(shè)這樣一種特殊的查詢場(chǎng)景：找出開發(fā)商是XXX，小區(qū)綠化率大于30%，周邊200米有大型超市，500米有地鐵，1000米有三甲醫(yī)院，2000米有升學(xué)率超過(guò)60%的高中，房?jī)r(jià)在800W以內(nèi)，最近被經(jīng)紀(jì)人帶看次數(shù)最多的房子。

這可能是一個(gè)客戶想要的房子，但是各位覺得有哪個(gè)產(chǎn)品可以支持么？如果說(shuō)我們用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，MySQL或者Oracle可以嗎？那是不是我們要關(guān)聯(lián)房源表、客戶表、經(jīng)紀(jì)人表、開發(fā)商表等等，一次關(guān)聯(lián)幾十張表才可能得到想要的結(jié)果？但明顯這是不現(xiàn)實(shí)的；那ES ( Elasticsearch ) 可以嗎？ES在搜索領(lǐng)域非?；穑梢越鉀Q嗎？其實(shí)ES也是解決不了的，ES要搜這樣的房源，肯定是需要有一張很寬的房源表，那怎么搜索這套房源周邊200米有大型超市？難道要建距離周邊超市的距離這樣一個(gè)字段嗎？顯然也是不現(xiàn)實(shí)的；HBase更不用說(shuō)了。所以顯而易見這種行業(yè)圖譜的數(shù)據(jù)只能使用圖數(shù)據(jù)庫(kù)，比如Neo4j這樣的存儲(chǔ)引擎才可以支持。

2. 圖數(shù)據(jù)庫(kù)簡(jiǎn)介

簡(jiǎn)單介紹一下圖數(shù)據(jù)庫(kù)，什么是圖數(shù)據(jù)庫(kù)？

• 不是存儲(chǔ)圖片的數(shù)據(jù)庫(kù)

• 存儲(chǔ)節(jié)點(diǎn)和關(guān)系，以圖結(jié)構(gòu)存儲(chǔ)和查詢

應(yīng)用場(chǎng)景非常廣泛，遠(yuǎn)不止我們聊到的行業(yè)圖譜、知識(shí)圖譜這些，它包含：

• 社交網(wǎng)絡(luò)、計(jì)算機(jī)網(wǎng)絡(luò)、道路網(wǎng)絡(luò)、電信網(wǎng)絡(luò)

• 關(guān)聯(lián)查詢，搜索推薦

• 風(fēng)險(xiǎn)預(yù)測(cè)，風(fēng)控管理

• 業(yè)務(wù)流程，生物流程

• 公司或市場(chǎng)結(jié)構(gòu)

• 事件及其之間的因果關(guān)系或其他聯(lián)系

還有很多其他領(lǐng)域都可以使用圖數(shù)據(jù)庫(kù)來(lái)解決。

這是DB-Engines上的各種類型數(shù)據(jù)庫(kù)的流行度趨勢(shì)圖，可以明顯的看出圖數(shù)據(jù)庫(kù)在近兩年來(lái)越來(lái)越流行，越來(lái)越被大眾所關(guān)注。

這是圖數(shù)據(jù)庫(kù)領(lǐng)域的各類產(chǎn)品，排名第一的就是大家最熟悉的Neo4j，下面還有很多開源的、閉源的、單機(jī)的、分布式的等等各種圖數(shù)據(jù)庫(kù)，產(chǎn)品非常繁多。

02

圖數(shù)據(jù)庫(kù)技術(shù)選型

剛才提到圖數(shù)據(jù)庫(kù)的應(yīng)用場(chǎng)景非常廣：搜索、推薦、關(guān)系圖譜、知識(shí)圖譜等等。目前貝殼也有各種場(chǎng)景需要使用到圖數(shù)據(jù)庫(kù)，但選型各不相同，有的部門使用JanusGraph，有的使用Neo4j，每個(gè)有需要的部門都得從頭搭建一套。所以我們想是不是應(yīng)該有一個(gè)通用的圖數(shù)據(jù)庫(kù)平臺(tái)，可以支撐所有需要使用圖數(shù)據(jù)庫(kù)的場(chǎng)景，然后讓做關(guān)系圖譜、行業(yè)圖譜的同學(xué)可以更關(guān)注于上層的算法和策略，而無(wú)需關(guān)注底層的存儲(chǔ)、分布式、高性能、高可用等等？答案顯然是確定的：我們需要這樣一個(gè)統(tǒng)一的圖數(shù)據(jù)庫(kù)平臺(tái)。那么目前圖數(shù)據(jù)庫(kù)領(lǐng)域已經(jīng)有這么多產(chǎn)品，要做圖數(shù)據(jù)庫(kù)平臺(tái)的話，到底應(yīng)該選用哪一個(gè)呢？所以我們進(jìn)入第二個(gè)主題，圖數(shù)據(jù)庫(kù)的技術(shù)選型。

1. 圖數(shù)據(jù)庫(kù)技術(shù)選型

當(dāng)我們進(jìn)行圖數(shù)據(jù)庫(kù)技術(shù)選型的時(shí)候，我們具體需要關(guān)注哪些指標(biāo)？哪些因素會(huì)影響我們的決策呢？我們主要關(guān)注以下幾個(gè)方面：開源、成熟度、可擴(kuò)展性、文檔豐富度、性能、穩(wěn)定性、運(yùn)維成本、易用性。其中運(yùn)維成本是比較容易忽視的，但我們做技術(shù)選型時(shí)必須考慮清楚，每種選型的運(yùn)維成本是否是可接受的，投入產(chǎn)出比是否值得。

前面看到圖數(shù)據(jù)庫(kù)雖然有很多種，但實(shí)際上開源的、流行的圖數(shù)據(jù)庫(kù)就只有以下幾種：Neo4j、OrientDB、ArangoDB、JanusGraph、Dgraph，Neo4j實(shí)際上是用來(lái)做對(duì)比的，OrientDB和ArangoDB都是老牌的圖數(shù)據(jù)庫(kù)了，發(fā)展比較早，從2012、2013年就開始做了，JanusGraph和Dgraph是比較新的，從2016、2017年才開始做。

2. 主流圖數(shù)據(jù)庫(kù)對(duì)比

那它們的主要區(qū)別是什么呢？我們將上述主流的圖數(shù)據(jù)庫(kù)做一下調(diào)研，先簡(jiǎn)單粗略的對(duì)比分析一下：

Neo4j歷史悠久，且長(zhǎng)期處于圖數(shù)據(jù)庫(kù)領(lǐng)域的龍頭地位，那為什么不考慮它呢？原因很簡(jiǎn)單，因?yàn)樗_源的社區(qū)版本只支持單機(jī)，不支持分布式。

OrientDB和ArangoDB它們起步比較早，最初的時(shí)候都是一個(gè)單機(jī)的圖數(shù)據(jù)庫(kù)，然后隨著用戶數(shù)據(jù)量的不斷增加，后期增加了分布式模式，支持集群和副本，但是經(jīng)過(guò)調(diào)研發(fā)現(xiàn)，可能是由于后加的功能，他們的分布式支持的不是很好。

所以主要注意力放到了JanusGraph和Dgraph上，他們發(fā)展的比較晚，從設(shè)計(jì)之初就考慮了分布式和擴(kuò)展性，所以對(duì)分布式支持的非常好，也都是完全的開源免費(fèi)，存儲(chǔ)數(shù)據(jù)模型也都是專為圖數(shù)據(jù)而設(shè)計(jì)。他們有一個(gè)比較大的區(qū)別就是，JanusGraph的存儲(chǔ)需要依賴于其他存儲(chǔ)系統(tǒng)，而Dgraph使用自身的存儲(chǔ)系統(tǒng)，這就造成了前面提到的運(yùn)維成本的問(wèn)題。例如JanusGraph多數(shù)使用HBase作為底層存儲(chǔ)系統(tǒng)，而HBase又依賴于Zookeeper和HDFS，另外JanusGraph的索引又依賴于ES，所以想要搭建一套完整的JanusGraph，需要同時(shí)搭建維護(hù)好幾套系統(tǒng)，維護(hù)成本非常大；而Dgraph這些都是原生支持的，所以相對(duì)來(lái)說(shuō)，Dgraph維護(hù)成本低很多。

下面我們具體對(duì)比一下二者的架構(gòu)。

3. JanusGraph架構(gòu)

前文提到，JanusGraph的存儲(chǔ)系統(tǒng)依賴于像Cassandra、HBase、BerkelyDB等等這樣的存儲(chǔ)系統(tǒng)，索引系統(tǒng)依賴于Elasticsearch、Solr、Lucene等等；也基于這些原因，它和大數(shù)據(jù)生態(tài)結(jié)合的非常好，可以很好地和Spark結(jié)合做一些大型的圖計(jì)算；但缺點(diǎn)就是它的維護(hù)成本會(huì)非常高，依賴于這么多的外部系統(tǒng)，搭建一套JanusGraph系統(tǒng)的同時(shí)需要搭建好幾套依賴系統(tǒng)；另一方面就是穩(wěn)定性，根據(jù)經(jīng)驗(yàn)來(lái)看，系統(tǒng)越復(fù)雜，依賴系統(tǒng)越多，整體可控性就越差，穩(wěn)定性風(fēng)險(xiǎn)就越大。

4. Dgraph架構(gòu)

這是Dgraph的架構(gòu)，它的架構(gòu)其實(shí)非常簡(jiǎn)單，所有功能都是原生支持的，不依賴于任何第三方系統(tǒng)，右圖從下往上看：

• zero：集群大腦，用于控制集群，將服務(wù)器分配到一個(gè)組，并均衡數(shù)據(jù)。通過(guò)raft選主；相當(dāng)于hadoop的namenode或者Elasticsearch的master。

• alpha：存儲(chǔ)數(shù)據(jù)并處理查詢，托管謂詞和索引，即datanode。

• group：多個(gè)alpha組成一個(gè)group，數(shù)據(jù)分片存儲(chǔ)到不同group，每個(gè)group內(nèi)數(shù)據(jù)通過(guò)raft保證強(qiáng)一致性。

• ratel：可視化界面，用戶可通過(guò)界面來(lái)執(zhí)行查詢，更新或修改schema。

• 同時(shí)Dgraph還支持gRPC或者HTTP來(lái)連接alpha進(jìn)行寫入或查詢。

Dgraph只有一個(gè)可執(zhí)行文件，通過(guò)指定不同的參數(shù)在不同的機(jī)器上啟動(dòng)，就能自動(dòng)組成集群，無(wú)需搭建維護(hù)其他任何第三方系統(tǒng)，這是它的優(yōu)勢(shì)。那是不是就能通過(guò)這樣的架構(gòu)對(duì)比，因Dgraph運(yùn)維簡(jiǎn)單就直接選擇它呢？肯定不行，我們還需要做一些性能壓測(cè)來(lái)對(duì)比，如果說(shuō)JanusGraph的性能是Dgraph的好幾倍，那維護(hù)成本高些也是可以接受的。所以基于這個(gè)目的，我們對(duì)這兩個(gè)圖數(shù)據(jù)庫(kù)做了詳細(xì)的性能對(duì)比測(cè)試。

5. JanusGraph和Dgraph性能對(duì)比

在48核、128G內(nèi)存、SATA硬盤的三臺(tái)物理機(jī)環(huán)境，4800萬(wàn)個(gè)點(diǎn)、6300萬(wàn)條邊、4.5億三元組、總計(jì)30G的數(shù)據(jù)集下進(jìn)行性能對(duì)比測(cè)試：

• 寫入性能維度來(lái)看，分為實(shí)時(shí)寫入和初始化寫入三元組兩種，在實(shí)時(shí)寫入對(duì)比中，點(diǎn)的寫入性能：JanusGraph達(dá)到15000/s，Dgraph達(dá)到35000/s；邊的寫入性能：JanusGraph達(dá)到9000/s，Dgraph達(dá)到10000/s。

• 查詢性能維度來(lái)看，相差較大，主要測(cè)試圖數(shù)據(jù)庫(kù)典型的幾種場(chǎng)景，比如點(diǎn)的屬性，點(diǎn)的一度、二度、三度關(guān)系，包括最短路徑等等。大家可以從表中看到，在簡(jiǎn)單查詢的場(chǎng)景下，比如查詢點(diǎn)的屬性、點(diǎn)的一度關(guān)系時(shí)，二者都是毫秒級(jí)別的，沒(méi)有太大的性能差別；但是隨著查詢?cè)絹?lái)越復(fù)雜，JanusGraph的查詢?cè)絹?lái)越慢，最后查到三度的頂點(diǎn)和屬性要消耗700多毫秒，但Dgraph一直保持在幾毫秒之內(nèi)。

所以可以看出Dgraph相對(duì)JanusGraph的查詢性能的優(yōu)勢(shì)是非常大的。

6. JanusGraph VS Dgraph

總結(jié)一下兩種圖數(shù)據(jù)庫(kù)特性的對(duì)比：

• 架構(gòu)方面：Dgraph是分布式的，而JanusGraph構(gòu)建于其他分布式數(shù)據(jù)庫(kù)之上。

• 副本方面：Dgraph是強(qiáng)一致性的，JanusGraph需要依賴底層的存儲(chǔ)DB。

• 數(shù)據(jù)均衡方面：Dgraph支持自動(dòng)均衡，JanusGraph也是依賴底層的存儲(chǔ)DB。

• 語(yǔ)言方面：JanusGraph使用了比較常用的Gremlin，而Dgraph使用基于GraphQL改進(jìn)的GraphQL+-。

• 全文檢索、正則表達(dá)式、地理位置檢索方面：Dgraph是原生支持的，JanusGraph依賴外部檢索系統(tǒng)。

• 可視化方面：Dgraph有自己的可視化系統(tǒng)，JanusGraph依賴外部系統(tǒng)。

• 維護(hù)成本方面：由于不依賴其他系統(tǒng)，Dgraph遠(yuǎn)低于JanusGraph。 

• 寫入性能方面：Dgraph稍高一些。

• 查詢性能方面：深度查詢時(shí)，Dgraph性能遠(yuǎn)高于JanusGraph。

所以基于以上對(duì)比，我們最終選擇了使用Dgraph來(lái)構(gòu)建我們的圖數(shù)據(jù)庫(kù)平臺(tái)。

03

圖數(shù)據(jù)庫(kù)平臺(tái)建設(shè)

在圖數(shù)據(jù)庫(kù)選型確定后，就需要真正地把圖數(shù)據(jù)庫(kù)平臺(tái)搭建起來(lái)。

1. 集群的建設(shè)

上文提到，搭建Dgraph集群其實(shí)非常簡(jiǎn)單，我們使用docker+k8s技術(shù)對(duì)Dgraph進(jìn)行統(tǒng)一的容器化部署和管理。如圖使用三臺(tái)服務(wù)器，每臺(tái)服務(wù)器上啟動(dòng)四個(gè)節(jié)點(diǎn)，其中三個(gè)是Alpha節(jié)點(diǎn)，就是存儲(chǔ)數(shù)據(jù)、索引、執(zhí)行查詢的節(jié)點(diǎn)，一個(gè)zero節(jié)點(diǎn)，是Dgraph的控制節(jié)點(diǎn)；需要注意到的一點(diǎn)是，每個(gè)Group的3個(gè)Alpha用于存儲(chǔ)同一份數(shù)據(jù)的三個(gè)副本，一個(gè)Group的不同的Alpha肯定是不能在同一臺(tái)機(jī)器的，而哪幾個(gè)Alpha組成一個(gè)Group是zero根據(jù)副本數(shù)來(lái)確定的，比如dgraph zero -- replicas 3這樣啟動(dòng)時(shí)候就指定三個(gè)副本數(shù)，并且根據(jù)Alpha的啟動(dòng)順序來(lái)確定。所以有個(gè)啟動(dòng)技巧就是，先在第一臺(tái)服務(wù)器上啟動(dòng)Alpha1，然后切到第二胎服務(wù)器上啟動(dòng)Alpha2，再到第三臺(tái)服務(wù)器上啟動(dòng)Alpha3，這三個(gè)先啟動(dòng)的Alpha組成第一個(gè)Group；然后輪流順序地啟動(dòng)其他的Alpha 4、5、6組成第二個(gè)Group，7、8、9組成第三個(gè)Group，不能直接在第一臺(tái)服務(wù)器上直接啟動(dòng)123，這樣組成一個(gè)Group是無(wú)法保證高可用的，因?yàn)楫?dāng)這一臺(tái)機(jī)器掛掉之后三個(gè)副本就全部丟失了。

左側(cè)是Dgraph的啟動(dòng)命令，啟動(dòng)zero時(shí)候指定一下副本數(shù)量；啟動(dòng)alpha的時(shí)候，指定一下zero的地址就可以了；這樣就啟動(dòng)了一個(gè)Dgraph集群，由此可見，它的搭建和維護(hù)成本確定很低。

2. 數(shù)據(jù)寫入

集群搭建好了以后，就要考慮數(shù)據(jù)的寫入了，因?yàn)槭且鲆粋€(gè)通用的圖數(shù)據(jù)庫(kù)平臺(tái)，所以要考慮多種的數(shù)據(jù)寫入模式，比如實(shí)時(shí)數(shù)據(jù)流、批量數(shù)據(jù)流和初始化數(shù)據(jù)流。

實(shí)時(shí)數(shù)據(jù)流模式：有一個(gè)Data-Accepter模塊，用戶可以將實(shí)時(shí)變更的數(shù)據(jù)用過(guò)這個(gè)模塊推過(guò)來(lái)，然后通過(guò)Kafka做異步消峰，寫到Kafka隊(duì)列里面，后面有Graph-Import模塊從Kafka將數(shù)據(jù)取出寫到Dgraph集群。

批量數(shù)據(jù)流模式：比如說(shuō)要做全量的數(shù)據(jù)更新，目前貝殼大部分的行業(yè)圖譜數(shù)據(jù)都是存在Hive或者是HDFS中的，這時(shí)候會(huì)有一個(gè)Hive2Kafka的spark任務(wù)，從用戶的Hive表或者HDFS拿到全部的圖譜數(shù)據(jù)，同樣寫入Kafka，最后通過(guò)Graph-Import模塊從Kafka取出數(shù)據(jù)寫入Dgraph集群。

初始化數(shù)據(jù)流模式：Dgraph還有一個(gè)不同點(diǎn)就是支持?jǐn)?shù)據(jù)初始化導(dǎo)入，這個(gè)導(dǎo)入是非?？斓?，比如像行業(yè)圖譜這樣的480億數(shù)據(jù)，第一次全部導(dǎo)入，按照這種數(shù)據(jù)流的模式一條條去寫一定是要花很多時(shí)間的，所以采用Dgraph提供的初始化導(dǎo)入，使用Dgraph的Bulk Loader接口，通過(guò)MapReduce的方式預(yù)先生成它的數(shù)據(jù)文件和索引文件，然后再啟動(dòng)Dgraph的Alpha節(jié)點(diǎn)去加載這些文件，這樣可以實(shí)現(xiàn)非?？斓某跏蓟瘜?dǎo)入，后面會(huì)詳細(xì)說(shuō)這塊內(nèi)容。所以我們也支持這種初始化數(shù)據(jù)流，通過(guò)腳本可以一鍵式的完成初始化數(shù)據(jù)生成，然后調(diào)用k8s接口啟動(dòng)一個(gè)Dgraph集群，再加載生成好的數(shù)據(jù)，最后返回一個(gè)查詢API接口給Dgraph的使用方。

3. 數(shù)據(jù)查詢 

完成數(shù)據(jù)導(dǎo)入之后，接下來(lái)就是數(shù)據(jù)查詢了，上圖為Dgraph的可視化界面Ratel，左邊輸入一個(gè)查詢語(yǔ)句之后，右邊就會(huì)出現(xiàn)相應(yīng)圖的展示；這個(gè)例子是要查出名字包含“秀園”，綠化率大于百分之三十的小區(qū)的附近一千米內(nèi)的所有幼兒園。右邊展示圖的下面可以看到Dgraph的服務(wù)端查詢只花了24毫秒，加上來(lái)回網(wǎng)絡(luò)開銷總計(jì)也就91毫秒，非常的快。

4. Graph SQL

最上面就是Dgraph的查詢語(yǔ)句，大家可以感受一下，并不是那么簡(jiǎn)單，是需要一定的學(xué)習(xí)成本的。而我們前面說(shuō)到建設(shè)圖數(shù)據(jù)庫(kù)平臺(tái)需要考慮易用性，需要盡量簡(jiǎn)化使用方的學(xué)習(xí)成本，所以需要考慮是否有更簡(jiǎn)單的查詢語(yǔ)法。

這種查詢?cè)贕remlin是怎么寫的呢？如圖，使用多個(gè)has然后select就可以篩選出來(lái)，但同樣不夠簡(jiǎn)單明了。

考慮到大部分程序員最熟悉的查詢語(yǔ)言就是SQL，甚至不是程序員，一些數(shù)據(jù)分析師也會(huì)SQL，那是否可以使用SQL對(duì)圖數(shù)據(jù)庫(kù)查詢？于是我們?cè)O(shè)計(jì)了一套使用SQL查詢圖數(shù)據(jù)庫(kù)的語(yǔ)言，稱之為Graph SQL。比如上圖最下面的語(yǔ)句：select小區(qū)名字、小區(qū)綠化率、幼兒園名字；from小區(qū)到幼兒園的這么一個(gè)關(guān)系，此處和SQL有所不同，不是from一個(gè)表，而是from一個(gè)小區(qū)到幼兒園的關(guān)系子圖；然后where小區(qū)名字包含"秀園"，綠化率大于30%，距離幼兒園的距離小于1000米。

上圖為目前我們提供的一個(gè)完整的基于SQL查圖的語(yǔ)法，增加了一些特定的圖的關(guān)鍵字，比如：shortestpath：查詢圖的最短路徑；degree：查詢一度關(guān)系、二度關(guān)系、三度關(guān)系等等；然后也支持查點(diǎn)、查邊、查節(jié)點(diǎn)的屬性等等，后面還有GROUP BY、HAVING、ORDER BY、LIMIT等等，LIMIT支持對(duì)點(diǎn)、也支持對(duì)邊進(jìn)行LIMIT；當(dāng)然目前只支持了一些簡(jiǎn)單的語(yǔ)法，后面復(fù)雜的查詢還在繼續(xù)完善中。通過(guò)支持這種類SQL的查詢語(yǔ)法，就可以極大的降低圖數(shù)據(jù)庫(kù)平臺(tái)的接入成本和學(xué)習(xí)成本。 

這是最終的一個(gè)實(shí)現(xiàn)效果，可以看到通過(guò)發(fā)送一個(gè)簡(jiǎn)單的HTTP請(qǐng)求，里面包含一個(gè)SQL查詢語(yǔ)句，可以很快的返回圖數(shù)據(jù)庫(kù)的查詢結(jié)果。

5. 整體架構(gòu)

匯總前面的集群搭建、數(shù)據(jù)寫入、數(shù)據(jù)查詢，再?gòu)?fù)用統(tǒng)一的服務(wù)治理框架，整合起來(lái)就是我們當(dāng)前圖數(shù)據(jù)庫(kù)平臺(tái)的整體架構(gòu)了：

統(tǒng)一的網(wǎng)關(guān)，用來(lái)做鑒權(quán)、分發(fā)、限流、熔斷和降級(jí)。

在網(wǎng)關(guān)之下有統(tǒng)一的數(shù)據(jù)流模塊和查詢層模塊：

• 數(shù)據(jù)流模塊包含數(shù)據(jù)源、數(shù)據(jù)接收、增量、全量、Kafka、數(shù)據(jù)導(dǎo)入。

• 查詢層模塊支持Graph-SQL，如果有Graph-SQL無(wú)法支持的查詢，也可以使用原生的GraphQL+-來(lái)進(jìn)行復(fù)雜的查詢，然后通過(guò)Graph-Client連接到底層的Dgraph集群執(zhí)行并返回結(jié)果。

其中：

• Dgraph集群整體是通過(guò)Docker+K8s虛擬化技術(shù)部署到物理機(jī)上的

• 右邊復(fù)用了貝殼搜索平臺(tái)的整體服務(wù)治理能力，所有微服務(wù)都通過(guò)注冊(cè)中心、配置中心、負(fù)載均衡、消息總線、熔斷降級(jí)、鏈路追蹤、監(jiān)控告警等技術(shù)進(jìn)行統(tǒng)一調(diào)度、管理、監(jiān)控等。

04

原理&優(yōu)化&不足

完成了圖數(shù)據(jù)庫(kù)平臺(tái)的搭建之后，相當(dāng)于只是完成了從0到1的工作，只是有了這樣一個(gè)圖數(shù)據(jù)庫(kù)平臺(tái)可用；下一步就是要完成從1到N 的過(guò)程，需要保證平臺(tái)的穩(wěn)定性、提升平臺(tái)的性能和體驗(yàn)，這是第二部分的工作。為了完成第二部分的工作，就需要對(duì)Dgraph做一些深入的學(xué)習(xí)、深入的理解、深入的優(yōu)化，需要知道它的優(yōu)勢(shì)和不足，知道他的底層的原理實(shí)現(xiàn)。

1. Dgraph原理

簡(jiǎn)單介紹一下Dgraph的原理：

① 存儲(chǔ)引擎：

Dgraph的存儲(chǔ)引擎是自研的Badger，完全由Go語(yǔ)言開發(fā)。最初Dgraph存儲(chǔ)也是使用RocksDB，但后來(lái)上層通過(guò)go調(diào)用，出現(xiàn)一些內(nèi)存溢出的問(wèn)題，于是Dgraph團(tuán)隊(duì)干脆自己用Go實(shí)現(xiàn)了一個(gè)高效的、持久化的，基于LSM的鍵值數(shù)據(jù)庫(kù)，并且號(hào)稱隨機(jī)讀比RocksDB快3.5倍

② 存儲(chǔ)結(jié)構(gòu) ( 因?yàn)榇鎯?chǔ)引擎是KV的，所存儲(chǔ)結(jié)構(gòu)也是KV的 )：

(Predicate, Subject) --> [sorted list of ValueId]，Key是由謂詞和主語(yǔ)組成的，Value是一個(gè)有序的數(shù)組。

舉個(gè)例子：

(friend, me)-->[person1, person2, person3, person4, person5]，Key是friend和me，friend是關(guān)系，me是主語(yǔ)，這樣組成的一個(gè)Key；Value是有序的，me的所有friend，從person1、person2到person5這些ID組成的一個(gè)有序的數(shù)組。

基于這樣的底層存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)，Dgraph同一個(gè)謂詞下的所有數(shù)據(jù)都存儲(chǔ)在同一個(gè)數(shù)據(jù)節(jié)點(diǎn)甚至同一個(gè)數(shù)據(jù)塊中，所以這樣查詢一個(gè)謂詞數(shù)據(jù)時(shí)候，只需要一次RPC調(diào)用就可以拿到這個(gè)謂詞下面全部需要的數(shù)據(jù)，對(duì)于后面的一度、二度、多度的關(guān)聯(lián)查詢有非常大的性能提升，這是它核心的優(yōu)勢(shì)。

③ 數(shù)據(jù)分片 ( 作為一個(gè)分布式系統(tǒng)，要想平滑的擴(kuò)展，必須要支持?jǐn)?shù)據(jù)分片 )：

根據(jù)謂詞分片，相同謂詞的數(shù)據(jù)按序存儲(chǔ)在同一個(gè)節(jié)點(diǎn)，減少RPC，提升查詢性能，不同謂詞可能是在不同的節(jié)點(diǎn)

定期數(shù)據(jù)均衡 ( rebalance_interval )，zero節(jié)點(diǎn)會(huì)定期的檢測(cè)各個(gè)節(jié)點(diǎn)的數(shù)據(jù)是否均衡，如果某個(gè)節(jié)點(diǎn)數(shù)據(jù)過(guò)大或者過(guò)小，會(huì)導(dǎo)致查詢的性能下降，因此zero節(jié)點(diǎn)會(huì)盡量的保證每個(gè)節(jié)點(diǎn)的數(shù)據(jù)均衡。

group根據(jù)replicas和alpha啟動(dòng)順序確定，因?yàn)镈graph的副本一致性是依賴Raft協(xié)議的，所以要保證至少有三個(gè)節(jié)點(diǎn)，才能保證數(shù)據(jù)的強(qiáng)一致性。

④ 高可用：

每個(gè)group至少3個(gè)alpha，互為副本，raft協(xié)議保證強(qiáng)一致性；每個(gè)group中的alpha的數(shù)據(jù)保持一致，這樣某個(gè)alpha節(jié)點(diǎn)掛了，可以通過(guò)其他的alpha進(jìn)行數(shù)據(jù)恢復(fù)。

write-ahead logs，預(yù)寫日志；分布式很常見的WAL機(jī)制，為了提升寫入性能，一定是先寫緩存后刷磁盤的，不會(huì)直接寫磁盤的，那樣性能會(huì)非常低，但先寫內(nèi)存后寫磁盤會(huì)帶來(lái)一個(gè)問(wèn)題，一旦機(jī)器掛掉了，內(nèi)存數(shù)據(jù)沒(méi)有刷到磁盤中，那這部分?jǐn)?shù)據(jù)就會(huì)丟失。因此大部分分布式系統(tǒng)，比如：HBase、Elasticsearch、Dgraph等都是數(shù)據(jù)寫內(nèi)存之前，先預(yù)寫日志，日志會(huì)實(shí)時(shí)刷到磁盤上，然后再將數(shù)據(jù)寫內(nèi)存，一旦內(nèi)存中數(shù)據(jù)丟失了，可以通過(guò)磁盤上的日志回放這些數(shù)據(jù)，從而保證高可用性。

2. Bulk Loader優(yōu)化

其實(shí)我們對(duì)于Dgraph的研究也僅僅只有幾個(gè)月而已，所以目前只是做了一些小的優(yōu)化：480億的行業(yè)圖譜如何快速的導(dǎo)入到集群中？

最開始使用Java客戶端寫入，發(fā)現(xiàn)這種方法性能非常低，完全寫完可能需要整整一周的時(shí)間；

然后使用Dgraph的Bulk Loader寫入，先生成索引數(shù)據(jù)，再通過(guò)alpha節(jié)點(diǎn)加載，最后啟動(dòng)集群來(lái)提供服務(wù)，這種方式需要48小時(shí)才能全部寫入完成，時(shí)間也有點(diǎn)長(zhǎng)，是否還能進(jìn)一步優(yōu)化提升速度呢？

于是我們研究了一下Bulk Loader的源碼，發(fā)現(xiàn)只是一個(gè)簡(jiǎn)單的Map Reduce過(guò)程，但他是在單機(jī)上執(zhí)行的，使用單機(jī)執(zhí)行是因?yàn)樗峙湟粋€(gè)全局唯一的UID，為了保證UID的唯一性和順序性而選擇單機(jī)執(zhí)行，使用單機(jī)多線程，啟動(dòng)多個(gè)Map和Reduce線程，然后每個(gè)線程生成Shard文件，最后通過(guò)Dgraph的alpha加載數(shù)據(jù)。于是基于對(duì)源碼的理解，我們發(fā)現(xiàn)是可以優(yōu)化的，Dgraph原本作為分布式系統(tǒng)，各種查詢寫入都是可以做線性擴(kuò)展的，不能說(shuō)最初的批量導(dǎo)入只能是一個(gè)單機(jī)的模塊。

所以我們對(duì)源碼進(jìn)行了一定的優(yōu)化，將原來(lái)的單機(jī)多線程改為了多機(jī)多線程模式，首先通過(guò)Partition模塊，為原來(lái)的每條數(shù)據(jù)分配一個(gè)UID，這塊還是單機(jī)執(zhí)行的，把相同group的數(shù)據(jù)分到一個(gè)數(shù)據(jù)塊中；然后把這些數(shù)據(jù)塊分發(fā)到不同機(jī)器上，每臺(tái)機(jī)器上都可以啟動(dòng)原來(lái)的Map進(jìn)程和Reduce進(jìn)程，每臺(tái)機(jī)器都可以生成Dgraph需要的數(shù)據(jù)文件，再在每臺(tái)機(jī)器上啟動(dòng)alpha進(jìn)程加載這些數(shù)據(jù)文件，直至整個(gè)集群?jiǎn)?dòng)成功為止。這樣把480億三元組的數(shù)據(jù)初始化導(dǎo)入從48小時(shí)提升到了15小時(shí)，提升了三倍性能。

3. 性能壓測(cè)

把這480億數(shù)據(jù)導(dǎo)入后，就可以回答我們最初的問(wèn)題了，它真的可以支持百億級(jí)圖譜數(shù)據(jù)毫秒級(jí)查詢嗎？于是我們專門對(duì)其進(jìn)行了性能壓測(cè)，如上圖，可以看出Dgraph的性能確實(shí)很好，底下橫坐標(biāo)是我們的并發(fā)線程，左邊縱坐標(biāo)是響應(yīng)時(shí)間 ( 單位毫秒 )，右邊縱坐標(biāo)是QPS吞吐率；當(dāng)我們用1000并發(fā)壓測(cè)時(shí)，仍然可以保持在50ms的響應(yīng)延遲，并且QPS可以達(dá)到15000/s，性能非常好。

4. Dgraph不足

那Dgraph性能這么好，運(yùn)維又簡(jiǎn)單，是不是就可以說(shuō)Dgraph是一個(gè)完美的圖數(shù)據(jù)庫(kù)呢？是不是所有的場(chǎng)景都可以用Dgraph來(lái)支持呢？顯然不是的，沒(méi)有最完美的系統(tǒng)，只有最適合你業(yè)務(wù)的系統(tǒng)；就像沒(méi)有最完美的人，只有最適合你的人一樣。Dgraph也是有它的缺陷和不足的：

① 不支持多重邊

就是說(shuō)任意一對(duì)頂點(diǎn)，相同標(biāo)簽類型的邊只允許存在一條；在JanusGraph中，兩個(gè)頂點(diǎn)確定之后，是允許存在多重邊的。比如：Dgraph中，我和你是同學(xué)關(guān)系，那只能有一條叫同學(xué)關(guān)系的邊；但在JanusGraph中，我和你可以同時(shí)是小學(xué)同學(xué)、中學(xué)同學(xué)、大學(xué)同學(xué)，有三條同學(xué)關(guān)系的邊。

② 一個(gè)集群只支持一個(gè)圖

目前Dgraph一個(gè)集群只支持一個(gè)圖，支持多圖這個(gè)功能官方正在開發(fā)中，后期會(huì)支持；目前對(duì)貝殼的影響還不大，貝殼的圖譜都是比較大的、隔離的，比如行業(yè)圖譜480億本身就是需要一個(gè)單獨(dú)的集群的，不會(huì)和其他圖譜共用，目前還夠不成太大的問(wèn)題。后期自然是希望官方可以盡快的支持了。

③ 大數(shù)據(jù)生態(tài)兼容不夠

不像JanusGraph和大數(shù)據(jù)生態(tài)兼容的那么好，因?yàn)镴anusGraph本身就是基于HBase存儲(chǔ)的；Dgraph本身使用Go開發(fā)，使用Spark對(duì)它進(jìn)行大并發(fā)寫的時(shí)候，會(huì)出現(xiàn)overload的狀態(tài)。

④ 不是很成熟

Dgraph從2016年開始做，總結(jié)下來(lái)并不是很成熟，有很多小問(wèn)題，但是更新也比較快，很多問(wèn)題很快就修復(fù)了。

總結(jié)一下，就是沒(méi)有最完美的系統(tǒng)，只有最合適的系統(tǒng)；我們做技術(shù)選型，主要就是看它的優(yōu)勢(shì)是不是我們需要的、缺陷是不是我們可以接受的，所以最后我們選擇了Dgraph作為我們的圖數(shù)據(jù)庫(kù)選型，然后基于它搭建我們的圖數(shù)據(jù)庫(kù)平臺(tái)，后續(xù)開放給需要的各個(gè)業(yè)務(wù)方去使用。

05

未來(lái)規(guī)劃

最后簡(jiǎn)單說(shuō)一下未來(lái)的規(guī)劃，我這邊主要是負(fù)責(zé)貝殼整體的搜索平臺(tái)建設(shè)，Dgraph建設(shè)只是其中的一部分，在整個(gè)搜索的架構(gòu)之下。目前我們已經(jīng)有基于Elasticsearch的文本檢索引擎，以及基于Dgraph的圖數(shù)據(jù)檢索引擎，后續(xù)還會(huì)有基于Faiss的向量檢索引擎。

搜索云平臺(tái)是一個(gè)業(yè)務(wù)接入平臺(tái)，將與下層的效果平臺(tái)、算法平臺(tái)、三大引擎、容器平臺(tái)全部打通，同時(shí)集成統(tǒng)一的服務(wù)治理能力，整體構(gòu)成一個(gè)搜索中臺(tái)。以后業(yè)務(wù)方不用再關(guān)心底層的數(shù)據(jù)存儲(chǔ)、寫入和查詢，由搜索中臺(tái)來(lái)統(tǒng)一整合相關(guān)能力，然后提供統(tǒng)一的入口和出口，同時(shí)保障整體性能和穩(wěn)定性，從而快速對(duì)業(yè)務(wù)賦能，業(yè)務(wù)方只需要關(guān)注上層的業(yè)務(wù)邏輯和策略。

所以對(duì)圖數(shù)據(jù)庫(kù)的整體規(guī)劃是：

• 深入學(xué)習(xí)，性能、穩(wěn)定性優(yōu)化，源碼改進(jìn)

• 作為搜索中臺(tái)基礎(chǔ)引擎，支持各種圖數(shù)據(jù)庫(kù)檢索需求

• 接入搜索云平臺(tái)，界面化操作快速配置接入，簡(jiǎn)化運(yùn)維

• 增強(qiáng)搜索功能，提升搜索效果

• 支持行業(yè)圖譜、關(guān)系圖譜、知識(shí)圖譜、風(fēng)險(xiǎn)管理……

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝