傳統(tǒng)的關(guān)系型數(shù)據(jù)庫通過實體和關(guān)系來建模，在過去的很長一段時間內(nèi)都占據(jù)著絕對的統(tǒng)治地位。但是隨著大數(shù)據(jù)的興起，它的一些缺陷也變得越來越明顯，特別是在需要處理非常復(fù)雜的實體關(guān)系時，關(guān)系型數(shù)據(jù)庫變得越來越力不從心。

當我們要表示實體間的多對多關(guān)系時，一般會建立關(guān)系表。當要看實體間的關(guān)系時，我們需要把這種關(guān)系再關(guān)聯(lián)起來。這通常是一項非常消耗性能的工作，特別是在關(guān)系非常復(fù)雜或者關(guān)系層次很多的情況下，需要關(guān)聯(lián)非常多的表，甚至產(chǎn)生非常巨大的中間結(jié)果，導(dǎo)致查詢非常緩慢甚至跑不出來。

圖數(shù)據(jù)庫以圖論為基礎(chǔ)，數(shù)據(jù)本身以圖的方式存儲(比如鄰接表)，在處理與圖相關(guān)的任務(wù)時占有先天的優(yōu)勢。所以目前在知識圖譜，社交網(wǎng)絡(luò)分析等領(lǐng)域開始有越來越多的應(yīng)用。

常見的圖形數(shù)據(jù)庫

以下是三個比較流行的圖數(shù)據(jù)庫及各自的特性對比。

經(jīng)過我們對比及試用的結(jié)果，OrientDB 和 Neo4j 使用比 Titan 都要簡單，社區(qū)也更活躍。但是 Neo4j 最大的缺陷在于并非是真正的分布式，當數(shù)據(jù)量超過單機的承載能力以后很難處理；而且 Neo4j 和OrientDB 的底層存儲都是自主研發(fā)，Titan 支持HBase/Cassandra 作為底層存儲，跟我們目前主要的數(shù)據(jù)平臺 Hadoop 能很好集成在一起；此外，Titan 除了支持 OLTP 操作以外，還可以跟 Spark 結(jié)合進行 OLAP 相關(guān)的分析。所以我們最終決定采用 Titan 。

Titan技術(shù)架構(gòu)

Titan 的總體技術(shù)架構(gòu)如上所示，存儲、索引、OLAP 的計算引擎都是開源的可選組件：

底層存儲支持 HBase/Cassandra，所以存儲是可以平行擴展的，幾乎沒有容量限制；

支持 Elasticsearch/Solr/Lucene 作為外部的索引插件，實現(xiàn)在進行非等值查詢時也能利用到索引；

Management API 負責 Schema 的創(chuàng)建，修改，刪除及實例管理等操作；

通過 Tinkerpop API提供圖上的操作接口；

Internal API、Database Layer、Storage and Index Interface Layer負責將 Tinkerpop 和Management API 的圖操作轉(zhuǎn)換成底層存儲 Cassandra 和 HBase 上的操作(比如HBase 中的put、get、scan)。

GraphComputer 提供以 Spark/MR 的方式進行圖上的 OLAP 操作，做子圖或者全圖上的分析(比如計算 Pagerank )。

Titan圖的表示

Titan用結(jié)點、邊和屬性三類信息來描述一個圖，如上圖所示。

結(jié)點(Vertex)：用于表示一個實體，結(jié)點通過指定不同的標簽(LABEL)來區(qū)別具體的實體類型，如Titan、Location；結(jié)點由唯一的 Vertex ID 標識，該ID由 Titan 自動生成并管理。

邊(Edge)：用于描述實體之前的關(guān)系，有出結(jié)點和入結(jié)點；邊同樣有標簽(LABEL)，用于區(qū)分邊的類型，如上圖所示的 father、lives；邊帶有方向；邊可以指定是否只允許單向查詢；邊可以指定 MULTILICITY，表示該 LABEL 的邊能存在幾條；邊也有唯一的 Edge ID，該ID由 Titan 自動生成及管理。

屬性(property)：既可以在結(jié)點上，也可以在邊上，用于描述結(jié)點和邊的附加信息；屬性通過 PROPERTY KEY來表示該屬性是什么屬性，如上圖所示 name、age、place；屬性也可以指定 CARDILITY，用于表示該屬性可以存在多個該屬性；屬性也有唯一的 Property ID，該 ID由 Titan自動生成及管理；對于結(jié)點和邊上的屬性都可以添加索引，這時通過屬性來查詢特定結(jié)點或者邊的時候，可以直接通過索引定位到對應(yīng)的結(jié)點或者邊的 ID，減少掃描的數(shù)據(jù)量，提升性能。

Titan的圖查詢

Titan通過 Tinkerpop 的 Gremlin 語言提供圖的查詢、修改等操作。一個 Titan 實例對應(yīng)的就是 Tinkerpop 的一個 Gremlin Server。多個對應(yīng)相同存儲后臺的 Gremlin Server 組成了 Titan 的分布集式集群。用戶可以通過 Gremlin Client 或者Restful API提交查詢請求。

查詢的例子如下：

#創(chuàng)建一個集群??

