本⽂整顿⾃ NebulaGraph x 阿⾥云计算巢专场中众安保险的⼤数据应⽤⾼级专家曾⼒带来的《众安资产在 NebulaGraph 的应⽤实际》分享，视频⻅链接。
⼤家好，我是众安数据迷信应⽤中⼼的曾⼒，明天很⾼兴在这⾥能够跟⼤家分享 NebulaGraph 在众安资产的实际。
01 基于事件的数据资产平台设计
在理解这⼀切之前，咱们须要先晓得什么是资产治理平台以及它能够解决什么样的问题。
资产治理平台是全域的元数据中⼼，它能够对数据资产进行治理监控，解决企业外部的数据孤岛问题，开掘数据价值并对业务赋能。它次要解决咱们数据找不到、数据从哪⼉取，排查门路⻓、数据复⽤率低这四个十分核⼼的关键问题。
设计指标
对于资产治理平台，咱们有三个⾮常重要的设计⽬标——
- 强扩大：是指实体关系定义、资产操作以及资产查问的扩展性。
- 低耦合：是指资产平台与其余零碎对接时，对接入零碎业务流程零影响。
- 高时效：是指须要近实时的数据采集、疾速的数据处理和查问性能。
外围性能
数据资产治理平台核⼼性能包含以下三个：
- 类型定义：需提供⼀个形象的设计定义不同的实体 / 关系，以及它们蕴含的属性。每个定义的实体 / 关系均须要定义唯一性束缚，用于数据判重。在此基础上咱们能够扩大一些定义类型，比方标签、术语、标签流传等等。
- 元数据采集：次要有通过周期性、流式和手工录入三种形式进行数据采集。
- 元数据管理：数据存储常见的选型是关系型数库存储定义或数据，搜索引擎存储数据、变动记录、统计类信息，图数据库则负责关系查问。数据分析常见的场景是数据地图、血统及影响性剖析、全链路血统剖析。数据利用则是在相干数据采集到平台后，能够疾速实现资产割接、数据安全治理以及数据治理等更高层次利用需要。
类型定义
开源零碎 Apache Atlas
借鉴于开源零碎 Apache Atlas 和 DataHub，咱们来初步理解类型定义设计的外围因素。
Atlas 的类型定义模式是一套基于 JSON 的 TypeSystem，能够自定义扩大，它的外围概念是实体、关系和属性，并在此基础上扩大出分类、术语、业务数据等定义设计。
DataHub 则采纳 Avro 进行事件模型的定义、PEGASUS 建模语言进行实体、关系和属性的建模，值得一提的是 Aspect 这个概念，其形容实体特定方面的属性汇合，同一实体关联的的多个 Aspect 能够独立更新，雷同的 Aspect 也能够再多个实体间共享。DataHub 预置了一些实体和关系模型，咱们能够复用这些模式或自定义新模型。
通过两个开源零碎的类型定义设计，咱们不难看出实体、关系、属性是元数据系统当中最根底的三个外围类型定义的元素。基于整体的架构、外部数据模型场景、数据存储选型、学习老本等方面因素的思考，众安数据资产平台的类型定义是参照 Apache Atlas 的 TypeSystem 设计，定义一套独立的类型定义零碎。
实体类型定义 EntityDef 的外围因素是类型名称、父类型名称和属性列表。
对于类型名称，须要单租户下束缚惟一；对于父类型名称，其实就是对一些公共属性集的复用，相似于 Java 类的继承机制，咱们能够通过获取父类型及其超类的所有属性。目前为不便类型解析，一个实体仅能定义一个父类型。对于属性列表，一个实体能够有 1~n 个属性，且至多有一个唯一性属性。
关系定义 RelationshipDef 的外围因素是定义名称、关系类别、起始 / 完结端点定义和属性定义；
对于类型名称，须要单租户下束缚惟一；对于关系类别，依据是否容器关系和端点实体生命周期分为三类。
- Association 关系：是一种非容器关系，比拟典型的例子是调度作业的依赖关系，两者之间不为蕴含关系，且生命周期独立。
- Aggregation 关系：是一种容器关系，但端点实体的生命周期独立，比方咱们的报表零碎，数据模型和画布关系，画布蕴含模型，但模型能够独立于画布而出存在，生命周期独立。
- Composition 关系：是一种容器关系，且端点生命周期完全一致，最直观的例子是表和列之间的蕴含关系，删除表的时候列实体主动被删除。
对于端点定义 RelationshipEndDef，端点即是实体关系中关系实体的映射，所以须要定义起源和指标两个端点。每个端点定义须要端点的实体类型名称以及是否为容器。如果关系类别是⼀个容器类型的关系的话，须要设置某⼀个端点容器标记为 true，此时边方向是子项实体指向容器实体。如果关系类别是非容器的关系的话，所有的端点容器标记都须要设置为 false，此时边方向是端点 1 实体指向端点 2 实体。
对于属性列表来，一个关系能够有 0~n 个属性。同实体属性定义不同的是，关系定义能够不配置属性定义。
属性定义 AttributeDef 外围因素是名称、类型、是否可选、是否惟一属性、是否创立索引、默认值等内容。对于属性类型，因 NebulaGraph 图库反对的类型无限，仅反对根底数据类型。是否反对索引创立，是指创 Nebula tag/edge schema 的时候，对于某个属性是否创立一个 tag/edge 索引，以反对在非凡查问场景下的数据查问。
实体的判重是资产平台类型定义的要害设计，咱们首先看看开源产品的设计理念。
Atlas 类型定义零碎当中，所有实体都继承于⼀个⽗实体 Referenceable，它只有⼀个惟一属性 QualifiedName，且被标记为了唯⼀的属性。所有继承于它的实体类型属性中均没有惟一属性。QualifiedName 没有用固定格局，在 Atlas 内置的几个 Hook 中，次要格局为 xxx@meta-namespace。在 Hook 写入时指定，上图的例子就定义的是某个集群、某个存储卷在的唯一性标识。
DataHub 实体唯一性标记是 URN，也叫作唯⼀属性资源名称。它有肯定的生成规定，即 urn:<namspace>:<Entity Type>:<ID> 命名空间默认设置为 li，类别则是实体定义名称，ID 是指惟一属性汇合拼接，能够嵌套 URN，上图的例子一个数据集，代表某个 Kafka 集群下的 Topic。
基于两个开源项目分析，不难看出唯一性判断均是基于惟一属性来解决，两者均是在 Ingest 扩大中进行了固定格局的定义写入，而不是基于实体定义中多个明确代表惟一属性进行灵便的拼接解决，其拼接的字段艰涩难以解析。
众安设计了一套唯一性判断定义形式，即某个实体注册时，先判断实体定义是否有 Composition 类别关系的边定义援用。如果不存在该关系类别定义，则间接从实体定义的属性定义中检索 isUnique=true 的属性。如果存在改关系类别定义，那以后实体的唯一性属性将不足以束缚其唯一性，还须要带上边定义的容器实体的惟一属性才能够保障。这是一个递归的过程，可能须要传入多个实体的唯一性属性才能够判断。比方注册一个 MySQL 表，除了表实体的表名称之外，还须要 MySQL 库实体的 Host、端口、数据库名称等惟一属性才是残缺的为惟一属性列表。
在获取了惟一属性列表后，还须要加上租户和类型定义名称，继而生成某一租户下对应的惟一实体标记。
操作须要三个流程，首先须要把唯⼀性的属性列表，依据其对应的类型名称跟属性名称进行一次正序排序，而后对租户、类型定义名称、惟一属性 key 进行一次正序排序，生成一个可读性高的惟一名称。其次，因惟一名称可能较长，须要进行一次 32 位摘要后进行存储，并加以索引进行查问，能够晋升整体查问的有效性。最终全局的资产惟一 ID，则是用 Snowflake 算法生成的惟一 ID。因摘要算法无效概率反复，故应用分布式 ID 生成算法生成 ID，用于数据存储。
资产采集
流式采集有十分好的劣势，能够通过音讯队列，实现零碎间解耦，实现数据的准实时上报，同时对事件音讯也有良好的扩展性。周期性采集是流式采集的⼀个补充，它包含两种⽅式基于 ETL 或零碎接口的被动推送，或相似数据发现零碎的数据被动拉取。
对于以上两种⽅式还没有达成的采集，能够用过人工补录的模式进行填写，以反对注入对接零碎无奈反对上报或局部血统无奈解析等场景，晋升数据残缺度。
上面给大家介绍一下众安元数据系统⼏个版本采集流程的迭代——
V1.0 版本是齐全基于 T+1 的离线 ETL，咱们会把数据开发⼯作台、调度零碎以及阿⾥云 MaxCompute 元数据加载到数仓后，通过 ETL 解决推送到元数据平台，因数据量不大一个反对递归的关系型数据库即可满足要求。若数据量较大，则能够通过搜索引擎和图数据库进行扩大。
随着业务的倒退，数据开发对于元数据的时效性要求会越来越高，比方分析师创立的长期数据想 T0 就间接分享给其余部门应用，以及元数据整体数量越来越大，解决耗时较长，获取的工夫越来越晚。
基于以上需要，咱们在元数据平台开了⼀层 API，在数据开发工作台进行表操作时，或调度零碎创立调度工作时，会调用接口将数据同步给元数据平台。同时早晨咱们仍然会有离线的 ETL 进行数据补充，两者联合起来进行数据源的数据查问服务。
接口模式也会有肯定的弊病，在各个对接的业务零碎中，会有大量的同步嵌套流程，元数据服务不可用或执行工夫过长，例如零碎发版时的业务中断，创立一个数百列的表引发的接口超时等，均会影响失常业务流程。
于是咱们参考各类开源元数据平台设计思路，设计了基于流式事件的元数据平台，基于不同的事件，对接零碎通过音讯队列上报后，实现零碎间解耦。资产平台基于不同事件进行分类解决，并将最终的数据存储到搜索引擎、关系型数据库，以及图数据库当中。
平台架构
下⾯给⼤家介绍⼀下众安数据资产平台的架构，咱们将平台分为了 5 个子系统。
- Portal 服务 对接前端，提供通用的实体页面布局配置接口，实现配置化的页面布局。同时转发申请到 Core Service 进行解决，比方查问、类型定义等。
- Discovery 服务 次要就是周期性的采集服务，通过配置定时的采集工作，并实现元数据的定时采集。
- 零碎 SDK 所有服务对接资产平台，均须要通过 SDK 进行对接，包含 Discovery 服务、数据超市、报表平台、开发⼯作台、数据标签平台等，SDK 提供了对立的事件拼装、权限治理、事件推送等性能，能够极大的晋升平台间交互的开发效率。
- Event 服务 负责生产音讯队列中的音讯，进行事件的解析和数据长久化。
- Core 服务 提供对立的查问 API、标签 API 以及类型定义的 API 来实现查问跟类型定义的治理。
同时咱们提供了对立的数据存储层模块 Repo，来实现查询器和对立数据处理器的相干解决，其外部提供了数据库及图库的扩大 SPI，以便实现相干扩大。
咱们将资产平台的事件形象为以下三种：
- 元数据事件 MetadataEvent，包含实体 / 关系的增删改查等子事件。
- 元数据异样事件 FailMetadataEvent，在解决 MetadataEvent 时失败了，比方类型定义不存在或事件程序有问题，咱们会对立生成一个元数据异样失败事件，能够基于此事件做异样数据落库或告警告诉。
- 平台事件 PlatformEvent，包含应用元数据平台触发的埋点事件，包含实体的珍藏、查问、应用以及平安分级等事件，其中一部分会做按天级别的统计解决，以便在平台上能够看到相似的统计信息。
事件进⾏解决，须要关注以下三点：
- 分而治之，因为整体的事件的数据量会⽐较多，为了保障性能须要依照 Event 类别和影响，使⽤不同的音讯队列。对于咱们方才介绍的三种型的事件，咱们理论应用了三个 Kafka Topic 进行音讯推送。
- 音讯的程序，对于元数据相干事件，音讯生产须要严格保障有序，如何来保障有序呢？咱们⽬前采⽤的⽅案是由 Kafka Topic 单分区模式来解决的，为什么不⽤多 Partition 呢？因为实体跟关系之间的注册有可能是会分到不同的 Partition 上来进⾏解决的，因为异步生产解决有可能不同分区的数据产生生产沉积，有概率呈现不同的分区，生产注册事件先到，实体注册事件后到的状况，导致废音讯的呈现。
- 最终一致性，因为事件 Event 的异步解决，咱们只能保证数据的最终⼀致性。
好，那讲完了事件的生产流程，咱们下⾯就要来看数据长久化的流程。咱们的数据事件从音讯队列拿到之后，会被咱们的事件服务 Event Service 所生产，Event Service 中的事件处理器在生产数据的时候会⽴刻对这个数据进⾏⼀份数据的存储，它会存到关系型数据库⾥⾯，作为⼀个审计的回溯⽇志。
在存储完回复⽇志之后，事件处理器就会开始对事件进⾏解决，如果事件处理异样的话，依据特定的这种事件类型，咱们会有抉择的把⼀些异样的事件放到异样事件的音讯队列⾥⾯，而后供上游的零碎进⾏订阅告诉，或者是做外部前期的问题排查。
如果事件处理胜利了之后，咱们会把数据丢到联结数据处理器当中。那联结数据处理器外部其实就是咱们对关系型数据库以及图库的数据进⾏了⼀个整体的事务的包裹，以便两者之间呈现失败的时候，能够对数据内容进⾏回滚。
那在数据长久化当中，咱们的关系型数据库跟图库当中别离存储了什么内容呢？像关系型数据库当中，咱们往往存储了实体跟关系的数据，包含属性跟这种理论的这种名称的⼀些定义，同时还存储了实体的统计类的信息⽤于剖析，还有类型定义的数据⽤于各种各样数据的这样⼀种校验。那图库当中次要就是点边的这种关系⽤于图谱的查问。
资产的查问剖析集成于 Core Service 模块中，目前有两大场景分类，数据地图和血统剖析。
数据地图类检索，个别是分查问，咱们定义一套相似于 ES DSL 格调的查问接口申请，通过查问解析器，翻译成要查问的关系型数据库语句，目前因为数据量还在 PG 的接受范畴内，咱们并没有应用 ES。同时应用、珍藏、查问的统计类记录和变动记录，也是寄存于 PG 当中，通过指定接口查问。
血统剖析类查问，个别是关系查问，咱们也通过相似于 ES DSL 格调的查问接口申请，通过查问解析器，翻译成图数据库所辨认的 nGQL 或 Cypher 语句，包含 N 跳关系查问、子图查问、属性查问等。
对于⼀些非凡场景查问需要，比方数据大盘，或特定实体的扩大事件，咱们通过或定制化查问的形式进行解决。
02 NebulaGraph 在众安资产平台的实际
图数据库选型
咱们在做⾃主化平台开发之前，对热门开源我的项目的图数据库选型做了调研。
选型次要思考两⽅⾯的因素，数据库架构和资产平台设计的匹配性。
在架构因素⽅⾯，外围因素是读写性能、分布式扩大、事务反对和第三方依赖。对于 Neo4j 来说，尽管它的性能读写性能⾮常优越和原⽣存储，然而因为 3.x 版本之后，社区版曾经不再⽀持分布式模式，所以说必定不能达到咱们预期的要求。JanusGraph 和 NebulaGraph 均反对分布式扩大和存算拆散架构，但前者的存储、索引均依赖于第三方组件，带来大量额定运维工作，其反对分布式事务，而 NebulaGraph 不反对分布式事务处理。
资产平台设计的匹配性因素，外围因素是数据隔离、属性及 Schema 数量上线、属性类型、查询语言等。
JanusGraph/Neo4j 社区版属性集均不反对强 Schema，这意味着更灵便的属性配置。同时，属性类型也反对诸如 map、set 等简单类型。NebulaGraph 属性集尽管有强 Schema 依赖，但属性和 Schema 数量没有下限，也反对 Schema 的批改，惟一美中不足的是不反对 map/set 等简单类型属性，这将对类型定义和零碎设计有肯定的影响，以及对潜在的需要场景有肯定的束缚。三种数据库均有通用的查询语言、以及能够基于 GraphX 进行图算法剖析。
为什么抉择 NebulaGraph
基于以下四点的思考，众安抉择了 NebulaGraph——
第⼀是 分布式的存算拆散架构，能够以最优的老本，疾速扩缩容相干服务。
第二是 内部组件依赖较少，⽅便运维。
第三是 卓越的读写性能 ，在 19 年年底众安金融风控场景，咱们对 NebulaGraph 就进⾏了⼀定的性能测试，咱们 在纯 nGQL 的 insert 这种写入计划下，通过 DataX 能够实现 300w record/s 的数据写⼊速度，这个是一个十分惊人的数据同步的体验。
第四是 数据存储格局，因为众安有大量的子公司租户，须要进行数据的存储隔离，如果是其余产品就须要部署多套图库，或一套图库数据里打租户标签。NebulaGraph 能够应用图空间的形式实现人造的数据隔离，大大简化了咱们开发的工作量。
NebulaGraph 阿⾥云部署模式
因为众安没有独立机房，所有的服务均依赖于阿里云金融云，基于阿⾥云 ECS 的能力，能够疾速实现服务器以及服务器上存储资源的弹性扩收留。理论部署中，咱们将 graphd 跟 mated、storaged 进行了离开部署，防止大量查问导致内存过高，影响到其余图数据服务的稳定性。
graphd 占用了 2 台 4C 8G 服务器，metad/storaged 占用了 3 台 4C 16G 服务器。以后资产平台的实体数量在 2,500w 个左右，边数据在 4 左右，次要为数据集类型数据。
咱们应用每台 ECS 应用了两块 200G 的 ESSD 进行存储，依据 NebulaGraph 的举荐，磁盘的数量越多，图空间 Partition 的扩大的数量就能够越多，能够取得更好的并发解决能力。
众安在 NebulaGraph 中的模型设计
上面介绍一下基于 NebulaGraph 的模型设计。
对于实体定义来说，对应 NebulaGraph 的某一个 Tag，其绝对于其余图数据库相似于 Label 概念，就是某个属性集的名称，通过 Tag 能够更快检索倒到某一个实体点下的属性，类型定义的 Tag 必须同这一类型的点 ID 进行强绑定，注册时须要进行相干校验。另一个属性集的概念是公共标签，公共标签能够做很多事件，比方业务属性集、实体标签等。公共标签在 NebulaGraph 当中也对应一个 Tag，这个 Tag 能够绑定到多种不同的实体，比方环境公共标签，能够赋给 MySQL 数据源实体，也能够赋给 MaxCompute 数据源实体等。
对于关系定义来说，对应 NebulaGraph 中的某个 Edge Type，类型定义中的起源指标端点的实体类型，必须同这一类型的点 ID 进行强绑定，注册时须要进行相干校验。
对于数据隔离来说，上述实体和关系模型，通过 NebulaGraph 的图空间进行隔离，在众安外部的多个租户实体下，比方保险、小贷、科技等，会在租户初始化时创立指定图空间，后续的类型定义均在租户图空间下进行。
最初咱们再来看⼀下模型设计的继承关系。咱们所有的实体根节点是⼀个叫做 Asset 的实体定义，咱们将一些公共属性定义其中，包含名称、展现名称、备注、类型等；
基于 Asset 类型，咱们实现了对接平台的各种资产实体，报表平台里的模型、视图、画布、⻔户等实体，数据超市里的路由 API、数据 API 以及内部扩大 API 等实体，开发工台里的调度工作、流计算工作、工作空间、文件等实体，以及两个比拟非凡的资产属主实体和服务资产实体。
另一个非凡的实体是数据集实体，咱们将不同数据源数据源、表、列等信息均定义了独立的资产实体定义，以便实现不同数据源的差异化属性展现。
咱们最终的全链路数据资产，均是通过数据集及其子类自定义实现串联，从而实现跨平台的链路剖析。比方调度作业的库表血统，能够关联到报表平台的数据模型，也能够关联到数仓的 Data API 依赖的 Table Store 的某张表等等。
03 将来瞻望
2022 年年底，众安基本上曾经实现了各个平台的各种资产的注册跟上报的过程。
2023 年，咱们将在围绕数据资产割接、数据安全治理和数据治理三个方面进行扩展性开发。
- 数据资产割接，将站在用户实体的角度上，疾速辨认集体关联的数据资产，工夫属主资产切换和到职交接性能。
- 数据安全治理，基于资产平台的能力做出多种扩大，迁徙外部老元数据系统的表分级、权限审批性能；外部脱敏规定配置平台及 SDK，扩大反对基于表分级数据加密和白名单策略等。
- 数据治理，基于资产平台的全链路血统剖析能力，察看资产热度、应用等要害指标，清理有效作业和反复计算作业，实现降本增效，缩小云平台应用费用。
要来感触同众安科技一样的图数据库体验嘛？NebulaGraph 阿里云计算巢现 30 天收费应用中，点击链接来搭建本人的资产管理系统吧！