圖資料庫專案DGraph的前世今生

本文由雲+社群發表

作者：ManishRai Jain

作者：ManishRai Jain Dgraph Labs創始人

版權宣告：本文由騰訊雲資料庫產品團隊整理，頁面原始內容來自於db weekly英文官網，若轉載請註明出處。翻譯目的在於傳遞更多全球最新資料庫領域相關資訊，並不意味著騰訊雲資料庫產品團隊贊同其觀點或證實其內容的真實性。如果其他媒體、網站或其他任何形式的法律實體和個人使用，必須經過著作權人合法書面授權並自負全部法律責任。不得擅自使用騰訊雲資料庫團隊的名義進行轉載，或盜用騰訊雲資料庫團隊名義釋出資訊。

---

每當我向別人介紹自己，並解釋我們在Dgraph Labs所建設的內容時，我經常被人問到是否在Facebook工作過，或者我現在所做的嘗試是否受到FaceBook的啟發。很多人都知道FaceBook為社交圖資料庫所做的努力，是因為他們釋出了很多關於圖資料庫基礎設施的文章。

來自谷歌的Word僅限於提供知識圖譜，但在這個專案之前，幾乎沒有人認為內部基礎架構就可以實現這個服務。Google提供專門的系統來提供知識圖譜服務。事實上，在谷歌工作的時候，我和我的團隊對圖資料庫服務系統下了很大的賭注。遠在2010年，我自己就至少做了兩個比較激進的嘗試去研究新的圖資料庫理論，來看看我們可以創造什麼。

Google需要構建一個新的圖資料庫服務系統，不僅可以處理知識圖譜資料中的複雜關係，還可以處理所有訪問結構化資料的搜尋服務（OneBoxes）。該服務系統要具備遍歷所有資料的能力，還要具備足夠高的吞吐量和足夠低的延時，這樣就可以應用於海量的網路搜尋查詢。當時幾乎沒有可用的系統或者資料庫能同時滿足上面三個要求。

現在我已經回答了谷歌為什麼要構建圖資料服務系統，剩下的篇幅我會向你們介紹，我們是如何一步一步，構建一個符合要求的圖資料庫系統來服務知識圖譜和搜尋引擎的。

我是怎麼知道這些的？

先允許我快速的自我介紹一下，2006年到2013年，我在谷歌工作。最開始是作為一個實習生，後面在Web Search Infrastructure組作為一個軟體工程師工作。2010年，Google收購了Metaweb，我的團隊剛剛推出了Caffeine。我想做一些與眾不同的事情，並開始與Metaweb人合作，穿梭在舊金山和山景之間。我當時的目標是弄清楚如何使用知識圖譜來改進網路搜尋。

在我致力於研發圖資料庫之前，Google有一些專案。值得注意的是，Google在紐約辦公室建立了一個名為Squared的專案，並且有一些關於知識卡片的討論。這些是個人和小團隊的零星努力。但那時候還沒有形成一個既定的決策鏈，這也最終使我離開了谷歌。這個我們稍後再談。

Metaweb故事

如上所述，谷歌在2010年收購了Metaweb。Metaweb使用多種技術構建了一個高質量的知識圖譜，包括爬取和解析維基百科，以及使用類似維基百科的眾包策略通過Freebase運作。所有這些都是由他們內部構建的圖形資料庫驅動的，這個資料庫名為Graphd ，一個圖資料庫程式（現已經GitHub上釋出）。

Graphd有一些非常典型的屬性。像守護程式一樣，它在一臺伺服器上執行，所有資料都在記憶體中。整個Freebase網站都用了Graphd。收購完成後，谷歌面臨的挑戰之一就是繼續執行Freebase。

Google構建了SSTable，然後是Bigtable，它們可以橫向擴充套件到數百或數千臺機器，共同服務於數PB的資料。而且它們使用Borg（一個叢集管理工具，K8s的前身）分配機器，使用Stubby（gRPC出來）進行通訊，通過Borg名稱服務解析IP地址（BNS，baked into K8s），並將資料儲存在Google檔案系統（GFS，類似Hadoop FS）。程式可能會死亡，機器可能會崩潰，但系統還是會一直保持執行。

