大家好，我是吳敏。今天分享一個叫圖數據庫的技術產品。
什麼是圖和圖數據庫
先來介紹一下什麼是圖和圖數據庫，所謂的圖和平常認知的圖片其實不是同一個概念，圖（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 數據。所以對於圖遍歷操作，圖專用的查詢語言要更簡潔。
更快！
使用圖還有一個優勢是更快，行業內的經典例子就是查詢的數據深度越多的時候，圖數據庫的優勢越加明顯。對於 4、 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。另外，雲這幾年流行和增速也非常的快，雲目前是在受邀公測的階段。大家有什麼興趣可以聯繫我們。
謝謝大家！
