基于动态知识图谱的大规模数据集成技术

编者按

数据烟囱、信息孤岛已成为政府、企业在数据应用中不可回避的问题，都在寻求各种方案打破现状，实现数据融合已成当务之急。百分点在经历多个大型数据集成项目洗礼后，已经达到了业界领先水平，通过利用动态知识谱图技术，将模型与数据进行解耦，在业务处于探索期或业务变化十分迅速的场景下，能够极大地提升数据集成的效率，解决海量数据动态集成的难题，并且能支持千万级、PB 级的实时导入分析。

在信息高速变化的时代，企业、政府对数据的认知是一个不断变化的过程。通常某个数据集成项目的初期，客户与集成方对数据、业务的认知都是不全面的，比如今天提供了人口库的数据，明天提供车辆数据、后天又提供了卡口数据……

在这种场景下，如果利用常规的数据集成实现手段，就要调整表结构、改写 ETL 任务代码、删除已经集成过的数据，并重新进行数据集成。但这在大规模数据集成的场景下，几乎是不能接受的，比如已经集成数百张表、入库 10PB 数据，如果要重新进行一遍集成，可能需要数以月记。这时，具备数据动态集成的能力就十分重要了。

因此，如何在海量数据之上将动态的数据进行关联融合，同时满足融合快速、融合无信息丢失等业务要求，并将新增的数据快速融入到当前的图谱中，不间断提供知识服务是目前的业界难题。

基于动态知识图谱的数据集成实现方案

常规的数据集成方案通常有以下痛点：

1. 只能针对特定行业的数据进行集成，一旦存在多个行业数据交叉融合，需重新定制方案；
2. 集成方案不灵活，一旦数据发生变更或有新的数据进入，就需下线业务重新集成，成本巨大。

对此，百分点利用动态知识谱图技术，将模型与数据进行解耦，采用灵活的元数据管理方式，即使元数据变更，已入库数据也无需重新入库。

百分点数据集成实现方案整体架构，包含五个部分：

数据源： 原始数据，支持各种类型的数据，如结构化数据，RDBMS、NOSQL、MQ 中的数据，也可能是各种半结构化的数据，如 HTML、PDF、TEXT 等各种文档或音频、视频等多媒体数据。同时，系统也支持配置 URL，通过互联网爬取的网页数据。

知识管理：知识管理的核心在于对多源异构的数据建立统一的模型，并将不同的源数据映射到统一的知识模型上，最后配置知识的融合规则与冲突解决规则，以形成统一的知识体系。

知识存储： 核心的知识库，原始数据经过离线或实时 ETL 处理后的转换为知识，并与库中存量数据按照模型的配置进行知识拉通、融合、冲突解决后，供上游系统消费。

后台管理： 实现对系统的监控、告警、日志审计以及资源管理、调度管理，并对采集到的数据进行统计分析，以改善整个动态知识图谱的运作效率。

知识应用： 支持全局知识库联合搜索、图谱分析、地图分析、知识的多维度分析、多人多机协同分析以及战法分析，除通用的各种分析手段外，还支持特定行业的定制化分析应用。

由上可知，整个架构中最重要的部分为以知识管理为核心的知识图谱建模方式，以及知识存储为核心的动态存储设计，本文也将着重对以上两点进行解读。

以知识管理为核心的知识图谱建模

本体模型是数据世界对现实世界的映照，同时也是一种数据的分类、建模方式。在实际项目中，用户面对着海量多源的、异构的数据，非常难以进行数据分析。

为了解决这一问题，本项目引入了本体模型，对异构数据进行统一建模，并在字段级别进行了归一化，多源异构数据源通过抽取、转换、清洗变成统一的本体模型后，可为上层应用或分析人员暴露更加友好的接口，从而提供便利。

值得注意的是，在本项目中，本体模型是由业务人员进行配置的。业务人员可以建立四种类型的本体，包括实体、事件、文档、关系，具体解释如下：

实体：能够独立存在的人或事物，例如：

