CN112130812B - 一种基于数据流混合编排的分析模型构建方法及系统 - Google Patents

Abstract

本发明提供了一种基于数据流混合编排的分析模型构建方法，所述基于数据流混合编排的分析模型构建方法包括以下步骤：拆分处理子任务，接收分析任务的数据流转，并将分析任务按照分析流程拆分为处理子任务；修饰处理子任务，为处理子任务定义：数据输入、数据输出及处理逻辑；封装分析任务，将分析任务封装为编码结构的数据流图；转换语言格式，将数据流图转换为标记语言格式的任务流图；调度执行，将任务流图解析，并进行分发调度执行；生成分析结果，返回调度执行的执行结果，得到分析结果。本发明还提供了一种基于数据流混合编排的分析模型构建系统。本发明能够解决了数据分析建模过程中建模方式单一、建模流程复杂、缺少混合运算支持的问题。

Description

一种基于数据流混合编排的分析模型构建方法及系统

技术领域：

本发明涉及数据分析模型构建技术领域，尤其涉及一种基于数据流混合编排的分析模型构建方法及系统。

背景技术：

随着万维网、互联网、物联网、云计算、三网融合等IT与通讯技术的迅猛发展，数据的快速增长成了许多行业所共同面对的严峻挑战和难得的机遇，信息社会已经进入了网络化的大数据时代，相较于传统数据，大数据具有体量巨大、模态繁多、增长极快、价值稀疏等特点，而要从大数据挖掘大价值，往往涉及到从预处理、分析挖掘、知识推断、决策研判、可视化交互、领域应用这样冗长的分析链路，这些特点使得传统的分析建模方法效率低且建模系统难以适用。

传统的大数据分析建模流程，对于普通业务人员来说，通常会先使用表格等分析工具去记录分析数据，通过对工具中数据的排序、叠加、存储等方式去进行分析业务，这类分析工具的分析流程繁琐，分析过程无法进行持久化记录与可视化展示；并且在分析过程中，由于业务数据规模庞大，导致分析过程中数据处理速度慢，分析效率低，且最终得到的分析结果需要通过人工筛选及整合，消耗了大量的时间成本；传统的分析建模工具如SPASS、Excel、Matlab、SAS等，对数据规模支持有限，功能结构单一，无法同时进行数据接入、数据处理、数据分析、数据评估、可视化展示等一站式分析流程构建。

随着大数据人工智能技术的发展，不断涌入出Hadoop、Spark、Tensorflow、PyTorch等分布式计算框架与深度学习框架，这些框架为大数据计算与机器学习提供了较好的平台和框架支持。对分析人员来说，在进行大数据分析建模过程中，针对不同的数据及分析模型往往需要不同框架和语言来进行分析处理才能够达到较好的分析效果，比如在处理小批量的数据集时，只需要单个节点运算避免多节点之间数据传输增加的成本；而对于大批量的数据来说，分布式运算能够通过多机并行的方式进行数据处理，并行处理所带来的性能提升远超过节点之间数据传输的消耗。因此，在进行大数据分析建模过程中，混合编排计算的需求愈加迫切，给现有的建模系统与方法带来了巨大的挑战。

因此，本领域亟需一种基于数据流混合编排的分析模型构建方法及系统。

有鉴于此，提出本发明。

发明内容：

本发明的目的在于提供一种能够更好使用的一种基于数据流混合编排的分析模型构建方法及系统，以解决现有技术中的至少一项技术问题。

具体的，本发明的第一方面，提供了一种基于数据流混合编排的分析模型构建方法，所述基于数据流混合编排的分析模型构建方法包括以下步骤：

拆分处理子任务，接收分析任务的数据流转，并将分析任务按照分析流程拆分为处理子任务；

修饰处理子任务，为处理子任务定义：数据输入、数据输出及处理逻辑；

封装分析任务，将分析任务封装为编码结构的数据流图；

转换语言格式，将数据流图转换为标记语言格式的任务流图；

调度执行，将任务流图解析，并进行分发调度执行；

