阿里云：圖計算及其應用（2022）（69頁）.pdf

《阿里云：圖計算及其應用（2022）（69頁）.pdf》由會員分享，可在線閱讀，更多相關《阿里云：圖計算及其應用（2022）（69頁）.pdf（69頁珍藏版）》請在三個皮匠報告上搜索。

1、封面頁（此頁面將由下圖全覆蓋，此為編輯稿中的示意，將在終稿 PDF 版中做更新）卷首語 近年來，基于圖數據的計算（圖計算）得到了學術界和工業界越來越多的關注，被認為是人工智能發展的一個重要方向。本專場圍繞圖計算系統、應用及前沿學術研究問題，首先介紹阿里巴巴開源的一站式圖計算系統 GraphScope 的設計思想、基礎能力以及未來發展方向；另外，邀請來自學術界和工業界的大咖，分享圖計算最前沿的學術和技術熱點；同時，邀請在業務中應用圖計算技術的客戶，分享圖計算在真實業務場景中的應用案例及效果。目錄 一、圖計算發展的回顧與展望.5 二、GraphScope：人人可用的一站式圖計算.15 三、Grap

2、h+Insight 在關聯數據中發現商業價值.32 四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用.48 五、圖計算在全域數據融合場景的實踐.60 一、圖計算發展的回顧與展望 5 一、圖計算發展的回顧與展望 摘要：本文整理自上海交通大學安泰經濟與管理學院數據與商務智能系講席教授、數據與商務智能系系主任、歐洲科學院院士、IEEE Fellow 林學民，在云棲大會“圖計算及其應用”分論壇的分享。本篇內容主要分為四個部分：1)子圖羅列 Subgraph Enumeration 2)內聚子圖 Cohesive Subgraphs 3)網絡彈性 Network Resilience 4)二分圖

3、Bipartite Graph 什么是圖？這個圖不是我們平時說的圖形或者圖像，這個圖是點和邊。點代表事物，邊表示他們之間的關系。我們最早知道圖是歐拉定理和格尼斯堡七橋問題，然后翻山越嶺，經過歷史的長河，我們來到了本世紀初的圖數據庫和大圖計算。一、圖計算發展的回顧與展望 6 現在各行各業都需要圖，比如：Web Graph，Social Network、Protein Interaction Network 等等。下圖是一個圖的應用場景，左邊是各種各樣的應用，應用可以分解出基本算子，然后基本算子再分解出最基本算子，所以做系統就要把最基本算子處理好。1.子圖羅列 Subgraph Enumerati

4、on 左邊 P 是模式圖，中間 G 是數據圖，通常模式圖比較小，可能就是幾個點，數據圖有可能非常大。下面是從 G 中找到所有和 P 同構的子圖實例的三個樣例。所以能想象，在實際應用中這種映射有可能會有成千上萬，甚至上億的量。下面來分享一下子圖羅列在各行各業中的應用。1)實時周期檢測 下圖是幾年前和阿里合作的實時周期檢測項目，主要用于欺詐檢測和洗錢檢測。一、圖計算發展的回顧與展望 7 2)檢測指定社區 3)單 CPU 解決方案 一、圖計算發展的回顧與展望 8 4)分布式技術 在分布式技術中沒有哪一個算法是最好的，需要我們根據數據分布選擇適合的算法。2.內聚子圖 Cohesive Subgraph

5、s 下圖是曾經和阿里合作的一個項目，目的是抓住刷單的水軍。這個問題我們是怎么解決的呢？其實就是將問題轉化成抓 Bi-Clique 就可以了。所謂的 Clique 就是每兩個點之間都有一條邊，那么如何把所有的 Clique 或者最大的 Clique 找出來呢？這里就會有一個很大的難點。因為 Clique 和 Clique 之間是可以重疊的，這樣就會使數目變得非常大。一、圖計算發展的回顧與展望 9 在數據庫他們會做各種各樣的變種，比如 Quasi-Clique，那么如何定義他們呢？比如 clique 的邊數是|v|(|v|)-1，那么 Quasi-Clique 就是|v|(|v|)-1。K-Ple

6、x 在 Clique 里它的度數等于 n-1，那么 K-Plex 每個點的度數就會大于等于 n-k。一、圖計算發展的回顧與展望 10 K-clique 是子圖中任意兩個頂點之間的距離小于等于 k，K-club 同樣也是任意兩個頂點之間的距離小于等于 k，但是它的兩點是指子群中兩點的距離。K-Core 是指子圖中每個點的度數大于等于 k。這個就比較簡單，比如現在這個圖里找一度數最小的點，如果度數等于或者大于 k 就 finish 了。小于 k 的，我們就把它除掉，再 update 度數。K-Truss 是 K-Core 的加強版，每條邊上三角形的個數要大于等于 k-2。那么為什么說 K-Trus

7、s 是加強版呢？你能想象一個 K-Truss 一定是 k-1 Core，就是度數值一定是大于等于 k-1 的。K-Truss 的算法實際上和 K-Core 的差不多。算法復雜性就是把每條邊上的三角形個數全部羅列出來，這也是一個多項式算法。一、圖計算發展的回顧與展望 11 子圖里的度數如果大于等于 p 乘以全局的度數就叫 P-Cohesion。K-edge Connected 是指一個圖里去掉任意 k 減一條邊，它仍然是聯通的。所以 K-edge Connected Component 就是找最大的子圖。這是一個分解算法，最壞的情形是 N 的三次方。一、圖計算發展的回顧與展望 12 還有一個是

8、K-vertex Connected Component，這個我們暫時沒有找到非?？斓乃惴?。如果你們對這個話題感興趣，可以來一起提高它的性能。3.網絡彈性 Network Resilience Friendster 曾經是一家比較大的社交網站，但在 2005 年突然就 collapse 了。這到底是為什么呢，其實原因非常不好找。就比如你去了一個 party，好吃的東西和一個聊得來的人并不會讓你留很久。如果想要長時間呆留在 party，就需要很多這樣的人才可以。假如我是 K-Core，給你的 budget 是 b，也就是讓你想辦法留下 b 個人。這個 b 不用滿足 K-Core 條件，那么 b

9、要怎么選才能讓 network 最大呢？一、圖計算發展的回顧與展望 13 最終我們沒有找出非?？焖俚木_算法，所以就找了個近似算法。這個論文發表在了 VLDB 2017 上。4.二分圖 Bipartite Graph 所謂的 Bipartite Graph 就是把圖分成兩層，上面一層，下面一層。它們都沒有邊只有 cross 兩層。一、圖計算發展的回顧與展望 14 實際上它有很多應用，比如下圖最左邊的就是一個非常典型的 academic 的例子，上面是演員，下面是電影。二、GraphScope：人人可用的一站式圖計算 15 二、GraphScope：人人可用的一站式圖計算 摘要：本文整理自達摩院

10、的資深技術專家與圖計算團隊的負責人于文淵老師，在云棲大會“圖計算及其應用”分論壇的分享。本篇內容主要分為六個部分：1)實時離線一體圖計算引擎 2)全新的圖交互查詢/模式匹配 IR 與引擎 3)圖分析引擎的全新升級 4)圖學習引擎的全新升級 5)圖可視化解決方案 6)用戶友好型與易用性提升 目前存在各種各樣的圖數據類型，如上圖所示：網頁鏈接圖、生物結構圖、社交網絡圖等。二、GraphScope：人人可用的一站式圖計算 16 現實中的圖計算任務是非常復雜的工作流程，不是僅僅靠一個簡單的算法就能實現的。如上圖示例：1)欺詐檢測的工作流首先要通過 ETL 抽取數據，建模以后儲存管理，并進行格式轉換。2

