圖數據庫基準測試 LDBC SNB 系列講解:Schema 和數據生成的機制

LDBC(Linked Data Benchmark Council)Social Network Benchmark,簡稱 LDBC SNB,是一種針對社交網絡場景的評估圖數據庫性能的基準測試。

LDBC 簡介

除了 Social Network Benchmark,LDBC 旗下目前還有其他幾種基準測試:Graphalytics Benchmark,Financial Benchmark 和 Semantic Publish Benchmark,分別針對圖分析、金融和 RDF 的場景。Social Network Benchmark 是 LDBC 最早的提出的基準測試,已經成爲國內外最主流的圖數據庫基準測試,在國內很多圖數據庫招標也會將 LDBC SNB 作爲性能測試的一項。但需要說明的是,LDBC 本身作爲一個非盈利組織,只提供官方審計。不同圖數據庫可能受到運行環境以及基準測試的相關參數影響,因此測試結果的橫向對比沒有任何意義

LDBC SNB 主要包括三個主要部分:

  1. Data Generator:這是一個數據生成工具,用於生成具有社交網絡特性的大規模複雜數據。這些數據包括人、帖子、評論、地理位置、組織和其他一些社交網絡的典型實體和關係。
  2. Interactive Workload:主要針對 OLTP,模擬了用戶在社交網絡上的日常活動,例如發佈帖子、添加好友、點贊等。讀請求以查詢以一到兩跳爲主,同時可能會伴隨一些寫請求。
  3. Business Intelligence Workload:主要針對 OLAP,模擬了對社交網絡數據進行深入分析,以全圖查詢爲主。例如分析用戶的社交行爲、社區的形成和演變,以及其他一些需要複雜分析和大量數據處理的任務。

LDBC SNB 的論文裏還提到了一個 SNB Algorithms,顧名思義主要是跑圖算法的,如 PageRank、社區發現、廣度搜索等。但論文是 2015 年發表的,當時描述這個場景還在起草中,目前已經將這部分移到了 Graphalytics Benchmark。

此外,想要運行 LDBC SNB 測試,還需要一個官方提供的 Driver。不同的數據庫需要基於 Driver 的接口實現相應的 Connector,用來連接 Driver 和數據庫。之後 Driver 會根據 Benchmark 的相關參數生成 Workload(這裏可以理解爲一系列的查詢語句),並驅動待測數據庫執行這些查詢語句,最終得到性能測試結果。

整個 LDBC SNB 基準測試的流程如下,主要分成準備階段基準測試結果輸出這三個階段。

準備階段主要執行數據生成,包括初次導入的全量數據,以及後續實時更新的數據。此外在官方審計中,還需要在 SF10 Dataset 上進行 Validation,因此這一階段也會生成用於校驗的數據。

基準測試階段會先在 SF10 Dataset(在本文文末介紹了何爲 SF)上進行 Validation,之後會在 SF30 或者 SF100 Dataset 進行性能測試。Validation 的過程就是在數據導入之後,由 Driver 根據之前準備階段的一系列 query 和期望結果,對數據庫的查詢結果進行校驗,以確保數據庫的查詢結果正確。Validation 的這個過程沒有時間要求。而之後的性能測試分爲導入、預熱、性能測試,數據庫可以有 30 分鐘的預熱時間,而在性能測試至少要持續兩個小時,最終將測試結果彙總並輸出。

figure

由於篇幅限制,我們這一系列重點介紹 SNB Interactive Workload 相關內容。這一篇,我們主要會結合論文,介紹 SNB 的 Schema 以及數據生成,也就是準備階段。

LDBC SNB Schema 生成

爲了和 SNB 中的數據命名統一,本文相關名稱我會用英文,所以讀起來可能會有些怪怪的。爲了降低理解成本,每個英文單詞首次出現後面會跟隨對應的中文註釋講解。