生成分析结果，返回调度执行的执行结果，得到分析结果。

采用上述方案，能够有效解决大规模数据分析建模过程中遇到的建模方式单一、建模流程复杂、不易维护、缺少混合运算支持的问题，通过进行大数据分析建模的流程与业务数据流转，将分析建模任务按照数据加载、数据转换、数据预处理、特征工程、模型训练、模型预测、模型评估等流程进行拆解，形成一个数据流分析任务；其次，在数据流图中的每个处理子任务相互独立，可以独立使用不同的语言、计算框架、运行模式等进行处理逻辑实现，并在模型运行时，将数据流图转换为调度引擎能够解析的任务流图；调度过程中，调度引擎基于任务流图进行任务的分发与调度执行，并将任务执行结果返回从而生成最终的分析结果，上述过程不仅在用户交互过程中具有很好的可解释效果，降低用户搭建任务流程的门槛，同时以数据流为中心，以任务流为最终导向的模式，弥补了现有的调度引擎单纯执行工作流程序的缺点，节约了时间成本，极大的提高了用户进行大数据分析建模的效率。

优选地，所述拆分处理子任务步骤中，所述分析任务的数据流转包括分析数据集D和分析流程S，所述分析流程S记为S＝{A₁,A₂,…,A_n}，其中A_i为分析流程S中的第i个处理子任务。

优选地，所述修饰处理子任务步骤中，为拆分处理子任务步骤中所拆分的每个处理子任务A_n，定义统一标准的数据输入、数据输出及处理逻辑。

进一步地，所述修饰处理子任务步骤中为所拆分的每个处理子任务定义的数据输入、数据输出均为文件形式进行读写。

进一步地，所述修饰处理子任务步骤中，处理逻辑为传递数据输入、数据输出参数文件的路径，处理子任务的输入、输出节点的个数可根据模块的内部处理逻辑的输入和输出进行确定。

进一步地，所述修饰处理子任务步骤中，对每个处理子任务内部的定义可以互相独立。

采用上述方案，所述处理子任务的数据输入和数据输出，以模块A_i为例，所对应的数据输入为input_i＝{in_i1,in_i2…in_ij}，其中j＝input_count，input_count为模块A_i输入节点的个数；模块A_i对应的数据输出为output_i＝{out_i1out_i2…out_ik}，其中k＝output_count，output_count为模块A_i输出节点的个数；所述处理逻辑为处理子任务的内部处理逻辑，除了需要暴露输入和输出参数之外，其的实现方式可根据所处理的业务数据的特点自由选择不同的编程语言、计算框架、运行模式等来处理具体的业务，每个处理子任务之间的依赖关系基于数据的流转，对于上一个模块的输出数据可以作为其在数据流转过程中下一个模块的数据输入。

优选地，所述封装分析任务步骤中，为将分析任务封装为编码结构有向无环的数据流图。

进一步地，所述数据流图包括组件节点及边。

进一步地，所述封装分析任务步骤中，采用Json格式进行整个数据流图的封装。

进一步地，所述封装分析任务步骤中，编码结构采用Dataflow Graph，所述组件节点包括模块组件及连线组件。

进一步地，所述模块组件包括数据组件及处理组件，所述数据组件对应为数据流图中的数据集，每个数据集包含的属性包括组件的标识、组件坐标、数据存储位置信息；所述处理组件对应数据流图中的处理子任务，每个处理子任务包含的属性包括组件的标识、组件坐标、组件类型、处理子任务参数、处理子任务执行包位置、执行状态的信息。

进一步地，所述连线组件用于建立组件之间的输入输出关联关系，因此连线是有方向的，包含的属性包括连线标识，连线的起始位置组件标识，起始位置组件对应的输出点的位置，终止位置组件标识，终止位置组件对应的输入点的位置。

采用上述方案，在实际使用中，一个数据流图中，包含了多个模块组件和连线组件，对于每个模块组件和连线关联需要符合以下条件：

R1：模块组件的每个输入节点必须关联一条连线；

R2：模块组件的每个输入节点，只能关联一条连线，无法关联多条连线；