11、)開展圖挖掘獲取有效信息。3)利用圖學習，即機器算法尋找共性特征；第四，展開圖分析，通過標簽擴散；最后，交互式分析與結果可視化。但是，在真實的應用場景中問題復雜，計算模式多樣，解決方案碎片化；同時用戶的門檻很高，學習難度也很大；海量數據的計算復雜度高且效率低。因此，解決圖計算大規模應用的挑戰是我們 GraphScope 系統開發的重要目標。二、GraphScope：人人可用的一站式圖計算 17 GraphScope 的構建，始于 2020 年底。兩年的時間里，我們結合了阿里的海量數據場景以及以達摩院團隊和業界專家學者的合作成果，將各個團隊的圖計算工作整合在一起，最終形成了 GraphScope

12、 系統。具體來說，GraphScope 的基本架構如上圖所示。底層現在是 Vineyard 分布式內部存儲，同時支持其他類型的存儲。中間層為一系列高性能圖計算引擎，并且用 Python 語言把各種各樣的圖計算的負載串聯在一起，提供了一個統一的圖模型和算法庫。同時本系統可以和上下游的其他生態環節打通，使用戶可以在使用系統的時候，能以很低的成本同時拷貝上下游的數據。團隊目標是希望 GraphScope 成為用戶開發圖計算應用的第一站，通過開源努力打造一個業界圖計算的標準。二、GraphScope：人人可用的一站式圖計算 18 1)為用戶建立簡單、通用、靈活的編程模型，拓展 Gremlin 和 Py

13、thon。2)支持豐富的圖計算任務的類型，比如說圖分析、圖交互式查詢、圖模式匹配、圖學習等。3)達到業界領先的性能；第四，有一個開放、易用的 Notebook 的環境；最后，與上下游的業務做深度結合，形成一個全生命周期的一個設計。12 月開源以來，GraphScope 入庫了中國科協“科創中國”平臺，在今年的 OSCAR開源產業大會上得到了“尖峰開源社區和開源項目”獎。兩年時間里系統積攢了2000+Github stars，上百個各種各樣的圖分析和學習算法庫，在阿里每天大概完成近 5 萬的日常任務支持。同時，系統支持復雜的圖模型，單個圖的規模大小在阿里內部也超過了 50TB?？傮w開發效率對于工

14、程師來說也是從幾周加速到幾個小時的時間。關于 GraphScope 平臺，用戶有很多問題，如下圖所示：支不支持 JAVA？是否可以把算法放進來？支持 Spark 嗎？數據怎么更新？如何支持在線推理？怎么直觀管理生命周期？如何編輯交互式的圖查詢？不用 Python 可以嗎？等等。因為我們要打造的是一個人人可用的圖計算系統，如果大家還有新的問題與建議，也歡迎大家多給我們一些反饋。二、GraphScope：人人可用的一站式圖計算 19 1.實時離線一體圖計算引擎 首先，講一講 GraphScope 如何實現離線一體圖計算引擎。關于 GraphScope 究竟是不是圖數據庫，這是一個常見的問題。杭州有

15、很多關于圖數據庫的創業公司，大家也很容易聯系到我們是否也是圖數據庫。但我們不是一個圖數據庫，GraphScope其實是一個圖計算引擎。在真實的用戶場景中，用戶首先有一個實時的數據源會被處理，比如說互聯網的用戶日志，或者說銀行的用戶交易。這個數據會沉淀到一個主數據庫，即 OLTP 的主數據庫。二、GraphScope：人人可用的一站式圖計算 20 舉個例子，用戶從銀行 ATM 機取款，這筆操作一定是一個 transaction，就是存在事務的一個數據庫里。隨后這個數據庫里會定期周期性地同步到一個數據倉或數據庫里。這些數據包括一些實時的數據，例如日志等行為：在某應用中點了一個商品、點了一個鏈接、看

16、了某個帖子。日志同樣會被沉淀到數據庫里。那么這些分析與查詢，在傳統意義上都叫 OLAP 請求。那么圖處理在現實中是什么呢？一些模式 learning 的計算，數據從這個端口到那個端口可能要很長時間，比如在阿里最典型的場景里可能要一天或者兩天的時間。但是這樣會讓 freshness 下降，fresh 是新鮮度數據，意思是數據傳遞從這里到那里經過兩天的時間，數據可能就不這么新鮮了。目前解決這個問題最好的辦法是做圖數據庫。換言之，數據都存在數據倉庫里和數據庫里，如果不想經過很長的鏈路加載，這時候就需要圖數據庫，即 graph database。但是，如果數據一旦涉及雙寫的問題，跨系統的 ACID 即

17、數據的一致性很難保證。因此，GraphScope 是一個圖計算引擎，可以從關系數據庫中實時地把一個關系數據庫的表投影成一張圖，而用戶的增刪改查還是在關系數據庫里來實現。GraphScope 系統本身不處理數據的增刪改查，但是它可以通過 LOG 同步的方式永遠和外部數據源的圖保持一致；同時支持服務化能力、交互式查詢、圖分析、圖學習。未來，我們希望 GraphScope 的 capability，即處理計算的類型可以更加豐富，這個是我們的下一部分的工作，預計 2023 年的第一個季度可以完成正式開源，大家敬請期待。二、GraphScope：人人可用的一站式圖計算 21 2.全新的圖交互查詢/模式匹

18、配 IR 與引擎 很多用戶關心，GraphScope 支持圖模式匹配嗎？為什么查詢這么慢？怎么調優？在偏數據圖查詢的場景里，我希望做一些解答，這也是我們下一步的工作。我們第一個想解決的問題是，如何更好的支持更多的圖查詢語言。我們的目標是解決用戶的需要，用戶增加一種圖查詢語言，需要一百多種不同的算子。那么如果引擎把這一百多種算子各自實現一遍，基本上是無法正常運行的。二、GraphScope：人人可用的一站式圖計算 22 第二，是否能支持圖模式匹配？第三，如何支持更好的系統的自動查詢優化，即系統自動匹配一條最優路線？最后，如何支持更多類型的圖查詢，是采用高查詢吞吐還是并行加速？那么如何在一個系統里

19、讓交互式查詢引擎支持這么多能力呢？首先，我們在關系數據庫的查詢算子上做了一些和圖相關的擴展，發現絕大多數現有的圖查詢語言的語義，其實都可以用非常有限的算子來實現。因此算子的空間從幾百個甚至大幾百個優化精簡到幾十個。并且這幾十個的表達能力足夠強到，把所有現在最常見的查詢全都覆蓋掉。第二，我們需要做一層更通用的查詢優化器，預計是明年的第三季度。我們認為在這層查詢只有算子的組合，可以自動基于圖上的特征來做查詢優化。優化之后我們分為兩個路徑，第一個叫 High QPS，目標是讓這個系統在單位時間內能處理更多的圖查詢。另一條鏈路是 data parallel 的 plan，目標是單個查詢的延時盡量小。第

