1.3 阿里巴巴知识引擎技术架构

首先，我们把构建、维护知识图谱并提供服务的系统定义为知识引擎。下面对知识引擎的技术架构做整体介绍，如图1-2所示。

概括地讲，平台产品提供全链路构建领域知识图谱的基础能力，管理知识的整个生命周期和数据安全，包括图谱管理、知识建模、知识维护、知识生产、知识服务及知识推荐和问答。业务产品的最终目标是更好地服务于业务，基于底层知识图谱为具体的各业务场景提供一整套系统性的解决方案，而不仅仅只是提供独立零散的数据服务和算法服务。平台产品和业务产品在架构上采用框架式设计，在确保扩展性的同时，通过可插拔方式接入算法能力，不断提升产品的智能化水平。

底层数据存储支持多种存储方式，包括图存储和关系存储，并根据数据特性和业务诉求选择合适的数据库。业务层对于知识服务有数据量、QPS、RT、峰谷等要求，平台支持使用各种中间件进行数据服务加速，如搜索引擎、缓存、本地内存等。线上任务基于业务场景选择合适的加速方式。知识生产模块支撑知识获取、知识融合、知识推理等，会涉及极大的数据量、极复杂的规则和算法模型，需要与离线分布式计算平台、流计算和算法平台打通。

下面具体介绍各个模块。

1.3.1 平台产品：知识建模与管理

图谱的数据建模类图如图1-3所示。

1.基础模型

图域（domain）：各域之间数据隔离，用户权限可控制在域上，确保数据安全，至于是逻辑隔离还是物理隔离，取决于业务。

实体（topic）：也称为实例（instance），每一条实际的数据或信息叫作实体，比如古天乐。

概念（class）：也称为类型（type），用于管理图谱中的点，通过配置属性可结构化点实体，实体与概念的关系是多对多，如果一个实体属于多个概念，则其结构为这些概念属性的集合，比如古天乐属于人和演员。为了更好地管理概念，也可以建立起概念之间的关系，可以是树状、网状等。

关系（relation）：用于管理图谱中的边，通过配置属性可结构化边实体，一个边实体只能属于一个关系，比如同事。

属性（property）：每个概念或关系可以设置多个属性，如果属性的值可枚举，还可关联属性值，比如性别、出生日期等。

系统属性：不可通过平台功能进行更改，其值也是通过系统自动设置的，比如ID、KEY、创建时间、更新时间等。

基本属性：值的类型是基本类型，比如整型、字符串等，由用户自行配置管理。

对象属性：值的类型是另一个概念，比如父亲、主演电视剧等，在底层存储时会自动转换为边实体进行关联，所以关系不能配置这类属性。

属性约束：针对属性值的各种限制，比如：格式约束（数字范围、文本长度、小数点精度、日期格式等）、条件约束（是否多值、是否去重、是否唯一等）。

2.存储模型

由于知识建模本身就是提供数据建模能力，当然也可以自建配置平台所需的基础模型，所以在存储模型上有两种方式：1）平台的基础模型系统固化，图谱的Schema存储在关系数据库中，实体存储在图数据库中，通过基础属性关联起来；2）平台的基础模型通过建模功能灵活配置，图谱的Schema和实体都存储在图数据库中，通过边关联起来。具体采用哪种方式，主要取决于平台的基础模型是否稳定、是否需要频繁变更。

知识建模功能主要管理图谱的本体，知识管理功能则是管理实体数据，并没有技术难点，主要在于视觉交互设计以及前端页面渲染，因为会涉及点边的网状图形化展示，以便更加直观地管理维护，模型管理原型图和实体管理原型图分别如图1-4和图1-5所示。

1.3.2 平台产品：知识生产

如图1-6所示，知识生产主要包含知识接入、知识获取、知识融合和知识推理，这四个模块也是知识图谱相关算法的主要模块。四个流程通常是算法通过代码、脚本等形式进行黑盒化处理，那么平台建设如何实现知识生产白盒化管理呢？

通过对这四种知识生产流程进行调研和抽象，可以通过组件化方式封装算法能力和业务逻辑，以实现复用性和扩展性。这里有两类：1）节点流组件，关联底层分布式计算平台的脚本任务流，通过产品界面手工配置进行注册；2）UDF组件，自定义实现Java组件接口，通过注解方式自动化扫描注册。平台提供通用的组件库，业务方可自行管理私域的组件库，通过组件全景视图管理组件的使用情况和生命周期。

