探索圖資料庫在資料資產視覺化中的應用

隨著社交、電商、金融、物聯網等行業的快速發展，現實組成了一張龐大的關係網，傳統資料庫很難處理關係運算，大資料行業需要處理的資料之間的關係隨著資料量呈幾何指數增長，亟需一種支援海量複雜資料關係運算的資料庫，圖資料庫應運而生。

1。圖資料庫介紹

這張圖是一個社交網路場景，每個使用者可以發簡訊、發郵件，分享資訊。這些都是最基本的增刪改查，也是大多數研發人員對資料庫做的常見操作。而在研發人員的日常工作中除了要把使用者的基本資訊錄入資料庫外，還需找到與該使用者相關聯的資訊，方便去對單個的使用者進行下一步的分析，比如說：我們發現張三的賬戶裡有很多關於推理小說和音樂方面的內容，那麼我們可以據此推測出他可能是一名學生，從而推送他可能感興趣的內容。

但是在資料分析過程中，會出現各種各樣的場景，比如說在一個典型的社交網路中，常常會存在“誰認識誰，誰上過什麼學校，誰常住什麼地方，誰喜歡什麼餐館”等查詢，這種查詢在資料分析過程中是很常見的，但是這種操作會因為資料庫的選擇不同而對效能產生巨大的差異。

傳統資料庫解決思路

傳統解決上述問題最簡單的方法就是建立一個關係模型，我們可以把每個員工的資訊錄入表中，存在諸如 MySQL 之類的關係資料庫，圖片展示的是最基本的關係模型圖。

基於上述的關係模型，依據需求，就不可避免的涉及到很多庫表的join操作，實現的查詢語句可能也會很長，並且這種程式碼可讀性很差，而且會有嚴重的效能問題。關於傳統關係資料庫的效能問題我們後續分析。

圖資料庫解決思路

在傳統資料庫雖然運用 JOIN 操作把不同的錶鏈接了起來，從而隱式地表達了資料之間的關係，但是當我們要透過 A 管理 B，B 管理 A 的方式查詢結果時，表結構並不能直接告訴我們結果。如果我們想在做查詢前就知道對應的查詢結果，我們必須先定義節點和關係。使用圖結構建模，節點和關係先定義是圖資料庫和別的資料庫的核心區別。

打個比方，我們可以把經理、員工表示成不同的節點，並用一條邊來代表他們之前存在的管理關係，或者把使用者和商品看作節點，用購買關係建模等等。而當我們需要新的節點和關係時，只需進行幾次更新就好，而不用去改變表的結構或者去遷移資料。根據節點和關聯關係，傳統資料庫建模可以轉換為圖片所示建模：

在透過圖資料庫原生圖查詢語言（Cypher）進行建模和查詢後，近百行的sql程式碼變成3，4行的程式碼可以明顯的看出圖資料庫在資料表達上的優勢：

MATCH （boss）-［：MANAGES*0。。3］->（sub），（sub）-［：MANAGES*1。。3］->（userid） WHERE boss。name = “zhangsan”

RETURN sub。name AS list， count（userid） AS Total

什麼是圖

圖的定義：A database that uses graph structures for semantic queries with nodes， edges and properties to represent and store data – independent of the way the data is stored internally。 It’s really the model and the implemented algorithms that matter。

圖資料庫是基於圖模型的資料庫。相比較於關係型資料庫，圖資料庫是真正注重“關係”的資料庫。圖資料庫的主要職能是管理圖資料，因此需要支援高效的對頂點/邊的查詢與更新；為了方便使用者的使用，通常還需要增加對事務（transaction）的支援，從而保證併發操作下的正常運作。

圖廣泛存在於現實世界中，從社交網路到金融關係，都會涉及大量的高度關聯資料。這些資料構成了龐大的圖，圖資料庫就是呈現和查詢這些關聯的方式。這種聯絡形成了一種互相關聯的資料，聯絡才是資料的本質所在。傳統的關係型資料庫並不能很好地表現資料的聯絡，而一些NoSQL（Not Only SQL，非關係型資料庫）資料庫又不能表現資料之間的聯絡。同樣屬於NoSQL範疇的圖資料庫是以圖的結構形式來儲存資料的，它所儲存的就是聯絡的資料，是關聯資料本身。

