CN112380218B - 一种基于etl进行数据仓库各层数据表汇总的自动触发方法 - Google Patents

Abstract

本发明提供一种基于ETL进行数据仓库各层数据表汇总的自动触发方法，属于数据信息技术领域，本发明基于ETL工具NIFI和大数据仓库平台Hadoop，在大数据仓库平台中对数据进行分层汇总，最原始采集的数据存储在ODS层、初次汇总的存储在DWD层、针对上层应用的汇总存储在DWS层。ETL工具ODS层元数据采集成功、触发DWD层数据的汇总，DWD层的汇总触发DWS层的汇总。本发明包括：基于NIFI的依赖触发流程配置功能，及在多任务相互依赖的情况下，解决重复汇总的问题，有效避免了资源浪费和汇总报错等问题，提高了整个数据仓库的执行效率，有效支撑了上层数据的应用。

Description

一种基于ETL进行数据仓库各层数据表汇总的自动触发方法

技术领域

本发明涉及数据信息技术领域，具体地说是一种基于ETL进行数据仓库各层数据表汇总的自动触发方法。

背景技术

传统的数据仓库各层数据的采集汇总都是采用一个ETL流程实现或者是多个定时任务进行定时采集汇总实现。前者处理方法耦合性较强，一个环节出问题则会影响整体任务的进行，后者处理方法关联性太差，难以充分发挥整体执行效率。

ETL任务采用依赖触发的方式对数据进行采集汇总的过程中，如果一个任务A被多个其他任务依赖，则如果A任务重复采集或重复执行，则会触发后续多个相关任务的重复执行，如果依赖链条比较长的话，则会触发雪崩式待执行任务，对集群产生巨大资源浪费甚至压垮整个计算集群。

其次在基于Hadoop数仓的数据采集汇总过程中，在对数据进行重采、重新汇总的过程中，也往往会产生误触发的情况。这种情况很多是出现在维度表的更新时，维度表的更新往往会关联到多个事实表的汇总中，在正常的汇总流程中仅仅维度表的更新是不会触发事实表的更新的，但在重采、重新汇总等情况下则会发生。

发明内容

本发明的技术任务是解决现有技术的不足，提供一种基于ETL进行数据仓库各层数据表汇总的自动触发方法。

本发明基于Hadoop的数据仓库各层数据采集汇总的依赖触发流程实现方法设计，主要解决在基于Hadoop数仓及ETL工具NIFI实现的采集汇总任务自动化执行过程中遇到的重复触发、错误触发问题，以及依赖触发流程可能产生的雪崩式待执行计算任务，对Hadoop集群造成的巨大压力等一些列问题，从而保障采集汇总任务的顺利有序执行。

本发明解决其技术问题所采用的技术方案是：

一种基于ETL进行数据仓库各层数据表汇总的自动触发方法，该方法基于Hdp大数据集群环境以及基于NIFI的定制开发功能实现的NIFI ETL任务的依赖触发能力，在Hdp大数据集群的Hive数据仓库上进行数据仓库的建模：包括ODS层、DWD层和DWS层和DM层；

通过ETL工具NIFI对电信网元产生的数据文件进行采集入库到大数据平台HIVE，HIVE可以将结构化文件映射为HIVE的一张表，这些原始文件映射的多张表都存储在HIVE的ODS层；

ODS层采集任务执行完成后，根据配置的触发条件触发DWD层数据的汇总任务执行，这一层汇总对数据进行清洗转换等操作形成原始明细数据的存储层；

根据一个或多个DWD层的汇总任务执行结果情况可以触发DWS层汇总任务的计算汇总，这一层汇总的结果对明细数据按维度进行汇总，为上层应用尽可能多的提供服务项，用于提供后续的业务查询和OLAP分析，

最后一层DM层的汇总数据供前台应用进行数据的查询，通过rowkey提供小数据量的数据即席查询服务。

进一步地，数据主要是电信行业的结构化的B域数据，包括三户信息数据、客户使用电信业务产生的用量信息、由此产生的计费信息等，例如语音用量数据、短信用量数据、数据用量数据和订购套餐数据等。

进一步地，所述DM层的汇总数据存储在HBASE中。

进一步地，基于NIFI定制开发的NIFI任务的依赖触发流程，实现方式如下：

首先NIFI有Flow的配置页面，可以进行NIFI的任务配置以实现完成特定的任务；

