分布式圖數(shù)據(jù)庫在貝殼的應(yīng)用實踐

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

• 圖數(shù)據(jù)庫簡介

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

• 圖數(shù)據(jù)庫平臺建設(shè)

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

• 未來規(guī)劃

01

圖數(shù)據(jù)庫簡介

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

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

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

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

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

2. 圖數(shù)據(jù)庫簡介

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

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

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

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

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

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

• 風(fēng)險預(yù)測，風(fēng)控管理

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

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

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

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

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

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

02

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

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

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

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

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

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

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

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

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

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

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

3. JanusGraph架構(gòu)

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

4. Dgraph架構(gòu)

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

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

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

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

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

• 同時Dgraph還支持gRPC或者HTTP來連接alpha進行寫入或查詢。

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

5. JanusGraph和Dgraph性能對比

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

• 寫入性能維度來看，分為實時寫入和初始化寫入三元組兩種，在實時寫入對比中，點的寫入性能：JanusGraph達到15000/s，Dgraph達到35000/s；邊的寫入性能：JanusGraph達到9000/s，Dgraph達到10000/s。

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

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

6. JanusGraph VS Dgraph

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

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

• 副本方面：Dgraph是強一致性的，JanusGraph需要依賴底層的存儲DB。

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

• 語言方面：JanusGraph使用了比較常用的Gremlin，而Dgraph使用基于GraphQL改進的GraphQL+-。

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

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

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

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

• 查詢性能方面：深度查詢時，Dgraph性能遠高于JanusGraph。

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

03

圖數(shù)據(jù)庫平臺建設(shè)

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

1. 集群的建設(shè)

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

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

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

集群搭建好了以后，就要考慮數(shù)據(jù)的寫入了，因為是要做一個通用的圖數(shù)據(jù)庫平臺，所以要考慮多種的數(shù)據(jù)寫入模式，比如實時數(shù)據(jù)流、批量數(shù)據(jù)流和初始化數(shù)據(jù)流。

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

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

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

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

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

4. Graph SQL

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

這種查詢在Gremlin是怎么寫的呢？如圖，使用多個has然后select就可以篩選出來，但同樣不夠簡單明了。

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

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

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

5. 整體架構(gòu)

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

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

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

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

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

其中：

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

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

04

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

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

1. Dgraph原理

簡單介紹一下Dgraph的原理：

① 存儲引擎：

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

② 存儲結(jié)構(gòu) ( 因為存儲引擎是KV的，所存儲結(jié)構(gòu)也是KV的 )：

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

舉個例子：

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

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

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

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

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

group根據(jù)replicas和alpha啟動順序確定，因為Dgraph的副本一致性是依賴Raft協(xié)議的，所以要保證至少有三個節(jié)點，才能保證數(shù)據(jù)的強一致性。

④ 高可用：

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

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

2. Bulk Loader優(yōu)化

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

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

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

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

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

3. 性能壓測

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

4. Dgraph不足

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

① 不支持多重邊

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

② 一個集群只支持一個圖

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

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

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

④ 不是很成熟

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

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

05

未來規(guī)劃

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

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

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

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

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

• 接入搜索云平臺，界面化操作快速配置接入，簡化運維

• 增強搜索功能，提升搜索效果

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

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