当前大数据行业，随着算法的升级，尤其是机器学习的加入，“找规则”算法带来的“红利”正在逐渐消失，随之而来的是需要更深入地挖掘数据的方法，而这种新方法就是知识图谱。下面说说知识图谱，以及知识图谱在大观数据中的实践。1.什么是知识图谱知识图谱是一种语义网络，它使用点而不是实体，使用边而不是实体之间的关系。通俗地说，知识图谱就是连接所有不同类型的信息（HeterogeneousInformation）而得到的关系网络，它提供了从关系角度分析问题的视角。从这个角度来看，我们可以从“发现规律”的维度上升到“理解”的维度，这也是为什么有人说知识图谱是AI的未来。“大观数据是一家人工智能公司”这句话在机器眼中无非是一连串的字符，但从人的角度来看可以分为三部分，即主语“大观数据”和谓语“是”对象。人工智能公司”。那么有没有一种数据组织形式，可以让机器把这句话看成不再是一个字符串，而是一个主谓宾相近的可以“理解”的结构呢？当然，这是知识图谱应该做什么。知识图谱可以表示为实体-关系网络图。实体是包含信息的个体，绘制时称为节点；关??系是两个实体之间的连接，并且是画的时候叫边。借用上面的例子“大观数据是一家人工智能公司”，“大观数据”和“人工智能公司”是两个实体，“是”指的是这两个实体之间的关系。所以这句话可以用知识图谱表示在图1中图12.知识图谱的应用场景知道什么是知识图谱，知识图谱有什么用？这里我举两个例子：知识图谱的作用搜索引擎中的电子图及其在银行风控系统中的应用。1、知识图谱在搜索引擎中的应用有时候我们在使用搜索引擎的时候，我们的搜索词（Query）往往更像是一个问题，比如“张三毕业于哪里？”这时候就需要搜索引擎直接给我想要的结果，而不是网页排名。例如，如果我在Google中搜索“WhoisZuckerberg'swife”，我需要的是Zuckerberg妻子PriscillaChan的详细信息，而不是一些包含她信息的网页。我们先看看谷歌的结果：图2那么谷歌是怎么做到的呢？其实早在2012年，谷歌就在搜索中加入了知识图谱。用户可以通过谷歌构建的知识图谱直接查询结果。这种方法大大提高了用户体验。而且谷歌处理起来更方便。首先，query“WhoisZuckerberg'swife”通过自然语言处理技术（NLP）处理成“Zuckerberg”实体与“has_wife”的关系，从已构建的知识图谱中进行Query，然后返回query结果给用户。但这样的改变，从用户使用的角度来说，已经从一个普通的搜索引擎变成了一个智能问答系统，用户体验上升了一个层次。2.知识图谱在隐藏关系挖掘中的应用。马克斯韦伯曾经说过，“人是一种动物，挂在自己编织的意义网上”。这句话从侧面说明人与人之间的关系是很复杂的。能否挖掘出复杂的人际关系？？首先，人际关系其实就像一个网络。既然是网络，就一定有一个特点，就是网络上两个相邻节点之间的路径损坏，并不一定会影响到整个网络。例如，如果一个网络（无向图）中从相邻节点A到节点B的路径“断了”，则很有可能在不影响整个网络的情况下找到另一条从A到B的路径。那么互联网的这一特性应该如何应用到数据挖掘中呢？我们来看一个银行风控系统中知识图谱的例子。图3我们可以根据借款人在借钱时填写的关系来构建知识图谱。如图所示，借款人与张三是朋友，与李四是父子关系。当我们尝试将借款人的信息添加到知识图谱中时，“一致性验证”引擎就会触发。引擎会先读取张三和李四的关系，以此验证“三角关系”是否正确。显然，朋友的朋友不是父子关系，因此存在明显的风险。这里的隐藏关系挖掘可以借用通用的关系挖掘引擎，也可以自己实现隐藏关系挖掘引擎。由于其通用性，一般关联关系的挖掘通常难以保证关系挖掘的正确性。通常，规则的配置是为了保证关系挖掘的准确性。隐式关系挖掘技术是目前知识图谱研究的前沿方向。有兴趣的可以参考相关论文。知识图谱在银行风控中还有很多其他的作用，比如对流失的借款人进行二次甚至多度关系挖掘，寻找借款人。可见，“关系”越复杂，知识图谱越能发挥作用。知识图谱的应用场景还有很多，这里就不一一列举了。有兴趣的可以参考《知识图谱的应用》（http://mp.weixin.qq.com/s/aRKS1CHNdh51010sZzBLlA）三、知识图谱的构建既然知识图谱这么有用，那么我们如何构建自己的知识图谱，以及如何将传统数据转化为知识图谱？传统数据主要分为两类，格式化数据和未格式化数据。在将格式化数据转化为知识图谱时，需要将格式化数据映射到实体关系组中，从而构建知识图谱。非格式化数据的转换比较复杂，通常采用算法提取和程序提取两种方法。1、算法提取法：利用自然语言处理（NLP）技术对文本进行命名实体识别（NER），从无格式文本中识别出专有名词和有意义的短语，并进行分类。比如上面的例子，从文本“大观数据是一家人工智能公司”中，识别出了“大观数据”和“人工智能公司”这两个实体以及“是”的隶属关系，这样我们就可以通过“大观数据”“是”“人工智能公司”是实体组构建知识图谱。由于目前NER识别技术还不够成熟，我们通常对NER识别出的实体进行人工修正，以保证识别的准确性2.程序抽取方法：在处理实体识别无格式数据的过程中，我们经常会遇到半格式数据，比如一份简历文本，其中往往包含，姓名：XXX，公司名称：XXX等格式，当遇到这种半格式化的文本，我们也可以使用正规的方法进行抽取，以保证知识图谱构建的完整性和准确性。4、知识图谱的存储和neo4j的性能测试知识图谱是基于图的数据结构，通常存储在图数据库中。我们先来看一下图数据库的排名（部分）。数据来源DB-EnginesRanking(https://db-engines.com/en/ranking/graph+dbms)。图4通过排行榜可以看出Neo4j数据库是最受欢迎的。事实上，neo4j已经是业界分析知识图谱的主流数据库。那么如何将neo4j图数据库应用到项目中，如何优化neo4j图数据库呢？首先我们看一下neo4j的性能：测试环境：1、操作系统：MacOSX10.10.52、内存：8G3、CPU参数：8核8线程4、编程语言：python2.75，Neo4j版本：3.3.06、服务器节点数：单点测试内容：当节点数为10000、100000、100万、1000万时，设置索引和不设置索引时搜索节点的平均延迟放。测试结果如下：图5从上面的测试可以看出，当节点数（Node）超过1000万时，在不设置索引的情况下，平均查询延迟已经超过6秒，可见neo4j有明显的这时候慢了下来。“难以忍受”，显然这样的延迟在实际项目应用中是完全不能接受的。但是我们发现设置索引后查询时间明显下降，那么索引是不是设置的多一些呢？我们来看看1000万节点情况下有无index的插入延迟测试：图6从上图的测试结果可以看出，在***数据的情况下，insertionwithindex为30%比没有索引的插入慢，所以索引越多越好，那neo4j还能优化什么呢？四、neo4j图数据库优化neo4j不使用schema，所以理论上neo4j可以存储任何形式的数据。但是，由于neo4j通过键值对（Key-Value）的双向列表来保存节点和关系的属性值，neo4j只适用于存储实体关系和实体的简单属性。在实际应用中，一个实体通常包含许多属性。如果把这些属性都存储在neo4j中，neo4j的查询会变得异常缓慢。在实际应用场景中，经常会遇到高并发的情况。这时候单节点的neo4j就会显得力不从心。那么在实际项目实战中如何更好的使用neo4j来抵抗高并发呢？1、高可用架构：neo4jHA（HighAvailability）是neo4j的高可用特性，但是这个特性只有neo4j企业版才有。neo4jHA使用多个neo4j从数据库来替代单个neo4j主数据库的容错架构。这种架构可以让数据库具备在物理机出现故障的情况下完成读写操作的能力。因为neo4jHA使用主从数据同步，而且写操作也可以在从库进行（测试过这种方式不如主节点写靠谱），所以使用neo4jHA比读负载处理能力更强单个neo4j数据库。如果你使用的不是neo4j企业版，那么你可能需要自己搭建一个neo4j集群来实现高可用的架构。当然，你可以使用Neo4j+DRBD（DistributedReplicatedBlockDevice）+Keepalived搭建自己的neo4j集群，使用DRBD单点备份neo4j库数据，使用Keepalived管理你的集群。此外，你还可以通过zookeeper管理你的集群节点，将master节点上数据修改的Cypher语句元操作同步到slave节点（类似MySQL的binlog），实现主从同步，从而实现读写分离。当然，无论你使用方法一还是方法二，都会增加开发和维护成本。2、增加缓存：应用缓存：在实际应用过程中读写图库时，经常会遇到查询一些不经常修改的数据。比如需要经常查询用户所属国家的信息，更改国家属性的频率比较低。而且，用户的国籍信息不会经常变化。这时候我们可以添加应用缓存（如：redis、leveldb等）对查询结果进行缓存，减少直接访问图库的频率，减轻图库的读取压力。数据库缓存：neo4j执行一次查询操作后，会将数据缓存在内存中，执行相同的查询操作neo4j会直接返回缓存在内存中的数据结果。如果进行随机查询，后一次查询的结果将覆盖前一次查询数据。可以通过修改配置文件中的dbms.query_cache_size参数来调整内存缓存配置。因此，在执行语句时，尽量利用已有数据的缓存，减少Cache-Miss情况的发生。3.索引查询优化：查询优化：由于neo4j会在内存中缓存查询结果，所以尽量不要把不需要的查询结果放在内存中，比如下面的cypher语句：1、MATCH(n)OPTIONALMATCH(n)-[r]->()RETURNcount(n.prop)+count(r.prop);2,MATCH(n)可选匹配(n)-[r]->()RETURNcount(*)+count(*);语句1优于语句2，因为后者会将节点和关系的所有属性加载到内存中，然后计算计数值，而前者只会将必要的属性加载到内存中计算计数值。索引优化：我们知道，数据库索引实际上是一种在数据之外维护特定算法的数据结构（如B+Tree）。比如图7，建立二叉树来加速col2的查询，让原来的“顺序”搜索变成“二分搜索”，将查询复杂度降低到O(logn)，索引也利用了原理accesslocality充分利用操作系统的pagecache来加快查找速度。图7：数据库索引原理介绍。由于添加索引会让库在维护数据的同时维护一个额外的数据结构，因此在更新数据时会造成额外的开销。这也证实了上面测试中插入数据时没有索引。结论比索引更快。Neo4j1.4之后的版本引入了自动索引。可以在config/neo4j.properties配置自动创建索引，也可以通过CREATEINDEXON:Label(PropertyName)语句手动创建索引，提高查询效率。多属性值也可以用联合索引来设置（https://neo4j.com/docs/developer-manual/current/cypher/schema/index/）。4.Neo4j和KV（Key-Value）数据库的结合使用由于neo4j中节点的属性和关系是通过Key-Value的双向链表存储的，这种数据结构决定了neo4j中存储的节点不能包含属性值太多。但是在实际应用中，经常会遇到一些实体拥有大量属性的情况。如果有必要，需要通过这些属性的值来查询实体，然后找到实体拥有的关系。这时候可以联合使用neo4j数据库和KV数据库（如：MongoDB），比如在neo4j节点的属性中存储MongoDB中的objectId。这样既可以充分利用neo4j的特性进行关系查询，又可以利用KV数据库的特性进行从属性到实体的查询。通常当gallery和KV数据库一起使用时，尤其是经常需要通过属性查询实体时，需要设置neo4jschemaIndex，即在中为与KV数据库关联的值设置索引neo4j。总结与展望Knowledgegraph和Neo4j有很多有趣的特性，这里限于篇幅不再赘述。自2012年谷歌推出知识图谱技术以来，知识图谱迎来快速发展。由于知识图谱在关系“理解”方面的优势，已经在各大互联网公司和传统企业的项目中落地，并取得了不错的效果。正是因为对知识图谱中数据的理解与传统方法不一致，给传统的数据挖掘算法带来了挑战。相信随着人们对知识图谱的关注度越来越高，知识图谱领域也会涌现出越来越成熟的构建、存储和挖掘概念。相信在不久的将来，知识图谱会被应用到更广泛的领域。服务大家。【本文为专栏作者“大观数据”原创稿件，如需转载可通过专栏取得联系】点此查看该作者更多好文
