CN112637288A - 流式数据分发方法和系统 - Google Patents

Abstract

本申请实施例提供了一种流式数据分发方法，所述方法包括：消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据；解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据；根据所述流标识，确定目标Protobuf模型；基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据；及将所述Parquet数据下发到下游节点。在本申请实施例中，通过Protobuf模型对数据进行强约束，以防止数据错位以及其导致的数据转换异常等问题；通过Protobuf格式实现嵌套数据的传输，通过将支持嵌套的Protobu格式转换为支持嵌套的Parquet格式，从而有效的实现了嵌套格式的数据的传输、读取和存储。

Description

流式数据分发方法和系统

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种流式数据分发方法、系统、计算机设备及计算机可读存储介质。

背景技术

当前的流式数据传输系统一般由数据传输层(如网关)、数据缓存层、数据分发层(controller)和数据存储终端构成。当数据源有数据上报时，所述数据源会将上报数据经由数据传输层、所述数据缓存层、所述数据分发层最终流入到所述数据存储终端。

当前数据上报方式为：当上报数据有多个字段时，在不同字段之间插入分隔符然后进行数据上报。然而，上述上报方式会有以下问题：(1)当某个字段或分隔符丢失时，容易导致数据错位，从而导致数据转换异常等；(2)对嵌套格式的支持性较差。

发明内容

本申请实施例的目的是提供一种流式数据分发方法、系统、计算机设备及计算机可读存储介质，可以用于解决以下问题：(1)当某个字段或分隔符丢失时，容易导致数据错位，从而导致数据转换异常等；(2)对嵌套格式的支持性较差。

本申请实施例的一个方面提供了一种流式数据分发方法，所述方法包括：消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据；解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据；根据所述流标识，确定目标Protobuf模型；基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据；及将所述Parquet数据下发到下游节点。

可选的，各个数据流的Protobuf模型的可执行文件存储在本地缓存中；根据所述流标识，确定目标Protobuf模型，包括：根据所述流标识，从对象存储服务节点中检索与所述流标识对应的Protobuf模型；判断检索到的Protobuf模型的版本号是否高于本地缓存中相应可执行文件的Protobuf模型的版本号；若所述检索到的Protobuf模型的版本号高于所述本地缓存中相应可执行文件的Protobuf模型的版本号，则确定所述检索到的Protobuf模型为所述目标Protobuf模型，并下载所述检索到的Protobuf模型对应的可执行文件以加载到内存中；及若检索到的Protobuf模型的版本号不高于本地缓存中相应可执行文件的Protobuf模型的版本号，则确定本地缓存中相应可执行文件的Protobuf模型为所述目标Protobuf模型。

可选的，基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据，包括：根据所述目标Protobuf模型的可执行文件，对所述Protobuf序列化数据进行反序列化以得到目标对象；从所述目标对象中提取所述多个字段，所述多个字段包括一个或多个嵌套字段；及将所述多个字段转换为扁平格式的Parquet数据。

可选的，还包括预先生成和存储各个数据流的Protobuf模型：通过用户界面接口，接收针对相应流标识的录入信息；根据所述录入信息，生成相应的Protobuf模型；对所述相应的Protobuf模型进行编译，以得到相应的可执行文件；将所述相应的Protobuf模型和所述相应的可执行文件存储到对象存储服务节点。

可选的，还包括：以预设时间间隔，检测所述对象存储服务节点中的各个数据流的Protobuf模型是否更新；及若检测到其中一个Protobuf模型发生更新，则下载该发生更新的Protobuf模型对应的可执行文件，将发生更新的Protobuf模型对应的可执行文件加载到所述内存中。

可选的，还包括：当所述Parquet数据下发到所述下游节点之后，将所述Parquet数据的元数据信息写入到Hive Metastore中。

可选的，所述Protobuf序列化数据为通过所述目标Protobuf模型进行序列化处理之后得到的数据。

本申请实施例的再一个方面提供了一种流式数据分发系统，所述系统包括：消费模块，用于消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据；解析模块，用于解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据；确定模块，用于根据所述流标识，确定目标Protobuf模型；转换模块，用于基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据；及下发模块，用于将所述Parquet数据下发到下游节点。

本申请实施例的再一个方面提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，上述处理器执行上述计算机程序时用于实现如上任一项所述的流式数据分发方法的步骤。

本申请实施例的又一个方面提供了一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时用于实现如上任一项所述的流式数据分发方法的步骤。