R3：模块组件的输出节点允许关联多条边或不关联边；

R4：模块组件的输出节点只能为连线起始位置；

R5：数据流图不存在环形连线状态。

优选地，所述转换语言格式步骤中，采用XML流程定义语言进行定义描述封装分析任务步骤所得数据流图。

进一步地，所述XML流程定义语言采用HPDL(Hadoop Process DefinitionLanguage)。

进一步地，所述转换语言格式步骤包括以下步骤：

遍历Dag图中的所有处理组件，对其输入进行初始化；

基于Dag图中的连线关系，构建图中所有模块组件的邻接表结构；

根据处理组件状态，通过图深度优先遍历获得图中的活跃节点；

根据活跃节点及边构建处理组件的输入输出文件映射关系；

根据活跃节点及边生成HPDL任务工作流图。

进一步地，在遍历Dag图中的所有处理组件，对其输入进行初始化步骤中，需要对图中的所有处理组件的输出节点进行初始化，不区分处理组件状态，在后续输入输出映射过程中，所有的处理组件的输入来源于上一个处理组件的输出。

进一步地，在基于Dag图中的连线关系，构建图中所有模块组件的邻接表结构步骤中，遍历图中所有的连线，根据连线所关联的组件可以确定组件之间的依赖关系，从而构建图的邻接表结构，在邻接表结构中，包含了组件节点、组件节点的前继节点集合、组件节点的后继节点集合，可以通过组件节点快速索引到前继和后继节点，从而进行图向根部和向叶子节点的遍历。

进一步地，在根据处理组件状态，通过图深度优先遍历获得图中的活跃节点步骤中，对于图中已经运行过的处理组件，基于结果复用原则，无需重复执行。

采用上述方案，在实际使用中，根据图中处理组件的运行状态及组件之间的依赖关系，寻找图中需要重新执行的组件即活跃节点，需重新执行的组件需符合以下规则：

R’1：节点为处理组件，且组件运行状态为未执行、失败、杀死，则该处理组件为活跃节点；

R’2：节点为处理组件，从当前处理组件开始，其祖先节点中有运行状态为未执行、失败、杀死，则该处理组件为活跃节点；

通过深度优先遍历方法在数据流图中搜索获得活跃节点集合。

进一步地，在根据活跃节点及边构建处理组件的输入输出文件映射关系步骤中，需要清空所有的活跃节点的状态和工作区间路径。所有的活跃节点的工作区间路径的根目录均为本次任务的工作区间。

采用上述方案，遍历所有的处理组件，若当前组件有活跃节点标识，则会动态为其的输出节点随机生成UUID，作为处理组件的输出文件的名称。处理组件的输出文件的Path规则为：工作区间目录/处理组件标识符/输出节点名称。

遍历所有的连线组件，根据连线组件所关联的起始组件A_src及输出节点序号m，终止组件A_dest及输入节点序号n，将起始模块A_src所对应的数据输出为output_k赋值给终止模块A_dest所对应的数据输入input_k。若起始组件为数据组件，则直接将数据组件的文件路径赋值给终止模块A_dest所对应的数据输入input_k。

进一步地，在根据活跃节点及边生成HPDL任务工作流图步骤中，需要根据活跃节点生成本次提交分析任务的任务流workflow文件，任务流workflow中包含了起始节点(start)、终止节点(end)、合并节点(join)、分叉节点(fork)、处理节点(action)五种类型节点，其中合并节点与分叉节点一一对应，成对出现。

优选地，所述调度执行步骤中，采用Oozie调度框架执行工作流任务的解析与调度。

进一步地，所述调度执行步骤中，所有由动作节点触发的计算和处理任务可以通过Hadoop和Spark计算框架执行。

采用上述方案，当Oozie启动了处理任务的时候，它会为任务提供一个唯一的回调URL，然后任务会在完成的时候发送通知给特定的URL，在任务无法触发回调URL的情况下，如网络崩溃，或者当任务的类型无法在完成时触发回调URL的时候，Oozie会采用轮询的机制，能够对计算或处理任务进行轮询，从而保证能够完成任务。

