上個月，國際權威圖基準測評“LDBC SNB Interactive”（社交網絡 - 交互查詢）榜單更新中出現關鍵突破：阿里云開源的圖計算引擎 GraphScope 登頂并打破榜單歷史紀錄，性能達此前紀錄保持者 2.45 倍。

LDBC 全稱 Linked Data Benchmark Council，是一個致力于發展圖數據管理的產業聯盟國際權威非盈利組織，其成員來自工業界和學術界，包括 Intel、AWS、Neo4j、TigerGraph 和 Oracle 等。

在此次基準測評中，GraphScope 以超過 33,000 QPS 的吞吐量排名第一。GraphScope 是阿里云自研的一站式圖計算系統，于 2020 年 12 月開源，在 GitHub 上已超過 2.6k star。

GitHub 地址：
https://github.com/alibaba/GraphScope

不可或缺的圖計算

在阿里巴巴的電商推薦、搜索、風控等場景中，有很多地方會用到 GraphScope 圖計算引擎。

自 2020 年起的多年雙十一期間，阿里巴巴的搜索以及風控團隊采用 GraphScope 作為底部支撐實施了準實時欺詐檢測，虛假訂單檢測能實現秒級識別，評測準確度達到了 97%。在此之前虛假訂單一般需要等到第二天才能處理。

另外，在推薦場景中，常會用到鏈路預測，通過已知的網絡結構預測尚未發生連邊的兩個節點之前產生連接的可能性。比如對社交網絡做關系分析時，共同鄰居是一個重要的特征，它標記了兩個不直接關聯的點之間共同的好友關系。

這個應用如果用傳統的關系數據庫寫查詢，會十分復雜，事實上，很多業務場景確實是通過 SQL + 一些 UDF 的方式寫的。但由于復雜度的問題，要舍棄一些精度以及引入很多近似計算才能在一個很大規模的數據集上成功跑下來，但千億規模的數據上需要近 10 個小時。

這種情況采用圖建模的話，共同鄰居的查找就十分直觀，也很容易寫。GraphScope 系統通過基于子圖模型、增量化計算等技術，能高效的支撐千億規模以上的圖計算，并且由于圖建模可以準確計算共同鄰居，避免精度損失。這類之前用時 10 小時的計算任務，用 GraphScope 只需要約 600 秒。

現在，在阿里巴巴內部，已經海量任務跑在 GraphScope 圖計算引擎上，GraphScope 每天要處理數萬個圖計算任務。

以前，相比于傳統的關系型數據庫以及 SQL，圖數據庫的使用所占的比重很小。但近年來，隨著互聯網應用的爆炸式增長和對用戶需求的深度挖掘，大家開始認識到有些場景下，傳統的 SQL 處理方式已經不能滿足高效的需求。而圖數據庫，與其他的文檔數據庫、KV 數據庫類似，為復雜數據分析提供了全新的維度。特別是在需求深入挖掘關聯關系的場景下，圖幾乎成為了不二之選。這一趨勢的重要性在 ISO SQL 標準的 2023 版本中得到了體現，其中，SQL/PGQ（Property Graph Query）被納入，未來支持 SQL 的數據庫中也將支持圖的查詢。

不僅在數據庫中，圖計算已經在大數據處理和分析中也開始展現其獨特的價值和地位。根據 2022 年 8 月發布的 Gartner 報告，到 2025 年，圖計算技術將在 80% 的數據和分析創新中扮演核心角色。這與 2021 年的數據大相徑庭，當時圖計算在數據和分析創新中的占比僅為 10%。這樣的飛速增長無疑證明了圖計算在未來數據分析領域的至關重要性。

正因如此，該團隊一直在持續精益求精地打磨 GraphScope。2018 年，GraphScope 團隊的主要成員加入阿里巴巴，并將其自研圖計算技術 GRAPE (GraphScope 核心引擎之一的前身) 逐漸應用到阿里巴巴集團和阿里云上。經過幾年打磨和使用后，2020 年 11 月，GraphScope 在第二屆世界科技與發展論壇上重磅宣布開源并發布了白皮書，同年 12 月代碼在 GitHub 開源。

架構演進

在以往的圖計算系統中，由于針對不同類型的圖計算任務設計了特定的特征，導致解決方案出現了嚴重的碎片化現象。這意味著每種不同類型的圖計算任務都需要使用不同的系統或工具來進行處理，導致系統架構的復雜性急劇上升。

