知新溫故，從知識圖譜到圖數據庫
說到人工智能技術，首先會聯想到深度學習、機器學習技術;談到人工智能應用，很可能會馬上想起語音助理、自動駕駛等等。實際上，人工智能要在行業中得到應用的先決條件是首先要對行業建立起認知，只有理解了行業和場景，才能真正智能化。簡單的說，就是要建立行業知識圖譜，才能給行業AI方案。
機器通過人工智能技術與用戶的互動，從中獲取數據、優化算法，更重要的是構建和完善知識圖譜，認知和理解世界，進而服務于這個世界。
那什么是知識圖譜呢?
知識圖譜
知識圖譜本質上是語義網絡的知識庫，從實際應用的角度出發其實可以簡單地把知識圖譜理解成多關系圖。
那什么是多關系圖呢? 回憶在數據結構中的“圖”。圖是由節點和邊來構成，通常用來描述某些事物之間的某種特定關系。圖用點代表事物，用連接兩點的邊表示相應兩個事物間具有某種關系，但這些圖通常只包含一種類型的節點和邊，在IOTA,物聯網區塊鏈?一文中就談到了有向無環圖。多關系圖一般包含多種類型的節點和多種類型的邊。 圖的數學基礎是圖論，本身是應用數學的一部分，在往下大概要涉及到拓撲學的領域了。
在知識圖譜里，通常用“實體”來表達圖里的節點、用“關系”來表達圖里的“邊”。實體指的是現實世界中的事物，關系則用來表達不同實體之間的某種聯系，實體和關系也會擁有各自的屬性。知識圖譜的構建是后續應用的基礎，而且構建的前提是需要把數據從不同的數據源中抽取出來。數據抽取的難點在于處理非結構化數據，這回涉及到NLP中的相關技術，例如實體命名識別、關系抽取、實體統一、指代消解等等。
知識圖譜工程本身還是業務為重心，以數據為中心。不要低估業務和數據的重要性。
知識圖譜最重要的核心在于對業務的理解以及對知識圖譜本身的設計。要從業務邏輯出發，并且通過觀察知識圖譜的設計也很容易推測其背后業務的邏輯，而且設計時也要想好未來業務可能的變化。讓知識圖譜盡量輕量化、并決定哪些數據放在知識圖譜，哪些數據不需要放在知識圖譜，在于把知識圖譜設計成小而輕的存儲載體。
知識圖譜主要有兩種存儲方式：RDF和圖數據庫。它們之間的區別如下圖所示。RDF一個重要的設計原則是數據的易發布以及共享，圖數據庫則把重點放在了高效的圖查詢和搜索上。其次，RDF以三元組的方式來存儲數據而且不包含屬性信息，但圖數據庫一般以屬性圖為基本的表示形式，所以實體和關系可以包含屬性，這就意味著更容易表達現實的業務場景。
那為什么要用圖數據庫呢? 核心在于“關系”。
重新認識“關系”
關系是指人與人之間，人與事物之間，事物與事物之間的相互聯系。
不同事物按著各種不同類型的關系而彼此聯系在一起，例如，空間與時間的關系，整體與部分的關系，原因與結果的關系，內容與形式的關系以及遺傳關系、函數相依關系、內部關系與外部關系等等。 數據結構中的關系指的是集合中元素之間的某種相關性。關系的運算包括集合的子，交，并，補等等。
在數學中，相關關系是一種非確定的相互依存關系：
- 按程度：完全相關、不完全相關和不相關
- 按影響： 正相關和負相關
- 按形式：線性相關和非線性相關
- 按變量數目：單相關、復相關和偏相關
- ......
事物之間的關系也是復雜的、無限多樣的。
在現實生活中，每一個實體都和周圍的其他實體有著千絲萬縷的關系，這些關系里面所存儲的信息甚至要大于實體本身的屬性。
但是數據庫有很多，為什么需要圖數據庫呢?關系型數據庫和眾多的NoSQL為什么不能完全擁有知識圖譜的構建呢?
“關系”的數據庫存儲與表達
世界是由關系組成的，關系型數據庫能夠處理好關系嗎?
關系型數據庫
傳統的關系型數據庫更注重刻畫實體內部的屬性，實體與實體之間的關系通常都是利用外鍵來實現，將所有的數據用豎立的堆棧表示，并且保持它們直接的關系，在求解關系的時候通常需要join操作，而join操作通常又是耗時的。常常被優化用于聚合數據，而非高度關聯的數據。
互聯網尤其是移動互聯網的爆發式增長本來就使得傳統關系型數據庫不堪重負，再加上諸如社交網絡等應用對于關系的高需求，關系型數據庫顯得力不從心。
從應用開發的角度上看，不增加關系型數據庫復雜性就不能建模和存儲數據和關系。隨著關系數量和層次的增加，數據庫尺寸的增加，性能降低。當增加新類型的數據和關系的時候，需要重新設計，增加了時間成本，這些導致傳統數據庫不適用于有實時價值的數據關系。
既然這樣，對于高度關聯的數據存儲與分析就需要求助于NoSQL了。
NoSQL
在NoSQL之于大數據一文中將NoSQL分為了4類：key-value，文檔型，列存儲和圖數據庫。
Key-Value模型適合用于簡單的數據或者列表。當數據之間不斷交互關聯時，實際上更需要一張圖。文檔型NoSQL用來管理文檔。在傳統的數據庫中，信息被分割成離散的數據段，而在文檔數據庫中，文檔是處理信息的基本單位。文檔可以很長，可以很復雜，可以是無結構的，與字處理文檔類似。一個文檔相當于關系數據庫中的一條記錄。文檔型NoSQL用文檔進行層次劃分，而自由的數據規劃也很容易被表示成一顆樹。成長為一張圖的話，文檔之間的關聯需要更有代表性的數據結構來存儲，列存儲的NoSQL也是如此。
從應用開發的角度看，這些NoSQL數據庫不處理關系，沒有數據結構建模或存儲數據關系，沒有查詢結構支持些數據關系。而且，在應用中連接數據同樣需要JOIN操作， 對事務沒有 ACID 的支持。
ACID，指數據庫事務正確執行的四個基本要素的縮寫。包含：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)。
因此，這三種 NoSQL 數據庫也不適用于有實時價值的數據關系。
圖數據庫終于登場，它作為重點描述數據之間關系的數據庫應運而生，最適合處理關系，能夠制作從簡單到到復雜的數據結構且互相連接的數據。圖數據庫成為了NoSQL中非常重要的一部分。
圖數據庫
圖數據庫是基于數學里圖論的思想和算法而實現的高效處理復雜關系網絡的數據庫。圖形數據庫善于高效處理大量的、復雜的、互連的、多變的數據，計算效率遠遠高于傳統的關系型數據庫。
圖中每個節點代表一個對象，節點之間的連線代表對象之間的關系。節點可帶標簽，節點和關系都可以帶若干屬性。關系可以將節點組織成任意的結構，允許一張圖被組織成一個列表，一棵樹，一張地圖，或者一個復雜的實體。這個實體本身也是由復雜的，關系高度關聯的結構組成。
以圖數據庫Neo4J為例，用 Cypher 創建節點和關系的示意如下：
- CREATE (:Person { Name:“Abel Cao”} )-[:Love]-> (:Person { Name:“Andy Cao”} )
查詢也很簡單：
- MATCH (:Person { Name:“Abel Cao”} ) -[:Love]-> (:Person { Name:“Andy Cao”} )
一個節點可以從單屬性開始，成長為成千上億，雖然會有一點點麻煩。從某種意義上講，將數據用關系連接起來分布到不同節點上才是有意義的。對于通過某一給定的屬性值來找到節點或者關系，對比遍歷圖查找，用索引將會更加高效。
用圖來存儲數據，是最接近高性能的一種用于存儲數據的數據結構方式之一。圖數據庫也有很多，常用且比較聞名的應該是Neo4j了。
圖數據庫中的Neo4j
圖數據庫中的 Neo4j 是專為數據關系而生的，模型維護容易，白板模型即物理模型，查詢也較簡單，表映射關系變成了圖關系,使用較少的資源就可以獲得較高的性能。
用圖來表示社交網絡中人與人的關系
實際上，Neo4j最適合一個完整的企業部署或者用于一個輕量級項目中服務器的一個子集，有以下幾個顯著特特性:
ACID支持
ACID操作是保證數據一致性的基礎。Neo4j確保了在一個事務里面的多個操作同時發生，保證數據一致性。不管是采用嵌入模式還是多服務器集群部署，都支持這一特性。
高可用性
圖存儲可以非常輕松的集成到任何一個應用中。隨著應用在運營中的不斷發展，性能問題肯定會逐步凸顯出來，而Neo4j不管應用如何變化，只會受到計算機硬件性能的影響，而不受業務本身的約束。
輕松擴展
可以擴展到上億級別的節點和關系，部署一個neo4j服務器便可以承載上億級的節點和關系。當單節點無法承載數據需求時，可以進行分布式集群部署。通常來講，對于10億節點以下規模的圖譜來說Neo4j已經足夠了。
高速檢索
通過Neo4j提供的遍歷工具，可以非常高效的進行數據檢索，每秒可以達到上億級的檢索量。
Neo4j的用戶包括電子港灣、必能寶、沃爾瑪、德國漢莎航空公司、思科、惠普、埃森哲等很多知名企業。
Neo4j編程概要
Neo4j是是一個嵌入式的、基于磁盤的、具備完全的事務特性的Java持久化引擎。主要有三種訪問Neo4j數據庫的方式：
嵌入式
通過指定數據庫地址直接訪問數據庫。
- new GraphDatabaseFactory().newEmbeddedDatabase(DB_PATH);
REST API
通過請求API訪問數據庫。
- curl -D - -H Accept:application/json "http://neo4j:123456@localhost:8474/db/data/"
JDBC
通過Java API的方式訪問數據庫。
- DriverManager.getConnection("jdbc:neo4j:123456//localhost:8474/");
人生苦短，我用Python
應用Python完成基于Neo4j的應用，需要從http://py2neo.org/v3/安裝py2neo:
- 連接Neo4j
- mygraph = Graph(host='localhost', http_port=8474, https_port=8473, bolt_port=8687, username='Abel_Cao', password='xxxxxx')
- 創建節點和關系
- abel = Node('Person', name='Abel')
- zmx = Node('Person', name='Zmx')
- abel_love_zmx = Relationship(abel, 'Love', zmx)
- graph.create(abel_love_zmx)
- 修改屬性
- abel.properties['age'] = 47
- andy.properties['age'] = 17
- abel.push()
- andy.push()
- 查找節點或關系
- abel = graph.find_one(label='Person', property_key='name', property_value='Abel')
- zmx = graph.find_one(label='Person', property_key='name', property_value=’Zmx')
- abel_love_zmx= graph.match_one(start_node=abel, rel_type='Love’, end_node=zmx)
- 刪除節點、關系
- graph.delete(alice_knows_bob)
- graph.delete(alice)
- graph.delete(bob)
自定義查詢
- cursor = graph.run(Cipher_statement)
Cipher 簡要
簡單的類比一下，可以把Cipher查詢語言理解為SQL語句。
- 刪除節點、關系
- MATCH (abel:`Person` {name:"Abel"})-[abel_love_andy:`Love`]->(
- 查找路徑
- MATCH p=(abel:`Person` {name:"Abel"})-[]->(andy:`Person` {name:"Andy"}) DELETE p;
- 查找最短路徑
- MATCH p=shortestPath((abel:`Person` {name:"Abel"})-[*..5]->(zmx:`Person` {name:"Zmx"})) DELETE p;
Cipher中的其他操作指令包括：
- 刪除標簽和屬性 REMOVE
- 遍歷節點 FOREACH
- 過濾條件 WHERE
- 使用索引 START
- 排序 ORDER BY
- 分頁 LIMIT SKIP
- 索引 INDEX
- 唯一性約束 UNIQUE
- 聚合函數 COUNT SUM AVG DISTINCT 等等
在Neo4j的集群部署中，一般使用zookeeper來負責neo4j server的心跳檢測。
需要注意的是，在 zookeeper master選舉期間，write請求不可處理，會直接返回異常，最好在客戶端提供一種故障切換的重試機制進行控制。
各種的圖數據庫
在db-engines.com上，可以看到圖數據庫的市場排名。
市場有著較大的變化，曾經的記憶好像是這樣的：
- AWS使用titan，分布式圖形數據庫。
- titan不是數據庫，而是客戶端庫，依賴于下面的存儲引擎，例如Cassandra或者Hadoop，也依賴于索引引擎，比如Lucene、ElasticSearch或Solr，來執行相關的查詢。
- arangoDB支持靈活的數據模型，比如文檔Document、圖Graph以及鍵值對Key-Value存儲。
- OrientDB的主要特點是支持多模型對象，支持不同的模型，如文檔，圖形，鍵/值和真實對象。
- GUN是一個實時的、分布式的、嵌入式圖形數據庫引擎。
曾經關注的幾種圖數據庫部分屬性對比：
由于Neo4j沒有緩存層，將無法支持讀取QPS量，也不能滿足分布式巨量數據存儲的需要。許多大廠都有著自己圖數據庫，例如百度就開源了他的HugeGraph，可以存儲海量的節點對象和復雜的關系。
圖數據庫的應用
對于在數據捕獲設計之后，追求數據驅動運營和決策的組織而言，圖分析可能是最有效的競爭優勢.因此，圖形數據庫在社交網絡、征信系統等諸多領域有著廣泛的應用，例如：
- 實時推薦
- 主數據管理：組織架構，社交網絡，產品訂購，IT網絡
- 欺詐檢測，合成身份詐騙環
- 基于圖的搜索
- IT網絡管理
- 身份和訪問管理
- 地理信息系統
其中重要的是，圖數據庫能夠將大數據洞察付諸于行動，是構建知識圖譜的基石之一，在人工智能極其應用中有著重要的一席之地。
參考資料
https://neo4j.com/developer
https://www.jiqizhixin.com/articles/2018-06-20-4
https://db-engines.com/
Ian，Robinson、Jim，Webber、Emil，Eifrem 著，劉璐，梁越 譯 《圖數據庫(第二版)》，人民郵電出版社，2016
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