具体的，本发明的第二方面，提供了一种基于数据流混合编排的分析模型构建系统，所述基于数据流混合编排的分析模型构建系统采用上述基于数据流混合编排的分析模型构建方法进行建模。

综上所述，本发明具有以下有益效果：

1.本发明所提供方法能够基于业务数据流将分析模型根据步骤进行拆解，建立步骤间依赖关系，形成数据流图，数据流图中的各模块步骤相互独立可混合编排，最后将数据流图转换为任务调度工作流图通过调度引擎进行解析、分发调度与执行；

2.本发明所提供的建模方法以数据为中心，以任务流为最终导向，弥补了现有的调度引擎单纯执行工作流程序的缺点，节约了时间成本，极大的提高了用户进行大数据分析建模的效率；

3.本发明在建模过程中支持混合编排调度、实时状态监控与结果回传，提高了建模的灵活性与模型优化空间，帮助用户实时跟踪模型运行状态进行管理与监控，实现了模型训练全生命周期的管理与优化；

4.本发明中基于数据流混合编排的分析模型构建方法，所形成大数据分析建模系统，可帮助企业级用户实现复杂分析模型的构建、训练调优与流程管理，推动大数据分析技术到实际生产系统中的应用落地，挖掘和释放大数据价值。

附图说明：

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明基于数据流混合编排的分析模型构建方法的一种实施方式的流程图；

图2为本发明中Oozie工作流Workflow结构示意图。

具体实施方式：

这里将详细地对示例性实施例进行说明，其示例表示在附图中。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

在本发明使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

以下将通过实施例对本发明进行详细描述。

本发明的发明思路为以数据流为中心，将复杂的分析模型根据数据流转拆解为若干处理环节，构建数据流图，数据流图中的处理环节相互独立，支持混合编排与计算，以任务流为最终导向，将数据流图转换为任务流图，通过调度引擎解析任务流进行处理环节的分发调度、监控与结果回传，最终实现分析模型的构建与运行，该方法为业务人员提供了一种灵活可配置的分析建模框架，提高业务人员进行大数据分析建模的效率。

实施例

如图1所示，本发明提供了一种基于数据流混合编排的分析模型构建方法，所述基于数据流混合编排的分析模型构建方法包括一下步骤：

步骤S100，基于分析任务的数据流转将分析任务按照分析流程拆解为A₁,A₂…A_n个处理子任务；

步骤S200，对每个处理子任务，定义每个模块A_n的Input输入、Output输出和处理逻辑；

步骤S300，将分析任务封装为一个Json结构的有向无环数据流图DataflowGraph，图中包含组件节点和边；

步骤S400，将数据流图转换为Xml格式的任务流图Workflow Graph；

步骤S500，解析Workflow任务流图并进行分发调度执行；

步骤S600，返回各个处理子任务的执行结果，得到最终的分析结果。

在实际使用过程中，所述步骤S100的具体实施方式为：对于一个复杂的大数据分析任务，一般包含分析数据集D和分析流程S，记为S＝{A₁,A₂,…,A_n}，其中A_i为分析流程S中的第i个处理子任务，A_j为分析流程S中的第j个处理子任务，处理子任务从整体上是按照顺序执行的，即A_i和A_j的关系可能为并列关系或者前后依赖关系，其中i<j。

在实际使用过程中，步骤S200的具体实施方式为：针对步骤S100中的每个处理子任务A_n，对应的为大数据分析流程中的某个处理过程，可能为数据加载、格式转换、数据清洗、训练算法、预测算法、评估算法，即指定了统一的标准来定义每个处理子任务。

对于每个处理子任务，包含数据输入、数据输出和内部处理逻辑。对于数据的输入和输出，这里设置模块A_i所对应的数据输入为input_i＝{in_i1,in_i2…in_ij},其中j＝input_count，input_count为模块A_i输入节点的个数；同理，设置模块A_i对应的数据输出为output_i＝{out_i1,out_i2…out_ik},其中k＝output_count，output_count为模块A_i输出节点的个数。每个处理子任务中，输入和输出均为文件形式进行读写，传递的输入输出参数为文件的路径，输入输出节点的个数可根据模块的内部处理逻辑的输入和输出进行定义。

