CN112100265A - 面向大数据架构与区块链的多源数据处理方法及装置 - Google Patents

Abstract

本发明提供了一种面向大数据架构与区块链的多源数据处理方法、装置及***，其中的方法包括：对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流；实现对所述数据流的分类缓存并提供数据流输出接口；经数据流输出接口获取数据流并调用大数据开源算法对获取到的数据流进行消费；经数据流输出接口获取数据流并将获取的数据流转存至区块链。本发明提供了一个统一的、轻量级的、能够满足多种实际业务场景的数据处理平台，其实现了对不同数据源的数据采集，并将采集到的数据转换成具有统一格式的数据流，以方便各种数据查询、分析工具的快速读取。此外，分类存储的数据流能够被快速、方便地转存至区块链上，从而满足区块链应用。

Description

面向大数据架构与区块链的多源数据处理方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种面向大数据架构与区块链的多源数据处理方法及装置。

背景技术

近年来，随着科技的迅猛发展和信息化建设的推进，小到移动终端上的各个应用程序后台的用户缓存，大到服务器集群上存储的记录用户访问及自身运行状态的日志数据，数据在无时不刻以PB级别地产生、积累。数据量的增大带来了数据价值的增大，大量的数据在用户行为分析、***安全告警等领域有着至关重要的作用，在各项大数据分析技术的加持下，以往被丢弃、不被重视的众多数据开始体现出新的价值。

但另一方面，由于早期企业开发生产环境下，数据格式不规范，数据存储较为随意，缺乏集中的存储手段，也给目前的大数据处理带来了难度。众多的数据散落在未经整理的、格式不统一的各种类型的数据库中，开发人员获取数据时需要重复多次在服务器或本地主机上搭建数据管道、清洗数据才能使用，这极大的增加了开发难度、开发的时间、人力消耗。因此，如何对散落的、不统一的、数据来源复杂的数据进行采集和处理，是摆在数据管理人员和开发人员面前的难题。

基于此问题，国内外许多大型的公司企业选择建设数据仓库或数据中台，将公司内部的数据以统一的格式集中存储在数据仓库或数据中台，作为实际开发中统一的数据来源。但是，数据仓库或数据中台的开发时间长、人力成本高，集群搭建困难，架构复杂，且需要大量的实际业务数据进行支撑，广大的中小企业并不具备建设数据仓库或数据中台的条件。鉴于此，一个统一的、轻量级、能够应用多种实际业务场景的数据平台才是更符合实际的技术方案。

数据量的增多也带来了另一个问题：即数据安全的问题。传统的数据库运行在单一节点的服务器或若干台服务器组成的集群上，对于数据维护的成本很高，并且安全性不是很好。而区块链技术是一种分布式账本技术，通过密码学的原理将交易记录串联，并在节点间通过共识机制进行确认，保证交易记录不被篡改、公开透明。这就给重要数据加密提供了一条新的思路，也即将重要数据上链，通过共识加密的方式对数据进行加密存储，可以得到比以往传统数据库加密方式更好的性能和安全性保证。

但数据上链的过程中同样的存在数据转换的问题，由于区块链数据库服务器通常只开放特定端口并要求以特定HTTP请求格式发送数据，这与数据库中数据存储的格式并不直接相符，因此数据库中存储的数据格式与区块链服务器开放通信的请求中所需数据格式的转换问题也是急需解决的问题。

发明内容

为了解决上述技术问题，本发明第一方面提供了一种面向大数据架构与区块链的多源数据处理方法，该方法能够实现对来自不同数据源的异构数据采集，并将采集到的数据转换成具有统一格式的数据流。本发明的具体技术方案如下：

一种面向大数据架构与区块链的多源数据处理方法，包括：

对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流；

实现对所述数据流的分类缓存并提供数据流输出接口；

经所述数据流接口获取数据流并对获取到的数据流进行消费；和/或

经所述数据流输出接口获取数据流并将获取的数据流转存至区块链。

在一些实施例中，所述多种数据源至少包括关系型数据库和非关系型数据库，所述数据流为JSON格式的数据流。

在一些实施例中，所述从所述数据缓存及传输模块中获取数据流并将数据转存至区块链包括：将数据流解析成数据字段；提取目标数据字段并将提取到的目标数据字段封装进报文；将封装有目标数据字段的报文转存至区块链。

本发明的第二方面提供了一种面向大数据架构与区块链的多源数据处理装置，所述处理装置包括：

