在當(dāng)前大數(shù)據(jù)行業(yè)中，?隨著算法的升級(jí)，?特別是機(jī)器學(xué)習(xí)的加入，“找規(guī)律”式的算法所帶來(lái)的“紅利”正在逐漸地消失，進(jìn)而需要一種可以對(duì)數(shù)據(jù)進(jìn)行更深一層挖掘的方式，這種新的方式就是知識(shí)圖譜。

下面我們來(lái)聊一下知識(shí)圖譜以及知識(shí)圖譜在達(dá)觀數(shù)據(jù)中的實(shí)踐。

知識(shí)圖譜（Knowledge Graph）是一種用點(diǎn)來(lái)代替實(shí)體，用邊代替實(shí)體之間關(guān)系的一種語(yǔ)義網(wǎng)絡(luò)。通俗來(lái)說(shuō)，知識(shí)圖譜就是把所有不同種類(lèi)的信息（Heterogeneous Information）連接在一起而得到的一個(gè)關(guān)系網(wǎng)絡(luò)，它提供了站在關(guān)系的角度去分析問(wèn)題的視角。站在這個(gè)角度我們可以從“找規(guī)律”的維度上升到“理解”的維度，?這也就是為什么有人說(shuō)知識(shí)圖譜是?AI 的未來(lái)。

“達(dá)觀數(shù)據(jù)是一家人工智能公司”這句話在機(jī)器看來(lái)只不過(guò)是一連串的字符，?但是在我們?nèi)丝磥?lái)卻可以分成主謂賓三部分，即主語(yǔ)“達(dá)觀數(shù)據(jù)”謂語(yǔ)“是”賓語(yǔ)“人工智能公司”。?那么有沒(méi)有一種數(shù)據(jù)的組織形式讓機(jī)器看到這句話時(shí)不再是一個(gè)字符串，?而是一個(gè)具有類(lèi)似主謂賓可以“理解”的結(jié)構(gòu)呢？當(dāng)然，這就是知識(shí)圖譜要干的事情。

知識(shí)圖譜可以表示成一個(gè)實(shí)體關(guān)系網(wǎng)絡(luò)圖，實(shí)體是包含信息的個(gè)體，畫(huà)出來(lái)叫節(jié)點(diǎn)；關(guān)系是兩個(gè)實(shí)體間的聯(lián)系，畫(huà)出來(lái)叫邊。借用上面的例子“達(dá)觀數(shù)據(jù)是一家人工智能公司”，“達(dá)觀數(shù)據(jù)”和“人工智能公司”是兩個(gè)實(shí)體，“是”即這兩個(gè)實(shí)體之間的關(guān)系。

圖 1 知識(shí)圖譜表示實(shí)體關(guān)系網(wǎng)絡(luò)圖

知道了什么是知識(shí)圖譜，那么知識(shí)圖譜有什么用處呢？這里我舉兩個(gè)例子：知識(shí)圖譜在搜索引擎中的作用以及在銀行風(fēng)控系統(tǒng)中的應(yīng)用。

有時(shí)候我們?cè)谑褂盟阉饕鏁r(shí)，?我們的搜索詞（Query）往往看起來(lái)更像是一個(gè)問(wèn)題，比如“張三是從哪里畢業(yè)的”，這時(shí)我們需要搜索引擎直接給出我想要的結(jié)果，而不是一個(gè)網(wǎng)頁(yè)排名(page rank) 。比如我在?google 中搜索“扎克伯格的妻子是誰(shuí)”，?我需要是扎克伯格的妻子普莉希拉?陳的詳細(xì)信息而不是一些包含了她信息的網(wǎng)頁(yè)。我們先看下?google 的結(jié)果：

圖 2?google 中搜索“扎克伯格的妻子是誰(shuí)”

那么Google是怎么做到的呢？其實(shí)早在2012年Google 就已經(jīng)在搜索中加入了知識(shí)圖譜，用戶可以通過(guò)Google 構(gòu)建的知識(shí)圖譜直接查詢(xún)到結(jié)果，這種方式極大地提升了用戶體驗(yàn)。然而對(duì)于?Google 來(lái)說(shuō)處理起來(lái)也比較便捷，首先將“扎克伯格的妻子是誰(shuí)” 這個(gè)?Query通過(guò)自然語(yǔ)言處理技術(shù)（NLP）處理成“扎克伯格”實(shí)體和”has_wife” 的關(guān)系，從已經(jīng)構(gòu)建好的知識(shí)圖譜中查詢(xún)，?然后將查詢(xún)結(jié)果返回給用戶。