在实际使用过程中，对于处理子任务的内部逻辑，除了需要暴露输入和输出参数之外，内部的实现方式不限，可根据所处理的业务数据的特点自由选择Java、Python等编程语言进行实现，也可选择MapReduce、Spark、Tensorflow等分布式计算框架与深度学习框架来处理具体的业务。

在实际使用过程中，每个处理子任务内部实现是互相独立的，模块之间的依赖关系基于数据的流转，对于上一个模块的输出数据会作为其在数据流转过程中下一个模块的数据输入。

在实际使用过程中，步骤S300的具体实施方式为：采用Json格式进行整个数据流图Dataflow Graph的封装，在Dataflow Graph中，包括两种数据结构；

第一种为模块组件，模块组件分为两种类型：

数据组件：数据组件对应为数据流图中的数据集，每个数据集包含的属性包括组件的标识，组件坐标，数据存储位置信息；

处理组件：处理组件对应数据流图中的处理子任务，每个处理子任务包含的属性包括组件的标识，组件坐标，组件类型，处理子任务参数，处理子任务执行包位置，执行状态等信息。

在实际使用过程中，所述组件类型包括单机、分布式两种类别，其中单机表示处理子任务为单机实现方式，仅在单个节点上运行，分布式表示处理子任务的实现方式为分布式，可在多个节点上进行分布式调度运行；所述处理子任务参数包括输入输出、调试参数，其中输入输出参数为模块的输入输出文件路径，调试参数为模块暴露出的可用于调试的参数。

第二种为连线组件，连线组件用于建立组件之间的输入输出关联关系，即连线是有方向的，包括：连线标识，连线的起始位置组件标识，起始位置组件对应的输出点的位置，终止位置组件标识等信息。

在实际使用过程中，数据流图包括了多个模块组件和连线组件，对于每个模块组件和连线关联需要符合以下条件：

R1：模块组件的每个输入节点必须关联一条连线，否则在分析流程执行过程中，该模块将因缺少数据输入而无法执行；

R2：模块组件的每个输入节点，只能关联一条连线，无法关联多条连线，若需要有多个输入，则在定义处理子任务输入时进行多个数据输入的定义；

R3：模块组件的输出节点允许关联多条边或不关联边，即输出数据可被多个处理子任务使用，也可单独生成模块的输出数据，如对于评估类处理子任务，其一般为整个分析建模的最后一步，生成评估分析报告，该数据很少被其他模块使用；

R4：模块组件的输出节点只能为连线起始位置，不能为终止位置；

R5：数据流图为有向无环图，即Dag图，数据的流转不存在从某个处理子任务输出后又回到该处理子任务的情况。

在本发明的一些优选实施方式中，每一个Json结构的数据流图表示一个基于数据流的分析任务。

在实际使用过程中，步骤S400的具体实施方式为：需要将Json结构的数据流图转换为任务调度引擎能够解析的任务工作流图，采用XML流程定义语言进行定义，进一步地，采用HPDL(Hadoop Process Definition Language)定义描述任务工作流图。

采用HPDL语言，能够减少使用流程控制和动作节点，提高所得任务工作流图的质量。

在实际使用过程中，控制节点会定义执行的流程，并包含工作流的起点和终点，即start、end和fail节点，以及控制工作流的执行路径的机制，即fork和join节点。

动作节点，即机制，通过动作节点工作流会触发执行计算或者处理任务。

在本发明的一些优选实施方式中，步骤S400中还包括将Json结构数据流图转换为HPDL任务流图，所述将Json结构数据流图转换为HPDL任务流图包括以下步骤：

S410：遍历Dag图中的所有处理组件，对其输入进行初始化；

S420：基于Dag图中的连线关系，构建Dag图中所有模块组件的邻接表结构；