在處理現實業務時，一個復雜的工作流可能涉及多種不同類型的圖計算任務，比如多模式的圖計算，以及需要跨越多個系統進行協同的情況。舉例來說，考慮一個包含交易圖和欺詐檢測的工作流，這可能需要在不同的系統中執行不同的圖計算任務，這不僅會引入大量的 IO 開銷，還會增加系統運維的復雜性。

在以前的部署方式中，為了完成工作流中的不同圖計算任務，可能需要通過外部存儲來部署多套系統，增加了整個系統的維護難度。此外，不同系統之間的數據交互也變得復雜，可能需要額外的工作來確保數據一致性和有效的傳遞。

這種復雜性還使得開發人員需要具備對多個系統的熟悉度，增加了開發和維護圖計算任務的技術門檻。這對于數據科學家、算法用戶和應用開發方來說，都帶來了極大的挑戰，限制了圖計算在業務中的應用和發展。

在 2020 年，基于收集到的用戶需求，GraphScope 團隊提出了一種創新的概念——一站式圖計算，通過一個系統整合了當時的多個圖計算引擎（即當時 GRAPE、MaxGraph 和 GraphLearn）的能力，覆蓋了圖分析、圖遍歷、圖學習等多種任務。

為了實現這一概念，他們進行了大量的研究和開發工作。例如，開展了自研的子項目 vineyard，這個項目解決了跨不同引擎之間數據交互與共享的挑戰。值得一提的是，vineyard 項目開源后被捐贈給了云原生大數據社區，進入了 CNCF Sandbox。

經過這些改進，最終形成了 GraphScope 一站式圖計算，可以在一個平臺完成多類圖計算任務，這也是業界首個一站式圖計算系統。GraphScope 的用戶們從一站式得到的好處，“從體驗側的價值來說，最主要的是極大程度降低了圖計算門檻，極度簡化了數據科學家、算法用戶以及應用方開發、部署和運維圖計算的成本，可將圖計算研發上線的周期從以數周計，提效為一兩天即可完成。”

組件化架構

在此基礎上，為了進一步滿足圖業務的多樣化和碎片化需求，GraphScope 正在推進下一代組件化架構 GraphScope Flex，以像樂高一樣的組件化形式為各種具體的圖計算場景提供方便的部署、服務和計算的能力。

在這一架構下，用戶可以根據實際的業務場景，靈活地選用 GraphScope 中的若干組件，從而得到最合適其業務場景的部署形態，形成定制化的圖計算環境。

與此對應，本次提交的 LDBC 基準測試就是基于 GraphScope Flex 架構的高吞吐圖查詢部署方案。在這個部署模式中，他們利用自研的多層級 Actor 框架 Hiactor 作為底層執行引擎，并結合了 GraphScope 在圖存儲和圖分析引擎方面的積累。這種方案能夠在保障事務性要求的前提下，為用戶提供超高吞吐的圖查詢能力。

在開源之后，GraphScope 團隊也在不斷優化與創新。比如在高效圖分析引擎上拓展了 GPU 加速，性能較之其他系統快 5 倍有余；通過引入新的 FLASH 高效模型，將內置圖算法種類擴增到近 100 種。

Rust 編程語言的應用

此外，GraphScope 還利用近期備受關注的系統編程語言 Rust 編寫了交互式查詢的核心組件，分布式引擎 GAIA。相較于適用于高吞吐場景下的 hiactor 系統，GAIA 更著重于系統的擴展性和利用并行技術優化查詢延遲。為了構建一個更加高效、穩健且安全的并行系統，從 GAIA 的原型系統（發表于 NSDI 2021）起，便選用 Rust 語言進行開發。

選擇 Rust 主要是因為它提供的“編譯時生命周期檢查”、"卓越的并發控制"，以及“媲美 C/C++ 的執行效率”，具體來說：

編譯時生命周期檢查：Rust 在編譯過程中提供的變量生命周期檢查功能，使我們能夠在編程的初始階段盡可能地確保程序的正確性。相比其他語言，這為 GAIA 這樣復雜的系統的實現提供了極高的可靠性保障，解決在分布式服務化的部署中的內存管理問題。

卓越的并發控制：并發編程中最常見的問題包括競態條件和死鎖。Rust 提供了各種機制來避免這些問題的發生，包括但不限于原生的互斥鎖和讀寫鎖，以及通過 Send 和 Sync 兩個原生 trait 來保證線程安全。該并發控制是 GAIA 分布式系統實現的基礎。

媲美 C/C++ 的執行效率：Rust 憑借零開銷的抽象和底層優化，以及優質的標準庫實現，使得其編寫的程序能達到傳統面向性能的編程語言 C/C++ 的水準。同時，通過生命周期檢查和并發控制，Rust 很大程度地避免了 C/C++ 實現的系統常遇到的內存溢出和死鎖等難以定位和修復的問題。