然而關聯資料中的聯絡本來就很複雜，若要在關係型資料庫中使用結構化形式來表現這種聯絡，則一般不能直接表示，處理起來既繁瑣又費事，並且隨著資料的不斷增長，其訪問效能將日趨下降。無數的開發人員和資料庫管理人員都或多或少地使用過關係型資料庫，在其應用的規模化進展過程中，對於資料庫的效能最佳化往往捉襟見肘、陷入窘境。圖資料庫沒有模式結構的定義，也不需要這些定義，它使用非結構化的方式來儲存關聯資料，所以能夠直接表現資料的關聯特性。

圖資料庫的發展趨勢

在眾多不同的資料模型裡，關係資料模型自20世紀80年代就處於統治地位，而且出現了不少巨頭，如Oracle、MySQL，它們也被稱為：關係資料庫管理系統（RDBMS）。然而，隨著關係資料庫使用範圍的不斷擴大，也暴露出一些它始終無法解決問題，其中最主要的是資料建模中的一些缺陷和問題，以及在大資料量和多伺服器之上進行水平伸縮的限制。同時，網際網路發展也產生了一些新的趨勢變化：使用者、系統和感測器產生的資料量呈指數增長，資料量不斷增加，大資料的儲存和處理；新時代網際網路形勢下的問題急迫性，這一問題因網際網路+、社交網路，智慧推薦等的大規模興起和繁榮而變得越加緊迫。而在應對這些趨勢時，關係資料庫產生了更多的不適應性，從而導致大量解決這些問題中某些特定方面的不同技術出現，它們可以與現有RDBMS相互配合或代替它們。過去的幾年間，出現了大量新型資料庫，它們被統稱為NoSQL資料庫。其中圖資料庫從最近十年的表現來看已經成為關注度最高，也是發展趨勢最明顯的資料庫型別。

NoSQL資料庫分為四種類型，分別是：

鍵值（key/value）資料庫

列儲存資料庫

文件型資料庫

圖資料庫

上圖就是從2013年來所有資料庫種類發展趨勢的分析結果如圖展示。圖（Graph）是非常強大的工具，因為它們透過以簡潔的形式表示資料關係，幫助商業世界和其他機構中的人們理解資料集。有了合適的圖資料庫，企業可以以關係圖的形式視覺化資料，並對其進行管理，以提高整體效能。比起傳統資料庫的資料儲存，圖資料庫能夠清晰的展現點與點之間的關係。許多組織之所以接受圖資料庫，是因為越來越多的行業認識到這種資料庫技術的重要性，尤其在複雜的場景下，如物流，金融風控，社交網路管理，媒體傳播分析等行業正在發揮不可或缺的作用。

圖資料庫是分析資料間關聯的最佳技術

圖資料庫對於可以在不同場景下發揮作用，從企業應用角度，業務使用者使用角度，資料開發者應用角度都發揮著作用。

圖資料庫產品

依據網站對Graph DBMS的排名來看，目前主流的圖資料庫有：Neo4j，Janusgraph，Dgraph，ArangoDB，OrientDB，TigerGraph等。下面我們來介紹一下目前圖資料庫的分類都有哪些。

圖資料庫分類

原生資料庫：

代表資料庫為neo4j、orientdb。其原生體現在查點到邊或者邊到點的時候，不需要走原來關係型資料庫的B+索引，節點本身就有指向索引，類似於連結串列的指標概念

直接在關係型資料庫之上構建的圖資料庫：

代表為AgensGraph，以及微軟的GraphView。SparkGraphX也可以基於關係型儲存結構進行轉化成圖結構，然後完成圖運算

使用外接nosql儲存的資料庫：

以Titan/JanusGraph為代表，以及使用外接的索引生成工具如Elasticsearch，OLAP支援外接Spark等工具，以及Cassandra/Hbase等nosql資料庫。

在圖計算上基於batch進行最佳化的新一代圖資料庫：