其次，NIFI还有一个Stream的配置页面，可以进行NIFI Flow任务间的依赖触发关系的配置；每个Flow任务包含一个Startpoint节点和一个Endpoint节点，其中Startpoint周期性轮询或者按配置的Crontab表达式配置的时间进行执行，执行首先判断该任务是否应该执行，

对于Startpoint有两种情况，在A触发B的情况下，则针对A任务的情况下，A任务的Startpoint节点是按周期进行定时执行的，之后触发后续业务组件进行业务处理，针对B任务执行的情况，B任务的Startpoint节点会首先按配置的执行时间进行执行，执行时首先进行依赖任务执行情况的判断，及判断A任务执行结果是否满足B任务触发条件，如果满足则Startpoint节点触发后续任务节点进行业务处理，否则Startpoint节点不会触发后续任务节点；

通过Startpoint节点来配置任务的执行时间和配置任务的执行粒度信息。

进一步地，在Stream配置依赖触发关系界面添加了强依赖关系和弱依赖关系选项，强依赖关系是指该任务的执行条件只是满足一次就会触发后续任务一次，弱依赖关系则是指只有在第一次触发后续任务时，该依赖条件才起作用，如果第二次触发后续任务，则该任务执行记录被忽略。

进一步地，在Stream任务配置完成进行保存时会对强弱依赖关系进行校验，在存在一任务触发多任务情况下，会提示需要配置弱依赖关系，其选择权在用户，用户根据实际的业务场景选择重复触发后续任务、只触发一次后续任务和不触发后续任务；

进一步地，该方法可以灵活配置NIFI任务间的依赖触发关系，包括：

A任务触发B任务执行；

A任务且B任务触发C任务执行；

A任务或B任务触发C任务执行；

A任务且B任务触发C任务的同时，A任务C任务触发D任务，A任务、B任务、C任务都可以选择是强依赖关系还是弱依赖关系。

进一步地，根据Stream的配置的依赖触发关系，可以实现：

NIFI任务的依赖触发，及采集任务执行完成后，可以触发后续的汇总任务、汇总任务执行完成后可以再触发后续的汇总任务；

当采集任务重跑时，可以重复触发后续的所有任务，满足实际的业务需求；

整个依赖关系的任一环节任务重跑都会触发后续所有相关任务的重复执行。

进一步地，在重跑的场景下，触发任务的重复执行既不能多次触发也不能不触发；

针对重跑场景，实现如下配置：

A1：根据相互依赖关系，针对一个任务触发多个任务的情况，可以选择都为强依赖关系，则结果为出现重复触发；

A2：根据相互依赖关系，只选择一个为强依赖关系、另一个选择为弱依赖关系，则不会产生重复触发的场景；

A3：根据相互依赖关系，都选择为弱依赖关系，则结果为不触发后续任务执行。

本发明的一种基于ETL进行数据仓库各层数据表汇总的自动触发方法与现有技术相比所产生的有益效果是：

本发明方法依赖于大数据平台和ETL工具NIFI,在实现任务依赖触发的基础上设计实现了任务间的强依赖关系和弱依赖关系，有效避免了任务间的重复触发，增强了依赖触发配置的灵活性，使***配置更加多样化，满足更多的业务场景需求。同时，强、弱依赖关系的引入将提高集群的利用效率，将***资源使用在有效的计算任务上，同时也增加了***的稳定性，在任务设计完成后就可有效评估***所需资源等，避免了***的不稳定性。

附图说明

附图1是本发明A且B任务触发C任务的配置流程图；

附图2是本发明A或B任务触发C任务的配置流程图；

附图3是本发明A且C任务触发B任务的配置流程图；

附图4是本发明依赖触发关系配置界面图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

一种基于大数据平台仓库和ETL工具NIFI的任务依赖触发设计流程，可以灵活配置NIFI任务间的依赖触发关系，包括：

A任务触发B任务执行；

A任务且B任务触发C任务执行；

A任务或B任务触发C任务执行；

A任务且B任务触发C任务的同时，A任务C任务触发D任务，A任务、B任务、C任务都可以选择是强依赖关系还是弱依赖关系。

进一步包括：

A、B、C所有任务的执行粒度可以灵活选择，任务的执行粒度可以选择为分钟、15分钟、小时、天、周、月、季度、年；

通过Startpoint节点可以配置任务的执行时间和配置任务的执行粒度信息。

根据Stream的配置的依赖触发关系，可以实现：