配置后台是知识生产的人机交互产品，实现任务流程统一配置管理，各业务使用了哪些流程、哪些算法能力，产生了哪些数据，任务执行情况如何，一目了然。

基础配置：四种任务需要的基础配置元素各不相同，在产品交互上进行差异化处理。

步骤配置：一个任务可以包含一个或多个步骤，通过顺序进行任务流程编排，一个步骤关联一个组件，从组件库中挑选好组件后，根据业务需求调整组件的参数值，如图1-7所示。

执行记录：包含任务实例、状态查询、手工触发、日志分析等功能，通过实时服务或异步消息等机制与底层执行引擎频繁交互。

执行引擎：是知识生产的内核，主要包含了任务调度、任务执行和监控报警三个模块，与底层分布式定时调度器和分布式计算引擎交互，实现统一调度、执行、优化、监控和预警等。

配置后台在完成任务配置提交后，调用执行引擎的服务进行任务注册，通过手工执行或分布式定时调度器触发任务执行流程。

任务执行流程首先结合日期及业务参数生成任务实例，再根据任务先后顺序生成任务流，发给分布式计算引擎执行实际任务，通过轮询机制获取任务流执行状态，并通过消息机制上传给配置后台。

如果任务执行失败或未按时执行，根据报警配置，通过邮件、钉钉、短信和电话等方式报警。

下面展开说明整个知识生产流程，如图1-8所示。在完成知识建模后，通过知识生产流程产出数据，再通过知识维护进行人工处理（编辑、审核等），最终通过知识服务赋能业务。其中，知识生产的第一步包含结构化的知识接入和非结构化的知识获取，然后通过知识融合和知识推理进行数据的再处理。

（1）知识接入的产品功能主要包括本体对齐、属性映射配置、属性校验三大模块，如图1-9所示。它针对的是结构化的源数据，一次配置只接入一张源表，如果多张源表对应到同一个目标类型，则可通过下一步的知识融合功能进行数据融合处理，目标类型的选择来自之前的知识建模结果。在属性映射配置中，可以针对每一个属性做简单的数据处理，这里的处理算法来自组件库。在属性校验模块，可针对整个本体数据进行综合性的校验处理，校验算法也来自组件库。

（2）知识获取主要针对非结构化的源数据，通常为文本或文章，从中抽取出结构化的数据。主要包括数据源和目标类型配置、获取算法组件配置，算法组件来自组件库；可通过摘取一段文本进行在线实例预运行，以测试算法组件效果，如图1-10所示。

（3）知识融合产品功能较为复杂，设计上是一个子流程，可以由多个步骤组成，而知识接入和知识融合都只有一个步骤。在产品功能上分为两个模块：融合源类和目标类型配置、融合处理设置，融合流程可以从分组组件开始，每组数据可配置不同的步骤，每个步骤可关联算法组件，并调整参数，最终生成一张子流程图，如图1-11所示。

（4）知识推理产品设计为规则推理，把推理逻辑抽象为可配置、可管理的规则，规则的元数据来自知识建模，如图1-12所示。如果推理逻辑不可描述，可生成算法组件，然后通过知识融合功能进行配置。规则推理分为离线推理和在线推理。

离线推理适用于数据量大、耗时长和规则复杂的场景，底层执行引擎根据规则数据生成可执行的Hive脚本，并进行拓扑优化后，运行在分布式计算引擎上，反复迭代运行，直至结果数据稳定。产出的结果数据再通过知识接入，回到知识引擎中。

在线推理适用于数据量可控、耗时短和规则简单的场景，执行引擎根据规则数据生成Gremlin语句，进行图数据库的实时查询，返回查询结果。在线推理还可发布为实时知识服务对外赋能，在产品设计上进行性能压测校验，RT和QPS需控制在阈值范围内。

1.3.3 业务、平台产品：知识服务

如图1-13所示，从服务形态上分为在线服务和离线服务，分别对应OLTP和OLAP的场景；从服务类别上分为通用服务和定制服务。

1.通用服务