SNB 的數據主要是模擬了一個類似 Facebook 的社交網絡。其中數據都是圍繞 Person(人)構建而來,Person 之間會構成 Friendship(情誼)網絡。每個 Person 可能會有若干 Forum(特定討論區),Person 可以在 Forum 中下面發送若干 Post(帖子),其他 Person 可能會 likes(點贊)其中一些 Message(消息)。

以上這些元素的數據量主要會受 Person 和時間的影響:

  • 有更多朋友的人會發送更多的評論或點贊
  • 時間越長,會結交更多的朋友,評論或點贊數量也會上升

還有一部分數據不會隨 Person 數量而變化,主要包括一些 Organization(組織,這裏主要是學校)以及 Place(地方,這裏主要是居住城市、國家等地理信息)。這部分數據會在數據生成時起一些作用,比如在同一時期在同一個學校上學的人更有可能稱爲朋友。

SNB 的完整 Schema 如下圖所示:

figure

大多數圖數據庫在進行測試時候,會將實體建模爲點,而不同關係會建模爲邊。但這只是一個慣例,SNB 的數據建模和實際數據庫中的 Schema 可以不同,只要數據庫能夠完成相應 Workload 的查詢即可

LDBC SNB 數據生成

SNB 的一個重要部分是 Data Generator(下文稱爲 DataGen),用來生成滿足上面 Schema 的數據。Generator 生成的數據由以下三個參數決定:

  1. Person 的個數
  2. 模擬多少年的數據
  3. 從哪一年開始模擬

根據官方文檔,DataGen 生成的數據有以下性質:

  • 現實性:生成數據模擬了一個真實的社交網絡。一方面,生成數據中的屬性、基數、數據相關性和分佈經過精心設置,從而能夠模擬 Facebook 等真實社交網絡。另一方面,其原始數據來自於 DBpedia,保證數據中的屬性值真實且相關。
  • 可擴展性:針對不同規模和預算的系統,DataGen 能夠生成不同大小的數據集(GB 到 TB 級),此外 DataGen 可以在單機,或者是一個集羣中完成數據生成。
  • 確定性:無論用來生成數據的機器數量多少、機器配置是高還是低,DataGen 生成的數據都是確定且相同的。這一重要功能確保了任意一個數據系統都能使用相同的數據集,保證不同系統環境之間的測評比較公平且基準測試結果可重複。
  • 易用性:DataGen 被設計得儘可能易於使用。

整個數據生成的流程圖如下所示,我們會分解爲幾部分介紹:

figure

生成屬性分佈

第一步是初始化。DataGen 使用的原始數據來自於 DBpedia,針對每一個屬性,DataGen 會根據以下方面決定屬性的分佈:

  • 有多少種可能的屬性值
  • 每一種屬性值出現的概率

最終將屬性的分佈情況作爲資源文件以及 DataGen 的參數保存下來。

生成 Person 和 Friendship

前面也提到過,SNB 的 Schema 的核心是 Person,這也體現在數據生成過程中。接下來 DataGen 就會生成所有 Person,以及 Person 中一部分後續操作所需要的信息,比如每個 Person 有多少 Friendship(這個值非常重要,其分佈滿足 Power law(冪定律)),Person 所就讀的大學,Person 所就職的公司等。

接下來,DataGen 會創建每個 PersonFriendship 關係(即流程圖中的 knows)。和真實社交網絡一樣,有相同興趣或者行爲的人,很有可能會連接在一起。爲了模擬這樣的社交網絡,SNB 在生成 Friendship 時會考慮以下三個維度:

  1. Person 所就讀的大學,就讀時間,以及大學所在城市
  2. Person 的興趣
  3. 每個 Person 會生成一個隨機值,隨機值越相近代表其越類似(這是爲了模擬不是所有朋友都是通過大學和興趣結交的)

三個維度分別佔每個 PersonFriendship關係權重的 45%,45% 和 10%,也就將 Person 之間建邊的過程分成了三個子步驟。