1. 人物: 凡是可以用于标识“人”的东西，都可以当作人物，包括虚拟的社交账号，实际中的手机号，具体的人等；
2. 物品: 包括真实的手机，电脑，各种真实物品；也包括 IM 工具，各类软件等虚拟物品；
3. 组织: 包括真实的各类组织，如 ISIS 组织，政府单位，慈善组织等各类真实的组织；也包括 QQ 群，聊天室等各类虚拟组织；
4. 位置: 包括某具体的地理位置，如政府大楼；也包括 LAC 地址，IP 地址等虚拟空间。

事件：有时间属性，视为一种特殊的关系，用于连接实体与实体，实体与文档。本项目中，事件主要指现实生活中的内容，如发邮件、发短信、转发帖子、发表评论等。

文档：文档特指非结构化文档，如邮件中的各种格式的附件，包括但不限于 PDF 文档、Word 文档，以及各种格式的视频、音频。

关系：用于连接实体之间，实体与事件、文档等的相互关系，如人与人之间的亲属关系，人与物品之间的拥有关系，人与事件之间的主导关系。

在创建本体时，不光要指定本体的类型，还需要对本体所包含的字段与对应的字段类型进行配置，从而进行字段级别的归一化。此项目支持的字段类型有 date、long、int、double、string 和 geo。特殊字段还会进行数值的归一化，如时间格式有多种表现形式，这里会转换为统一的形式，方便后续处理。

以车管所数据为例，通过车管所的数据可以建立一种人 - 车 - 罚单的本体模型，人与车之间为拥有关系；人与罚单之间通过“闯红灯”事件相连接，而罚单本身则以文档的形式展现。完成本体模型后，就完成了对元数据的描述。

接下来，就需要将真实的数据映射到本体模型上。同时，要在字段级别上对多源异构数据进行归一化。还以车管数据为例，具体过程如下图所示，可以看出，通过本体映射将车管所 3 张表的数据映射到了 7 个本体上（2 个实体、3 个关系、1 个事件和 1 个文档），并将车主名称和姓名进行了统一，将日期的不同表示方式进行了归一化。

通过以上建模过程，在应用侧就建立了一个多源数据的统一的逻辑视图，即从分析人员的角度对所有数据构建成了一个图模型，分析人员无需关注底层数据源差异和存储细节，只需关注如何在此图模型上进行分析即可。

对于知识库的存储设计，由 HBase 核心存储、Elasticsearch 全文索引、neo4j 关系索引组成。HBase 存储了完整的数据，Elasticsearch 建立全文索引方便用户搜索，neo4j 建立关系索引，以加速关系查询。

四种数据集成架构

以上内容描述了整个数据模型构建的过程，任何数据要集成进来，必须先进行以上过程，在元数据层面进行拉通、融合。

接下来的问题就是如何将客户的数据快速接入知识库的存储中去，以提供统一的数据查询服务，也就是数据层面的集成。

由于数据具有多样化特点：

从 数据类型 上看，存在结构化数据、半结构化数据、非结构化数据；

从 业务价值 上来看，又分为高价值密度数据，如账户信息、转账信息、低价值密度数据，如日志信息；

从 数据规模 上来看，有超大规模数据，如万亿级数据，大规模数据，如亿级数据，小规模数据，如百万级以下数据。

百分点经历多个大型数据集成项目洗礼后发现，通常高价值密度的数据，数据规模都不会太大。比如公安领域的重点人员数据、卡口设备数据、网络安全领域的高危 IP、重点监控网站等“实体”数据，此类数据特征是数据量有限，价值密度高。

而如果数据规模超过 10 亿级，通常都是“事件”类型的数据，比如车辆通过卡口的事件、手机连 wifi 的事件和手机上网的 HTTP 日志。这类数据还有一个典型特征，就是数据量巨大且无限增长，但数据价值密度很低，通常也只关心最近一段时间的日志。

因此，针对不同的数据场景，百分点提供了不同的数据集成方法，分别应对不同场景下的数据集成需求。

整体数据集成架构如下：

小规模数据集成： 这类数据往往是客户提供了小规模的样本，通过前台 Import 功能，直接上传各种类型的文件，即可导入。

高价值密度数据集成： 通常是客户提供的关键数据，这类数据首先需要业务人员根据需求进行建模，然后通过后台离线 / 实时数据流将数据接入到本体库中。

