- 圖算法:行業應用與實踐
- 嬴圖團隊
- 4974字
- 2024-07-25 16:04:11
2.2 圖分析與數據科學
圖分析(Graph Analytics)在本質上是對圖數據的處理與分析,其過程可以概括為圖計算。而圖計算的范疇不僅包含數據的計算或分析,還包含元數據管理、模式管理、數據建模、數據清洗、轉換、加載、治理、圖分析與計算等一系列操作。或許我們用大數據生命周期來剖析圖分析、圖計算會有一個更全面的理解。
圖2-5所示的是大數據發展歷程中通常會遇到的五大問題,依次是大數據存儲、大數據治理、大數據計算與分析、大數據科學和大數據應用。

圖2-5 大數據(圖數據)的五大問題
圖2-5中的大數據在很大程度上可以直接替換為圖數據,畢竟圖數據是大數據發展的必然趨勢、終極階段(圖2-6)。我們解決圖2-5中的五大問題的目的如下:
1)通過信息的關聯化(高維、原生圖)存儲,采集更準確、更靈活、更能直觀反映真實世界問題的數據,用于支撐決策。
2)通過圖數據建模、血緣分析、數據核驗、元數據管理等一系列數據治理工作來為科學的數據存儲、計算與應用提供保障。
3)通過讓信息更靈活、更透明、更實時化地被計算與分析,解鎖大(圖)數據的價值。
4)通過數據科學指導的圖計算與關聯分析,例如對風險傳導的深度下鉆與科學計量、對用戶群體進行精細化產品、服務定位等,進行深度、復雜、白盒化(可解釋)的數據分析及預測來提升決策準確率。
5)通過基于數據科學的應用與解決方案開發(高維建模、白盒化算法、決策與反饋機制),改善下一代產品、服務的開發。
圖2-6中所示的數據發展趨勢有兩條主線和一個核心觀點。
? 主線1:數據處理底層技術的核心發展趨勢是從關系型數據到大數據直至深數據(圖數據)。
? 主線2:對應底層技術的面向數據的處理維度呈現了從點到線、由線及面再到體的由簡入繁、自低維到高維、自低算力需求到高算力需求、自簡單分析到復雜分析的一個自然發展過程。
? 核心觀點:圖計算的本質是復雜網絡化計算,是與人類大腦工作最為貼切的逆向工程,圖數據庫相對于傳統關系型或NoSQL數據庫的效率與性能有指數級的提升。