然而就是這樣的一個(gè)改動(dòng)，從用戶使用的角度來(lái)看已經(jīng)從普通的搜索引擎變成了智能問(wèn)答的系統(tǒng)，用戶體驗(yàn)上升了一個(gè)層次。

馬克斯·韋伯曾說(shuō)“人是懸掛在自我編織的意義之網(wǎng)上的動(dòng)物”，這句話從側(cè)面說(shuō)明人與人之間的關(guān)系是很復(fù)雜的，我們是否可以將復(fù)雜的人際關(guān)系進(jìn)行一次挖掘呢？

首先人際關(guān)系實(shí)際形如一張網(wǎng)，?既然是網(wǎng)那么它一定具有一個(gè)特性，即網(wǎng)上兩個(gè)相鄰節(jié)點(diǎn)之間的路徑損壞，并不一定影響整張網(wǎng)。比如?一張網(wǎng)（無(wú)向圖）中相鄰的?A 節(jié)點(diǎn)到?B 節(jié)點(diǎn)的路徑“壞了”，?有極大可能找到另一條從?A 到?B 的路徑，而不影響整張網(wǎng)。那么網(wǎng)的這個(gè)特性應(yīng)該怎樣應(yīng)用到數(shù)據(jù)挖掘上來(lái)呢？我們來(lái)看一個(gè)知識(shí)圖譜在銀行風(fēng)控系統(tǒng)中的例子

圖 3?知識(shí)圖譜在銀行風(fēng)控系統(tǒng)中的應(yīng)用

我們可以根據(jù)借款人借款時(shí)填寫(xiě)的關(guān)系構(gòu)建知識(shí)圖譜， 如圖借款人跟張三是朋友關(guān)系，跟李四是父子關(guān)系。當(dāng)我們?cè)噲D把借款人的信息添加到知識(shí)圖譜里的時(shí)候，“一致性驗(yàn)證”引擎會(huì)觸發(fā)。引擎首先會(huì)去讀取張三和李四的關(guān)系，從而去驗(yàn)證這個(gè)“三角關(guān)系”是否正確。很顯然，朋友的朋友不是父子關(guān)系，所以存在著明顯的風(fēng)險(xiǎn)。這里的隱含關(guān)系挖掘可以借用通用的關(guān)系挖掘引擎，也可以自己實(shí)現(xiàn)隱含關(guān)系的挖掘引擎。通用關(guān)聯(lián)關(guān)系的挖掘由于其通用性，通常難以保證對(duì)關(guān)系挖掘的正確性，通常是自己配置規(guī)則來(lái)確保關(guān)系挖掘的準(zhǔn)確性。對(duì)隱含關(guān)系的挖掘技術(shù)目前是知識(shí)圖譜研究的前沿方向， 如果有興趣，可以查閱相關(guān)論文。

知識(shí)圖譜在銀行風(fēng)控中的作用還有很多，比如對(duì)失聯(lián)借款人兩度，甚至多度的關(guān)系挖掘來(lái)找到借款人等。 由此可見(jiàn)在“關(guān)系”越復(fù)雜的情況下，知識(shí)圖譜越是能發(fā)揮它的作用。

知識(shí)圖譜還有很多其他應(yīng)用場(chǎng)景，這里就不一一列舉了，如果您感興趣的話，參見(jiàn)《知識(shí)圖譜的應(yīng)用》。

既然知識(shí)圖譜這么有用，那么怎樣才能構(gòu)建自己的知識(shí)圖譜，怎樣將傳統(tǒng)的數(shù)據(jù)轉(zhuǎn)化成知識(shí)圖譜呢？

傳統(tǒng)數(shù)據(jù)主要分成兩種，格式化數(shù)據(jù)和非格式化數(shù)據(jù)。格式化數(shù)據(jù)轉(zhuǎn)化成知識(shí)圖譜時(shí)需要將格式化的數(shù)據(jù)映射成實(shí)體關(guān)系組，從而構(gòu)建知識(shí)圖譜。而非格式化的數(shù)據(jù)轉(zhuǎn)化時(shí)比較復(fù)雜，通常采用算法抽取和程序抽取兩種方式。