20、三，我們會構建一個通用的存儲，預計明年的年終完成。它可以支持動態圖、靜態圖、內存、外存。3.圖分析引擎的全新升級 那么還有一些問題怎么解決呢？二、GraphScope：人人可用的一站式圖計算 23 如圖所示，如何高效地開發并讓用戶能執行更多種多樣的復雜圖分析的問題，以及如何適配已經有的 JAVA 等圖算法；還有如何更好的融入像 Spark 為代表的大數據的這種處理生態。這個就是我們要解決的問題。對于這些問題，我們提供 FLASH 框架。真正的圖計算系統中面臨的分析問題非常多樣化，不一定所有都是固定點計算，一些有非常復雜的控制流。那么我們的目標其實不僅僅是要達到一個很好的性能，同時我們還要讓這個

21、開發變得簡單。所以我們提出了FLASH，它不僅是讓開發簡單，使得大家的代碼行數可以都減少了，最多的情況下減少了 92%。大概只有不到 10%的代碼行數，可以最高加速兩個數量級。同時，基于 FLASH 我們提供了 72 個常見的各種全新的圖算法，可以直接在GraphScope 里使用。二、GraphScope：人人可用的一站式圖計算 24 我們現在有很多的圖引擎，尤其計算引擎。除了 GraphScope 以外，很多的生產中用的引擎是在大數據套件中使用的，但是往往性能會比較差。是否能把 Sprak 上的一些應用運行在 GraphScope 上，并充分發揮 GraphScope 的性能，將這個生態打

22、通呢？要解決這個問題，首先要解決如圖所示的一些問題。即如何在 GraphScope 上通過各種 JAR 來實現 Java 的高效運行。二、GraphScope：人人可用的一站式圖計算 25 如果不考慮性能，那么 JAVA 對 C+、c 語言、原生代碼的調用都翻譯成了一次跨語言的調用，但這中間就會有數倍的性能的磨損。那我們能不能解決這個問題呢？其實是可以的，我們和阿里云的編譯器團隊做了一套開源的 Fast FFI 的解決方案，自動地把 JAVA 和 C+之間的數據類型和方法對接，生成膠水代碼?？梢宰?JAVA 代碼很容易地去調用 C+里邊的代碼，保證它的安全性和易用性。同時，把 C+中的代碼通過

23、 LLVM 可以直接翻譯到 JVM 上的 byte code，打通了 native code 和 JAVA code 之間的屏障。通過這一系列的工作，我們的性能基本上達到 C+在 JAVA 實現的性能與 JAVA 和 C+類似的能力。二、GraphScope：人人可用的一站式圖計算 26 目前的支持主要是通過兩條路徑，一條是 GraphScope Java SDK 實現了性能提高；另一條是 GraphScope for Giraph 降低圖計算任務的運行時間。同時我們也做了 Spark 支持，核心的一點是 Spark 是現在最廣泛使用的大數據處理套件。它本身自帶的圖計算 GraphX 非常低效

24、，基于 GraphScope 的跨語言能力賦能 GraphX 加速。同時更好的一點是內部的存儲是直接作為 RDD 被 Spark 的下游任務直接使用，而不需要把這個數據載入到一個中間文件中。所以通過整體的方案實現了和 Spark 的對接。流程圖如下所示：二、GraphScope：人人可用的一站式圖計算 27 達到效果 Spark 的性能提升大概是 4.8 倍，端到端的性能提升大概是兩倍。其中，端到端的意思是一個數據的轉換、轉碼和重新加載的速度。就用戶體驗來說，和基本的 Spark 沒有區別。4.圖學習引擎的全新升級 GNN 的訓練框架其實越來越多，各種類型的學術界和工業界都已經開發出來了。那么

25、它沒有一個很好的支持工業界的在線推理的方式，而我們能不能利用各種各樣的像 GPU 這樣的新興的硬件呢？這些答案都是肯定的。首先我們做了一個升級，增加了高吞吐的采樣引擎，這部分已經進入了主分支。同時，我們也已經完成了一個動態圖推理的采樣服務。使得我們在 GraphScope 上開發的模型可以很容易地服務客戶。二、GraphScope：人人可用的一站式圖計算 28 工業級分布式 GNN 訓練中的挑戰主要是計算與資源利用需求不對等。模型訓練是在稠密的數據集上做計算，圖采樣是在很稀疏的圖上做計算，對內存的要求會比較高。兩邊的不對等使得我們 GPU 要么內存帶寬，要么 GPU 的計算能力使用效率不高。通

26、信、存儲等也是同樣道理。為了解決這些問題，我們使用采樣訓練解耦、異構硬件加速和兼容 PyG 生態。二、GraphScope：人人可用的一站式圖計算 29 采樣訓練解耦在邏輯上把圖的采樣過程和圖的訓練過程分為兩個角色來分別執行，中間用一個渠道可以讓他們通信。這個渠道可以是共享內存，比如說共享顯卡的內存和共享主機的內存；也可以通過網絡，也可以通過高速互聯網絡。通過這樣一個解耦的方法實現它能靈活部署、獨立伸縮，同時又能利用各種部署模式，使得高并發采樣和采樣訓練異步的能力得以實現。我們也實現了異構硬件加速。比如說 GPU 上采樣的支持，通過把特征做緩存，把圖結構做切分等，充分利用 GPU 間的互聯的特

27、征，加速采樣過程。二、GraphScope：人人可用的一站式圖計算 30 兼容 PyG 生態是指，用戶可以在沒有任何修改的情況下，可以直接使用 PyG 上的現有的模型。5.圖可視化解決方案 這部分工作是我們和來自螞蟻集團的 AntV 團隊一起來合作完成的。比如有一張圖，圖數據很大，怎么把它展示出來？如何進行探索？怎么讓用戶能交互式地把查詢給表達出來，直觀地把圖的整個生命周期管理起來？二、GraphScope：人人可用的一站式圖計算 31 比如可以管理圖，建一個圖的模型，導入圖，進而分析圖的數據。那么想做到這樣，用戶需要有一個類似于整個圖的 bi 工具。在整個站點中實現一個 zero code

28、的對接到 GraphScope 上，然后讓用戶來實現上述功能。然后它也支持 Gremlin 的查詢，pattern 的繪制，對 pattern 進行查詢，點邊條件過濾，擴展節點，在這個結果上進行探查。6.用戶友好性與易用性提升 最后我們希望能實現對用戶的友好性和易用性的提升，關鍵不在于我們的技術怎么樣，而在于我們怎么樣才能服務好用戶。三、Graph+Insight 在關聯數據中發現商業價值 32 三、Graph+Insight 在關聯數據中發現商業價值 摘要：本文整理自螞蟻集團數據可視化方向負責人林志峰，在云棲大會“圖計算及其應用”分論壇的分享。本篇內容主要分為四個部分：1)大勢所趨技術價值和

29、趨勢 2)生機勃勃應用場景和生態 3)厚積薄發這些年的工作與沉淀 4)淺知拙見落地探索和應用實踐 近 些 年，圖 不 管 加 什 么 都 會 成 為 一 個 大 熱，比 如 Graph+Database，Graph+Computing，Graph+Knowledge，Graph+Visualization 等。我自己所在的領域里，我發現可視化頂會論壇里，超過 30%以上都是跟圖相關的一些論文，這就可以說明圖是一個大熱的課題。1.大勢所趨技術價值和趨勢 在過去 20 年的數據浪潮里，我相信這張圖大家都不陌生。傳統中我們通過 BI 工具從數據里獲取洞察，BI 就成為了一個非常常用的工具。但隨著數據