基于 GraphScope Flex 提供的組件化能力，GraphScope 可以通過 GAIA 來支持更多的復雜查詢，實現對圖數據更為復雜和深刻的洞察與分析，未來也可以為支持 LDBC 的 SNB BI 的工作負載奠定基礎。

GraphScope 是如何打破紀錄的

這次，GraphScope 登頂并打破榜單歷史紀錄的基準測評是 LDBC SNB Interactive ，也是業界最受認可的圖數據庫基準評測。

近年來參與 SNB Interactive 評測并在榜中領先的圖數據庫產品是螞蟻集團開源的圖數據庫產品 TuGraph，最近成績為 2023 年 1 月做的測試；另外，國內知名圖廠商創鄰科技的 Galaxybase 也在 2022 年 5 月提交過成績。

在 LDBC SNB Interactive 評測中，為了全面評估圖數據庫，引入了復雜的數據表和多樣化的讀寫混合查詢。背后通過一個驅動器向待測系統快速、持續地發送這些查詢請求，主要以系統處理查詢的吞吐率（QPS）來衡量其性能。

其中涉及到處理技術難點，包括：

復雜查詢優化：圖查詢等價于多表關聯的查詢，而此類優化一直是數據庫的傳統難題。同時，查詢中涉及復雜算子如點對間最短路徑，這本身就難以高效實現。復雜的 SNB 數據表結構，不同類型的數據量差異很大，不當的查詢順序可能導致大量中間結果，嚴重影響執行性能。

讀寫并發和事務：高并發的讀寫需要加鎖，但在高吞吐情況下，鎖開銷會顯著影響性能。圖存儲數據結構需要兼顧讀寫性能，傳統的結構往往在寫或讀性能上存在不足。同時，在高并發情況下，保證事務的一致性和效率更加困難。

高并發查詢：高并發場景下，物理線程切換會引入大量的開銷。查詢涵蓋了復雜和簡單查詢，復雜查詢可能長時間占用資源，導致系統吞吐大幅下降。

這些技術難點涉及圖數據庫的查詢優化、讀寫并發、事務保證以及高并發查詢等方面，對于系統設計和實現提出了嚴峻挑戰。為了克服前述技術難題，GraphScope 主要從以下三個方面實現突破：

在圖查詢優化方面，通過引入“高維圖數據的無偏估計”技術，子圖采樣可以準確估計基數，從而優化查詢訪問順序，提高了特定查詢性能。同時，采用了“雙向路徑搜索”算法，在包含最短路徑的負載下，性能提升近 3000 倍。

在高性能讀寫圖存儲設計方面，通過采用“細粒度的鎖控制”策略，將圖數據寫操作細分為修改（如屬性更新）和插入（點 / 邊），采用不同級別的鎖以提高讀寫并發效率（對于修改操作使用常規讀寫鎖，對于插入操作用細粒度或者無鎖技術）。引入了“高效的版本控制”技術，通過原子操作降低鎖開銷，改進了事務同步。此外，改進了原有的 CSR 圖數據結構，通過預留空間和自旋鎖應用，在保證讀效率的同時，有效支持插入操作。

為支持超高吞吐的計算引擎，引入了“輕量級用戶態線程”技術，極大地減少了高并發場景下線程切換的開銷。同時，采用了“異步協同式調度”策略，使得用戶態線程在異步操作時能主動釋放時間片，避免了復雜查詢阻塞其他并發查詢的情況。

這些關鍵技術的整合使得 GraphScope 在性能和效率方面都取得了顯著突破。

圖計算在大語言模型中的應用前景

今年以來，以 ChatGPT 為代表的大語言模型（LLM）迎來爆發式增長，雖然 LLM“涌現”出的智能令人興奮不已，但其訓練方式和特有的自然語言交互模式，使得將 LLM 應用于生產依然面臨諸多挑戰，例如：在訓練數據滯后的情況下，如何提升 LLM 回答的實時性？在大部分 LLM 都具有“幻覺”（Hallucination）的情況下，如何確保回答的準確性？雖然 LLM 具有智能，但其大語言模型的本質決定了 LLM 在特定領域能力的限制，例如數學計算、網頁搜索等。同時，在處理復雜任務時，往往需要對任務進行拆解和編排，利用工具逐個解決，如何才能端到端完成復雜任務？

為解決上述 LLM 原生問題，業界已經涌現出大量實踐，舉例來說：

