COSCon'19 | 如何設計新一代的圖資料庫 Nebula

11 月 2 號 - 11 月 3 號，以 “大愛無疆，開源無界” 為主題的 2019 中國開源年會（COSCon'19）正式啟動，大會以開源治理、國際接軌、社群發展和開源專案為切入點同全球開源愛好者們共同交流開源。

作為圖資料庫技術的代表，Nebula Graph 總監——吳敏在本次大會上將會講述了大規模分散式圖資料庫設計思考和實踐。在資訊爆發式增長和內容平臺遍地開花的資訊時代，圖資料庫在當中扮演了什麼樣的角色？同傳統資料庫相比，圖資料庫又有什麼優勢？圖資料庫開發需要哪些新技術？就此，開源社特訪吳敏來分享下圖資料庫主題內容，從圖資料 Nebula 的研發開始，就傳統資料庫面臨的挑戰，開源模式的優勢，Nebula 的社群開展和產品規劃等問題進行深入解析。

About Nebula 總監--吳敏

開源社：Hi，吳敏，先和大家介紹下自己。

大家好，我是吳敏，VEsoft 總監，博士畢業於浙江大學。 曾就職於阿里雲、螞蟻金服，從事分散式圖資料庫以及雲端儲存相關工作。

開源社：談談您在 COSCon'19 上的分享話題。

隨著抖音、小紅書等社交內容平臺的爆紅誕生了一種基於社交關係網路的推薦需求，而以垂直領域作為切入點的知識圖譜過去兩年的 “爆火”，傳統資料庫在處理社交推薦、風控、知識圖譜方面的效能缺陷，圖資料庫的研發應運而生。

本演講開篇將陳述圖資料庫行業現狀，讓你對圖資料庫儲存的資料及對場景有所瞭解，再從開源的分散式圖資料庫 Nebula Graph 切入深度講解大規模分散式圖資料庫應該如何設計儲存、計算及架構，最後講述開源對圖資料庫開發的影響。

內容大綱

1. 圖資料庫概述及應用
   
2. Nebula Graph 設計介紹
   
3. 技術細節
4. 開源社群及服務

開源社：哪些人可以應該瞭解這個內容？

對圖資料庫有興趣，或是有推薦、風控、知識圖譜等業務場景需求的人。

Nebula 研發之旅

開源社：為什麼給圖資料庫取名 Nebula ？

Nebula 是星雲的意思，很大嘛，也是漫威宇宙裡面漂亮的星雲小姐姐。對了，Nebula 的發音是：[ˈnɛbjələ]

開源社：現在資料庫領域百花齊放，國產的 OceanBase 和 TiDB 都發展得不錯，為什麼還要研發 Nebula 這樣的圖資料庫？

OceanBase、TiDB 這類 NewSQL 最近發展勢頭很強勁，他們的出現更多的是對傳統單機的關係型資料庫在可用性的補充。
Nebula 聚焦在圖資料庫這一領域，也是近年來在資料庫各分支中增長最為快速的領域。圖資料庫使用圖（或者網）的方式很直接、自然的表達現實世界的關係: 用節點來表示實體，邊來表示關聯關係，everything is connected。能高效的提供圖檢索，提供專業的分析演算法、工具，比如 ShortestPath、PageRank、標籤傳播等等。

開源社：圖資料庫應用場景有哪些？

典型的應用場景有社交網路，金融風控，推薦引擎，知識圖譜等。

社交網路，比如，推薦一條最短路徑讓我結識迪納熱巴，還可以加上篩選條件，路徑中的每個人都是單身女性。

金融風控場景，比如，去查一個信用卡反套現的網路。很典型的一個場景，A 轉賬到 B，B 轉賬到 C，C 又轉回給 A 即是一個典型的閉環。對於這樣的閉環，這類查詢在圖資料庫大規模應用之前，大部分都是採用離線計算的方式去查詢，但是離線場景很難去控制當前發生的這筆交易。一個信用卡交易或者線上貸款，整個作業流程很長，而在反套現這塊的稽核時間又限制在毫秒級，這就是圖資料庫非常大的一個應用場景。

