你了解知识图谱吗？

技术选型

知识图谱

一、什么是知识图谱

概念

知识图谱是谷歌在2012年提出来的，最初的目的是优化其搜索引擎。在现实世界中是存在很多的实体的，各种人、物，他们之间是相互联系的。知识图谱就是对这个真实世界的符号表达，描述现实世界中存在的一些概念，以及它们之间的联系 。具体来说是一个具有属性的实体，通过关系连接而成的网状知识库。
基本组成

知识图谱的基本组成三要素：实体、属性、关系。实体-关系-实体三元组；实体-属性-属性值三元组。例如在电商的知识图中，包括用户、商家、商品都是实体，他们带有各自的属性，彼此之间又互相联系。

在知识图谱中，有一类特殊的实体叫做本体，也叫做概念或语义类。它是一些具共性的实体构成的集合。比如说，比尔盖茨和乔布斯都是人，微软和苹果都是公司。
应用领域：搜索、推荐、问答

Google 2012年提出来知识图谱概念，并将其用来提高其搜索引擎质量，与谷歌类似，微软将知识图谱技术用于旗下必应（Bing）搜索引擎，优化搜索结果质量和交互式搜索体验；LinkedIn 与 Facebook 利用知识图谱挖掘其平台上人、事、资讯等之间的相互关系，使得用户更容易发现感兴趣的内容、找到志同道合的朋友；eBay、亚马逊 等电商平台使用知识图谱为用户和产品建立联系，执行更精准的产品推荐；IBM 则专注于企业服务，其 IBM Watson Discovery 产品能够帮助用户根据自身的特殊需求快速构建自己的知识图谱框架。

与传统的数据存储和计算方式相比，知识图谱技术更加侧重于对非结构化异构数据的收集和处理 ，更擅长对于关系的表达和计算，可以处理复杂多样的关联分析、挖掘到更多隐藏知识。与此同时，知识图谱的数据结构与人工智能领域许多技术任务所基于的数据一脉相zhi承（异质结构多关联的大数据），可以为后续的机器学习和推理任务提供强有力的支持，帮助企业在智能搜索、智能问答、智能推荐、以及大数据分析这几个方面提升性能。
- 智能搜索：传统的搜索引擎依靠网页之间的链接和权重进行搜索排序，而知识图谱提供了实体的分类、属性和关系的描述，从而可以直接对事物进行更精准的语义搜索。
- 智能问答：基于知识图谱的智能问答是目前产业界问答系统的主要技术路线之一，即对于给定的自然语言问题，利用知识图谱技术进行语义的解析、查询、推理以得出答案。该技术常见于智能手机或音箱载体上的智能对话机器人，如 Siri、Google Assistant、Amazon Alexa、小爱同学、天猫精灵，以及微软的小冰、小娜等，这些智能问答 agent 的背后都有相关企业各自积累的知识图谱作为问答系统的支撑。
- 智能推荐：基于知识图谱的推荐能更好将用户与被推荐项目之间的各种相互联系考虑进来，可以增强数据的语义信息、挖掘隐藏的关联信息，进一步提高推荐的准确度。
- 大数据分析：基于知识图谱中实体的关联信息和推理，我们能挖掘出传统数据分析较难得到的隐含信息，该优势在存在大量异构信息的数据集中更为显著。基于知识图谱的大数据关联分析在金融风控、反欺诈乃至安防等应用场景中都有很好的效果。

二、如何构建知识图谱

参考连接

baijiahao.baidu.com/s?id=168322...

baijiahao.baidu.com/s?id=161226...

虽然知识图谱的概念 2012 年才被提出，但其背后的思想本质上是上个世纪的**语义网络（Semantic Network）**知识表达形式，即一个由节点（Point）和边（Edge）组成的有向图结构知识库。其中，图的节点代表现实世界中存在的"实体"，图的边则代表实体之间的"关系"。
知识图谱构建流程