通過(guò)自然語(yǔ)言處理（NLP）技術(shù)對(duì)文本進(jìn)行命名實(shí)體識(shí)別（NER），從非格式化的文本中識(shí)別出專(zhuān)有名詞和有意義的短語(yǔ)并進(jìn)行分類(lèi)。比如上例中從“達(dá)觀數(shù)據(jù)是一家人工智能公司”這段文本中識(shí)別出”達(dá)觀數(shù)據(jù)”和“人工智能公司”這兩個(gè)實(shí)體以及“是”這個(gè)從屬關(guān)系，這樣我們就可以通過(guò)”達(dá)觀數(shù)據(jù)” “是” “人工智能公司” 這個(gè)實(shí)體組來(lái)構(gòu)建知識(shí)圖譜。由于目前NER識(shí)別技術(shù)還不夠成熟，通常我們會(huì)對(duì)NER 識(shí)別的實(shí)體進(jìn)行人工矯正，確保所識(shí)別實(shí)體的準(zhǔn)確性。

在處理實(shí)體識(shí)別非格式化數(shù)據(jù)的過(guò)程中我們經(jīng)常會(huì)碰到半格式化的數(shù)據(jù)，比如一段簡(jiǎn)歷的文本，文本中經(jīng)常會(huì)包含，姓名：XXX，公司名：XXX 等格式，遇到這樣的半格式化文本，我們也可以采用正則等方式來(lái)抽取，確保知識(shí)圖譜構(gòu)建的完整性和準(zhǔn)確性。

知識(shí)圖譜是基于圖的數(shù)據(jù)結(jié)構(gòu)，通常用圖數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)，我們先來(lái)看一下圖數(shù)據(jù)庫(kù)排行（部分）。

圖 4?知識(shí)圖譜的存儲(chǔ)以及neo4j 的性能測(cè)試

通過(guò)排行榜可以看出?Neo4j 數(shù)據(jù)庫(kù)遙遙領(lǐng)先，實(shí)際上neo4j 已經(jīng)是當(dāng)前業(yè)界分析知識(shí)圖譜的主流數(shù)據(jù)庫(kù)。那么怎樣將?neo4j 圖數(shù)據(jù)庫(kù)應(yīng)用到項(xiàng)目中去，以及怎樣優(yōu)化?neo4j 圖數(shù)據(jù)庫(kù)呢？首先我們來(lái)看一下?neo4j 的性能表現(xiàn)：

測(cè)試內(nèi)容：?節(jié)點(diǎn)數(shù)分別在1萬(wàn)，?10萬(wàn)，?100萬(wàn)，1000萬(wàn)情況下，在節(jié)點(diǎn)設(shè)置索引和不設(shè)置索引的情況下查找節(jié)點(diǎn)的平均延時(shí)。測(cè)試結(jié)果如下:

圖 5 查找節(jié)點(diǎn)平均延時(shí)的測(cè)試結(jié)果

通過(guò)上面的測(cè)試可以看出，當(dāng)節(jié)點(diǎn)（Node）的數(shù)量超過(guò)1000萬(wàn)時(shí)，在不設(shè)置索引的情況下，平均查詢(xún)延時(shí)已經(jīng)超過(guò)了6秒，說(shuō)明此時(shí)?neo4j 已經(jīng)明顯“吃不消”了，顯然這樣的延時(shí)這在實(shí)際的項(xiàng)目應(yīng)用中是完全不可接受的。但是我們發(fā)現(xiàn)設(shè)置索引之后查詢(xún)時(shí)間明顯降下來(lái)了，那么是不是設(shè)置的索引越多越好呢？我們看下在1000萬(wàn)節(jié)點(diǎn)的情況下有索引和無(wú)索引插入延時(shí)測(cè)試：

圖 6 1000萬(wàn)節(jié)點(diǎn)情況下有索引和無(wú)索引的插入測(cè)試結(jié)果

由上圖測(cè)試結(jié)果可以看出：?在千萬(wàn)級(jí)數(shù)據(jù)的情況下有索引插入比無(wú)索引插入要慢30%，?所以索引并不是越多越好，?那么除此之外?neo4j 還有哪些地方可以?xún)?yōu)化呢？

neo4j 不使用schema，所以從理論上來(lái)說(shuō)?neo4j 可以存儲(chǔ)任何形式的數(shù)據(jù)。但由于neo4j 是通過(guò)鍵值對(duì)（Key-Value）?的雙向列表來(lái)保存節(jié)點(diǎn)和關(guān)系的屬性值，所以neo4j僅適用于存儲(chǔ)實(shí)體關(guān)系和實(shí)體簡(jiǎn)單的屬性。在實(shí)際應(yīng)用中一個(gè)實(shí)體通常會(huì)包含眾多的屬性，如果將這些屬性全部存儲(chǔ)到?neo4j 中，neo4j 的查詢(xún)將變得異常的慢，?而在實(shí)際的應(yīng)用場(chǎng)景下，經(jīng)常會(huì)遇到高并發(fā)的情況。這時(shí)候單節(jié)點(diǎn)的?neo4j 就會(huì)顯得力不從心。那么在項(xiàng)目實(shí)戰(zhàn)中怎樣更好的利用?neo4j 來(lái)抵御高并發(fā)呢？