数据采集模块，用于对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流；

数据缓存及传输模块，实现对数据流的分类缓存并提供数据流输出接口；

数据消费模块，经所述数据流接口获取数据流并对获取到的数据流进行消费；和/或

区块链上链模块，经所述数据流接口获取数据流并将获取的数据流转存至区块链。

在一些实施例中，所述多种数据源至少包括关系型数据库和非关系型数据库，所述数据采集模块包括可并行运行的若干数据采集组件，所述若干数据采集组件经JDBC接口与所述多种数据源连接，所述若干数据采集组件包括Kafka组件、Logstash组件、Canal组件及Maxwell组件，所述数据流为JSON格式的数据流。

在一些实施例中，所述数据缓存及传输模块包括Kafka开源平台，数据流被分类缓存在所述Kafka开源平台的Topic内。

在一些实施例中，所述数据消费模块包括数据查询工具Hive、Impala和数据分析工具Spark、Storm。

在一些实施例中，所述区块链上链模块包括：

解析子模块，将数据流解析成数据字段；

封装子模块，提取目标数据字段并将提取到的目标数据字段封装进报文；

上链子模块，将封装有目标数据字段的报文转存至区块链。

在一些实施例中，所述区块链为预先布置好的私有链、联盟链或公有链。

本发明提供了一个统一的、轻量级的、能够满足多种实际业务场景的数据处理平台，其能够实现对来自不同数据源的异构数据的采集，并将采集到的数据转换成具有统一格式的数据流进行分类存储，方便各种数据查询、分析工具的快速读取。此外，分类存储的数据流能够被快速、方便地转存至区块链上。

附图说明

图1为本发明实施例提供的面向大数据架构与区块链的多源数据处理方法的流程示意图；

图2为本发明实施例提供的面向大数据架构与区块链的多源数据处理方法的流程示意图；

图3为本发明实施例提供的面向大数据架构与区块链的多源数据处理装置的流程示意图；

图4为本发明实施例提供的面向大数据架构与区块链的多源数据处理装置的流程示意图；

图5为可用于执行本发明的实施方式的环境示例；

图6为本发明实施例提供的面向大数据架构与区块链的多源数据处理方法的一个应用例的实施流程图；

图7为本发明实施例提供的面向大数据架构与区块链的多源数据处理方法的另一个应用例的实施流程图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

虽然本发明提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本发明实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行。

为了实现对散落的、不统一的、数据来源复杂的数据的采集和处理，一般需要建设数据仓库或数据中台，数据仓库或数据中台开发时间长、人力成本高，集群搭建困难，架构复杂，且需要大量的实际业务数据进行支撑。

针对现有技术中在多源数据采集、处理中的缺陷，本发明提供一种面向大数据架构与区块链的多源数据处理方法，该方法能够实现对来自不同数据源的异构数据的采集，并将采集到的数据转换成具有统一格式的数据流。

图1示出了本发明实施例提供的面向大数据架构与区块链的多源数据处理方法，为便于描述，仅示出了与本发明实施例相关的部分，详述如下：

S101、对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流。

如图5所示，数据源包括部署在数据源层的传统关系型数据库和云端非关系型数据库，传统关系型数据库包括MySQL、SQLite、Oracle、Acess等，云端非关系型数据库包括mongoOB、Redis、Hadoop、Menbase等。

实施过程中，通过部署数据采集管道，经编写好的包括有目标数据库的URL的JDBC接口即能实现对存储于不同的目标数据库中的数据的采集，并将采集的异构数据转换成具有统一格式的数据流。

可选的，如图5所示，所部署的数据采集管道层包括Kafka、Logstach、Canal和Maxwell组件。其中：Kafka组件用于实现对数据库中的源数据的采集和输入，Logstach组件用于实现对数据库日志的采集及输送，而Canal组件和Maxwell组件则用于解析数据库日志以实现对数据的读取和输出。经过这些组件的处理后，存储于不同的数据库中的异构数据被采集并以统一的Json格式的数据流被输出。

S102、实现对所述数据流的分类缓存并提供数据流输出接口。

Json格式的数据流按主题被分类缓存至Kafka开源平台的各Topic内。可选的，数据流的主题包括数据的数据来源及数据去向。其中，数据来源及数据去向根据具体的应用业务进行定义，此处不进行限定。

S103、经所述数据流接口获取数据流并对获取到的数据流进行消费。

