本文为微众银行大数据平台：周可在 nMeetup 深圳场的演讲这里文字稿，演讲视频参见：B 站
自我介绍下，我是微众银行大数据平台的工程师：周可，明天给大家分享一下 Nebula Graph 在微众银行 WeDataSphere 的实际状况。
先来说下图数据库利用背景。
WeDataSphere 图数据库架构是基于 JanusGraph 搭建，正如邸帅在演讲《NebulaGraph – WeDataSphere 开源介绍》中提及的那样，次要用于解决微众银行数据治理中的数据血统问题 。在应用 JanusGraph 过程中， 微众银行发现 JanusGraph 自身依赖组件较多，数据存储在 HBase 中，索引存储在 Eleasticsearch 中，而因为受分布式高可用和两地三核心架构标准要求，要搭建一套残缺的图数据库系统波及技术点较多，比方高可用问题，再加上三个组件串联，须要解决很多技术问题。而且，自身 JanusGraph 这块数据写入性能也存在问题，当然自身咱们对 JanusGraph 的优化也较少，次要集中在参数调整和平安性能晋升。
过后用这套零碎解决的数据量大略是每天 60 万个点，百万级的边，差不多一天要花 5 个小时左右能力实现写入。这就导致业务方须要应用血统数据时，大数据平台不能及时提供。
至于微众银行大数据平台为什么选用 Nebula Graph，微众银行晚期调研过一些商用、开源的图数据库解决方案，测试局部这里不做赘述，能够参考下 Nebula Graph 社区 美团、腾讯云平安团队和 Boss 直聘 做的性能测评。
这里说下方才 60 万个点、百万级别边这个场景的状况，在单节点低配机器部署状况下，微众银行导入数据基本上在 20 分钟内实现。Nebula Graph 的写入性能十分好，微众银行大数据平台这块业务对查问的性能要求并不高，Nebula Graph 也能满足大数据平台这块的查问要求。
微众银行的图数据库抉择还有一个分量考核点，高可用和容灾的架构反对 。这个考核项，Nebula Graph 自身的架构存在肯定劣势，合乎微众银行行内硬性的架构要求和标准。加上大数据平台自身旨在构建一个残缺的数据流生态，Nebula Graph 提供了一些大数据相干开源组件，比方：Connector，Exchange，这些工具能 很好地同大数据平台进行联合。
最初一点，回归到人的问题——微众银行同开源社区的交换等同于跟其余技术人的交换。和 Nebula Graph 社区交换过程中发，微众银行发现不论是在 PoC 微信群，还是在 Nebula Graph 社区论坛上提问题，官网反馈十分及时。印象较深的一点是，有一天早晨 10 点多，大数据平台在 Nebula Graph 研发人员领导下优化了一个参数，咱们在微信群里和 Nebula Graph 反馈，这个参数调整之后解决了生产问题，Nebula Graph 研发同学还给咱们发了一个 666 的表情。[手动狗头] 哈哈哈哈挺好。
OK，上面来解说下 WeDataSphere 架构，次要集中在架构设计中所思考的点。
上图和大多数利用的层级划分相似，从上往下看，应用层产生数据，通过数据交换层的各种工具，同底层的图数据库系统替换数据。利用场景方面这里不作具体介绍，在本文前面会具体地解说金融行业的利用状况。
从行业来看，两头的数据层个别分为三个局部：批量数据 、 流式数据 和在线数据。而数据交换方面，微众银行大数据平台基于 Nebula 提供的开源计划做了接入优化，底层则应用 Nebula Graph 图数据库系统。此外，微众银行大数据平台还有一套运维自动化零碎叫 Managis，基于 Managis 构建了自动化部署工具，Nebula 配置也是在类 CMDB 零碎中治理。
服务监控模块，微众银行大数据平台外部应用 Zabbix 监控，通过写脚本调用 Metric HTTP 接口，将监控指标传输到 Managis Monitor (Zabbix) 零碎中。
总体的架构如上图所示，从上至下的 4 层架构体系。
回到用户层面，搭建这套零碎在银行架构标准下如何提供给用户应用，保障服务稳定性以及可用率，是大数据平台的首要思考条件。通过借鉴 WeDataSphere 之前计算存储组件的成功经验，例如 HBase、ES 等组件，如果业务方的系统对稳定性和一致性有所要求，业务接入端须要实现双写性能；针对数据一致性方面，大数据平台做了 T+1 的数据写入校对。当然这种双写形式接入，业务端会存在革新和开发成本。
前期，基于大数据平台开源的解决方案 Linkis 提供的 Orchestrator 模块实现编排、回放、高可用。业务端无需理解具体的技术实现细节，通过调用大数据平台的 SDK 接入 Linkis 的 Orchestrator 解决方案实现高可用和数据的双读双写性能。目前这块性能尚在开发中，会在近期开源。
上图为异地容灾过程，次要依赖于 Nebula Graph 自身提供的容灾个性，比方：Checkpoint。目前，大数据平台的具体操作是每天将 Checkpoint 做数据备份同步到上海的容灾集群。一旦主集群出问题，即刻切换零碎到上海灾备集群，等主集群复原后，将数据同步到主集群。
上面来介绍下 Nebula Graph 在大数据平台 WeDataSphere 数据治理零碎中的利用。
先简略地介绍一下 WeDataSphere 数据治理零碎，它包含
数据建模工具
元数据管理系统
数据脱敏零碎
数据品质管理系统
元数据管理系统会对接数据建模工具、数据品质管控零碎、以及数据脱敏零碎，最终提供给用户一套前端的操作界面。
当中比拟要害的组件叫数据地图，次要为整个银行的数据资产目录，它采集各个数据源的数据，通过 WeDataSphere 对数据进行加工存储，最初返回一份全行残缺的数据资产 / 数据字典。在这个过程中，大数据平台构建了数据治理的标准和要求。
这套数据系统升高了用户应用门槛，直观地通知用户数据在哪，如果某个用户要审批数据，提交一个数据申请单便可提取他想要的数据，甚至在数据提取之前，零碎告知用户数据源是谁，能够找到谁要数据。这也体现了这套数据治理零碎中数据血统的能力：数据源是哪里，上游又是哪里。
上图为数据治理零碎的性能架构，最上层为零碎须要采集的数据，以及它对应的数据存储中央。在这个架构中，大数据平台采纳 3 个底层存储引擎：次要存储元数据的 TiDB、存储图数据的 Nebula Graph、存储索引数据的 ES。在底层存储的下面，数据地图提供了多个微服务提供给内部应用的申请接口。
上面解说下 WeDataSphere 数据治理零碎中血统数据的处理过程。咱们 通过各种组件 Hook 从 Hive、Spark、Sqoop 等工作脚本中解析输出数据和输入数据构建血统数据。例如：当中的 Hive Hook 次要解决大数据平台外部的表与表之间的关系，咱们通过 Hive 自身提供的 Lineage SDK 包装了数据接口，构建一个 Hook 去解析 SQL 语句的输出数据和输入数据，从而建设血缘关系记录在 Log 中。Spark 相似，不过微众银行是自研 Spark 在 Drive 层的 Hook。Sqoop 这块实现是基于 Sqoop 的 Patch 解析数据在 importer 和 exporter job 过程中提供的 Public Data，最终构建关系型数据库（比方：MySQL、Oracle、DB2）和大数据平台 Hive 数据之间的流向关系。血统数据生成之后写入执行节点，即 Driver 所在节点，从而造成 Lineage Log。
再用微众银行外部的自动化运维工具 AOMP 每日从各个节点导入数据存储到 Hive ODS DB。在这个过程中，大数据平台对 Hive 进行 ETL 加工同现有数据进行关联剖析失去导入图数据库的 DM 表。最初应用 Nebula Graph 提供的 Spark Writer 从 Hive 中将点和边的数据写入图数据库对应 Schema 中。
以上便是数据加工过程。
上图为大数据平台的整体数据模型，两头的 DATA 大表为 Hive 加工后的利用表，将下面的点、边信息写入 Nebula Graph Schema 中，包含解决某个 SQL 语句的 job_id，数据源 src_db_id，数据上游 dst_db_id 等等数据信息。
相对而言上图比「数据治理零碎血统图模型设计 1/3」图更直观，Schema 左侧为点，右侧为边，一个 job 对应某个 SQL 语句或 Sqoop 工作。举个例子，一个 SQL 语句会存在多个输出表，最终写入到一个输出表，在图构造中出现便是 job 入边和 job 出边，对应 source table 和 destination table。表和 DB 自身存在 Contain 关系，而微众银行基于本人的业务减少了表和表的间接 Join 关系，可查问表和表之间关系，比方：一度关系。
上图是一个数据过程，下面有个 db_id，比方：158364，通过一个 job_id，例如：0555261f733b4e90824343b19810a73d 构建起了一个图构造。
这是数据治理的实时查问和批量剖析架构，次要通过 ETL 加工血统数据再写入到数据存储系统中。而上图中的 Metadata Service 会依据实时剖析需要通过 SDK 调用图数据库，将查问的返回后果传给前端做展现。
在利用场景这块，次要有两个场景，一是 实时查问 ，以某个表为起始节点，遍历上游和上游表，遍历实现后在 UI 中展现。具体的技术实现是调用 Nebula Java Client 连贯 Nebula Graph 查问失去血缘关系。二是 批量查问，当然批量查问所需的血统数据已构建好并存储在 Nebula Graph 中。针对批量查问，这里举个例子：有一个部门的表，在某个时刻处于出现异常，会影响一批表，要找到这个部门的表，首先咱们得找到它到底影响了哪些上游表，把这个残缺的链路追踪进去后挨个确认这些表是否修复。那么这时候就须要做批量查问。具体技术实现是通过 Nebula Spark Connector 连贯 Nebula Graph 批量将点和边数据导入到 Spark 封装为 DataFrame，再通过 GraphX 等图算法批量剖析失去残缺的血统链路。
上图为 WeDataSphere 实时查问界面，因为波及到敏感信息打了个马赛克，以上图的蓝色表为核心数据，查问上游的一度关系表和上游的一度关系表，大数据平台构建图数据库数据模型时退出了工夫属性，能够查问特定工夫，比方：某张表昨天到明天的血缘关系，可基于工夫维度进行数据过滤和检索。
以上，Nebula Graph 在 WeDataSphere 数据治理过程中的利用状况介绍结束。
在邸帅在演讲《NebulaGraph – WeDataSphere 开源介绍》中，WeDataSphere 提供两层数据连贯和扩大能力，前者是一站式数据业务开发治理套件 WeDataSphere，后者是计算中间件 Linkis 用于连贯底层的根底组件。而 Nebula Graph 也基于 WeDataSphere 这两层性能同现有数据业务进行联合，买通数据开发流程。
上图为 WeDataSphere 一站式数据利用开发治理门户 Studio 的数据处理流程。上图的 Exchangis 为数据交换零碎，读取不同异构数据源的数据导到大数据平台，再通过 Maskis 零碎做前置脱敏，遮挡敏感数据或进行 Hash 转换提供给业务剖析人员应用。这个零碎中有一个 Online 写 SQL 环境 Scriptis，相干研发人员能够写些 SQL 剖析语句做前置数据处理，而后数据传输给零碎中的机器学习工具 Prophecis 做建模解决。最初，数据处理实现后交付给 Qualitis 零碎做数据品质校验，失去平安、牢靠数据之后再由可视化零碎 Visualis 进行后果展现和剖析，最终发送邮件给报表接管方。
上图为用户可感知的一个流程，但整个解决流程会应用到底层技术组件，在 WeDataSphere 外部次要通过 Linkis 这个计算中间件去解决和底层组件连贯、串联问题。除此之外，Linkis 还提供了通用的多租户隔离、分流、权限管控的能力。基于 Linkis 这个计算中间件，大数据平台实现了 Linkis Nebula Engine 图剖析引擎，和 WeDataSphere 现有的大数据处理流程联合。
当初来介绍下 Linkis 数据处理流程：
第一阶段：一个工作在 DataSphere Studio 提交后，进入上图所示 Entrance，这个组件次要用于工作解析和参数接管。
第二个阶段：也是一个要害的筹备阶段，进入 Orchestrator 模块，在下面 PPT 的「同城业务数据双写」章节说过 Orchestrator 模块实现编排、分流、回放、高可用。编排会将一个 Job 拆分成 N 个细小的 Task，而这些 Task 对应的资源申请须要连贯底层 Linkis Manager，Linkis Manager 会把 Task 散发、映射到对应的执行引擎做数据处理，最初，通过 EngineConn Manger 连贯到对应执行引擎，可见和 Nebula Graph 进行数据交互的次要是 EngineConn Manger。
第三个阶段：执行。
下面整个过程的实现逻辑是可复用的，做数据利用接入时，只需建设中间件同底层引擎的连贯，数据通过 Orchestrator 模块会主动散发到对应的执行引擎做数据处理。
数据加工解决流程如上所示，和 WeDataSphere 一站式数据利用开发治理门户 Studio 的数据处理流程相似：捞数据 -> 大数据平台 -> Qualitis 数据品质校验 -> 写 SQL -> Hive / Spark 做简单的数据加工解决，最终输入之前进行数据品质校验，通过 Nebula Graph 的 Spark Writer 写到 Nebula。
这里，大数据平台提供了一个 nGQL 编程界面，因为这时数据已写入 Nebula Graph，进入 nGQL 界面后执行如下查问语句：
USE nba;
GO FROM 100 OVER follow;即可在界面返回图数据库 Nebula Graph 的查问后果，同 Nebula Graph 官网提供的可视化工具 Studio 不同，WeDataSphere 的 nGQL 界面次要是解决数据流程的串联问题，不波及具体的可视化性能，前期微众银行大数据团队也会思考和官网进行可视化方面的单干。
最初一部分是将来瞻望，先来讲下 WeDataSphere 这套图数据库系统在微众银行外部的利用，目前咱们大数据平台外部次要是利用 Nebula Graph 做 血统数据存储和剖析 ；其余业务部门也有理论利用，例如： 资管零碎解决企业关系时有用到 Nebula；咱们的 AIOPS 零碎目前也在做这块业务测试，次要是 构建运维常识图谱去实现故障的根因剖析和解决方案发现 ；此外，咱们的 审计零碎 也在基于图数据库做常识图谱构建，相干部门目前在尝试接入这套图数据库系统；咱们 风控场景业务 也已接入 WeDataSphere 图数据库系统进行测试，接下来会有更多的业务方来做这一块的尝试。
将来的话，大数据平台这边会基于 Nebula Graph 2.0 凋谢的性能和架构搭建更加自动化、更加稳固的技术架构，服务好更加要害的业务。
还有同 Nebula Graph 一起拓展图剖析这块能力，接入到整个大数据平台 WeDataSphere 这套数据处理流程中。
最初，最重要的，心愿有更多适合的业务场景可能接入到 WeDataSphere 这套图数据处理的流程和零碎中，以上是微众银行大数据平台——周可的技术分享，谢谢。
喜爱这篇文章？来来来，给咱们的 GitHub 点个 star 表激励啦~~ ????♂️????♀️ [手动跪谢]
交换图数据库技术？欢送报名加入 nMeetup 北京场，和 BOSS 直聘文洲大佬现场谈笑自若，更有美团 NLP 技术大佬和你分享美团的图数据库技术实际，以及知乎反作弊工程师和你聊 Nebula Graph 在知乎的利用。报名地址：nMeetup·北京场 | 图数据库经验之谈
举荐浏览
- 图数据库选型 | 360 数科的图数据库迁徙史