正是基於這個環境，Graphd得以發揚光大，服務於在單個伺服器上執行整個網站的資料庫的想法與Google（包括我自己）最初的想法千差萬別。Graphd需要64GB或更多記憶體才能執行。如果你在嘲笑這記憶體，請注意時間點，這是在2010年。大多數Google伺服器的最大容量為32GB。事實上，Google必須購買具有足夠大RAM的特殊機器來支援Graphd。

GraphD的替代者

關於如何移動和重寫GraphD以分散式方式工作的想法被提出，但是他們不是儲存鍵值對的資料庫，人們只需要獲取一大塊資料，將其移動到另一個服務上，當訪問對應的key，就可以提供服務了。圖資料庫需要保證有效的連線和遍歷，這就需要我們使用特定的方式構建軟體。

在這些想法中，其中一個是使用名為MindMeld（IIRC）的專案。該專案可以通過網路硬體可以更快地訪問來自另一臺伺服器的記憶體。據推算，這種訪問方式正常的RPC更快，足以快速複製記憶體資料庫所需的偽複製直接記憶體訪問。這個想法並沒有走得太遠。

另一個真正被採納的想法是構建一個真正的圖資料庫服務系統。不僅可以取代Graphd for Freebase，還可以為將來的所有知識圖譜工作服務。這被命名為Dgraph，一個分散式的圖資料庫服務系統，一個升級版的Graphd。

不用感到疑惑，答案是肯定的。在Google內部，Dgraph Labs這家公司和開源專案Dgraph，就是這樣被命名的。

對於本博文的大部分內容，當我提到Dgraph時，我指的是Google內部的專案，而不是我們構建的開源專案。當然開源專案後面也會有更多介紹。

Cerebro的故事：一個知識圖譜引擎

一個無意中造就的圖資料庫服務系統

雖然那時是我已經意識到Dgraph在努力取代Graphd的路上，但我當時的目標是改進網路搜尋的體驗。我在Metaweb找到了一位研發工程師DH，他同時也是Cubed的創始人。

正如我前面提到的，Google紐約的一些工程師已經建立了Google Squared。DH建立了一個類似的專案Cubed。雖然Squared這個專案最終爛尾了，但Cubed非常令人印象深刻。我開始考慮如何在Google上構建它。Google提供了一些小特性，幫助我更輕鬆的搞定整個構建過程。

第一個特性是搜尋，谷歌提供了一種方法，可以高度準確地判斷哪些詞是連在一起理解的。例如，當看到像[tom hanks movies]這樣的短語時，它可以告訴你[tom]和[hanks]應該連起來。同樣，看到[san francisco weather]就知道[san]和[francisco]連在一起表達一個意思。對於人類而言，這些都是顯而易見的事情，然而對於機器來說，做到這一點很難。

第二個特性是理解語法，當一個類似於[books by french authors]的搜尋請求產生時，機器可以理解為[french authors]寫的[books]（即法國籍作者寫的書）。但這個短語還可以被理解為寫[french books]的[authors]，即寫法國書籍的作者。我使用史丹佛的詞性（POS）標記器來更好地理解語法並構建一棵語法樹。

第三個特性是理解實體，[french]一詞可以代表很多實體。它可以代表國家（地區），國籍（指法國人），菜餚（指法式食物）或法語。這裡我可以使用另一個專案來獲取單詞或短語可以對應的實體列表。

第四部分是瞭解實體之間的關係。現在我已經知道如何將單詞連線成到短語，短語應該被以什麼樣的形式組織（即語法），以及它們可以對應的實體，我需要一種方法來找到這些實體之間的關係以建立機器解釋。例如，一個查詢說[books by french authors]，然後POS告訴我們它代表[french authors]寫的[books]。我們有[french]的幾個實體，[authors]的幾個實體，接下來演算法需要確定它們的連線方式。他們可以通過出生地聯絡起來，即出生在法國的作者（但可能是英文寫作），或者是法國國民的作者，或者說或寫法語（但可能與法國這個國家無關）的作者，或者僅僅是喜歡法國美食的作家。