该步骤为大数据处理引擎所执行，大数据处理引擎从Kafka开源平台内查询、获取到所需的Json格式的数据流，并对数据流进行分析、计算，从而实现相应的应用业务。可选的，如图5所示的，大数据处理引擎包括数据查询工具Hive、Impala和数据分析工具Spark、Storm等。

S104、经所述数据流输出接口获取数据流并将获取的数据流转存至区块链。

该步骤为区块链处理步骤，其用于将数据流转存至区块链上。其中的区块链为预先布置好的私有链、联盟链或公有链。

可选的，如图2所示的，步骤S104具体包括：

S1041、将数据流解析成数据字段。

S1042、提取目标数据字段并将提取到的目标数据字段封装进报文；

S1043、将封装有目标数据字段的报文转存至区块链。

具体的，在获取到json格式的数据流后，通过编写解析程序对数据流进行解析，并识别、提取出需要上链的目标数据字段。之后，将提取到的需要上链条的数据字段封装至请求报文的数据字段内，以POST形式将报文通过端口转存至区块链上。

需要进行说明的，本实施例的多源数据处理方法在实际应用中，步骤S103和步骤S104可以执行其中一个，也可以两个均执行。如果两个均执行，可以并行执行，也可以选择性地先执行一个，再执行另一个。

本发明还提供了一种面向大数据架构与区块链的多源数据处理装置，如图3所示，该处理装置包括数据采集模块201、数据缓存及传输模块202、数据消费模块203及区块链上链模块204，其中：

数据采集模块201，用于对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流。

如上文实施例所提的，数据源一般分为传统关系型数据库和云端非关系型数据库，如图5所示的，传统关系型数据库包括MySQL、SQLite、Oracle、Acess等，云端非关系型数据库包括mongoOB、Redis、Hadoop、Menbase等。

可选的，如图5所示，数据采集模块201包括可并行运行的若干数据采集组件，这些数据采集组件经JDBC接口与各数据库连接。可选的，数据采集组件包括部署于数据管道层的Kafka组件、Logstash组件、Canal组件及Maxwell组件。其中：Kafka组件用于实现对数据库中的源数据的采集和输入，Logstach组件用于实现对数据库日志的采集及输送，而Canal组件和Maxwell组件则用于解析数据库日志以实现对数据的读取和输出。经过上述组件的处理后，存储于不同的数据库中的异构数据被采集并以统一的JSON格式的数据流被输出。

数据缓存及传输模块202，用于实现对数据流的分类缓存并提供数据流输出接口。

可选的，如图5所示，数据缓存及传输模块202包括部署在数据管道层的Kafka开源平台。经数据采集模块201采集及输出的JSON数据流被分类缓存在Kafka开源平台的Topic内。可选的，数据流的主题包括数据的数据来源及数据去向。其中，数据来源及数据去向根据具体的应用业务进行定义，此处不进行限定。

数据消费模块203，用于经所述数据流接口获取数据流并调用大数据开源算法对获取到的数据流进行计算分析。可选的，如图5所示，数据消费模块包括部署在数据消费层的数据查询工具Hive、Impala和数据分析工具Spark、Storm。这些大数据处理引擎从Kafka开源平台内查询、获取到所需的Json格式的数据流，并对数据流进行分析、计算，从而实现相应的应用业务。

区块链上链模块204，用于经所述数据流接口获取数据流并将获取的数据流转存至区块链。

如图4和图5所示，可选的，区块链上链模块204包括：

解析子模块2041，将数据流解析成数据字段。

封装子模块2042，提取目标数据字段并将提取到的目标数据字段封装进报文。

上链子模块2043，将封装有目标数据字段的报文转存至区块链。

如图5所示，这些功能模块被部署在数据消费层内。

经过上述描述可知，本发明提供了一个统一的、轻量级的、能够满足多种实际业务场景的数据处理平台，其能够实现对来自不同数据源的异构数据的采集，并将采集到的数据转换成具有统一格式的数据流进行分类存储，从而方便各种数据查询、分析工具的快速读取、消费。此外，分类存储的数据流能够被快速、方便地转存至区块链上，从而满足某些对安全性、不可篡改性要求较高的业务场景的应用需求。

为了更加清楚地展现本发明的实施过程，下面将从大数据应用、区块链应用两个视角对本发明进行更加详细的示例性描述。

图6示出了大数据应用中本发明的具体实施流程，为了便于描述，下文中仅对部分流程进行着重介绍，其余部分可以参考前文中的相关描述。