在推薦演算法中，為某個人推薦他的好友。現在的方案是去找好友的好友，判斷好友的好友有沒有可能成為某人的新好友，這當中涉及好友關係的親密度，抵達好友的好友的最短路徑等。業務方可能會用 MySQL 等傳統資料庫或是 HBase 來存各類好友關係，然後通過多個序列的 Key-Value 來做查詢，但這線上上場景是很難滿足效能要求的。

知識圖譜這些年非常火，知識圖譜結合自然語言的形式在金融，醫療，網際網路等眾多領域被廣泛使用，常見的有語音助手、聊天機器人、智慧問答等應用場景。而圖資料庫儲存的資料結構完全適配知識圖譜資料，圖譜中的實體對應圖資料庫的點，實體與實體的關係對應圖資料庫的邊，拿 Nebula 為例，Nebula Graph Schema 採用屬性圖，點邊上的屬性對應圖譜實體和關係中的屬性，邊的方向表示了關係的方向，邊上的標記表示了關係的型別。

再說到最近國內非常火的區塊鏈場景，由於區塊鏈上的所有行為都是公開被記錄的又是不可篡改的，因此所有的交易行為，不管是歷史資料，還是大概每幾分鐘產生的新 block，都可以對 DAT 檔案解析後匯入到圖資料庫和 GNN 中做分析。例如我們都聽說在一些數字貨幣場景下，洗錢、盜竊、團伙、操縱市場的各類事情很多，通過圖的手段包括可以幫助我們挖掘裡面的非法行為。

開源社：作為圖資料庫，有參考借鑑了哪些資料庫嗎？哪些方面是 Nebula 有特點的設計？

Nebula 是完全自主研發的資料庫，它主要有以下的技術特點

儲存計算分離

對於 Nebula Graph 來講，有這麼幾個技術特點：第一個就是採用了儲存計算分離的架構，主要好處就是為了上雲或者說彈性，方便單獨擴容。業務水位總是很難預測的，一段時間儲存不夠了，有些時候計算不夠了。在雲上或者使用容器技術，計算儲存分離的架構運維起來會比較方便，成本也更好控制。大家使用 HBase 那麼久，這方面的感觸肯定很多。

查詢語言 nGQL

Nebula Graph 的第二個技術特點是它的查詢語言，我們稱為 nGQL，比較接近 SQL。唯一大一點的語法差異就是 不用巢狀 （embedding）。大家都知道巢狀的 SQL，讀起來是非常痛苦的，要從裡向外讀。另外，由於圖這塊目前並沒有統一的國際標準，這對整個行業的發展並不是好事，使用者的學習成本很高。目前有個 ISO / IEC 組織在準備圖語言的國際標準，我們也在積極相容標準。

支援多種後端儲存

第三個特點就是 Nebula Graph 支援多種後端儲存，除了原生的引擎外，也支援 HBase。 因為很多使用者，對 HBase 已經相當熟悉了，並不希望多一套儲存架構。從架構上來說，Nebula Graph 是完全對等的分散式系統。

計算下推

和 HBase 的 CoProcessor 一樣，Nebula Graph 支援資料計算下推。資料過濾，包括一些簡單的聚合運算，能夠在儲存層就做掉，這樣對於效能來講能提升會非常大。

多租戶

多租戶，Nebula Graph 是通過多 Space 來實現的。Space 是物理隔離。

索引

除了圖查詢外，還有很常見的一種場景是全域性的屬性查詢。這個和 MySQL 一樣，要提升效能的主要辦法是為屬性建立索引 ，這個也是 Nebula Graph 原生支援的功能。

圖演算法