neo4j HA（High Availability）即neo4j 的高可用特性，不過(guò)這個(gè)特征只能在neo4j 企業(yè)版中可用。neo4j HA使用多臺(tái)neo4j從數(shù)據(jù)庫(kù)設(shè)置替代單臺(tái)neo4j主數(shù)據(jù)庫(kù)的容錯(cuò)架構(gòu)，這種架構(gòu)可以在一臺(tái)實(shí)體機(jī)故障的情況下使數(shù)據(jù)庫(kù)具備完善讀寫(xiě)操作的能力，由于?neo4j HA 采用主從數(shù)據(jù)同步，?而且寫(xiě)操作也可以在從庫(kù)中執(zhí)行（經(jīng)測(cè)試這種方式不如主節(jié)點(diǎn)寫(xiě)入可靠）因此采用neo4j HA 比單臺(tái)neo4j數(shù)據(jù)庫(kù)擁有更多的讀取負(fù)載處理能力。

如果你使用的不是?neo4j 企業(yè)版，那么你可能需要自己動(dòng)手來(lái)構(gòu)建?neo4j 集群以此來(lái)實(shí)現(xiàn)高可用架構(gòu)了。當(dāng)然你可以采用Neo4j+DRBD（Distributed Replicated Block Device）+?Keepalived?方式來(lái)構(gòu)建自己的neo4j 集群，?通過(guò)?DRBD 來(lái)備份單點(diǎn)上的?neo4j 圖庫(kù)數(shù)據(jù)，通過(guò)Keepalived?來(lái)管理你的集群。除此之外你還可以通過(guò)?zookeeper 來(lái)管理你的集群節(jié)點(diǎn)，自己實(shí)現(xiàn)將主節(jié)點(diǎn)數(shù)據(jù)修改的Cypher 語(yǔ)句元操作同步到從節(jié)點(diǎn)（類(lèi)似?MySQL 的binlog）來(lái)實(shí)現(xiàn)主從同步，從而達(dá)到讀寫(xiě)分離。當(dāng)然不管你采用方式一還是方式二，都會(huì)增大開(kāi)發(fā)和維護(hù)成本。

應(yīng)用緩存：在實(shí)際應(yīng)用的過(guò)程中讀寫(xiě)圖庫(kù)時(shí)經(jīng)常會(huì)遇到查詢(xún)一些不常修改的數(shù)據(jù)，?比如需要頻繁查詢(xún)用戶所屬的國(guó)家信息，而國(guó)家的屬性更改的頻率比較低，而且用戶的國(guó)籍信息不會(huì)經(jīng)常變動(dòng)，這時(shí)我們可以通過(guò)添加應(yīng)用緩存（如：redis, leveldb等），將查詢(xún)的結(jié)果緩存起來(lái)，減少直接訪問(wèn)圖庫(kù)的頻次，減小圖庫(kù)的讀取壓力。

數(shù)據(jù)庫(kù)緩存：由于neo4j 執(zhí)行一次查詢(xún)操作之后，會(huì)將數(shù)據(jù)緩存到內(nèi)存中，執(zhí)行相同的查詢(xún)操作?neo4j 直接返回內(nèi)存中緩存的數(shù)據(jù)結(jié)果。如果是執(zhí)行隨機(jī)查詢(xún)，則后一次結(jié)果會(huì)覆蓋前一次的查詢(xún)數(shù)據(jù)，內(nèi)存緩存的配置可以通過(guò)修改配置文件中dbms.query_cache_size參數(shù)進(jìn)行調(diào)整。所以說(shuō)執(zhí)行語(yǔ)句時(shí)盡可能的利用已有數(shù)據(jù)的緩存，減少?Cache-Miss 情況的發(fā)生。

查詢(xún)優(yōu)化：由于?neo4j 會(huì)將查詢(xún)結(jié)果緩存到內(nèi)存中，所以不需要的查詢(xún)結(jié)果盡量不要放到內(nèi)存，比如?下面的cypher 語(yǔ)句：