gremlin>?graph?=?TitanFactory.open('conf/titan-hbase.properties')??

==>standardtitangraph[hbase:[titan003,?titan004,?titan005]]??

gremlin>?g?=?graph.traversal()??

==>graphtraversalsource[standardtitangraph[hbase:[titan003,?titan004,?titan005]],?standard]??

#查詢name為'saturn'的結(jié)點??

gremlin>?saturn?=?g.V().has('name',?'saturn').next()??

==>v[256]??

#查看saturn結(jié)點有哪些屬性??

gremlin>?g.V(saturn).valueMap()??

==>[name:[saturn],?age:[10000]]??

#saturn的祖父的姓名??

gremlin>?g.V(saturn).in('father').in('father').values('name')??

==>hercules??

#查詢hercules的父母的信息??

gremlin>?g.V(hercules).out('father',?'mother')??

==>v[1024]??

==>v[1792]??

gremlin>?g.V(hercules).out('father',?'mother').values('name')??

==>jupiter??

==>alcmene??

gremlin>?g.V(hercules).out('father',?'mother').label()??

==>god??

==>human??

gremlin>?hercules.label()??

==>demigod?

Titan底層存儲格式

Titan 中的結(jié)點和邊按照鄰接表的方式組織，每個結(jié)點的鄰接表包含該結(jié)點的所有相鄰邊和該結(jié)點的屬性，存儲上遵循Big Table Data Model。

也就是說，表由多行組成，每一行由很多的Cell組成，每個 Cell 由一個Column和Value組成。行由唯一的 Key 標識，每個 Cell 由 Key+column 標識。

Titan Layout：

Edge & Property Layout：

如上圖所示，對于 Titan 的實現(xiàn)來說。每一行的 Key 就是結(jié)點的 Vertex ID，該 ID 是由 Titan自動維護的一個64bit長整型數(shù)。每個 Cell 就是結(jié)點的屬性或者該結(jié)點相連的邊。

邊 Cell 的 Column 包含邊的方向,邊上指定的排序?qū)傩缘男畔?#xff0c;鄰接點的ID, 邊的ID； 邊的 Value 包含邊上的所有屬性( Signature 屬性在前)。

屬性 Cell 的 Column 包含屬性的類型 ID ; ?Value 包含屬性的 ID 和屬性的值。

拍拍貸圖數(shù)據(jù)庫應(yīng)用

我們目前將用戶信息、設(shè)備信息及社交關(guān)系構(gòu)建了一個異構(gòu)網(wǎng)絡(luò)，并將該異構(gòu)網(wǎng)絡(luò)圖應(yīng)用在用戶關(guān)聯(lián)分析及反欺詐檢測場景。

傳統(tǒng)的方式上，我們的數(shù)據(jù)都是存儲在RDMS上，要查詢用戶的關(guān)聯(lián)關(guān)系時，都是通過關(guān)聯(lián)多張表來實現(xiàn)。但這種方式存在很多的問題：

這些表相應(yīng)都較大，在做表關(guān)聯(lián)的時候效率非常低下；

對于關(guān)系的層次支持非常有限，出入度很大的結(jié)點，產(chǎn)生的中間結(jié)果會非常大；

對于圖上的查詢不夠靈活。

這些都極大地限制了我們分析能力和分析效率。出于以上這些痛點，我們引入了 Titan 圖形數(shù)據(jù)庫。每天會通過改寫的 Titan Bulkload 將10億+結(jié)點信息和500億+左右的關(guān)系數(shù)據(jù)導(dǎo)入Titan 后臺 HBase 生成一張包含13類節(jié)點和15類邊的復(fù)雜異構(gòu)網(wǎng)絡(luò)。

通過該網(wǎng)絡(luò)，可以方便快速地回答以下類似問題：

• 和用戶A關(guān)聯(lián)的用戶有哪些；
• 和用戶A關(guān)聯(lián)的用戶有什么特征；
• 用戶A和用戶B怎么關(guān)聯(lián)在一起的。

下圖是我們將圖數(shù)據(jù)庫應(yīng)用于反欺詐中的示例圖：

根據(jù)原始的數(shù)據(jù)圖我們可以對用戶做以下調(diào)查分析，來確定特定的用戶是不是欺詐用戶或者是不是與欺詐用戶有關(guān)聯(lián)：

• 通過特定規(guī)則篩選可疑用戶
• 查看與可疑用戶有特定關(guān)聯(lián)的用戶
• 查看與可疑用戶有特定關(guān)聯(lián)的所有用戶組成的子網(wǎng)的網(wǎng)絡(luò)特征及用戶特征
• 分析特定用戶可以通過什么樣的關(guān)聯(lián)關(guān)系關(guān)聯(lián)在一起
• 最多可分析6層關(guān)聯(lián)關(guān)系的數(shù)據(jù)?

通過該方式，我們大大減少了調(diào)查過程中的工作量，整體效率提升了25%+。

作者介紹

馮錦明，拍拍貸高級數(shù)據(jù)工程專家。

http://database.51cto.com/art/201804/570147.htm

總結(jié)

以上是生活随笔為你收集整理的直击Titan图数据库：如何提升25%+的反欺诈检测效率？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。