一般来说，构建一个知识图谱通常会经历知识获取、知识表示与建模、知识融合、知识存储，以及构建完成后的知识查询和推理几大要素：
- 知识获取：从不同来源、不同结构的数据中抽取知识（实体、关系以及属性等信息），这是知识图谱构建的核心与前提条件。
  - 互联网上的数据基本上都是结构化的，非结构化的和半结构化的。结构化数据 一般就是公司的业务数据（关系型数据库）。这些数据都存储到数据库里，从库里面抽取出来做一些简单的预处理就可以拿来使用。半结构化数据 （词典、百科类标记清晰的网页数据）和非结构化数据（如声音、图像和文字语料数据），比如对商品的描述，或是标题，可能是一段文本或是一张图片，这就是一些非结构化数据了。但它里面是存储了一些信息的，反映到的是知识图谱里的一些属性。所以需要对它里面进行一个抽取，这是构建知识图谱中比较费时费力的一个工作。
  - 从数据里需要抽取的其实就是之前所提到的实体、属性、关系这些信息。对于实体的提取就是NLP里面的命名实体识别。这里相关的技术都比较成熟了，从之前传统的人工词典规则的方法，到现在机器学习的方法，还有深度学习的一些使用。比如说，从一段文本里面，我们提取出来比尔盖次这个实体以及微软这个实体，然后再进行一个关系提取。比尔盖次是微软的创始人，会有这么一个对应的关系。另外还有属性提取，比如比尔盖茨的国籍是美国。在这些提取完成之后都是一些比较零散的信息，然后在再加之前用结构化信息所拿到的东西以及从第三方知识库里面所拿到的信息做一个融合。
- 知识表示与建模：为知识制定统一的数据架构（data schema），将获取到的知识依照统一的数据结构存储并形成知识库，这是知识图谱正式构建的第一步，影响着后续的知识融合、存储以及查询推理可以使用的方法与效果。
- 知识融合：将不同源的知识以统一的框架规范进行验证、消歧、加工等异构数据整合工作，这是知识图谱更新与合并的必经之路，为不同知识图谱间的交互融合提供可能性。
  - 关于实体对齐。举例来说，比尔盖茨这四个字是中文名称，Bill Gates是他的英文名称，但其实这两个指的是同一个人。由于文本的不一样，开始的时候导致这是两个实体。这就需要我们对它进行实体对齐，把它统一化。
  - 另外是实体消歧。举例来说，苹果是一种水果，但是在某些上下文里面，它可能指的是苹果公司。这就是一个实体歧义，我们需要根据上下文对它进行实体消歧。
- 知识存储：依据数据量的大小、数据特征以及应用需求的不同，选取合适的存储模式，将获取到的数据存储起来，形成知识图谱。
- 知识查询与推理：基于构建完成的知识图谱进行查询，或者进一步推理挖掘出隐藏知识来丰富、扩展知识图谱，这是知识图谱构建的最终目的，与知识获取共同影响着知识图谱的应用场景和范围。
  - 形成知识图谱以后，有些关系可能是无法直接得到的，然后需要进行知识推理，这可以对知识图谱进行扩展。比如，猫是猫科动物。猫科动物是哺乳动物。这就可以推理出来，猫是哺乳动物。但是这个推理也不是随便就可以推出来的。比如，比尔盖茨是美国人，比尔盖茨创建了一个公司，但这个公司并不一定是美国的。
知识获取之前，确认构建方式
- 先为知识图谱设计数据模式（data schema），再依据设计好的数据模式进行有针对性的数据抽取，这是自顶向下（top-down）的数据建模方法，一般适用于数据相对集中、知识结构相对确定的垂直领域行业知识图谱；
- 先进行数据的收集和整理，再根据数据内容总结、归纳其特点，提炼框架，逐步形成确定的数据模式，这是自底向上（bottom-up）的数据建模方法，一般适用于与涉及海量数据、内容繁杂且架构不清晰的公共领域通用知识图谱。

三、目前构建知识图谱的技术实现方案有哪些？

参考：zhuanlan.zhihu.com/p/613855167...

知识生产构建技术
- 实体、关系抽取
  - 基于规则：词典匹配、正则表达式、模板
  - 机器学习：决策树、支持向量机、朴素贝叶斯
  - 深度学习
知识存储技术
- 图数据库是知识图谱的底层存储计算引擎，是一种以图结构进行存储和查询的数据库。图数据库的关键概念是点（代表实体）和边（代表关系），通过边将顶点连接在一起，从而进行快速的图检索操作。相对于关系数据库来说，图数据库善于处理大量复杂、互连接、低结构化的数据，这些数据变化迅速，需要频繁的查询，而在关系数据库中，这些查询会导致大量的表连接，因此会产生性能上的问题。
- 不管是实体关系还是事件抽取总是要有个地方来存储的。现在产业界基本用的都是图数据库，也就是属性图数据库，是完全和知识图谱契合的。
知识应用技术
- 知识检索、知识探索，涉及到图数据库查询语言 Gremlin 和 Cypher 以及 SparQL。
- 知识搜索方面会用一些其他方法从图数据库或者其他存储方法里面获取所需要的知识。
- 知识计算更多的是与图相关的计算（路径分析、社区分类和中心性等算法），知识推理更多的是跟深度学习有关的，比如图神经网络。
- 还有很多面向具体的应用，比如问答、推荐、数据分析、知识溯源以及辅助决策等，这些都是与具体业务有直接关联的人工智能或知识图谱方面的应用。

