圖資料庫洞察資料間的關聯價值
大家好，我是吳敏。今天分享一個叫圖資料庫的技術産品。
什麼是圖和圖資料庫
圖資料庫洞察資料間的關聯價值
先來介紹一下什麼是圖和圖資料庫，所謂的圖和平常認知的圖檔其實不是同一個概念，圖（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。另外，雲這幾年流行和增速也非常的快，雲目前是在受邀公測的階段。大家有什麼興趣可以聯系我們。
謝謝大家！
圖資料庫洞察資料間的關聯價值