30、規模的增大，以及更多關聯數據的要求，我們慢慢發現，傳統的數據庫并不能滿足高效的查詢要求。剛才提到的圖數據結構，它是刻畫現實世界最理想的數據特征。不管是人與人之間的關系，企業之間的往來，點對點的物流，還是整個社會上下游的銜接，都可以用圖的數據結構去描述，非常準確，同時也非常高效。三、Graph+Insight 在關聯數據中發現商業價值 33 如果把這些數據放到傳統的關系數據庫里，就會發現它會帶來很多存儲冗余，表達稀疏以及復雜查詢，這就會變得非常緩慢，并且非常復雜。但是如果用圖引擎可能非常優雅的幾行代碼，就能把一個三度查詢表達出來。正是因為這些局限性，我們經常在圖數據庫圈里看到這么一句話，關系數據

31、庫里存的不是關系，而是數據。下圖是一個非常經典的模型，DIKW。原始數據經過數據加工，變成一個有意義的信息。當我們把這些信息組合起來成為一個知識，并從這個知識里挖掘到一些可以用于預測未來的因果關系，我們稱它為智慧。但是經過幾年后，我們慢慢發現在 Knowledge 和 Wisdom 之間，有巨大的鴻溝難以跨越。三、Graph+Insight 在關聯數據中發現商業價值 34 更實際的是在這個過程中，我們發現從里面找到相關性的 Insight 會帶來更多實際的業務價值，所以 Graph 和 Insight 的結合會越來越被重視。下面給大家看一個更加直觀的例子，怎么從圖里面獲得洞察？下圖是兩個 mo

32、ck 的虛擬數據，銀行卡賬號和交易明細。三、Graph+Insight 在關聯數據中發現商業價值 35 字有點小大家可能看不清，但哪怕你能看清里面的每一個字母和數字，都不能快速的得到洞察。下面我們嘗試把它可視化出來，我相信你可以立刻得到一些關鍵的點，或者說有一個大概的印象。阿拉伯數字大概是在 1200 年前后出現的，中國的甲骨文數字是在公元前 1600 年，最早的楔形文字是在公元前 3000 年，而洞穴壁畫在公元前 4 萬年就已經出現了。換句話說，人類習慣用圖形、圖像去表達，比用文字和數字足足早了 4 萬年。各種科學實驗也驗證了，人類對于圖形、圖像識別能力的速度和效率比文字和數字高出1-2 個

33、數量級。所以在我看來不管人類基因怎么突變，人類依賴圖形、圖像去獲取信息依然還是我們最主要的渠道。眼睛是我們最主要的信息獲取通道，我們大腦里超過 50%的組織是用于圖像圖識別和獲取知識的，這是從人類自身的特點去看這個趨勢本身的變化。那么我們在圖方向堅持做那么久，有沒有可能只是我們的一廂情愿。但好在頂級經營機構的一些趨勢報告驗證了我們的一些判斷。在跟進圖分析的這些年里，它幾乎在 Gartner 的趨勢報告里從未缺席。2019 年提到圖分析是獲得復雜關系多維數據洞察的關鍵技術；2020 年提到關系的使用將重構整個數據和分析的價值；2021 年預測了 50%的客戶會有圖分析的需求；直到 2022年更激

34、進的說分析模型將取締現有傳統數據模型。雖然說的很激進，但市場已經給出答案。三、Graph+Insight 在關聯數據中發現商業價值 36 2.生機勃勃應用場景和生態 我們國內外一些公司，其實他們核心依賴的技術跟圖都極其相關。不管是 Google 的搜索，還是亞馬遜的產品推薦，還是 Facebook 社交網絡里的廣告定位。換位到國內對標的企業大家對圖也是強依賴的。比如 360，會用圖去發現整個軟件供應鏈鏈路上，存在的全網大規模固定資產中漏洞的傳播路徑。天眼查、企查查會提供給付費用戶一些增值服務，比如關于企業關聯關系、股權結構等。三、Graph+Insight 在關聯數據中發現商業價值 37 從下

35、圖中，可以歸納出圖應用的核心以及主要的四個應用場景。3.厚積薄發這些年的工作與沉淀 下圖是 AntV 的技術棧?？v向分成三個域，分別是常規統計數據、關系數據、地理空間數據。三、Graph+Insight 在關聯數據中發現商業價值 38 今天主要是分享一下關系數據。這個棧被分為了三層，從下到上分別是引擎層 G6、組件層 Graphin、平臺層 GraphInsight。這三層的關系相信從名字上就能看到它們所面向的客戶和場景。同時我也很自豪地說，AntV G6 這個引擎在 2017 年 6 月 26 發布至今，在全球開源可視化項目里排名世界第二。接下來我們會繼續努力，希望早一天能代表中國登頂。當然

36、這里也離不開阿里、螞蟻以及社區的很多同學在這個方向投入。三、Graph+Insight 在關聯數據中發現商業價值 39 這是 2020 年 11 月 22 日對外發布的第一份關于圖可視化解決方案的白皮書。包括6 個文檔，將近 18 萬字的內容，是我們聯合阿里，以及社區內外三十多個設計師、產品經理、技術人員，一起書寫的關于圖可視化分析的一些產品案例、經驗總結。我們做這件事的初衷是希望在技術不斷前進的同時，還能有一些認知上的迭代，也希望這個白皮書在未來能夠繼續迭代。三、Graph+Insight 在關聯數據中發現商業價值 40 4.淺知拙見落地探索和應用實踐 在業務落地的過程中，我們發現了兩個業務

37、團隊的顧慮。第一個是整個投入的成本，因為畢竟是新技術，大家對圖可能很陌生，不知道畫一個圖在 web 上需要多大的成本，然后未來能否持續迭代。另外一個是實際效果，因為傳統的統計分析是有沉淀，有慣性的。今天我們用圖的方式給一個呈現，用圖的方式做數據挖掘和分析，究竟用戶能不能接受，并且這種分析能不能真正帶給業務效果，都是它們擔心的。針對這兩個問題，我們慢慢摸索到，能夠讓業務快速進行驗證，是成為新技術落地的殺手锏。不管你是數據研發的同學、數據算法的同學、還是業務的分析師，能夠用最短的路徑、最高效的方式讓他們看到數據，摸得著，玩的起來，慢慢這件事情就有戲了。所以這里會有兩個最主要的卡點。第一個是關系數據

38、究竟如何獲??？另外一個是有了數據之后我如何去分析？三、Graph+Insight 在關聯數據中發現商業價值 41 接下來我們先從“關系數據如何分析？”講起。那么就不得不提到 GraphInsight，它可以零代碼完成圖分析洞察的業務驗證，低代碼支持功能模塊的持續集成。什么是零代碼？怎么去完成呢？我們還是拿剛才那份假數據，包括賬號和交易明細點邊的結合。三、Graph+Insight 在關聯數據中發現商業價值 42 我們快速的把這兩份數據導到系統里面，然后做一些簡單數據映射的匹配。1 分鐘就可以把一個非?？菰锏谋砀駭祿兂梢粋€圖可視化。核心就是告訴 GraphInsight這份數據哪些映射到點，哪