本申请实施例提供的流式数据分发方法、系统、计算机设备及计算机可读存储介质具有以下优势：通过Protobuf模型数据进行强约束，以防止数据错位以及其导致的数据转换异常等问题；通过Protobuf格式实现嵌套数据的传输，通过将支持嵌套的Protobu格式转换为支持嵌套的Parquet格式，从而有效的实现了嵌套格式的数据的传输、读取和存储等。

附图说明

图1示意性示出了流式数据传输链路的链路图；

图2示意性示出了根据本申请的流式数据分发方法的数据流向示意图；

图3示意性示出了根据本申请实施例一的流式数据分发方法的流程图；

图4为图3中步骤S304的子步骤图；

图5为图3中步骤S306的子步骤图；

图6至图8分别示意性示出了根据本申请实施例一的流式数据分发方法的新增流程图；

图9示意性示出了根据本申请实施例二的流式数据分发系统的框图；以及

图10示意性示出了根据本申请实施例三的适于实现流式数据分发方法的计算机设备的硬件架构示意图。

具体实施方式

为了使本申请实施例的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

在本申请的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本申请及区别每一步骤，因此不能理解为对本申请的限制。

以下为本申请涉及到的一些术语解释：

Protobuf(Google Protocol Buffer)，由google公司用于数据交换的序列结构化数据格式。

Parquet，是面向分析型业务的列式存储格式。

Flink集群(Flink Cluster)，是一个分布式系统，用于对无界和有界数据流进行有状态计算。Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。

任务部署者(JobManager)，作为Flink集群的Master节点(主节点)，负责Flink集群任务调度以及资源管理。

任务执行者(TaskManager)，作为Flink集群的Worker节点(从属节点)。TaskManager从JobManager接收需要部署的任务，负责具体的任务执行和对应任务在每个节点上的资源申请和管理。

数据输入模块(Source)，作为数据输入接口，用于从数据缓存层3中相应的主题(Topic)下消费数据。

数据解析模块(Parser)，用于对Source接收到的数据进行解析。

数据导出模块(Exporter)，用于将数据进行格式转换和/或类型转换，以得到转换后的数据。

数据输出模块(Sink)，作为数据输出接口，用于将数据分到数据存储层5的存储终端。

分区消息提交模块(Commiter)，用于分区消息等提交给元数据信息存储节点。

流标识(LogId)，可以通过三段式语义(如，部门+项目+业务)进行定义，以便可以快速锁定数据所属的范畴，同时，所述流标识还可以定义有其他附属信息，如，创建者信息等。数据流可以定义有schema(数据库的组织与结构)，如字段、类型、必填与否等信息。schema可以用于所述数据流的分析和评估操作。根据定义的schema，所述数据流的元数据信息中可以被发送相应的字段值，如业务场景等，不同业务场景可以配置不同的SLA(Service-Level Agreement，服务等级协议)质量保障。需要说明的是，这些字段值可以被用户或管理发送和修改的。

图1示意性示出了根据本申请实施例的流式数据传输链路，所述的流式数据传输链路在于提供流式的数据传输服务，如用于实时流和离线流两大场景的数据收集和分发。实时流场景，对应于秒级别的数据时效性，主要用于将数据写入到Kafka、Hbase等数据库中。离线流场景，对应于小时级别或天级别的数据时效性，主要用于将数据写入到HDFS、Hive等数据库中。所述流式数据传输系统可以由下几部分组成：数据源1、网络路由层2、数据缓冲层3、数据分发层4、数据存储层5等。

所述数据源1可以是内部数据源，也可以连接外部数据源的数据接口。所述数据源1中可以有多种格式的数据，例如，APP和Web的上报数据是HTTP(HyperText TransferProtocol，超文本传输协议)格式的数据，服务端的内部通信数据是RPC(Remote ProcedureCall，远程过程调用)格式的数据。如图1所示，所述数据源1的数据可以是通过一个或多个边缘节点接收的移动终端上报的日志数据等，也可以是数据库、数据协同系统、日志代理等各个系统或设备提供的数据。

网络路由层2，可以通过一个或多个网关节点实现，用于将BFE层1提供的数据转发到数据缓冲层3。具体的，所述网络路由层2被配置连接于BFE层1，并可以适应各种不同的业务场景和数据协议，例如，被配置用于兼容解析HTTP(HyperText Transfer Protocol，超文本传输协议)协议的APP和Web数据，和GRPC协议的内部通信数据。