最後的技術特點就是關於圖演算法方面。
這裡的演算法和全圖計算不太一樣，更多是一個子圖的計算，比如最短路徑。大家知道資料庫通常有 OLTP 和 OLAP 兩種差異很大的場景，當然現在有很多 HTAP 方面的努力。那對於圖資料庫來說也是類似，我們在設計 Nebula Graph 的時候，做了一些權衡。我們認為全圖的計算，比如 Page Rank，LPA，它的技術挑戰和 OLTP 的挑戰和對應的設計相差很大。所以 Nebula 的查詢引擎主要針對 OLTP 類的場景。
那麼，對於 OLAP 類的計算需求，我們的考慮是通過支援和 Spark 的相互訪問，來支援 Spark 上圖計算，比如 graphX。這塊工作正在開發中，應該在最近一兩個月會發布。

開源社：為什麼會考慮儲存計算分離的架構呢？

儲存計算分離是個很熱的話題。我們將儲存模組和 Query Engine 層分開主要有以下考慮。

1. 成本的原因。儲存和計算對計算機資源要求不一樣，儲存依賴 I/O，計算對 CPU 和記憶體的要求更高，業務在不同的應用或者發展時期，需要不同的儲存空間和計算能力配比，儲存和計算的耦合會使得機器的選型會比較複雜，儲存計算分離的架構，使得 storage 的 scale out/in 更容易。
2. 儲存層抽象出來可以給計算帶來新的選擇，比如對接 Pregel, Spark GraphX 這些計算引擎。通常來說，圖計算對於儲存的要求是吞吐量優先的，而線上查詢是時延優先的。通過把儲存層分離出來，不管是開發的時候（做 QoS ）還是運維的時候（單獨叢集部署），都會更容易一些。
3. 在雲端計算場景下，能實現真正的彈性計算。

開源社：作為一個分散式資料庫，是如何保障資料一致性的？

我們使用 Raft 協議，Raft 一致性協議使得 shared-nothing 的 kv 有一致性保障。為什麼選擇 Raft？相對於 Paxos，Raft 更加有利於工程化實現。Nebula 儲存層 Raft 使用 Multi-Raft 的模型，多個 replica 上的同一個 partition 組成一個 Raft 組，同一個叢集記憶體在互相獨立 Raft 組，在一致性保障的同時，提高了系統的併發能力。

開源社：在資料庫的優化方面，Nebula 做了哪些？

Nebula 在資料優化方面主要做了以下工作：

1. 非同步和併發執行：由於 IO 和網路均為長時延操作，Nebula Graph 採用非同步及併發操作。此外，為避免一些大 query 的長尾影響，為每個 query 設定單獨的資源池以保證服務質量 QoS。
2. 計算下沉：為避免儲存層將過多資料回傳到計算層，佔用寶貴頻寬，條件過濾等運算元會隨查詢條件一同下發到儲存層節點。
3. 資料庫系統的優化與資料的物理儲存方式以及資料的分佈息息相關。而且隨著業務的發展，資料分佈是會發生變化的，一開始設計的索引和資料儲存或者分割槽會慢慢變得不是最優的，這就需要系統能夠做一些動態的調整。我們 storage 支援 scale out/in, load balance。系統的調整會帶來 overhead，這是需要權衡考慮的問題。

開源社：現在市面上已有一些圖資料庫，Nebula 考慮相容部分資料庫讓已有的使用者無縫切到 Nebula 嗎？

Nebula 有 CSV、HDFS 批量 資料匯入工具。使用者可以將數倉的資料匯入到 Nebula。也提供 C++，Java，Golang，Python 的客戶端。另外對於市面上已有的一些產品，現在也正在開發將它的資料格式直接解析為 Nebula 的資料格式，這樣就可以非常方便的遷移，包括查詢語言層面的相容。

開源社：水平伸縮能夠支援多大的規模？

儲存層 shared-nothing 的架構，理論上支援無限加機器。

開源社：Nebula 最新的版本 RC1 支援最短路徑和全路徑演算法，可以具體講下這塊的實現，及以後的研發規劃嗎？

目前實現較為簡單，基於雙向搜尋，返回點邊組合的路徑。未來規劃是計劃在執行計劃與優化器都完成後，完善對路徑的支援，包括實現 match，支援雙向 bfs、雙向 dijkstra、allpair(全路徑)，kshortest 等。當然我們歡迎社群的同學們都參與完善 Nebula 的路徑演算法。