NIFI任务的依赖触发，及采集任务执行完成后，可以触发后续的汇总任务、汇总任务执行完成后可以再触发后续的汇总任务；

当采集任务重跑时，可以重复触发后续的所有任务，满足实际的业务需求；

整个依赖关系的任一环节任务重跑都会触发后续所有相关任务的重复执行。

进一步包括：在重跑的场景下，触发任务的重复执行既不能多次触发也不能不触发；

针对重跑场景，可以实现如下配置：

A1：根据相互依赖关系，针对一个任务触发多个任务的情况，可以选择都为强依赖关系，则结果为出现重复触发；

A2：根据相互依赖关系，只选择一个为强依赖关系、另一个选择为弱依赖关系，则不会产生重复触发的场景；

A3：根据相互依赖关系，都选择为弱依赖关系，则结果为不触发后续任务执行。

进一步包括：新的Stream依赖关系配置完成后，会针对所有配置关系进行全局的校验，提醒用户配置关系存在的问题及会出现的情况，但最终的选择权归用户；

用户根据实际的业务场景可以选择重复触发后续任务、只触发一次后续任务和不触发后续任务；

进一步包括：基于NIFI的任务依赖触发流程配置；

实现数据仓库数据从采集到分层汇总计算任务的实现；

NIFI依赖触发关系配置可实现多种任务粒度间的触发实现；

NIFI依赖触发关系的配置可满足多种场景下的任务触发执行；

和/或，

进一步包括：

可实现正常业务处理流程，从ODS层采集任务的完成触发DWD层汇总任务的计算到触发DWS层汇总任务的计算再到DM层汇总任务的计算；

同时，可实现采集任务或者汇总任务的重跑情况下，自动化的触发后续汇总任务的汇总计算。

和/或，

可实现采集任务或汇总任务重跑只触发一次后续任务执行；

也可实现采集任务或汇总任务重跑触发多次汇总任务重跑；

也可实现采集任务或汇总任务重跑触发零次汇总任务重跑计算；

所有的情况在Stream流程配置时会给出校验结果，但选择权归用户；

本发明具体实验方案如下：

本发明基于Hdp大数据集群环境以及基于NIFI的定制开发功能实现的NIFI ETL任务的依赖触发能力。在Hdp大数据集群的Hive数据仓库上进行数据仓库的建模：主要包括ODS层、DWD层和DWS层和DM层：

数据主要是电信行业的结构化的B域数据，包括三户信息数据、客户使用电信业务产生的用量信息、由此产生的计费信息等，例如语音用量数据、短信用量数据、数据用量数据和订购套餐数据等。

通过ETL工具NIFI对电信网元产生的数据文件进行采集入库到大数据平台HIVE，HIVE可以将结构化文件映射为HIVE的一张表，这些原始文件映射的多张表都存储在HIVE的ODS层；

ODS层采集任务执行完成后，根据配置的触发条件触发DWD层数据的汇总任务执行，这一层汇总对数据进行清洗转换等操作形成原始明细数据的存储层；

根据一个或多个DWD层的汇总任务执行结果情况可以触发DWS层汇总任务的计算汇总。这一层汇总的结果对明细数据按维度进行汇总，为上层应用尽可能多的提供服务项，用于提供后续的业务查询和OLAP分析等；

最后一层DM层的汇总数据供前台应用进行数据的查询，一般存储在HBASE中，通过rowkey提供小数据量的数据即席查询服务。

在基于以上的业务场景需求下，在使用大数据平台的环境下，我们基于NIFI定制开发了NIFI任务的依赖触发流程，实现方式如下：

首先NIFI有Flow的配置页面，可以进行NIFI的任务配置以实现完成特定的任务、例如采集任务、汇总任务等，其次，NIFI还有一个Stream的配置页面，可以进行NIFI Flow任务间的依赖触发关系的配置，例如采集任务A满足一定条件下可触发汇总任务B，采集任务A、B执行成功后可触发汇总任务C等等的情况。每个Flow任务包含一个Startpoint节点和一个Endpoint节点，其中Startpoint周期性轮询或者按配置的Crontab表达式配置的时间进行执行，执行首先判断该任务是否应该执行，对于Startpoint有两种情况，例如在A触发B的情况下，则针对A任务的情况下，A任务的Startpoint节点是按周期进行定时执行的，之后触发后续业务组件进行业务处理，针对B任务执行的情况，B任务的Startpoint节点会首先按配置的执行时间进行执行，执行时首先进行依赖任务执行情况的判断，及判断A任务执行结果是否满足B任务触发条件，如果满足则Startpoint节点触发后续任务节点进行业务处理，否则Startpoint节点不会触发后续任务节点。基于上述逻辑实现了A、B任务的依赖触发流程。