基於搜尋索引的圖資料庫系統

為了確定實體是否需要以及如何連線，我需要一個圖資料庫系統。Graphd從未擴充套件到整個Google級別，而我擅長的是網路搜尋。知識圖譜後設資料以三元組格式化，即每個事實由三個部分表示，主題S（實體），謂詞P（關係）和物件O（另一個實體）。查詢必須來自[S P]→[O]，來自[P O]→[S]，有時來自[S O]→[P]。

我使用了Google的搜尋索引系統，為每個三元組分配了一個Id，並構建了三個索引，分別為S，P和O.另外，索引允許附件，所以我附上了每個實體的型別資訊（即演員，書，人等等）。

我建立了這個圖資料服務系統，但知道它存在連線深度問題（如下所述），並且不適合任何複雜的圖資料查詢。事實上，當Metaweb團隊的某個人讓我開放該系統給其他團隊訪問時，我堅持拒絕了。

為了確定實體間的關係，我會遍歷查詢實體間的所有可能性。比如，[french]和[author]之間會產生的所有關係，從中選一部分結果出來，在判斷[book]和這些結果之間產生的任何聯絡，以此類推不斷推演。這會導致同一個短語會產生多個解釋，比如[tom hanks movies]這個短語，它會產生如[湯姆漢克斯執導的電影]、[湯姆漢克斯主演的電影]、[湯姆漢克斯製作的電影]這樣的解釋，並自動過濾像[電影命名湯姆漢克斯]的解釋。

對於每個可能解釋，圖資料庫系統將生成結果列表，包含圖中的有效實體，並且還將返回其型別（存在於附件中）。使用起來非常強大，因為結果的型別允許過濾，排序或進一步擴充套件等功能。比如對於電影搜尋結果，您可以按照發行年份，電影的長度（短片，長片），語言，獲獎等等對電影進行分類。

這個專案看起來很常智慧，我們（DH作為知識圖譜專家也參與了一部分）將它命名為Cerebro，之後X戰警電影裡出現了同名機器（腦波觸發器）。

Cerebro的執行經常會揭示一個人們最初沒有探索過的非常有趣的事實。當執行像[美國總統]那樣的查詢時，Cerebro會明白總統是人類，而人類有身高。因此，它允許你按身高對總統進行分類，並表明亞伯拉罕林肯是美國最高的總統。它還可以允許人們按國籍查詢總統，在這種情況下，它同時顯示了美國和英國總統的名單，因為美國有一位英國國籍總統：喬治華盛頓。 （免責宣告：基於當時KG狀態的結果，不能保證這些結果的正確性。）

超連結 vs 知識圖譜

Cerebro是有機會真正理解使用者查詢的含義的。利用圖資料庫的中的資料庫，我們可以生成查詢的機器解釋，生成結果列表並理解結果以支援進一步探索。如前面介紹的，您可以對結果啟動特定的過濾和排序操作，也可以進行對連線進行遍歷來顯示資料的連線關係。從[美國總統]到[他們去的學校]，或者[他們所生的孩子]。 DH在另一個他稱為Parallax的專案中證明了從一個結果列表跳轉到另一個結果列表的能力。

Cerebro令人非常印象深刻，Metaweb的領導層也支援它。即使是服務於其中的一部分的，Cerebro也具有令人滿意的高效能和功能，我稱之為知識引擎（從搜尋引擎升級）。但是谷歌的領導沒有知識圖譜相關領域的。我的經理對此也並不感興趣，在跟他溝通之後，我獲得了將其展示給一位非常高階的搜尋部門領導的機會。

然而展示之後的回應令人沮喪。對於[法國作者的書籍]的演示，該領導向我展示了谷歌查詢的搜尋結果，其中顯示了十個相關的超連結，他認為谷歌可以做同樣的事情。此外，他們不想從網站上取走大量資訊，也許會侵犯搜尋者的隱私。

