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 主要包括三個主要部分：
- Data Generator：這是一個資料生成工具，用於生成具有社交網路特性的大規模複雜資料。這些資料包括人、帖子、評論、地理位置、組織和其他一些社交網路的典型實體和關係。
- Interactive Workload：主要針對 OLTP，模擬了使用者在社交網路上的日常活動，例如釋出帖子、新增好友、點贊等。讀請求以查詢以一到兩跳為主，同時可能會伴隨一些寫請求。
- 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 分鐘的預熱時間，而在效能測試至少要持續兩個小時，最終將測試結果彙總並輸出。
由於篇幅限制，我們這一系列重點介紹 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 如下圖所示：
大多數圖資料庫在進行測試時候，會將實體建模為點，而不同關係會建模為邊。但這只是一個慣例，SNB 的資料建模和實際資料庫中的 Schema 可以不同，只要資料庫能夠完成相應 Workload 的查詢即可。
LDBC SNB 資料生成
SNB 的一個重要部分是 Data Generator（下文稱為 DataGen），用來生成滿足上面 Schema 的資料。Generator 生成的資料由以下三個引數決定：
Person的個數- 模擬多少年的資料
- 從哪一年開始模擬
根據官方文件，DataGen 生成的資料有以下性質：
- 現實性：生成資料模擬了一個真實的社交網路。一方面，生成資料中的屬性、基數、資料相關性和分佈經過精心設定，從而能夠模擬 Facebook 等真實社交網路。另一方面，其原始資料來自於 DBpedia，保證資料中的屬性值真實且相關。
- 可擴充套件性：針對不同規模和預算的系統，DataGen 能夠生成不同大小的資料集（GB 到 TB 級），此外 DataGen 可以在單機，或者是一個叢集中完成資料生成。
- 確定性：無論用來生成資料的機器數量多少、機器配置是高還是低，DataGen 生成的資料都是確定且相同的。這一重要功能確保了任意一個資料系統都能使用相同的資料集，保證不同系統環境之間的測評比較公平且基準測試結果可重複。
- 易用性：DataGen 被設計得儘可能易於使用。
整個資料生成的流程圖如下所示，我們會分解為幾部分介紹：
生成屬性分佈
第一步是初始化。DataGen 使用的原始資料來自於 DBpedia，針對每一個屬性，DataGen 會根據以下方面決定屬性的分佈：
- 有多少種可能的屬性值
- 每一種屬性值出現的機率
最終將屬性的分佈情況作為資原始檔以及 DataGen 的引數儲存下來。
生成 Person 和 Friendship
前面也提到過，SNB 的 Schema 的核心是 Person，這也體現在資料生成過程中。接下來 DataGen 就會生成所有 Person，以及 Person 中一部分後續操作所需要的資訊，比如每個 Person 有多少 Friendship（這個值非常重要，其分佈滿足 Power law（冪定律）），Person 所就讀的大學，Person 所就職的公司等。
接下來，DataGen 會建立每個 Person 的 Friendship 關係（即流程圖中的 knows）。和真實社交網路一樣，有相同興趣或者行為的人，很有可能會連線在一起。為了模擬這樣的社交網路，SNB 在生成 Friendship 時會考慮以下三個維度：
Person所就讀的大學，就讀時間，以及大學所在城市Person的興趣- 每個
Person會生成一個隨機值，隨機值越相近代表其越類似（這是為了模擬不是所有朋友都是透過大學和興趣結交的）
三個維度分別佔每個 Person 的 Friendship關係權重的 45%，45% 和 10%，也就將 Person 之間建邊的過程分成了三個子步驟。
DataGen 會依次根據三個維度將所有 Person 進行排序（每次只按一個維度進行排序），然後將排序過後的 Person 切分為不相交的多個部分，分發給不同 Worker 程序。即便是切分之後，每個 Worker 執行緒負責的 Person 可能也可能超過記憶體大小。因此，Worker 執行緒會維護一個滑動視窗，滑動視窗內的 Person 之間建立 Friendship 關係的機率滿足幾何分佈。
如下圖所示：
假設現在根據就讀大學這個維度進行了排序，得到了一個 Person 有序序列。之後 Worker 就會維護一個滑動視窗，每次為滑動視窗最左側的人生成 Friendship 關係（上圖當前是 P2），滑動視窗內的其他人和視窗第一個人建立 Friendship 的比例滿足幾何分佈。
直到滑動視窗的第一個人建立了足夠多的 Friendship 之後，滑動視窗的起點會移到下一個人。
這裡沒有深究滑動視窗的大小、幾何分佈的引數甚至是隨機生成器的引數，不知道在出現滑動視窗內無法生成足夠多 Friendship 關係時，DataGen 如何處理。
將三個維度都經過排序、分發、按滑動視窗建邊之後，DataGen 就進入了下一階段。
生成社交活動
生成完 Person 和 Friendship 之後，DataGen 就開始生成每個 Person 的社交活動，包括 Forum，Post 和 Comment。這部分資料也有一些相關性存在：
- 有越多
Friendship的Person在社交網路上會越活躍 - 每個
Person更可能在自己感興趣或者就讀大學相關的Forum進行Post或者Comment - 社交活動和時間是有相關性的，比如接近世界盃，足球相關的討論就會激增
最終輸出
經過以上步驟之後，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。不同比例因子的各個型別的點邊資料量如下表所示：
最終生成的 Dataset 分為兩大類：Static 和 Dynamic，格式都是 CSV。根據 DataGen 配置的執行緒數量大小，最終生成的資料也會分為多個分片。Static 包含 Organization、Place、Tag 等，都是基於 DBpedia 生成的靜態資料，其數量不會隨著比例因子變化而變化。換而言之，這部分資料與 Person 的個數無關。而 Dynamic 部分主要包括 Person、knows（即前面資料生成部分描述的 Friendship）、Forum、Post 和 Comment 等。
而 Update Streams 中包含了所有更新的操作，主要就是模擬實時註冊新使用者、評論、點贊、加好友等等行為。
Reference
到這裡準備階段大概就介紹完了，在準備階段最終生成的請求引數部分我們會在下一篇講述Workload時再展開。
- ldbc-snb-interactive-sigmod-2015.pdf (ldbcouncil.org)
- The LDBC Social Network Benchmark Specification
關於 NebulaGraph
NebulaGraph 是一款開源的分散式圖資料庫，自 2019 年開源以來，先後被美團、京東、360 數科、快手、眾安金融等多家企業採用，應用在智慧推薦、金融風控、資料治理、知識圖譜等等應用場景。GitHub 地址：https://github.com/vesoft-inc/nebula
作者：critical27