数据缓冲层3，可以通过消息分发订阅系统或上述系统集群实现。在一些实施例中，数据缓冲层3可以由多套kafka cluster(kafka集群)组成，起到数据削峰填谷的作用。不同重要性、优先级、数据吞吐量的数据，可以被分流到不同的kafka cluster中，以保障不同类型数据的价值，避免系统故障影响整体数据。

数据分发层4，可以由流式数据分发方法(由多个流量分发节点Collector构成)实现，用于内容转换和分发存储，即保障数据从数据缓冲层3获取并写入到数据存储层5中对应的存储终端。具体的，所述数据分发层4用于数据的分发落地，支持的分发场景包括HDFS(Hadoop Distributed File System，Hadoop分布式文件系统)、Kafka、Hbase、ES(Elasticsearch)等，而在分发的过程中，由于不同存储终端的数据落地时效性要求可能不同，例如，HDFS的数据写入是按天进行任务的计算和应用，Kafka的数据写入一般是按秒进行任务的计算和应用，通常用于诸如实时推荐、实时计算等场景中。针对数据不同场景的分发要求，数据分发层4可以根据存储终端进行服务分组管理。例如，线上会划分为KafkaCollector组、HDFS Collector组等。不同Collector组会从数据缓冲层3获取相应主题(topic)的数据并分发至下游。

数据存储层5，用于存储数据，可以由不同形式的数据库构成，所述数据库可以是HDFS、ES、Hive、Kafka和Hbase等。

即，所述流式数据传输链路的数据流向如下：数据源1→网络路由层2→数据缓冲层3→数据分发层4→数据存储层5。通过所述流式数据传输链路，数据源中的数据可以被传输到目标终端。具体如下：数据源可以输出以LogId为流标识的数据流，通过HTTP、RPC等协议将这些数据上报给边缘节点，并依次经过网关路由层2、数据缓冲层3、数据分发层4，并最终进入到数据存储层5中的存储终端中。

作为示例，数据分发层4由集群组成，例如，Flume集群或Flink集群。以Flink集群为例：Fink集群可以消费上游节点中相应Topic下的数据流，并将该数据流处理后下发至下游节点。Flink集群可以包括JobManager和TaskManager这两个模块。如图2所示，所述TaskManager包括Source、Parser、Exporter、ParquetSink和Commiter。

以下对Source、Parser、Exporter、ParquetSink和Commiter分别进行介绍。

(1)Source：

所述Source可以从上游节点(如，数据缓存层3)中消费待下发数据。所述待下发数据封装有header(头部)和body(主体)。其中，body为PBEvent，所述PBEvent可以包括数据流的流标识、时间戳和基于目标Protobuf模型的Protobuf序列化数据。

即，当上报一组数据时，会将该一组数据根据相应的Protobuf模型转换为相应的PBEvent，并封装为用于传输的待下发数据(RawEvent)。该相应的Protobuf模型的schema文件可以预先定义有各个字段以及各个字段类型、格式、明确概念以及字段间关系(例如，两个字段之间的嵌套关系)等，以实现数据强规范。

(2)Parser：

Parser可以对Source获取的待下发数据(RawEvent)进行解析，以得到PBEvent。

作为示例，用户可以自定义所述相应的数据流的数据清洗规则，并将包括数据清洗规则的Metadata发送到Parser中，使得Parser可以对所述待下发数据执行相应的解析操作。

(3)Exporter：

Exporter可以对Protobuf序列化数据进行反序列化以及格式转换，以得到Parquet数据。

Exporter的操作步骤可以如下：

步骤一：根据PBEvent关联的流标识，定位到对应的Protobuf模型；

Protobuf模型中定义有各个字段、各个对端的格式、类型、描述以及其它各类约束规则；

步骤二：基于对应的Protobuf模型，对PBEvent进行反序列化操作以反射回一个对象。

步骤三：从这个对象中提取多个字段，所述多个字段中可以包括一个或多个嵌套字段。

步骤四：将所述多个字段转换为扁平格式的Parquet数据。

在本实施例中，可以采用a.b这样偏平格式解决嵌套问题。

例如：A嵌套有B、C时，C嵌套有D、E时，可以生成以下格式的数据：

A，对应数据A；

A.B，对应数据B，且表示B嵌套在A中；