S430：根据处理组件状态，通过Dag图深度优先遍历获得Dag图中的活跃节点ActiveNode，即需要调度执行的节点；

S440：根据活跃节点及边构建处理组件的输入输出文件映射关系；

S450：根据活跃节点及边生成HPDL任务工作流图。

在实际使用过程中，步骤S410中，需要对Dag图中的所有处理组件的输入节点进行初始化，不区分处理组件状态，在后续输入输出映射过程中，所有的处理组件的输入来源于上一个处理组件的输出。

在实际使用过程中，步骤S420中，遍历Dag图中所有的连线，根据连线所关联的组件可以确定组件之间的依赖关系，从而构建图的邻接表结构，其中，在邻接表结构中，包含了组件节点、组件节点的前继节点集合、组件节点的后继节点集合，可以通过组件节点快速索引到前继和后继节点，从而进行图向根部和向叶子节点的遍历。

在实际使用过程中，步骤S430中，对于Dag图中已经运行过的处理组件，基于结果复用原则，可以直接使用该处理组件的生成结果，无需重复执行，故需要根据Dag图中处理组件的运行状态及组件之间的依赖关系，寻找Dag图中需要重新执行的组件，即活跃节点，需重新执行的组件需符合以下条件：

R’1：节点为处理组件，且组件运行状态为未执行、失败、杀死，则该处理组件为活跃节点；

R’2：节点为处理组件，从当前处理组件开始，如由前继节点往前回溯，直到根节点，其祖先节点中有运行状态为未执行、失败、杀死，则该处理组件为活跃节点；

在本发明的一些优选实施方式中，步骤S430还包括步骤，通过深度优先遍历方法在数据流图中搜索获得活跃节点ActiveNode集合，所述通过深度优先遍历方法在数据流图中搜索获得活跃节点ActiveNode集合包括以下步骤：

S431：遍历Dag图中所有组件；

S432：筛选出处理组件A_i，所述处理组件A_i的状态为未执行、失败或杀死状态，且未被标记为活跃节点，则将该节点加入到活跃节点中；

S433：针对S432步骤所得结果，根据Dag图邻接表结构获得处理组件A_i的后继节点Child_i＝{C₁,…,C_n}，遍历每个Child_i；

S434：针对S433中的每个Child_i，重复S432-S433步骤，直至无法筛选出满足状态为未执行、失败或杀死状态，且未被标记为活跃节点的处理组件A_i。

在实际使用过程中，步骤S440中，需要清空所有的活跃节点的状态和工作区间路径。

对于每个分析任务来说，每次运行都会生成一个工作区间路径，在工作区间路径中，每个分析任务执行的处理子任务会生成一个单独的文件夹，内部保存处理子任务的执行结果，而对于分析任务中已执行成功的处理子任务，即未标记为活跃节点，基于复用原则，不会在本次提交中执行，对于该处理子任务，会保留其之前的工作区间路径，在输入输出文件映射过程中，只需要从原有的工作区间中获得已生成的处理结果，这样极大的节省了分析任务运行的时间。

在本发明的一些优选实施方式中，步骤S440中，所有的活跃节点的工作区间路径的根目录均为本次任务的工作区间。

步骤S440中，遍历所有的处理组件，若当前组件有活跃节点标识，则会动态为其的输出节点随机生成UUID，作为处理组件的输出文件的名称。

在本发明的一些优选实施方式中，所述处理组件的输出文件的Path为：工作区间目录/处理组件标识符/输出节点名称。

步骤S440中，遍历所有的连线组件，根据连线组件所关联的起始组件A_src及输出节点序号m，终止组件A_dest及输入节点序号n，将起始模块A_src所对应的数据输出为output_k赋值给终止模块A_dest所对应的数据输入input_k。

在本发明的一些优选实施方式中，步骤S440中，若起始组件为数据组件，则直接将数据组件的文件路径赋值给终止模块A_dest所对应的数据输入input_k。