開源社：使用 Nebula 之前，使用者應該做哪些準備工作？

對於剛開始使用圖資料庫的使用者，我們提供了詳細的文件；

對於已經在使用其他圖資料庫，想要試試 Nebula 的使用者，我們提供了資料匯入等工具，有疑問或者任何問題，歡迎在 GitHub 上給我們提 issue，我們的工程師會在第一時間為您解答。

Nebula 和開源

開源社：作為一個企業級產品，為什麼 Nebula 一開始就選擇了走開源路線？

如果沒 Linux，現在網際網路的格局也不會是今天這樣。我們想要建立圖資料庫的社群，做出更好的圖資料庫產品，也希望更多對 Nebula，對圖資料庫感興趣的同學成為社群的貢獻者，一起努力，共同建立一個互助互利的社群。

開源社：在開源的過程中，有遇到什麼困難嗎？

很多人都想為開源做一份力，但會被開源專案的門檻 “勸退”，尤其是 Nebula 是一個即使耕耘在資料庫領域多年的資料庫專家，如果對圖資料庫的不夠了解的話，都會感嘆 “高大上” 的一個專案。但技術是為業務服務的，所以 Nebula 力求自己的文件讓你即使你對圖資料庫一無所知，通過 Nebula 的文件也能夠了解到圖資料庫及其應用場景。

開源社：在開源社群搭建這塊，有什麼可以和開源社小夥伴們分享的嗎？

開源專案最重要的是生態的搭建，Nebula Graph 剛開源半年在社群搭建這塊只能說略有心得，僅供大家參考 :) 開源社群運營主要從下面幾個方面展開

1. 簡潔明瞭的文件：一個好的文件能讓使用者快速同產品拉近距離，Nebula 的文件從 “讓非技術人做技術事” 的出發，力求即使你是一個不懂技術的人也可以按照文件部署 Nebula，玩起來——用 Nebula 完成簡單的 CRUD，如果開源社的小夥伴閱讀過 Nebula 文件覺得哪裡有更改意見，歡迎聯絡我們；
2. 實時的反饋回覆：使用者的反饋，我們會第一時間進行回覆，在 GitHub 的 issue 及使用者交流群裡進行回覆；
3. 同使用者直接對話：線上上，Nebula 在各大技術平臺同圖資料庫和 Nebula 愛好者們進行交流，包括 Nebula 架構設計、使用者使用實操等系列文章；線上下，我們也開展了主題 Meetup 同各地愛好者交流圖資料庫技術及 Nebula 的開發心得；
4. 社群使用者體系：在 Nebula 的 GitHub 上，現階段你可以看到 3 種使用者，User、Contributor、Committer，User 通過向 Nebula 提 issue / pr 或者投稿等方式成為 Contributor，Contributor 再進階成為 Committer。配合 Nebula 開展的各類社群活動，eg：捉蟲活動，幫助社群使用者完成角色 “升級”；

最後，打個小廣告：歡迎大家來參與到 Nebula 的建設中，為開源貢獻一份力 :)

程式設計師寄語

開源社： 作為資深資料庫從業人員，怎樣讓自己的眼界更加開闊，怎麼獲取這個領域的最前沿資訊？

多看看論文，看看開源分散式系統的設計以及原始碼；多關注資料庫的的會議，比如，SIGMOD, VLDB，關注學術界的最新成果；多關注業界相關公司的發展和動態，比如 OsceanBase，TiDB。

Nebula 有話說

以上為開源社對圖資料庫 Nebula 總監——吳敏的採訪，歡迎你關注 Nebula GitHub：github.com/vesoft-inc/nebula 瞭解 Nebula 最新動態或新增 Nebula 小助手為好友進圖資料庫技術交流群交流，小助手微訊號：NebulaGraphbot

推薦閱讀

• 億萬級圖資料庫 Nebula Graph 的資料模型和系統架構設計
• Nebula Graph 在 HBaseCon Asia2019 的分享實錄
• Vol.03 nMeetup | 圖資料庫綜述與 Nebula 在圖資料庫設計的實踐