在任务依赖触发关系中还有一个概念非常重要，就是任务的执行粒度，即NIFI任务执行的周期，每个NIFI任务是1分钟执行一次，还是5分钟执行一次，这对依赖触发的判断是完全不同的。举例说明，针对A触发B的情况，A的执行粒度是1分钟，则每一分钟会记录一条A的执行记录，B任务的执行粒度是每小时执行一次，则A需要在任意整点小时内每一分钟都有一个执行成功的记录才会触发小时任务B执行，即如果要触发B任务汇总8点到9点间产生的数据的任务，则A任务在8点到9点间需要执行60条任务，且每一分钟都需要有执行成功的记录。而针对A、B触发C任务的情况，则需要C任务执行周期内，A、B粒度的任务都执行成功才会触发该周期的C任务执行。

但在实际生产环境下，NIFI任务的依赖触发关系会非常的复杂，例如A且B任务触发C任务，如图1所示，A或B任务触发C任务，如图2所示，A且C任务触发B任务，如图3所示。依赖任务，像A、B这样的任务在生成环境中往往会有10到20个满足条件去触发后续一个任务。这样就会出现A任务作为依赖条件会出现在Stream流程1中，A任务的执行情况业务作为依赖条件出现在Stream2流程中，其中，Stream是指任务的依赖触发配置关系图，这样在A任务执行成功时会触发B、C或者多个依赖A任务的任务执行。这在正常顺序执行的过程中是没有任何问题的，但是在整个任务流程出现错误需要重跑部分流程，或者之前的数据没有来全，等数据来全之后，需要部分重跑采集任务，且需要触发后续汇总任务重新执行。这时针对如下情况，就会出现重复触发，如果依赖流程比较长的话，则会触发更多没有必要的汇总计算任务：A且B触发C流程执行配置在Stream1流程中，A且C触发D流程配置在Stream2流程中执行的情况下，在正常业务处理过程中，A且B任务执行成功只会触发C任务执行，C任务没有执行成功D任务是不会执行的。当时在补数重跑场景下，A任务执行成功会触发C任务执行，因为C任务执行过一次，触发C任务的B任务执行记录已经满足触发C任务了。所以A任务只要执行成功就会触发C任务，同时A任务执行成功也会触发D任务执行，因为C任务有过执行成功的执行记录，所以A有新的执行记录时会再次触发D任务执行。这是第一次触发D任务执行，当C任务执行成功后，同样会再次触发D任务的执行，这是第二次触发D任务的执行。所以，在这次重跑的场景下，会触发两次D任务的执行，同样的逻辑如果D任务作为触发任务再去触发其他任务执行时，在一次重跑过程中就会触发2的2次方次的后续流程执行。所以后续任务执行次数会成指数级增长。实际的业务场景往往出现在A表是一个维度表，会被多次汇总任务依赖，B、C、D都是事实表。

为解决类似场景下出现的问题，我们在配置依赖触发关系界面添加了强依赖关系和弱依赖关系选项如图4所示。强依赖关系是指该任务的执行条件只是满足一次就会触发后续任务一次，弱依赖关系则是指只有在第一次触发后续任务时，该依赖条件才起作用，如果第二次触发后续任务，则该任务执行记录被忽略。针对上述重复触发例子，正确的配置逻辑如下：在A且B触发C的Stream1流程中，A、B任务都配置为强依赖关系，只要A、B任务满足条件则触发C任务；在A且C触发D任务的Stream2流程中，A任务则需要配置为弱依赖关系，C任务需要配置为强依赖关系。这样在重跑补数等重复场景下D任务才会既不重跑也不漏跑，实现对***资源的有效利用。同时，在Stream任务配置完成进行保存时会对强弱依赖关系进行校验，在存在一任务触发多任务情况下，会提示需要配置弱依赖关系，但是选择权在用户，用户也可以选择两个都是强依赖关系。

Claims (4)

1.一种基于ETL进行数据仓库各层数据表汇总的自动触发方法，其特征在于，该方法基于Hdp大数据集群环境以及基于NIFI的定制开发功能实现的NIFI ETL任务的依赖触发能力，在Hdp大数据集群的Hive数据仓库上进行数据仓库的建模：包括ODS层、DWD层和DWS层和DM层；