如DGraph。DGraph的儲存結構與cayley同樣借鑑了google的論文，將每個節點的屬性也作為一個節點與主節點產生聯絡，這樣更有益於基於batch來設計運算方法。

Neo4j

Neo4j圖資料庫，它是一個高效能的NOSQL圖形資料庫，它將結構化資料儲存在網路上而不是表中。它是一個嵌入式的、基於磁碟的、具備完全的事務特性的Java持久化引擎，但是它將結構化資料儲存在網路（從數學角度叫做圖）上而不是表中。

優勢：

可叢集，使用讀/寫負載平衡器將請求直接到一個叢集

支援事物、鎖、頁面快取

遍歷下：建立索引通常成本O（log（n）），但Neo4J的遍歷一個關係的複雜度趨向於O（1）

支援ACID事務，它確保實時顯示資料的合法性和準確性。

Cypher語法友好

劣勢：

Neo4j沒法儲存巨大的一張關係圖，因為他不支援分片

因為index-free adjacency，遍歷快但是計算隨機兩個節點最短路徑效能不佳

索引：

index-free adjacency，擅長遍歷圖，以及計算不存在大量關係的節點的圖

ArangoDB

ArangoDB圖資料庫，它是一個原生多模型資料庫，兼有key/value鍵/值對、graph圖和document文件資料模型，提供了涵蓋三種資料模型的統一的資料庫查詢語言，並允許在單個查詢中混合使用三種模型。基於其本地整合多模型特性，您可以搭建高效能程式，並且這三種資料模型均支援水平擴充套件。

優勢：

儲存空間佔用下：採用了元資料模式儲存資料；可透過記憶體提速，CPU佔用率低

支援主從叢集

Multi-collection transactions

擴充套件性好：JavaScript

用JavaScript和ArangoDB構建應用，Foxx微服務執行在DB內部，可快速訪問資料。

AQL功能很強大，配置程式設計遠方便於、靈活於Neo4J、OrientDB

Neo4J的Cypher也比較強大，清晰，但是不利於調整，靈活性不夠

OrientDB，類SQL，查詢繁瑣，調整不便利，內建SQL函式介面也不方便

劣勢：

插入效能稍低

索引：

自動索引_key屬性，_from和_to屬性；保證V和E的查詢速度

OrientDB

OrientDB是指兼具文件資料庫的靈活性和圖形資料庫管理連結能力的可深層次擴充套件的文件-圖形資料庫管理系統。

優勢：

安裝簡單，功能豐富

OrientDB是兼具文件資料庫的靈活性和圖形資料庫管理連結能力的可深層次擴充套件的文件-圖形資料庫管理系統（NoSQL資料庫）

可選無模式、全模式或混合模式下。支援許多高階特性，諸如ACID事務、快速索引，原生和SQL查詢功能

可以JSON格式匯入、匯出文件

若不執行昂貴的JOIN操作的話，如同關係資料庫可在幾毫秒內可檢索數以百計的連結文件圖

劣勢：

坑很多

效能和可擴充套件性不好

索引：

側重文件資料庫，主要還是SB樹索引導致，空間浪費比較大；插入節點與另外兩個資料庫（neo4j和ArangoDB）相差無幾，但是在插入關係中另外兩個資料庫都做了最佳化，OrientDB無最佳化，就掛了；在圖論計算力上效能優異，但是在遍歷中還是最佳化不夠，被甩開。

JanusGraph

開源 JanusGraph是一個可擴充套件的圖資料庫，可以把包含數千億個頂點和邊的圖儲存在多機叢集上。它支援事務，支援數千使用者實時、併發訪問儲存在其中的圖。

優勢：

分散式部署，因此，支援叢集

可以儲存大圖，比如包含數千億Vertices和edges的圖

支援數千使用者實時、併發訪問。

叢集節點可以線性擴充套件，以支援更大的圖和更多的併發訪問使用者。

資料分散式儲存，並且每一份資料都有多個副本，因此，有更好的計算效能和容錯性。

支援在多個數據中心做高可用，支援熱備份。

透過整合大資料平臺，比如Apache Spark、Apache Giraph、Apache Hadoop等，支援全域性圖資料分析、報表、ETL

