
11 月 2 号 - 11 月 3 号,以“大愛無疆,開源無界”為主題的 2019 中國開源年會(COSCon'19)正式啟動,大會以開源治理、國際接軌、社群發展和開源項目為切入點同全球開源愛好者們共同交流開源。
作為圖資料庫技術的代表,Nebula Graph 總監——吳敏在本次大會上将會講述了大規模分布式圖資料庫設計思考和實踐。在資訊爆發式增長和内容平台遍地開花的資訊時代,圖資料庫在當中扮演了什麼樣的角色?同傳統資料庫相比,圖資料庫又有什麼優勢?圖資料庫開發需要哪些新技術?就此,開源社特訪吳敏來分享下圖資料庫主題内容,從圖資料 Nebula 的研發開始,就傳統資料庫面臨的挑戰,開源模式的優勢,Nebula 的社群開展和産品規劃等問題進行深入解析。
About Nebula 總監--吳敏
開源社:Hi,吳敏,先和大家介紹下自己。
大家好,我是吳敏,VEsoft 總監,博士畢業于浙江大學。 曾就職于阿裡雲、螞蟻金服,從事分布式圖資料庫以及雲存儲相關工作。
開源社:談談您在 COSCon'19 上的分享話題。
随着抖音、小紅書等社交内容平台的爆紅誕生了一種基于社交關系網路的推薦需求,而以垂直領域作為切入點的知識圖譜過去兩年的“爆火”,傳統資料庫在處理社交推薦、風控、知識圖譜方面的性能缺陷,圖資料庫的研發應運而生。
本演講開篇将陳述圖資料庫行業現狀,讓你對圖資料庫存儲的資料及對場景有所了解,再從開源的分布式圖資料庫 Nebula Graph 切入深度講解大規模分布式圖資料庫應該如何設計存儲、計算及架構,最後講述開源對圖資料庫開發的影響。
内容大綱
- 圖資料庫概述及應用
- Nebula Graph 設計介紹
- 技術細節
- 開源社群及服務
開源社:哪些人可以應該了解這個内容?
對圖資料庫有興趣,或是有推薦、風控、知識圖譜等業務場景需求的人。
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 層分開主要有以下考慮。
- 成本的原因。存儲和計算對計算機資源要求不一樣,存儲依賴 I/O,計算對 CPU 和記憶體的要求更高,業務在不同的應用或者發展時期,需要不同的存儲空間和計算能力配比,存儲和計算的耦合會使得機器的選型會比較複雜,存儲計算分離的架構,使得 storage 的 scale out/in 更容易。
- 存儲層抽象出來可以給計算帶來新的選擇,比如對接 Pregel, Spark GraphX 這些計算引擎。通常來說,圖計算對于存儲的要求是吞吐量優先的,而線上查詢是時延優先的。通過把存儲層分離出來,不管是開發的時候(做 QoS )還是運維的時候(單獨叢集部署),都會更容易一些。
- 在雲計算場景下,能實作真正的彈性計算。
開源社:作為一個分布式資料庫,是如何保障資料一緻性的?
我們使用 Raft 協定,Raft 一緻性協定使得 share-nothing 的 kv 有一緻性保障。為什麼選擇 Raft?相對于 Paxos,Raft 更加有利于工程化實作。Nebula 存儲層 Raft 使用 Multi-Raft 的模型,多個 replica 上的同一個 partition 組成一個 Raft 組,同一個叢集記憶體在互相獨立 Raft 組,在一緻性保障的同時,提高了系統的并發能力。
開源社:在資料庫的優化方面,Nebula 做了哪些?
Nebula 在資料優化方面主要做了以下工作:
- 異步和并發執行:由于 IO 和網絡均為長時延操作,Nebula Graph 采用異步及并發操作。此外,為避免一些大query 的長尾影響,為每個 query 設定單獨的資源池以保證服務品質 QoS。
- 計算下沉:為避免存儲層将過多資料回傳到計算層,占用寶貴帶寬,條件過濾等算子會随查詢條件一同下發到存儲層節點。
- 資料庫系統的優化與資料的實體存儲方式以及資料的分布息息相關。而且随着業務的發展,資料分布是會發生變化的,一開始設計的索引和資料存儲或者分區會慢慢變得不是最優的,這就需要系統能夠做一些動态的調整。我們 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 之前,使用者應該做哪些準備工作?
對于剛開始使用圖資料庫的使用者,我們提供了詳細的文檔;
對于已經在使用其他圖資料庫,想要試試 Nebula 的使用者,我們提供了資料導入等工具,有疑問或者任何問題,歡迎在 GitHub 上給我們提 issue,我們的工程師會在第一時間為您解答。
Nebula 和開源
開源社:作為一個企業級産品,為什麼 Nebula 一開始就選擇了走開源路線?
如果沒 Linux,現在網際網路的格局也不會是今天這樣。我們想要建立圖資料庫的社群,做出更好的圖資料庫産品,也希望更多對 Nebula,對圖資料庫感興趣的同學成為社群的貢獻者,一起努力,共同建立一個互助互利的社群。
開源社:在開源的過程中,有遇到什麼困難嗎?
很多人都想為開源做一份力,但會被開源項目的門檻“勸退”,尤其是 Nebula 是一個即使耕耘在資料庫領域多年的資料庫專家,如果對圖資料庫的不夠了解的話,都會感歎“高大上”的一個項目。但技術是為業務服務的,是以 Nebula 力求自己的文檔讓你即使你對圖資料庫一無所知,通過 Nebula 的文檔也能夠了解到圖資料庫及其應用場景。
開源社:在開源社群搭建這塊,有什麼可以和開源社小夥伴們分享的嗎?
開源項目最重要的是生态的搭建,Nebula Graph 剛開源半年在社群搭建這塊隻能說略有心得,僅供大家參考 :) 開源社群營運主要從下面幾個方面展開
- 簡潔明了的文檔:一個好的文檔能讓使用者快速同産品拉近距離,Nebula 的文檔從“讓非技術人做技術事”的出發,力求即使你是一個不懂技術的人也可以按照文檔部署 Nebula,玩起來——用 Nebula 完成簡單的 CRUD,如果開源社的小夥伴閱讀過 Nebula 文檔覺得哪裡有更改意見,歡迎聯系我們;
- 實時的回報回複:使用者的回報,我們會第一時間進行回複,在 GitHub 的 issue 及使用者交流群裡進行回複;
- 同使用者直接對話:線上上,Nebula 在各大技術平台同圖資料庫和 Nebula 愛好者們進行交流,包括 Nebula 架構設計、使用者使用實操等系列文章;線上下,我們也開展了主題 Meetup 同各地愛好者交流圖資料庫技術及 Nebula 的開發心得;
- 社群使用者體系:在 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