四、落地实现

业务理解、知识图谱设计、算法、开发。

图数据库

一、调研

根据存储方式的不同可以将图数据库分为两类：

原生图数据库无论从功能上还是性能上都明显优于非原生图数据库，是我们做图数据存储计算技术实施的首选
- 原生图数据库：数据存储模式为存储和管理图而设计，为图进行过优化，如Neo4j、Nebula Graph等。
- 非原生图数据库：将图数据序列化，采用关系型数据库、面向对象数据库、或是其他通用数据存储，如JanusGraph、HugeGraph等。
图数据库目前排名：db-engines.com/en/ranking/...
常见图数据库

Neo4j和JanusGraph目前应用最广泛,TinkerPop作为标准规范也很重要。需要根据使用场景选择合适的图数据库。
- Neo4j：最流行的开源图数据库，拥有自己的Cypher查询语言。具有高性能和可伸缩性。
- OrientDB：多模型图数据库，支持键值对、文档和关系模型。使用SQL作为查询语言。
- ArangoDB：多模型图数据库，提供键值、文档和图形支持。使用SQL和自己的查询语言AQL。
- Amazon Neptune：亚马逊云上的快速、可靠的全托管图数据库服务。与Amazon VPC集成。
- JanusGraph：基于TinkerPop标准，可以运行在Hadoop和Spark之上。提供分布式图数据库功能。
- Azure Cosmos DB：微软Azure上的全球分布式多模型数据库。支持图数据模型。
- AgensGraph：用于大规模图分析的事务型并行图数据库，支持Cypher查询语言。
- Apache Giraph：基于Hadoop的开源图形处理系统，用于进行分布式图计算。

对照

图数据技术调研以及业务实践

	JanusGraph	Nebula Graph	Dgraph（原谷歌团队）	Neo4j
开放性	完全开源，Java 开发	企业版和社区版差异体现不具体	部分管理工具差距	闭源
部署成本	需要额外部署Hbase,Cassanda	原生	原生	原生
学习成本	gremlin 查询语句，apache 推荐，java 语言开发	nGQL，C++ 语言开发	DQL,类似 GraphQL	cypher 查询
实践案例	ebay、360、redhat	美团、腾讯、知乎	思科、西门子、贝壳	国外目前最广泛使用
社区&文档	不活跃，文档数量尚可	活跃，中文友好，官方中文文档	活跃，中文不友好，文档较少	有社区版
分布式支持	原生支持	原生支持	原生支持	支持

其他对照

java 复制代码

Nebula Graph 和 Neo4j 都是图数据库,它们之间的区别主要在:
1. 数据规模
- Nebula Graph可以处理千亿级节点和万亿级边缘关系,是大规模图数据库。
- Neo4j更适合中小规模的图计算,最大规模在10亿节点级别。
2. 数据结构
- Nebula Graph有property graph和hypergraph两种数据结构。
- Neo4j只支持property graph。
3. 查询语言
- Nebula Graph使用nGQL查询语言。
- Neo4j使用Cypher查询语言。
4. 实现机制
- Nebula Graph是原生分布式图数据库。
- Neo4j可以通过集群实现分布式,但复杂度较高。
5. 运维成本
- Nebula Graph部署和扩缩容更简单。
- Neo4j集群运维复杂度较高。
综合来说,如果需要处理超大规模图数据,需要强大的分布式能力,那么Nebula Graph更为合适。如果是中小规模图,或者需要灵活性和丰富生态,则Neo4j更好。 （已编辑）
    
Memgraph 也是一款图数据库,与 Neo4j 和 Nebula Graph 相比,主要特点是:
1. 规模级别
- Memgraph可处理上亿规模节点和关系,小于Nebula Graph,但大于Neo4j。
2. 查询语言
- 支持使用Cypher查询语言,与Neo4j类似。
3. 分布式能力
- 支持分布式部署,但需要手动 sharding,不如 Nebula Graph 原生自动分布。
4. 性能
- 读性能优于Neo4j,但写性能略差于Neo4j。
5. 算法支持
- 内置图神经网络和机器学习算法。这方面优于 Neo4j。
6. 运维难易度
- 简单的分布式配置,部署维护相对容易。
综上,Memgraph在查询性能和算法支持上具有优势,适合在亿量级规模场景下 besoin高性能分析的图数据库。但分布式能力不如Nebula Graph。
所以可以根据实际场景的规模、性能要求、算法需求等进行选择。
    