整合ElasticSearch、Apache Solr、Apache Lucene等系統後，可以支援全文搜尋

在計算層上可使用Spark做計算，這點優於Neo4j和OrientDB

即可OLAP也可OLTP，可以執行批處理和實時處理

開源，基於Apache 2 Licence

支援各種後端儲存系統，目前標準支援以下四種，當然也可以增加第三方的儲存系統：

Apache Cassandra®

Apache HBase®

Google Cloud Bigtable

Oracle BerkeleyDB

劣勢：

新圖形資料庫

視覺化工具缺乏（可繼承第三方工具Cytoscape、Gephi等）

2。關係型資料庫和圖資料庫的區別

與傳統關係型資料庫相比，圖資料庫的優勢

優秀的查詢效能

相對於關係型資料庫，圖資料庫產品在設計上避免大量的join操作，提供快速的查詢。圖資料庫則天然把關聯資料連線在一起，無需耗時耗記憶體的Join操作，可以保持常數級時間複雜度。

靈活的資料建模和查詢語言，Schema-less

多數圖資料庫沒有預設的schema，藉助底層的儲存機制，能夠更加靈活的變更結構

靈活的圖查詢語言，輕鬆實現複雜關係網路的分析

靈活的資料模型可以適應不斷變化的業務需求

易於理解，更加敏捷

相對於關係型資料庫的二維表格，圖的組織形式更接近於現實世界，易於理解

可以很自然的表達現實世界中的實體及其關聯關係（對應圖的頂點及邊）

關係型資料庫在遍歷關係網路並抽取資訊的能力非常弱，圖資料庫則為此而生

基於圖演算法提供強大分析能力

PageRank/社群發現演算法等

圖資料庫的功能是傳統關係型資料庫的一個拓展，相比較關係型資料庫僅支援表結構，圖資料支援的圖結構更為靈活。圖資料庫在基於圖的資料增加、刪除、查詢、修改等方面做了不同於其他資料庫的設計。在圖資料的操作抽象上，採用基於頂點的視角，比如頂點透過其所有處、邊訪問其鄰接頂點，這一類的操作也是圖資料庫系統設計的核心。

圖資料庫與關係型資料庫優劣比對

優勢

a）使用者可以面向物件的思考，使用者使用的每個查詢都有顯式語義；

b）使用者可以實時更新和查詢圖資料庫；

c）圖資料庫可以靈活應對海量的關係變化，如增加刪除關係、實體等；

d）圖資料庫有利於實時的大資料探勘結果視覺化。

劣勢

a）不適合記錄大量基於事件的資料（例如日誌條目）；

b）二進位制資料儲存。

c）併發效能要求高的專案。

d）目前相關圖查詢語言比較多，尚未有很好統一。

e）圖資料庫相關的一些書籍文件偏少，相關生態還在不斷完善。

圖資料庫在處理關聯關係上具有完全的優勢，但是在一些場景下，圖資料庫並不能完全代替關係型資料庫。

圖資料庫在處理關聯資料時三個技術優勢

1、效能方面：

隨著資料量的增多和關聯深度的增加，傳統關係型資料庫受制於檢索時需要多個表之間連線操作，資料寫入時也需考慮外來鍵約束，從而導致較大的額外開銷，產生嚴重的效能問題。而圖模型固有的資料索引結構，使得它的資料查詢與分析速度更快。在關聯關係的處理上，用關係型資料庫處理不可避免要用到表的JOIN操作，對效能的影響較大；而圖資料庫則是類指標直接跳轉訪問，更高效的操作關聯資料，比關係型資料庫有2到4個數量級的效能提升。

2、靈活度方面：

圖資料庫有非常靈活的資料模型，使用者可以根據業務變化隨時調整資料模型，比如任意新增或刪除頂點、邊，擴充或者縮小圖模型這些都可以輕鬆實現，這種頻繁的 Schema 更改在關係型資料庫上不能到很好的支援。現實中，專案的程序往往是不斷演進的。資料的內容甚至資料格式也會不斷髮生變化。在關係型資料庫中，這意味著表結構的變化，或者多個新表的建立，對源資料的改動非常大。而在圖資料庫裡，僅需新增新的頂點、邊、屬性，設定為對應的型別即可。從本質上說，一個表代表一個型別的資料，一個頂點代表一個特定的資料，意味著關係資料庫更關注資料的型別，而圖資料庫更關注資料的個體，識別其關聯關係。