當 LLM 充當 QA 助手時，回答的實時性問題可以通過在提示詞（prompt）中加入實時信息得以解決。但這也引出另一個問題，如何找出和問題相關的實時信息呢？網絡上的公開數據，尚且可以使用例如 serpapi 之類的搜索工具得到，那么特定領域數據或者私有數據如何處理呢？在提示詞長度限制下，如何選出最相關的數據加入其中呢？

當 LLM 出現“幻覺”時，用戶往往基于“常識”作出了判斷，并通過降低活躍度（temperature）和細化提示詞來降低“幻覺”。然而在處理特定領域（例如醫療、法律）任務時，即使用戶具有該領域的“常識”，“幻覺”往往難以被識別，因為一般用戶難以全面掌握領域知識。那么，有沒有什么方法可以有效利用領域知識來識別 LLM 的“幻覺”呢？

針對復雜任務，將 LLM 與現有成熟生產工具結合，充分利用 LLM 的智能作為編排復雜工作流程的“大腦”，并調動生產工具完成端到端執行，是業界給出的方案。其中代表，包括閉源的 ChatGPT-Plugin 和開源的 Langchain。然而，在 LLM 單一自然語言交互模式下，如何才能實現工作流可視化、實時交互等，以提升系統整體的透明度，避免成為黑盒子呢？如何才能完成數據沉淀、統計分析、快速迭代等，從而提升工作流效率和可持續性呢？

得益于圖抽象的語意表達能力和可解釋性，圖計算可以很好的解決上述業界正在面臨的問題。

首先，將領域數據或私有數據存儲于圖數據庫中，并通過邊來表示數據點之間的關系，可以實現更精準的相關數據查找。常見的向量數據庫通過比較查詢和文檔分片 embeding 之間的相似度來查找相關數據，然而對于稍顯復雜的查詢，其相似性并不體現在單個文檔分片上。例如，用戶的查詢是“OpenAI 的前核心員工有沒有自己創業的？”，這里其實包含兩條信息，一是“誰是 OpenAI 的前核心員工”，二是“這些人有沒有自己創業的”，相關信息可能出現在多個文檔分片中，故使用向量數據庫難以為 LLM 提供最相關信息。然而，若使用圖數據庫，便可以從 Company 節點出發，通過 Empolyment 邊遍歷核心員工，再將這些員工的 Profile 和 Company 一起構建 embeding，來與查詢匹配，從而為 LLM 提供更為精準的相關數據。

其次，知識圖譜作為一種高效領域知識表示，可以為識別 LLM 的“幻覺”提供事實支撐。例如：LLM 回答包含某公司董事會成員 A。如果通過向量數據庫進行驗證，可能某監事 A 總是出現在董事會會議中，其高頻出現會被識別為董事會成員；而通過圖數據庫，可以查找到姓名為 A 的 Person 節點的職位是監事，從而識別出 LLM 的“幻覺”。

再者，將 LLM 作為“大腦”解決復雜問題，其核心思路是將可供選擇的工具（例如網頁搜索、數值計算、本地數據庫訪問等）的“說明書”加入提示詞，和問題一起交由 LLM 來決定下一步使用哪種工具，以及應該為其提供什么樣的輸入。對于復雜問題，往往不是一步就能得到結果，所以 LLM 還要和用戶一起完成工作流的編排，一般稱為 Chain-of-Thought。實際上，由于 LLM 的返回具有選擇性（即 LLM 會依據輸入做出不同的選擇，例如判斷為是的情況下調用 A 工具，否則為 B 工具），用 Graph-of-Thought 來抽象這一工作流是更為通用的方法。不難看出，基于圖抽象的圖計算系統，可以更好的管理這一工作流，其對圖數據的高效查詢、分析和展示能力，可以實現更透明的觀察、更易用的 UI 和更有效的數據管理。

LLM 的特點，決定了它須與私有數據、領域知識和工作流框架充分結合，才能在實際生產中產生價值，而圖計算系統可以很好的解決目前 LLM 在這三方面遇到的問題。所以大家堅信圖計算作為一項基礎技術，將助力 LLM 走向生產，發揮價值。

此外，GraphScope 正在 Text2GQL 領域作出嘗試，不僅考慮通過提示詞工程來提升準確率，還會嘗試通過對開源模型的調優（finetune）來定制更專注的 Text2GQL 模型，進一步提升準確率和查詢效率。在 GQL（無論是 Gremlin 還是 Cypher）學習門檻較 SQL 都更高的今天，期待 Text2GQL 的實踐，能夠讓更多的用戶連接圖數據庫，享受圖計算帶來的價值。