A.C，对应数据C，且表示C嵌套在A中；

A.C.D，对应数据D，且表示D嵌套在C中，C嵌套在A中；

A.C.E，对应数据E，且表示E嵌套在C中，C嵌套在A中。

可知，通过Protobuf格式实现嵌套数据的传输，通过将支持嵌套的Protobu格式转换为支持嵌套的Parquet格式，从而有效的实现了嵌套格式的数据的传输、读取和存储等。

如图2所示，Exporter中的Protobuf模型是加载到内存中的。Protobuf模型的获取步骤如下：

步骤一：通过用户界面接口，接收用户输入的针对数据流A的录入信息，如对字段、类型、描述等。

步骤二：根据所述录入信息，生成Protobuf模型，如Schema.proto。

步骤三：对Protobuf模型进行编译，以得到可执行文件，如Schema.java、Schema.class。

步骤四：将Protobuf模型和可执行文件存储到对象存储服务(Object StorageService，OSS)节点。

Protobuf模型作为原始文件亦存储于OSS节点中，其优势在于：一种计算机语言不可能被所有进行数据上报的用户所接受或熟悉，例如，有些用户使用Java、有些用户使用C++，有些用户使用Python。不同用户可以根据上述原始文件生成对应语言的可执行文件，如schema.c。通过对应语言的可执行文件进行数据上报操作等。本实施例中，作为数据上报的一端，可以基于同一个Protobuf模型生成不同语言的可执行文件，通过相应的可执行文件对数据进行强规范并生成符合相应protobuf模型的数据。

Flink集群可以更新发生变更的Protobuf模型的.class文件，具体如下：

步骤一：Flink集群运行时，检测各个数据流的Protobuf模型是否发送变更。

步骤二：Flink集群如果检测到数据流A的Protobuf模型发生变更，则从OSS中下载该数据流A对应的Schema.class，并将Schema.class加载到JVM(Java Virtual Machine，Java虚拟机)内存中。

(4)ParquetSink：

ParquetSink可以接收Parquet数据写入到下游节点，如，HDFS指定的目录下。

(5)Commiter：

当所述Parquet数据下发到所述下游节点之后，将所述Parquet数据的元数据信息写入到Hive Metastore中，以用于告知该Parquet数据写入完毕，并提供该Parquet的查询信息。

实施例一

图3示意性示出了根据本申请实施例一的流式数据分发方法的流程图。下面计算机设备为执行主体进行示例性描述。需要说明的是，该计算机设备可以是Flink集群。

如图3所示，该流式数据分发方法可以包括步骤S300～步骤S308，其中：

步骤S300，消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据。

所述上游节点，可以为消息队列系统，如Kafka。所述待下发数据，可以为Kafka的某个Topic下的数据。

所述待下发数据封装有header(头部)和body(主体)。其中，body为PBEvent，所述PBEvent可以包括数据流的流标识、时间戳和Protobuf序列化数据。所述Protobuf序列化数据为通过所述目标Protobuf模型进行序列化处理之后得到的数据。所述Protobuf序列化数据可以包括嵌套格式的嵌套数据和提高传输数据效率。

即，当用户进行数据上报时，会在目标Protobuf模型的各种数据约束下将上报数据转换为相应的PBEvent，并封装为用于传输的待下发数据(RawEvent)目标Protobuf模型可以为一个schema文件(如，schema.proto)。在该schema文件，可以预先定义有各个字段以及各个字段的类型、格式、明确概念等，以实现数据强规范。

步骤S302，解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据。

不同的数据流可以对应不同的数据清洗规则。

用户可以自定义所述相应的数据流的数据清洗规则，并将包括数据清洗规则的Metadata发送到计算机设备中，使得计算机设备可以对所述待下发数据执行相应的解析操作。

步骤S304，根据所述流标识，确定目标Protobuf模型。

不同的数据流可以对应不同的Protobuf模型。

Protobuf模型，为schema文件(如，schema.proto)，不是可执行文件。因此，需要根据计算机环境，将Protobuf模型编译为相应格式的可执行文件，如Java环境下的.class文件。

各个Protobuf模型和相应的可执行文件，可存储在对象存储服务(OSS)节点中。