如果你也認為這個高管說的有道理，不妨再想一想：當Google進行網路搜尋時，它並不能真正理解查詢。它會在正確的相對位置，頁面的等級中查詢正確的關鍵字，以及做諸如此類的事。它是一個非常複雜和極其複雜的系統，但它並不能真正理解查詢或結果。使用者需要自行從結果中讀取，解析和提取他們需要的資訊，並進一步搜尋以將完整的結果列表放在一起。

例如，對於[法國作者的書籍]，首先需要將一個詳盡的列表放在一起，內容多大單個網頁可能都放不下。然後按出版年份對這些書籍進行排序，或者按出版社等進行過濾，所有這些操作都需要大量的連結跟蹤，進一步搜尋和人工聚合結果。 Cerebro有能力將所有使用者過濾資訊的步驟省除，讓人機互動簡單而完美。

然而，這是當時典型的知識圖譜方法。Google的管理層不確定知識圖譜的效用，也不確定搜尋引擎應該如何跟知識圖譜結合起來。這個通過向使用者提供網頁連結而獲得巨大成功的組織，難以輕易消化這種接近更知識的新方式。

在與Google管理層對峙了一年後，我幾乎喪失了繼續的信心。此時谷歌上海辦公室的一位經理向我伸出手，我於2011年6月將專案交給了他。他組建了一個由15名工程師組成的團隊。我在上海呆了一個星期，將我建造和學到的東西轉移給工程師。 DH也參與其中，他在這裡長期指導團隊。

連線深度問題

我為Cerebro構建的圖資料庫服務系統存在一個連線深度問題。當需要查詢的先前部分的結果集來執行其後續部分時，一個連線就被建立了。典型的連線將涉及一些SELECT操作，即來自通用資料集的某些結果中的過濾器，然後使用這些結果來過濾資料集的另一部分。我將以一個例子來說明。

比如說，你想知道 [people in SF who eat sushi]（住在舊金山且吃壽司的人）。資料被人們分成兩類：住在SF的人和吃壽司的人這兩類資訊。

以上查詢是單級連線。如果資料庫外部的應用程式正在執行此操作，它將執行一個查詢來執行第一步。然後執行多個查詢（每個結果一個查詢），找出每個人吃什麼，只挑選吃壽司的人。

第二步是出現扇出問題。如果第一步有一百萬個結果（所有舊金山人口），那麼第二步需要將每個結果放入查詢中，檢索他們的飲食習慣，然後通過過濾器過濾出符合條件的人。

分散式系統工程師通常通過廣播來解決這個問題。他們將結果分成很多批量任務，使用分片功能進行分割，並將查詢任務分配到叢集中的每個伺服器。使用分散式會完成連線，但會導致查詢延遲問題。

分散式系統中的廣播很糟糕。谷歌的Jeff Dean在他的“Achieving Rapid Response Times in Large Online Services” 演講中最好地解釋了這個問題。查詢的總延遲總是大於最慢的那臺機器的延遲。單個機器上的小問題就會導致延遲，每次查詢涉及到海量的機器就會大大增加延遲的可能性。

考慮一個伺服器，其50％延遲為1ms，但99％延遲為1s（即百分之99的延遲都小於等於1s）。如果查詢僅僅在一個伺服器上處理，則只有1％的請求會佔用一秒鐘以上。但如果查詢觸及其中的100臺伺服器，則63％的請求將佔用一秒鐘以上。

因此，執行一個查詢的廣播對於查詢延遲是不利的。現在考慮是否需要進行兩次，三次或更多次連線。對於實時OLTP場景來說，會變得太慢，延時超出人們的接受範圍。

大多數非原生圖資料庫都存在這種高扇出的廣播問題，包括Janus圖，Twitter的FlockDB和Facebook的TAO。

分散式連線是一個難題。現有的單機圖形資料庫通過將通用資料集保持在一個機器（獨立資料庫）內，並且在不觸及其他伺服器的情況下進行所有連線操作，則可以避免這個問題，比如Neo4j。

進入Dgraph：任意深度連線引擎

