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

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

圖數據庫以圖論為基礎，數據本身以圖的方式存儲(比如鄰接表)，在處理與圖相關的任務時占有先天的優勢。所以目前在知識圖譜，社交網絡分析等領域開始有越來越多的應用。

常見的圖形數據庫

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

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

Titan技術架構

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

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

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

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

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

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

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

Titan圖的表示

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

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

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

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

Titan的圖查詢

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

查詢的例子如下：

#創建一個集群??

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'的結點??

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

==>v[256]??

#查看saturn結點有哪些屬性??

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 中的結點和邊按照鄰接表的方式組織，每個結點的鄰接表包含該結點的所有相鄰邊和該結點的屬性，存儲上遵循Big Table Data Model。

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

Titan Layout：

Edge & Property Layout：

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

邊 Cell 的 Column 包含邊的方向,邊上指定的排序屬性的信息，鄰接點的ID, 邊的ID； 邊的 Value 包含邊上的所有屬性( Signature 屬性在前)。

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

拍拍貸圖數據庫應用

我們目前將用戶信息、設備信息及社交關系構建了一個異構網絡，并將該異構網絡圖應用在用戶關聯分析及反欺詐檢測場景。

傳統的方式上，我們的數據都是存儲在RDMS上，要查詢用戶的關聯關系時，都是通過關聯多張表來實現。但這種方式存在很多的問題：

這些表相應都較大，在做表關聯的時候效率非常低下；

對于關系的層次支持非常有限，出入度很大的結點，產生的中間結果會非常大；

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

這些都極大地限制了我們分析能力和分析效率。出于以上這些痛點，我們引入了 Titan 圖形數據庫。每天會通過改寫的 Titan Bulkload 將10億+結點信息和500億+左右的關系數據導入Titan 后臺 HBase 生成一張包含13類節點和15類邊的復雜異構網絡。

通過該網絡，可以方便快速地回答以下類似問題：

• 和用戶A關聯的用戶有哪些；
• 和用戶A關聯的用戶有什么特征；
• 用戶A和用戶B怎么關聯在一起的。

下圖是我們將圖數據庫應用于反欺詐中的示例圖：

根據原始的數據圖我們可以對用戶做以下調查分析，來確定特定的用戶是不是欺詐用戶或者是不是與欺詐用戶有關聯：

• 通過特定規則篩選可疑用戶
• 查看與可疑用戶有特定關聯的用戶
• 查看與可疑用戶有特定關聯的所有用戶組成的子網的網絡特征及用戶特征
• 分析特定用戶可以通過什么樣的關聯關系關聯在一起
• 最多可分析6層關聯關系的數據?

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

作者介紹

馮錦明，拍拍貸高級數據工程專家。

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。