当接收某个数据流时，计算机设备会根据这个数据流的流标识查询对象存储服务节点中是否有相应的Protobuf模型及其可执行文件，并将该可执行文件加载到内存中。如果每次都要从对象存储服务节点中下载和加载同一条数据流的Protobuf模型的可执行文件，对内存的消耗非常大。然而，申请人发现，各个数据流的Protobuf文件的变更频率比较低。因此，在本实施例中，将加载过的Protobuf模型的可执行文件存储在本地缓存中，以便下次处理同一条数据流时可以直接使用。

作为示例，各个数据流的Protobuf模型的可执行文件存储在本地缓存中。如图4所示，所述步骤S304可以包括步骤S400-S406，其中：根据所述流标识，确定目标Protobuf模型，包括：步骤S400，根据所述流标识，从对象存储服务节点中检索与所述流标识对应的Protobuf模型；步骤S402，判断检索到的Protobuf模型的版本号是否高于本地缓存中相应可执行文件的Protobuf模型的版本号；步骤S404，若所述检索到的Protobuf模型的版本号高于所述本地缓存中相应可执行文件的Protobuf模型的版本号，则确定所述检索到的Protobuf模型为所述目标Protobuf模型，并下载所述检索到的Protobuf模型对应的可执行文件以加载到内存中；及步骤S406，若检索到的Protobuf模型的版本号不高于本地缓存中相应可执行文件的Protobuf模型的版本号，则确定本地缓存中相应可执行文件的Protobuf模型为所述目标Protobuf模型。在本实施例中，如果所述检索到的Protobuf模型为版本更新后的模型，则需要从对象存储服务节点重新下载和加载所述检索到的Protobuf模型对应的可执行文件。如果所述检索到的Protobuf模型的版本未更新，则可以直接使用本地缓存中的相应可执行文件进行后续操作。试验表明，本实施例所述的技术方案可以提升Protobuf解析(反序列化)性能6倍。

步骤S306，基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据。

在本实施例中，可以将所述Protobuf序列化数据进行反序列化，Parquet映射处理。如图5所示，为实现Protobuf格式的Protobuf序列化数据到Parquet数据的转化，所述步骤S306可以包括步骤S500～S504，其中：步骤S500，根据所述目标Protobuf模型的可执行文件，对所述Protobuf序列化数据进行反序列化以得到目标对象；步骤S502，从所述目标对象中提取所述多个字段，所述多个字段包括一个或多个嵌套字段；及步骤S504，将所述多个字段转换为扁平格式的Parquet数据。

在本实施例中，为高效处理嵌套问题，可以采用a.b这样偏平格式。

例如：A嵌套有B、C时，C嵌套有D、E时，可以生成以下格式的数据：

A，对应数据A；

A.B，对应数据B，且表示B嵌套在A中；

A.C，对应数据C，且表示C嵌套在A中；

A.C.D，对应数据D，且表示D嵌套在C中，C嵌套在A中；

A.C.E，对应数据E，且表示E嵌套在C中，C嵌套在A中。

步骤S308，将所述Parquet数据下发到下游节点。

所述下游节点，可以为HDFS。当然，也可以是支持Parquet格式的其他存储节点。

在申请实施例所述的流式数据分发方法，至少包括以下技术效果：

(1)通过Protobuf模型数据进行强约束，以防止数据错位以及其导致的数据转换异常等问题；

(2)通过Protobuf格式实现嵌套数据的传输，通过将支持嵌套的Protobu格式转换为支持嵌套的Parquet格式，从而有效的实现了嵌套格式的数据的传输、读取和存储等。

作为示例，为了提升Protobuf模型的灵活配置和通用性、兼容性，如图6所示，所述流式数据传输方法还可以包括预先生成和存储各个数据流的Protobuf模型，其可以包括以下子步骤：步骤S600，通过用户界面接口，接收针对相应流标识的录入信息；步骤S602，根据所述录入信息，生成相应的Protobuf模型；步骤S604，对所述相应的Protobuf模型进行编译，以得到相应的可执行文件；步骤S606，将所述相应的Protobuf模型和所述相应的可执行文件存储到对象存储服务节点。不同用户可以根据所述相应的Protobuf模型生成对应语言的可执行文件，如schema.c。通过对应语言的可执行文件进行数据上报操作等。因此，在本实施例中，作为数据上报的一端，可以基于同一个Protobuf模型生成不同语言的可执行文件，通过相应的可执行文件对数据进行强规范并生成符合相应protobuf模型的数据。

