或為什麼我們建立自己的圖形資料庫

弗朗西斯科·桑托斯和索非亞·戈麥斯

欺詐是一個複雜的話題。它具有多種形狀，並且隨著時間不斷髮展。雖然最先進的模型可以在幾毫秒內輕鬆捕獲最常見的欺詐模式，但是最複雜的欺詐和反洗錢（AML）方案涉及許多相互交織的攻擊和當事方，並且需要補充工具來防禦我們的客戶。

Genome是Feedzai堆疊上可用的此類工具之一。Feedzai Genome是一項創新的新產品，可幫助欺詐分析人員和調查人員使用連結分析來發現和 視覺化 複雜的金融犯罪模式。

我們的客戶對基因組的熱愛與我們對基因組的熱愛一樣。我們最近釋出了Genome v2，它在Genome v1的基礎上進行了重大改進。它的核心改進是新的圖形儲存系統，在此係統中，我們大大提高了圖形查詢的效能。

透過徹底的大修，Genome V2專注於透過更大的資料配置檔案啟用客戶的能力，從而實現效能的巨大飛躍並提高可用性。

我們是如何做到的？劇透警報：我們建立了自己的圖形資料庫！在這篇文章中，我們解釋了為什麼以及如何做到這一點。

基因組v1

與任何最低可行產品（MVP）一樣，為了快速，廉價地構建Genome v1，我們重用了現有Feedzai堆疊的某些 元件 。結果，Genome v1儲存建立在另一個Feedzai的元件 資料庫系統 上。儘管不理想，但這對於展示基因組，展示其價值以及與客戶合作以更好地瞭解我們需要構建的產品是必要的。

Genome v1在檢測複雜欺詐模式和發現重要欺詐環方面取得了重大成功。最大的挑戰？它無法縮放，而且某些最重要的操作也非常緩慢，即使對於小型圖形也是如此。

本機圖資料庫

從一開始，我們就知道我們需要一個不同的儲存系統來支援Genome的前端。在Feedzai，我們始終努力避免重新發明輪子，並以可用的最佳解決方案為基礎。

我們意識到，某些最慢的查詢是“圖形查詢”-例如，擴充套件節點以查詢其鄰居（可能是某些節點或關係屬性的條件）或計算節點的程度。

因此，顯而易見的步驟是研究本機Graph資料庫（Graph DB）的概況。我們探索了許多解決方案，包括：

Neo4j

RedisGraph

JanusGraph

為了測試它們，我們首先定義需要支援的最常見的操作和查詢。它們包括上述的圖查詢，還包括其他常規查詢，例如查詢特定節點（使用ID或其他特定屬性）或查詢給定節點的所有屬性（透過ID）。

接下來，我們使用這些查詢來評估系統以及一個小型資料集，該資料集包含約920萬個節點，860萬個邊和1億個屬性。我們感到失望的是，沒有一種解決方案適合於我們的預期 用例 。

Neo4j

Neo4j可能是當今最受歡迎的圖形儲存系統。它是用 Java 構建的，並且是開源的。它是成熟的Graph DBMS，支援ACID事務，多個使用者的角色，授權策略和強大的查詢語言。

當我們探索Neo4j時，它缺乏我們一個非常重要的功能：擴充套件能力。同時，Neo4j團隊已經發布了Neo4j 4。0，它透過支援圖形聯合來解決此問題。

儘管有此限制，我們仍然決定在單個節點上對其進行測試，但結果令人失望。即使在較小的資料集上，有條件地擴充套件節點也可能需要大約1。5– 3s ，而計算節點的度數可能需要超過3s。諸如查詢給定型別的節點ID的所有屬性之類的圖形操作較少，大約需要9s。

RedisGraph

在Neo4j的效能令人失望之後，我們對RedisLabs的模組RedisGraph進行了測試，該模組基於驚人的GraphBlas庫，該庫將大多數圖形操作視為線性代數。我們測試了RedisGraph v1。2，它聲稱比其他解決方案快600倍。

結果確實比Neo4j好得多。有條件地擴充套件將花費0。3-1。3s，並計算大約0。6s的節點度。我們的另一個查詢，查詢給定型別的節點的所有屬性現在將花費0。5s。

儘管結果很好，但是RedisGraph有一個主要限制：它不能水平縮放。由於RedisGraph與Redis一樣需要將所有資料載入到記憶體中，因此這是一個嚴重的問題。即使使用非常高效的記憶體管理，這也將需要功能強大且昂貴的機器，即使在這些機器上，我們也無法滿足多個用例。