39、些映射到邊，他們屬性的配置關系。邁出了這 1 分鐘這一步之后，業務人員、研發人員就可以把它當作一個工作室，配各種節點的樣式，把一些更加重要的屬性映射出來。改變它的布局，顏色，甚至把一些業務的語義含義在圖里面表達。那么一個帶著互動能力的圖分析雛形就出現了。接下來 3 分鐘的調參配置，自定義樣式，交互，布局，讓關系圖栩栩如生。這一步之后，更重要的來了，怎么去分析？這份數據里有沒有更深層的含義？三、Graph+Insight 在關聯數據中發現商業價值 43 這個時候可以用 GraphInsight 提供的分析資產。它是把圖可視分析領域里，常用的分析手段全都封裝成一些能力組件。在 GraphInsig

40、ht 的資產平臺里，可以隨便挑選那些已有的分析能力，直接掛載到自己的應用里，直接使用。這個過程大概需要 6分鐘。我們再重新回顧一下整個過程。從一個 excel 表，1 分鐘的時間把它變成一張可見的圖，3 分鐘的時間把業務語義的數據映射給上面配置出來，最后花了 6 分鐘時間從里面選一些資產做進一步的分析，得出洞察力。這是 GI 提供的一個零代碼數據分析和能力。三、Graph+Insight 在關聯數據中發現商業價值 44 接下來說一說“關系數據如何獲??？”。如果要到真實的數據里，那真實的數據就可不是一個 excel 能夠承載的，它需要連接一個數據源。目前 GraphScope 跟 GI 是打通的

41、。大家可以非常高效的在 GI 里去把 GraphScope 配置進來，這樣我們就會擁有的一個強大的圖計算和存儲引擎在后臺為我們提供服務。有了這幾步簡單的一些配置，我們就會擁有數據查詢服務的能力。三、Graph+Insight 在關聯數據中發現商業價值 45 回到 GI 的研發，要做這么一個業務系統究竟是怎么一個過程？其實很簡單，只需要四步。第一步，選擇一個模板。這個模板更多的只是一個布局，比如你希望未來系統是什么樣子，左右布局還是上下布局。第二步，選擇分析資產。默認模板會提供一些分析資產，如果你覺得這些分析資產并不是你需要的，可以直接把它刪掉，加入自己需要的資產?；蛘呖梢杂靡粋€空白模板去搭出自

42、己的業務應用。三、Graph+Insight 在關聯數據中發現商業價值 46 第三步，一鍵 sdk 導出。這是一份帶 sdk 可以二次開發的代碼，換句話說它對我們平臺是完全無依賴的，你可以直接放到自己的業務系統里，它就可以直接部署和上線。最后，配置自己真實的數據源。這可能是唯一需要寫代碼的地方。那么剛才所看到業務系統就可以跟你自己的業務系統完美的融合了。三、Graph+Insight 在關聯數據中發現商業價值 47 另外當遇到一些長尾的需求，我們的核心產品并不 cover 用戶的時候，我們可以在GI 里像保存一個項目一樣，把分析思路所沉淀下來的東西變成了一個模板。它就類似于你在 BI 里打開一

43、張報表，它永遠存在你的空間。所以從這個角度來說，GI 其實可以理解成一個 Web 版的 BI。最后來想暢想一下未來。我們希望在未來 1-3 年，能夠探索出在圖方向的可視化查詢。3-5 年能夠成為圖分析領域的數字基建、助力圖業務的商業價值增長。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 48 四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 摘要：本文整理自阿里巴巴數據中臺數據資產平臺的何興盛（河竹），在云棲大會“圖計算及其應用”分論壇的分享。本篇內容主要分為四個部分：1)業務場景中的“大”圖 2)基于子圖挖掘的設備識別解決方案 3)離線子圖采樣系統 Graph View 4)

44、總結 1.業務場景中的“大”圖 立足于數據中臺，我們每天都需要處理超大規模的數據，當我們落地圖計算時也不例外。這里的“大”圖有兩層含義，一是圖的數量特別多，舉一個典型的例子，我們每天都要從近千億的采集日志中提取百億級別的圖，然后在規定的時間內完成分析和計算。那么在這個數據規模下，一些比較通常概念下的指標計算也變得非常棘手。另外一個是單圖的規模特別大。以用戶商品交互網絡為例，因為網絡中的實體類型特別多，用戶的行為又特別豐富。對于這種類型的圖，我們經常會遇到幾十億的節點上沉淀了上萬億關系的邊。那么針對這兩類問題我們是怎么解決的呢？四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 49 馬老師

45、曾經說過，“small is powerful”。我們的思路也很類似，都是從子圖出發。對于“圖的數量多”的情況，我們就需要看一下它的基本組成成分，以及是否有顯著的結構特征，然后我們再設計高并發的算法。對于“圖的規模大”的情況，就需要有一個良好的子圖抽樣系統，從一個大圖中提取出我們需要的子圖，然后再完成后面的分析和計算。2.基于子圖挖掘的設備識別解決方案 下面我將就“圖的數量多”和“圖的規模大”這兩類問題的典型場景展開講述。設備標識符是移動互聯網領域中非?；A，同樣也非常重要的一個信息，它的本質是對一個物理設備的具體描述。然后我們才能通過設備識別服務，對用戶做一些個性化推薦、用戶口徑統計以及廣告

46、轉化中的歸因分析等等。但實際上因為種種原因，整個移動互聯網上有多種解決方案在市場上并行。那就會導致我們在采集日志中會對同一個物理設備采集到多個設備識別符。下面舉個例子，在正常的一個采集日志中，我們通常會采集設備標識符和用戶行為商品信息等等，這里我們只需要關注設備標識符。如果兩個設備標識符出現在同一條日志中，我們就認為它產生了連邊。如果一條采集日志中有多個設備標識符，我們就認為它是一個全連接的結構。匯總一段時間的數據，其實就可以可視化出一個結果。就是我們希望把所有屬于同一臺物理設備的設備標識進行聚合，滿足廣告外投、用戶畫像等下游需求。從下圖中我們可以看到它包含了多個連通分量，那聯通分量是有多少呢

47、？大家可以想一想整個移動互聯網領域的設備有多少，問題的規模就會有多少，它們是成正比的。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 50 第一是設備網絡顯著子圖挖掘：基于采集特性，設備網絡世界中是否存在顯著的子圖模式？大簇是否存在超家族特性？第二是超大規模聯通分量識別：在降本增效的大背景下，如何穩定高效支撐千億規模的聯通分量識別？第三是大簇分解問題：針對一個設備大簇，如何對其進行切割，使得分割結果準確&穩定？那么如何解決以上三個問題呢？其實它們有一個共性，就是需要子圖的匹配能力。也就是在一個給定的大圖里面找到與一個給定小圖同構的子圖。以下圖為例，假設有兩個需要查詢的小圖，和兩個待查詢

48、的大圖。從圖中我們可以看到，T1 中包含一個 Q1，T1 包含一個 Q2。簡單來說這個算法的能力就是在輸出T1 包含幾個 Q1 和 Q2，然后我們會記錄下它的個數和實例。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 51 針對這種問題我們自研了的基于 ODPS 的子圖模式匹配算法，我們采取了一種分解再合并的算法思路。比如下圖中的例子，上面是一個小圖，下面是一個待查詢的大圖。我們首先會按照一定的模式把上方的小圖分解成多個三元組，然后通過類似的方式，把下面的大圖也分解成三元組。接著對小圖進行合并，使它回歸到原始的結構。在小圖的合并過程中我們發現，下面兩個節點相同，且上面兩個節點不同的進行

