阿里云图数据库GDB V3引擎发布，加速开启“图智”未来
簡介：無論是學術界還是產業界，都對圖數據庫有比較高的預期。Gartner發布的《2021年十大數據和分析技術趨勢》中提到：“到2025年圖技術在數據和分析創新中的占比將從2021年的10%上升到80%。”應用需求推動著技術的發展，在GDB V3的引擎設計過程中，通過重建并改進數據存儲架構、優化數據流轉過程、自研計算引擎、重寫執行引擎，以及資源池化、無鎖化編程等一系列性能優化方法，從而逐步逼近物理硬件的極限性能。提供超越傳統圖數據庫百倍的查詢能力，為圖技術的應用，解鎖了更多的可能性。
一、業務價值，為什么我們要用圖數據庫？
隨著互聯網時代的快速發展，企業的數據呈現爆發式的增長，數據之間的關聯也越來越復雜，圖數據庫應運而生。最重要的是如何運用技術方式幫助業務發揮輔助的決策作用，從而運用到新冠疫情、社交推薦、信用卡交易反欺詐等場景中。
技術創新與產業應用，遵循著雙螺旋上升的發展趨勢，促使圖技術到達了爆發式增長的邊緣。從技術角度出發，圖數據庫的運用是針對解決數據的高度關聯帶來的嚴重的隨機訪問問題；從業務角度出發，圖的價值在融合數據、技術、于打破生態位屏蔽產生高維認知。
在了解圖數據庫時，我們不得不提到“知識圖譜”這個概念。計算機在智能發展路徑上，遵循著從數據-信息-知識-智慧的演進過程，知識圖譜是其中認知智能發展的基礎，而圖數據庫是承載知識圖譜的最佳底座，幫助我們實現智能決策。
二、應用場景，圖數據庫能夠解決什么問題？
圖數據庫目前已經應用在金融、社交、互聯網等領域，這個部分我會更多分享阿里巴巴的圖數據庫的應用場景，希望與各位更多探討如何利用圖幫助客戶解決問題。
社交關系
以社交關系為例，圖技術在好友查詢中僅需要幾毫秒的時間，它將好友定義成節點，將好友與好友之間的關系定義成邊，圖數據庫這樣以“點、邊”的查詢方式，速度遠遠快于關系型數據庫。
不僅是好友查詢，在“初始用戶推薦、好友精細推薦、點贊查詢、關聯話題推薦”等場景中都能運用圖來建模。
智能營銷
圖神經網絡等圖技術已經是阿里巴巴智能營銷中必不可少的組件。接下來我將分享兩個在智能營銷中的圖技術應用。
第一個是One-ID，它的核心思路是借助聯通子圖等圖算法，將不同數據源的多個實體實際代表的是同一個真實實體進行合并，從而識別到不同行為路徑的ID隸屬于同一個用戶。
第二個是智能營銷。它的本質是是協同過濾算法思想為核心，通過計算共同鄰居數進行相似節點推薦。
欺詐檢測
同時圖技術還運用在金融領域中，實現信用卡欺詐檢測。
保險欺詐檢測
與此同時，圖技術也在保險反欺詐中發揮了作用。在某頭部保險公司的案例中，運用圖技術的測算，使得關聯查詢性能是原有保險反欺詐方案的10-100倍（客戶實際測試反饋）。
游戲拉新、促活、防流失
由于游戲業務成長周期的特殊性，運營促活效率至關重要。一旦出現用戶流失，之后用戶活躍幾乎不可逆。通過使用圖數據庫GDB的自動機器學習組件，可以更加準確的預測付費、7日內留存玩家，幫助運營人員更準確的投放點卡、道具等權益。
三、產品介紹，揭開阿里云圖數據庫GDB性能的秘密
圖數據庫GDB為企業提供從“知識存儲”到“推理分析”，一站式智能決策方案
為了幫助企業更好地解決業務問題進行智能決策，阿里云GDB從“知識存儲”到“推理分析”，為企業提供了一站式智能決策方案。
在知識圖譜技術在解決智能決策的問題過程中，包含著四個重要的環節：知識構建、知識存儲、推理分析、可視化展示。
在知識存儲的環節中，我們需要將提取出來的信息進行有效存儲與管理，以及使用時能夠快速篩選及查詢。最為復雜環節是推理分析，如何在相互關聯的信息中抽取并推理分析出高度有價值的信息，最后要在數據分析推理后如何進行可視化展示。這其中知識存儲產品化程度最高，推理分析價值潛力最大。
圖數據庫GDB的優勢特性
GDB引擎擁有以下四個獨特的優勢：
● 極致性能，相較于傳統圖數據庫提升近百倍。通過自研算子體系、計算引擎、執行引擎，逐步逼近物理硬件的極限性能，提供超越傳統圖數據庫百倍的查詢性能，只為解鎖更多可能性。
● 兼容并包，集多種圖查詢語言于一身。高度兼容Neo4j、JanusGraph等圖數據庫引擎，支持 OpenCypher 、Gremlin 查詢語言，降低遷移成本和研發門檻。
● 快速彈性、高可用、易運維，盡享云原生技術普惠。基于云原生架構的圖數據庫引擎，可快速擴縮容，應對突增業務負載；支持高可用實例、節點故障自動切換，保障業務連續性；提供備份恢復、自動升級、監控告警、故障切換等豐富的運維功能，免去繁瑣的運維煩惱。
● 低構建成本、靈活計費，滿足不同成本需求。產品構建、運維成本，僅為國外圖數據庫友商的 40%；支持按量付費、包年包月多種計費形式，無論創新探索，亦或生產應用都能自由掌握。
國內唯一進入Forrest Wave評測報告的圖數據庫產品
Forrest Wave在2020年底公布了一次評測報告，在全球中遴選了十余款圖數據庫產品進行評審，其中阿里云GDB是國內唯一進入評測報告中的圖數據庫產品，同時在高可用于災難恢復評測項目中取得了最高的成績。
GDB V3高性能的秘密
不同于關系型數據庫的設計目標，圖數據庫誕生是為了解決高度關聯數據帶來的隨機訪問問題，這就注定了在這一領域上沒有太多的現成方法可供直接參考。我們以影響查詢請求性能的三大因素“硬件間性能墻”、“數據管理開銷”、“硬件效能利用”出發，在GDB V3的引擎設計過程中，通過重建并改進數據存儲架構、優化數據流轉過程、自研計算引擎、重寫執行引擎，以及資源池化、無鎖化編程等一系列性能優化方法，從而逐步逼近物理硬件的極限性能。提供超越傳統圖數據庫百倍的查詢能力，為圖技術的應用，解鎖了更多的可能性。
1.影響用戶查詢請求時延的因素
2. 圖數據庫架構分類
從目前業界流行的圖數據庫產品來看，主流的架構主要分為兩類：計算、存儲分離的分布式架構和以主-備架構為代表的高可用架構。
前者的典型代表包括Tiger、Janus、Nebula等。這種架構下系統一般包括計算節點、存儲節點和元數據管理節點。優勢是通過Share Nothing的方式可以實現存儲規模和計算能力彈性擴展，非常適用面向海量數據萬億大圖場景。缺點是計算和存儲一般跨節點部署，查詢時會帶來較大的跨網絡數據交互開銷，另外可能有數據熱點問題。
后者的典型代表包括阿里云GDB、Neptune、Neo4j等。 這種架構下系統一般只有主節點和備節點。主節點提供讀、寫服務，備份通過提供stand-by形式提供主異常時服務切換。優勢是架構輕量, 用戶使用體驗好，比較適合中小規模的用戶。缺點是存在存儲規模和計算能力的瓶頸， 另外如果存儲模型 和 計算邏輯不一致的化，會存在數據轉換，開銷會比較大。對阿里云GDB而言，由于采用Cloud Native的架構，存儲和計算實質上也可以獨立擴縮容， 存儲規模一般可以達到數百億規模，計算既可以垂直升配，也可以水平擴容到最多15個只讀節點。
GDB V3引擎基于主-備架構做了深度優化，主要體現在兩點：
3. 關鍵技術
● 自研算子體系
數據庫的基礎包括: 數據模型以及基于數據模型之上的各類數據操縱算子。
關系數據庫的邏輯模型是E-R模型，該模型主要包括：Entity、Releation、Property。用戶將業務場景建模為邏輯模型后，再轉換為關系表并存儲再關系數據庫中，然后利用基于關系代數衍生而出的操縱算子例如：掃描、投影、過濾等對其數據進行業務洞察。
圖數據庫的模型包括屬性圖和RDF圖，以屬性圖為例其包含關鍵信息為：Vertex、Edge、Property。本質上和E-R模型是一致的。但不同于關系模型將邏輯模型轉換為一張張物理表，屬性抽象為列，用表的外鍵來描述表之間的關系，屬性圖直接將邏輯模型利用鄰接矩陣(表)等技術進行圖原生存儲。存儲模型的簡潔使的操縱算子非常靈活和豐富。
以Gremlin圖查詢語言為例，操縱算子有map(flatmap)、filter、sideEffect、branch四大類共有110多個。考慮到Tinkerpop通用執行框架效率低下，GDBV3自研算子體系可以進行高效優化并大幅提升請求執行效率。
●?自研計算引擎
定義算子執行體系后，需要通過計算引擎先將Gremlin請求翻譯為物理算子樹，GDBV3中這由三個模塊構成：
● 解析引擎：相比Tinkerpop原生引擎性能提升1000倍，同時極大提升用戶體驗，增強數據庫安全能力
● 翻譯引擎: Gremlin每個算子都有對應的算子或者表達式，翻譯過程中實時優化，多輪優化
● 優化引擎：相比基于策略的優化存在依賴性、低效性等問題，基于Cascade子樹匹配模型自上向下多層匹配優化，支持謂詞下推、子查詢打平、算子Schema融合等
●?自研執行引擎
GDB V3的執行引擎主要包括三個方面：
● 存算一體的架構： 傳統基于開源組件構建的非原生圖數據庫系統一般都是存算分離架構，無法避免跨網絡數據交互等問題。 V3采用存算一體解決方案，將這個執行算子樹下推到圖原生存儲層，最大化的減少了算子和數據之間的距離，提升了數據處理的效率。 同時圖原生存儲本身就是針對圖算子設計的存儲結構，也會讓算子的每個操作執行時延降到最低。
● 數據驅動：傳統的基于Volcano執行引擎調度過程類似下圖中間左側，算子自上向下調用，每次每個算子只獲取處理一條數據，大量Cache Miss、數據轉換、函數調用開銷、內存浪費等問題導致數據執行效率低下。 V3采用數據驅動的策略，每個算子會對一批數據進行集中處理，并生成新的一批數據。 父子算子間通過Producer-Consumer模型共享同一批結果集合，極大減少數據跨算子傳輸。
● 動態執行技術： 圖原生存儲基于Tree結構精確保存了各個屬性的相關統計信息，系統并不需要額外的統計模塊進行代價估算。 靜態優化后直接將整個物理算子樹下推到圖原生存儲層，利用算子進行執行時實時優化。
4. 面向性能設計
● 資源池化：為解決系統運行時頻繁new(delete)開銷，自研內存管理系統并構建數組、樹等基礎數據結構，同時將系統中關鍵數據結構資源池化
● 無鎖化編程： 基于快照的MVCC技術避免讀請求進行鎖等待；通過多級緩存池解決高并發下線程資源分配競爭；使用線程局部變量，解決數據可見性與多線程資源爭搶的矛盾；基于CAS原子操作解決高并發下多線程資源同步、日志記錄等并發沖突
● 使用<指針, 引用計數> 思路解決復雜數據結構跨算子數據傳輸中編解碼性能問題
● 自研Binary數據編解碼算法解決復雜結果集Encoding(Decoding)開銷
5. 性能測試數據
以Twitter數據集作為測試數據，
● 2跳查詢中，相比Neo4j性能提升95倍；
● 3跳查詢中，相比Neo4j性能提升87倍；
● 6跳查詢中，GDB V3單線程消耗266s，其他測試產品均已超時，平均幾十納秒掃描一條數據；
GDB V3原生內存圖存儲引擎
1. 原生圖和非原生圖
從存儲方式來講，目前市面上的圖數據庫，可以分為原生圖和非原生圖兩大類。
非原生圖使用現有的關系型數據庫或者NoSQL數據庫存儲圖數據，在查詢時把圖查詢語句映射到底層系統的查詢語言或者算子上。典型的例子是使用HBase/Cassandra作為存儲后端的JanusGraph和HugeGraph。還有一些以插件形式內嵌到傳統關系數據庫里，實現圖查詢功能的系統，也可以歸為這一類，比如Apache Age，Oracle PGX等。非原生圖的優勢是可以充分利用現有系統中比較成熟的基礎設施，減少開發工作量。但是缺點也很明顯：首先，非原生圖數據庫架構在其他系統之上，軟件棧往往更加復雜，調用層次更深，可能還需要進行跨進程通信，帶來額外的開銷；其次，由于底層存儲引擎并不是專門針對圖數據的設計的，并不能很好的支持圖查詢的I/O訪問模式。總而言之，非原生圖數據庫通常很難發揮硬件的最佳性能。
原生圖數據庫針對這些問題進行了重新設計，從數據結構和數據布局上進行了優化，數據訪問的效率大大提升。除此之外，原生圖數據庫還可以從存儲引擎的層面為圖計算提供定制化的算子支持，從而將計算任務下推到存儲層，減少不必要數據交互，進一步提升性能。也正是因為這些優勢，GDB一直堅持采用原生圖存儲。其他使用原生圖存儲的產品還包括neo4j、Nebula Graph、TigerGraph等。
2. GDB V3內存圖存儲引擎
圖查詢是I/O比較密集的操作，計算高度依賴數據，因此數據的訪問效率對于查詢性能非常重要。不僅如此，對于多跳圖遍歷這一類常見的查詢模式，還存在數據局部性差的問題。在圖遍歷中，每向外一跳，需要訪問的數據量都會成倍增加，并且這些數據通常是隨機分布的，訪問效率低并且對緩存不友好。所以圖數據庫的查詢性能通常會隨著跳數的增加急劇下降。
GDB V3針對這些問題，設計了新的原生內存圖存儲引擎，以內存為存儲介質來承載圖數據，解決隨機I/O性能差的問題，同時從數據結構、遍歷算法、動態更新和垃圾回收等幾個方面進行了優化。
3. 優化的核心數據結構
GDB V3的核心數據結構是改進的壓縮鄰接矩陣。我們從如下三個方面進行了改進：
● 以行位單位進行存儲和更新。鄰接矩陣中的一行，就是一個頂點關聯的所有邊。在實際數據中，大部分點的度數都比較小。比如twitter數據集，80%以上的頂點，出度和入度在30以內。把他們作為一個單元在內存中連續存儲，可以保證高效的讀取，也比較容易更新，更加適合動態圖的存儲。
● 以樹狀結構存儲超級頂點。對于度數很大的超級頂點，用連續內存空間存儲的方法并不適用。因此我們把它進一步拆分成樹結構，以解決超級頂點的更新問題。
● 對相同類型（標簽）的邊進行聚合。在實際業務場景中，一次圖查詢往往只會選取特定類型的邊進行遍歷，把相同類型的邊存放在一起，可以有效的提高這種訪問模式下的性能表現。
4. 用矩陣計算的思想解決圖遍歷問題
基于GDB V3所使用的鄰接矩陣結構，我們在實現圖查詢的過程中，使用矩陣計算的思想。圖的多跳遍歷問題，可以轉換成鄰接矩陣的乘法問題：將鄰接矩陣跟自身多次相乘，可以得到頂點之間的多跳鄰接關系。GDB V3在圖查詢的實現中，借鑒了矩陣乘法中的優化方法，以達到更高的性能。
5. 動態圖的實時更新
GDB V3的內存存儲引擎支持細粒度的快照，并以此為基礎實現了樂觀的MVCC事務。更新操作不會直接修改現有數據，而是創建一個新版本的快照。
讀事務都基于某一個版本的快照來進行，保證了數據的一致性和事務之間的相互隔離，徹底杜絕dirty-read、non-repeatable等異常現象的出現。讀事務也不會被寫事務阻塞，可以做到無鎖并發，達到很高的讀性能。
寫事務在執行階段先把更新數據記錄到自身的事務緩存里，僅對自己可見，事務之間互不干擾，在事務提交階段，才會處理并發沖突。在低沖突率的情況下，這種方式可以充分利用處理器多個核心的并行能力。
6. 高效垃圾回收
在GDB的MVCC機制下，隨著數據的不斷更新，會產生多個版本的快照，而不再需要的快照需要及時回收以釋放空間。如前文所述，大部分數據都是在多個快照之間共享的，所以在刪除快照時，需要知道每個數據單元的生命周期[start, end)，其中start是當前版本的創建時間，end則是它從邏輯上被刪除的時間。在刪除快照Si時，如果一個數據單元同時滿足start > i - 1（①） 且 end <= i + 1（②） （即該單元在前一個版本和后一個版本均不可見），它就可以被安全刪除。
在大數據量的情況下，全量掃描逐個去檢查快照中的所有數據單元是很耗時的。因此，GDB為每個快照引入了一個失效列表來加速這個過程。快照Si的失效列表，記錄的是在Si中從可見變為不可見的所有數據單元，也即生命周期end = i的數據單元。通過失效列表，可以快速拿到滿足上述條件②的數據，只需要再檢查是否滿足條件①，就可以快速找出可以刪除的數據。
為了提升內存分配和釋放的效率，GDB在內部維護了輕量級資源池，垃圾回收中收集到的內存不會馬上釋放，而是放入資源池等待復用，以減少跟操作系統和內存管理器之間的交互，提升效率。
Graph + AI，從數據升維到規律總結
圖數據庫要解決的問題是將大規模，多元異構的數據有效連接起來之后產生高維決策。
不同于關系型數據庫，圖數據庫背后目前沒有指導進行決策的思想與規則，也是導致圖數據庫技術至今沒有被大規模應用的核心原因。圖的意義在于信息升維，因此我們將圖技術與自動機器學習結合，使用機器學習算法，探尋數據規律并找到最佳分析路徑，實現數據升維到規律總結。
從數據科學家到業務專家 – 降低使用門檻
通過GDB自動學習機器的任務，可以實現在不寫任何代碼的情況下，去幫助開發選取業務模型、實現模型調優，從而形成相應的超級模型。以此幫助客戶進行輔助判斷，降低模型研發周期。
原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?
總結
以上是生活随笔為你收集整理的阿里云图数据库GDB V3引擎发布，加速开启“图智”未来的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何画一张架构图（内含知识图谱）
- 下一篇： MySQL 深潜 - 一文详解 MySQ