如5和图6所示的，本实例采用的是Kafka中间件读取数据库数据的方式，主要有三种方式进行读取，以下分别说明：

第一种方式是通过Kafka-connect-JDBC进行实现。Kafka-connect-JDBC是由confluent平台开源的一个第三方Kafka插件，支持使用各种JDBC数据类型来复制表，从而动态的同步数据库的状态，并支持对数据库进行增删操作。其主要有三种模式：bulk批量导入模式、incrementing增量模式以及Timestamp&Incrementing时间戳结合自增模式。

该数据采集插件的部署十分简单，在配置文件中添加目标数据库的URL即可实现，并支持多种数据库源输入数据，易于扩展。插件会将按照配置文件中选择的模式将数据以JSON格式输出到Kafka的topic下的控制台中，方便后续多组件进行消费。

第二种方式是通过专门的数据管道组件实现，主要技术选型有Canal及Maxwell，其中：

Canal是一个开源的数据管道，基于数据库增量日志解析，该组件会模拟MySQLSlave的交互协议，在使用时伪装自己为MySQL Slave，从而向MySQL master发送dump协议。MySQL master收到dump请求后，开始推送binary log给slave，之后Canal收到binary log并开始解析，从而完成对MySQL数据库的同步，最后由Kafka负责对Canal数据的缓存、输出，实现了MySQL到Kafka的数据过渡。

Maxwell的优势则是能够直接将MySQL数据转换为json格式输出，使用更加简单，而后由Kafka直接进行读取即可。

经过上述三种并行的数据采集通道将数据缓存至到Kafka的topic下之后，数据采集读取工作结束，之后Kafka通过数据输出接口将json格式的数据流输出至数据消费层。

数据消费层主要有两个部分组成，一个是由Hive与Impala组成的数据查询模块，通过类sql语句完成对数据库的操作，包括添加、删除、修改及查询等各项任务；另一个是由Spark和Storm组成的数据计算处理部分，能够应对实际场景的数据计算等任务，并能够支持在Spark、Storm中完成机器学习等模型的训练，并将需要返回数据库的标记结果返送回数据库的特定字段中。

下面具体介绍数据消费层读取Kafka特定topic下数据的方法。

由于Spark已经提供了足够丰富的接口或组件，以便于大量的数据流式批量处理。在本发明中，Spark对Kafka对接时使用直连模式，不同于传统的Receiver模式通过调用高阶api的方式，直连方式没有receiver这一层次，而是基于Spark Streaming周期性的获取Kafka中某个具体topic中的每个partition中的最新offsets，之后根据设定的maxRatePerPartition来处理每一段传送进来的数据包，从而实现了Spark对Kafka数据的读取。

Storm则提供了一个storm-Kafka模块用于读取Kafka中的数据，具体的搭建方式分为以下两步：首先使用Brokerhosts接口来配置Kafka broker host与partition的mapping信息，这一步支持两种方式，一种是基于zookeeper管理实现，另一种方法是直接连接开放端口，本发明对两种方法都进行了实现；其次是使用Kafka Config配置与Kafka相关的输出信息，如单位时间输出的数据量、端口访问超时时间等。

Hive本身不能够直接同步Kafka数据，但随着日志处理等实际场景的出现，Hive到Kafka的数据连通也日渐被重视。本发明中主要是考虑了两个方案，一个是camus组件，另一个是gobblin，前者已经在2015年被归并如后者的子集中，实现方式上来者大体上是相同的，都是通过执行MapReduce任务将Kafka数据抽取到HDFS中，而后通过shell脚本从HDFS过渡到Kafka中，这种方案能够实现一个相对简单的数据管道场景，并在实际的业务场景下达到一个比较优秀的抽取速率和容量。

Impala是基于Hive实现的大数据实时查询分析引擎，直接使用了Hive的元数据库Metadata，意味着Impala元数据都存储在Hive的metastore中，并且Impala兼容Hive的类SQL语句解析，因此其只需对Hive操作即可同步到Kafka中。

图7示出了区块链应用中本发明的具体实施流程，为了便于描述，下文中仅对部分流程进行着重介绍，其余部分可以参考前文中的相关描述。

本实例中，数据上链过程中，需要依赖管理人员手动标记一个重要数据字段的标识，以标记需要进行上链操作的数据。