49、了合并，合并后可以看到們它們回歸到了原始的結構中。對于大圖分解后的結構，我們按照這種條件進行合并，如果合并成功了，那就說明大圖中也有一個相同的實例。那么對于一些比較簡單的結構，一次迭代可能就可以完成。對于一些稍微復雜的結構，通過兩次迭代也幾乎能夠滿足所有結構。下面來說下顯著模式挖掘與子圖匹配算法。由于采集日志中一條數據最多采集的設備 ID 類型是有限的，因此需要考慮的子圖規模具有上限。對于節點規模比較小的子圖，我們可以窮舉出它所有的結構。對于節點=4 的 motif，一般只保留 p1-p8 這八種結構。對于 size 為 5 和 6 的 motif，僅考慮全連接結構。最終我們需要考慮的圖結構也

50、就是從 p1-p10 這十種結構。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 52 下圖是基于某個真實業務統計的結果，首先看下鏈式的結構。長度為 2，節點個數為 3 的鏈式結構，占 p1-p10 所有結構的 7.8%；長度為 3，節點個數為 4 的鏈式結構占比驟降到了 1.3%；長度為 4，節點個數為 5 的鏈式結構占比幾乎到了 0。這就可以說明整個鏈式結構在設備網絡中是很難出現的。所以就進一步證明了，一個大簇的網絡直徑一旦超過 5，它就一定是有問題的，我們要對其進行拆解。接下來我們再來看一下全連接的結構。從圖中我們可以看到 p3-p6 的全連接結構占比已經超過了 60%，這就說明

51、這個設備網絡的連接其實是偏稠密的。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 53 對于 size 為 5 和 6 的全連接結構，雖然它的總體占比比較低，但是如果我們只考慮size 為 5 的 motif，這種全連接的結構占比就高達 98.4%。所以對于這種類型我們只需要考慮全連接結構，不需要再去窮舉出其他 size 為 5 的 motif 類型。接下來介紹下該怎么去識別超大規模的圖連通分量。這個問題的特點是：第一，整個網絡中全連接的子圖比較多，它會有非常多全連接的小簇，在大簇中它又包含了很多全連接的子圖。第二，小圖占比比較大。小簇代表了一個比較正常的物理設備，在非孤立簇中小簇的占

52、比為 84%。也就是如果我們能把連通分辨先識別出來，那么整個設備識別問題，我們就已經解決 84%了。第三，操作的時效性要求特別高。這一步操作是所有下游任務的基礎，我們必須在保證的時間內完成計算。那么我們的思路是什么呢？首先要對全連接子圖這種比較稠密的結構進行化簡，在不影響連通性的情況前提下把復雜的結構轉變成簡單的結構。第二步，我們可以先把這些小簇識別出來。這樣就不需要再讓它進入下一步聯通分量識別的任務，減輕下游的壓力。第三步，我們會把一些大簇難以識別的問題交給一些成熟的圖計算平臺。剛才第一步提到的化簡，我們是采用了一種叫做 Star Compression 的算法。它的目的是在不改變連通性的前

53、提下，對圖中的邊進行壓縮，這是一個迭代式的算法。它的核心是把一個稠密的連接，通過幾步迭代的方式，最終轉變成星狀的結構，所以叫做 star compression。通常對于節點為 5 左右的小簇，經過兩次迭代，可以保證收斂。稀疏子圖的匹配要比稠密子圖匹配更高效，方便利用 GPS 的能力。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 54 先看一下第一行數據，可以想一下雙十一期間整個淘寶的流量有多大，平常我們就可能要面臨千億級別的采集日志，在其基礎上做連通分量的識別。在過往的時間內，調度高峰期計算資源緊張的情況下，其實沒有現成的圖計算引擎接口，可以 hold 住這么大的吞吐數據量。所以我

54、們必須要給下游的圖計算引擎減輕壓力，經過 Compression 圖壓縮，子圖識別之后，可以發現其實已經過濾掉約 87%的邊了。剩下交給第三方圖計算平臺的壓力就小了很多。通過這種方法，大約有一百多億的邊進入下游的圖計算引擎，從而保證聯通分量識別的穩定性和可靠性。對于一些比較小的業務，通常通過一輪的迭代就可以達到比較好的結果。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 55 這是設備識別，它是一個比較稠密的網絡。其實我們還實現了在一些偏 sparse 的網絡，比如說分享關系。兩個用戶分享了同樣一個商品，我們就給他建立一條邊，也就是 a 給 b 分享，b 和 c 分享，a 和 c 還有

55、分享，對于這種稀疏的分享關系，只需要利用子圖識別的能力，就可以得到很大數據量的下降。接下來是設備大簇拆解問題?，F實世界中這個情況總是非常復雜的，整個移動互聯網領域也是這樣，我們每天的流量中包含了用戶各種復雜的行為，比如換機、惡意的流量、山寨機，甚至不是物理設備，是一些軟件生成的流量。這些行為就會產生非常多的噪聲邊，就可能把很多無關設備連接到了一起，形成大簇。這里我們就希望能找到一種可解釋、穩定的方式對大簇進行拆解，得到背后真正的物理設備。這是一個圖例，假設這是一個規模還可以的大簇。我們將它拆解成若干個具體的物理設備，這些拆解結果就直接影響了你整個移動設備的口徑統計，以及不同系統對接時轉換的準確

56、性。那么設備大簇拆解的挑戰又有有哪些呢？第一，設備大簇是非常多樣的。即使節點數量相似，結構相似，但排列組合不同，大簇也可能存在一定的差異。第二，設備大簇的規模非常龐大。以一個業務單日新增的大簇來看，如果把大簇定義為 20 以上，那么單日新增的大簇就會有約 20 萬個，這就影響了百萬個具體物理設備的聚合結果。如果拉長時間周期，就有可能直接影響了上億的設備識別結果。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 56 那么對于大簇要如何拆解呢？我們的思路是，大簇并不是無序隨機產生的，而是多個超家族成員通過異常的連邊產生的組合。那么這個問題就變成怎么識別哪些節點屬于正常結構，哪些節點屬于異常

57、的連接邊。這就需要我們對整個網絡進行角色定義，對網絡中的節點進行特征提取。這是一個問題的一體兩面，一個合適的定義，它影響著我們怎么給節點抽取特征，抽取特征的好壞就影響著分類的結果。最終通過多輪的迭代，我們把大簇拆解的問題轉變成了一個對圖中節點分類的問題?；氐酱蟠氐膯栴}，我們定義了三種角色。第一個叫做 D-CoreClique，是指一個緊密連接的團體；被多個更大的團體所共享；團體內成員的邊權重大于他們與團體外成員的邊權。第二個叫做 Peripherals，是指與多個同類共享同一個 CoreClique。第三個叫做 D-Connector，在一個圖中起橋梁作用；通常連接多個 CoreClique。