3、敏捷度方面：

圖資料庫的圖模型非常直觀，支援測試驅動開發模式，每次構建時可進行功能測試和效能測試，符合當今最流行的敏捷開發需求，對於提高生產和交付效率也有一定幫助。使用圖（或者網）的方式來表達現實世界的關係更加直接、自然，在萬物互聯的物聯網時代尤為突出。如果採用關係型資料，先將人物建表，再將關係建表，最後將資料進行對映，需要高度的抽象思維。在圖資料上進行分析查詢時，也可以直觀地透過點邊連線的拓撲，互動式找到想要的資料，不需要具備任何的專業知識。

傳統關係資料庫的效能問題

效能問題的本質在於資料分析面臨的資料量，假如只查詢幾十個節點或者更少的內容，這種操作是完全不需要考慮資料庫效能最佳化的，但當節點資料從幾百個變成幾百萬個甚至幾千萬個後，資料庫效能就成為了整個產品設計的過程中最需考慮的因素之一。

在資料量這麼大的場景中，使用傳統 SQL 會產生很大的效能問題，原因主要有兩個：

1、大量 JOIN 操作帶來的開銷：

之前的查詢語句使用了大量的 JOIN 操作來找到需要的結果。而大量的 JOIN 操作在資料量很大時會有巨大的效能損失，因為資料本身是被存放在指定的地方，查詢本身只需要用到部分資料，但是 JOIN 操作本身會遍歷整個資料庫，這樣就會導致查詢效率低到讓人無法接受。

2、反向查詢帶來的開銷：

查詢單個經理的下屬不需要多少開銷，但是如果我們要去反向查詢一個員工的老闆，使用表結構，開銷就會變得非常大。表結構設計得不合理，會對後續的分析、推薦系統產生效能上的影響。比如，當關系從_老闆 -> 員工變成 _使用者 -> 產品，如果不支援反向查詢，推薦系統的實時性就會大打折扣，進而帶來經濟損失。

圖資料庫和關係型資料庫效能比較

如圖所見，傳統關係型資料庫可以非常好地處理深度為2和3的查詢。join操作在關係型資料庫世界中很常見，大多數資料庫都是如此設計，在某些特定列上使用索引相關也能幫助最大化join操作的效能。然而，當深度達到4和5時，您會看到效能顯著下降：一個涉及4個join的查詢需要10秒以上才能完成，而在深度為5時更花了太長時間，超過一分半鐘，雖然計數結果沒有改變。這恰恰說明了在對圖結構資料建模時關係型資料庫的侷限性：深度圖遍歷需要多個join操作，關係資料庫通常並不擅長這種處理。

但是圖資料庫，可以看見，除了最簡單的查詢，圖資料庫在其他查詢的效能表現上都是明顯更好的那一個。只有在尋找朋友的朋友時（深度為2），關係型資料庫效能可與圖資料庫遍歷的效能相媲美。在深度為3時的遍歷比關係型資料庫快4倍。在深度為4，結果則要好五個數量級。深度為5時，圖資料庫結果的速度甚至要比關係型資料庫要快1000萬倍。關係型資料庫查詢效能下降如此之快正是由於，join操作需要對全部資料進行笛卡爾積運算，其中大部分的資料我們並不需要。

3。探索圖資料庫在資料資產視覺化中的應用

當前這種任務擴充套件方式僅僅只是給開發人員提供了便利，但是使用者仍然很難擴充套件自己的任務，因此後續會考慮將任務擴充套件的能力做成平臺功能的一部分提供給使用者使用。

我們以Apache Atlas為例，探索圖資料庫在資料資產視覺化方面的應用。

Apache Atlas是Hadoop的資料治理和元資料框架。是一組可擴充套件和可擴充套件的核心基礎治理服務，使企業能夠有效，高效地滿足Hadoop中的合規性要求，並允許與整個企業資料生態系統整合。