DataGen 會依次根據三個維度將所有 Person 進行排序(每次只按一個維度進行排序),然後將排序過後的 Person 切分爲不相交的多個部分,分發給不同 Worker 進程。即便是切分之後,每個 Worker 線程負責的 Person 可能也可能超過內存大小。因此,Worker 線程會維護一個滑動窗口,滑動窗口內的 Person 之間建立 Friendship 關係的概率滿足幾何分佈。

如下圖所示:

figure

假設現在根據就讀大學這個維度進行了排序,得到了一個 Person 有序序列。之後 Worker 就會維護一個滑動窗口,每次爲滑動窗口最左側的人生成 Friendship 關係(上圖當前是 P2),滑動窗口內的其他人和窗口第一個人建立 Friendship 的比例滿足幾何分佈。

直到滑動窗口的第一個人建立了足夠多的 Friendship 之後,滑動窗口的起點會移到下一個人。

這裏沒有深究滑動窗口的大小、幾何分佈的參數甚至是隨機生成器的參數,不知道在出現滑動窗口內無法生成足夠多 Friendship 關係時,DataGen 如何處理。

將三個維度都經過排序、分發、按滑動窗口建邊之後,DataGen 就進入了下一階段。

生成社交活動

生成完 PersonFriendship 之後,DataGen 就開始生成每個 Person 的社交活動,包括 ForumPostComment。這部分數據也有一些相關性存在:

  1. 有越多 FriendshipPerson 在社交網絡上會越活躍
  2. 每個 Person 更可能在自己感興趣或者就讀大學相關的 Forum 進行 Post 或者 Comment
  3. 社交活動和時間是有相關性的,比如接近世界盃,足球相關的討論就會激增

最終輸出

經過以上步驟之後,DataGen 完成了數據生成,模擬的社交網絡圖會分成兩部分進行輸出:

  • Dataset:90% 的數據用於初始導入
  • Update Streams:10% 的數據用於後續實時更新

除此之外,還會生成後續 Workload 中請求的參數(主要是起點)。關於參數生成我們會在下一篇詳細解釋,這裏簡單描述一下 SNB 的讀請求 Workload。Interactive Workload 主要的查詢希望在一秒以內得到查詢結果,所有讀 query 都是從圖中的一個點出發,獲取很小一部分的子圖信息。另外,因不同起點的出入度不同,基本上也就決定了這次讀請求會訪問的數據量。

爲了測試不同系統和場景,SNB 定義了比例因子(Scale Factor,即所謂的 SF)用來控制最終生成的數據量大小。比如,SF1 原始數據大小爲 1 GB,同理 SF0.1 和 SF300 的大小爲 100 MB 和 300 GB。不同比例因子的各個類型的點邊數據量如下表所示:

figure

最終生成的 Dataset 分爲兩大類:Static 和 Dynamic,格式都是 CSV。根據 DataGen 配置的線程數量大小,最終生成的數據也會分爲多個分片。Static 包含 OrganizationPlaceTag 等,都是基於 DBpedia 生成的靜態數據,其數量不會隨着比例因子變化而變化。換而言之,這部分數據與 Person 的個數無關。而 Dynamic 部分主要包括 Personknows(即前面數據生成部分描述的 Friendship)、ForumPostComment 等。

而 Update Streams 中包含了所有更新的操作,主要就是模擬實時註冊新用戶、評論、點贊、加好友等等行爲。

Reference

到這裏準備階段大概就介紹完了,在準備階段最終生成的請求參數部分我們會在下一篇講述Workload時再展開。

關於 NebulaGraph
NebulaGraph 是一款開源的分佈式圖數據庫,自 2019 年開源以來,先後被美團、京東、360 數科、快手、衆安金融等多家企業採用,應用在智能推薦、金融風控、數據治理、知識圖譜等等應用場景。GitHub 地址:https://github.com/vesoft-inc/nebula

作者:critical27

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章