作为示例，如图7所示，所述流式数据传输方法还可以步骤S700～S702，其中：步骤S700，以预设时间间隔，检测所述对象存储服务节点中的各个数据流的Protobuf模型是否更新；及步骤S702，若检测到其中一个Protobuf模型发生更新，则下载该发生更新的Protobuf模型对应的可执行文件，将发生更新的Protobuf模型对应的可执行文件加载到所述内存中。在本实施例中，不是仅检测当前数据流对应的Protobuf模型是否发送更新，而是检查每个Protobuf模型是否更新，以便能够及时下载和更新可执行文件，以提高各个数据流的处理效率。另外，预设时间间隔是可以动态调整的。例如，根据历史更新频率数据和近期更新频率数据(如最近三天)，预测各个Protobuf模型的当前变更频率以动态调整预设时间间隔。另外，也可以对数据流进行分组，对不同数据流的Protobuf模型检测频率。

作为示例，如图8所示，所述流式数据传输方法还可以步骤S800：当所述Parquet数据下发到所述下游节点之后，将所述Parquet数据的元数据信息写入到Hive Metastore中。通过元数据信息可以表示所述Parquet数据已经完成写入以及写入的分区，以便查找。

实施例二

图9示出了根据本申请实施例二的流式数据分发系统的框图，该流式数据分发系统可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例中各程序模块的功能。如图9所示，所述流式数据分发系统900可以包括以下组成部分：

消费模块910，用于消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据；

解析模块920，用于解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据；

确定模块930，用于根据所述流标识，确定目标Protobuf模型；

转换模块940，用于基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据；及

下发模块950，用于将所述Parquet数据下发到下游节点。

在示例性的实施例中，各个数据流的Protobuf模型的可执行文件存储在本地缓存中。所述确定模块930，还用于：根据所述流标识，从对象存储服务节点中检索与所述流标识对应的Protobuf模型；判断检索到的Protobuf模型的版本号是否高于本地缓存中相应可执行文件的Protobuf模型的版本号；若所述检索到的Protobuf模型的版本号高于所述本地缓存中相应可执行文件的Protobuf模型的版本号，则确定所述检索到的Protobuf模型为所述目标Protobuf模型，并下载所述检索到的Protobuf模型对应的可执行文件以加载到内存中；及若检索到的Protobuf模型的版本号不高于本地缓存中相应可执行文件的Protobuf模型的版本号，则确定本地缓存中相应可执行文件的Protobuf模型为所述目标Protobuf模型。

在示例性的实施例中，所述转换模块940，还用于：根据所述目标Protobuf模型的可执行文件，对所述Protobuf序列化数据进行反序列化以得到目标对象；从所述目标对象中提取所述多个字段，所述多个字段包括一个或多个嵌套字段；及将所述多个字段转换为扁平格式的Parquet数据。

在示例性的实施例中，所述系统还包括生成和存储模块(未标识)，用于预先生成和存储各个数据流的Protobuf模型：通过用户界面接口，接收针对相应流标识的录入信息；根据所述录入信息，生成相应的Protobuf模型；对所述相应的Protobuf模型进行编译，以得到相应的可执行文件；将所述相应的Protobuf模型和所述相应的可执行文件存储到对象存储服务节点。

在示例性的实施例中，所述系统还包括更新模块(未标识)，用于：以预设时间间隔，检测所述对象存储服务节点中的各个数据流的Protobuf模型是否更新；及若检测到其中一个Protobuf模型发生更新，则下载该发生更新的Protobuf模型对应的可执行文件，将发生更新的Protobuf模型对应的可执行文件加载到所述内存中。

在示例性的实施例中，所述系统还包括元数据信息写入模块(未标识)，用于：当所述Parquet数据下发到所述下游节点之后，将所述Parquet数据的元数据信息写入到HiveMetastore中。

在示例性的实施例中，所述Protobuf序列化数据为通过所述目标Protobuf模型进行序列化处理之后得到的数据。

实施例三

图10示意性示出了根据本申请实施例三的适于实现流式数据分发方法的计算机设备的硬件架构示意图。所述计算机设备15其是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是工作站、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图10所示，计算机设备15至少包括但不限于：可通过系统总线相互通信链接存储器1010、处理器1020、网络接口1030。其中：

