发明内容
针对现有技术中的缺陷,本发明提供基于ArangoDB引擎的多模型数据存储方法及***,基于ArangoDB为核心引擎,适用于高性能领域需求。
第一方面,一种基于ArangoDB引擎的多模型数据存储方法,包括以下步骤:
获取外部来源数据,对所述外部来源数据进行预处理后,将预处理后的外部来源数据推给Kafka集群;
利用Flink集群监控Kafka集群,并消费Kafka集群中的数据;
在Flink集群上构建计算模型,利用该计算模型对消费后的数据进行计算,将计算后的数据分别存储在ArangoDB数据库和Clickhouse数据库集群中;
接收API业务接口的业务数据,根据该业务数据从ArangoDB数据库和Clickhouse数据库集群中读取相应的数据。
优选地,所述对外部来源数据进行预处理后,将预处理后的外部来源数据推给Kafka集群具体包括:
对外部来源数据进行过滤,得到过滤数据;
将所述过滤数据按照类别推给Kafka集群中对应的Topic,每个Topic对应业务数据中指定的字段。
优选地,所述利用Flink集群监控Kafka集群,并消费Kafka集群中的数据具体包括:
利用Flink集群响应Kafka集群中Partition的偏移状态,确认是否推送该Partition对应的Topic中的过滤数据。
优选地,所述计算模型通过以下方法构建:
在Flink集群上创建StreamExecutionEnvironment,调用相应的Source算子创建原始的DataStream;
调用零到多次转换算子,生成零到多次DataStream;
调用Sink,并提交给JobManager,由JobManager进行优化后,生成所述计算模型。
优选地,所述利用该计算模型对消费后的数据进行计算,将计算后的数据分别存储在ArangoDB数据库和Clickhouse数据库集群中具体包括:
使用Zookeeper集群对Kafka集群中的服务器进行管理,其中Zookeeper集群的主服务器通过以下一种或几种方式选举得到:
定义Zookeeper集群中事务ID最大的服务器为主服务器;
定义Zookeeper集群中选举ID最大的服务器为主服务器。
第二方面,一种基于ArangoDB引擎的多模型数据存储***,包括:
逻辑层:用于获取外部来源数据,对所述外部来源数据进行预处理后,将预处理后的外部来源数据推给Kafka集群;
Kafka集群;
Flink集群:用于监控Kafka集群,并消费Kafka集群中的数据;还用于在Flink集群上构建计算模型,利用该计算模型对消费后的数据进行计算,将计算后的数据分别存储在ArangoDB数据库和Clickhouse数据库集群中;
ArangoDB数据库;
Clickhouse数据库集群;
接口层:用于接收API业务接口的业务数据,根据该业务数据从ArangoDB数据库和Clickhouse数据库集群中读取相应的数据。
优选地,所述逻辑层具体用于:
对外部来源数据进行过滤,得到过滤数据;
将所述过滤数据按照类别推给Kafka集群中对应的Topic,每个Topic对应业务数据中指定的字段。
优选地,所述Flink集群具体用于:
利用Flink集群响应Kafka集群中Partition的偏移状态,确认是否推送该Partition对应的Topic中的过滤数据。
优选地,所述计算模型通过以下方法构建:
在Flink集群上创建StreamExecutionEnvironment,调用相应的Source算子创建原始的DataStream;
调用零到多次转换算子,生成零到多次DataStream;
调用Sink,并提交给JobManager,由JobManager进行优化后,生成所述计算模型。
优选地,所述Flink集群具体用于:
使用Zookeeper集群对Kafka集群中的服务器进行管理,其中Zookeeper集群的主服务器通过以下一种或几种方式选举得到:
定义Zookeeper集群中事务ID最大的服务器为主服务器;
定义Zookeeper集群中选举ID最大的服务器为主服务器。
由上述技术方案可知,本发明提供的基于ArangoDB引擎的多模型数据存储方法及***,基于ArangoDB为核心引擎,适用于高性能领域需求。
具体实施方式
下面将结合附图对本发明技术方案的实施例进行详细的描述。以下实施例仅用于更加清楚地说明本发明的技术方案,因此只作为示例,而不能以此来限制本发明的保护范围。需要注意的是,除非另有说明,本申请使用的技术术语或者科学术语应当为本发明所属领域技术人员所理解的通常意义。
应当理解,当在本说明书和所附权利要求书中使用时,术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解,在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样,除非上下文清楚地指明其它情况,否则单数形式的“一”、“一个”及“该”意在包括复数形式。
还应当进一步理解,在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。
如在本说明书和所附权利要求书中所使用的那样,术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地,短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
实施例一:
一种基于ArangoDB引擎的多模型数据存储方法,参见图1,包括以下步骤:
S1:获取外部来源数据,对所述外部来源数据进行预处理后,将预处理后的外部来源数据推给Kafka集群,具体包括:
对外部来源数据进行过滤,得到过滤数据;
将所述过滤数据按照类别推给Kafka集群中对应的Topic,每个Topic对应业务数据中指定的字段。
具体地,Topic为每条发布到Kafka集群的消息的类别,Kafka集群是面向Topic的。外部来源数据主要为有大量的、复杂的数据类型和字段类型的数据,或者是不同来源数据库的原始数据(例如Greeplum、PostgreSQL、Oracle、Hive、Hbase等等),如果将该外部来源数据直接推给工程师,难免会出现由于工程师的操作导致意想不到的疏忽,从而影响后期接口层的快速检索,或者因为数据库自身维护索引的缓慢而影响项目的效果。
所以该方法对外部来源数据进行过滤,包括去除外部来源数据中多余的字段、不合理的字段、或者是未清理完善的垃圾数据,然后统一整合划分到Kafka集群的Topic中,每个类别的数据对应具体的Topic。比如人员库基础信息(包括证件号码、证件类型、姓名等30多个字段)可以对应名为PersonnelInfo的Topic中。账号记录表(包括账号号码、账号类型、来源等20多个字段)可以对应名为AccountInfo的Topic中。
Kafka集群可以批量提交消息或压缩消息,这样对于消息产生者(也就是外部来源数据的来源)而言,几乎感觉不到性能的开支。而消息消费者(例如Flink集群)在进行消息消费时,只需要进行初步统一数据(包括统一字段命名、统一结构、统一数据库存储格式),保证数据不可丢失即可。
S2:利用Flink集群监控Kafka集群,并消费Kafka集群中的数据;具体包括:
利用Flink集群响应Kafka集群中Partition的偏移状态,确认是否推送该Partition对应的Topic中的过滤数据。
具体地,每个Topic包含一个或多个Partition,kafka集群分配的单位为Partition。一般来说,开始会先导入一批历史数据到Kafka集群,然后将每天的动态增加数据同步到Kafka集群中。这样当需要导出历史数据的时候,可能会出现TB甚至PB的数据量(几十亿甚至百亿的数据量存储的存储空间大小),这么多数据的吞吐会给服务器和数据库带来积压。如果通过脚本来定时获取,一则不及时,二则不可靠(不能实时获取数据流状态,如果每秒去查询有会造成较多的网络IO请求)。所以该方法使用Flink集群消费Kafka集群中的消息,响应Kafka集群的Partition的偏移状态,从而确认数据是否推送。例如当需要清洗基础人员信息数据时,可以允许Flink集群访问Kafka集群中Personnelnfo Topic,访问拉取偏移数据,并对应好字段,严格执行数据字段和格式(没有字段则执行默认值,格式不对或者Error报错将舍弃垃圾数据)。
S3:在Flink集群上构建计算模型,利用该计算模型对消费后的数据进行计算,将计算后的数据分别存储在ArangoDB数据库和Clickhouse数据库集群中;
优选地,所述计算模型通过以下方法构建:
在Flink集群上创建StreamExecutionEnvironment,调用相应的Source算子创建原始的DataStream;
调用零到多次转换算子(即Transformation),每调用一次Transformation,就会生成一个新的DataStream;
调用Sink,写的程序就形成一个Data Flow Gragh(数据流图),并提交给JobManager,由JobManager进行优化后,生成所述计算模型(即包含有具体计算逻辑的Task实例)。计算模型运行时,被调度到TaskManager的slot中进行计算。
具体地,本方法将同一批数据分别存储在两个数据库中,是为了对数据的基础检索和关系计算进行分离。该方法将基础搜索放在Clickhouse数据库集群,即保证了格式符合检索,且没有复杂的存储格式,可以用来进行OLAP分析,这样就可以在秒级内响应TB级别检索,多维联表查询也保证在3~5s内完成。也可以自定义方法进行数据检索,比如Clickhouse数据库集群里存储人员信息照片,当想要根据一张照片搜索对应的人或者其它根据相似度精度排序的最新照片,可以通过自定义方法内置CalculateFeature算法搜索即可满足业务。
ArangoDB数据库用来进行关系计算,比如当想要搜索人员A是否和人员D存在关系时,可以通过Edge(ArangoDB数据存在collection中,类型分为docuemnt和edge两种格式,document用来存储多元型基础信息,edge用来存储节点和节点间关系)建立好关系:例如构建A与B存在关系,B与C、D存在关系,这样就可以通过图算法BFS(广度优先遍历算法)和DFS(深度优先遍历算法),实现亚秒级内响应A-B-D的关系和基本详情,大大的简化的计算时间,从而可以基于此进行图关系匹配、知识图谱展示等各类难点大的业务。
优选地,所述利用该计算模型对消费后的数据进行计算,将计算后的数据分别存储在ArangoDB数据库和Clickhouse数据库集群中具体包括:
使用Zookeeper集群对Kafka集群中的服务器进行管理,其中Zookeeper集群的主服务器通过以下一种或几种方式选举得到:
定义Zookeeper集群中事务ID最大的服务器为主服务器;
定义Zookeeper集群中选举ID最大的服务器为主服务器。
具体地,Zookeeper是一个分布式(集群环境)的协调服务框架,主要用来协调分布式Clickhouse数据库集群、Flink集群、Kafka集群,防止数据库或集群因为停电等外部因素或者网络IO等内部因素导致宕机。
集群或数据库中的主服务器(消息生产者和消息消费者只和主服务器进行交互)可以采用以下pk原则选出:
①比较每台Zookeeper集群中服务器的事务ID,事务ID最大的服务器为主服务器。
②如果事务ID比较不出来,比较选举ID,选举ID最大的服务器为主服务器。
③必须要满足过半性,即选举过程的过半同意。这样才能保证Zookeeper集群正常工作,所以,一般在工作中,Zookeeper集群数量一般是奇数个。
S4:接收API业务接口的业务数据,根据该业务数据从ArangoDB数据库和Clickhouse数据库集群中读取相应的数据。
具体地,假设该方法实现的业务为数据检索和查询,即将处理后的数据返回给前端,得到客户想要的需求。API业务接口可以是基于Gin框架下的WebAPI。比如可以搜索查询ArangoDB数据库API业务接口,也可以查询ArangoDB数据库业务场景,可以搜索人的基础信息数据、或者交通出行记录数据,进行关系匹配计算程序等等。
该方法基于ArangoDB为核心引擎集成得到,能够实现自定义适配索引计算、多元化数据存储、秒级亦或亚秒级调度查询、更新、***、删除等业务,成效斐然。另外还根据业务集成Flink集群、Zookeeper集群、Kafka集群实现实时批流推进,集成Clickhouse数据库集群实现秒级分析OLAP场景的业务扩展。
实施例二:
一种基于ArangoDB引擎的多模型数据存储***,参见图2,包括:
逻辑层:用于获取外部来源数据,对所述外部来源数据进行预处理后,将预处理后的外部来源数据推给Kafka集群;
Kafka集群;利用Kafka生产者和消费者机制来实现高可靠、高可用的存储数据和发送数据。Kafka集群在发送数据阶段,契合下游组件Flink集群匹配度较高。
Flink:主要负责推流。用于监控Kafka集群,并消费Kafka集群中的数据;还用于在Flink上构建计算模型,利用该计算模型对消费后的数据进行计算,将计算后的数据分别存储在ArangoDB数据库和Clickhouse数据库集群中;
ArangoDB数据库;主要负责存储数据和关系计算、自定义索引和进行Action。
Clickhouse数据库集群;主要负责存储数据和进行OLAP查询。
接口层:主要负责业务查询对接,通过HTTP协议或者TCP协议获取业务数据,实现秒级调度。用于接收API业务接口的业务数据,根据该业务数据从ArangoDB数据库和Clickhouse数据库集群中读取相应的数据。
优选地,所述逻辑层具体用于:
对外部来源数据进行过滤,得到过滤数据;
将所述过滤数据按照类别推给Kafka集群中对应的Topic,每个Topic对应业务数据中指定的字段。
优选地,所述Flink具体用于:
利用Flink响应Kafka集群中Partition的偏移状态,确认是否推送该Partition对应的Topic中的过滤数据。
优选地,所述计算模型通过以下方法构建:
在Flink上创建StreamExecutionEnvironment,调用相应的Source算子创建原始的DataStream;
调用零到多次转换算子,生成零到多次DataStream;
调用Sink,并提交给JobManager,由JobManager进行优化后,生成所述计算模型。
优选地,所述Flink具体用于:
使用Zookeeper集群对Kafka集群中的服务器进行管理,其中Zookeeper集群的主服务器通过以下一种或几种方式选举得到:
定义Zookeeper集群中事务ID最大的服务器为主服务器;
定义Zookeeper集群中选举ID最大的服务器为主服务器。
本发明实施例所提供的***,为简要描述,实施例部分未提及之处,可参考前述方法实施例中相应内容。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围,其均应涵盖在本发明的权利要求和说明书的范围当中。