通用服务是平台型服务，不感知具体业务数据本身的含义，直接基于知识图谱的物理模型而提供的服务，比如域服务、实体类型服务、关系类型服务和属性服务。

（1）单点查询。查询一个人的住址、公司名称等。

（2）扩线查询。查询一个人的同事，或者一个商品管理的类型属性信息等。

（3）统计查询。查询从某个城市出发的航班架次。

（4）增加过滤条件。在查询过程中可增加实体或者关系属性的过滤条件，比如只查询一个人在其工作地的朋友而非出生地的朋友。

（5）图算法查询。最短路径算法、PageRank算法和社区发现算法等。

2.模板规则服务

模板规则服务是在通用服务之上封装了一层模板规则，用于提供更加复杂的图谱查询服务。Gremlin模板是把要查询的Gremlin范式抽离具体的参数，用占位符代替，把语法表达式固化成模板，从而最大限度地减少语法解析的耗时，提高了查询的性能。推理规则是指定特定为实体或者实体类型，以及图谱游走遍历的关系和属性过滤条件，返回符合规则约束的联通子图。

（1）Gremlin模板。查询一个商品关联的菜谱，并根据菜谱的做菜人数倒排，取最常用的100个菜谱。通常这样写（Gremlin语法举例）：

其中有4个中间节点，item（商品）、sku（最小库存单元）、material（食材）、recipte（菜谱），一个商品关联多个sku，一个sku关联多个食材，一个食材关联多个菜谱。

商品的ID经常变化，每查询一个商品，都要构造这样一条Gremlin语句，经历语法树的解析。通常把语法中经常变化的字段抽象成占位符，组装成模板语句。

把模板语句解析的结果缓存起来，这样能大幅提升服务查询的效率。

（2）推理规则。例如，爷孙关系：（a，b）存在父子关系，（b，c）存在父子关系，得出（a，c）是爷孙关系。

商品场景挂载：商品a属于类目b，类目b属于婚礼场景，得出商品a是婚礼用品。

3.渠道定制服务

渠道定制服务则是针对具体业务场景打造的私域图谱服务，具有很强的业务相关性，作用域仅限于某项具体的业务范围内，图谱的模型设计和服务内容与业务场景本身强耦合，比如商品服务、金融服务等。

对于商品渠道而言，有些特殊场景的查询是图谱通用的遍历式的查询无法满足的，渠道定制服务更多的是提取图谱中的某个或者某些类型实体，利用强大的离线分析引擎，提前计算出结果，并利用缓存或者搜索引擎提供服务。比如商品归一服务提取了商品图谱中商品、类目、属性等节点，经过一系列的数据关联分析过程，识别出不同渠道的类似商品。从而应用于相似品推荐、竞品分析、跨渠道铺货和商品属性补全等场景。

4.离线服务

离线服务主要针对数据量大、业务逻辑复杂、无实时性要求的业务场景，包括数据分析统计、管控、导入导出等服务，以及更加复杂的知识生产、知识推理等OLAP服务。主要分为Scheme服务和实体数据服务，除了最基本的批量导入导出，还支持定制更复杂的数据产出规则，比如知识生产和推理服务。知识生产在数据导出的同时支持数据分组、融合、对齐等知识加工过程；推理服务则是把推理规则下沉到离线分析引擎做数据筛选的过程。

5.知识管控

知识管控对图谱的管控不仅仅是指对实例数据的增删改查，更多的是对图谱操作性能和安全的管控。例如图谱查询的剪枝机制、超时强杀机制、事务回滚机制、Drop等危险指令管理机制等，在业务上有对图谱规则化、配置化管理机制。当对接新渠道图谱时，只需切换渠道标识以及图谱实例标识，快速接入。

平台需赋能众多业务，必须考虑如何平衡业务便捷性和平台稳定性。私域图谱服务不仅仅要做接入的管控，更要做数据服务内部的强安全管控，如图1-14所示。比如，图谱查询具有其特殊性，每一层的关系网络查询，中间数据集、计算量都和图谱稠密度强相关，很容易遇到超级顶点（例如快递员的朋友）等问题，造成系统超时、内存溢出、线程池满，从而导致服务崩溃。所以必须从接入层、服务容器层、业务逻辑层做好服务权限和数据资源的安全管控。