存储器1010至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器1010可以是计算机设备15的内部存储模块，例如该计算机设备15的硬盘或内存。在另一些实施例中，存储器1010也可以是计算机设备15的外部存储设备，例如该计算机设备15上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器1010还可以既包括计算机设备15的内部存储模块也包括其外部存储设备。本实施例中，存储器1010通常用于存储安装于计算机设备15的操作系统和各类应用软件，例如流式数据分发方法的程序代码等。此外，存储器1010还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器1020在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1020通常用于控制计算机设备15的总体操作，例如执行与计算机设备15进行数据交互或者通信相关的控制和处理等。本实施例中，处理器1020用于运行存储器1010中存储的程序代码或者处理数据。

网络接口1030可包括无线网络接口或有线网络接口，该网络接口1030通常用于在计算机设备15与其他计算机设备之间建立通信连接。例如，网络接口1030用于通过网络将计算机设备15与外部终端相连，在计算机设备15与外部终端之间的建立数据传输通道和通信连接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，简称为GSM)、宽带码分多址(Wideband CodeDivision Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图10仅示出了具有部件1010-1030的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器1010中的流式数据分发方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器1020)所执行，以完成本申请。

实施例四

本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的流式数据分发方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中的流式数据分发方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种流式数据分发方法，其特征在于，所述方法包括：

消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据；

解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据；

根据所述流标识，确定目标Protobuf模型；

基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据；及

将所述Parquet数据下发到下游节点。

2.根据权利要求1所述的流式数据传输方法，其特征在于，各个数据流的Protobuf模型的可执行文件存储在本地缓存中；根据所述流标识，确定目标Protobuf模型，包括：

根据所述流标识，从对象存储服务节点中检索与所述流标识对应的Protobuf模型；

判断检索到的Protobuf模型的版本号是否高于本地缓存中相应可执行文件的Protobuf模型的版本号；

若所述检索到的Protobuf模型的版本号高于所述本地缓存中相应可执行文件的Protobuf模型的版本号，则确定所述检索到的Protobuf模型为所述目标Protobuf模型，并下载所述检索到的Protobuf模型对应的可执行文件以加载到内存中；及

若检索到的Protobuf模型的版本号不高于本地缓存中相应可执行文件的Protobuf模型的版本号，则确定本地缓存中相应可执行文件的Protobuf模型为所述目标Protobuf模型。

3.根据权利要求2所述的流式数据传输方法，其特征在于，基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据，包括：

根据所述目标Protobuf模型的可执行文件，对所述Protobuf序列化数据进行反序列化以得到目标对象；

从所述目标对象中提取所述多个字段，所述多个字段包括一个或多个嵌套字段；及

将所述多个字段转换为扁平格式的Parquet数据。

4.根据权利要求2所述的流式数据传输方法，其特征在于，还包括预先生成和存储各个数据流的Protobuf模型：

通过用户界面接口，接收针对相应流标识的录入信息；

根据所述录入信息，生成相应的Protobuf模型；

对所述相应的Protobuf模型进行编译，以得到相应的可执行文件；

将所述相应的Protobuf模型和所述相应的可执行文件存储到对象存储服务节点。

5.根据权利要求2至4任意一项所述的流式数据传输方法，其特征在于，还包括：

以预设时间间隔，检测所述对象存储服务节点中的各个数据流的Protobuf模型是否更新；及

若检测到其中一个Protobuf模型发生更新，则下载该发生更新的Protobuf模型对应的可执行文件，将所述发生更新的Protobuf模型对应的可执行文件加载到所述内存中。

6.根据权利要求2至4任意一项所述的流式数据传输方法，其特征在于，还包括：

当所述Parquet数据下发到所述下游节点之后，将所述Parquet数据的元数据信息写入到Hive Metastore中。

7.根据权利要求1至4任意一项所述的流式数据传输方法，其特征在于，所述Protobuf序列化数据为通过所述目标Protobuf模型进行序列化处理之后得到的数据。

8.一种流式数据分发系统，其特征在于，所述系统包括：

消费模块，用于消费上游节点的待下发数据，所述待下发数据中封装有流标识和Protobuf序列化数据；

解析模块，用于解析所述待下发数据，以得到所述流标识和所述Protobuf序列化数据；

确定模块，用于根据所述流标识，确定目标Protobuf模型；

转换模块，用于基于所述目标Protobuf模型，将所述Protobuf序列化数据转换为Parquet数据；及

下发模块，用于将所述Parquet数据下发到下游节点。

9.一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现权利要求1至7任意一项所述流式数据分发方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时用于实现权利要求1至7任意一项所述流式数据分发方法的步骤。

Images