Apache Atlas為組織提供了開放的元資料管理和治理功能，以建立其資料資產的目錄，對這些資產進行分類和治理，併為資料科學家，分析師和資料治理團隊提供圍繞這些資料資產的協作功能。

此圖為Atlas的架構圖，主要包含的元件如圖所示，我們主要關注於在Core元件中使用JanusGraph圖資料庫來儲存元資料物件。Atlas採用了分散式圖資料庫JanusGraph作為資料儲存，目的在於用有向圖靈活的儲存、查詢資料血緣關係。預設情況下元資料儲存配置為 HBase ，索引儲存配置為 Solr。也可以透過構建相應的配置檔案使用BerkeleyDB儲存元資料儲存和使用ElasticSearch儲存 Index。元資料儲存用於儲存元資料物件本身，索引儲存用於儲存元資料屬性的索引，其允許高效搜尋。

Atlas定義了一套atlas-graphdb-api，允許採用不同的圖資料庫引擎來實現api，便於切換底層儲存。所以Atlas讀寫資料的過程可以看作就是將圖資料庫物件對映成Java類的過程，基本流程如下：

在Atlas中查詢某一個元資料物件時往往需要遍歷圖資料庫中的多個頂點與邊，相比關係型資料庫直接查詢一行資料要複雜的多，當然使用圖資料庫作為底層儲存也存在它的優勢，比如可以支援複雜的資料型別和更好的支援血緣資料的讀寫。

JanusGraph與應用的整合，有如下兩種方式：

第一種：可以把JanusGraph嵌入到應用程式中去，JanusGraph和應用程式處在同一個JVM中。應用程式中的客戶程式碼（相對JanusGraph來說是客戶）直接呼叫Gremlin去查詢JanusGraph中儲存的圖，這種情況下外部儲存系統可以是本地的，也可以處在遠端。

第二種：應用程式和Janus Graph處在兩個不同JVM中，應用透過給JanusGraph提交Gremlin查詢給GremlinServer，來使用JanusGraph，因為JanusGraph原生是支援Gremlin Server的。（Gremlin Server是Apache Tinkerpop中的一個元件）。

下面就展示實際基於JanusGraph圖資料庫的視覺化展現情況：

基於以JanusGraph圖資料庫為例，結合Atlas獲取hadoop生態系統的元資料思路，未來資料資產視覺化擴充套件對大資料的採集能力，以kafka作為訊息系統，解耦生產者和消費者，圖資料庫作為資料處理核心，以Hbase、solr，es，zookeper等技術作為輔助手段。為資料儲存，關係建立，資料血緣建立，資料快速查詢提供便利。

寫在最後

基於對圖資料庫知識的探索，圖資料庫在未來資料資產視覺化中的應用將會是促進資料價值提升，提高企業資料資產配置效率的有效手段，企業可以透過圖資料庫建立企業資料資產全景圖，快速搜尋定位，形成有效的資料交匯，以個性化展現企業的資料資產，方便使用者獲取關鍵資訊，更好的瞭解資料資產的各個方面。

以上是我分享的內容以及一些不成熟的思考，希望跟大家一起探討。

精選提問：

問1：圖資料庫增刪改查有特定語法嗎？

答：根據不同型別的圖資料，所支援的語法也是不一樣的。

問2：看到上面列舉了四種圖資料庫的比較，在實際使用中，傾向於用哪個產品？為什麼？

答：每個圖資料庫都有不同的優點和缺點，需要看產品的需求，注重哪方面的，比如說更關注於效能，更專注於擴充套件性等。

問3：有些公司欄位依賴是自己解析sql實現的，但是我還沒具體思路。。。老師能提示下嗎？

答：目前是透過sql解析器對sql指令碼做解析，例如sqlparser，比如說解析儲存過程，perl指令碼什麼的。

問4：mongodb支援圖資料庫嗎？圖資料庫的應用場景在哪裡？

答：mongodb屬於nosql資料庫的一種，和圖資料是不一樣的。圖資料庫的應用場景有很多，比如最典型的知識圖譜，在資料資產管理中，我認為更多的應用資料資產視覺化展現，以及資料地圖，資料影響/血緣分析等。