在实际使用过程中，S450步骤中，需要根据活跃节点生成本次提交分析任务的任务流workflow文件，任务流workflow中包括起始节点(start)、终止节点(end)、合并节点(join)、分叉节点(fork)、处理节点(action)五种类型节点，其中合并节点与分叉节点一一对应，成对出现。

在本发明的一些优选实施方式中，S450步骤还包括，节点类型生成步骤，所述节点类型生成包括以下步骤：

S451：根据活跃节点初始化任务流图OozieGraph，OozieGraph图中包含每个活跃节点及活跃节点关联的边相关信息；

S452：根据任务流图中的节点的出度和入度，为workflow增加start节点和end节点，其中start节点入度为0，而end节点出度为0；

S453：创建空节点队列queue，设置当前节点current＝start；

S454：获得current节点的后继节点，对每个后继节点，删除节点入度，若删除入度的后继节点的入度为0，则将后继节点入队，设置当前节点的后继节点为空；

S455：若队列中节点的个数大于1，生成fork节点和join节点。

在本发明的一些优选实施方式中，S455步骤包括：构建current节点与fork节点的边，即buildlink(current，fork)，函数buildlink(current，fork)表示将current的后继节点设置为fork，将fork的前继节点设置为current；弹出队列中的节点que_node，对每个节点que_node_i构建fork节点与其的边，即buildlink(fork，que_node_i)；遍历fork节点的每个后继节点fork_child_i，对于每个后继节点fork_child_i，遍历后继节点的孩子节点fork_child_ij即fork_child_ij，表示第i个后继节点的第j个孩子，对fork_child_ij，删除其与后继节点的边，增加join节点与其的边，即buildlink(join,fork_child_ij)；构建后继节点与join节点的边，即buildlink(fork_child_i，join)；设置current节点为join节点，重复S454～S456步骤；

S456：若队列节点个数小于1，则构建当前节点与队列中节点的边，弹出队列节点赋值给current节点，判断current是否已被赋值，未赋值则重复S454～S456步骤，已赋值进行下一步骤；

S457：生成workflow.xml文件头描述信息，创建空队列queue，将start节点入队；

S458：若queue不为空，弹出current节点，若节点为start、end、fork、join类别，则生成对应的描述信息，添加至workflow.xml中；若节点为action类别，则生成shell类别的描述信息，所述shell类别的描述信息包括：job-tracker(任务启动主节点地址)、name-node(hadoop集群namenode地址)、configuration(执行相关环境参数)、exec(执行脚本)、argument(执行脚本传入参数列表)、file(执行脚本具体位置)；

S459：遍历当前节点current的后继节点，对每个后继节点删除其入度边，若删除后节点入度为0，则将节点入队，重复S458-S459步骤，直至遍历完成；

在实际使用过程中，步骤S500的具体实施方式为：采用Oozie调度框架执行工作流任务的解析与调度，Oozie为管理Hadoop作业的工作流程调度管理系统。

其中工作流程调度管理系统Oozie包括：工作流(Workflow)任务和协调器(Coordinator)，工作流负责定义任务拓扑和执行逻辑，协调器负责工作流的依赖和触发，工作流程调度管理系统Oozie为Java Web应用程序，运行在Java servlet容器Tomcat中，并使用数据库来存储工作流。

在本发明的一些优选实施方式中，步骤S500中，所有由动作节点触发的计算和处理任务不在Oozie之中进行，工作流程调度管理系统是通过Hadoop和Spark计算框架执行。

采用上述方法能够使Oozie支持现存的Hadoop用于负载平衡和灾难恢复的机制，同时上述任务主要是异步执行，即只有文件系统的动作例外，为同步处理的。意味着对于大多数工作流动作的计算或处理任务，在工作流操作转换到工作流的下一个节点之前都需要等待，直到计算处理任务结束了之后才能够继续之后的任务。采用Oozie处理，会调用两种不同的方式检测任务是否完成，即回调和轮询。如当Oozie启动了处理任务的时候，它会为任务提供一个唯一的回调URL，然后任务会在完成的时候发送通知给特定的URL。在任务无法触发回调URL的情况下，可能由于各种原因，如网络崩溃，或者当任务的类型无法在完成时触发回调URL的时候，能够采用轮询的机制，可以对计算或处理任务进行轮询，从而保证任务的顺利完成。

