導讀 FinBench，全稱 Financial Benchmark，是螞蟻集團基於業務實踐總結出來並在 LDBC 組織下多廠商共同建設的金融圖場景系統基準評測，本次分享題目為《FinBench：金融場景下的圖系統選型》，該文章內容基於 TuGraph 社群 MeetUp 演講實錄整理。
全文目錄如下：
1. FinBench Background
2. FinBench Scenarios
3. FinBench Design
4. FinBench Chokepoints
5. Progress and Plans
分享嘉賓｜戚仕鵬 螞蟻集團 FinBench 開源專案負責人/LDBC Steering Committee Member
編輯整理｜付欣嵐 中國農業銀行
出品社群｜DataFun
1. Why Benchmark?
不同的資料庫具有不同的特性表現，例如查詢語言有 Cypher，Gremlin 等，圖模型有語義的 RDF 和屬性圖，計算場景上分為 TP、AP、HTAP，資料庫的場景和功能都是多種多樣的。使用者選擇使用哪一個資料庫與怎樣構建整體的業務解決方案，這兩個問題相生相成，業務方和使用者很難嚴謹地對比這些資料庫。Benchmark 提供了一個真實的場景，有一些特殊的資料 pattern，或者計算測試 case 的 pattern，幫助去測試系統，來驗證這些系統的功能的正確性、效能、穩定性等。比如 TPC-C 是在關係型資料庫（RDBMS）領域中比較經典的一個 Benchmark，它描繪了一個供應鏈/零售場景去對系統進行測試。2. Benchmarks by TPC for RDBMS
發展比較早的 TPC 是關係型資料庫領域的 Benchmark 組織，其下的 Benchmark 有 TPC-C、TPC-H 和 TPCx-AI 等。比如 TPCx-AI 是專門面向端到端的以 AI/ 資料分析為核心的一個 Benchmark。TPC 透過定義各種各樣的 Benchmark，同時對外提供 audit 服務，能夠從功能、效能、開銷、價效比等多方面對各個資料庫進行對比。3. Linked Data Benchmarks by LDBC
新興的圖領域，有一個類似 TPC 的組織叫做 LDBC，全稱為關聯資料委員會。在之前，LDBC 已經定義了比較多的 Benchmark，比如 SPB 是用於 RDF 資料庫的 Benchmark。還有 Graphalytics 包含了一些標準的圖演算法，主要是面向 AP 系統作圖計算分析系統的 Benchmark。大家瞭解最多的可能是 SNB，它用社交網路的場景來對基於屬性圖的 GDBMS 進行測試的 Benchmark。在與螞蟻集團內部的金融場景進行總結對比之後，我們認為金融場景和 SNB 的社交場景有一定的差別，所以在去年向 LDBC 提出提案，現在與多家廠商一塊共同建設這個 Financial Benchmark，能夠模擬金融場景對 GDBMS 進行測試。4. Data Processing Pipeline
在資料處理流程中，往往會有一個偏 TP 的、線上的系統，有實時的資料寫入，處理偏 TP 的查詢/資料寫入。對於相對複雜的圖分析，透過某種方式把資料從 TP 系統 ETL 到另外的 AP 系統中，跑一些分析迭代類的演算法。還有一些情況下的較複雜的查詢，相比於全圖分析計算複雜度沒有那麼高，但由於某些原因不能在 TP 系統中進行查詢，那麼就會構建第二個 AP 系統去處理。此係統處理的查詢往往比 TP 複雜，但又沒有到全圖迭代級別的計算，這就是 SNB 中 BI 和 Interactive workload 的區別。在 FinBench 中，我們也分別總結出了兩個 FinBench workload，一個 Transaction workload 是今年著力建設的 workload，另一個 analytics workload 是計劃未來建設的工作。1. Risk Control Scenario: Transfer Cycle
這部分從幾個比較典型的場景切入來介紹 FinBench 的設計理念。第一個場景是風控場景。為了做交易風控，我們往往會構建一個圖，其中點是賬戶，比如有個人賬戶或者公司賬戶等等，賬戶往往會有賬戶資訊、狀態資訊等等。邊是賬戶到賬戶之間的轉賬關係，轉賬關係上會有常見的業務屬性，比如這筆轉賬是什麼時候發生的，轉賬金額是多少。有這麼一個建模的圖之後，業務人員就可以在這個圖上進行風控策略的設計，比如可以透過轉賬行為或者關聯賬戶的情況判斷一筆交易是否存在一定的風險。這是在風控場景下的圖建模。上圖中右側是一個轉賬環的例子，這個轉賬環就是一個業務層面的風控策略對應在圖上的特徵。這裡在業務流程上，業務人員會遇到一個問題：有一個轉賬邊要寫入的時候，業務人員首先檢測是否存在一個轉賬環，當轉賬環構成（這筆交易可能會涉及到一些危險場景）時，希望終止這筆交易，同時把相關的賬戶狀態標記為一個異常的狀態，給業務的下一個流程進行反饋。直接處理這類查詢的結果是，即使檢測到風控策略命中了，轉賬也已經寫入到 db 裡面了，我們不希望這樣的事情發生。如果不把轉賬關係直接寫入到 db 裡面，就需要把風控策略對應的圖上的特徵做翻譯，比如先假設當前的交易不存在來檢測這筆交易發生之後是否形成一個轉賬環，業務人員需要在這裡對風控策略做“翻譯”後再去檢測這個圖上特徵，以滿足風控需求。2. Read-Write Query: Transaction-Wrapped Strategy
針對上述場景，我們提出了 Read-Write Query，從業務層面來解釋就是用 Transaction（事務）包裹的風控策略。這類 Query 把風控策略、轉賬邊的寫入都放在一個 Transaction 中。具體例子比如，在 Transaction 內先檢測涉及到的相關賬戶是否狀態異常，如果狀態異常，那這筆交易肯定是有問題的，就把這個 Transaction 直接退出，對應的交易就被駁回了。如果涉及到的賬戶狀態都沒有問題，則進行下一步，在這個 Transaction 中把轉賬邊寫入，再去分析是否命中業務 pattern，如果命中 pattern，那麼交易有問題，就把這筆 Transaction 退出，隨著 Transaction 的退出，這筆交易自然也不會寫到 db。同時會開啟一個新的 Transaction，把相關賬戶的狀態標記為有問題。如果轉賬關係寫入後發現業務 pattern 並沒有命中，那麼就提交 Transaction，交易邊可以順利的寫入到 db。這就是為了方便業務人員寫風控策略而做的 Read-Write Query 設計。3. Risk Control Scenario: Fund tracing from Loan
上圖展示的是一個模擬資金追蹤溯源的場景。圖上特徵是貸款發放後，把一定時間範圍內的資金去向相關的交易邊過濾出來，比如示例中紅色邊就是相應時間視窗之外的交易邊，在分析過程中就要過濾掉。示例中，將黑色的交易邊過濾出來之後，根據各級賬戶各條邊上的交易金額，與上一級賬戶的資金流輸入金額進行比例計算。這類圖上的計算有兩個重要的特徵，第一個點在遍歷時的過濾上，我們稱之為 recursive filtering。它是在篩選一條路徑的時做一個遞迴的判斷，假設存在一條路徑，這個路徑上的時間順序是 e1<e2<e3<...<ei，在金額上的順序是 e1>e2>e3>..>ei，另外時間視窗上，上一跳跟下一跳的時間要落在一個時間視窗之內（如時間差不超過一天）。第二個點是在計算上，在計算上明顯的特徵是在路徑上基於當前邊回溯計算到上一跳（上游邊）資金濃度的特徵。這是貸後追蹤貸後資金濃度計算的典型場景在圖上特徵的總結。
在 data 特性上，資料模型仍是關聯資料建模（點由邊去進行連線），點邊都具有一些屬性。邊上有一個特性叫做 Edge Multiplicity，指的是在相同的起點和終點之間可能會存在多條重複邊，資料分佈上有大點。在測試集上的特性有圖上遍歷、Read-Write Query，基於時間的資料管理等。在負載上，模擬真實世界的負載來對系統進行測試，同時提供不同規模的負載。在 Benchmark Suite 建設上，主要有四個元件分別是 DataGen，Driver，Reference Implementation 以及 ACID Suite。DataGen 的主要功能是生成測試資料，包括存量資料和增量資料，存量資料由測試系統進行批次載入，增量資料會交給 Driver，由 Driver 分析後以 Query 的形式發到測試系統，由測試系統接收這些資料進行寫入。ACID 測試是相對比較獨立的對測試系統進行測試。
圖模型建模上目前主要是有五類點，虛線邊代表的是 Edge Multiplicity。3. Data Distribution Design
資料分佈上，我們對一些真實的線上系統儲存的資料做了一個側寫，從側寫的結果來看，有如下共性結論，average degree 即平均的度數大概是分佈在 1 到 3 之間，平均是2。大點的度數基本上是在百萬級別，也就是有百萬條邊。整體圖上度數的分佈符合 PowerLaw 冪律迴歸的特徵。同時我們也對有時間戳的邊的時間分佈做了分析，可以看到這些邊在時間上的分佈是符合現實生活中的預期的，基本上分佈在早中晚高峰。
Transaction Workload 有四種 query：Complex Read Query，Simple Read Query，Write Query，和 Read-Write Query。Complex Read Query 相比 Simple Read Query 的計算會稍微複雜一點，它是從典型的風控或者商業分析的場景中總結出來的。Simple Read Query 往往是一些比較簡單的查詢。Write Query 是資料的寫入，包括插入、更新、刪除。Read-Write Query 總結出來了三個 query，是 FinBench 的一個亮點。① Transaction Workload：Read-Write Query
Read-Write Query 的設計如上圖所示，前面已經透過業務上的例子詳細介紹過了，這裡就不再展開介紹。Read-Write Query 由不同的 Read Query 和 Write Query 組成，將這些 Complex Query 包裹在一個 transaction 中，來滿足風控業務人員的需求。② Transaction Workload：Temporal Window
第二個 FinBench transaction workload 的特性是 Temporal Window。在做資料分析或者過濾時，我們往往會關注更靠近當前時間的資料，這就是一個時序視窗。在圖上的表現是，在做查詢的時候對邊上的時間做起始時間到結束時間的過濾約束。在具體的業務實踐中，大家往往會選擇做最佳化，比如儲存分級把冷資料熱資料做分開儲存，或者做 TTL 把一些過期的資料做淘汰。③ Transaction Workload：Special Patterns
這是 FinBench 總結出的一些比較特殊的 pattern，比如左上角是一個轉賬環，右上角是一級二級賬戶的呈樹狀結構轉賬關係。下面是一個擔保鏈，比如對企業做擔保關係的穿透。④ Transaction Workload：Recursive Path Filtering
這是在貸後追蹤場景中，有 Recursive Path Filtering 的特徵，在上文也做了具體的介紹，不再贅述5. Load Pattern in Real System
這裡是對負載設計的總結。我們對一些業務系統做了持續長達一個月以上的監測，發現負載的波動遵循著以天為週期的變化。同時我們也對點邊的負載做了分離的分析，可以看到點邊的負載以及讀寫的負載也是存在差異的。6. Load Pattern (Driver Design) 
Driver 設計上，Driver 向測試系統發出查詢請求，將有不同的 query 按照一個策略混合在一起發給測試系統，FinBench 中有 n+2 個 stream，一個 stream 用來單獨地發 Complex Read Query，一個 stream 用來發 Read-Write Query，n 個 stream 用來發寫的 Query，來保證讀寫的比例是平衡的。在負載規模的控制上，Driver 基於 TCR 引數保證系統能夠在不同的負載下得到測試。
ACID 測試在工業界或者學術界都是一個比較標準成熟的設計。原子性和隔離級別的測試都是基於 Fail Case 進行測試的。Durability 測試上，ACID Suite 分別對系統做 graceful（有緩衝時間/當機）和 ungraceful（無緩衝時間/當機）的情況來分別對系統進行測試。Consistency 上的測試和 Durability 結合在一起進行測試。1. Chokepoints in FinBench
Chokepoint 是 LDBC 在創立之後就一直在宣傳的一個概念，指的是在 Benchmark 設計過程中，對問題場景總結出來的一些技術上的挑戰，這也是資料庫的開發人員需要去考慮進行最佳化的方向。這裡列出了 FinBench 的一些 chokepoint。2. Examples of Chokepoints in FinBench
比如貸後追蹤的 Recursive Path Filtering 的過濾特徵是這樣的。現有的查詢語言事實標準 Cypher 在表達這個過濾的 pattern 時沒有很好的表達能力。我們希望的是，查詢語言在這個場景下能夠有好的表達能力。這裡有一個例子，是某個實驗室正在做的嘗試去改善的 Cypher 的一個擴充套件，嘗試從一些關鍵字上去解決表達的問題。
在儲存上，我們在邊上都是有時間戳屬性的。為了保證在對時間進行過濾的時候資料訪問有比較良好的區域性性，我們可以做一些最佳化，比如在存邊的時候把時間戳作為邊上的一個 ID，對這個邊進行排序儲存，那麼在資料訪問的區域性性就會比較好。Read-Write Query，其表現是一個 Complex Query 並上一個比較短的 Write Query，在表現上來說，它大部分的時間可能是在讀，小部分時間是在寫，針對 Read-Write Query 的情況，可以做一些最佳化。比如把前一個 Read-Write Query 的讀和下一個 Read-Write Query 的讀並行起來，並行後可能會出現最終在寫入資料的時候有一些競爭或者衝突的情況，這裡也是有各種最佳化手段的。Progress and Plans
最後介紹一下 FinBench 當前的進度和未來的規劃。FinBench 在 2022 年 2 月份開始做了一個提案，在 6 月份正式 Kick Off。經過半年的時間，基本上確定了 FinBench 的主體框架，並且組建了一個開發小組，對 FinBench 的 Suite 做開發測試套件的開發。
在今年1月底釋出了 Alpha Version。在 Alpha Version 釋出之後，我們會邀請 Task Force 內部的一些廠商做內測（Alpha/Beta Test）。在 Test 完成之後，我們確認整個 FinBench 的邏輯包括實現都是沒有問題之後，大概會在年中釋出一個正式版本。
這是當前 Task Force 的廠商名單，包括開發小組，聯合了一些國內外知名廠商，包括螞蟻集團、創鄰科技、StarGraph、Ultipa、Intel、TigerGraph、Vesoft等。整體上 FinBench 是以一個開源專案的形式來運作的，歡迎大家關注和提出建議。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70027824/viewspace-2949753/，如需轉載，請註明出處，否則將追究法律責任。