COSCon'19 | 如何設計新一代的圖數據庫 Nebula

11 月 2 號 - 11 月 3 號，以「大愛無疆，開源無界」爲主題的 2019 中國開源年會（COSCon'19）正式啓動，大會以開源治理、國際接軌、社區發展和開源項目爲切入點同全球開源愛好者們共同交流開源。

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

About Nebula 總監--吳敏

開源社：Hi，吳敏，先和你們介紹下本身。

你們好，我是吳敏，VEsoft 總監，博士畢業於浙江大學。 曾就任於阿里雲、螞蟻金服，從事分佈式圖數據庫以及雲存儲相關工做。

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

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

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

內容大綱

1. 圖數據庫概述及應用<br />
2. Nebula Graph 設計介紹<br />
3. 技術細節
4. 開源社區及服務

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

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

Nebula 研發之旅

開源社：爲何給圖數據庫取名 Nebula ？

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

開源社：如今數據庫領域百花齊放，國產的 OceanBase 和 TiDB 都發展得不錯，爲何還要研發 Nebula 這樣的圖數據庫？

OceanBase、TiDB 這類 NewSQL 最近發展勢頭很強勁，他們的出現更多的是對傳統單機的關係型數據庫在可用性的補充。<br />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 原生支持的功能。

圖算法

最後的技術特色就是關於圖算法方面。<br />這裏的算法和全圖計算不太同樣，更可能是一個子圖的計算，好比最短路徑。你們知道數據庫一般有 OLTP 和 OLAP 兩種差別很大的場景，固然如今有不少 HTAP 方面的努力。那對於圖數據庫來講也是相似，咱們在設計 Nebula Graph 的時候，作了一些權衡。咱們認爲全圖的計算，好比 Page Rank，LPA，它的技術挑戰和 OLTP 的挑戰和對應的設計相差很大。因此 Nebula 的查詢引擎主要針對 OLTP 類的場景。<br />那麼，對於 OLAP 類的計算需求，咱們的考慮是經過支持和 Spark 的相互訪問，來支持 Spark 上圖計算，好比 graphX。這塊工做正在開發中，應該在最近一兩個月會發布。

開源社：爲何會考慮存儲計算分離的架構呢？

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

1. 成本的緣由。存儲和計算對計算機資源要求不同，存儲依賴 I/O，計算對 CPU 和內存的要求更高，業務在不一樣的應用或者發展時期，須要不一樣的存儲空間和計算能力配比，存儲和計算的耦合會使得機器的選型會比較複雜，存儲計算分離的架構，使得 storage 的 scale out/in 更容易。
2. 存儲層抽象出來能夠給計算帶來新的選擇，好比對接 Pregel, Spark GraphX 這些計算引擎。一般來講，圖計算對於存儲的要求是吞吐量優先的，而在線查詢是時延優先的。經過把存儲層分離出來，無論是開發的時候（作 QoS ）仍是運維的時候（單獨集羣部署），都會更容易一些。
3. 在雲計算場景下，能實現真正的彈性計算。

開源社：做爲一個分佈式數據庫，是如何保障數據一致性的？

咱們使用 Raft 協議，Raft 一致性協議使得 share-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 的數據格式，這樣就能夠很是方便的遷移，包括查詢語言層面的兼容。

開源社：水平伸縮可以支持多大的規模？

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

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

目前實現較爲簡單，基於雙向搜索，返回點邊組合的路徑。將來規劃是計劃在執行計劃與優化器都完成後，完善對路徑的支持，包括實現 match，支持雙向 bfs、雙向 dijkstra、allpair(全路徑)，kshortest 等。固然咱們歡迎社區的同窗們都參與完善 Nebula 的路徑算法。

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

對於剛開始使用圖數據庫的用戶，咱們提供了詳細的文檔；<br /> <br />對於已經在使用其餘圖數據庫，想要試試 Nebula 的用戶，咱們提供了數據導入等工具，有疑問或者任何問題，歡迎在 GitHub 上給咱們提 issue，咱們的工程師會在第一時間爲您解答。<br />

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 的建設中，爲開源貢獻一份力 :)

程序員寄語

開源社： 做爲資深數據庫從業人員，怎樣讓本身的眼界更加開闊，怎麼獲取這個領域的最前沿信息？

<br />多看看論文，看看開源分佈式系統的設計以及源代碼；多關注數據庫的的會議，好比，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 在圖數據庫設計的實踐