在結束Cerebro之後，我有了構建圖形服務系統的經驗，參與了Dgraph專案，併成為該專案的三位技術主管之一。 Dgraph設計中涉及的概念是新穎的，解決了連線深度問題。

Dgraph以一種特殊的方式對圖形資料進行分片，其中每個連線都可以完全由一臺機器執行，回到之前說的概念主題 - 謂詞 - 物件（SPO），Dgraph的每個例項將儲存與該例項中的每個謂詞相對應的所有主題和物件。多個謂詞將儲存在例項上，每個謂詞都以整體儲存。

這實際上允許了查詢執行任意深度連線，同時避免扇出廣播問題。比如查詢[people in SF who eat sushi]，會導致資料庫內最多進行兩次網路呼叫，無論叢集規模大小。第一個呼叫會找到所有住在舊金山的人。第二個呼叫會傳送這個人名單並與所有吃壽司的人求並集。我們還可以新增更多約束或擴充套件，每個步驟仍然會涉及最多一個網路呼叫。

這引入了位於單個伺服器上的非常大的謂詞的問題，但是這個問題可以通過隨著大小的增長在兩個或更多個例項之間進一步分割謂詞來解決。即使這樣，整個叢集中的單個謂詞拆分也只是在最極端情況下的最壞行為，其中所有資料僅對應於一個謂詞。在其他情況下，這種通過謂詞對資料進行分片的技術表現都很好，可以在實際系統中實現更快的查詢延遲。

分片技術並不是Dgraph的唯一創新。Dgraph為所有物件分配了整數ID，並對其進行排序並儲存在釋出列表結構中，以便快速對這些釋出列表求進行交叉計算。這些創新將在連線期間加快過濾速度，還可以用來查詢公共引用等。這些想法裡涉及到了Google的Web服務系統。

通過Plasma專案統一所有OneBox

谷歌的Dgraph不是一個資料庫，而是一個服務系統，相當於谷歌的網路搜尋服務系統。使用Dgraph還可以對實時更新做出反應。作為實時更新服務系統，它需要一個實時圖形索引系統。我在Caffeine專案中積累了很多實時增量索引系統方面的經驗。

我發起一個專案，通過圖資料索引系統來統一所有Google OneBox，其中包括天氣，航班，事件新聞等。你可能不知道OneBox這個詞，但你肯定已經看過了。 OneBox不同於其他搜尋結果，是一個單獨的顯示框，在執行某些型別的查詢時顯示，Google可以在OneBox返回更豐富的資訊。想了解一下OneBox，請嘗試搜尋[weather in sf]。

在發起這個專案之前，每個OneBox由獨立後端執行並由不同的團隊維護。有一組很複雜的結構化資料，但每個OneBox之間沒有共享資料。這樣不僅在操作上保留了後端的大量的重複工作，而且每個Box之間缺乏知識共享也限制了Google可以響應的查詢型別。

舉個例子，[events in SF]可以顯示舊金山的事件新聞，[weather in SF]可以顯示舊金山的天氣。但如果[events in SF]這個OneBox瞭解到天氣多雨並且知道使用者需要查詢的事件是在室內還是在室外，它就可以根據天氣過濾（或至少排序）事件（在暴雨中，可能電影或交響樂等室內活動是最好的選擇）。

在Metaweb團隊的幫助下，我們開始將所有這些資料轉換為SPO格式並在一個系統下對其進行索引。我將系統命名為Plasma，一個基於圖資料服務系統Dgraph的實時圖形索引系統。

管理混亂

像Cerebro一樣，Plasma專案資金不足，但仍在繼續。最終，當管理層意識到OneBox團隊即將遷移到這個專案時，他們需要負責知識圖譜的“合適人選”。在那場“權利的遊戲”中，我經歷了三次管理層變化，但每次都沒有對知識圖譜有經驗的人加入。

在此次管理層洗牌期間，支援Spanner的管理層認為Dgraph過於複雜，Spanner是一個全球分散式的SQL資料庫，需要GPS時鐘來確保全域性一致性。具有諷刺意味的是，這至今仍然令人難以置信。