本发明中，出于安全性的考虑，基于Hyperleger Fabric超级账本架构搭建了一个简单的私有链，并开放了数据上链、返回合约凭证等端口供实例使用，后续也可以与其他外部的公有链对接，只需要有相应的端口开放并对接即可，本发明因此具有更好的实用性和更广泛的应用场景。

在得到数据传输层输出的JSON格式数据流后，编写程序对JSON格式进行解析，识别标记字段并确定所需要上链的数据。之后将数据封装在请求报文的数据字段中，以POST形式向端口发送数据上链请求，并接收返回报文。需要注意的是，管理人员可以主动查询状态确认存证是否成功，如果发现返回失败信息则可以再次进行数据上链请求。服务器返回的状态码若为0，表示上链成功，若为-1，则表示失败，失败原因有三种，用-3表示是非法交易，此时管理人员需要重新验证身份等信息，若为-2则为hash值错误，管理人员需重新校验数据完整性，若为4000则需要检查存证***是否发生错误。

按照上文所述，在收到服务器返回的0状态码表示已经成功上链后，开始启动服务为数据管理人员返还合约凭证，具体实施方法为：客户端向服务器端口发送GET报文请求交易详情，收到之后将交易ID返回给数据管理人员作为数据上链的数据凭证。管理人员拿到数据凭证后，可以凭借该凭证信息向区块链服务器发送POST请求，通过ID生成的hash值查询上链情况情况，并可与数据库中的原始数据进行对比，确保数据传输无误，至此完成数据转存到区块链、数据上链并返回凭证的全过程，进而完成数据转存模块去区块链模块的实现。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明权利要求所限定的范围。

上文对本发明进行了足够详细的具有一定特殊性的描述。所属领域内的普通技术人员应该理解，实施例中的描述仅仅是示例性的，在不偏离本发明的真实精神和范围的前提下做出所有改变都应该属于本发明的保护范围。本发明所要求保护的范围是由所述的权利要求书进行限定的，而不是由实施例中的上述描述来限定的。

Claims (9)

1.一种面向大数据架构与区块链的多源数据处理方法，其特征在于，所述多源数据处理方法包括：

对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流；

实现对所述数据流的分类缓存并提供数据流输出接口；

经所述数据流接口获取数据流并对获取到的数据流进行消费；和/或

经所述数据流输出接口获取数据流并将获取的数据流转存至区块链。

2.如权利要求1所述的多源数据处理方法，其特征在于，所述多种数据源至少包括关系型数据库和非关系型数据库，所述数据流为JSON格式的数据流。

3.如权利要求1所述的多源数据处理方法，其特征在于，所述从所述数据缓存及传输模块中获取数据流并将数据转存至区块链包括：

将数据流解析成数据字段；

提取目标数据字段并将提取到的目标数据字段封装进报文；

将封装有目标数据字段的报文转存至区块链。

4.一种面向大数据架构与区块链的多源数据处理装置，其特征在于，所述处理装置包括：

数据采集模块，用于对多种数据源进行数据采集并将采集到的数据转化成具有统一格式的数据流；

数据缓存及传输模块，实现对数据流的分类缓存并提供数据流输出接口；

数据消费模块，经所述数据流接口获取数据流并对获取到的数据流进行消费；和/或

区块链上链模块，经所述数据流接口获取数据流并将获取的数据流转存至区块链。

5.如权利要求4所述的多源数据处理装置，其特征在于，所述多种数据源至少包括关系型数据库和非关系型数据库，所述数据采集模块包括可并行运行的若干数据采集组件，所述若干数据采集组件经JDBC接口与所述多种数据源连接，所述若干数据采集组件包括Kafka组件、Logstash组件、Canal组件及Maxwell组件，所述数据流为JSON格式的数据流。

6.如权利要求5所述的多源数据处理装置，其特征在于，所述数据缓存及传输模块包括Kafka开源平台，数据流被分类缓存在所述Kafka开源平台的Topic内。

7.如权利要求4所述的多源数据处理装置，其特征在于，所述数据消费模块包括数据查询工具Hive、Impala和数据分析工具Spark、Storm。

8.如权利要求1所述的多源数据处理装置，其特征在于，所述区块链上链模块包括：

解析子模块，将数据流解析成数据字段；

封装子模块，提取目标数据字段并将提取到的目标数据字段封装进报文；

上链子模块，将封装有目标数据字段的报文转存至区块链。

9.如权利要求1所述的多源数据处理方法，其特征在于，所述区块链为预先布置好的私有链、联盟链或公有链。

Images