58、如果能夠把這些角色識別出來，再基于一些策略的拆解就變得比較容易起來。剛才在跑聯通分量識別的時候，我們已經用了 GPS 子圖匹配的能力。所以對于每個節點我們已經保留了該節點的結構信息，那么這個信息在這里其實就發揮了用處，我們可以把每個節點它自身及它鄰居的結構信息匯聚起來去做分類任務。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 57 3.離線子圖采樣系統 Graph View 離線子圖采樣系統主要用于從一個大圖中抽樣出一個易分析的子圖。在推薦領域圖上法可以提效的核心原因，是通過擴散機制為下游人物匯聚更多的信息。在數據中臺沉淀了如此多關系數據的情況下，當今降本增效的大環境下，我們第一步要

59、做的就是存儲統一和結構統一。存儲統一是指整個團隊關系數據的使用僅此一份，從而避免下游因為各種需求的微小修改，而把數據備份多次，造成的巨大存儲浪費。結構統一是指所有關系數據的存儲范式必須是一致的，這樣方便我們后續做一些模塊接口的開發。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 58 當我們做完結構統一和存儲統一之后，其實我們背后就有了一張非常規范的異質信息網絡。在平常的任務中，我們并不需要去總覽這個大圖的信息，我們只需要根據指定的路徑找到一些我們感興趣的小圖就好了。在 GraphView 里，我們根據自己的業務特性，設計了三種模式。第一個是 Path 模式，它可以從源節點出發，按照你

60、指定的路徑得到一個比較完整的圖結構。第二個是 Pair 模式，它最終只輸出頭節點和尾節點的映射關系。第三個是 End 模式，只輸出尾節點。下面是個真實的案例，現在要給指定的人群做商品召回，召回邏輯就是先通過這個人群去找到他好友人群，然后我們看到這些好友人群買了什么商品，以及這些商品的相似商品是什么，這就是一個 U2U2I2I 的召回邏輯。在最新的 GraphView 版本上，我們測試了 1 萬個用戶，我們發現只需要約 3.8 分鐘就可以得到最終的商品召回，其實也是對應了我們剛才介紹的 End 模式。四、小圖撬動大圖：千億規模用戶群體網絡的子圖挖掘與應用 59 4.總結 今天跟大家介紹的主要是我

61、們自建的一些圖引擎。其實依托于阿里生態的一些比較成熟的計算平臺，比如 ODPS、GraphScope。我們根據自己的業務特點，提出了一些比如說連通分量識別，子圖匹配、子圖抽取這樣一些不含業務語義的計算引擎。這些計算引擎其實和下游的比如說一些 GNN 推薦是無縫銜接的。最終在下游結合一些業務特征，我們就可以做出一些比較有意思的數據資產。五、圖計算在全域數據融合場景的實踐 60 五、圖計算在全域數據融合場景的實踐 摘要：本文整理自 StartDT 資深算法專家的曾云，在云棲大會“圖計算及其應用”分論壇的分享。本篇內容主要分為四個部分：1)公司介紹 2)全域數據融合場景介紹 3)圖計算實踐 4)未來

62、展望 1.公司介紹 StartDT 作為一家獨立的第三方數據科技集團，旗下有奇點云（Data Cloud）和GrowingIO（Analytics Cloud）兩大品牌。專注為客戶構建統一開放、中立安全的數據云，和全域全場景智能易用的分析云，協同客戶培育其自有的數據能力，在數據商業時代占據制高點。其中，奇點云（Data Cloud）核心的數據云產品，為企業去提供中立、安全、可控的數據云的基礎底座，幫助企業做好數據的沉淀和管理。GrowingIO（Analytics Cloud）的分析云，致力于為客戶提供數據+分析+智能+運營的一站式產品與服務，提升數據驅動增長能力，全域全場景賦能商業決策。下圖

63、為 StartDT 產品的矩陣大圖，底層是數據云，上層是分析云。五、圖計算在全域數據融合場景的實踐 61 從數據采集到數據加工到數據應用，我們提供端到端全鏈路的產品和服務，去幫助企業完成從構建數據云的基礎設施，到挖掘數據數據價值，到數據驅動應用的全場景的需求。本次分享的主題是全域數據融合，下面和大家分享一下 StartDT 在全域數據融合的經驗。StarDT 的 CEO 張金銀（行在）是淘寶消費者信息庫 TCIF 的創始人。他在 2012 年花了一年的時間，拉通了阿里消費者與所有用戶的數據，然后在建立統一用戶識別ID 的基礎之上，構建了 one data 體系，生成了三千多個通用的用戶標簽。這

64、個項目當時也在阿里內部被各個業務去使用，這件事也論證了全域數據融合能帶來巨大的商業價值，以及 StarDT 有最領先的經驗。2.全域數據融合場景介紹 StarDT 合作了非常多的企業，包含了泛零售、金融、制造、政企等行業。不管是哪個行業的客戶，發展到了一定的規模，它的數據和業務也逐漸成熟。在這個階段企業會有非常強烈的做數據驅動業務這樣的訴求。但是在做這件事情也會面臨非常大的挑戰。第一個問題是用戶數據割裂的問題。企業通過多渠道運營沉淀了大量的數據，如果這些數據分散，它是很難形成有效的數據資產的。五、圖計算在全域數據融合場景的實踐 62 第二個問題是標簽數據未整合。如果沒有做統一的數據拉通，在這樣

65、的基礎之上去做畫像和標簽，都是很難做到精準的，數據的價值也很難體現。第三個問題是數據化運營體系薄弱。沒有一個數據化運營的基礎底座，企業的數據加工就會非常的低效，也很難去滿足業務更多的數據需求。所以全域數據融合這件事情是非常有必要，是做數據數字化轉型的一個基礎。下面以零售企業為例，客戶可能會有淘寶、天貓、京東等渠道去做品牌的運營，通過公域渠道去獲取優質的用戶流量。另外客戶也會有自己的 APP、公眾號、訂閱號去運營自己的私域流量。一個用戶可能會關注天貓店，關注企業的公眾號，下載企業的 APP，然后在 APP 上完成了一筆商品交易。但是用戶的這些操作行為會落在不同的業務系統，如果沒有做有效的數據拉通

66、，其實是沒有辦法通過這些零散的數據，去識別這些操作的背后其實是同一個用戶。權益數據融合這件事情是一個非?；A而且非常有必要的工作。通過全域數據融合可以把碎片化的信息以圍繞一個自然人 ID 的方式去融合和拉通起來。這里說的用戶 ID 是描述真實世界中用戶的數字化標識，包含像 Union ID、手機號、身份證號。另外 ID-Mapping 是全域數據融合里非常核心的技術，它是將同一個用戶在各個不同渠道、生態及業務系統中的身份標識串聯起來并映射到一個統一的用戶標識。五、圖計算在全域數據融合場景的實踐 63 有了全域數據融合的基礎底座，再和大家分享一個身份新增的例子。如果一個用戶關注了企業的公眾號，然

67、后去注冊了一個賬號。這個時候我們就會獲取到一條用戶信息，包含了手機號、Open ID。然后我們把這個新增的信息輸入到ID-Mapping 計算的過程中，就可以去持續擴充用戶唯一標識的列表和持續豐富用戶的特征數據。全域數據融合整體的解決方案，包含通過整合多元的業務數據，使用 ID-Mapping的技術去把各個業務系統的用戶 ID 進行關聯，并且生成唯一用戶標識。從而進一步可以串聯起來各個業務系統的用戶標簽和行為軌跡，全面助力全域營銷的場景。五、圖計算在全域數據融合場景的實踐 64 整個方案架構包含三個核心的服務，數據采集、識別服務、查詢服務。通過采集可以把多個渠道的數據進行統一收集以及加工處理，