語(yǔ)句1比語(yǔ)句2 更好，因?yàn)楹笳邥?huì)將所有的節(jié)點(diǎn)和關(guān)系的屬性加載到內(nèi)存，然后計(jì)算?count 值，而前者只會(huì)將必要的屬性加載到內(nèi)存求count值。

索引優(yōu)化：我們知道數(shù)據(jù)庫(kù)索引實(shí)際上是在數(shù)據(jù)之外維護(hù)了特定算法的數(shù)據(jù)結(jié)構(gòu)(如?B+Tree)，比如圖7為了加快?Col2的查詢(xún)構(gòu)建一個(gè)二叉樹(shù)，使原來(lái)的“順序”查找，變成“二分查找”，從而將查詢(xún)復(fù)雜度降低為?o(logn)，而且索引還會(huì)利用訪問(wèn)局部性原理，充分利用操作系統(tǒng)的頁(yè)緩存，加快查找的速度。

圖 7 數(shù)據(jù)庫(kù)索引原理介紹

由于增加索引會(huì)讓圖庫(kù)維護(hù)在維護(hù)數(shù)據(jù)的同時(shí)還會(huì)維護(hù)一份額外的數(shù)據(jù)結(jié)構(gòu)，更新數(shù)據(jù)時(shí)會(huì)造成額外的開(kāi)銷(xiāo)，這也印證了上面測(cè)試的插入數(shù)據(jù)時(shí)無(wú)索引比有索引快的結(jié)論。

Neo4j 1.4以后的版本引入了自動(dòng)索引（automatic index），可以在config/neo4j.properties中配置自動(dòng)創(chuàng)建索引，也可以通過(guò)語(yǔ)句CREATE INDEX ON :Label(PropertyName)手動(dòng)創(chuàng)建索引，從而提高查詢(xún)的效率。

由于?neo4j 的節(jié)點(diǎn)和關(guān)系的屬性是通過(guò)Key-Value 的雙向列表來(lái)保存的，所以這種數(shù)據(jù)結(jié)決定了?neo4j 中存儲(chǔ)的節(jié)點(diǎn)不能包含太多的屬性值。但是在實(shí)際應(yīng)用中經(jīng)常會(huì)碰到一些實(shí)體擁有大量的屬性，必要時(shí)還需要通過(guò)這些屬性的值來(lái)查詢(xún)實(shí)體進(jìn)而查找實(shí)體擁有的關(guān)系。這時(shí)候可以將?neo4j 數(shù)據(jù)庫(kù)和KV 數(shù)據(jù)庫(kù)（如：MongoDB）進(jìn)行聯(lián)合使用，比如在?neo4j 節(jié)點(diǎn)的屬性中存儲(chǔ)MongoDB 中的?objectId。

這樣既可以充分利用?neo4j 的特性來(lái)進(jìn)行關(guān)系查詢(xún)又可以通過(guò)?KV 數(shù)據(jù)庫(kù)的特性來(lái)進(jìn)行屬性到實(shí)體的查詢(xún)。通常在圖庫(kù)和?KV 數(shù)據(jù)庫(kù)聯(lián)合使用時(shí)，?特別是經(jīng)常需要通過(guò)屬性來(lái)查詢(xún)實(shí)體時(shí)需要設(shè)置?neo4j schema Index，即將neo4j中與?KV 數(shù)據(jù)庫(kù)關(guān)聯(lián)的值設(shè)置索引。

知識(shí)圖譜和Neo4j還有很多有趣的特性，鑒于篇幅這里不再贅述。自Google在2012年推出知識(shí)圖譜技術(shù)以來(lái)，知識(shí)圖譜迎來(lái)了飛速的發(fā)展。由于知識(shí)圖譜在關(guān)系“理解”方面的優(yōu)勢(shì)，目前已經(jīng)在各大互聯(lián)網(wǎng)公司和傳統(tǒng)企業(yè)的項(xiàng)目中落地，并取得了良好的效果。

正是由于知識(shí)圖譜對(duì)數(shù)據(jù)理解和傳統(tǒng)方式不一致，給傳統(tǒng)的數(shù)據(jù)挖掘算法帶來(lái)了挑戰(zhàn)。相信隨著人們對(duì)知識(shí)圖譜的關(guān)注度越來(lái)越高，在知識(shí)圖譜領(lǐng)域?qū)?huì)涌現(xiàn)更多更成熟的構(gòu)建、存儲(chǔ)和挖掘理念，相信在不遠(yuǎn)的將來(lái)知識(shí)圖譜將會(huì)在更廣泛的領(lǐng)域內(nèi)為大家服務(wù)。