如图2所示，在本发明的一些优选实施方式中，在Workflow中的每对Fork和Join中间的程序都会并行执行，当系统将任务描述文件workflow.xml提交给Oozie，A和B程序会被并行调度执行，当两个程序都执行成功时，C程序会被启动，C程序执行完成时，整个任务执行完成，如果其中任意一个任务失败，则整个任务失败。

在实际使用过程中，步骤S600的具体实施方式为：对于workflow工作流中的每个动作节点，都有对应的执行脚本run.sh，该脚本中包含了动作节点触发前的数据准备工作、执行命令、执行结果上传到分布式文件系统中，每个任务在分布式文件系统中都有特定的工作区间，在工作区间中，每个子处理任务会生成一个目录，当oozie调度该动作到特定的节点执行完成后，会将执行结果上传到分布式文件系统对应的目录中，方便后续的结果复用与查看，所述数据准备工作包括包含数据下载、执行包下载。

具体的，本发明提供了一种基于数据流混合编排的分析模型构建系统，所述基于数据流混合编排的分析模型构建系统采用上述基于数据流混合编排的分析模型构建方法进行建模。

应当指出，对于本领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (4)

1.一种基于数据流混合编排的分析模型构建方法，其特征在于：所述基于数据流混合编排的分析模型构建方法包括以下步骤：

拆分处理子任务，接收分析任务的数据流转，并将分析任务按照分析流程拆分为处理子任务；

修饰处理子任务，为处理子任务定义：数据输入、数据输出及处理逻辑；

封装分析任务，将分析任务封装为编码结构的数据流图；

转换语言格式，将数据流图转换为标记语言格式的任务流图；

调度执行，将任务流图解析，并进行分发调度执行；

生成分析结果，返回调度执行的执行结果，得到分析结果；

所述拆分处理子任务步骤中，所述分析任务的数据流转包括分析数据集D和分析流程S，分析流程S记为S＝{A₁,A₂,…,A_n}，其中A_i为分析流程S中的第i个处理子任务；

所述修饰处理子任务步骤中，为拆分处理子任务步骤中所拆分的每个处理子任务A_n，定义统一标准的数据输入、数据输出及处理逻辑；

所述封装分析任务步骤中，为将分析任务封装为编码结构有向无环的数据流图；

所述数据流图包括组件节点及边；

所述转换语言格式步骤中，采用XML流程定义语言进行定义描述封装分析任务步骤所得数据流图；

所述转换语言格式步骤包括以下步骤：

遍历Dag图中的所有处理组件，对其输入进行初始化；

基于Dag图中的连线关系，构建图中所有模块组件的邻接表结构；

根据处理组件状态，通过图深度优先遍历获得图中的活跃节点；

根据活跃节点及边构建处理组件的输入输出文件映射关系；

根据活跃节点及边生成HPDL任务工作流图；

根据图中处理组件的运行状态及组件之间的依赖关系，寻找图中需要重新执行的组件即活跃节点，需重新执行的组件需符合以下规则：

R’1：节点为处理组件，且组件运行状态为未执行、失败、杀死，则该处理组件为活跃节点；

R’2：节点为处理组件，从当前处理组件开始，其祖先节点中有运行状态为未执行、失败、杀死，则该处理组件为活跃节点。

2.根据权利要求1所述基于数据流混合编排的分析模型构建方法，其特征在于：在遍历Dag图中的所有处理组件，对其输入进行初始化步骤中，需要对图中的所有处理组件的输入节点进行初始化。

3.根据权利要求2所述基于数据流混合编排的分析模型构建方法，其特征在于：所述调度执行步骤中，采用Oozie调度框架执行工作流任务的解析与调度。

4.一种基于数据流混合编排的分析模型构建系统，其特征在于：所述基于数据流混合编排的分析模型构建系统采用如权利要求1-3任一种基于数据流混合编排的分析模型构建方法进行建模。

Images