低价值密度数据集成： 通常是“事件”数据，数据量极大，并有一定时效性，需要定期 House Keeping。当前的实现方式是通过存放在外部 OLAP 型数据库中，应用层通过直连的方式进行 adhoc 查询，将其中有价值的数据选择性地导入到本体库中。

互联网半结构化数据集成： 通过给定 URL，会启动后台爬虫，爬取对应的网页进入知识库，跟存量知识进行协同分析。

实现“动态性”的核心逻辑

百分点动态知识图谱实现“动态性”的核心逻辑在于，采用元数据与存储分离查询的方案，来赋予知识图谱“动态”特性，包含数据模型的动态性、模型变更的动态性、融合的动态性和“事件”数据的动态性。

1 数据模型的动态性

由于数据模型有一个专门的后台管理系统进行配置管理，业务可以根据实际客户需求进行模型设计与数据源接入，节省了大量开发成本。

2 模型变更的动态性

进行新增字段、修改字段、删除字段，以及模型修改的时候，在应用端不用重新导入数据。

实现方式如下：

本体库中的数据元数据的存储与物理数据的存储是分离的，应用层查询 MySQL 获取元数据并进行缓存，然后在 Elasticsearch 中检索到数据后，会在应用层的内存中进行元数据与物理数据的拼装。

因此，当元数据变更后，只需要更新 MySQL 数据库与应用层的缓存，无需对实际的物理数据进行变更。

这里需要注意的是，在 Elasticsearch 中存储的是融合完成的数据。因此当融合规则变更后，需要重建索引。

3 融合的动态性

当融合规则变更后，只需要对特定表重建索引，无需重新导入用户数据。

这是因为，在 HBase 中是按照每种本体类型一张表进行存储的，而需要融合的数据必然是多个源的数据写到 HBase 的一张表中，HBase 的 rowkey 设计为 MD5(PK)，而 column 设计为数据源 ID，因此若多源数据存在相同的主键，则会存储到 HBase 同一行的不同列中。而后续的 ETL 任务，则会将多列的数据按照融合规则进行融合后在 Elasticsearch 中建立索引。

由此可见，不同本体数据写入互不影响，而同一本体新增数据源，若发生融合，会写入到不同列中。此时下一次 ETL 任务就会用新的数据覆盖 Elasticsearch 中旧的数据，完成索引重建。而当融合规则发生变更时，同样不需要再从客户数据源接入数据，只需要进行索引重建即可。

4 “事件”数据的动态性

由于本体库中的数据，是固化的高价值密度数据，而“事件”数据天然是低价值密度的，并且具有时效性。

因此，为了不“污染”本体库，在实现中将事件数据存放到单独的 OLAP 存储中，用户可以进行预分析，然后将其中具有价值的部分导入到本体库中。

受益于这种分离存储的架构，无需对客户数据提前进行大量转换、融合处理，单纯的写入 OLAP 存储是十分高效的，对 1KB 数据能轻松达到 10W+ TPS。在实际的场景中，客户当天提供的数 TB 数据，第二天就能完成建模、接入到应用端可见。

总结与展望

在本文中，我们介绍了如何通过知识图谱对多源异构的数据进行数据集成，以及百分点使用知识图谱进行数据集成的几种方案和如何通过元数据与存储分离查询的方案赋予知识图谱“动态”的特性。

从实际项目的落地情况来看，这些特性和方案无疑能很好地助力客户落地各种场景下的数据集成、分析需求。从另一个角度讲，当前方案还是有很多进步空间的，比如目前应用层的开发还需要对底层知识库的存储方式有很深的认识，并且应用与底层存储耦合严重，若底层架构需要升级往往会影响到所有的下游应用。

未来，可将底层知识库进行逻辑抽象，封装出统一查询层 API，应用层可以像使用图数据库一样使用知识库，简化与解耦应用层开发，也可助力快速开发行业应用。另外，外部的“事件”库如何更好的与本体库进行协同、统一管理，也是目前百分点进一步探索的方向。

本文转载自公众号百分点（ID：baifendian_com）。

原文链接：

https://mp.weixin.qq.com/s/kwt5uOIf93o8XoVrNZVLhw