通过ETL工具NIFI对电信网元产生的数据文件进行采集入库到大数据平台HIVE，HIVE可以将结构化文件映射为HIVE的一张表，这些原始文件映射的多张表都存储在HIVE的ODS层；

ODS层采集任务执行完成后，根据配置的触发条件触发DWD层数据的汇总任务执行，这一层汇总对数据进行清洗转换等操作形成原始明细数据的存储层；

根据一个或多个DWD层的汇总任务执行结果情况可以触发DWS层汇总任务的计算汇总，这一层汇总的结果对明细数据按维度进行汇总，为上层应用尽可能多的提供服务项，用于提供后续的业务查询和OLAP分析，

最后一层DM层的汇总数据供前台应用进行数据的查询，通过rowkey提供小数据量的数据即席查询服务；

数据是电信行业的结构化的B域数据，包括三户信息数据、客户使用电信业务产生的用量信息、由此产生的计费信息；

所述DM层的汇总数据存储在HBASE中；

基于NIFI定制开发的NIFI任务的依赖触发流程，实现方式如下：

首先NIFI有Flow的配置页面，可以进行NIFI的任务配置以实现完成特定的任务；

其次，NIFI还有一个Stream的配置页面，可以进行NIFI Flow任务间的依赖触发关系的配置；每个Flow任务包含一个Startpoint节点和一个Endpoint节点，其中Startpoint周期性轮询或者按配置的Crontab表达式配置的时间进行执行，执行首先判断该任务是否应该执行，

对于Startpoint有两种情况，在A触发B的情况下，则针对A任务的情况下，A任务的Startpoint节点是按周期进行定时执行的，之后触发后续业务组件进行业务处理，针对B任务执行的情况，B任务的Startpoint节点会首先按配置的执行时间进行执行，执行时首先进行依赖任务执行情况的判断，及判断A任务执行结果是否满足B任务触发条件，如果满足则Startpoint节点触发后续任务节点进行业务处理，否则Startpoint节点不会触发后续任务节点；

通过Startpoint节点来配置任务的执行时间和配置任务的执行粒度信息；在Stream任务配置完成进行保存时会对强弱依赖关系进行校验，在存在一任务触发多任务情况下，会提示需要配置弱依赖关系，其选择权在用户，用户根据实际的业务场景选择重复触发后续任务、只触发一次后续任务和不触发后续任务。

2.根据权利要求1所述的一种基于ETL进行数据仓库各层数据表汇总的自动触发方法，其特征在于，该方法可以灵活配置NIFI任务间的依赖触发关系，包括：

A任务触发B任务执行；

A任务且B任务触发C任务执行；

A任务或B任务触发C任务执行；

A任务且B任务触发C任务的同时，A任务C任务触发D任务，A任务、B任务、C任务都可以选择是强依赖关系还是弱依赖关系。

3.根据权利要求1所述的一种基于ETL进行数据仓库各层数据表汇总的自动触发方法，其特征在于，根据Stream的配置的依赖触发关系，可以实现：

NIFI任务的依赖触发，及采集任务执行完成后，可以触发后续的汇总任务、汇总任务执行完成后可以再触发后续的汇总任务；

当采集任务重跑时，可以重复触发后续的所有任务，满足实际的业务需求；

整个依赖关系的任一环节任务重跑都会触发后续所有相关任务的重复执行。

4.根据权利要求1所述的一种基于ETL进行数据仓库各层数据表汇总的自动触发方法，其特征在于，在重跑的场景下，触发任务的重复执行既不能多次触发也不能不触发,在Stream配置依赖触发关系界面添加了强依赖关系和弱依赖关系选项，强依赖关系是指该任务的执行条件只是满足一次就会触发后续任务一次，弱依赖关系则是指只有在第一次触发后续任务时，该依赖条件才起作用，如果第二次触发后续任务，则该任务执行记录被忽略；

针对重跑场景，实现如下配置：

A1：根据相互依赖关系，针对一个任务触发多个任务的情况，可以选择都为强依赖关系，则结果为出现重复触发；

A2：根据相互依赖关系，只选择一个为强依赖关系、另一个选择为弱依赖关系，则不会产生重复触发的场景；

A3：根据相互依赖关系，都选择为弱依赖关系，则结果为不触发后续任务执行。

Images