最重要的是，由於存在多個問題和不穩定問題，我們認為該解決方案仍然不成熟。同時，RedisGraph啟動了v2，它可以解決其中的一些問題並使RedisGraph更快。但是，其核心問題-可伸縮性-尚未解決。

JanusGraph

我們留下了最有希望的解決方案，最後進行測試。JanusGraph是基於Java構建的分散式，開放源圖形資料庫。在功能方面，它打勾了所有框，因此我們很高興嘗試一下。JanusGraph可以插入多個後端，例如HBase，BigTable或Cassandra。我們使用Cassandra對其進行了測試。

由於我們知道JanusGraph是我們最有前途的選擇，因此我們花了數週的時間學習如何針對查詢最佳化JanusGraph。JanusGraph在其中幾個方面的效能優於RedisGraph v1。2。有條件地擴充套件節點需要20到50毫秒，找到一個節點的程度約為7毫秒。

但是，我們發現其他類似圖形的操作（例如簡單搜尋）妨礙了我們的效能，並經常導致超時。對於我們而言，搜尋是一筆不小的交易，因為這是欺詐分析師開始Genome會話的主要方式。我們試圖克服這一問題，但是最好的解決方案要求我們使用其他元件，這使得我們的解決方案的維護和開發成本非常高。

重新評估我們的選擇

在這個階段，我們對如何前進感到困惑。我們不能接受沒有可供我們使用的圖儲存解決方案。因此，我們著手研究其他公司如何解決這個問題。這是我們發現的：

如您所見，所有這些公司都使用知名技術開發了自己的Graph DB解決方案。每家公司內外都知道自己的用例，因此有意義的是，每個人都可以為自己開發一個出色的Graph DB。這種觀察將我們帶入了下一步的旅程：構建自己的Graph DB解決方案。

基因組圖資料庫

為了構建Graph資料庫，我們研究了Genome的兩種操作。首先是搜尋特定的節點和邊。第二個是用於條件擴充套件和節點度計算的圖形操作。欺詐分析師通常會透過搜尋開始Genome會話，然後使用圖操作繼續進行探索。

結果，我們定義了針對這兩個操作最佳化的 資料模型 。一方面，它可以回答有關節點（我們的實體和屬性）和邊緣（節點之間的相互關係及其屬性）的查詢。另一方面，這種具有邊和節點的資料模型使我們能夠非常快速地執行圖操作（例如展開）。

與LinkedIn，Twitter或 Facebook 相似，我們選擇了RDBMS作為Graph DB的基礎引擎。在我們的例子中，我們使用 PostgreSQL ，因為它已在Feedzai堆疊中使用。我們還探索了Cassandra作為可能的替代方法，但是它為一般搜尋查詢提供了更少的靈活性，並且由於我們的圖形操作還需要其他查詢來檢索屬性，因此大多數圖形操作的效能通常較差。

我們在PostgreSQL中的解決方案-Genome V2-獲取原始資料並將其轉換為聚合資料，儲存到包含節點和邊的多個表中。此外，我們按型別劃分節點和邊，以支援資料分片和可伸縮性。

總之，在所有類別中，Genome V2均比Genome V1快。就搜尋操作而言，它比Genome V1快37倍，就圖形操作而言，它比Genome V1快131倍。

總結

本機圖資料庫是不錯的通用解決方案，在過去幾年中已經獲得了很大的普及。儘管這些解決方案已經發生了巨大的發展，但它們仍然缺乏大型資料集的成熟度和效能，這迫使我們構建自己的圖儲存，專門針對應用程式的需求量身定製。

隨著新圖形資料庫的開發，這種情況將來可能會進一步發展。無論使用哪種工具，我們都將繼續開發Genome之類的產品，並盡最大努力為客戶提供最佳效能和功能。

從角度來看，在Genome V1中，對於一個標準銀行，我們只能處理1周的資料，而現在，我們可以輕鬆處理6個月以上的資料，以及數十億個節點和邊緣。這為基因組創造了一個新的世界，使我們的客戶能夠探索和了解更好的欺詐模式，而這些模式以前是不可見的。

（本文由聞數起舞翻譯自Randy Au的文章《Empowering Fast Graph Visualizations for Fraud Detection （or Why We Built Our Own Graph Database）》，轉載請註明出處，原文連結：https：//medium。com/feedzaitech/empowering-fast-graph-visualizations-for-fraud-detection-or-why-we-built-our-own-graph-database-4dee85f0688f）