從關系數據庫遷移到圖形數據庫的指南
跟隨
邁向數據科學
154
4
一、說明
????????TLDR:知識圖譜在圖數據庫中組織事件、人員、資源和文檔,以進行高級分析。本文將解釋知識圖譜的用途,并向您展示如何將關系數據模型轉換為圖模型、將數據加載到圖數據庫中以及編寫一些示例圖查詢的基礎知識。
二、為什么選擇知識圖譜?
????????關系數據庫非常適合創建列表,但對于管理不同實體的網絡來說卻很糟糕。您是否曾經嘗試過使用關系數據庫執行任何這些任務?
- 分析患者與數十人、地點和程序互動時的醫療保健護理事件
- 通過涉及的供應商、客戶和交易類型網絡查找金融欺詐模式
- 優化供應鏈的依賴關系和相互關聯的元素
????????這些都是事件、人員和資源網絡的例子,這些事件、人員和資源給使用關系數據庫的 SQL 分析師帶來了巨大的麻煩。隨著網絡規模的增加,關系數據庫的速度呈指數級增長,而圖形數據庫具有相對線性的關系。如果您正在管理活動和事物的網絡或 Web,圖形數據庫是正確的選擇。在未來,我們應該期待看到企業數據組采用關系數據庫的組合,對一個業務功能進行孤立的分析,以及知識圖譜的組合,用于跨功能的復雜網絡化流程。
????????基于圖形數據庫技術的知識圖譜旨在處理各種流程和實體網絡。在知識圖譜中,您具有表示人員、事件、地點、資源、文檔等的節點。并且您具有表示節點之間鏈接的關系(邊)。這些關系以名稱和方向物理存儲在數據庫中。并非每個圖形數據庫都是知識圖形。要被視為知識圖譜,設計必須將業務語義模型嵌入到跨越多個業務功能的各種節點集中,該模型反映在節點和關系的清晰業務名稱中。實質上,您是在從交互的業務的所有部分創建一個無縫的網絡,并使用業務語義將數據與它們所代表的流程緊密聯系在一起。這可以作為未來生成LLM模型使用的基礎。
????????為了說明知識圖譜中的各種數據集,讓我們看一個簡單的供應鏈物流示例。業務流程可以按如下方式建模:
供應鏈圖數據庫模型。圖片由作者提供。
????????此模型可以擴展到包括業務流程的任何相關部分:客戶退貨、發票、原材料、制造流程、員工,甚至客戶評論。沒有預定義的架構,因此模型可以向任何方向或深度擴展。
三、從關系模型到維度模型再到圖模型
????????現在,讓我們了解一下使用電子商務供應商的方案將典型的關系數據庫模型轉換為圖形模型的過程。假設該供應商正在運行一系列數字營銷活動,在其網站上接收訂單,并將產品運送給客戶。關系模型可能如下所示:
電子商務關系數據庫模型。圖片由作者提供。
????????如果我們將其轉換為用于數據倉庫的維度模型,該模型可能如下所示:
電子商務維度模型(數據倉庫)。圖片由作者提供。
????????請注意,事實數據表側重于事件,維度表表示合并到一個表中的業務實體的所有屬性。這種以事件為中心的設計提供了更快的查詢時間,但會產生其他問題。每個事件都是一個不同的事實數據表,很難看到從一個事件到相關事件之間的聯系。當維度實體(如產品)與另一個維度中的實體(如運營商)共享的所有事件(在多個事實數據表之間拆分時),沒有簡單的方法可以理解這些關系。維度模型一次關注一個事件,但模糊了不同事件之間的聯系。
????????圖模型通過對過程進行建模,解決了顯示實體之間相互關聯的問題,如下所示:
電子商務圖數據庫模型。圖片由作者提供。
????????乍一看,該圖模型與關系模型比維度模型更相似,但它可以用于與數據倉庫相同的分析目的。請注意,每個關系都有名稱并具有方向。可以在任何節點之間創建關系 - 事件與事件、人與人、文檔與事件等。圖形查詢還允許您以 SQL 無法實現的方式遍歷圖形。
????????例如,您可以收集與關鍵事件相關的任何節點并研究發生的模式。與非規范化維度表不同,層次結構被保留,每個級別都可以單獨引用。最重要的是,圖表在對業務中的任何事件或實體進行建模時更加靈活,無需遵循一組嚴格的模式約束。該圖旨在匹配業務的語義模型。
四、提取、轉換和加載 (ETL)
????????現在,讓我們看一個示例關系數據庫表,并創建一些示例腳本來提取、轉換數據并將其加載到圖形數據庫中。在本文中,我將使用Cypher語言,這是最流行的商業圖形數據庫Neo4j使用的語言。但這些概念將適用于圖形查詢語言(GQL)的其他變體。我們將使用以下示例產品表:
產品表。?
????????使用此查詢,我們可以提取過去 24 小時內更新的新產品:
SELECT product_id,product_name,cost_usd,product_status
FROM Product
WHERE last_updated_date > current_date -1;
????????我們可以將這些結果拉取到名為“df”的?Python Pandas?數據幀中,打開圖形數據庫連接,然后使用此腳本將數據幀合并到圖形中。
UNWIND $df as row
MERGE INTO (p:Product {product_id: row.product_id})
SET p.product_name = row.product_name,p.cost_usd = row.cost_usd,p.product_status= row.product_status,p.last_updated_date = datetime();
????????第一行引用參數“df”,這是來自 Pandas 的數據幀。我們將合并到節點類型“產品”中,該節點類型由別名“P”引用。然后,“product_id”部分用于綁定到節點中的唯一標識符。之后,Merge 語句看起來類似于 SQL 中的合并。
????????使用上面這樣的合并語句創建每個節點后,我們創建關系。關系可以在同一腳本中創建,也可以使用如下所示的合并命令在后處理腳本中創建:
MATCH (p:Product), (o:Order)
WHERE p.product_id = o.order_id
MERGE (o)-[:CONTAINS]->(p);
????????Match 語句類似于 Oracle 中的舊版聯接用法,在 Match 之后聲明了兩種節點類型,然后在 Where 子句中聲明了聯接。
五、對圖模型的查詢
????????假設我們已經構建了圖形,現在想要查詢它。我們可以使用這樣的查詢來查看從亞利桑那州吸引訂單的廣告組。
MATCH (ag:AdGroup)<-[:BELONGS_TO]-(a:Ad)-[:DRIVES]->(o:Order)<-[:PLACES]-(c:Customer)
WHERE c.state = 'AZ'
RETURN ag.group_name,COUNT(o) as order_count
????????此查詢將返回廣告組名稱和訂單數量(按亞利桑那州過濾)。請注意,與SQL不同,Cypher中不需要Group By子句。從該查詢中,我們將收到以下示例輸出:
圖形查詢的示例結果。圖片由作者提供。
????????此示例可能看起來微不足道,因為您可以使用訂單事實數據表在關系數據庫或數據倉庫中輕松創建類似的查詢。但是,讓我們考慮一個更復雜的查詢。假設您想查看從廣告系列啟動到收到可歸因投放所花費的時間。在數據倉庫中,此查詢將跨事實數據表(不是一個簡單的任務)并占用大量資源。在關系數據庫中,此查詢將涉及一長串聯接。在圖形數據庫中,查詢如下所示:
MATCH (cp:Campaign) )<-[:BELONGS_TO]-(ag:AdGroup)<-[:BELONGS_TO]-(a:Ad)
MATCH (a)-[:DRIVES]->(o:Order)<-[:FULFILLS]-(d:Delivery)
RETURN cp.campaign_name,cp.start_date as campaign_launch_date,MAX(d.receive_date) as last_delivery_date
????????我使用了一個示例查詢路徑,但用戶可以采用多種路徑來回答不同的業務問題。在查詢中,請注意,從“營銷活動”到“投放”的路徑經過訂單和投放之間的關系。另請注意,為了便于閱讀,我將路徑分為兩部分,從第二行中的 Ad 別名開始。查詢的輸出如下所示:
????????圖形查詢的示例結果。圖片由作者提供。
六、結論
????????我們已經查看了一些將電子商務業務流程從關系模型轉換為圖形模型的示例步驟,但我們無法在本文中涵蓋所有設計原則。希望您已經看到圖形數據庫需要與關系數據庫大致相同的技術技能水平,并且遷移不是一個巨大的障礙。
????????最大的挑戰是重新訓練你的大腦,遠離傳統的關系建模技術,從語義或業務建模的角度思考。如果您看到圖形技術的潛在應用,請嘗試概念驗證項目。使用知識圖譜進行分析的可能性遠遠超出了二維表格所能做到的!斯坦·帕格斯利