68、然后再進到識別服務對用戶識別做相應的計算。最后把結果以 API 的方式對外服務和調用。在權益數據融合實踐過程中也會面臨非常多的問題。第一個問題是，如果企業的數據體量非常大，渠道非常多，ID 類型多的話，那么它對計算性能的要求就會非常高。還有一些大型企業它可能會有億級別的用戶數據，有幾十甚至幾百個渠道，ID 的類型可能也會有十幾種。用戶 ID 類型多，ID 關系復雜的話，一些傳統的規則計算的邏輯也會遇到一些挑戰。第二個問題是渠道數據的質量問題。如果渠道數據參差不齊，就需要考慮做 ID 關系的權重以及數據置信度的設定。最后做完整個數據融合的計算，這樣的結果怎么去做驗證呢？這就是第三個問題。圖計算在

69、全域數據融合遇到的這些實踐的問題，能帶來一些很好的解決方案。下面我們將從七個維度去比較規則識別和圖計算識別的方案。幾個維度包含可用性、時效性、可解釋性、業務擴展性、準確度、開發和維護成本、可推廣性。規則識別基于多渠道場景會很快遇到計算性能的一個瓶頸，通過圖計算識別能夠去解決計算性能的一個限制。另外我們也在多個大型項目中沉淀了很多業務規則，解決了一些業務復雜的訴求，最終形成了一套基于規則和圖計算識別的一個解決方案。這個方案從計算性能、業務的復雜度以及最終結果的可解釋性上都具備優勢。五、圖計算在全域數據融合場景的實踐 65 3.圖計算實踐 整個全域用戶關聯的流程分為四個的步驟。第一個步驟是數據接入

70、。這個部分會把多個渠道的數據和業務系統的數據做采集和接入。然后在這個階段也需要強調一下數據安全性的問題，針對一些敏感和重要的個人用戶數據，在這個階段也要做好數據加密和脫敏的處理。第二個步驟是 ID 校驗。每一個渠道都需要做一個校驗判定，來確定哪些 ID 要參與到 ID-Mapping 的計算。第三個步驟是 ID 關聯。它有幾個細分的步驟，包括關聯、回溯、拆分和刪除等邏輯。最后基于計算好的結果做一個存儲和落盤。我們有一整套基于流批圖一體的技術架構方案，它的計算會包含兩個鏈路。第一個鏈路是實時流。數據通過 Kafka 推過來，進入到實時計算引擎做計算和加工處理。這個是為了滿足一些企業對于實時用戶識

71、別和實時標簽的訴求。第二個鏈路是離線。包含數據初始化和增量計算兩個部分。數據初始化階段會把全量的數據都加載進來，再做統一的加工和處理。最后輸入到圖計算引擎去做計算，然后再把結果去做落盤。數據初始化一般只需要做一次，之后只需要保留每天的增量計算的部分。五、圖計算在全域數據融合場景的實踐 66 基于流批圖一體的技術架構，我們會定期把圖計算和流計算的結果做修正，然后把我們的結果以 API 的方式對外去做輸出調用。下面來分享下在用戶關聯場景使用圖計算的流程。首先數據接入會把多個來源的數據做一個聚合，這里的 ID-Mapping 我們以證件、unioinid 及手機號三個特征為例子。聚合好的數據首先需要

72、對一些臟數據或者是異常數據做處理，然后再把加工好的聚合表形成一個點集合和編集合的數據。點集合會包含了證件、unioinid 及手機號的數據，邊集合主要是三個特征之間的關系。然后會把點和邊的數據加載到圖計算引擎做一個連通圖的計算。最后形成一個基于用戶特征和 unioinid 的一個映射表。五、圖計算在全域數據融合場景的實踐 67 基于全量億級別的數據我們做過一個測試。如果前期的加工過程是用 Hive 處理億級別數據，整個 ETL 會耗時 65 分鐘。圖計算基于四臺 32G 的機器計算大概需要 15分鐘。最后結果落盤 1 分鐘，整個過程大概耗時 81 分鐘。增量計算的部分主要的處理邏輯差異在于，前

73、期聚合和異常處理的部分，這里考慮一個百萬級別的增量數據，整個計算過程大概是 19 分鐘，這個計算結果是能滿足一個中型企業數據量級計算要求的。另外我們也對常見的一些圖計算引擎做了一些技術調研。因為我們在做數據治理的時候用了圖數據庫，所以首先考慮了我們熟悉的圖數據庫技術 Janusgraph。同時也調研了開源的圖計算引擎，Spark GraphX 和 Alibaba GraphScope。從使用場景、運維以及對于現有技術架構的兼容性這三個維度做一個綜合的評估。其中 Janusgraph 更適合 OLTP 場景，Spark GraphX 和 Alibaba GraphScope 對于OLAP 場景會

74、更實用。另外 GraphScope 有一個優勢，它有豐富的使用場景，能夠支持圖計算、圖學習和圖查詢，性能上也能有一定的保障。為了讓我們整個的數據加工處理和圖計算任務的開發能夠更靈活，我們把圖計算引擎深度集成到了算法組件中。形成了一套集數據集成、交互式任務開發、任務調度、任務運維、數據治理和數據安全能力于一體的體系。底層是圖計算引擎，能夠支持計算和查詢的服務。在接口層能夠支持交互式任務和周期任務的運行。往上的應用層我們提供基于全域數據融合的算法以及基于數據安全異常檢測的算法。五、圖計算在全域數據融合場景的實踐 68 在實踐過程中我們也會遇到一些具體業務場景的訴求。比如屬性合并的問題，如果一個用戶

75、關聯到多個屬性，就需要根據時序或者渠道的優先級去設定屬性合并的邏輯。另外一個是不能合并的規則，比如有一些企業希望他們用戶的證件或者手機號不要做合并，這個就需要通過我們的業務規則去實現。在實踐的過程中也會遇到渠道的數據質量參差不齊的問題，我們會提供數據置信度的方案。通過對不同來源、不同渠道的數據去設定置信度的參數，以及設計置信度的計算公式。我們可以去滿足企業在不同場景，例如做客戶身份識別、sso、權益、營銷推廣等。五、圖計算在全域數據融合場景的實踐 69 整體來說應用圖計算對于現有的全域數據融合的方案能帶來一個顯著的提升?；诹髋鷪D一體的方案，整個效果能體現在多、快、好、省四個方面。多是指我們能夠合并更多的渠道，快是指我們的數據處理的速度快，好是指我們的處理結果準確度高，省是指我們能夠跨渠道關聯出更多的用戶。4.未來展望 首先我們會講現在的一套基于業務規則和圖計算識別的方案，形成一套標準的算法包方案。把一些業務場景和不同企業沉淀下來的邏輯形成一些配置開關，能夠快速的落地到不同的客戶場景。五、圖計算在全域數據融合場景的實踐 70 第二我們會進一步去深度集成產品，把一些計算的能力去集成到我們的算法組件。最后我們會探索更多圖計算方向的應用，包括數據治理，還有像推薦場景用戶商品的知識圖譜等等。