JanusGraph 也是一种图数据库,相比 Neo4j、NebulaGraph 和 Memgraph,它的特点是:
1. 数据规模
- 可扩展到十亿级节点和关系,大于 Neo4j 但小于 NebulaGraph。
2. 分布式能力
- 支持分布式集群,通过 sharding 实现水平扩展。
3. 存储后端
- 支持不同的存储后端如 HBase、Cassandra 等。
4. 查询语言
- 支持 Gremlin 和 SPAL 查询语言。
5. 一致性
- 提供强一致性保证。
6. 其他特点
- 支持多模型图,定制性较高。
- 可与 Spark、Giraph 集成进行大规模图计算。
综上,JanusGraph 对Distributed图计算有很好的支持,但易用性不如 Neo4j。如果需要大规模分布式图处理,JanusGraph是一个不错的选择。
    
DGraph 是一个开源的分布式图数据库,它与 Neo4j、NebulaGraph、JanusGraph 等图数据库的对比情况如下:
1. 数据规模
- DGraph 可扩展到数十亿个节点和数百亿条边,适用于大规模图数据。
2. 查询语言
- 支持 GraphQL 查询语言。
3. 一致性
- 通过 Raft 协议保证强一致性。
4. 分布式架构
- 原生支持分布式,可无缝水平扩展。
5. 存储后端
- 使用 Badger 作为默认键值存储。
6. 额外功能
- 提供管理 UI 和监控功能。
- 支持acl、身份验证等安全特性。
总体而言,DGraph 更注重易用性、安全性和分布式特性。如果需要一个分布式、安全、易于使用的图数据库,DGraph是一个不错的选择。它很适合在云环境下构建图应用。 （已编辑）

二、Neo4j

Neo4j是一个嵌入式的、基于磁盘的 、具备完全事务特性、由Java语言编写 的面向图的数据库，它将结构化数据存储在图上而不是表中，重点解决了拥有大量连接的传统RDBMS在查询时出现的性能衰退问题。通过围绕图进行数据建模，Neo4j会以相同的速度遍历节点与边，其遍历速度与构成图的数据量没有任何关系。结合我们的使用经验总结来看Neo4j的特点主要为：

较早发布的图数据库，功能完善稳定，易用（Cypher支持最完善）；
基于JVM运行，跨平台支持友好，易于满足国产化要求；
社区版仅支持单节点，在千万节点上亿边的数据规模下有较好的表现，在数据规模较大时可通过部署多个Neo4jServer做数据拆分，但限制为一个图的数据规模要在单个节点可承受的数据范围（大概单图数据规模控制在千万顶点上亿边）内。

问题

是不是基于磁盘的？可以存储多少节点和数据？

java 复制代码

基于磁盘，Neo4j更适合中小规模的图计算,最大规模在10亿节点级别，但是相比较关系型数据库，Neo4j需要更多的磁盘空间、内存空间、CPU资源
1. 存储空间占用:
- Neo4j中每个节点和关系都会存储对应数据,需要占用一定磁盘空间。
- MySQL可以通过关系表的设计优化存储,节省空间占用。
2. 内存占用:
- Neo4j要缓存数据到页面缓存以提高访问速度,对内存需求较高。
- MySQL可以通过配置控制缓存使用,内存占用较低。
3. CPU占用:
- Neo4j查询时需要即时遍历图结构,CPU计算密集型。
- MySQL查询针对的是预定义的schema,计算效率较高。
4. 读写吞吐:
- Neo4j是面向读优化,复杂读查询效率高。
- MySQL可以通过索引、 partitions进行读写优化。
5. 数据冗余:
- Neo4j可能存在数据冗余,一个节点被多个关系引用。
- MySQL可以通过表关系设计来减少数据冗余。

多个独立的图结构如何存储？

txt 复制代码

1. 使用标签(Label)来区分不同的图
- 为每个图的节点添加不同的标签
- 在查询时,通过指定标签来过滤对应图中的节点和关系
- 不同图之间可以通过关系连接
- 这种方式所有的图共存在同一个数据库中
2. 使用多个Neo4j数据库来隔离不同的图
- Neo4j支持同一实例下创建多个数据库
- 每个图在一个独立的Neo4j数据库中存储
- 数据库之间的节点无法直接通过关系连接
- 需要在服务层对多个数据库进行协调查询