你們好，我是吳敏。今天分享一個叫圖數據庫的技術產品。數據庫
什麼是圖和圖數據庫
先來介紹一下什麼是圖和圖數據庫，所謂的圖和日常認知的圖片其實不是同一個概念，圖（Graph）在計算機科學裏面是一種數據結構，這種數據結構有三個比較主要的概念：點、邊和屬性。安全
通俗的說，圖結構還有其餘的叫法，好比：網絡結構、拓撲結構，大體上都是描述的同一種數據結構。服務器
舉個例子，上面這個圖是典型的圖結構（網絡結構），人和公司，公司與公司都存在關聯關係。這裏面存在幾個重要的概念，在網絡結構中一家公司、一我的能夠是一個點；還有另一個概念是邊，描述的是點與點之間的關係，對應上圖中母公司和子公司之間的一個控股關係，也能夠是某一我的是另一個公司的董事長，這樣的一個身份關係。點和邊基本上組成一個網絡結構。微信
圖結構在工業界使用的時候還會加上一個概念就是**屬性。**好比，中間的這我的（點）能夠有他的身份證、性別、年齡屬性，關係就是邊上也能夠有一些屬性，好比說投資某家公司的投資金額、投資的比例、投資的時間等等，均可以構成這個投資關係的屬性。網絡
像基於上圖這樣的工商關係，微衆銀行、騰訊和咱們（Nebula Graph）也都是有各自合做的項目。數據結構
圖數據庫的案例 1：反欺詐
下面來介紹下圖的應用。運維
通常來講，圖在安全場景裏面的應用會比較多，上面這種圖的中間部分是和 360金融合做的一個項目，主要用於識別詐騙團伙。函數
具體來講，如今是互聯網時代，不少 APP 支持申請貸款，不論是持牌或者持其餘牌照的平臺，均可以提供必定的貸款能力。與此同時，也存在團伙「做案」，固然搶銀行的少，詐騙、騙貸的團伙多，而這些團伙是有特徵的，能夠經過必定的方式進行關聯。微服務
在左邊的這個例子裏，有些的黑產團伙，他們控制的帳號會登陸一些設備（手機），這些設備和 Wi-Fi 有關聯關係。經過這樣的 帳號-設備-WiFi 關聯關係能夠識別出來這些團伙。這些團伙被識別出來後，若是團伙相關的人來貸款或者說是來申請授信時，在風控環節會先識別出來。工具
在中間這個例子裏，紅色的點是已知存在風險的帳號，最中間的那個區域就是一個風險的團伙，這些節點就是被識別出來的風險節點，它們基於 Wi-Fi 關係將其餘點關聯到了一塊兒。
360 金融經過用圖的方法大概識別了接近 100 萬個有風險的團伙，因此這些團伙哪怕換一個馬甲或者其餘設備也能第一時間把他們識別出來，進行屏蔽。右邊案例圖是一些受害人，藍色的點是詐騙團伙，詐騙團伙仍是有挺明顯的特徵存在的。
圖數據庫的案例 2：公司信用分
上面的例子主要是識別有風險的人，在這個例子裏主要講下 BOSS 直聘的公司風控。在上圖中顯示了 BOSS 直聘的一些公司，有些公司是很早入駐 BOSS 直聘平臺，有些是新註冊的。當中存在部分公司不必定可信，須要對這些公司做區分給必定信用分。好比說，公司信用等級好的對它的運營策略會放鬆點，信用等級差的公司對它的運營審覈嚴格些。由於有不停的新的公司在註冊，能夠經過不一樣的運營方式獲得這些公司的不一樣信息，上圖這裏用的是同這些公司有關聯關係的關係公司。舉個例子，我新註冊一家公司的時候，這家公司仍是會和其它公司有一些互動和關聯，例如：該公司的分公司，或是公司同失信被執行人之間有關聯關係，經過一輪輪的迭代算出風險評級和信用評級，爲新出來的公司提供一個啓動初始信用分，這個方法相似於網頁權重中使用的 Page Rank。天天晚上 BOSS 直聘會跑幾百萬社區的權重。
圖數據庫的案例 3：可信設備
這個例子比較直觀。如今每一個人基本上都有手機，而後會有經常使用的手機設備，也可能你會臨時換一個設備。這個經常使用設備下，鑑權的要求比較低。而用臨時設備鑑權的要求較高，風控等級較高。還有一種狀況就是家人臨時使用彼此的設備，這種狀況下的鑑權要求能夠不須要那麼高。由於只要換一個新設備就判斷爲高風險場景的話，其實對於用戶的侵入和打擾很明顯。
圖數據庫的案例 4：智能助理
這個是和美團合做的項目，自己實際上是有兩方面，一方面是和知識圖譜相關，一方面是和深度學習相關。目前來講大多數公司的推薦系統都有基於深度學習的模型。那麼會存在一個問題：這個推薦出來的內容可解釋性差。簡單來講，用戶不知道爲何產生這樣的列表。所以，美團結合圖譜作了一些應用，把全部的菜、地點、人、人與人之間的關係還有這些東西組成大的網，當深度學習模型算出推薦列表以後，取用戶和商家之間全部可能的關係，取出一條路徑或者多條路徑的，在多條路徑之間作一些加權或者說計算一些路徑規則分，呈現給用戶看上去更可理解的理由。好比，這裏挺有意思的理由，叫「在北京喜歡北京菜的山東老鄉都說這家店很贊」，看到這個理由的時候，你會以爲這個推薦略微合理。固然相似的方法也能夠用於像問答機器人這樣的 KBQA 的系統。
圖數據庫的案例 5：外部做弊與刷單
這是一個刷單的例子，其實不少公司會有運營經費，特別是對新用戶會有運營經費，可是這會招來一些羊毛黨。這些專業的羊毛黨技術很好，他們來薅羊毛的速度比通常的消費者速度快不少，通常前期的大多數的運營經費不是給新用戶用掉而是給羊毛黨薅走了，羊毛黨通常就是那些人，把他們識別出來以後，就能夠下降運營經費被薅走的機率。
圖數據庫的案例 6：數據治理系統
這個例子是關於 IT 系統的。我相信如今大多數的公司都是有一個龐大的數倉，幾萬張甚至幾百萬張的表，表與表之間又有比較強的依賴關係。例如：一張表或者某幾張表取當中幾個字段，經過一個 job 清洗，生成下一張表。某一天 DBA 或者某個業務人員發現有一個數據不太對，想知道哪一個環節出錯了，一層一層往上查，上百層的依賴，用圖的方式關聯就能夠很快的查到哪一個地方更有可能出錯。這也是咱們和微衆銀行合做的，他們如今正在使用的東西。
圖數據庫的案例 7 / 8：服務依賴分析 / 代碼依賴分析
左邊是和運維相關的，右邊是和研發相關的事。由於如今基本都是微服務化了，整個微服務之間的調用關係實際上是很龐大的。特別是一個大型集團內的RPC 調用關係，運維本身都不必定搞得清楚全局是什麼依賴狀況。
這個是美團的例子，把全部的調用關係寫到圖譜裏，大概是百萬級別的調用關係。好比說運維想知道過去 7 天可用率低於 4 個 9 的鏈路有哪些，能夠很是快速地識別出來，深度能夠是 10 層也能夠 100 層。
右邊是一個輔助開發過程的小工具，對研發人員來講挺方便的。對於一個大型的代碼倉庫，函數之間相互調用。好比說研發今天想改用一個接口，可是我不知道有多少人在調用這個接口，是怎麼調用的。對於測試來講，也不知道要測試哪些邊界場景。那能夠把這些關係都放到圖譜裏面去，這樣大約是一個千萬級別的調用關係，把整個調用關係全抽出來以後，那研發說我想看一眼這個接口被多少人調用了，調用方是怎麼使用的；QA 要作測試的時候，可能有哪些邊界場景受到影響也能夠很快地知道。
爲何使用圖數據庫
剛纔說的其實就是一些圖的應用，固然其實這些應用不用圖這種數據結構來處理，也是能夠的。好比在數倉用 Spark 或者寫 SQL 來作也能夠。可是爲何更推薦用圖數據庫呢？有如下幾個緣由。
一圖勝千言
一個是圖的表達能力更強。左邊是用表的結構方式來處理人物關係和社區關係。右邊當中人的是比較重要的節點，他在左邊的表中對應的某一行，右邊是用圖的方式來看。經過不一樣的着色能夠很容易地看出來不一樣的社區，而後不一樣的社區之間經過某些特殊的節點來關聯。這樣遠比用表的方式直觀得多，特別是在右邊圖裏面查找中心節點比起在左邊的表中查找屬性值大小要方便的多。
繁瑣 vs 簡潔
第二個是對於圖的遍歷這種操做來講——至關於表操做中 join。若是用 SQL 來寫，大約是左邊這麼長，也不是算很是複雜；可是用圖的查詢語言（右側）來寫的話，其實例子核心就是一句話，沿着一個點開始沿着這樣一個路徑取 Person 數據。因此對於圖遍歷操做，圖專用的查詢語言要更簡潔。
更快！
使用圖還有一個優點是更快，行業內的經典例子就是查詢的數據深度越多的時候，圖數據庫的優點越加明顯。對於 四、 5 層深度的查詢，小時級別的時延和秒級別的時延，是兩種不一樣的業務形態。
最後一個緣由是關於流行趨勢。在國際上，用於統計各類數據庫類型流行狀況的 DB-Engines 上，能夠看到圖數據庫的趨勢。上圖這是這個月最新的數據，綠色是圖這種數據庫類型流行的趨勢，最下面紅色的線是關係型數據庫的流行趨勢。能夠看到，圖數據庫在過去 8 年內保持了比較好的增速，增加了 11 倍。
爲何選擇 Nebula Graph
固然，在整個圖數據庫領域，產品並非只有 Nebula Graph 一個，也有不少的其餘公司。今天早上也有其餘同行在會場上，我想解釋一下爲何會推薦 Nebula Graph。
通常你們選型基於不一樣的需求看的重點不同，我想可能會對可靠性、成本性能、功能各個方面進行權衡。
Nebula Graph 是一個開源的產品，源代碼是開放在 GitHub 上的。雖然產品的研發時間不長，從 2018 年 10 月開始第一行代碼，可是整個項目很活躍。
上圖左下角是 Nebula Graph 中文論壇的狀況，在國內有大量的使用者。而 Nebula Graph 自己是開源的項目，整個項目除了咱們公司人員以外也有不少國內外貢獻者，不少人在使用 Nebula 以後會發現一些 bug 這樣就會 file 個 issue，也有很多人會本身動手 fix 和貢獻 feature，這樣提高了整個研發迭代速度。
右邊是全部 Nebula 的 GitHub 貢獻者列表，這些是公開狀況，你能夠在 GitHub 上面看到。總的來講，貢獻者來源不少，並非背後只有一家公司在研發。
上圖是在生產環境使用 Nebula Graph 的公司。
既然是 Nebula Graph 是開源代碼的，那麼全部人能夠下載和評測。全部的用戶均可以根據本身的業務場景作的評測，會更貼近本身的實際場景。而不像某些供應商本身提供的評測，用戶難驗證這樣的評測裏面隱藏了多少坑。
這張圖第一個例子是去年和微信合做的項目，他們如今的生產環境單個集羣是 50 臺機器的規模，它的更新數據量大概是 4,000 億這樣的級別。第二個是美團的例子，美團所作的 Nebula 和其它競爭對手產品的評測。由於美團也是有一個很是高的可用需求，基本上都是要兩地多機房。第三個是 BOSS 直聘的評測，從友商產品遷移到 Nebula 以後，從最初只能作 50 億量級的邊的產品，提高到作千億點邊的項目。下面這是貝殼作的評測，公開在今年的DTCC，也是和友商產品的的對比。右邊是 360 金融作的評測，生產環境服務器數量減小到原先集羣的 1/3，性能是原來的 20 倍以上。
雖然軟件自己是開源的，可是開源軟件是能夠商業化的。這個在國內外也是一個比較廣泛的事情。Nebula 的源代碼是開放的，因此不論是社區版也好，企業版也好，在產品功能內核、可視化、生態方面基本上沒有太大的差異。主要的差異是在服務上，社區版若是有問題能夠經過開源社區的方式來解決，按照開源協議（Apache 2.0）的約定。而若是是企業版的話，那會提供企業版的嚴格的 SLA。另外，雲這幾年流行和增速也很是的快，雲目前是在受邀公測的階段。你們有什麼興趣能夠聯繫咱們。
謝謝你們！