Seraphdb: 轻量级图计算引擎(一) 概述

简介: 随着图技术的不断成熟,与大数据框架的融合也越来越紧密,使得使用图的场景也越来越广泛;安全领域里很多的场景也开始用图的相关技术来解决实际问题;如云安全中心利用图对关联关系的遍历能力,实现了基于进程链的安全检测, 更大程度的检测隐藏在正常操作背后的恶意行文, 为用户的主机保驾护航;同时基于多种数据的关联关系,可以实现安全事件的调查分析、溯源等;基于图来分析解决安全问题更符合现实场景,也更容易被人理解和

随着图技术的不断成熟,与大数据框架的融合也越来越紧密,使得使用图的场景也越来越广泛;安全领域里很多的场景也开始用图的相关技术来解决实际问题;如云安全中心利用图对关联关系的遍历能力,实现了基于进程链的安全检测, 更大程度的检测隐藏在正常操作背后的恶意行文, 为用户的主机保驾护航;同时基于多种数据的关联关系,可以实现安全事件的调查分析、溯源等;基于图来分析解决安全问题更符合现实场景,也更容易被人理解和接受;

      但是由于图数据库需要庞大的图存储、图计算的资源, 因此在专有云场景下,直接使用传统的图数据库或者图计算引擎,会给客户带来巨大的资源压力;目前公有云上的基于图的安全检测、时间调查以及溯源功能,在专有云上是缺失的,而这部分功能对于安全能力又提升明显,时间调查、溯源能力在护网场景下可以很大提升客户分析处理问题的效率;所以图技术落地专有云已经迫在眉睫;

      为了能够将图的能力应用在专有云的安全场景下,我们需要解决三个问题,图数据的存储问题,图计算问题以及定时任务的执行问题,解决了这三个问题,就可以将图在专有云的安全场景上落地,解决专有云的安全问题;

  

       上图为Seraphdb的结构; 作为一个开放的图引擎, 首先在存储层,我们适配了大多数的存储介质,比如ES等文档型的存储,RDS/MYSQL等关系型存储以及RocksDB等KV型的存储,这样用户可以基于现有的存储资源来实现图的能力; 

Reader/Model

Reader层提供统一的接口,向下对接底层数据存储,向上提供数据存储的基本操作,实现图存储对于图操作的透明;而Model层则作为图引擎与底层数据存储的枢纽,将图的基本操作如节点和边的CRUD,图的遍历等以及图的复杂算法如最短路径等转为Reader的操作;Reader层与Model层的结合,让seraphdb的扩展变的更加轻松; 当需要对接一种新的存储介质时,只需要基于Reader层的接口,构建新的实现类即可;

Schema

Schema层是seraphdb特有的逻辑层,它对于实现轻量级的图引擎有着重要的意义; 在传统的图数据库中,我们需要将数据按图数据库预先定义的数据格式写入到图数据库,即便是我们现在的数据格式以及索引已经具备了图遍历的能力; 而通过Schema层,将图的逻辑结构映射到底层物理存储的结构上,不但减少了人工处理数据的流程,同时对于有向图中的含有来、去向边,可以基于同一结构来实现,大大降低了图数据占用的存储;

计算逻辑层

计算逻辑层完全继承了Tinkerpop的概念, Structure、DSL、Strategy、Step均来自Tinerpop,简单介绍, Structure主要是用定义图的基本结构,如Vertex,Edge,Graph, Property等;Process API中的TraversalSource以及Traversal主要是用于定义图遍历的逻辑,Strategy则提供了一系列的拦击方法,用于在遍历过程中更改执行的逻辑、方向等;而Step则提供了最基础的执行算子;

为了能够实现轻量级一体化的图计算引擎,我们基于现有的功能做了一系列的扩展;

Steps

为了能够在gremlin中扩展自己的算子, 我们实现了自己的TraversalSource以及Traversal, 并基于自身的Traversal提供了一系列数据写出类的算子,如toJdbc(), toPrint(), toSlS(),toRocketmq()等, 满足图的遍历结果直接写到外部存储的要求;