最終，Dgraph取消了，Plasma倖免於難，但由新的領導和新的團隊來負責繼續運營，並直接彙報給CEO。新團隊對知識圖譜缺乏瞭解，他們決定建立一個基於Google現有搜尋索引的服務系統（就像我為Cerebro所做的那樣）。我建議使用我已經為Cerebro建立的系統，但是被拒絕了。我將Plasma改造為一個爬取並可以擴充套件知識話題到若干層的系統，這樣Google現有的搜尋服務可以把結果當成Web文件來處理。他們稱之為TS（名稱縮寫）。

這種改造也意味著新的服務系統將無法進行任何深度連線。在很多公司，我都看到一個關於知識圖譜的“決策詛咒”，是因為工程師們通常錯誤地認為“圖資料服務是一個簡單的問題，可以通過在另一個已有系統之上構建一個層來解決”。

幾個月之後，2013年5月，我離開谷歌，此時我已經為Dgraph / Plasma工作了兩年。

後記

• 幾年後，Web搜尋基礎設施團隊被重新命名為Web搜尋和知識圖形基礎設施團隊，我曾經向其演示Cerebro的領導開始重新領導知識圖譜工作，大談特談他們打算如何用知識圖譜取代超連結，並直接回應儘可能多的使用者查詢。
• 當上海的Cerebro研發團隊的即將將專案上線時，該專案從上海直接被拉到了谷歌紐約辦公室。最終，它以Knowledge Strip的形式上線。如果你搜尋[tom hanks movies]，你會在搜尋結果頂部看到它。自首次釋出以來，它有一些迭代改進，但仍然不支援Cerebro提供的過濾和排序級別。
• 在Dgraph工作的所有三位技術主管（包括我）最終都離開了谷歌。據我所知，其他兩位領導現在正在微軟和LinkedIn工作。
• 當我作為高階軟體工程師離開谷歌時，我確實獲得了兩次晉升，目前準備迎接第三次。
• 小道訊息，當前版本的TS實際上非常接近Cerebro的圖形系統設計，主題，謂詞和物件都有一個索引。因此，它將繼續受到加入連線深度問題的困擾。
• 此後，Plasma被重寫並重新命名，但仍然繼續充當實時圖形索引系統，支援TS。他們一起繼續託管和提供Google的所有結構化資料，包括知識圖譜。
• 從很多地方都可以看出，Google無法進行深度連線。首先，我們仍然沒有看到OneBoxes的各種資料反饋的結合：儘管天氣和KG資料隨時可用， [cities by most rain in asia] （亞洲下雨最多的城市）都、沒有生成城市實體列表（相反，結果是來自網頁的引用）; [events in SF]無法根據天氣進行過濾; [US presidents]的結果不能進一步分類，過濾或擴充套件到他們的孩子或他們就讀的學校。我懷疑這也是停止使用Freebase的原因之一。

搜尋關注“騰訊雲資料庫TencentDB"官方微信，最新最熱資料庫前沿知識和手把手實戰教程等你來約，更可在移動端一鍵管理資料庫。

Dgraph：鳳凰磐涅

離開谷歌兩年後，我決定建立Dgraph。不在Google的日子裡，我見證了很多與在內部研發圖資料系統時的猶豫不決。圖形空間有很多半生不熟的解決方案，特別是很多自定義解決方案，草率的將系統搭建在關係型或NoSQL資料庫之上，或者作為多模型資料庫的眾多功能之一。如果存在一個本地單擊解決方案，則會遇到可伸縮性問題。

Dgraph團隊花了三年的時間，不僅吸收了我自己之前的經驗，而且還對系統設計進行了大量的原創型研究，建立了市場上無與倫比的圖形資料庫。因此，公司具備了強大，可擴充套件且高效能的解決方案，用來替代那些半生不熟的解決方案。

此文已由騰訊雲+社群在各渠道釋出

獲取更多新鮮技術乾貨，可以關注我們騰訊雲技術社群-雲加社群官方號及知乎機構號