圖2-6 從關系型數據到圖數據、深數據的發展趨勢
我們以主線1為例簡要展開論述。20世紀70年代至80年代是關系數據庫發展的早期階段,它迅速地占領了政企IT市場,其中的佼佼者有IBM Db2、Oracle、Sybase等。1983年是關系數據庫發展的標志性年份,SQL(結構化查詢語言)國際標準應運而生,作為關系數據庫的通用查詢語言,盡管各個廠家都有自己的特殊語法與功能實現,但大體上都會支持通用的SQL,以保證系統間通信、系統遷移、升級換代與維護等操作的便捷性。隨著互聯網,特別是移動互聯網、云計算業務的興起,大多數基于單機、小型機或集中式架構設計的關系數據庫在面向海量數據、多樣多維多模態異構數據處理時的缺陷開始體現得越來越明顯,于是基于分布式架構理念設計的Hadoop、非關系數據庫等陣營開始出現,大數據庫處理與分析技術開始得到越來越多人的關注。在大數據發展的歷程中,出現了多種類型的架構陣營,可以簡單地梳理為如下幾個陣營。
? 基于MapReduce理念的架構陣營:最為常見的是Hadoop陣營,以及基于內存加速的Spark項目。
? 基于NoSQL理念的非關系數據庫陣營:包含多種數據庫架構,如列數據庫、寬表、KV、文檔、時序、多模數據庫以及圖數據庫等。
? 基于SQL接口,但對底層進行了擴充與增強的新型關系型數據庫、數倉、數湖陣營:數量龐大的各種商業或開源關系數據庫、MPP數倉、各類流批一體化數倉、實時數倉等。
需要指出的是,盡管出現了多個陣營,但是自1983年開始的以SQL為主流的趨勢并沒有因為大數據等架構的出現而產生實質變化,畢竟絕大多數的新型數據庫與框架依然還在向SQL兼容。然而,這一切可能會在2024年迎來一個實質性的轉變。屆時,數據庫查詢語言將迎來第二個國際標準—GQL,即圖查詢語言。換言之,Hadoop、Spark、NoSQL、數倉數湖盡管制造了無數的“噪聲”,但是并沒有形成一整套國際標準—一個會推動全球IT生態自上而下革新的標準。這種革新從底層上要解決的是SQL與關系數據庫在處理多維、多模態數據時的無力—無法深層、動態、靈活、高效地完成對數據的處理與分析,特別是對于復雜關聯、深層遞歸形式的分析—SQL在語言設計層面就不具備這種能力,而關系數據庫二維表結構的低維性讓分析實時性的問題變得更加“不可能”。事實上,SQL的這種低維性已經被詬病了很多年,但是在底層架構上一直沒有本質的改變,盡管MapReduce等架構的出現讓數據處理量大幅提升,但是并沒有改變淺層數據處理的特征。換言之,幾乎所有的分布式數據庫只能面向淺層數據處理,任何深層數據處理依然會遇到效率低下、延遲巨大甚至錯誤求解的問題。而這一“不可能的任務”有望在圖數據庫的時代被解決。因為圖數據庫自下而上關注的是數據的關聯關系,從建模、存儲到數據治理再到數據計算與分析,以及數據查詢與應用,它不再拘泥于關系數據庫的表結構,不再受限于主鍵、外鍵,讓數據建模更加靈活和高維,不再專注于淺層查詢,也第一次讓計算引擎成為數據庫的一等公民,進而意味著在面向深層、復雜、動態、遞歸查詢、分析與計算時的效率有指數級提升。這也是為什么我們會提出一個觀點:圖數據庫是終極數據庫,或最接近終極數據庫的一種形態。
辯證地看待任何問題,我們需要意識到,無論是出于認知的局限性還是有意的誤導,市場上很多所謂的圖數據庫在本質上都和圖沒有太大關系,它們都不具備對數據進行靈活建模、深度處理與分析、高效處理的能力,盡管它們都會毫無例外地宣稱自己是高性能、分布式圖數據庫。這些以假亂真的圖計算或圖數據庫產品有哪些特點呢?在此梳理如下幾條線索以供讀者迅速辨別真偽。
? 底層存儲引擎基于NoSQL或RDBMS實現。這是典型的拿來主義,如此構建的非原生圖不可能具有高性能處理能力,也沒有靈活的數據建模的能力。其中,最典型的有基于HBase、Cassandra、ClickHouse、Hadoop甚至MySQL、PostgreSQL、Oracle實現。
? 計算引擎基于Spark GraphX或第三方“圖上計算”引擎實現。以Spark GraphX為例,它僅僅是借用了圖的名字而已,其數據加載與處理效率相對于Hadoop而言只提高了1~2個數量級,但是距離真正的高性能依然非常遙遠,特別是面向實時數據時,Spark缺乏數據加載更新的能力,更缺乏深度下鉆與分析的能力。
? 宣稱可以同時支持多種圖查詢語言。例如,能同時支持OpenCypher與Gremlin可能意味著它對任何一種語言都沒有極致的性能優化,因為數據庫與查詢語言是一一匹配的,而通用性則需要長時間的性能優化來實現。甚至還有的圖數據庫可以通過SQL來實現查詢與分析,這基本就能斷定該系統依舊是傳統關系數據庫,而且也無法支持圖數據庫所應該具有的任一優點—靈活性、高效性、深度下鉆計算與分析能力。
? 一味鼓吹分布式、鼓吹萬億規模,但是卻連一個百萬量級的數據集都無法深度下鉆與高效處理。圖計算或圖數據庫面臨的最大挑戰并不在于數據存儲,而在于計算,特別是復雜計算、深度計算與關聯、靈活計算,這才是數倉數湖無法有效解決的。這種挑戰有的時候不是通過100臺低配服務器解決的,而是應該通過可能10臺高配服務器來高效解決的—本質上我們是在回答一個問題:到底是100臺1線程的大集群的計算能力高,還是10臺10線程的小集群的計算能力高?答案是后者。然而大多數人都會回答錯誤,因為大多數人忽略了網絡延遲與I/O對于分布式系統在數據關聯計算時的降維打擊。這就是算力引擎在圖數據庫中必須成為一等公民的最核心原因。所謂高性能計算絕不等于高性能存儲,存得多并不意味著算得動。
? 基于開源項目或社區版項目包裹。基于開源盡管可以快速地出“成果”,但對于底層代碼卻是失控的,因為極少有人能真正去吃透別人的底層代碼,安全風險隱患無法得到有效控制。至于社區版,更是赤裸裸地對別人知識產權的侵犯,也意味著任何底層功能的改進都不可能實現(通常基于別家項目包裹的產品會出現宣稱支持多種查詢語言的情況,讀者可自行甄別)。
圖2-7描述了從源數據到數據應用與產品、圍繞數據全鏈路生命周期的分步流程。