Strategy

Tinkerpop 自有的图遍历的逻辑,通常是一步一步的查,将上一步的查询结果作为下一步查询的输入,这对于关系型数据存储来说,会同时产生大量的数据库查询,尤其是对于递归遍历而言,膨胀的查询会给数据库造成巨大的压力;

为此我们构建自己的strategy,对在关系型数据库上的图查询做了进一步的优化; 我们基于策略,实现了过滤条件提前的方式,这样将过滤放在数据库查询阶段,降低了返回的数据量; 同时我们对递归做了妥协, 强制用户加入递归的层数,同时基于用户的递归逻辑,将原来多次执行的简单查询做重建,构建为一个复杂的join查询,大大降低了数据库的压力;

任务调度

Seraphdb基于quzrtz实现了一个轻量级的分布式调度系统, 可帮助用户定时调度图的查询任务,并将结果写出,从而解决了专有云上图任务的调度问题;

         

至此,Seraphdb 轻量级图引擎方案在专有云上落地了; 后续我会继续介绍seraphdb的用法,以及在业务中的发展;希望大家能加入到讨论,提供更多的场景和方案;

       

相关实践学习
阿里云图数据库GDB入门与应用
图数据库(Graph Database,简称GDB)是一种支持Property Graph图模型、用于处理高度连接数据查询与存储的实时、可靠的在线数据库服务。它支持Apache TinkerPop Gremlin查询语言,可以帮您快速构建基于高度连接的数据集的应用程序。GDB非常适合社交网络、欺诈检测、推荐引擎、实时图谱、网络/IT运营这类高度互连数据集的场景。 GDB由阿里云自主研发,具备如下优势: 标准图查询语言:支持属性图,高度兼容Gremlin图查询语言。 高度优化的自研引擎:高度优化的自研图计算层和存储层,云盘多副本保障数据超高可靠,支持ACID事务。 服务高可用:支持高可用实例,节点故障迅速转移,保障业务连续性。 易运维:提供备份恢复、自动升级、监控告警、故障切换等丰富的运维功能,大幅降低运维成本。 产品主页:https://www.aliyun.com/product/gdb
目录
相关文章
|
2月前
|
SQL 存储 网络协议
分布式的概述
分布式的概述
|
6月前
|
分布式计算 API 数据处理
Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
【2月更文挑战第15天】Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
169 1
|
分布式计算 数据挖掘 大数据
分布式计算概述
分布式计算概述
102 0
|
存储 SQL NoSQL
大数据存储组件TiDB原理+实战篇1
大数据存储组件TiDB原理+实战篇
|
存储 SQL 分布式计算
大数据存储组件TiDB原理+实战篇2
大数据存储组件TiDB原理+实战篇
|
存储 自然语言处理 算法
ClickHouse设计原理简介(下)
ClickHouse设计原理简介(下)
373 0
ClickHouse设计原理简介(下)
|
存储 SQL 设计模式
ClickHouse设计原理简介(中)
ClickHouse设计原理简介(中)
421 1
ClickHouse设计原理简介(中)
|
SQL 分布式计算 Kubernetes
图解 DataX 核心设计原理
前段时间我在 K8s 相关文章中有提到过数据同步的项目,该项目就是基于 DataX 内核构建的,由于公司数据同步的需求,还需要在 DataX 原有的基础上支持增量同步功能,同时支持分布式调度,在「使用 K8s 进行作业调度实战分享」这篇文章中已经详细描述其中的实现。
1016 0
图解 DataX 核心设计原理
|
存储 SQL 算法
ClickHouse设计原理简介(上)
ClickHouse设计原理简介(上)
582 0
ClickHouse设计原理简介(上)
|
分布式计算 大数据 Hadoop
大数据框架原理简介(1)
大数据框架原理简介(1)
231 0
大数据框架原理简介(1)
下一篇
无影云桌面