圖2-7 數據科學與分析流程示意圖
1)多源數據采集:多源、多維、多模態數據采集、ETL/ELT。
2)圖數據建模:高維建模,設計并創建點、邊Schema。
3)圖數據存儲與數據治理:數據持久化、元數據庫管理、核驗、血緣分析等。
4)圖計算與分析:圖查詢邏輯與功能設計與實現(后文將展開討論)。
5)圖算法與映射:圖算法調用(通常作為圖計算與分析的子集存在)。
6)圖譜管理與可視化:集成化、圖譜化、可視化數據管理與展示,以及二次開發。
7)商務智能與決策:可看作包含以上所有步驟。
8)圖應用與產品:可看作以上7條的超集。
以上可以看作大數據應用視角下圖計算與分析結合數據科學的完整鏈路,涉及數據建模、存儲與治理、計算與分析、算法與映射、二次開發與應用場景等核心功能模塊。
提及數據科學與大數據分析,人們很自然地會聯想到商業智能(Business Intelligence,BI)。BI使用統一的衡量標準來評估企業的過往績效指標,并用于幫助制定后續的業務規劃。常見的BI組件一般包括:
1)建立KPI(Key Performance Index,關鍵績效指標)以明確面向所服務用戶的功能目標。
2)多維數據的匯聚、去正則化、標記、標準化等。
3)實時報表生成、報警等。
4)處理結構化、簡單數據集為主,而發展的趨勢是集成越來越多源、復雜的數據集,并進行更深度的計量、下鉆、關聯分析。
5)集成統計學分析模塊與概率模型模擬等功能。發展的趨勢還包括集成AI、圖嵌入算法等。
BI通常會在底層依賴某種數據處理(如ETL,數據抽取、轉換、裝載)架構,如數據倉庫等。隨著大數據技術的發展,BI系統正在越來越多地擁抱諸如內存計算(如IMDG數據庫技術)、實時圖計算或圖數據庫等新事物,歸根結底是為了更高的數據處理效率、更深的數據處理能力、更靈活的數據建模方式,以及對于真實業務挑戰的更真實的還原方式,而圖計算顯然是一個可以同時滿足以上限定條件的答案。
數據科學則可以通過科學的方法論來指導實現BI系統中的預測分析、數據挖掘等功能。數據科學使用統計分析、模式識別、機器學習、深度學習、圖計算等技術,對獲取到的數據中的信息形成推斷及洞察力。相關方法包括回歸分析、關聯規則計算(如風險傳導路徑分析、鏈路分析、購物籃分析)、優化技術和仿真(如蒙特卡羅仿真用于構建場景結果)。在BI系統的基礎上,數據科學又可為其增添如下組件與功能:
? 結構化/非結構化數據、多種類型數據源、超大數據集。
? 優化模型、預測模型、預報、統計分析模型等。
數據科學的發展從分析復雜度與價值兩個維度看,可分為3種境界、5個階段(圖2-8)。3種境界分別如下:
1)后知后覺—傳統的BI,滯后的延時分析。
2)因地制宜—實時化分析。
3)未卜先知—預測性分析。

圖2-8 數據科學的發展
圖2-8所示的5個階段與3種境界匹配關系如下:
? 后知后覺—描述性+診斷性
? 因地制宜—描述性+診斷性+指示性+(部分)預測性
? 未卜先知—描述性+診斷性+預測性+指示性+搶先式(基于預測的行動指南)
這5個階段自上而下實現的復雜度越來越高,畢竟每向前一個階段,所涵蓋的階段性能力就越完整,價值也越大,這也是為什么越來越多的企業、政府機構要把大數據科學驅動的大數據分析引入并應用到BI、智慧城市等廣泛的領域中來。
與大數據處理與分析項目中通常需要多種角色類似,依托圖計算技術,同樣需要行業問題專家(Subject Matter Expert, SME)、數據分析專家、建模工程師、大數據系統專家等一眾人才。區別在于,建模工程師需要擺脫傳統的二維表思維束縛,掌握用圖數據的高維建模,以及掌握如何進行高效的圖分析,在什么場景下用何種圖算法來實現更低的成本與更高的回報率。
數據科學屬于典型的把多學科知識集于一身的實踐,圖2-9示意了這種融合。
1)行業經驗:對垂直領域的深刻理解。
2)產品開發能力:能夠將數學模型轉換為可在圖數據處理平臺上運行的代碼,還能設計、實現和部署統計模型和數據挖掘方法等,最終形成產品或解決方案。
3)數理統計知識:能夠以數學、統計學模型、算法(如圖算法、機器學習、深度學習等)來抽象業務需求與挑戰。

圖2-9 數據科學的融合
我們看到國內大量的銀行只能把產品開發能力外包,原因在于業務人員缺乏開發能力,而那些號稱有自研能力的大型銀行,業務與科技部門也經常被各種問題困擾,其根本原因在于業務與科技之間沒有融會貫通,缺少具備“三江交匯”式數據科學分析能力的專業人員。
數據科學是一個新興的領域。數據分析專家負責為復雜的業務問題建模,運用業務洞察力找到新的商業機遇。對于這種能夠從海量數據中提取有用信息,再從信息中提煉出具有高度概括性與指導意義的知識、智慧甚至轉變為可以自動化智能(例如圖增強智能或圖AI)的新型人才,可以預見會受到來自市場越來越多的青睞。